I like it! Section 8.1 (Cross-Network Tracking) needs some significant changes. The new tracking risk here does not depend on "ipv6hint" as it claims: users could also be tracked by
* a per-user ServiceMode TargetName that resolves to a unique IP address * a per-user ECHConfig * a per-user SvcPriority "knocking" sequence on servers that respond "TCP RST". * potentially via other SvcParams as well (e.g. "port") The comparisons (8.1.1) are confusing, verbose, somewhat inaccurate, and largely irrelevant. I would omit them. The proposed mitigations (8.1.2) are also highly problematic, in my view. The first and third assume that the problem is limited to IP addresses, and the second is not a privacy mitigation at all. Instead, I believe the correct mitigation is for the system stub DNS resolver to ignore this flag and continue partitioning its cache as usual. The application must decide how to manage the lifetime of the record. Applications SHOULD bind the SVCB record to their identity lifetime/scope, like HTTP cookies and TLS session tickets. If the goal is to offer a high-level API, then this API needs an input to identify "user sessions" or expose a "privacy reset" operation. This section also misses another category of privacy issues: identity "leakage". This occurs when the client consents to being "tracked" by the server, but together they accidentally leak a linkable identifier to a third party. For example, a simple load balancer that inserts a random server host in each response could leak some tracking entropy for each user. The Privacy Considerations should warn about this possibility and make some recommendations (mostly to server operators) about how to avoid it. This is related to operational recommendations about what kinds of server deployments are most likely to benefit from this flag. --Ben Schwartz On Sat, Jul 11, 2026 at 9:16 AM Eric Kinnear <[email protected]> wrote: > > Hi dnsop, We’ve submitted the below draft as a way to opt-in to a particular > SVCB/HTTPS record being “globally relevant” across networks, somewhat similar > to the “persistent” flag in Alt-Svc. This came out of some discussion we were > having that > > Hi dnsop, > > We’ve submitted the below draft as a way to opt-in to a particular SVCB/HTTPS > record being “globally relevant” across networks, somewhat similar to the > “persistent” flag in Alt-Svc. > > This came out of some discussion we were having that cross-network behaviors > really need to be explicitly opt-in. > > I would expect this approach is especially useful for deployments using > things like Anycast. > > As always, there are quite a few caveats and situations where on some > networks a client may prefer not to reuse answers from a different network > and deployments where this wouldn’t apply. > > Suggestions and feedback are most welcome, via email or issues on the GitHub > repository. > > Thanks, > Eric > > > Begin forwarded message: > > From: [email protected] > Date: July 6, 2026 at 9:57:14 PM GMT+2 > To: Eric Kinnear <[email protected]>, Ian Swett <[email protected]>, Nidhi > Jaju <[email protected]> > Subject: New Version Notification for > draft-kinnear-dnsop-globally-relevant-00.txt > > A new version of Internet-Draft draft-kinnear-dnsop-globally-relevant-00.txt > has been successfully submitted by Eric Kinnear and posted to the > IETF repository. > > Name: draft-kinnear-dnsop-globally-relevant > Revision: 00 > Title: Globally Relevant HTTPS RRs > Date: 2026-07-06 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/archive/id/draft-kinnear-dnsop-globally-relevant-00.txt > Status: > https://datatracker.ietf.org/doc/draft-kinnear-dnsop-globally-relevant/ > HTML: > https://www.ietf.org/archive/id/draft-kinnear-dnsop-globally-relevant-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-kinnear-dnsop-globally-relevant > > > Abstract: > > DNS answers for SVCB and HTTPS resource records are typically treated > as scoped to the network on which they were obtained. This requires > clients to re-resolve DNS when changing network attachments, adding > latency to connection establishment. This document defines a new > SvcParamKey, "globally-relevant", for use in SVCB and HTTPS DNS > resource records as defined in [RFC9460]. When present, this boolean > flag indicates that the service binding parameters in the record are > valid regardless of the client's network attachment point. Clients > that observe this flag can reuse cached SVCB and HTTPS records across > network changes, subject to normal TTL expiry. > > > > The IETF Secretariat > > > _______________________________________________ > 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]
