suse 10.1 as a dns slave - file error
 

I've setup many DNS servers before, and I've used suse for many masters and slaves using each release since suse 9.1. I am just now trying it with suse 10.1 with a goal to upgrade and replace a couple of aging 9.2 DNS servers. I'm running into a small but annoying problem however that is occuring on both of the 10.1 replacement boxes.

I authorized the 10.1 IPs as authorized zone transfer requesters on the master box and then setup the slave zones in /etc/named.conf.include on the 10.1 slave as follows, exactly as I've configured many many DNS slaves over the years.

zone "zone.name" {
type slave;
masters { x.x.x.x; };
file "slave/zone.name";
};

This is my error.
I've found two workarounds:

#1 - remove the "file" option from the slave zone definition.
or
#2 - edit /etc/sysconfig/named and disable the chroot environment.

I'm currently using #1 which is functional and secure but does not yield a "hard copy" of the zone which is annoying since it's worked before in all previous suse versions that I've used for this.

Thinking that maybe 10.1 added a new security feature that was incompatible with me manually editing the config files I restored the original files and then setup the slave zone again using YaST's own DNS tool -- which yielded exactly the same error.

I'm thinking this is a 10.1 bug but, surprisingly, my google searches for suse 10.1 dns slave errors did not yield any useful results. 10.1's been around long enough that I figured surely someone else would've come across this by now and fixed it. I also looked for officially updated bind packages for 10.1 but it appears that the bind-9.3.2-17 it shipped with is still 10.1's latest official package.

If anyone can shed light on this I'd appreciate it, thanks.

I just solved the problem on my SuSE 10.1 server. You are probably running into a feature of 10.1 that is now on by default named "AppArmor". AppArmor is a kernel resident enforcement agent that uses files in /etc/apparmor and /etc/apparmor.d to set additional restrictions on what processes can do, per user, per binary, etc. Named is one of the daemons that is restricted by AppArmor by default, so if you are not using a completely default named configuration, then there's a good chance that AppArmor is blocking named's attempts to write files. Unfortunately, as far as I can tell, the default settings for apparmor don't log anything anywhere when it blocks something, so it's really difficult to identify as the source of the problem (not having read up on it, I'm sure there are a whole bunch of cool tools and logs you can setup, but right now, I just need to get my DNS server up). I'll :study: later.

Try stopping your named, then executing: "/etc/init.d/boot.apparmor stop" and restart your named. If everything works fine, then you've found your culprit. Look in /etc/apparmor.d for a file with the name: "usr.sbin.named" and edit that file. The format is cryptic but fairly simple. I just needed to add a line: " /home/named/** rwl," right after the line with "/var/named" on it to allow the named daemon to read and write files anywhere under "/home/named".

I hope this helps.

There's a lot of restrictions in place on 10.1, so if you run into other baffling things like this, then temporarily stopping AppArmor is a good troubleshooting step. It's really a very nice additional security measure when it's working with you, so I wouldn't leave it off for any length of time. Especially on an Internet accessible machine.

Thanks, I think you nailed it. I don't have access to the actual machines that were having difficulty right now but I was able to try your suggestion on a 10.1 development box and it solved my problem. I have every reason to believe this will work on the other machines too. Consider this resolved unless I post back.

just checking in with the final solution.

after trying several variations i found that this is the line i needed to add to the usr.sbin.named apparmor profile to get it to work with a suse stock named.conf slave directory in suse's stock chroot environment -- and then restart apparmor and named of course and delete all the tmp-* files that were left behind in the slave directory due to the apparmor prevention of the zone transfer files being saved.

it's possible i'll need to tweak the profile a little bit more, to work with master zone dynamic dns updates for example, but at least i know where to look now thanks to your tip. thanks again

I was having the same problem but, when I changed the line in the named.conf to

file "/var/lib/named/slave/domainname.com";

it works

I was having the same problem but, when I changed the line in the named.conf to

file "/var/lib/named/slave/domainname.com";

it works

Once more comment on the slave DNS
 

The interesting thing to note here is that you are putting "/slave" as the path to your slave server's zone files when in
reality the path is really "/var/lib/named/slave" but the fake path works and the real path does not work. There is no
link from /slave to /var/lib/named/slave either. I tried it both ways in my slave DNS server's named.conf file and it only works with the "/slave" path not the "/var/lib/named/slave path". And yes I first got it working by turning off the AppArmor. Thanks very much for pointing that out. The gui "yast" does make it fairly easy to configure AppArmor. I was able to turn that back on. I think that this must either be a bug in the Linux or the DNS server application.

Glad it was helpful to you. I'm sure the reason the apparmor path is /slave instead of /var/lib/named/slave is because of named running in a chroot environment. This makes /var/lib/named appear to be the / directory to named once it is running which adds add'l protection to the real / in the event named is compromised.

I haven't worked with it extensively but it looks like this problem with the slave dir was fixed in openSUSE 10.2. I recall that I had to change apparmor to allow named read/write to the master directory because I need dynamic DNS updates from my DHCP server and also desired to be able to update my master zones using nsupdate. This decreases the security of my zones in some ways but I setup the zones to require TSIG authentication which restores some of that security while still giving me the live update capability I needed.