[DNSOP] Re: Last Call: <draft-ietf-dnsop-structured-dns-error-12.txt> (Structured Error Data for Filtered DNS) to Proposed Standard

[tirumal reddy <[e-mail]>]

Hi Mark,

Thanks for the review. Please see inline

On Thu, 17 Apr 2025 at 07:47, Mark Nottingham <mnot=
[e-mail]> wrote:

> Since this draft was sent to the IESG, there's been significant other work
> incorporating feedback from browser vendors, in order to make information
> about DNS blocking more visible to end users. See:
>
> https://datatracker.ietf.org/doc/draft-nottingham-public-resolver-errors/
>
> I presented that work at IETF 122 in DNSOP and there seemed to be strong
> interest. While my draft builds on this one, and so could be considered
> separately, it's pretty clear that this draft doesn't reflect broader
> perspectives on what information is relevant to present; it's primarily
> written from the perspective of DNS folks.
>
> Given the renewed interest in this area of work and the new (and very
> relevant) participants, I suspect it would be beneficial to hold onto this
> draft a bit longer to get wider review and input, so that it could reflect
> these new use cases and perspectives. I don't appear to be alone in that
> assessment; e.g.,
>   https://youtu.be/6s0Q5oiydzc?feature=shared&t=2667
>
> That said, I'm not against publication, necessarily: I just suspect that
> the draft could be significantly improved and made more relevant if it had
> a bit more time.
>

Most of the structured informational aspects of
draft-nottingham-public-resolver-errors (blocking reasons, contact info,
etc.) are already supported by draft-ietf-dnsop-structured-dns-error, which
applies to a broader range of resolver deployments beyond IANA-registered
DNS resolvers.

The idea of resolver-provided URLs for user-facing error pages was proposed
in earlier versions (see draft-reddy-dnsop-error-page-08) but rejected by
the WG due to security concerns, including risks of advertising, malware,
or misleading content. Another issue highlighted during the discussions was
that TRRs are primarily validated only for the DNS server operator’s
privacy claims, yet could still misuse URLs to serve ads or unrelated
content that is not relevant to filtering. Several mitigation approaches
were considered but ultimately dismissed after discussions in the WG.
draft-ietf-dnsop-structured-dns-error remains extensible for structured
metadata but intentionally excludes dynamic resolver-hosted content to
preserve user safety.

>
> Now, some more specific feedback:
>
> * In Section 3, " If an HTTP enabled domain name is blocked" (and similar
> language). Domains are not "HTTP enabled" or "HTTPS enabled" -- try
> something like "If the authority of a HTTP URL is blocked."
>

Thanks, fixed.


>
> * In Section 3, "However, this approach is ineffective when DNSSEC is
> deployed given that DNSSEC ensures the integrity and authenticity of DNS
> responses, preventing forged DNS responses from being accepted."  There are
> assumptions about DNSSEC deployment baked into this statement. In practice,
> it has little preventative force.
>

The existing text in Section 3 is intended to describe the behavior when
DNSSEC is deployed, and is agnostic to the actual deployment levels of
DNSSEC globally. It makes no claim about how commonly DNSSEC is used in
practice.


>
> * In Section 4, the c field (contact) is required to be present, and
> required to be a mailto, sips, or tel URI field. Constraining URL schemes
> isn't great practice, even if backed with a registry; what if people want
> to use a web form? Furthermore, requiring operators of all DNS resolvers to
> provide contact information isn't realistic: at any scale it's unreasonable
> to ask them to respond meaningfully. Furthermore, if the block is legally
> motivated, they won't be able to do anything about it. I'd suggest removing
> both the constraint on the URL scheme and the requirement for c to be
> present. Recommending URL schemes is fine.
>

Allowing web forms was explicitly rejected during WG discussions to avoid
introducing risks associated with resolver-controlled content injection
(see discussion
<https://mailarchive.ietf.org/arch/msg/dnsop/fnMrR9UqwEVbY-KvoYna9AvkLaY/>
for more details). The "c" field is critical for transparency; it ensures
that end-users, client software, and administrators have a minimal yet
reliable method to obtain information about why access to a domain was
blocked and to report misclassifications.


>
> * In Section 4, it says: "If the text is provided in a language not known
> to the end-user, the client can use the "l" (language) field to identify
> the language of the text and translate it to the user's preferred
> language." This is not best practice for internationalisation. Better
> approaches might include:
>
> 1) Given that the draft already has a negotiation mechanism (Section 5.1),
> the client could state its preferred language(s) in the request.
>

The current client signaling only requests structured DNS errors; it does
not include language preferences to keep the proposed mechanism
interoperable with existing EDE handling.


>
> 2) Don't allow user-visible text in the record at all, but instead convey
> a URL which when resolved is negotiated for language. This would also help
> reduce message sizes.
>

Allowing user-facing URLs was rejected by the WG to prevent
resolver-controlled content injection risks; it was agreed in the WG that
structured errors must be self-contained


>
> * Throughout - the purpose of having sub error codes is never explained in
> the draft; it might be inferred from the defined codes, but it really
> should be explicit.
>

Thanks, we will update the draft.

Cheers,
-Tiru


> Cheers,
>
>
> > On 15 Apr 2025, at 1:18 am, The IESG <[e-mail]> wrote:
> >
> >
> > The IESG has received a request from the Domain Name System Operations WG
> > (dnsop) to consider the following document: - 'Structured Error Data for
> > Filtered DNS'
> >  <draft-ietf-dnsop-structured-dns-error-12.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> final
> > comments on this action. Please send substantive comments to the
> > [e-mail] mailing lists by 2025-04-28. Exceptionally, comments
> may
> > be sent to [e-mail] instead. In either case, please retain the
> beginning
> > of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >   DNS filtering is widely deployed for various reasons, including
> >   network security.  However, filtered DNS responses lack structured
> >   information for end users to understand the reason for the filtering.
> >   Existing mechanisms to provide explanatory details to end users cause
> >   harm especially if the blocked DNS response is for HTTPS resources.
> >
> >   This document updates RFC 8914 by signaling client support for
> >   structuring the EXTRA-TEXT field of the Extended DNS Error to provide
> >   details on the DNS filtering.  Such details can be parsed by the
> >   client and displayed, logged, or used for other purposes.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> >
> > _______________________________________________
> > IETF-Announce mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>