]> Apple Inc.

ekinnear@apple.com

Google

nidhijaju@google.com

Google

ianswett@google.com

DNS SVCB HTTPS SvcParamKey globally-relevant 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 . 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction When a client changes its network attachment, for example, by switching from one Wi-Fi network to another, transitioning between Wi-Fi and cellular connectivity, or connecting or disconnecting a VPN, current practice requires it to re-resolve DNS records for connections on the new network attachment. This is because DNS answers may be network-specific due to split-horizon DNS deployments, geographic load balancing, or network-level content policies. The re-resolution adds latency to connection establishment after every network transition, delaying the user experience. Many widely-used services, however, serve DNS answers that are identical regardless of which network the query traverses. Their HTTPS and SVCB resource records, including ALPN protocol identifiers, Encrypted ClientHello (ECH) configurations, port numbers, and address hints, are globally consistent. For these services, re-resolving DNS after a network change is unnecessary overhead that delays connection establishment without providing any benefit. This document defines a new SvcParamKey called "globally-relevant" for SVCB and HTTPS resource records . It is a boolean flag with an empty value that authoritative DNS servers set to indicate the record's service binding parameters are valid regardless of network context. Clients observing this flag MAY continue using cached SVCB and HTTPS records after network transitions, avoiding the latency of re-resolution. This mechanism is strictly opt-in. Services that do not include the "globally-relevant" SvcParamKey continue with current behavior, and their records are treated as network-scoped as they are today.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used in this document:

Network attachment change:

A change in the client's network connectivity, such as switching from one Wi-Fi network to another, transitioning between Wi-Fi and cellular connectivity, or connecting or disconnecting a VPN.

Authoritative server:

A DNS server that is authoritative for a zone and generates responses for names in that zone, as defined in .

Recursive resolver:

A DNS resolver that resolves queries on behalf of a client by iteratively querying authoritative servers, as defined in .

Origin server:

The server that terminates the client's transport connection to the service identified by an SVCB or HTTPS resource record. For HTTP-based services, this is the origin server as defined in . The ipv4hint and ipv6hint parameters of an SVCB or HTTPS record are hints for reaching this server.

Operator:

In this document, an entity that runs both the authoritative server for a service's zone and the origin server for that service. Where a single operator holds both roles, it can correlate observations between DNS queries and connections.

The "globally-relevant" SvcParamKey The "globally-relevant" SvcParamKey is a boolean flag parameter for SVCB and HTTPS resource records . Its presence indicates that the authoritative DNS server asserts the service binding parameters in this record are valid regardless of the client's network attachment point.

Wire Format The SvcParamKey number is TBD. The value MUST be empty (length 0), following the same pattern as "no-default-alpn" (SvcParamKey 2) defined in Section 7.1.2 of . If a client receives this SvcParamKey with a non-empty value, the client MUST ignore the parameter.

Presentation Format In DNS zone file presentation format, the key is represented as simply globally-relevant with no value. For example:

Applicability This parameter is applicable to both SVCB (RR type 64) and HTTPS (RR type 65) resource records. It is only meaningful in ServiceMode records (those with SvcPriority greater than 0) that carry service binding parameters. It has no meaning in AliasMode records.

Client Behavior When a client receives an SVCB or HTTPS record containing the "globally-relevant" SvcParamKey, it MAY retain the cached record and continue using its service parameters after a network attachment change. The record's TTL still applies. The "globally-relevant" flag does not extend the record's cache lifetime; it only permits reuse of the cached record across network changes within the remaining TTL window. If a client experiences connection failures when using cached parameters after a network change, it SHOULD re-resolve the record regardless of the "globally-relevant" flag. Clients MAY choose to ignore the "globally-relevant" flag entirely and always re-resolve on network changes. This flag is purely permissive and does not mandate any specific client behavior. When address hints (ipv4hint, ipv6hint) are present in a record carrying the "globally-relevant" flag, the globally-relevant assertion covers those hints as well. Clients MAY use the cached address hints on the new network, though they SHOULD prefer fresh address resolution if readily available and MAY choose to re-resolve in parallel with connection attempts to the cached address hints.

Address Synthesis Across Networks On IPv6-only networks that provide NAT64 connectivity , clients can synthesize IPv6 addresses from IPv4 addresses using the network's NAT64 prefix, discovered via Router Advertisements or DNS-based mechanisms . The "globally-relevant" flag asserts that the addresses in ipv4hint and ipv6hint are globally valid as published by the authoritative server; it does not assert the validity of any locally-synthesized addresses derived from those hints. If a client has synthesized an IPv6 address from an ipv4hint value using one network's NAT64 prefix, it MUST NOT reuse that synthesized address after moving to a different network. Instead, the client MUST re-synthesize using the NAT64 prefix of the new network, if available. The original ipv4hint value itself remains valid and can be used as input to the new synthesis.

