Hi Dan, Can you spell out how this intersects with enshittification? I understand that there are various centralisation issues and risks inherent in DNS, but if you're arguing that this mechanism makes it worse, it's hard to see the connection. In particular, could you explain more about the nature of 'too big to fail' resolvers? My understanding is that the switching costs for resolvers are extremely low for most users (hence the rise of public DNS); where user action is constrained (e.g,. in an enterprise network), their central role is by design (at least by the entity who controls the hardware). Now, we could talk about defaults and how that inertia tends to empower a few operators, but how this mechanism makes that situation worse isn't readily apparent. Are you just arguing that we should try to use it as a way to limit that tendency? If so, I don't see how it could be used effectively. Also, the mechanism you do describe -- "users would notice the lower error fidelity and browsers would be tempted..." doesn't seem very realistic to me. Showing a DNS filtering notification is a positive action, and most users won't notice its absence, they'll just see the behaviour they've seen to date. Granted, technical folks like us might notice and act, but we are a very tiny minority. Finally, the draft doesn't give IANA the role of deciding what 'bad behaviour' is -- I'm pretty sure they'd decline that responsibility. The draft gives clients the discretion to decide who to pay attention to, not IANA. Cheers, > On 29 Apr 2025, at 10:27 pm, Dan Wing <danwing@xxxxxxxxx> wrote: > > Once a DNS operator is listed with the DNS Resolver Identifier Registry, that operator could enshittify (https://en.m.wikipedia.org/wiki/Enshittification) their service to all or some clients. Even if IANA were to (somehow) pull a DNS server from the registry due to such bad behavior, users would notice the lower error fidelity and browsers would be tempted to continue behaving as if that DNS server was still on the IANA registry. For resolvers Too Big To Fail, we are likely stuck with whatever they want to do. Is this not the antithesis of a distributed system? > > -d > >> On Apr 17, 2025, at 05:16, Mark Nottingham <mnot=40mnot.net@xxxxxxxxxxxxxx> wrote: >> >> 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 <iesg-secretary@xxxxxxxx> 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 >>> last-call@xxxxxxxx mailing lists by 2025-04-28. Exceptionally, comments may >>> be sent to iesg@xxxxxxxx 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 -- ietf-announce@xxxxxxxx >>> To unsubscribe send an email to ietf-announce-leave@xxxxxxxx >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> _______________________________________________ >> DNSOP mailing list -- dnsop@xxxxxxxx >> To unsubscribe send an email to dnsop-leave@xxxxxxxx -- Mark Nottingham https://www.mnot.net/ -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
