Hi Paul, > On 20 Feb 2026, at 12:16 pm, Paul Wouters <[email protected]> > wrote: > > On Fri, 20 Feb 2026, Mark Nottingham wrote: > >> Subject: [DNSOP] Fwd: New Version Notification for >> draft-nottingham-dnsop-censorship-transparency-00.txt >> Based on discussion at the interim, this draft is renamed and contains a >> proposal for Privacy Considerations. > > Why the draft name change? I thought this looked familiar and then > re-found draft-nottingham-public-resolver-errors. The diff between > that and this is fairly small:
As discussed in the interim, the old name was no longer applicable, and potentially confusing. > I still do not like how the IANA registry and browser adoption of > certain lists becomes yet another centralization point in the internet. > > Why not use a _prefix within the configured resolver's namespace to > point to the reporting database url prefix? This would be a much better > decentralized method that wouldn't give further centralizing browsers > an additional benefit of "better error reporting". > > Why is a filtering ID needed? Doesn't the QNAME already provies a globally > unique identifier? It would make things less depending on filter vendors' > references. It would also prevent abusive IDs that embed javascript or > otherwise try to mislead by adding some identifier in it, eg > > id="123 www.malicious.com/why-did-my-dns-get-filtered" > > That is, if I run a pihole filter in my network, how can my browser use > a reporting service without me needing to hack the browser for it, or > be forced to use quad(1,8,9) for DNS resolving to get decent error reporting? > > If I run my resolver on 192.168.13.13, why can't extended errors be > defined to be at https://192.168.13.13/dns-filter-error/qname/ > > The extended errors would come from the same source as the query, so > either both are untrusted or both are trusted. > > That is, I strongly prefer a method that people can rollout that does > not depend on a "golden list" added to browsers based on some IANA > registry (and bags of money for certain business models) So, that gets us back to putting links from _any_ DNS resolver on the internet in front of end users. As we've said in a few different ways, that's a non-starter; it's a phishing vector and will be a huge headache for pretty much everyone. We need _some_ mechanism to make this safe. Our original approach was to only selectively support some resolvers (namely, widely recognised public resolvers). That (deservedly) got pushback for creating pressure for centralisation. This approach breaks from that by only selectively supporting some Web sites as "databases" of filtering incidents. The initial example (and I believe what Chrome wants to support) being https://lumendatabase.org - originally started by Wendy Seltzer, now run by Harvard Law School Library system. What exactly is the "bags of money" model you have in mind for Harvard here? Cheers, -- Mark Nottingham https://www.mnot.net/ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
