On Mar 1, 2012, at 6:08 AM, John R Levine wrote: >>> the additional section. MX queries already have their kludge, >>> returning A and AAAA records. >> >> I'm pretty sure MX queries do NOT have a kludge. I don't believe that >> the additional section is actually used by any servers these days, > > Really? Caches throw away additional sections even when they're > authoritative? I find that rather surprising. > > Why would it be a productive use of time to add all this new mechanism, > rather than fix caches to use the exact same data that they're already > getting? > > I know about cache poisoning, but the logic to deal with it is exactly the > same logic you'd have to use to decide which of multiple answers to accept. Yes, the logic should be "NEVER cache anything you didn't directly ask for, absent DNSSEC validation".
Which means you (IMO) MUST throw away non-authoritative information in the additional section, and most resolvers will only even attempt to cache additional records when they are the records associated with the authority section. It is the caching of non-asked-for data, be it Auth, Additional, CNAME chains, etc, which enables race-until-win attacks like the Kaminski attack. Thus a resolver MUST NEVER cache data that wasn't specifically asked for if it can't DNSSEC validate this information. It can use the additional data received to indicate that it SHOULD ask for the information, but it shouldn't ever cache it in a general context. Or, if it does cache it, it should validate that the entry would be valid by performing an independent lookup, a'la Unbound and replace the information with the new version. >> My personal goal is to improve resolution times for A/AAAA lookups by >> collecting them into a single query. Perhaps it makes more sense to >> simply add Yet Another DNS Hack and add a special QTYPE like ANY >> meaning "any address", that is actually well-defined and usable. > > Add a new RR called AORAAAA that returns both with a field that has flag bits > to say which is valid. And, of course, the A and AAAA records in the > additional section. Or don't bother. As I mentioned earlier, this is a clear parallelization case, so the only thing you are saving in this optimization is ~100B of traffic, and the latency involved in transmitting an additional 100B through the network. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
