Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

[Vladimír Čunát <[e-mail]>]

Hello.

> DNS Error reporting SHOULD be done using DNS Query Name Minimization
> [RFC7816  <https://datatracker.ietf.org/doc/html/rfc7816>] to improve privacy.

It's just a detail and "SHOULD" isn't strong, but I expect it might be 
worth elaborating here.  The name used in the reporting query adds a few 
labels to the failing QNAME and the whole reporting agent domain, so 
together that's lots of labels, and expending a packet for *each* of 
those labels would seem quite wasteful.  Perhaps we could agree on some 
boundary (e.g. around the "_er" label) under which minimization isn't 
recommended anymore, and put that as a suggestion into the text?

> The reporting resolver MUST NOT report about queries and responses
> from an encrypted channel (such as DNS over TLS [RFC7858  <https://datatracker.ietf.org/doc/html/rfc7858>] and DNS
> over HTTPS [RFC8484  <https://datatracker.ietf.org/doc/html/rfc8484>]).

I believe this needs some explanation at least (in the text, ideally).  
The failing query triggering the report is towards an authoritative 
server (i.e. unencrypted), and the reporting queries do not really carry 
more information.  They may travel by a different path, but on the whole 
I can't see significant motivation for the paragraph, especially in 
"MUST NOT" form.

> This method MUST NOT
> be deployed by default on reporting resolvers and authoritative
> servers without requiring an explicit configuration element.

I'm not so sure about forbidding this on resolvers so strongly, but 
certainly OK if the WG prefers it that way.  (On auths it wouldn't make 
sense to enable by default; what agent?)  If the error-reporting is 
meant really seriously, I'd rather improve the mechanism to never induce 
significant overhead and encourage enabling it by default on resolvers 
(at some point).

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.


--Vladimir | knot-resolver.cz

- - -
[*] and I support that.  I'm a big proponent of defaults.  They should 
work as good as possible, and deployments should operate as close to 
defaults as possible.