Hi Qinxin, Thank you for this draft, which contains a number of interesting considerations!
Some of them, but perhaps not all, have already been brought up during the genesis of RFC 9156 (and its experimental precursor RFC 7816), for example in [1]. Discussions can be found via [2] and [3]. Most points, I think, are generally covered by resolvers' practice to limit the amount of work, independently of the reason for the work (e.g., many authoritatives with timeouts to try, many non-matching signatures to try, long CNAME chains etc.). Last year's discussions on Keytrap have made some people ask for a general guidance document on bounding work. I don't know if anyone is coming up with a draft, but QNAME minimisation might deserve its own section there. While I think it is worthwhile to bring up the discussion, I don't think that sparking discussion needs an informational RFC. Instead, it think it would be interesting to juxtapose the new considerations from your document with arguments from [2] and [3], perhaps alongside some measurements on QNAME minimisation performance during complex name resolution in the wild, and/or measurements on how large the impact really is in practice (for example, using an attack testbed). As an editorial comment, "amplification" in the DNS context typically is related to queries from spoofed sources, and using this term here might cause confusion. Perhaps there is a better term for the case at hand. Best, Peter [1]: https://mailarchive.ietf.org/arch/msg/dnsop/K-i3cTpRRVvRPpP639pT7Ua0gm0/ [2]: https://mailarchive.ietf.org/arch/browse/dnsop/?q=rfc7816bis [3]: https://mailarchive.ietf.org/arch/browse/dnsop/?q=qname-minimisation On 1/4/26 08:36, 李沁心 wrote:
Hi all, We have recently submitted an individual Internet-Draft entitled "draft-li-qname-minimization-trade-offs": -- Abstract This document examines the current protocol policies and operational state of QNAME Minimization (QMIN), defined in RFC 9156 [RFC9156]. While QMIN is a DNS privacy mechanism, its existing implementation strategies introduce subtle trade-offs between privacy and security. Specifically, current policies may still present potential information leakage or introduce query amplification potential. This informational document aims to alert protocol designers, implementers, and users to these emerging challenges and suggests that a careful re-evaluation and improvement of the QMIN mechanism are necessary to fully mitigate these combined privacy and security risks. File can be retrieved from: https://www.ietf.org/archive/id/draft-li-qname-minimization-trade-offs-00.txt <https://www.ietf.org/archive/id/draft-li-qname-minimization-trade-offs-00.txt> We would appreciate any comments or feedback from the DNSOP community. Thanks in advance for your time and input. Best regards, Qinxin Li _______________________________________________ DNSOP mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
-- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Möckernstraße 74 10965 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
