Maybe a bug in 5.3 [Was: Re: BIND9 dump file]

[Gerard Samuel]

Erik Norgaard wrote:

>Gerard Samuel wrote:
>
>  
>
>>>Im getting a bunch of these in the logs ->
>>>Nov 10 10:30:48 gatekeeper named[312]: dumping master file:
>>>master/tmp-SLtSQEmBBK: open: permission denied
>>>
>>>So I figured a filesystem permissions problem.  I chowned
>>>Thanks for any info that you may provide...
>>>      
>>>
>>Im confused.  I've read the named and rc.conf man pages, and didn't find
>>out
>>why named is behaving as it is.
>>    
>>
>
>I don't know if this will help or is related. I had a problem with named
>not creating the pid-file with a permision denied error (see other thread).
>
>I eventually solved it by creating a new chroot-dir and setting
>permissions on that. It still remains a mystery to me why I ever got
>that problem or why this worked.
>
I dont think recreating the chroot will fix it.
According to the docs, the chroot process is automatic in 5.3.
And since, I have no idea where these *automatic* instructions live,
I dont think moving/recreating the chroot will fix it.
I believe the problem lies within the *automatic* instructions.
Even in the docs for DNS in the handbook states that ->

    *

      Create all directories that named expects to see:

# cd /etc/namedb
# mkdir -p bin dev etc var/tmp var/run master slave
# chown bind:bind slave var/*
    


      <http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html#CHOWN-SLAVE>
          named only needs write access to these directories, so that is
          all we give it.

Im not sure why the author assumes that named shouldn't write to the 
master directory.
In my case, DHCP can only update master zones (DHCP updates DNS within 
the LAN),
not slave zones, so master should be writeable by named.

What Im going to try is this.
Since the slave directory never seems to change permissions, I'll move the
LAN's zone files to the slave directory instead of the master directory.
And change named.conf ->
zone "trini0.org" {
        type master;
        file "slave/trini0.org";
        allow-update { key DHCP_UPDATER; };
};

zone "0.168.192.in-addr.arpa" {
        type master;
        file "slave/trini0.org.rev";
        allow-update { key DHCP_UPDATER; };
};

Kind of a contradiction if you're a stickler on the naming convention.

Hopefully if this *automatic* process doesn't recreate the directories 
at boot time,
this should work out.
I'll try this, and report any findings.

Thanks for replying.