5

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
16
  • Shouldn't the slave domain go into the slaves/ directory?
    – NickW
    Mar 27, 2014 at 10:14
  • Also, look into the allow-notify{} option.
    – NickW
    Mar 27, 2014 at 10:20
  • I'm using full paths to the zone files so locations do not matter. Also note that it is working on the 150 other zones set up previously. Mar 27, 2014 at 10:25
  • @NickW 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... Mar 27, 2014 at 10:27
  • Do the ns1 and ns2 entries correspond to the master and slave?
    – NickW
    Mar 27, 2014 at 10:33

2 Answers 2

3

For the benefit of anyone else having this problem and ending up here from Google, for me the problem was caused by my use of BIND views.

I had configured multiple views, assuming BIND would combine all matching views into one, but actually it picks the first matching view and uses only that one, ignoring all others. Consequently the client was only seeing a small section of my zones, and so those missing from the view were coming up as non-authoritative.

My problem was fixed by sticking everything into include files and using those to ensure each view was fully complete on its own.

1

Solved:

There were two instances of bind running on the server! One seemingly orphaned which continued serving requests (and thus refusing the zone it did not know of). And one which dutifully responded to rndc commands and logging all the right stuff in the same logfile as the other instance.

I picked this up when changing the listen directive to only localhost in order to filter out all the noise coming from clients in the logfile. However queries kept blasting the logfiles and then I double checked which ports and IPs were listening and indeed, there was multiple non-consistent entries.

I'm a bit disappointed that rndc reload let me continue talking to an in practice isolated process without even a warning that the named process was not bound to it's udp port due to conflict ;-)

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .