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

Hi Petr,

> On 26 Oct 2021, at 11:02, Petr Špaček <pspacek@isc.org> wrote:
> 
> 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.

Ack, lets discuss this afternoon.

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

Yes, one way of dealing with it is to have the reporting agent server (where the reports go), deploy a wildcard under their reporting agent zone.

Additionally, I think we should never require additional complexity to query name minimisation. The issue caused by query name minimisation can be solved by prepending an _er label, so the erroneous qname is encapsulated by _er’s.

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

I agree.

> * Is the paragraph considering channel from stub to resolver?

No.

> * From resolver to auth?

Yes. 

> * Both?

No.

> * What to do with queries executed by resolver on its own (prefetch)?

They’re not special.

> * What if multiple clients are waiting for the same query, using different channels? (query deduplication in the resolver)
> etc.

Assuming you’re referring to stubs (not sure if you do, apologies): The reporting is independent of the client. i.e. the report will not go to clients, but to authoritative servers.

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

Ack.

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

I agree.

Roy

> 
> -- 
> Petr Špaček  @  ISC
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop