Additional Section Cache Without Consulting Authoritative Data - Why?

[Kevin Darcy]

Sabahattin Gucukoglu wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> 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.
> So why is a recursive resolver 
> happy to give out an answer that isn't authoritative without so much as a 
> check against the authoritative host(s)?  It's true that a check can have 
> only minimal security benefit, since any data provided is the only source 
> available for pursuing referrals and that data must be considered 
> malicious, but it doesn't seem right.  For example, from no data in a 
> cache, I want the IPv4 address of
> bloodstone.sabahattin-gucukoglu.com:
>
> Ask . ns about bloodstone.sabahattin-gucukoglu.com, refer .com ns.
> Ask .com ns about bloodstone.sabahattin-gucukoglu.com, refer 
> bloodstone.sabahattin-gucukoglu.com ...
> ... and bloodstone.sabahattin-gucukoglu.com. (long-ttl) IN A (address)
> Cache that A result.
>   
> When client asks cache what the IPv4 address of bloodstone is, that's the 
> result it'll get.  It has a long TTL, unlike the genuine record.  So, no 
> host anywhere on the net using this cache can ever hope to see the short 
> TTL and genuine authoritative response.  The parent zone essentially holds 
> the only copy of that record anyone ever sees.  The parent gets to decide 
> what that A record will look like.  And all because it happens to be a 
> point of delegation, for which asking the node at the opposite side of the 
> cut would appear completely redundant (Bloodstone, what is the address of 
> Bloodstone?).  Just because it is a point of delegation, why does non-
> authoritative data for a host suddenly become authoritative?  Why does a 
> recursive cache even settle for non-authoritative data when it isn't 
> forwarding?
>
>   
If bloodstone.sabahattin-gucukoglu.com is one of the delegated 
nameservers for sabahattin-gucukoglu.com, its A record will appear in 
the Additional Section of a referral response from the .com nameservers. 
I don't see that you have much of a choice but to trust it. What's the 
alternative? Go to the authoritative nameservers and ask them instead? 
What A record(s) will you use to query those authoritative servers?? 
That's right: *exactly*the*same*A*record(s)*. So if .com has been 
hacked, you're pretty much stuck anyway. It could direct you to a set of 
bogus nameservers that will happily confirm, authoritatively, that 
bloodstone.sabahattin-gucukoglu.com resolves to an address of their 
choosing. The only reason for preferring the data from the authoritative 
servers in this scenario is that it may be more up-to-date (folks don't 
always update their delegation information in a timely manner). From a 
security standpoint, though, using a potentially-spoofed glue record to 
verify the authenticity of *itself* really adds negligible protection 
versus simply accepting that glue record as is.

If you're using DNSSEC then you have a semi-independent way of 
validating the data. But in the absence of that, there are certain 
things you simply have to trust. The security/integrity of the .com 
nameservers, for instance, is something we need to trust for domains 
that are under that TLD.

If, on the other hand, bloodstone.sabahattin-gucukoglu.com is *not* one 
of the delegated nameservers for sabahattin-gucukoglu.com, then BIND 9 
will go to the authoritative nameservers, ask them for 
bloodstone.sabahattin-gucukoglu.com/A, and, if it exists, the response 
will come back with the A record(s) in the *Answer* Section, not the 
Additional Section. If you can't trust the Answer Section of an 
authoritative response from the authoritative nameservers for the zone 
containing the name you're querying, what (in the absence of DNSSEC) 
*can* an iterative resolver trust? Answer: nothing. Trust needs to start 
somewhere.

- Kevin