On Wed, 30 Apr 2025, Mark Nottingham wrote:
[ speaking as individual ]
If browsers only display proper error messages when using a few well
known DNS servers, than I think that is apparent.
I'd agree, *if* being able to show DNS filtering / censorship error messages
can be argued to be a significant competitive advantage for resolvers.
Isn't that the whole reason for this? Better service to the enduser
instead of vague errors or timeouts ? Or as you wrote in your draft's
intro:
Because such filtering happens during DNS resolution, there
is not an effective way to communicate what is happening to
end users, often resulting in misattribution of the issue as a
technical problem
So yes, there would be a browser copetitive advantage of being better.
I tend to think about this in terms of getting the message that censorship is
happening out there.
That does not need free form text as I explained in my previous email.
One of the assumptions that the draft makes is that it's not feasible to show
details on every blocked response, for a variety of reasons. So, it allows
browsers to select those that they decide are trustworthy enough to show those
messages, in order to get that message out.
The browser displaying an i18n version of DNS_CENSORED_USG or
DNS_FILTERED_MALWARE or DNS_FILTERED_ADULT does that fine.
The "trustworthy" part is a separate issue I raised in my previous
email, but you completely ignored to response to that.
How many resolvers they choose to bless in this fashion is a good question;
likewise, questions about how they decide and what governance institutions
would be put in place are very good ones to ask. To me, those answers have the
most influence over the likelihood of this approach having a centralising
effect.
A lot of words saying "using a few centralized DNS servers blessed by
browser vendors" - clearly my own local home DNS server isn't going to
be one of them. So this is a centralization problem.
I'd love to hear responses from the browser vendors about this, and would be
happy to help sketch out some answers -- although just like in other areas,
actually defining those rules and institutions are likely out of scope for the
IETF. That doesn't mean we shouldn't be aware of, contribute to, and watch
those efforts, of course.
Not related to my questions and issues raised.
I'm also not sure what the security model is of this:
Generators MUST only use values that are registered in the DNS
Resolver Operator registry; see Section 4.2. Consumers MUST
ignore unregistered values, and MAY ignore registered values.
What prevents an attacking from using the Google DNS ID and then putting
a malicious text like "visit www.fbi.dev to avoid being arrested" in the
text ? Even if the text is not clickable, some people will fall for it.
The text isn't shown in the current approach taken by my draft; only the URL.
Most of the rest of your comments seem to rely on the text being shown, so I
won't respond to them for now.
A URL is worse than text. It is text that can take over your entire
browser window or OS screen. All the same raised issues apply, so I am
still interested to hear your answers on that. It is obvious either the
user is presented with some "human readable text", or it is presented
with a web page containing "human readable and clickable text".
Paul
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
