Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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
share|improve this question
    
Shouldn't the slave domain go into the slaves/ directory? –  NickW Mar 27 at 10:14
    
Also, look into the allow-notify{} option. –  NickW Mar 27 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. –  StianOvrevage Mar 27 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... –  StianOvrevage Mar 27 at 10:27
    
Do the ns1 and ns2 entries correspond to the master and slave? –  NickW Mar 27 at 10:33

2 Answers 2

up vote 0 down vote accepted

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 ;-)

share|improve this answer
    
Wow, that's pretty nuts.. never would have guessed that :) –  NickW Mar 28 at 14:14
    
Please accept your answer so that the site stops trying to nudge us into answering the question. –  Håkan Lindqvist Nov 9 at 10:53
    
There! I wasn't aware of that problem Håkan. Thanks! –  StianOvrevage Nov 11 at 16:25

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.