Hi Petr, > On 26 Oct 2021, at 11:02, Petr Špaček <pspa...@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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
