I wanted to weigh in with some thoughts from the browser perspective on mnot's draft-nottingham-public-resolver, discussed at [1]. I wasn't on the mailing list at the time, and so I figure it's easier to start a new thread specifically about the browser (Chrome) perspective.
Large-scale, public DNS resolvers (e.g. 8.8.8.8, 1.1.1.1, or any others that have followed the process documented in [2] to be included in Chrome by default) have only recently become the subject of court orders mandating that the DNS resolver itself block the resolution of certain domains. This working group previously published EDE to allow DNS servers to indicate when a response is blocked for the CENSORED, FILTERED, BLOCKED reason codes. For the legally mandated blocking that is now occurring, public resolvers can / could already return one of those EDE codes. However, this does not provide any information about _why_ a specific request was blocked. The search result page on Google notifies the user at the bottom when results were removed due to DMCA complaints and provides a link to get more information. You may have seen the following text: > In response to a complaint we received under the US Digital Millennium Copyright Act, we have removed 3 results from this page. If you wish, you may read the DMCA complaints that caused the removals at LumenDatabase.org: Complaint. Chrome and Google Public DNS would like to follow ~roughly the same pattern when DNS itself is blocked, and provide some way for DNS servers to provide a link to where users can learn more information about a blocking request. Specifically, Google is interested in linking to Lumen. >From a browser perspective, the constraints are: - Avoiding arbitrary strings and untrusted text being displayed to the user from DNS servers, which are untrusted in browsers - Limiting the UX complexity of the DNS error page The user flow I had envisioned was for DNS providers to be able to provide enough information for user agents to render a link to a pre-registered destination template on the "Domain Not Found / Blocked" error page (e.g. chrome://network-error/-805). This prevents untrusted DNS servers from being able to generate arbitrary links on error pages, but still allows different DNS resolvers to provide information in different ways. While Google may be interested in providing the Lumen ID of the blocking request and linking to lumendatabase dot org, other resolvers may wish to link to content they manage themselves. This is why we suggested the use of a registry. Compiling the registry into the user agent acts as an inherent limiter in what links can be shown to the user. Presumably, most DNS servers are not subject to such court orders, nor would they be interested in tracking enough state per order for this link template to be useful, so I would not expect the registry to be large. Happy to answer questions, etc. Unfortunately, I will not be at Bangkok, however I can investigate dialing in if that would be helpful. -dadrian [1]: https://mailarchive.ietf.org/arch/msg/dnsop/YU_sGM_SMzI-ELHIfTDPxlscIsw/ [2]: https://www.chromium.org/developers/dns-over-https/ -- David Adrian https://dadrian.io
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
