> On 26 Oct 2021, at 10:14, Vladimír Čunát <vladimir.cunat+i...@nic.cz> 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? > >
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. >> 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. > If, at any point, auth servers offer encrypted transport, a faulty query should not be replicated in clear text. >> 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). Ack. > 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. Roy > > --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. > > _______________________________________________ > 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
