[ still speaking as individual dns enthousiast ]
I removed the text where we have disagreement where I don’t think we are progressing / converging. I just have a few comments to add to some of your responses. On May 12, 2025, at 03:12, tirumal reddy <kondtir@xxxxxxxxx> wrote:
If you could elaborate further on the nature of your concern, it would help us understand the disagreement and address it more effectively.
I have done quite sone elaboration already. Others even pointed you to parts of my unaddressed items. Claiming these items are not concerns to you until further elaborated seems a bit odd to me.
> You are questioning a long-standing practice of providing contact details in HTTP(S) block pages to assist users. This isn’t new or experimentan, it’s a
> well-established and widely deployed pattern. Resolvers that present block pages include contact information by default. In fact, I’m not aware of any major
> resolver offering block pages that does not include such details.
It seems you are mixing up DNS blocking and spoof page presentations.
eg google states on https://developers.google.com/speed/public-dns/blocking
that they return REFUSED, so I don't understand how an enduser could end
up on a block page. Perhaps your claim above is not correct?
Yes, I was referring specifically to spoof pages.
So we agree I am not mixing things up then? Your concern about untrusted networks is valid and we have no disagreement. The draft explicitly recognizes this risk and includes guidance to mitigate it. Specifically, as discussed in the Security Considerations section:
“A client might choose to display the information in the 'c' field to the end-user if and only if the encrypted resolver has sufficient reputation, according to some local policy (e.g., user configuration, administrative configuration, or a built-in list of respectable resolvers)...”
This is intended to prevent clients from blindly displaying contact information, such as those found on potential attacker-controlled networks.
But the draft is just punting this problem from the protocol specification to the protocol implementers. It’s not only the contact data but also the extra text that’s a freeform text attack vector. The goal is to preserve user safety by ensuring that only trusted resolvers can supply user-facing details.
As previously said, this creates a central choke point of trustee dns that works “better” then untrusted dns and causes centralization of dns followed by centralization of censorship. Will the “trusted” DNS start refusing the .gl TLD soon because of a mad king ?
A dns protocol they distinguishes between trusted and untrusted resolvers will break and fragment the internet and is harmful. Additionally, if the client chooses not to display the full content of the EXTRA-TEXT field, it can still log the information for diagnostics.
For whom? Logging exists only in the enterprise or with geeks, neither need this “help”.
The draft requires clients to display the "c" field only if the resolver is trusted, specifically to prevent exposing users to harmful information from untrusted networks. Further, the draft does not require clients to display the "c" field, even for trusted resolvers; it is entirely up to the client's local policy.
See above.
> For elderly users, it’s unlikely they would contact anyone directly, but family members or caregivers assisting will benefit from the structured information to
> report the problem or educate the elderly not to visit the blocked domain as it is bad.
Having just spent two days reinstalling a windows machine with custom
malware running in C:\Users\User\Download, and a chrome browser that
pops up screens with "Your antivirus is disabled, CLICK HERE TO ENABLE"
and the person telling me they did click and renew they anti-virus but
the popup didn't go away, I really really really REALLY differ of
opinion with you my future 90 year old Paul will not click on these
things or make phone calls.
It highlights exactly why the draft leaves it entirely up to the client whether to display user-facing information like the "c" field.
See above.
ENUMs should be enough as a "reason" to be able to figure out if a block
was done in error ("without contacting the helpdesk"). IT admins can get
statistics on QNAMEs that got blocked for their internal investigations
without users calling them. Regardless, how you run your company and
helpdesk is out of scope for this document. Your users already know how
to contact their ISP or Enterprise admins.
It's not practical to capture all possible reasons for blocking using ENUMs. For example, OpenDNS defines numerous domain categories (see list),
There are many points to raise in response to that list. First, the list contains about 60 entries, so that is totally doable as enums.
Second, the list contains such as items as “politics”. This is far outside the scope of legitimate protection of the user and deeply into the area of facilitating government censorship by limiting free speech. Enums allow us to not support categories that go against humanity.
and new ones continue to be added over time. During WG discussions, there was no consensus to standardize categories beyond security-related ones, as others may involve censorship or policy-sensitive filtering.
For cert good reasons. But working around it by building infrastructure abs moving this to “trusted dns resolvers” in browsers will run into these same issues. The "j" field provides necessary flexibility to convey resolver-specific reasons in a structured way but only to the IT admin.
Again, IT admins who are dns censoring their users should have other means to determine why their stuff censors a particular QNAME and do not need this in individual dns responses. I agree that we’re aligned on the threat model.
We are not. My threat model includes abuse of the dns extended text, abuse of overly centralized dns services and government enforcing of censorship against the interest of the user.
The difference seems to be in our assessment of whether the proposed mitigations are sufficient to address the associated risks.
The proposed mitigations keep coming back to browsers or advanced users or enterprises building lists of trustworthy DNS servers. Additionally, because port 53 does not authenticate and any network can transparently proxy 1.1.1.1, 8.8.8.8 and 9.9.9.9, this means this solution can only be used by DoH or DoT dns servers - which the draft does not limit itself to - which together with other ADD/DNR drafts is trying to capture enduser DNS to ISP infrastructure and mark it as “trusted”, bringing endusers under full ISP involuntary censorship.
The draft needs to avoid giving some DNS servers a “special trustworthy” status. If it can’t, then the entire exercise becomes “provisioning” and is not an open internet solution. Questions on how browsers can or should handle information display and/or censorship are not really questions that the DNSOP WG should attempt to answer.
Paul |
