Resolving RFC1918 addresses on recursive, caching servers

[Oscar Ricardo Silva]

We use RFC1918 networks and have our authoritative servers configured to 
resolve for those networks. Some of these RFC1918 networks are delegated 
to departmental name servers.

This has been running well (or apparently well) for several years but a 
few weeks ago one of our authoritative name servers (chisos - see below) 
died and our recursive, caching servers could not resolve PTR records 
for delegated RFC1918 networks. There were no problems with the name 
servers in the delegations. On the surface (unless I'm missing something 
obvious which is possible), there should have been no failures as the 
second authoritative name server was still up.



authoritative servers:

- chisos.ots.utexas.edu (128.83.185.39)
- glass.its.utexas.edu  (129.116.136.5)




Configuration on recursive, caching name servers:

zone 16.172.in-addr.arpa IN {
	type forward;
	forward first;
	forwarders { 128.83.185.39; 129.116.136.5; };
};

zone 17.172.in-addr.arpa IN {
	type forward;
	forward first;
	forwarders { 128.83.185.39; 129.116.136.5; };
};

....

zone 30.172.in-addr.arpa IN {
	type forward;
	forward first;
	forwarders { 128.83.185.39; 129.116.136.5; };
};



That *SHOULD* be it. A client queries one of the recursive servers for 
172.17.5.250 and it should then query the two authoritative servers and 
iterate from there and if one is down then it should still get an answer 
from the other. Am I missing something obvious? The issue is not with 
resolving these addresses as "empty-zones-enable" is set to no.


Or (as I just read about 1 minute ago) do I *ALSO* need to add:

	disable-empty-zone "16.172.in-addr.arpa";
	disable-empty-zone "17.172.in-addr.arpa";
	...
	disable-empty-zone "30.172.in-addr.arpa";





Oscar