Hello, I am having a bit of trouble understanding what happens when, in this instance, a DNS reverse lookup occurs. Our site has the class-C 141.163.0.0 address range. If I perform reverse lookups from inside or outside our site, then they seem to work fine. However, we are currently investigating a problem an external site has with reverse lookups of our IP addresses.
If I run (externally): dig 141.in-addr.arpa ns then 6 NS records are returned. If I query any one of those using: dig +norecurse 163.141.in-addr.arpa ns @tinnie.arin.net (using 'tinnie' in this example) then I get our 4 NS records relating to our local and remote name servers: ============== ;; AUTHORITY SECTION: 163.141.in-addr.arpa. 172800 IN NS dns2.cis.strath.ac.uk. 163.141.in-addr.arpa. 172800 IN NS dns1.cis.strath.ac.uk. 163.141.in-addr.arpa. 172800 IN NS dns1.plymouth.ac.uk. 163.141.in-addr.arpa. 172800 IN NS dns0.plymouth.ac.uk. ============== There is no ANSWER section, but a referral to the servers listed in the AUTHORITY section. So, I assume that at this point the name server used by a resolver will now cache those NS records. As such, any subsequent reverse lookup for a 141.163.x.x address should use one of the above cached name servers and get an answer. If, however, you run a general query for the NS records: dig 163.141.in-addr.arpa ns then you will get an ANSWER section which lists several of our 'ils' servers: ============== ;; ANSWER SECTION: 163.141.in-addr.arpa. 3600 IN NS ils022.uopnet.plymouth.ac.uk. 163.141.in-addr.arpa. 3600 IN NS ils001.uopnet.plymouth.ac.uk. 163.141.in-addr.arpa. 3600 IN NS ils009.uopnet.plymouth.ac.uk. (etc) ============== The problem is that all these servers are internal to our site. They cannot be directly queried externally (you get a timeout). The external site (after flushing the cache) performs a reverse lookup and receives an answer. So working from the root down works. However, any subsequent reverse lookup of our IP address range has their resolver looking at the 'ils' servers mentioned above and not the local and remote name servers (dns0, dns1 etc) seen in the reply from 'tinnie'. So I think my question is what is the resolver doing? Does it use cached NS records seen in the AUTHORITY section, or does it use NS records seen in an ANSWER section? Or is it working its way down until it receives an authoritative answer ('aa' flag set), and then query one of those name servers? The 'aa' flag is only set if a query for the 163.141.in-addr.arpa NS records is directed to one of our local/remote name servers listed in the AUTHORITY by 'trinnie'. It will list the 'ils' servers mentioned above. However, the question then is how come our reverse lookups work at all - they do for me from home. If the resolver was looking for an authoritative answer, and they are only provided by our internal servers, then all the lookups should fail. Comments? Corrections to where I have gone wrong? I should point out that I have for a long time banged on at management about the fact that our internal name servers are visible on the Internet but cannot be accessed. This is bound to lead to problems. Does anyone listen though...? John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287 Fax: +44 (0)1752 587001 _______________________________________________ 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