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

[Frank Saxton]

Jason Vas Dias wrote:

> 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 isc.org
>> 
>> 
> 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
>    "slaves/x.db"
> or
>  - change the ownership of the $ROOTDIR/var/named directory to
>    named:named
> 
> 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:
> https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?component=bind
> you will get a swift response!
> 
> Jason Vas Dias,
> BIND Package Maintainer
> Red Hat Inc.

Thanks for that additional info Jason.  Everything seems to be working ok
now, thanks to all.  I do have SELinux running in enforced mode but did not
need to make the additional step that you spoke of.  

For the group and those who asked, yes of course named has write permissions
to the files it owns...  I came across several file mask recommendations in
my travels so there is some disagreement as far as what's right,
apparently.  if /var is anything other than 755 ownned and grouped by root,
selinux complains.  Below that 775 or 755 with owner and group set to named
seems to work fine.