Resolving RFC1918 addresses on recursive, caching servers

[Oscar Ricardo Silva]

Some clarification:


authoritative servers for all our in-addr.arpa domains and utexas.edu:

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




Some in-addr.arpa zones delegated to ns1.dept.utexas.edu on above 
authoritative servers:

	5.16.172.in-addr.arpa (172.16.5.0/24)
	128-25.6.17.172.in-addr.arpa (172.17.6.128/25)
	64-27.7.17.172.in-addr.arpa (172.17.7.164/27)



Recursive caching server:  ns1.utexas.edu



When one of the authoritative servers failed, the recursive caching 
server could not resolve PTR records for the delegated networks. As 
mentioned in my initial message there were no problems with the name 
servers to which those zones were delegated.


Oscar



On 11/09/2017 04:19 PM, Oscar Ricardo Silva wrote:
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users