Additional Section Cache Without Consulting Authoritative Data - Why?

Thu Jul 24 05:40:42 UTC 2008

Sabahattin Gucukoglu wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Kevin,
>
> On 23 Jul 2008 at 20:26, Kevin Darcy <kcd at chrysler.com> said:
>   
>> Sabahattin Gucukoglu wrote:
>>     
>>> How is this proper?  I observe Bind 9 doing it, and a quick rifle of RFC
>>> 1034-5 says that additional section data provided for crossing a zone cut
>>> is, without doubt, not authoritative.  
>>>       
>> RFC 2181 is the more modern reference, as far as "ranking data" is 
>> concerned. See Section 5.4.1 of that RFC.
>>     
>
> Cool!  Thanks.  But this only seems to confirm that the problem actually 
> exists, since the additional section is the most "Mistrusted" data 
> available for use according to that list and, indeed, the spirit of 
> Additional data in 1034-5.  And anyway, there's this smoking gun:
>
> |    Unauthenticated RRs received and cached from the least trustworthy of
> |    those groupings, that is data from the additional data section, and
> |    data from the authority section of a non-authoritative answer, should
> |    not be cached in such a way that they would ever be returned as
> |    answers to a received query.  They may be returned as additional
> |    information where appropriate.  Ignoring this would allow the
> |    trustworthiness of relatively untrustworthy data to be increased
> |    without cause or excuse.
>
> In other words, don't ever trust the additional data to actually be useful 
> for any purpose other than the very one for which it can not fail to be 
> used or useful: delegation.
>
> If I wrote a DNS server, I wouldn't even bother to cache it.  Why should 
> I?  It's only a bootstrap - it loses its usefullness as soon as I've got 
> what I want out of the next hop nameserver, which may well be the address 
> of that nameserver from that nameserver.  That's a result I *can* keep, 
> usefully.  Stuff the next-door neighbour - he can do as I did, unless I 
> happened to need that nameserver's address while recursing myself (I.E. 
> while actually needing the authoritative address of a host listed in the 
> NS records at a delegation or in response to an actual query I get), in 
> which case I'll be so good as to pass the information along in case he's 
> in the same situation.  Only then, though, as handing over stray data is 
> kind of defeating the non-caching role.  And if I am on a mission to 
> recurse for others, I care about trustworthy results, so I'll keep chasing 
> till I get what I want out of an authoritative server, including every 
> single authoritative response, just as though no glue were involved.
>
> Last but not least, though,
> host -v -t a bloodstone.sabahattin-gucukoglu.com
> against a BIND 9 cache that hasn't seen a query for Bloodstone in a bit 
> returns the result from the parent (in this case, the .com) zone rather 
> than the authoritative response.  That is to say, it actually violates the 
> above paragraph explicitly.  It isn't alone though, so I am probably 
> missing something pretty large in all this.
>
> Cheers,
> Sabahattin
>
> - -- 
> Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
> Address harvesters, snag this: feedme at yamta.org
> Phone: +44 20 88008915
> Mobile: +44 7986 053399
> http://sabahattin-gucukoglu.com/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8
> Comment: QDPGP - http://community.wow.net/grt/qdpgp.html
>
> iQA/AwUBSIgNXSNEOmEWtR2TEQIAQACfXDHaTjjGPun7LqvaYOUq2ezXqLcAoM1Z
> dRfNsXUAyQqFR3gq2XQLzGnS
> =rKF0
> -----END PGP SIGNATURE-----
>
>
>
>   
I'm showing otherwise. See sequences of queries below:

Query #1: proves that ns2.footprint.net is not in my local cache
Query #2: shows that the authoritative nameservers for .net are 
providing ns2.footprint.net glue records (among others) for the 
footprint.net delegation. The results of this query are *not* cached, 
since I asked an authoritative nameserver directly, bypassing my local 
resolver.
Query #3: I query ns1.footprint.net recursively. Based on #2 above, I 
know that the glue records for ns2.footprint.net must have been seen in 
the course of resolving this query
Query #4: Immediately afterwards, I query ns2.footprint.net 
non-recursively. It's still not in my cache.

So, BIND 9 is *seeing* the glue records, and using them for resolving 
the current query, but it's not providing them as answers to subsequent 
queries. They're not "cached" in any meaningful sense of the term. This 
appears to conform to the standards.

% dig ns2.footprint.net +norec

; <<>> DiG 9.3.0 <<>> ns2.footprint.net +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1956
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;ns2.footprint.net. IN A

