On Thu, May 1, 2025 at 6:11 PM Mark Nottingham <mnot= [email protected]> wrote:
> Hi Dan, > > > On 2 May 2025, at 4:31 am, Dan Wing <[email protected]> wrote: > > > > On Apr 30, 2025, at 01:09, Mark Nottingham <[email protected]> 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. > > Got it. > > My initial reaction is that this is somewhat different -- with mis-typed > domains, people got taken straight and silently to Web sites that just > loaded into their browsers; I know you know this, but just so we're all on the same page, this sort of auto redirection will not work with HTTPS URIs because the reference identity in the certificate will not match the expected domain name. > 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. > > If a DNS resolver starts inserting ads / phishing / etc. into responses > using this mechanism, I suspect we'd see a couple of responses: > > 1. Users *would* switch, because a) it's intrusive, b) if the UX folks do > their job it's going to be obvious what's happening, and c) because it's > likely browsers would only expose the information for resolvers that were > explicitly configured (e.g., using encrypted DNS) -- which is evidence that > the users who see it have the means to change because they've already made > one configuration change. > Note that users may or may not have made a configuration change to get this result. For instance, the provider may be advertising one of the public resolvers via DHCP: https://developers.google.com/speed/public-dns/docs/isp 2. Browsers / clients would hear about such abuse and (eventually) stop > their software from displaying information from that resolver. > It seems like a lot of the questions about the utility of this draft and this type of technique in general depend on the behavior of the browsers, but it doesn't seem like we've heard much from them in this IETF LC. Do we have public statements from any browser vendor about what they intend to implement here? -Ekr
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
