On 26/10/2021 12.10, Roy Arends wrote:
I have a slide ready to discuss the issue that DNS Query Name
Minimization brings… A minimised query can’t be distinguished from a
full query, so it may not be clear what name caused an issue. The
current thinking (but will be discussed later today) is to start with
_er as well. That way, the erroneous qname is “encapsulated” by _er
labels.
I assumed you can distinguish those quite reliably thanks to QTYPE=NULL
which I haven't heard of for minimization so far.
If, at any point, auth servers offer encrypted transport, a faulty
query should not be replicated in clear text.
I certainly agree with that, but then the text should be clarified that
the encryption refers to auth side and not client side. As it is now,
it refers to RFC numbers that explicitly consider client side only, so I
assumed that's what was meant.
To make the error-reporting work, you need noticeable commitment to
deploy on both sides, because otherwise the perceived benefit from
deploying might be quite low. On resolver side, I believe that it
will be quite rare for operators to tweak such highly technical
options[*]. So if this MUST be off by default, you at least need
commitment from some significant operators - say, I'm not even sure
if Quad9 by themselves would suffice to bootstrap this.
I'm inclined to remove that text alltogether. Resolver implementations
either do this by default, or not. No need to pedantically require
config first and default off. Additionally, there is an issue where
resolvers need to retry without the option when auth servers can’t
handle the option… I’m inclined, just like Extended DNS errors itself,
to have authoritative servers just set the option, unsolicited. It
hasn’t caused any issue for extended DNS errors yet… but lets have
that discussion this afternoon.
I'm not sure about this reasoning, but anyway - I'd be also inclined to
remove that paragraph, and we'll see what opinions appear during the
call and afterwards.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
