Forwarders and cache

Kevin Darcy kcd at daimlerchrysler.com
Thu Jan 27 20:24:30 UTC 2000


jade.roberts at srs.gov wrote:

> I have a server set up with forwarders in a forward only mode.  Doesn't
> this mean that the only NS records that my cache should know about are the
> forwarders?  That doesn't seem to be the case.  My cache dump shows lots of
> NS records - a sample of which is shown below.  Can some one also explain
> the comments?  Thanks.
>
> cisco   155801  IN      NS      NS1.cisco.com.  ;Cr=addtnl
> home    151154  IN      NS      NS2.HOME.NET.   ;Cr=addtnl
> 1       41536   IN      NS      forwarders.doe.gov. ;Cr=auth
> 168     86400   IN      NS      internal.srs.gov.       ;Cl=4

When you are forwarding, the forwarders you use aren't given bogus NS records;
named just "knows" that it should forward to those servers first ("forward
first") or exclusively ("forward only"). I don't believe this forwarding
information is shown anywhere in the database dump.

You're getting NS records in your cache because the answers you're getting
back from the forwarder(s) have NS records in them, the same as if you had
queried iteratively; unlike an iterative server, however, you're just not
*using* those NS records to find other nameservers. You still cache those
records anyway, in case anyone sends you an explicit NS query for them.

"Cr" is BIND-shorthand for "Credibility", and "Cl" is BIND-shorthand for
"Credibility level". "Cr=addtnl" means the answer came from the additional
section of a response (which is a little puzzling, since one doesn't normally
see NS records in the additional section), "Cr=auth" means it came from the
authority section, "Cl=4" means it's authoritative data (presumably you are
primary or secondary for "srs.gov"). If you don't know what these sections are
or how they are used, trying reading RFC's 1034 & 1035. The reason for
tracking credibility levels for every database entry is so that when new data
comes in which matches existing data, the correct decision can be made whether
to discard it (if it's lower credibility), replace the existing data (because
the new data is more credible), and/or to simply "freshen" the TTL so that it
stays in cache longer. That's a bit of a simplification, but you get the
general idea.


- Kevin





More information about the bind-users mailing list