;; AUTHORITY SECTION:
. 3600000 IN NS L.ROOT-SERVERS.net.
. 3600000 IN NS M.ROOT-SERVERS.net.
. 3600000 IN NS A.ROOT-SERVERS.net.
. 3600000 IN NS B.ROOT-SERVERS.net.
. 3600000 IN NS C.ROOT-SERVERS.net.
. 3600000 IN NS D.ROOT-SERVERS.net.
. 3600000 IN NS E.ROOT-SERVERS.net.
. 3600000 IN NS F.ROOT-SERVERS.net.
. 3600000 IN NS G.ROOT-SERVERS.net.
. 3600000 IN NS H.ROOT-SERVERS.net.
. 3600000 IN NS I.ROOT-SERVERS.net.
. 3600000 IN NS J.ROOT-SERVERS.net.
. 3600000 IN NS K.ROOT-SERVERS.net.

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 24 01:33:33 2008
;; MSG SIZE rcvd: 243

% dig footprint.net ns +norec @h.gtld-servers.net

; <<>> DiG 9.3.0 <<>> footprint.net ns +norec @h.gtld-servers.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1504
;; flags: qr; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 8

;; QUESTION SECTION:
;footprint.net. IN NS

;; ANSWER SECTION:
footprint.net. 172800 IN NS ns1.footprint.net.
footprint.net. 172800 IN NS ns2.footprint.net.
footprint.net. 172800 IN NS ns3.footprint.net.
footprint.net. 172800 IN NS ns4.footprint.net.
footprint.net. 172800 IN NS ns6.footprint.net.
footprint.net. 172800 IN NS ns7.footprint.net.
footprint.net. 172800 IN NS ns8.footprint.net.
footprint.net. 172800 IN NS ns9.footprint.net.

;; ADDITIONAL SECTION:
ns1.footprint.net. 172800 IN A 63.208.138.37
ns2.footprint.net. 172800 IN A 64.152.81.68
ns3.footprint.net. 172800 IN A 63.208.138.37
ns4.footprint.net. 172800 IN A 67.72.120.47
ns6.footprint.net. 172800 IN A 210.8.213.38
ns7.footprint.net. 172800 IN A 63.209.70.231
ns8.footprint.net. 172800 IN A 212.187.253.68
ns9.footprint.net. 172800 IN A 212.162.1.100

;; Query time: 122 msec
;; SERVER: 192.54.112.30#53(h.gtld-servers.net)
;; WHEN: Thu Jul 24 01:33:47 2008
;; MSG SIZE rcvd: 303

% dig ns1.footprint.net

; <<>> DiG 9.3.0 <<>> ns1.footprint.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1990
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 7

;; QUESTION SECTION:
;ns1.footprint.net. IN A

;; ANSWER SECTION:
ns1.footprint.net. 171867 IN A 63.208.138.37

;; AUTHORITY SECTION:
footprint.net. 171867 IN NS ns9.footprint.net.
footprint.net. 171867 IN NS ns1.footprint.net.
footprint.net. 171867 IN NS ns2.footprint.net.
footprint.net. 171867 IN NS ns3.footprint.net.
footprint.net. 171867 IN NS ns4.footprint.net.
footprint.net. 171867 IN NS ns6.footprint.net.
footprint.net. 171867 IN NS ns7.footprint.net.
footprint.net. 171867 IN NS ns8.footprint.net.

;; ADDITIONAL SECTION:
ns2.footprint.net. 171867 IN A 64.152.81.68
ns3.footprint.net. 171867 IN A 63.208.138.37
ns4.footprint.net. 171867 IN A 67.72.120.47
ns6.footprint.net. 171867 IN A 210.8.213.38
ns7.footprint.net. 171867 IN A 63.209.70.231
ns8.footprint.net. 171867 IN A 212.187.253.68
ns9.footprint.net. 171867 IN A 212.162.1.100

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 24 01:33:54 2008
;; MSG SIZE rcvd: 303

% dig ns2.footprint.net +norec

; <<>> DiG 9.3.0 <<>> ns2.footprint.net +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 315
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;ns2.footprint.net. IN A

;; AUTHORITY SECTION:
. 3600000 IN NS H.ROOT-SERVERS.net.
. 3600000 IN NS I.ROOT-SERVERS.net.
. 3600000 IN NS J.ROOT-SERVERS.net.
. 3600000 IN NS K.ROOT-SERVERS.net.
. 3600000 IN NS L.ROOT-SERVERS.net.
. 3600000 IN NS M.ROOT-SERVERS.net.
. 3600000 IN NS A.ROOT-SERVERS.net.
. 3600000 IN NS B.ROOT-SERVERS.net.
. 3600000 IN NS C.ROOT-SERVERS.net.
. 3600000 IN NS D.ROOT-SERVERS.net.
. 3600000 IN NS E.ROOT-SERVERS.net.
. 3600000 IN NS F.ROOT-SERVERS.net.
. 3600000 IN NS G.ROOT-SERVERS.net.

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 24 01:33:59 2008
;; MSG SIZE rcvd: 243

%

- Kevin