]> Google, Inc.

warren@kumari.net

Cloudflare

jabley@cloudflare.com

AREA WG Working Group address resolution dns performance Many web interactions require a client to resolve a hostname before it can establish a connection to a service. While DNS is generally efficient, each lookup incurs some delay and exposes information about the user's browsing activity to the recursive resolver and upstream infrastructure. This document explores techniques by which a client may receive DNS-derived address data as part of an application-layer response, so that it can initiate a connection without performing a separate DNS lookup for the same target. The mechanisms discussed here are intended to reduce lookup latency and potentially improve privacy, but they also raise significant questions about trust, freshness, and security. The document does not prescribe a single normative mechanism; instead, it describes several design options and the trade-offs associated with each. 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 The vast majority of web interactions begin with a hostname resolution step. A browser that needs to fetch an image from images.example.com or follow a link to www.example.net typically performs one or more DNS lookups before opening a connection. Even when a resolver cache produces a fast answer, the lookup can still impose measurable latency and can reveal information about the user's activities to the resolver and any intermediaries on the path. This document discusses a class of mechanisms in which the client receives address information as part of an existing application-layer exchange, rather than by performing a separate DNS lookup. Such information could be embedded in HTML, carried in HTTP metadata, or delivered through a protocol mechanism such as HTTP/3 or QUIC. The goal is to allow the client to establish a connection more quickly, and, in certain situations, can also avoid exposing the lookup itself to the DNS infrastructure. This document is intentionally exploratory. It presents a number of possible ways to embed address information, along with several trust models that a client might apply when deciding whether to use such information. The design space is broad, and the trade-offs are substantial. Consider a page at https://www.example.com/kittens.html that includes an image served from https://images.example.com/kittens.png and a link to https://www.example.net/bunnies.html. To fetch the image, the browser must resolve images.example.com. To follow the link, it must resolve www.example.net. Both operations take time and reveal that the user is accessing those resources. Prefetching and speculative connection setup can reduce the delay, but they do not eliminate it and they do not necessarily remove the privacy implications of host resolution. If the origin or a trusted intermediary were able to provide the relevant address information in the response itself, the client could potentially avoid a separate lookup or begin connection setup earlier. This could improve the user experience while reducing exposure of the requested hostnames to third parties.

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. This document uses the term "embedded answer" to refer to an application-layer value that conveys one or more network addresses associated with a hostname. The term is intentionally generic: it does not assume a specific format or a single authority model. The term "optimization hint" refers to a value that may improve connection setup latency, but is not necessarily authoritative. The term "authenticated answer" refers to a value that the client has reason to treat as equivalent to an answer obtained through DNS validation or other cryptographic means.

Goals and Non-Goals The goals of the techniques discussed here are to:

• reduce the latency incurred by hostname resolution;
• allow a client to begin connection setup earlier; and
• reduce the amount of hostname information exposed to the DNS path.

These techniques are not limited to a single transport or a single application protocol. However, the examples in this document focus on web content and connection establishment. The non-goals include:

• replacing DNS as the primary name resolution system;
• guaranteeing that embedded answers are universally trusted; or
• defining a single protocol mechanism without further discussion and deployment experience.

Trust Models A central question is why a client would trust an embedded answer. This section outlines several possible trust models, each with different security and operational properties.

DNSSEC-validated answers The strongest model is one in which the embedded answer is cryptographically bound to the originating DNS zone. For example, a response could include the relevant RRset, along with the necessary DNSSEC validation material, and the client could verify the answer using the DNSSEC chain. If the validation succeeds, the answer is equivalent to an authenticated DNS answer. This model has the advantage that it aligns closely with the existing security properties of DNS. It does, however, require that the relevant zone be DNSSEC signed and that the client and the embedding entity support the necessary validation steps.

Optimization-only hints A second model is to treat the embedded answer as an optimization hint rather than as authoritative data. In such a model, the client may use the address to begin connection setup or perform connection racing ()while waiting for DNS to confirm or refute the advertised address. In this design, the client does not necessarily consider the embedded answer to be trusted until it has been validated by a conventional DNS resolution or by another trusted mechanism. The benefit is that the client can exploit the embedded data to reduce connection setup latency without accepting the risk of blindly trusting it. This would allow the client to perform the transport connection, and TLS handshake, but it would not send any user data until the address has been validated. This model may be useful when the embedded answer is generated by a local infrastructure component that is in a position to estimate the best endpoint, but it still preserves a fallback path to DNS-driven verification.

Same-origin or same-operator assumptions A third model is to treat addresses associated with a related hostname as safe to use within a constrained trust boundary, such as a site or an organization. For example, a page at www.example.com might be allowed to carry an embedded answer for images.example.com if the hostnames are controlled by the same party and the client applies explicit restrictions. This model is attractive because it aligns with common web deployment patterns, but it is also more dangerous. It depends on an operational assumption that is not necessarily true even when the hostnames share a registrable domain. The client must define restrictions such as whether the value may be used only for read operations, only for a limited set of protocols, or only for a specific origin relation. It must also consider the possibility that a page can cause a client to connect to destinations that are not obviously related to the origin. The precise boundaries for "same-origin" and "same-operator" are not obvious, and this remains a topic for further discussion.

Embedding Mechanisms This document discusses several possible ways to deliver embedded answers. The purpose of this section is to illustrate the design space, not to mandate a single mechanism.

HTML embedding {Ed note: This is primarily documented to illustrate the concept and is not necessarily intended for production use, other than perhaps as initial testing.} A straightforward design is to embed the address information directly in HTML. For example, the page at https://www.example.com/kittens could include attributes on elements that indicate the network target for a given resource: Bunnies! Yay, bunnies! ]]> This mechanism is simple to understand and easy to prototype. It has the advantage that the page author or generation system controls the information that is embedded. It also has obvious drawbacks: the information may become stale, the browser must interpret a potentially large number of address hints, and the page author could embed values that are not aligned with the current DNS or the client's network conditions. The approach is useful for experiments, but it is not likely to be the final preferred mechanism for general deployment unless the format is carefully specified and tightly constrained.

HTTP headers A more structured design is to carry address information in an HTTP header. This would allow the server, edge cache, or CDN to provide a set of answer hints that are relevant to the response being served: This mechanism is architecturally cleaner than embedding data directly in HTML. The server is already in control of the response, and in many deployments it has valuable context about origin topology, load, and client affinity. In some cases, the same server or CDN is responsible for both the referencing page and the target resource, which makes it easier to select an appropriate endpoint. The drawback is that the server becomes responsible for resolving and selecting addresses. This introduces incentives and operational trade-offs. For example, a CDN that fronts multiple origins might prefer a local address or a preferred peer network in order to retain traffic, potentially at the expense of the client's optimal path. This is not necessarily an error in the protocol design, but it is a substantial deployment consideration.

QUIC and HTTP/3 transport mechanisms A protocol-native mechanism could allow the client to receive address hints as part of an HTTP/3 or QUIC exchange. Such a mechanism might be integrated into the transport context, a response header, or an extension-specific metadata field. This approach may be more efficient in environments where the transport and applications are tightly coupled, but it requires a specific protocol design and a clear trust model. This document does not attempt to define such a format in detail. It only notes that transport-specific mechanisms are likely to offer efficiency advantages, particularly when the client can apply the embedded data in a way that is consistent with the underlying connection establishment logic.

Address Selection and Operational Considerations Before an answer can be embedded in a response, the entity generating the response must determine what address information to provide. In many cases, the correct answer depends on factors such as:

• the client's local network conditions;
• the target service's current load and endpoint set;
• the transport and policy of the origin or CDN; and
• the service's DNS configuration and load-balancing behavior.

For example, a CDN serving multiple customers may have different optimal endpoints for the same hostname depending on the client network, the edge location, and the active service topology. A server that resolves a name in one geographic region may produce an answer that is excellent for Toronto clients but poor for clients in Sydney. This creates several operational tensions:

1. Resolution frequency: resolving names too often increases server-side load, while resolving too infrequently leads to stale answers and reduced effectiveness.
2. TTL semantics: the lifetime of the answer matters. A stale or overly broad answer might be counterproductive.
3. Client heterogeneity: different clients may have distinct optimal destinations for the same hostname, which complicates any attempt to generate a single answer for all clients.

The design implications are therefore not purely protocol-level. They depend on operator practices, client policies, and the operational realities of modern CDN and edge infrastructure.

Discussion Items This document is intentionally exploratory, and the authors invite feedback on a number of design questions. The purpose of this section is to highlight the areas where the concept is still under discussion and where further experience would be valuable.

What is the appropriate trust boundary? A key question is whether a client should treat embedded answers as cryptographically authenticated, as a best-effort optimization hint, or as an origin-local mechanism with explicit restrictions. The appropriate answer may depend on the embedding mechanism, the application context, and the client's security policy.

What restrictions are necessary for cross-origin use? A mechanism that carries address hints across origins introduces a question of scope: should such hints be usable only for a single origin, only for related hostnames, or only for restricted classes of requests? This question is closely related to the broader web-security discussion of site, origin, and delegated authority.

How should freshness be managed? Embedded addresses may become stale, either because the underlying endpoint set changes or because the client receives an answer that was generated under older conditions. The document does not yet specify how a client should bound the lifetime of such an answer or how a server should determine when to refresh it.

What is the right balance between privacy and performance? The concept is intended to reduce DNS exposure and improve latency, but we need to ensure that it does not introduce new privacy or tracking risks. An initial concern is whether embedded addresses, especially IPv6 addresses, could be used to correlate client activity across different contexts or origins. As far as the authors have been able to work out, an entity that is in a position to create unique embedded addresses for different clients, and then correlate those across those servers is already in a postion to track clients, even without the use of embedded addresses. This suggests that the privacy risk introduced by embedded addresses may be limited in practice, but it still requires careful consideration in the design and deployment of the mechanism, especially because we didn't discussed this over coffee and didn't actually document our reasoning :-)

Security and Privacy Considerations This proposal creates a tension between optimization and trust. The same mechanism that reduces DNS lookup latency may also allow a party that controls a response to steer the client toward a chosen address without the client having independently validated that address. The security considerations include:

• stale or incorrect answers;
• traffic steering to a malicious or unintended endpoint;
• downgrade or bypass of DNSSEC validation;
• cross-origin trust assumptions;
• abuse by compromised origins or intermediaries; and
• privacy exposure from embedded data itself.

A client must therefore be conservative about how it uses embedded answers. The safest model is to treat them as equivalent to DNS answers only when they are cryptographically authenticated or otherwise validated according to a defined trust policy. In the absence of such validation, the embedded value should be handled as a hint and used only under constrained conditions. Any design that permits embedded answers to alter a client's network connection must specify the security boundary of that decision. In particular, the draft must clearly explain whether the answer may be used for all requests, only for certain origins, only for read-only traffic, or only in conjunction with a separate DNS validation step.

IANA Considerations This document has no IANA actions.

References Normative References This document describes an experimental TLS extension for the in-band transport of the complete set of records that can be validated by DNSSEC and that are needed to perform DNS-Based Authentication of Named Entities (DANE) of a TLS server. This extension obviates the need to perform separate, out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a denial-of-existence proof that can be validated. This experimental extension is developed outside the IETF and is published here to guide implementation of the extension and to ensure interoperability among implementations. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] 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 Apple Inc Google LLC Google LLC Google LLC Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document defines the algorithm for "Happy Eyeballs", a technique for reducing user-visible delays on dual-stack hosts. This document updates the algorithm in RFC 8305.

Acknowledgments The authors would like to thank the following individuals for their feedback and suggestions: Mike Bishop, Lorenzo Colitti, Roman Danyliw, Geoff Huston, Suresh Krishnan, Mark Nottingham, Erik Nygren, Adam Roach, David Schinazi, Ian Swett. This work was informed by discussion on the "Resolverless DNS" mailing list and other places, and we would like to acknowledge the contributions of many individuals who have participated in these discussions over the years. Unfortunately, at least one of the authors has a terrible memory, and has lost track of all those who have contributed to this topic over the years, and will be more than happy to acknowledge their input if reminded of this :-)

Appendix A - DNSSEC Example The following example illustrates how DNSSEC can be used to validate embedded answers. Note that this is simple for illustrative purposes, and the actual format will change after discussions on the general approach. This is presented in "human-readable layout", but would obviously be transmitted in "single-line wire format". In addition, the format is compressed to minimize the size of the transmitted data to avoid exceeding typical HTTP header size limits. This example is stolen from , Section 4.1, and lightly edited for brevity.