I am having problems with getting a zone loaded properly on a slave DNS server. Both servers are running BIND 9.9.3-P2.
I am already serving ~150 zones and they are all working properly. However when I am adding another domain the slave server is refusing to recognize it.
Here is the zone specification on the master:
zone "test.no" { type master; file "/var/lib/named/zones/test.zone"; };
Here is the zone specification on the slave:
zone "test.no" { type slave; masters { master.ip; }; file "/var/lib/named/zones/test.zone"; };
And when I do a rndc reload
on the master, the slave gets the notification, transfer the zone from the master and does not complain. This is from the logs on the slave:
27-Mar-2014 10:30:15.146 zone test.no/IN: no master file
27-Mar-2014 10:30:15.146 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.157 dns_zone_maintenance: zone test.no/IN: enter
27-Mar-2014 10:30:15.158 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 zone_timer: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 zone_maintenance: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 queue_soa_query: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 soa_query: zone test.no/IN: enter
27-Mar-2014 10:30:15.170 refresh_callback: zone test.no/IN: enter
27-Mar-2014 10:30:15.170 refresh_callback: zone test.no/IN: serial: new 2014031901, old not loaded
27-Mar-2014 10:30:15.170 queue_xfrin: zone test.no/IN: enter
27-Mar-2014 10:30:15.171 zone test.no/IN: Transfer started.
27-Mar-2014 10:30:15.171 zone test.no/IN: no database exists yet, requesting AXFR of initial version from x.x.x.x#53
27-Mar-2014 10:30:15.171 transfer of 'test.no/IN' from x.x.x.x#53: connected using x.x.x.y#59644
27-Mar-2014 10:30:15.179 zone test.no/IN: zone transfer finished: success
27-Mar-2014 10:30:15.179 zone test.no/IN: transferred serial 2014031901
27-Mar-2014 10:30:15.179 zone_needdump: zone test.no/IN: enter
27-Mar-2014 10:30:15.179 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.179 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.179 transfer of 'test.no/IN' from x.x.x.x#53: Transfer completed: 1 messages, 6 records, 197 bytes, 0.007 secs (28142 bytes/sec)
27-Mar-2014 10:30:15.180 zone_timer: zone test.no/IN: enter
27-Mar-2014 10:30:15.180 zone_maintenance: zone test.no/IN: enter
27-Mar-2014 10:30:15.180 zone test.no/IN: sending notifies (serial 2014031901)
27-Mar-2014 10:30:15.186 zone_dump: zone test.no/IN: enter
27-Mar-2014 10:30:15.186 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.186 zone_gotwritehandle: zone test.no/IN: enter
27-Mar-2014 10:30:15.186 decrement_reference: delete from rbt: 0x9a725d8 test.no
27-Mar-2014 10:30:15.187 dump_done: zone test.no/IN: enter
And /var/lib/named/zones/test.zone
is created and populated on the slave:
-rw-r--r-- 1 named named 250 Mar 27 10:30 test.zone
All well and good! However, after I increase the serial on the master and do another reload I get the same damn error:
27-Mar-2014 10:30:51.405 client x.x.x.x#42033: received notify for zone 'test.no': not authoritative
The test.no
zone is the second zone I'm trying with the same error and the config has the same syntax as the rest of the working zones.
The actual zone-file as it appears on the master:
$TTL 1h0m6s
@ IN SOA ns1.domain.no. postmaster.domain.no. (
2014031902 ; serial, todays date + todays serial #
1H ; refresh, seconds
2H ; retry, seconds
2D ; expire, seconds
1H ) ; minimum, seconds
NS ns1.domain.no.
NS ns2.domain.no.
TXT "test.no"
test A 10.0.0.1
slaves/
directory?allow-notify{}
option.allow-notify{}
is not needed since the listed masters are allowed by default to notify:allow-notify applies to slave zones only and defines a match list, for example, IP address(es) that are allowed to NOTIFY this server and implicitly update the zone in addition to those hosts defined in the masters option for the zone. The default behaviour is to allow zone updates only from the masters IP(s).
I would also think that such an error would have prevented the rest of the zones from working as well...