On Sat, 3 May 2025 at 04:04, Stephen Farrell <stephen.farrell@xxxxxxxxx> 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
> last-call@xxxxxxxx mailing lists by 2025-04-28. Exceptionally, comments may
> be sent to iesg@xxxxxxxx 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, 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.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
