It seems clear to me that we do not have consensus on the right technical approach to solve this problem. The proposed solution has some obvious technical problems (e.g. internationalization issues, syntactic ambiguity, vulnerability to user-confusion attacks), to which some solutions have been proposed but not incorporated. It also lacks significant buy-in from browser vendors, who are the primary logical deployment base.
While the IETF often exhibits a "bias toward progress", with drafts moving forward so long as their authors are sufficiently engaged, I think that approach would be a mistake in this case. DNS interference is a highly politically charged topic with significant implications for privacy and human rights. Before any implicit endorsement of such interference, the IETF should have a very clear consensus for both the technical elements and the nontechnical implications, including support from DNS operators (e.g. DNSOP) , browser and HTTP client vendors (e.g. HTTPBIS), and human rights advocates (e.g. HRPC). --Ben Schwartz ________________________________ From: [email protected] <[email protected]> on behalf of The IESG <[email protected]> Sent: Monday, April 14, 2025 11:18 AM To: IETF-Announce <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [DNSOP] Last Call: <draft-ietf-dnsop-structured-dns-error-12.txt> (Structured Error Data for Filtered DNS) to Proposed Standard The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Structured Error Data for Filtered DNS' <draft-ietf-dnsop-structured-dns-error-12.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email protected] mailing lists by 2025-04-28. Exceptionally, comments may be sent to [email protected] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract DNS filtering is widely deployed for various reasons, including network security. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. The file can be obtained via https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/__;!!Bt8RZUm9aw!9C0Rj9H_b5e6aA3SNUklcrQTs7bfhWv3KVgbo4fPaZDhQR5vp_FbgFrTKPoMibIydRei2cU2bro93Yip0xuU$ No IPR declarations have been submitted directly on this I-D. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
