[DNSOP] Re: DNS, censorship, attacks and centralization

[Bill Woodcock <[e-mail]>]

> On May 19, 2025, at 09:03, Mark Nottingham <mnot=[e-mail]> wrote:
> 1. Surfacing censorship events to end users is desirable, because it a) avoids user confusion / misattribution of the problem, and b) allows end users to be more fully informed.

I would generalize this to all errors, not just censorship, but I strongly agree.

> Both my draft and (AIUI, based upon the above) the structured DNS error draft have a notion of 'trusted' DNS resolvers that has privilege over 'untrusted' DNS resolvers, as a mitigation to attack.

I think we have at least four cases here: (1) assertions made by authoritative resolvers, where the authoritative resolver is worthy of trust because it’s serving valid signed answers for the domain, (2) assertions made by recursive resolvers which contradict a valid answer, (3) assertions made by recursive resolvers which contradict an invalid answer, or (4) assertions made by recursive resolvers which are orthogonal to or do not contradict a valid answer.

(1) could include extended DNS error codes 0, 15-18, 20, 21, 24, and perhaps 23.  Since those answers are being provided from the authoritative to the recursive, the recursive could hypothetically make a decision about whether or not to pass them along to the stub or caching/forwarding resolver, and so on, all the way to whatever’s controlling the UI.  It occurs to me that, if RFC 8914 were extended, EDE could be signed, in cases where the error does not contain dynamic data (i.e. all possible error messages could be pre-generated and pre-signed) or in cases where the authoritative server wields a copy of the ZSK and is dynamically signing answers.  I don’t, offhand, see much downside to allowing this, and it would help establish whether the error message was “trustworthy” and thus help the UI determine whether it should be shown to the user.

(2) presumably includes extended DNS error codes 4 and 15-18.  

(3) includes at least EDEs 1-12.

(4) includes at least 13, 14, 19, and 21-23.

A scheme whereby EDEs originating from a recursive resolver could be signed by the recursive resolver can be imagined, but it might not shoehorn in easily.  Presumably if the user has a TLS connection to the resolver, and it is a recursive, not caching/forwarding, resolver, that’s good enough.  One can hope that a caching/forwarding resolver might also have a TLS connection to a “trusted” recursive resolver as well, though that would unfortunately be outside the user’s ability to verify.

…anyway...

>> Will the “trusted” DNS start refusing the .gl TLD soon because of a mad king ?
> 
> If that's the case, I don't see how proposals along this line change the outcome. If a government in a given jurisdiction wants to censor, they will censor. 

However, having three of the four big recursive resolvers all answerable only to the United States District Court for the Northern District of California does represent an astonishing degree of centralization.  Indeed, governments will censor, but we don’t all need to depend upon the same government’s idea of what should be censored.

                                -Bill