| Internet-Draft | DAE | October 2026 |
| Kumari & Abley | Expires 3 May 2027 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://wkumari.github.io/draft-wobbly-dispatch-embedded-address-answers/draft-wobbly-dispatch-embedded-address-answers.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-wobbly-dispatch-embedded-answers/.¶
Source for this draft and an issue tracker can be found at https://github.com/wkumari/draft-wobbly-dispatch-embedded-address-answers.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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 [RFC2119] [RFC8174] 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.¶
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:¶
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.¶
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.¶
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 ([I-D.ietf-happy-happyeyeballs-v3])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.¶
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.¶
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.¶
{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:¶
<img src="https://images.example.com/kittens.png"
address="192.0.2.1" />
<a href="https://www.example.net/bunnies.html"
address="192.0.2.1, 192.0.2.42, 2001:0DB8::42">Bunnies! Yay, bunnies!</a>
¶
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.¶
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:¶
Embedded-Answers: images.example.com=192.0.2.1; www.example.net=192.0.2.1,192.0.2.2¶
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.¶
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.¶
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:¶
Resolution frequency: resolving names too often increases server-side load, while resolving too infrequently leads to stale answers and reduced effectiveness.¶
TTL semantics: the lifetime of the answer matters. A stale or overly broad answer might be counterproductive.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 :-)¶
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.¶
This document has no IANA actions.¶
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 :-)¶
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.¶
Embedded-Answer: www.example.com=192.0.2.1; www.example.com. 3600 IN RRSIG ( A 13 5 3600 20201202000000 20181128000000 1870 example.com. rqY69NnTf4CN3GBGQjKEJCLAMsRkUrXe0JW8IqDb5rQHHzxNqqPeEoi+2vI6Sz2BhaswpGLVVuoijuVdzxYjmw== ); example.com. 3600 IN DNSKEY ( 257 3 13 JnA1XgyJTZz+psWvbrfUWLV6ULqIJyUS2CQdhUH9VK35bslWeJpRzrlxCUs7s/TsSfZMaGWVvlsuieh5nHcXzA== ); example.com. 3600 IN RRSIG ( DNSKEY 13 2 3600 20201202000000 20181128000000 1870 example.com. nYisnu/26Sw1qmGuREa9o/fLgYuA4oNPt4+6PMBZoN0MS8Gjtli9NVRYeSIztQHPGSpvRxTUC4tZi62z1UgGDw== ); example.com. 172800 IN DS ( 1870 13 2 e9b533a049798e900b5c29c90cd25a986e8a44f319ac3cd302bafc08f5b81e16); com. 172800 IN DNSKEY ( 257 3 13 RbkcO+96XZmnp8jYIuM4lryAp3egQjSmBaSoiA7H76Tm0RLHPNPUxlVk+nQ0fIc3I8xfZDNw8Wa0Pe3/g2QA/w== ); com. 172800 IN RRSIG ( DNSKEY 13 1 172800 20201202000000 20181128000000 18931 com. LJ4p5ORS2ViILwTotSlWixElqRXHY5tOdIuHlPWTdBGPMq3y40QNr1V+ZOyA57LFdPKpcvb8BvhM+GqKWGBEsg== ); com. 86400 IN DS ( 18931 13 2 20f7a9db42d0e2042fbbb9f9ea015941202f9eabb94487e658c188e7bcb52115 ); com. 86400 IN RRSIG ( DS 13 1 86400 20201202000000 20181128000000 31918 . nDiDlBjXEE/6AudhC++Hui1ckPcuAnGbjEASNoxA3ZHjlXRzL050UzePko5PbvBKTf6pk8JRCqnfzlo2QY+WXA== ); . 86400 IN DNSKEY ( 256 3 13 zKz+DCWkNA/vuheiVPcGqsH40U84KZAlrMRIyozj9WHzf8PsFp/oR8j8vmjjWP98cbte4d8NvlGLxzbUzo3+FA== ) ; Key ID = 31918; . 86400 IN DNSKEY ( 257 3 13 yvX+VNTUjxZiGvtr060hVbrPV9H6rVusQtF9lIxCFzbZOJxMQBFmbqlc8XclvQ+gDOXnFOTsgs/frMmxyGOtRg== ); . 86400 IN RRSIG ( DNSKEY 13 0 86400 20201202000000 20181128000000 47005 . 0EPW1ca+N ZhZPKla77STG734cTeIOjUwq7eW0HsnOfudWmnCEVeco2wLLq9mnBT1dtNjIczvLG9pQTnOKUsHQ==)¶
This example is stolen from [RFC9102], Section 4.1, and lightly edited for brevity.¶