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

[Frank Saxton]

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.

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.

I got the idea of using file "slaves/zonename"; from a newsgroup posting. 
Why this would make any difference I haven't a clue.  /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).

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.

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.