LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Suse/Novell
User Name
Password
Suse/Novell This Forum is for the discussion of Suse Linux.

Notices

Reply
 
Search this Thread
Old 09-02-2006, 10:51 PM   #1
knetknight
Member
 
Registered: Oct 2002
Location: Kansas City
Distribution: OpenSUSE, Fedora
Posts: 64

Rep: Reputation: 15
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.
Code:
Sep  2 21:32:29 dnsslave named[10083]: zone zone.name/IN: Transfer started.
Sep  2 21:32:29 dnsslave named[10083]: transfer of 'zone.name/IN' from 10.223.1.4#53: connected using 10.223.1.199#60199
Sep  2 21:32:29 dnsslave named[10083]: dumping master file: rename: slave/zone.name: permission denied
Sep  2 21:32:29 dnsslave named[10083]: transfer of 'zone.name/IN' from 10.223.1.4#53: failed while receiving responses: permission denied
Sep  2 21:32:29 dnsslave named[10083]: transfer of 'zone.name/IN' from 10.223.1.4#53: end of transfer
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.

Last edited by knetknight; 09-02-2006 at 10:54 PM.
 
Old 09-15-2006, 03:43 AM   #2
SoSpartan
LQ Newbie
 
Registered: Sep 2006
Posts: 1

Rep: Reputation: 0
Smile

Quote:
Originally Posted by knetknight
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.

...

This is my error.
Code:
Sep  2 21:32:29 dnsslave named[10083]: zone zone.name/IN: Transfer started.
Sep  2 21:32:29 dnsslave named[10083]: transfer of 'zone.name/IN' from 10.223.1.4#53: connected using 10.223.1.199#60199
Sep  2 21:32:29 dnsslave named[10083]: dumping master file: rename: slave/zone.name: permission denied
Sep  2 21:32:29 dnsslave named[10083]: transfer of 'zone.name/IN' from 10.223.1.4#53: failed while receiving responses: permission denied
Sep  2 21:32:29 dnsslave named[10083]: transfer of 'zone.name/IN' from 10.223.1.4#53: end of transfer
...

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 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.
 
Old 09-15-2006, 11:53 AM   #3
knetknight
Member
 
Registered: Oct 2002
Location: Kansas City
Distribution: OpenSUSE, Fedora
Posts: 64

Original Poster
Rep: Reputation: 15
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.
 
Old 09-17-2006, 06:40 PM   #4
knetknight
Member
 
Registered: Oct 2002
Location: Kansas City
Distribution: OpenSUSE, Fedora
Posts: 64

Original Poster
Rep: Reputation: 15
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.

Code:
/slave/** rw,
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
 
Old 11-27-2006, 11:27 PM   #5
almoj67
LQ Newbie
 
Registered: Nov 2006
Posts: 2

Rep: Reputation: 0
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


Quote:
Originally Posted by knetknight
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.

Code:
/slave/** rw,
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
 
Old 11-27-2006, 11:28 PM   #6
almoj67
LQ Newbie
 
Registered: Nov 2006
Posts: 2

Rep: Reputation: 0
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
 
Old 01-09-2007, 10:36 PM   #7
mrshock
LQ Newbie
 
Registered: Dec 2006
Posts: 1

Rep: Reputation: 0
Lightbulb Once more comment on the slave DNS

Quote:
Originally Posted by knetknight
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.

Code:
/slave/** rw,
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

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.
 
Old 01-10-2007, 10:54 AM   #8
knetknight
Member
 
Registered: Oct 2002
Location: Kansas City
Distribution: OpenSUSE, Fedora
Posts: 64

Original Poster
Rep: Reputation: 15
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.
 
  


Reply

Tags
apparmor, bind, dns, named, suse


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Slave DNS Error lindatan83 Linux - Networking 1 09-01-2006 10:02 PM
Slave dns help neocontrol Linux - Networking 5 05-12-2006 07:52 PM
transfer error to slave dns server robertngo Linux - Software 1 07-07-2005 12:06 AM
Slave Dns Question kemplej Linux - Networking 5 12-23-2004 02:58 PM
Expect script throws "open(slave pty): bad file number" error KNut Linux - Newbie 0 02-24-2004 01:24 PM


All times are GMT -5. The time now is 07:18 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration