Re: [DNSOP] draft-ietf-dnsop-structured-dns-error: suberr registration policy

[Ralf Weber <[e-mail]>]

Moin!

On 18 Apr 2023, at 13:11, Benjamin Schwartz wrote:

> The draft's opening words are "DNS filtering is widely deployed for network
> security".  This is true, but by far the "widest" deployment of DNS
> filtering is for authoritarian national censorship, to prevent citizens
> from engaging with forbidden ideas.

Do you have any data to back this claim up? I see far more solutions out
there protecting against attackers (malware, phishing, etc) then there
are for “censoring” or parental controls. Also there are democratic
countries that with agreements of their citizens block access to some
content using DNS. But none of that should matter here as the idea of
this draft is to help the user to be informed why something has happened
using extended DNS errors and I think that is a win for the end user.


> The EDE draft acknowledges and rebukes this rather directly with the
> "Censored" code, expressing that this filtering was performed _against_ the
> preference of the resolver operator.  Although the EDE registry is FCFS,
> the presence of this registry entry at the outset ensures that any attempt
> to whitewash this sort of behavior would be duplicative.
>
> The "structured errors" draft risks undermining this norm and diluting the
> intent of the "Censored" code.  For example, the "Malware", "Phishing",
> "Spam", and "Spyware" suberrors are listed as applicable to the "Censored"
> code, which is rather strange.  What is a "Spam" domain, and when would a
> resolver be forced to filter it "due to an external requirement imposed by
> an entity other than the operator"?
>
> I think the idea of "suberrors" for the "Censored" EDE code probably just
> doesn't make sense.  By definition, this code indicates that the resolver
> _doesn't_ know why the result was filtered.  (The resolver operator may
> know a _claimed_ reason, but it has no way to know whether this rationale
> is the real motivation.)  Thus, one way forward might be to exclude this
> code from the suberror registry.
>
> Even for the other codes, I think this registry opens a terrible can of
> worms that the IETF can and should avoid.  Shall we add codes for "adult
> content"? "advertising"? "social media"? "political extremism"? "terrorist
> content"? "CSAM"? "fake news"?
>
> The EDE draft manages this to some extent by presenting an initial list of
> codes that are plainly technical or structural in nature.  This draft does
> the opposite, by starting to enumerate all the perceived evils of the
> Internet.
>
> Let's not go down that road.

Ok, so for me sub errors are useful as they can give some further information
on why something was blocked, and that information can be conveyed to the
end user. The EDE categories are rather broad and hence don’t give enough
information on why exactly a site is blocked. Now we could also use free
text, which is a problem for people operating in multi language environments
or let each resolver operator pick there own, but maybe some categories that
we all can agree on would be good to put in here. I’m ok with not adding
stuff to the censored EDE code, but we should allow sub errors to Filtered
and Blocked.

So long
-Ralf
——-
Ralf Weber