Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

DNS Embedded Answers
draft-wobbly-dispatch-embedded-answers-00

Versions:

This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process.

Document	Type	Active Internet-Draft (individual)
	Authors	Warren Kumari , Joe Abley
	Last updated	2026-10-30
	RFC stream	(None)
	Intended RFC status	(None)
	Formats	txt html xml htmlized bibtex bibxml
Stream	Stream state	(No stream defined)
	Consensus boilerplate	Unknown
	RFC Editor Note	(None)
IESG	IESG state	I-D Exists
	Telechat date	(None)
	Responsible AD	(None)
	Send notices to	(None)

Email authors IPR References Referenced by Nits Nits v3 Search email archive

draft-wobbly-dispatch-embedded-answers-00

WG Working Group W. Kumari
Internet-Draft Google, Inc.
Intended status: Informational J. Abley
Expires: 3 May 2027 Cloudflare
30 October 2026

DNS Embedded Answers
draft-wobbly-dispatch-embedded-answers-00

Abstract

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

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Kumari & Abley Expires 3 May 2027 [Page 1]
Internet-Draft DAE October 2026

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.

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . 4
4. Trust Models . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. DNSSEC-validated answers . . . . . . . . . . . . . . . . 5
4.2. Optimization-only hints . . . . . . . . . . . . . . . . . 5
4.3. Same-origin or same-operator assumptions . . . . . . . . 5
5. Embedding Mechanisms . . . . . . . . . . . . . . . . . . . . 6
5.1. HTML embedding . . . . . . . . . . . . . . . . . . . . . 6
5.2. HTTP headers . . . . . . . . . . . . . . . . . . . . . . 7
5.3. QUIC and HTTP/3 transport mechanisms . . . . . . . . . . 7
6. Address Selection and Operational Considerations . . . . . . 7
7. Discussion Items . . . . . . . . . . . . . . . . . . . . . . 8
7.1. What is the appropriate trust boundary? . . . . . . . . . 8
7.2. What restrictions are necessary for cross-origin use? . . 9
7.3. How should freshness be managed? . . . . . . . . . . . . 9
7.4. What is the right balance between privacy and
performance? . . . . . . . . . . . . . . . . . . . . . . 9
8. Security and Privacy Considerations . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10

Kumari & Abley Expires 3 May 2027 [Page 2]
Internet-Draft DAE October 2026

10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A - DNSSEC Example . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12

1. 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.

Kumari & Abley Expires 3 May 2027 [Page 3]
Internet-Draft DAE October 2026

2. 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 [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.

3. 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.

4. 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.

Kumari & Abley Expires 3 May 2027 [Page 4]
Internet-Draft DAE October 2026

4.1. 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.

4.2. 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 ([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.

4.3. 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

Kumari & Abley Expires 3 May 2027 [Page 5]
Internet-Draft DAE October 2026

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.

5. 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.

5.1. 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:

<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.

Kumari & Abley Expires 3 May 2027 [Page 6]
Internet-Draft DAE October 2026

5.2. 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:

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.

5.3. 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.

6. 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;

Kumari & Abley Expires 3 May 2027 [Page 7]
Internet-Draft DAE October 2026

* 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.

7. 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.

7.1. 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.

Kumari & Abley Expires 3 May 2027 [Page 8]
Internet-Draft DAE October 2026

7.2. 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.

7.3. 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.

7.4. 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 :-)

8. 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;

Kumari & Abley Expires 3 May 2027 [Page 9]
Internet-Draft DAE October 2026

* 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.

9. IANA Considerations

This document has no IANA actions.

10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/rfc/rfc4034>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9102] Dukhovni, V., Huque, S., Toorop, W., Wouters, P., and M.
Shore, "TLS DNSSEC Chain Extension", RFC 9102,
DOI 10.17487/RFC9102, August 2021,
<https://www.rfc-editor.org/rfc/rfc9102>.

10.2. Informative References

Kumari & Abley Expires 3 May 2027 [Page 10]
Internet-Draft DAE October 2026

[I-D.ietf-happy-happyeyeballs-v3]
Pauly, T., Schinazi, D., Jaju, N., and K. Ishibashi,
"Happy Eyeballs Version 3: Better Connectivity Using
Concurrency", Work in Progress, Internet-Draft, draft-
ietf-happy-happyeyeballs-v3-04, 1 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-happy-
happyeyeballs-v3-04>.

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.

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==)

Kumari & Abley Expires 3 May 2027 [Page 11]
Internet-Draft DAE October 2026

This example is stolen from [RFC9102], Section 4.1, and lightly
edited for brevity.

Authors' Addresses

Warren Kumari
Google, Inc.
Email: warren@kumari.net

Joe Abley
Cloudflare
Email: jabley@cloudflare.com

Kumari & Abley Expires 3 May 2027 [Page 12]

DNS Embedded Answers draft-wobbly-dispatch-embedded-answers-00

DNS Embedded Answers
draft-wobbly-dispatch-embedded-answers-00