On Fri, May 2, 2025 at 2:44 PM Mark Nottingham <mnot@xxxxxxxx> wrote:
Hi EKR,
> On 3 May 2025, at 3:20 am, Eric Rescorla <ekr@xxxxxxxx> wrote:
>> 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
Not necessarily. As I alluded to above, in the discussions I've had with browser vendors there's a general sense that they'd only expose this information if it came from an explicitly configured resolver (e.g., DoH in the browser).
Sure. I just meant that using encrypted DNS does not mean that a resolver
was explicitly configured.
-Ekr
>> 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?
To be clear, most of the discussion here has been about my draft, which is *not* in IETF LC and is not even adopted.
To my knowledge browser vendors (and other potential consumers of the information) haven't been involved in draft-ietf-dnsop-structured-dns-error very much at all -- although I'd be happy to hear any corrections there. That was one of the reasons I suggested delaying the progression of this draft in my LC feedback.
Cheers,
--
Mark Nottingham https://www.mnot.net/
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
