Apologies for being late responding to the WGLC.
I (still) don't think this draft is a good idea. Reading -18 (quickly) just now I don't see any statement along the lines the a client MUST NOT initiate connections based on the content returned, which I think means this mechanism could provide a way to automatically, and at scale, report to "the authorities" that a query for the relevant DNS name was made, and from where. That could happen if: - a client parsing the JSON initiates a connection to any IP address derived from the response content - some client libraries might automatically do that if presented with strings that are to be interpreted as URIs - a change to the registry in 11.3 adding https would seem to make this much more likely as some clients would probably access the URL to offer a preview of the content or to pre-load the content I'd also worry that clients might anyway ignore the MUST that only sips/tel/mailto are to be supported for now. I note that clients can easily be induced to make such DNS queries via e.g. adverts or email content (if the text/html body part is rendered), so such connections could also be part of a DoS reflection attack, or used to "frame" a client. Overall, this just seems to much of a dangerous implement to me. Cheers, S. On 27/02/2026 12:26, Benno Overeinder via Datatracker wrote:
This message starts a WG Last Call for:
draft-ietf-dnsop-structured-dns-error-17
This Working Group Last Call ends on 2026-03-13
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.
File can be retrieved from:
Please review and indicate your support or objection to proceed with the
publication of this document by replying to this email keeping [email protected]
in copy. Objections should be explained and suggestions to resolve them are
highly appreciated.
Authors, and WG participants in general, are reminded of the Intellectual
Property Rights (IPR) disclosure obligations described in BCP 79 [1].
Appropriate IPR disclosures required for full conformance with the provisions
of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR Policy can be
found at [3].
Thank you.
[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-17.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-structured-dns-error-17
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
