[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]>]

On Sat, 3 May 2025 at 04:04, Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 14/04/2025 16:18, The IESG 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.
>
> Apologies for being a few days late.
>
> My top level input is that this should be sent back to the WG with
> a recommendation to chat more with some apps folks (not just for the
> web, but mail, calendaring etc too) before trying again, if trying
> again still seems like a plan.
>
> Details:
>
> - abstract: "filtered DNS responses lack structured information for end
>    users to understand" - end users do not know the DNS exists; expecting
>    them to understand DNS errors, outside of the context of whatever
>    application has made the DNS query, will IMO be unproductive
>

The structured error information defined in this document is not intended
to be consumed directly by end users. Instead, 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
<https://github.com/AdguardTeam/dns-sde-extension>, which demonstrates how
structured DNS error reporting can enhance transparency and improve
end-user communication.


>
> - I'm generally unkeen on helping censors, and while I recognise that
>    doing so is not the intent, it will be (at least) a side-effect, in
>    this case without even the cutesey/ironic 451 reference. On balance
>    I think (but not strongly) we've done enough to make filtering and
>    censorship explicit so don't need this.
>

The primary intent of this draft is not to aid censorship, but to provide
diagnostic clarity in diverse deployment environments.


>
> - Adding expectations of support for a variant of JSON seems optimistic.
>    That said I don't know how well supported that I-JSON variant may be
>    but I'd not expect anyone to go out of their way if they have some
>    JSON support but not quite that.
>

It builds on RFC 8427, "Representing DNS Messages in JSON", which already
defines a JSON-based schema for DNS message representation.


>
> - If a censor (in some authoritarian locale) includes a contact and a
>    person gets in touch with that, or their user agent decides to do
>    that, there could be negative consequences for the person. (That
>    field seems somewhat like "if you're unhappy with our censoring you
>    when you tried to get at something you ought not have wanted, please
>    feel free to call into secret-police-HQ and we'll happily deal with
>    your query" - not an attractive invitation.) And the 'contact' field
>    is mandatory. Seems a bad plan to me.


> - I agree with other comments to the effect that de-ref'ing the contact
>    is asking for e.g. malware trouble.
>

The "c" field is mandatory to be conveyed in the structured error payload,
but it is not intended to be displayed to the end user by default. As
discussed in the Security Considerations section, clients are expected to
apply restrictions on whether this information is revealed or not.


>
> - 11.3/11.4 seem wrong - "blocked by" is not an error when the blocking
>    is deliberate - I think that indicates something is fundamentally
>    wrong with this specification.
>

The rationale for introducing the new "Blocked by Upstream DNS Server" EDE
is to differentiate between filtering performed by local devices (e.g.,
home routers or enterprise gateways) and filtering enforced by upstream
recursive resolvers. It still represents a failure to resolve from the
client's perspective and requires a distinct diagnostic signal.

Cheers,
-Tiru


>
> Cheers,
> S.
>
>
>
>
>
>
>
>