> On May 19, 2025, at 09:03, Mark Nottingham <[email protected]>
> 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
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
