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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