Server Behavior An authoritative DNS server SHOULD set the "globally-relevant" SvcParamKey only when the service binding parameters in the record are consistent across all resolvers and network paths. This typically applies to globally-deployed services with uniform configurations. Services that employ split-horizon DNS, geo-dependent load balancing, or network-specific configurations MUST NOT set this flag. The flag asserts that all parameters in the record, including ALPN values, ECH configurations, and port numbers, are globally valid. If any parameter varies by network context, the flag MUST NOT be set. In particular, if the record includes ipv4hint or ipv6hint parameters, the addresses contained in those hints MUST be reachable and correct on all networks, not just the network on which the record was originally resolved. Servers that use address hints to direct clients to network-specific endpoints (e.g., CDN edge nodes selected by resolver location) MUST NOT set the "globally-relevant" flag unless those address hints are valid globally. Operators are strongly suggested to carefully audit their DNS configurations before deploying the "globally-relevant" flag, as incorrect use could cause clients to use inappropriate service parameters after network changes.

Resolver Behavior Recursive resolvers MUST pass the "globally-relevant" SvcParamKey through to clients transparently, without modification. Resolvers MUST NOT add or remove the "globally-relevant" flag. The assertion of global relevance is made by the authoritative server for the zone, and resolvers are not in a position to make or override this determination. Some resolvers modify DNS responses for operational purposes, such as DNS64 synthesis or content filtering. When a resolver synthesizes or rewrites a response, it is effectively acting as the authoritative source for that modified answer. Such synthesized answers SHOULD NOT carry the "globally-relevant" flag, as the resolver cannot assert that its locally-modified response is valid on other networks.

Security Considerations

Incorrect Use If an authoritative server incorrectly sets the "globally-relevant" flag on a record whose parameters vary by network, clients may use inappropriate service configurations after a network change. This could manifest as connection failures or as connections to unintended endpoints if address hints are incorrect for the client's new network. Operators bear responsibility for ensuring the flag is only set on records with truly globally-consistent parameters. Clients MUST NOT reuse cached address hints across network changes for connections that are not authenticated by a security protocol, such as TLS. This allows clients to reject connections established to an address that responds to incoming packets, but no longer represents the desired host.

Network Filtering Some networks apply DNS-based content filtering or access control policies. The "globally-relevant" flag allows clients to skip DNS re-resolution when joining such networks, which means the network's filtered DNS responses would not be applied to cached records. However, this does not meaningfully weaken network-level controls: users can already bypass DNS-level filtering by using alternative resolvers, encrypted DNS, or connecting directly to known IP addresses in some cases. Networks that require effective traffic control already need to enforce policies at layers beyond DNS, such as IP-level or SNI-based firewalling. The "globally-relevant" flag does not change this.

DNSSEC Considerations Where DNSSEC validation is employed, the "globally-relevant" flag does not change validation requirements. Cached records that were validated remain usable as long as the DNSSEC signatures have not expired. Clients performing DNSSEC validation MUST NOT reuse a cached record if the DNSSEC signature has expired, even if the record's TTL has not.

Downgrade and Upgrade Attacks An on-path attacker that can modify DNS responses could strip the "globally-relevant" flag from records, causing clients to re-resolve unnecessarily after network changes. This degrades performance to current behavior but does not otherwise affect security. An on-path attacker could also add the "globally-relevant" flag to a record that the authoritative server did not mark as globally relevant. The impact of this is limited: the client may reuse a record that would otherwise have been re-resolved, which is only problematic if the record was network-specific, and the resulting connection will fail to authenticate the host. DNSSEC also protects against both of these modification attacks, when deployed.

Privacy Considerations

Cross-Network Client Tracking via Unique Addresses The "globally-relevant" flag permits a client to use cached ipv6hint (or ipv4hint) addresses across network attachment changes. An operator that wishes to track a specific client across networks could exploit this by having its authoritative server return a per-client unique address, for example by encoding a client identifier in some of the bits of an IPv6 address, and then observing the resulting connections at its origin server from multiple networks. Because the client reuses the cached address after a network change, the operator observes the same unique address connecting to its origin server from a different network and links a single client identity to both networks. Without "globally-relevant", the client would re-resolve on the new network, and the authoritative server would issue a fresh unique address for that resolution. The operator would have no DNS-derived signal linking the resolutions as the same client, and the connections arriving at the origin server would carry different addresses, offering no linkage there either. The cross-network linkage exists in this design only because the unique address itself acts as a stable identifier that the client carries across networks instead of being replaced at each resolution. recognizes a related class of attack in which a user is "re-identified via DNS queries... regardless of the location from which the user makes those queries", based on query-pattern correlation across time. The cross-network linkage described in this section achieves the same result through a different mechanism: rather than correlating recurring query patterns observed by a passive watcher, an operator actively seeds a chosen identifier into the response returned by its authoritative server and recognizes it when the client connects to the resulting address at the origin server.

Comparison to Existing Tracking Vectors

