[DNSOP] Re: Comments from IETF Last Call about draft-ietf-dnsop-structured-dns-error

[tirumal reddy <[e-mail]>]

Hi Paul,

Please see inline

On Tue, 6 May 2025 at 19:23, Paul Wouters <[e-mail]> wrote:

> On Tue, 6 May 2025, tirumal reddy wrote:
>
> >       I am not sure why a JSON object for a browser would produce a more
> >       "meaingful error message" than one that is possible with RFC 8914 ?
> >
> > It is designed for clients to interpret and render meaningful,
> user-friendly messages. This approach has already seen adoption, such as
> in AdGuard’s DNS SDE
> > extension, which shows how structured DNS error reporting can enhance
> end-user communication.
>
> I disagree. An ENUM can be handled by browsers to display text in the
> locality of the user. This can just fling up a free text English
> message, that you expect browsers to validate for potential harm
> before displaying to the user. You are subcontracting out the
> security risks you are introducing.
>

To clarify, the sub-error attribute, being an ENUM, can be rendered without
interpretation and is suitable for localization and consistent handling
across clients. For other fields, specific restrictions are imposed to
avoid the risks associated with displaying its content.


>
> > The risks associated with displaying attacker-provided contact details
> are already addressed in the draft
> > (see
> https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-15.html#section-10.2)
> The draft explicitly states that displaying the "c" field is not
> > mandatory and outlines conditions under which it may be shown. While a
> home admin or IT department may already know the resolver’s contact
> details, other users on
> > the network often do not. Providing contact information in structured
> form improves ease-of-use, allowing users to report filtering errors
> without having to
> > independently search for their ISP’s or administrator’s support details.
>
> Ease of use for which users? Please tell me which of these users will
> use this contact information:
>
> 1) Paul using a mobile phone, maybe connected to wifi or LTE.
> 2) Paul using a mobile phone, at home using a default CP from his ISP
> 3) Paul using a mobile phone, at home using his own stuff - he is a geek
> 4) Paul using a mobile phone, at starbucks, mall or airplane
> 5) Paul using a mobile phone, as BYOD at work
> 6) Paul using a mobile phone, in his hotel room
> 7) Paul using a Desktop at home
> 8) Paul using a Desktop at work

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. For instance, see
real-world examples like OpenDNS block page
<https://answers.microsoft.com/en-us/windows/forum/all/opendns-has-blocked-my-main-sites-on-my-main/66b53344-7f01-4daa-998f-b1c6be295873>
and
Quad9’s collaboration
<https://devops.com/criminal-ip-and-quad9-collaborate-to-exchange-domain-and-ip-threat-intelligence/>
where
users are directed for support or further action. Structured DNS error
reporting
simply standardizes this practice, with clear restrictions on when the
"c" field
should be displayed to the end-user.


>
> Tell me in which of these scenarios the contact info should be
> displayed. Then do the same for Paul, now elderly at 90 years of
> age, and not really understanding how is phone or desktop connects
> to the internet at all.
>

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.


>
> >       The text "malware present for 23 days" and "example.net Filtering
> Service"
> >       could have already been placed in the EXTRA-TEXT field as per
> RFC8914.
> >
> >
> >       The draft further states:
> >
> >               Whether the information provided in the "j" name is
> meaningful
> >               or considered as garbage data (including empty values) is
> local
> >               to each IT teams.
> >
> >
> >       The draft seems the cherry-pick whether the content is meant for
> >       endusers ("to eliminate the need to "spoof" block pages for HTTPS
> >       resources") or when it is meant for IT teams. I think IT teams can
> >       figure out who admins a DNS resolver on a certain IP already. The
> >       non-admins are just vulnerable to misinformation.
> >
> >
> > Relying solely on the EXTRA-TEXT field to carry "j" would prevent
> carrying other structured fields intended for both IT admins and end-users.
> This is precisely why
> > separating structured information into dedicated fields is necessary to
> allow selective display to end-users and logging for IT admins.
>
> I am fine with more enum's helping categorize why an answer is withheld.
> I am having a problem with the EXTRA-TXT.
>
> If an IT admin cannot find out who is responsible for a DNS filter, they
> should probably switch DNS filter vendors. Worse, if their DNS service
> providing this is compromised, they can't even trust it anyway. They
> need to use their own resources and documentation, and not the network
> provided one. I think claiming this is useful for non-endusers is just
> not realistic. Which leaves us with endusers which means anything
> displayed can and will be abused by attackers to manipulate vulnerable
> endusers.
>
> I see the main concern from an ISP being "It looks like we are broken
> but we are merely following instructions (from government or the
> commercial serivce opted in by the enduser) to filter/block a DNS
> request".
>

IT admins typically know their resolver’s support contact details. The
"j" field
helps them identify the exact reason a domain was blocked without needing to
contact the resolver’s helpdesk. For example, if a domain is blocked because
it is unclassified or misclassified, and the IT team sees multiple
users accessing
it for legitimate reasons, they can create an explicit allow rule and raise a
ticket with the resolver’s helpdesk.


>
> So for that, ENUMs are enough and save to convey. And browsers can
> translate enums for the user. Eg:
>
> FILTERED_BY_DEVICE_REGULATORY
> FILTERED_BY_DEVICE_USER_OPTIN_ADULT
> FILTERED_BY_DEVICE_USER_OPTIN_ADBLOCKER
> FILTERED_BY_ISP_REGULATORY
> FILTERED_BY_ISP_USER_OPTIN_MALWARE
>

The draft has already added a registry to update the enum in future
specifications.

Cheers,
-Tiru


>
> etc.
>
>
> >
> >       And this:
> >
> >               This approach thus avoids the need to install a local root
> >               certificate authority on those IT-managed devices.
> >
> >       Is clearly targetting endusers.
> >
> >
> >       I believe this document is actually harmful to endusers, with no
> >       meaningful gains for IT teams. If I was a browser vendor, I would
> >       only allow displaying i18n text for EDE enums.
> >
> >
> > please elaborate how it is harmful to end-users.
>
> I've tried to explain this two times now. I hope this helps. Note that
> it might also be helpful to read the below text where I explain how
> Mark was trying to reduce the harm caused by your draft, but how I feel
> it is still (too) dangerous to use freefom text ask Mark proposed.
>
> Paul
>
> > Cheers,
> > -Tiru
> >
> >
> >
> >       Now Mark Nottingham does a fair attempt at trying to contain the
> >       problem of display free text for the enduser in
> draft-nottingham-public-resolver-errors
> >       by constraining the EXTRA-TEXT to just two IDs that map to a DNS
> >       provider and an incidence number. But that will lead us back to
> >       attacker induced spoof pages, eg:
> >
> >       The network / attacker does a:
> >
> >       - redirecting major IPs port 53 to itself (eg 1.1.1.1, 8.8.8.8,
> 9.9.9.9)
> >          (and block DoT, DoH, DoQ)
> >       - issuing DHCP DNS servers to itself.
> >       - transparently run all port 53 through its own resolver.
> >
> >       then:
> >
> >       - Use a globally trusted ID from the DNS Resolver Identifier
> Registry, eg
> >          the one from Google DNS.
> >       - Generate a filtered response with Extended DNS Error Code 17
> (see [RFC8914])
> >          and an EXTRA-TEXT field containing:
> >
> >          {
> >            "ro": "GoogleDNS", // or whatever they would have registered
> at IANAA
> >            "inc": "abc123" // or whatever format Google DNS would use
> >          }
> >
> >       Let's assume Google DNS has registered the template:
> >
> >
> https://resolver-report.dns.google.com/filtering-incidents/{inc}
> >
> >       then additionally:
> >
> >       - resolve resolver-report.dns.google.com to itself.
> >       - generate some self signed cert for
> resolver-report.dns.google.com
> >       - publish malicious / advertising content on any URL on
> resolver-report.dns.google.com
> >
> >
> >       Since captive portals have already desensitized users into
> accepting
> >       spoofed pages, this will still trick a percentage of users into
> going
> >       to a malicious site (even if one cannot make it clickable, the text
> >       can lure people to open a new tab/window and type in the name of
> the
> >       website conveyed in the error msg, eg "visit www.fbi-arrests.io to
> >       avoid an arrest warrant for trying to browse illegal content").
> >
> >       Furthermore, the incidents number can be customized for tracking or
> >       deanonimising a user (eg one using Private Relay / MASQ). It would
> be
> >       much better from a privacy perspective to only allow the QNAME to
> be
> >       the incident number.
> >
> >       Note also that RFC 8914 warns of the dangerous of EXTRA-TEXT
> causing DNS
> >       fragmentation when messages are used that are too long.
> >
> >       Mark's draft also causes more centalization of "well known/trusted
> DNS
> >       servers".
> >
> >
> >       I would suggest that instead of these solutions,
> draft-ietf-dnsop-structured-dns-error
> >       restricts itself to extend the ENUMs to cover most cases, and
> leave the
> >       user / browsers to try and give more details errors, without the
> IETF
> >       centralizing it using an IANA Registry. I would like it to
> deprecate
> >       EXTRA-TEXT.
> >
> >       If some kind of extra text option is _really_ needed, then extend
> RFC
> >       9606 resinfo with a template field that points to the resolver
> operators
> >       extended error website, that browsers can use by filling in the
> template
> >       URI with only the QNAME as option so it is guaranteed each user
> trying
> >       to go to the same blocked domain gets the same error message and
> cannot
> >       be deanonimized or tracked.
> >
> >       Paul
> >
> >       _______________________________________________
> >       DNSOP mailing list -- [e-mail]
> >       To unsubscribe send an email to [e-mail]
> >
> >
> >
>