On Apr 30, 2025, at 01:09, Mark Nottingham <m...@mnot.net> wrote: > > 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.
- DNS operator is added to IANA list - Browsers and other non-browser software query that server for extended errors - time passes - DNS operator increases revenue by encouraging users to visit certain URLs. For example, mis-typed domains (provided as an example we have seen before). Someone more creative might envision other bad behaviors if URL is returned. > In particular, could you explain more about the nature of 'too big to fail' > resolvers? It is not just the DNS servers with vanity IP addresses. Any resolver on the IANA list, or common enough to have their name or IP address spray painted on buildings during protests, or known to not filter domains disliked by the current government. > 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. Agreed. Which means users won’t change their DNS server, even when it starts enshittifying, and even though it’s low switching cost. So users will suffer when the DNS operator starts doing bad things. Users might well notice that browser A (which honors the higher fidelity error) “works better” than browser B (which ignores the higher fidelity error because that browser disfavors the user’s choice of DNS server because it misbehaves). Perhaps that isn’t solvable? But it does mean some users are going to be harmed when using browser A with that DNS server — and see whatever the operator wants on that URL. -d > 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 <danw...@gmail.com> 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....@dmarc.ietf.org> 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-secret...@ietf.org> 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-c...@ietf.org mailing lists by 2025-04-28. Exceptionally, comments may >>>> be sent to i...@ietf.org 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-annou...@ietf.org >>>> To unsubscribe send an email to ietf-announce-le...@ietf.org >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> _______________________________________________ >>> DNSOP mailing list -- dnsop@ietf.org >>> To unsubscribe send an email to dnsop-le...@ietf.org > > -- > Mark Nottingham https://www.mnot.net/ > _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
