Solution to slave zone transfer problem (at least in my case)

Jason Vas Dias jvdias at
Wed Mar 23 00:54:31 UTC 2005

On Tue, 2005-03-22 at 19:24, Mark Andrews wrote:
> > Kevin Darcy wrote:
> > 
> > > Frank Saxton wrote:
> > > 
> > >>Thanks for the response Kevin!  After about 4 days and reading literally
> > >>hundreds of forum posts, web pages and so on, I finally figured it out
> > >>with
> > >>a clue from someone who posted something about this subject.  This really
> > >>ought to be a FAQ item IMO since literally legions of people have
> > >>apparently slugged it out trying to solve this problem over time.  The
> > >>"responses" to these questions are usually something vague along the lines
> > >>of "there's a problem with named.conf" or "you have a permissions
> > >>problem". Duh... that may indeed have been the case with the other
> > >>thousand or so
> > >>people who had this problem,  but with over 20 years of *NIX Systems
> > >>Engineering experience, I think I know how to set up file permissions.
> > >>
> > >>Anyway, I was getting the classic "permissions denied" messages same as
> > >>everyone else.  With named debug turned on, I was seeing write deny
> > >>messages for /dev/sda3 (/var) but nothing more informational than that.
> > >>
> > >>I am not a DNS person and I don't know when the /var/named/slaves scheme
> > >>came along.  I am using Bind 9.2.4.  But this, not "file permissions" is
> > >>what bit me.
> > >>
> > >>On the DNS slave, you need to set zone, file "slave/zonename"; not just
> > >>file
> > >>"zonename";  THANK YOU CHRIS!!!!!!
> > >>
> > >>Then you need to (apparently) copy your zone files into /var/named/slaves
> > >>making them 664 and owned and grouped by named.
> > >>
> > >>Once I got it to work, I didn't do a lot of testing to figure out all of
> > >>the little pieces so you might be able to get away with a different mask
> > >>or
> > >>ownerships.  But if you're having this problem and the condescending "your
> > >>files aren't writeable" responses aren't helping, try this.
> > >>
> > >>Why named can't see the files in chroot on a slave is anyone's guess.  My
> > >>symlinks are right and my file protections are right and everything was
> > >>indeed writeable.  Perhaps this was fixed in later releases of bind.
> > >>
> > >>Anyway, I hope this information saves some time for others who get dragged
> > >>into this snake pit.
> > >>
> > > Frank,
> > > There's nothing magical about any "/var/named/slaves" convention, nor do
> > > I follow that convention on any of my chroot'ed-and-running-unprivileged
> > > slave servers. If you've solved your problem, you've done so in a
> > > roundabout way.
> > > 
> > > Is your /var/named directory itself writable? Since named writes temp
> > > files, it needs to have write permission for the working directory
> > > itself, not just to the zone files in that directory. I have a "data"
> > > subdirectory off my chroot, for instance, and that works just fine...
> > > 
> > > - Kevin
> > 
> > Roundabout isn't the half of it.  
> > 
> > named owns /var/named and below. Everything is also group writeable to
> > named.  The only thing named doesn't own is /var but just for fun I opened
> > that up to the world as a test.  Absolutely no difference.
> 	But was it all writable by named?  If named does not have write
> 	permission and the directory is owned by named then it doesn't
> 	matter what the group permissions are as the *user* permissions
> 	apply.  Everybody in the group but named can write there.
> > I can't swear what actually fixed this but it absolutely had nothing to do
> > with changing file masks or file ownerships since that was already a well
> > worn road.
> 	Why don't you show us the actual permissions?
> > I got the idea of using file "slaves/zonename"; from a newsgroup posting. 
> > Why this would make any difference I haven't a clue.
> 	I suspect different ownership/permissions on /var/named vs
> 	/var/named/slaves.
> >  /var/named/slaves
> > and /var/named/zonename have the same root and the same file protections
> > (although the latter is a symling to /var/named/chroot blah blah blah).
> 	You can't symlink slave files.  The symlink will be removed
> 	when the temporary file is renamed.
> > I think what actually fixed it was putting a copy of the zone file
> > in /var/named/slaves, sort of as a "seed".  I don't know enough about bind
> > to know if this should be needed but intellectuially it sounds a little
> > silly.  However it was at this point that zone transfers started working.
> 	/var/named/slaves needs to exist.  It doesn't need content.
> > In any case, I wasted a lot of time (and I suspect others in the past have
> > as well) going over and over and over file permissions and enduring some
> > pretty condescanding comments from "Admins" who really aren't smart enough
> > to be so arrogant.
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at
One further point on this - sorry I didn't see this trail until now!

In the default Red Hat BIND install, named does not own the
$ROOTDIR/var/named directory, (where ROOTDIR is your chroot directory),
but does have own the $ROOTDIR/var/named/slaves directory, to
increase security by not allowing named to write all master zone files
by default .

So in order to enable writing to slave zone files, or to enable DDNS
updates and writing of master zone files from merged .jnl updates, 
you have to either
 - store a slave zone or DDNS updated database file "x.db" in
 - change the ownership of the $ROOTDIR/var/named directory to

If SELinux is enabled, the file ownerships and permissions alone are
not enough: you must also set the 'named_write_master_zones" boolean
to 1, using the 'setsebool' command or 'system-config-security', to
enable slave zones or DDNS .

This extra security is provided to counter known security
vulnerabilities and was mandated by our security response team.

Please, if anyone is having problems with BIND on Red Hat systems, 
raise a bugzilla:
you will get a swift response!

Jason Vas Dias,
BIND Package Maintainer
Red Hat Inc.

More information about the bind-users mailing list