# BIND Zone Files Not Loading and Failed Transfers



## mbr661 (Dec 31, 2010)

Hello Friends, any help on this issue will be appreciated.

BIND 9.8.0a1
DHCP Server 4.1.2
FreeBSD 7.3-RELEASE-p2, with GENERIC  i386

I'm trying to get BIND and DHCP to work on FreeBSD to serve a small Windows Workgroup, but I cannot quite figure it out. They seem to be working because I can ping all the machines by name, even the ones newly added. But I'm still facing these two issues:

When I try to transfer my domain, the transfer fails, and when I restart named, the zone files won't load: file not found.

When I try to "dig" my domain I get the following:


```
# dig beltrandelrio.net axfr
; <<>> DiG 9.8.0a1 <<>> beltrandelrio.net axfr
;; global options: +cmd
; Transfer failed.
```

Furthermore the logs give me this after restarting named:


```
Dec 30 12:16:21 tuffy named[4617]: starting BIND 9.8.0a1 -t /var/named -u bind
Dec 30 12:16:21 tuffy named[4617]: built with '--localstatedir=/var' '--disable-linux-caps' '--disable-symtable' '--with-randomdev=/dev/random' 
'--with-opens
Dec 30 12:16:21 tuffy named[4617]: command channel listening on 127.0.0.1#953
Dec 30 12:16:21 tuffy named[4617]: command channel listening on ::1#953
Dec 30 12:16:22 tuffy named[4617]: zone 75.168.192.in-addr.arpa/IN: loading from master file 
/var/named/etc/namedb/dynamic/beltrandelrio.net.rev failed: file
Dec 30 12:16:22 tuffy named[4617]: zone 75.168.192.in-addr.arpa/IN: not loaded due to errors.
Dec 30 12:16:22 tuffy named[4617]: zone beltrandelrio.net/IN: loading from master file /var/named/etc/namedb/dynamic/beltrandelrio.net failed: 
file not found
Dec 30 12:16:22 tuffy named[4617]: zone beltrandelrio.net/IN: not loaded due to errors.
Dec 30 12:16:22 tuffy named[4617]: managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found
Dec 30 12:16:22 tuffy named[4617]: running
Dec 30 12:16:56 tuffy dhcpd: Unable to add forward map from test.beltrandelrio.net to 192.168.75.9: timed out
Dec 30 12:18:50 tuffy dhcpd: Unable to add forward map from bel-laptop01.beltrandelrio.net to 192.168.75.11: timed out
Dec 30 12:21:15 tuffy dhcpd: Unable to add forward map from bel-desktop02.beltrandelrio.net to 192.168.75.10: timed out
```

My config files are as follows:


```
#named.conf
options {
        // All file and path names are relative to the chroot directory,
        // if any, and should be fully qualified.
        directory       "/etc/namedb/working";
        pid-file        "/var/run/named/pid";
        dump-file       "/var/dump/named_dump.db";
        statistics-file "/var/stats/named.stats";

		listen-on       { 127.0.0.1; 192.168.75.105; };

        
        forwarders {
                68.94.156.1;68.94.157.1;
        };
        
        zone "beltrandelrio.net" {
    type master;
    file "dynamic/beltrandelrio.net";
    allow-transfer { localhost; };
    allow-update { key rndc-key; };
};

zone "75.168.192.in-addr.arpa" {
    type master;
    file "dynamic/beltrandelrio.net.rev";
    allow-transfer { localhost; };
    allow-update { key rndc-key; };
};
key "rndc-key" {
        algorithm hmac-md5;
        secret "ytlyIvvgnwRF8HUUpuYV3w==";
};
```

Zone files:

```
$TTL    3600

beltrandelrio.net.   IN    SOA   tuffy.beltrandelrio.net.    root.beltrandelrio.net. (

                                        1       ;       Serial
                                        10800   ;       Refresh
                                        3600    ;       Retry
                                        604800  ;       Expire
                                        86400 ) ;       Minimum TTL
;DNS Servers
beltrandelrio.net.         IN      NS              tuffy.beltrandelrio.net.

;Machine Names
bel-ser04.beltrandelrio.net.    IN      A               192.168.75.104
bel-ser06.beltrandelrio.net.    IN      A               192.168.75.106

;Aliases
bel-ser04                  IN      CNAME           bel-ser04.beltrandelrio.net.
bel-ser06                  IN      CNAME           bel-ser06.beltrandelrio.net.

;MX Record
```


