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

[Jens Finkhäuser <[e-mail]>]

DENIC hat firmly off.

> Mark Nottingham <mnot=[e-mail]> hat am 19.05.2025 > This seems like a good place to focus discussion. First, two things that I don't _think_ are being disputed:
> 
> 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. This is becoming a more urgent problem, thanks to current events.

Perhaps. I write this because:

a) There might be an assumption that censorship is something "bad regimes" require, but good folk would never! This isn't helped by the term "censorship", which is has far more negative connotations than "moderation". The debates in recent years about disinformation campaigns might shed a light on how one person's censorship can be another person's protection from harm.

I cannot stress how impossible it is to find a single answer here that satisfies the majority.

With this taken as a given, then: no, it is not clear that surfacing censorship events is always good. Some parties in this might legitimately wish for things to just "vanish".

To play devil's advocate for this approach: silently dropping ICMP messages has been part of my relationship with the Internet since I can remember.

Personally, I prefer to be informed. But equally, I do not post my social security number online. Information is a street that can be walked by anybody, at the end of the day.

b) Since I've been working with various Internet services for a while now, I've also been involved with helping law enforcement "do stuff" in the digital realm, albeit very rarely. The conversations I've had have been illuminating, as they keep reiterating that the majority of takedown requests they process are related to child pornography.

How we arrive at these anecdotal statistics, I have no idea. But all legitimate, fear-inducing, "bad censorship" scenarios aside (which also worry me), if there's a slight chance one can trust this information, then in order of highest to lowest preference:

- I get to discuss with my kids why they can't see something.
- It's just not there.
- They see a message about it not being there that isn't suitable for them.
- They see the content.

The TL;DR here being, censorship event information isn't of the same value for every Internet user.


> 2. Allowing untrusted network elements to display messages to the end user is an attack vector that needs to be mitigated. 

+1

> (2) leads to designs where the ability to display messages is gated somehow. 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 this kind of attack.
> 
> Paul, you say above that this approach can lead to outcomes where there is centralisation in both DNS and censorship. 
> 
> I agree that doing so creates a different experience -- users of 'trusted' resolvers will presumably see clearer error conditions when censorship is happening.
> 
> However, whether that difference amounts to an advantage that is so great that it creates overwhelming pressure to use such resolvers is questionable. Many users will be unaware of the difference at all; even those that care about censorship only benefit to the degree that they know censorship is happening. There is no economic or functional advantage beyond that knowledge.
> 
> Even if such pressure does eventuate, it's questionable that it would result in centralisation -- i.e., whereas those DNS resolvers would become more of an effective choke point for control than they are today. That's because users can easily switch between resolvers if they choose to; DNS is a standard protocol with multiple implementations and multiple deployments. Today people can (and do) use their ISP or other local network resolver, use a public resolver, or deploy their own resolver.
> 
> Note that I'm using 'centralisation' in a way that's distinct from 'concentration' -- but again, even if the concern is concentration in the DNS resolver market, it's hard to see this information making a significant difference in that market. Yes, some censorship-aware folks might decide to deliberately configure a DNS resolver, but that's hardly going to move the needle on concentration.
> 
> If I'm missing something here or otherwise misjudged it, please point out what/how.
> 
> If someone has an idea for a way to mitigate (2) in a different fashion, I'm all ears.

Kind of... there's an ongoing movement here in the fediverse on how to distribute moderation, which as per my previous remarks, is probably the same issue in a different guise.

I can't speak for every participant, but having followed this then the best mitigation isn't to "centralise" resolvers, but to separate resolvers from moderators, and let users (or in the case of children, their legal guardians) choose their moderators.

This moves the solution space close to the end user: the local home network resolver would need to implement this.

The specific technical means is not particularly relevant, but it amounts to publishing a list of moderation recommendations, having the resolver consume this, and apply a local policy in how to interpret those recommendations. There have also been discussions on aggregating and moderating such moderation lists, etc.

It may also result in different choices, "drop CSAM silently" and "inform, but allow" versus "inform, but censor" for other types of recommendations.

The reality is, again taking the parenting approach as an example, few parents will do more than consume a "trusted" source without reflection, but speaking about being informed and visible: here it would be.

It *does* require, however, that the resolver MAY announce censorship events (in a specific fashion). I do support this choice very much.

> You also talk about 'centralisation of censorship.' I'm not sure what you mean there, but am guessing that you're concerned that censorship might become easier, based upon:
> 
> > 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. Providing a mechanism for resolvers to making the details available to citizens who are affected by that censorship so as to inform their participation in the democratic process (assuming they're lucky enough to live in a jurisdiction that allows that) is the best we can do.
> 
> When I started this work, I had a latent concern that defining mechanisms like this would encourage censorship because it 'blesses' a path for courts (etc.) to use.  We're well past that now -- courts, legislatures and policymakers around the world are now regularly blocking content using a variety of (often technically bad) methods. The best outcome is one where that activity does as little collateral damage as possible, and its operation is made as clear as can be to those who it affects.

If you can trust your institutions to provide information on censorship events, then you can trust your institutions in this area.

If you cannot, then no amount of protocol changes will give you more information than "it should be there, but isn't".


In summary, I support the option to provide information very much. I would consider separating the resolver mechanism from the blocklist mechanism, which the draft does. I think it's clear enough that it won't do much for "bad censorship", but we're past that point anyway as Mark says. To me, the goal is improvement of "good censorship" to better benefit the end user.


As more of an aside, I would urge not to leave the blocklist mechanism entirely unaddressed. There is IMHO great value in treating this as a "decentralized dissemination of moderation recommendations" problem rather than as a DNS problem specifically, however, but the DNS use case should be considered.


>From this point of view, there's a case to be made to allow for e.g. a content-type kind of field somewhere. I was looking at the justification field first and foremost, because I've seen discussions on why structured data here might be good for federating decision making (TL;DR). So I would propose:

- Either add a type field that relates to the justification (optional, defaults to what's proposed), or
- Make a top-level object with type and content, and move the proposed fields into the default content.


Finally, one might think of replacing the I-JSON with RFC8152 COSE as an envelope (plain CBOR if no signing is desired). This would help the ability to attribute the recommendation to a source, keeping in mind my previous comments that the moderation decision may well best occur outside of the resolver maintainer and their policies, and a chain of trust here could also be beneficial.

(Apologies for this late input, I hadn't associated structured DNS errors with this kind of concern until this point in the thread)

Jens