Answers from cache or authority section?

John Horne john.horne at plymouth.ac.uk
Tue Jun 25 14:32:59 UTC 2013


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



More information about the bind-users mailing list