This is a discussion on Re: reverse lookups with dig for internal domains - DNS ; 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 ...
Mark Andrews wrote:
>>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
>>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 .
> 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 18.104.22.168.in-addr.arpa.
> If this bothers you use a slave / stub zone for
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...