Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 "" { type master; file "/var/lib/named/zones/"; };

Here is the zone specification on the slave:

zone "" { type slave; masters { master.ip; }; file "/var/lib/named/zones/"; };

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 no master file
27-Mar-2014 10:30:15.146 zone_settimer: zone enter
27-Mar-2014 10:30:15.157 dns_zone_maintenance: zone enter
27-Mar-2014 10:30:15.158 zone_settimer: zone enter
27-Mar-2014 10:30:15.166 zone_timer: zone enter
27-Mar-2014 10:30:15.166 zone_maintenance: zone enter
27-Mar-2014 10:30:15.166 queue_soa_query: zone enter
27-Mar-2014 10:30:15.166 zone_settimer: zone enter
27-Mar-2014 10:30:15.166 soa_query: zone enter
27-Mar-2014 10:30:15.170 refresh_callback: zone enter
27-Mar-2014 10:30:15.170 refresh_callback: zone serial: new 2014031901, old not loaded
27-Mar-2014 10:30:15.170 queue_xfrin: zone enter
27-Mar-2014 10:30:15.171 zone Transfer started.
27-Mar-2014 10:30:15.171 zone no database exists yet, requesting AXFR of initial version from x.x.x.x#53
27-Mar-2014 10:30:15.171 transfer of '' from x.x.x.x#53: connected using x.x.x.y#59644
27-Mar-2014 10:30:15.179 zone zone transfer finished: success
27-Mar-2014 10:30:15.179 zone transferred serial 2014031901
27-Mar-2014 10:30:15.179 zone_needdump: zone enter
27-Mar-2014 10:30:15.179 zone_settimer: zone enter
27-Mar-2014 10:30:15.179 zone_settimer: zone enter
27-Mar-2014 10:30:15.179 transfer of '' 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 enter
27-Mar-2014 10:30:15.180 zone_maintenance: zone enter
27-Mar-2014 10:30:15.180 zone sending notifies (serial 2014031901)
27-Mar-2014 10:30:15.186 zone_dump: zone enter
27-Mar-2014 10:30:15.186 zone_settimer: zone enter
27-Mar-2014 10:30:15.186 zone_gotwritehandle: zone enter
27-Mar-2014 10:30:15.186 decrement_reference: delete from rbt: 0x9a725d8
27-Mar-2014 10:30:15.187 dump_done: zone enter

And /var/lib/named/zones/ is created and populated on the slave:

-rw-r--r-- 1 named named 250 Mar 27 10:30

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 '': not authoritative

The 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 (
                        2014031902      ; serial, todays date + todays serial #
                        1H              ; refresh, seconds
                        2H              ; retry, seconds
                        2D              ; expire, seconds
                        1H )            ; minimum, seconds

                TXT     ""

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

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
up vote 1 down vote accepted


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 '14 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 '14 at 10:53
There! I wasn't aware of that problem Håkan. Thanks! – StianOvrevage Nov 11 '14 at 16:25

Your Answer


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.