Stranging Caching

[Kevin Darcy]

dbotham at edeltacom.com wrote:

> All,
>
> Looking at the dig results below, I wonder why two consecutive queries to
> the same name server resulted in two different replies.  Here is the
> background:
>
> Versions:
> ns1.isp-host.com BIND 9.2.1
> ns2.isp-host.com BIND ?
> 172.17.76.2  BIND 8.2.3 (checkpoint metaIP server)
>
> Contents of /etc/resolv.conf on ns1:
> nameserver 172.17.76.2
>
> Time Line:
> 172.17.76.2 answered a query for "domain.com" at 08:33 and (I assume)
> cached the response as->
> domain.com.      IN      A       192.168.45.4
>
> At 08:35 the A RR for domain.com was changed to->
> domain.com.      IN      A       192.168.45.6
>
> The digs below were performed at the times shown.
>
> It looks like the first dig asked for something that 172.17.76.2 did
> not have in its cache (www.domain.com), so, it got the answer from an
> authorative name server (ns1.isp-host.com or ns2.isp-host.com).  It looks
> like
> 172.17.76.2 also "passed" along the A RR for "domain.com" from the
> authoratative
> name server even though it was already in its cache.
>
> Why do I think the A RR for domain.com was already in the cache of
> 172.17.76.2?
> The second query was for www.domain.com, yet this time that was in cache
> and
> (I think) the A RR for domain.com was too.  Hence the second query required
> no
> contact with an authoratative name server and therefore resulted in both
> answers coming from cache.
>
> Is this normal?  Why didn't 172.17.76.2 update its cache during the first
> query?
>
> [root at ns1 # dig www.domain.com
>
> ; <<>> DiG 9.2.1 <<>> www.domain.com
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50882
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
>
> ;; QUESTION SECTION:
> ;www.domain.com.         IN      A
>
> ;; ANSWER SECTION:
> www.domain.com.  3600    IN      CNAME   domain.com.
> domain.com.      3600    IN      A       192.168.45.6
>
> ;; AUTHORITY SECTION:
> domain.com.      3600    IN      NS      ns1.isp-host.com.
> domain.com.      3600    IN      NS      ns2.isp-host.com.
>
> ;; ADDITIONAL SECTION:
> ns2.isp-host.com.      15397   IN      A       192.168.2.40
>
> ;; Query time: 26 msec
> ;; SERVER: 172.17.76.2#53(172.17.76.2)
> ;; WHEN: Mon Jul  8 08:50:18 2002
> ;; MSG SIZE  rcvd: 142
>
> [root at ns1 ]# hostname
> ns1
> [root at ns1 ]# dig www.domain.com
>
> ; <<>> DiG 9.2.1 <<>> www.domain.com
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20004
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
>
> ;; QUESTION SECTION:
> ;www.domain.com.         IN      A
>
> ;; ANSWER SECTION:
> www.domain.com.  3562    IN      CNAME   domain.com.
> domain.com.      2570    IN      A       192.168.45.4
>
> ;; AUTHORITY SECTION:
> domain.com.      2570    IN      NS      ns1.isp-host.com.
> domain.com.      2570    IN      NS      ns2.isp-host.com.
>
> ;; ADDITIONAL SECTION:
> ns1.isp-host.com.     171770  IN      A       10.150.18.10
> ns2.isp-host.com.      20533   IN      A       192.168.2.40
>
> ;; Query time: 8 msec
> ;; SERVER: 172.17.76.2#53(172.17.76.2)
> ;; WHEN: Mon Jul  8 08:50:56 2002
> ;; MSG SIZE  rcvd: 158

My guess is that the pre-existing cache entry was not overlaid, because it was
considered more "credible" (see RFC 2181's data-ranking rules) than the RR in
the response which it simply passed through from the authoritative server.
This could happen if the A record came directly -- and not in connection with
an alias -- from an authoritative server. When you queried again, it gave you
the "credible" A record instead of the one you previously saw.

Note that BIND 9 doesn't blindly "pass through" responses any more. So it is
more faithful to RFC 2181 and doesn't produce quirky behavior like the above.


- Kevin