reverse lookups with dig for internal domains

[Kevin Darcy]

Mark Andrews wrote:

>>Hi all 
>>
>>I have been scratching my head for the past two - three days to come
>>to terms with  an inexplicable (atleast it seems so to to me ) 
>>behaviour of dig. Let me explain it ..
>>
>>We have an  internal domain in the private ip space , which cannot be
>>looked up from external world. When I do a dig -x <ip> from our
>>internal name server
>>
>> say dig -x 10.1.1.1 
>>
>>gives the host name right 
>>
>>but the authority section is from the root zone 
>>----------- 
>>;; AUTHORITY SECTION:
>>10.in-addr.arpa.        9h6m59s IN NS   BLACKHOLE-1.IANA.ORG.
>>10.in-addr.arpa.        9h6m59s IN NS   BLACKHOLE-2.IANA.ORG 
>> 
>>------------
>>
>>When I follow that up with a qury like 
>>
>> dig ns 1.1.10.in-addr.arpa 
>>
>>I get the name servers right ( that of our internal domain ) 
>>
>>and now when I  try to reverse lookup any ip in the internal domain
>>the authority section of the answer is coming out absolutely right 
>>ever after .
>>
>>thoughts/comments ? 
>>Sai.
>>
>>    
>>
>
>	You made a reverse lookup for a 10.x.x.x address not in
>	10.1.1.x ~6.5 days ago and the cache has the NS records
>	for 10.in-addr.arpa as a result.
>
>	The NS records for 1.1.10.in-addr.arpa have timed out and
>	you still have the PTR record for 1.1.1.10.in-addr.arpa.
>
>	If this bothers you use a slave / stub zone for
>	1.1.10.in-addr.arpa.
>
Or, even better, set up 10.in-addr.arpa on your servers so that reverse 
lookups for _mistyped_ 10.*.*.* addresses are contained within your 
network instead of bugging the poor iana.org nameservers...

                                                                         
                                             - Kevin