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've been reviewing BIND/DNS documenatation and I've been unable to find a clear answer. tl;dr - querying a secondary nameserver for a delegated zone A record does not work with recusion enabled. And, by defition, doesn't work with recursion disabled either, since all that is defined in the zone from our point of view is the NS and glue record.

Software stack: bind-9.3.6-4 on CentOS 5.4 x86 for the secondary nameserver; bind-9.2.4-30 on Centos 4.7 x86 for the primary nameserver.

I will use master and primary, slave and secondary, as synonyms, respectively.

Our setup is as follows ( names/IPs changed to protect the innocent ): == primary nameserver,, == secondary nameserver,, == secondary nameserver,, == delegated sub-zone == authoratative NS for sub-domain, NOT under our control!

You'll notice that ns1 and ns2 can talk to over an shared network - However, cannot talk to the host, which only has a address.

The 192.168 network is a stand-in for our public-IP space; but the 10.10 and 10.11 networks are private, closed networks used for cluster computing. Connecting to the 10.11 network, either directly or through a static route, is out of the question.

On the primary nameserver,, the following defition is added to the zone file, along with an updated serial:


zone "" { type master; file [db.filename]; };

db.filename: IN NS IN A ; glue record

This is replicated to the slave servers, ns1 and ns2. The record can be seen, both in the flat files, and confirmed with dig:

slave example

dig -t ns +short @ns1 IN A

master example

dig -t ns +short @ns IN A

The nsdelegated server itself is responsive:

dig -t a +short

But, a lookup on the secondary nameserver with the recursion-desired bit set ( the default ) fails.

dig +recurse +short -t a @ns1 [no output]

It also fails on the primary server, ns, but that would be expected since there is no way for to contact and answer the request. Non-recursive queries also fail, since the relevant information must be fetched from the server.

My question is: why are the recursive questions to the secondary nameservers failing? They have the correct delegation information, an NS record and a glue record, and they are able to contact the delegated nameserver.

My hunch is that, as a secondary nameserver, it may somehow be 'passing on' the recursive question to the primary nameserver, where it then fails. But I can't find any documentation to this effect, and it doesn't make intuitive sense.

Any ideas, or debugging suggestions? I turned on maximal logging for named, as well as query logging, but I couldn't get good information. There wasn't an obvious "show me the lookups you do on behalf of clients" log.


share|improve this question
Update - the issue is "solved", but I'd still like an answer as to why it is so. I'm unable to reconcile how our configuration works with how it should work, based on documentation. In the zone file, we have the NS delegation record set and the glue record: IN NS IN A But there is ALSO in the named.conf: zone "" { type forward; forwarders {; } Why do I need both? All docs indicate to me that one, or the other, should be sufficient. – user56421 Oct 7 '10 at 20:07
up vote 0 down vote accepted

Of course you need to specify the delegated zone in named.conf, otherwise bind will think it is just a dotted record it should have, since it is authoritative for the zone.

What you want is something like this. In the master named.conf you specify a new zone (and accordingly a new zone in the slaves):

zone "" { type master; file [db.filename]; };

and the zone file should be: NS IN A ; glue record 

Now the main DNS server and its slaves know about the new zone and things should work.

==== EDIT

Mistake, the SOA record is not in but it is in the zone definition of Fixed that.

share|improve this answer
Okay, so we need to define our own SOA for the sub-domain. Why wouldn't that be in the nameserver for the subdomain, – user56421 Oct 8 '10 at 15:50
Also, do you have a reference to BIND/DNS RFC documentation where this is clearly spelled out? Looking at ( which seems to be quoting Pro DNS & BIND, by Apress ) it says that the above domain zone file needs only the IN NS and glue record. Not a separate SOA/zone on the master server. – user56421 Oct 8 '10 at 15:53
From your description it seems to me that you did not create a zone, but just added NS records. And when you did, you create a forward zone. You are right you not need the SOA record on the server, but you have the define the new zone in BIND the way I have showed you. – Dan Andreatta Oct 8 '10 at 20:07
Accepted the answer. I think the issue was that most online documentation skips over the need for a separate zone file: we were adding the NS/glue record into the same zone file as the domain above it. – user56421 Oct 12 '10 at 18:27

Do you have 'recusrsion no;' in your named.conf. If you don't have a dual zone configuration you should have it. However, it will prevent bind from answering recursive queries for you.

I expect you may want to configure dual zone with recursion allowed from your LAN but not from the Internet.

share|improve this answer
No, recursion is explicitly allowed for the 10.10 and 10.11 networks. I was also able to reproduce the 'solution' by setting recursion: no; in ns1 and ns2 - but this of course then broke all the other DNS requests they received. – user56421 Oct 7 '10 at 17:00

Your Answer


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