```
$TTL    3600

75.168.192.in-addr.arpa. IN  SOA tuffy.beltrandelrio.net.  root.beltrandelrio.net.   (

                                1       ;       Serial
                                10800   ;       Refresh
                                3600    ;       Retry
                                604800  ;       Expire
                                86400 ) ;       Minimum TTL
;DNS Servers
75.168.192.in-addr.arpa.   IN      NS              tuffy.beltrandelrio.net.

;Machine IPs
104                        IN      PTR             bel-ser04.beltrandelrio.net.
106                        IN      PTR             bel-ser06.beltrandelrio.net.
```


```
# dhcpd.conf
option domain-name "beltrandelrio.net";
option domain-name-servers 192.168.75.105;

default-lease-time 600;
max-lease-time 7200;

ddns-update-style interim;

authoritative;

log-facility local7;

subnet 192.168.75.0 netmask 255.255.255.0 {
  range 192.168.75.2 192.168.75.100;
  option routers 192.168.75.150;
}

host bel-ser50.beltrandelrio.net {
  hardware ethernet 00:18:f8:48:21:a5;
  fixed-address 192.168.75.150;}
  
key "rndc-key" {
        algorithm hmac-md5;
        secret "ytlyIvvgnwRF8HUUpuYV3w==";
};

zone beltrandelrio.net. {
     primary 192.168.75.105;
     key rndc-key;
}
zone 75.168.192.in-addr.arpa. {
     primary 192.168.75.105;
     key rndc-key;
}

update-static-leases on;
```

User bind is the owner and has read/write permissions on the following directories:

/var/named/etc/namedb/dynamic
/var/named/etc/namedb/slave
/var/named/etc/namedb/working


----------



## SirDice (Dec 31, 2010)

It looks like it has some problems chroot'ing. Make sure the files in /var/named/etc/named/ are hardlinks to the files in /etc/named/


----------



## mbr661 (Jan 3, 2011)

Hello, SirDice, thanks for your reply.

I'm not sure but I think the files in /var/named/etc/named/ are hardlinks to the files in /etc/named/. Here is what I get with ls -i, files in both directories reference the same inode locations:


```
tuffy# ls -i /etc/namedb/ /var/named/etc/namedb/
/etc/namedb/:
164875 dynamic          164879 named.conf       164880 named.root       164887 rndc.key         164878 working
164876 master           164888 named.conf.old   164886 rndc.conf.sample 164877 slave

/var/named/etc/namedb/:
164875 dynamic          164879 named.conf       164880 named.root       164887 rndc.key         164878 working
164876 master           164888 named.conf.old   164886 rndc.conf.sample 164877 slave
```

Is there another way to know for sure the second directory is a hard link of the first one?


----------



## SirDice (Jan 3, 2011)

If the inodes are the same you can be sure they're hardlinks.


----------



## quintessence (Jan 3, 2011)

Hello,

You should probably replace

```
zone "75.168.192.in-addr.arpa" {
    type master;
    file "dynamic/beltrandelrio.net.rev";
    allow-transfer { localhost; };
    allow-update { key rndc-key; };
};
```

with

```
zone "75.168.192.in-addr.arpa" {
    type master;
    file "/etc/namedb/dynamic/beltrandelrio.net.rev";
    allow-transfer { localhost; };
    allow-update { key rndc-key; };
};
```

and check it then
`# named-checkconf -t /var/named -z`


----------



## mbr661 (Jan 4, 2011)

Hello Quintessence and thanks a bunch, your advice fixed the issue and now my logs are clean.


```
tuffy# named-checkconf -t /var/named -z
zone beltrandelrio.net/IN: loaded serial 6
zone 75.168.192.in-addr.arpa/IN: loaded serial 6
```

If I may ask, why did it work with /etc/namedb directory and not with /var/named/etc/namedb/, even though both reference the same files?


----------



## SirDice (Jan 4, 2011)

Once bind has been chroot'ed the directory /var/named/etc/namedb/ doesn't exist.


----------



## quintessence (Jan 4, 2011)

Hello,

Because this is default behaviour when you chrooting ( i.e non-FreeBSD specific ). Do not forget your BIND is installed from ports, not default which is in base.

Your chroot in under /var/named, so the correct way to specify directory is like the line with pid file - you do not put /var/named/var/run/... but only /var/run because the service is already chrooted.

I can give you example with OpenBSD bind in base, which operates by usual chroot behaviour:


```
zone "11.11.10.in-addr.arpa" {
        type master;
        file "master/11.11.10.in-addr.arpa.zone";
        allow-query { any; };
};
```
or 
	
	



```
zone "11.11.10.in-addr.arpa" {
        type master;
        file "/master/11.11.10.in-addr.arpa.zone";
        allow-query { any; };
};
```
BUT the structure is as follows : 
/var/named/master, /var/named/slave and bind is also chrooted in /var/named


----------

