Hi Stephen, Thank you for the review. This is a good catch, we never imagined this could result in automatic connection initiation, but thank you for bringing it up.
That said, the concern is already partially addressed by the draft. Section 5.3 and the Security Considerations define a strict set of checks that must pass before any field is acted upon, including transport security verification, resolver authentication, and client security policy evaluation. Only after all these checks pass is the information displayed to the end-user. The "c" field contains contact URIs that require explicit user interaction to initiate a connection. On the registry expansion concern, the current registry intentionally limits Contact URI schemes to sips, tel, and mailto; schemes that do not result in automatic HTTP connections. Any future addition of https would require IETF Review, providing the appropriate oversight to evaluate exactly the risks you describe. To make these guarantees more explicit, we will add the following text to the Security Considerations: Clients MUST NOT automatically initiate connections to URIs derived from the EXTRA-TEXT field. Doing so could allow a resolver to silently report client activity to third parties at scale, enable DoS reflection attacks, or be used to frame a client. The restriction Contact URI schemes to sips, tel, and mailto is intentional, as these schemes do not result in automatic HTTP connections. Cheers, -Tiru On Thu, 19 Mar 2026 at 19:36, Stephen Farrell <[email protected]> wrote: > > 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] > >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
