Additional Section Cache Without Consulting Authoritative Data - Why?

Sabahattin Gucukoglu mail at sabahattin-gucukoglu.com
Wed Jul 23 23:35:25 UTC 2008


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

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/AwUBSIfAPSNEOmEWtR2TEQLiLgCgxD8j8k+9HHU3nqJvc6mT/7yUxhAAnR4L
PSWynpc6KDGL69LVT2J5IP/K
=tu6q
-----END PGP SIGNATURE-----


More information about the bind-users mailing list