On Wed, 30 Apr 2025, Mark Nottingham wrote:

[ speaking as individual ]

Now, we could talk about defaults and how that inertia tends to empower a few 
operators, but how this mechanism makes that situation worse isn't readily 
apparent.

If browsers only display proper error messages when using a few well
known DNS servers, than I think that is apparent.

I'm also not sure what the security model is of this:

        Generators MUST only use values that are registered in the DNS
        Resolver Operator registry; see Section 4.2. Consumers MUST
        ignore unregistered values, and MAY ignore registered values.

What prevents an attacking from using the Google DNS ID and then putting
a malicious text like "visit www.fbi.dev to avoid being arrested" in the
text ? Even if the text is not clickable, some people will fall for it.

There was no free form field in the original extended error list for
good reasons. I don't understand why it is being tried again. The idea
is a security nightmare and an i18n nightmare.

Stick to enums. Make more enums if you want to convey more details. Then
you don't need DNS resolver IDs.

The draft gives clients the discretion to decide who to pay attention to, not 
IANA.

I don't think it does, as there is no security validating the DNS Browser ID.

I am also not sure how this works when the extended error code happens
on a forwarded DNS server, and your DNS server gets the error without the 
answer,
ignores the extended error code (or maybe worse, blindly copies it
without security mechanism) and presents back to the user.

Additionally, all of these filter mechanisms risks the acceptance of
DNSSEC breakage as "normal".

DNS filtering should be rare and it is fine to give weird errors. Most
of these sites _are_ malicious, and so long waits doesn't really matter.
For sites that one juristiction feels needs censoring and another feels
not (whether it's tiananmen-square.org, dei.gov, or freeukrainelibrary.org),
I don't think a bad user experience is neccessarilly bad :P

For a user opt-in blocking, the Filtered, Blocked and Censored could be
extended with enums in the FCFS Registy, eg Blocked-Adult,
Blocked-Malware, Blocked-Fraud, etc. I am not sure what the enduser
really needs verbose text for beyond an enduser representation in their
own language of a handful of these enums.

Any reporting of "bad filters" can be done based on the qname and
extended error enum.

It would avoid a lot security issues with free text, and avoid make some
DNS server IDs more equal than others, and not add to centalization of
the internet.

Paul

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Reply via email to