Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > > Cute trick. I love it.
:-) > But it modifies the rules for response credibility (the most credible > response is in the additionnal section, not in the answer section). > Should we update RFC 2181, section 5.4.1?> I tend to think that the A > record, in that example, should be treated exactly like glue, by a > ANAME-aware client. Interesting point. My understanding is that, in principle, DNSSEC makes it possible to trust parts of answers that are (in current implementations) distrusted. For example, out-of-zone data about CNAME or MX targets. There's a big opportunity here to reduce latency by doing a bit more work to eagerly validate and cache additional data. (An aside: glue appears in multiple places in the RFC 2181 5.4.1 ranking, depending on whether the server found it in an primary/secondary zone or got it in a referral.) Regarding my ANAME suggestion, the key paragraphs are shortly after the trustworkthiness ranking: 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. The first word is the key word: "Unauthenticated" - the next paragraph says: When DNS security [RFC2065] is in use, and an authenticated reply has been received and verified, the data thus authenticated shall be considered more trustworthy than unauthenticated data of the same type. Note that throughout this document, "authoritative" means a reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY records to determine the authenticity of data, the AA bit is almost irrelevant. However DNSSEC aware servers must still correctly set the AA bit in responses to enable correct operation with servers that are not security aware (almost all currently). With this context, I believe RFC 2181 says that if you have validated the additional data from an answer like the one in my example (https://mailarchive.ietf.org/arch/msg/dnsop/Zh7viwmrR7QcJSFQvqMsb7YSRU8) you are allowed to return it as a direct answer to queries, and you don't have to keep it in the additional section sin bin. It's probably also sensible to retain its low trustworthiness ranking, so that it can be replaced in the cache by a more trustworthy answer, to reduce the risk of replay attacks that use old data that's still within its RRSIG validity period. On the other hand, it might be usefully simpler to make ANAME-specific recommendations about how to handle the additional data. Dunno :-) Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode East Sole, Lundy, Fastnet: Cyclonic 4 or 5, becoming northwesterly 5 to 7. Moderate or rough. Showers, thundery at first, fog patches at first. Moderate or very poor, becoming good. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
