BIND9 recursion on slave servers for a delegated zone - not working

Question

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

ns.pr.example.com == primary nameserver, 10.10.0.1, 192.168.0.1

ns1.pr.example.com == secondary nameserver, 10.11.0.1, 192.168.0.2

ns2.pr.example.com == secondary nameserver, 10.11.0.2, 192.168.0.3

delegated.pr.example.com == delegated sub-zone

nsdelegated.pr.example.com == authoratative NS for

delegated.pr.example.com sub-domain, 10.11.0.5 NOT under our control!

You'll notice that ns1 and ns2 can talk to ns.pr.example.com over an shared network - 192.168.0.0/24. However, ns.pr.example.com cannot talk to the nsdelegated.pr.example.com host, which only has a 10.11.0.0/24 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 ns.pr.example.com to the 10.11 network, either directly or through a static route, is out of the question.

On the primary nameserver, ns.pr.example.com, the following defition is added to the zone file, along with an updated serial:

/etc/named.conf:

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

db.filename:

delegated.pr.example.com. IN NS nsdelegated.pr.example.com. nsdelegated.pr.example.com. IN A 10.11.0.5 ; 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 delegated.pr.example.com nsdelegated.pr.example.com IN A 10.11.0.5

master example

dig -t ns +short @ns delegated.pr.example.com nsdelegated.pr.example.com IN A 10.11.0.5

The nsdelegated server itself is responsive:

dig -t a +short @nsdelegated.pr.example.com randomhost.delegated.pr.example.com 10.11.0.222

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

dig +recurse +short -t a @ns1 randomhost.delegated.pr.example.com [no output]

It also fails on the primary server, ns, but that would be expected since there is no way for ns.pr.example.com to contact 10.11.0.5 and answer the request. Non-recursive queries also fail, since the relevant information must be fetched from the nsdelegated.pr.example.com 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.

Thanks.

Solution

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 pr.example.com 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 "delegated.pr.example.com." { type master; file [db.filename]; };

and the zone file should be:

delegated.pr.example.com. NS nsdelegated.pr.example.com. 
nsdelegated.pr.example.com. IN A 10.11.0.5 ; 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 ps.example.com but it is in the zone definition of delegated.pr.example.com. Fixed that.

Comments

[Admin]

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 pr.example.com zone file, we have the NS delegation record set and the glue record: delegated.pr.example.com. IN NS nsdelegated.pr.example.com. nsdelegated.pr.example.com. IN A 10.11.0.5 But there is ALSO in the named.conf: zone "delegated.pr.example.com" { type forward; forwarders { 10.11.0.5; } Why do I need both? All docs indicate to me that one, or the other, should be sufficient.

[Waqar Janjua]

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.

[Arkanox]

Okay, so we need to define our own SOA for the sub-domain. Why wouldn't that be in the nameserver for the subdomain, delegated.pr.example.com.?

[Arkanox]

Also, do you have a reference to BIND/DNS RFC documentation where this is clearly spelled out? Looking at zytrax.com/books/dns/ch9/delegate.html ( 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.

[Arkanox]

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.