Since this draft was sent to the IESG, there's been significant other work incorporating feedback from browser vendors, in order to make information about DNS blocking more visible to end users. See: https://datatracker.ietf.org/doc/draft-nottingham-public-resolver-errors/
I presented that work at IETF 122 in DNSOP and there seemed to be strong interest. While my draft builds on this one, and so could be considered separately, it's pretty clear that this draft doesn't reflect broader perspectives on what information is relevant to present; it's primarily written from the perspective of DNS folks. Given the renewed interest in this area of work and the new (and very relevant) participants, I suspect it would be beneficial to hold onto this draft a bit longer to get wider review and input, so that it could reflect these new use cases and perspectives. I don't appear to be alone in that assessment; e.g., https://youtu.be/6s0Q5oiydzc?feature=shared&t=2667 That said, I'm not against publication, necessarily: I just suspect that the draft could be significantly improved and made more relevant if it had a bit more time. Now, some more specific feedback: * In Section 3, " If an HTTP enabled domain name is blocked" (and similar language). Domains are not "HTTP enabled" or "HTTPS enabled" -- try something like "If the authority of a HTTP URL is blocked." * In Section 3, "However, this approach is ineffective when DNSSEC is deployed given that DNSSEC ensures the integrity and authenticity of DNS responses, preventing forged DNS responses from being accepted." There are assumptions about DNSSEC deployment baked into this statement. In practice, it has little preventative force. * In Section 4, the c field (contact) is required to be present, and required to be a mailto, sips, or tel URI field. Constraining URL schemes isn't great practice, even if backed with a registry; what if people want to use a web form? Furthermore, requiring operators of all DNS resolvers to provide contact information isn't realistic: at any scale it's unreasonable to ask them to respond meaningfully. Furthermore, if the block is legally motivated, they won't be able to do anything about it. I'd suggest removing both the constraint on the URL scheme and the requirement for c to be present. Recommending URL schemes is fine. * In Section 4, it says: "If the text is provided in a language not known to the end-user, the client can use the "l" (language) field to identify the language of the text and translate it to the user's preferred language." This is not best practice for internationalisation. Better approaches might include: 1) Given that the draft already has a negotiation mechanism (Section 5.1), the client could state its preferred language(s) in the request. 2) Don't allow user-visible text in the record at all, but instead convey a URL which when resolved is negotiated for language. This would also help reduce message sizes. * Throughout - the purpose of having sub error codes is never explained in the draft; it might be inferred from the defined codes, but it really should be explicit. Cheers, > On 15 Apr 2025, at 1:18 am, The IESG <[email protected]> wrote: > > > 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://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > IETF-Announce mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Mark Nottingham https://www.mnot.net/ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