Recursive Resolvers and Anonymity Sets An authoritative server that returns a per-client unique answer today already observes that answer being requested by a specific recursive resolver. For clients using a shared public or ISP recursive resolver, the authoritative server sees the recursive resolver's address, and the client is part of an anonymity set composed of that recursive resolver's other users (see ). The set's size depends on the deployment (see for definitions of anonymity sets). This "hiding" by the recursive resolver is incomplete where the EDNS Client Subnet (ECS) option is used. notes that with ECS, the authoritative name server "sees the original IP address (or prefix, depending on the setup)" rather than only the recursive resolver's address. An authoritative server returning a per-client unique answer can therefore correlate that answer with the client's subnet on each fresh resolution, providing some cross-network correlation even without the "globally-relevant" flag. Without the "globally-relevant" flag, the authoritative server's view is partitioned by recursive resolver: it sees one anonymity set per recursive resolver, and a single client moving between networks that use different recursive resolvers appears as independent observations from disjoint sets. Caching at each recursive resolver further limits how often the authoritative server is queried at all. The "globally-relevant" flag allows the operator to join observations that would otherwise have been separated by recursive resolver boundaries, effectively intersecting the per-recursive-resolver anonymity sets and shrinking the set in which any one client is hidden (see ).

AliasMode and CNAME Targets A similar tracking primitive is already available without the "globally-relevant" flag. Authoritative servers can return per-client unique CNAME targets, SVCB AliasMode targets (), or other names that function as client identifiers. However, the "globally-relevant" attack described here is harder to mount than these similar attacks, since a unique IPv4 or IPv6 address used as an ipv4hint or ipv6hint value must actually be routable to the operator's origin server from every network the client uses, whereas a unique CNAME or AliasMode target is merely a label that the client subsequently resolves through its local recursive resolver, ultimately pointing at a shared address that the operator already serves. The label-based approach therefore costs the operator only a DNS record per identifier, while the address-based approach costs an IP address per identifier and the routing infrastructure to receive traffic on each. An arbitrarily long CNAME (or DNAME-induced CNAME) chain reintroduces the same tracking capability, because the final A or AAAA record in the chain can encode a per-client identifier in either its name or its address, and clients caching across networks would carry the chain's terminal answer with them. and do not normatively limit CNAME chain length, and explicitly notes that "fairly lengthy valid chains" may occur. SVCB itself requires clients and recursive resolvers to cap AliasMode chains at some implementation-chosen depth (), but that cap applies only to SVCB aliases, not to CNAME redirections. Implementations can bound CNAME chain following for resource reasons, but the limit is not interoperable. Defending against attacks using CNAME chains is out-of-scope for this document, but implementations of "globally-relevant" SHOULD generally apply the same cross-network caching policy to all elements of an alias chain consistently, reusing either all records in the chain after a network change or none, to avoid creating partial-reuse states that have privacy properties differing from either endpoint of the chain.

Encrypted DNS and ODoH Encrypted transports such as DNS-over-TLS , DNS-over-HTTPS , and Oblivious DNS-over-HTTPS protect the DNS query against on-path observers but do not prevent an authoritative server from returning a per-client unique answer. notes that "use of encrypted transports does not reduce the data available in the recursive resolver". ODoH in particular hides the client's IP address from the recursive resolver (the "Target" in ) and the query contents from the proxy, but its threat model treats the authoritative server returning unique records per-client as out of scope. A Target or any downstream authoritative server "could return a DNS answer corresponding to an entity it controls and then observe the subsequent connection from a Client" (see ). The "globally-relevant" flag does not change this on a single network, but it does extend the same attack surface across networks, subject to the constraints described above.

Client Mitigations Clients implementing this specification SHOULD apply the following mitigations to limit the cross-network tracking risk:

• Treat ipv4hint and ipv6hint values that appear unlikely to be shared with many other clients as candidates for re-resolution after a network change, even when the "globally-relevant" flag is present. Examples include addresses outside well-known anycast ranges, addresses that appear unique to a single client, and addresses with high entropy in the host bits.
• When re-resolving a globally-relevant record on a new network in the background (for example, to refresh before TTL expiry), if the new network blocks or refuses the resolution, stop using the cached record rather than continuing to connect to the previously cached address. A failed refresh on a network that otherwise resolves DNS is a signal that the cached parameters may not be appropriate for the new network, regardless of the flag.
• Apply existing privacy protections for address hints uniformly to globally-relevant records, including the requirement in that cached address hints not be reused across network changes for connections that are not authenticated by a security protocol such as TLS.

IANA Considerations This document requests IANA to register the following entry in the "Service Parameter Keys (SvcParamKeys)" registry :

Number	Name	Meaning	Change Controller	Reference
TBD	globally-relevant	Record is valid across network changes	IETF	(this document)

References Normative References This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts. This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK] This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK] This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers. This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation.

Acknowledgments TODO acknowledge.