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

[Petr Špaček <[e-mail]>]

On 26. 10. 21 11:14, Vladimír Čunát wrote:
> 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?

We need to consider & document interaction between Query Name 
Minimization and NXDOMAIN processing as per RFC 8020. If minimization & 
RFC 8020 are on default then it might very easily happen that most of 
_er subtrees (which are presumably empty) will be cut out by cache and 
nothing will be sent out when an error is detected.

All in all, I think the text should warn about this interaction instead 
of mandating query name minimization on/off.


>> 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.

I will use stronger language: This is under-specified to the point where 
it starts causing confusion.
* Is the paragraph considering channel from stub to resolver?
* From resolver to auth?
* Both?
* What to do with queries executed by resolver on its own (prefetch)?
* What if multiple clients are waiting for the same query, using 
different channels? (query deduplication in the resolver)
etc.

I think this should go to Security Considerations section and be left 
for implementations to decide. MUST mandate is way too strong and does 
not accommodate implementation- and deployment- specific circumstances.


>> 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.

I agree. Mandating "disabled by default" configuration on _resolvers_ 
sounds like a way to get to a working-but-never-deployed protocol.

-- 
Petr Špaček  @  ISC