Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

[Tony Finch <[e-mail]>]

Stephane Bortzmeyer <[e-mail]> 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  <[e-mail]>  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.