Additional Section Cache Without Consulting Authoritative Data - Why?

[Sabahattin Gucukoglu]

-----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-----