Synchronizing caches of DNS resolvers
draft-bortzmeyer-dnsop-poisonlicious-05
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 | Stéphane Bortzmeyer , Willem Toorop , Babak Farrokhi , Moin Rahman , Ondřej Surý , Otto Moerbeek | ||
| Last updated | 2026-08-04 | ||
| Replaces | draft-bortzmeyer-poisonlicious | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| 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) |
draft-bortzmeyer-dnsop-poisonlicious-05
Internet Engineering Task Force S. Bortzmeyer
Internet-Draft Afnic
Intended status: Experimental W. Toorop
Expires: 4 February 2027 NLnet Labs
B. Farrokhi
Quad9
M. Rahman
The FreeBSD Foundation
O. Surý
Internet Systems Consortium
O. Moerbeek
PowerDNS
3 August 2026
Synchronizing caches of DNS resolvers
draft-bortzmeyer-dnsop-poisonlicious-05
Abstract
Networks of cooperating and mutually trusting DNS resolvers could
benefit from cache sharing, where one resolver would distribute the
result of a resolution to other resolvers. This document
standardizes a protocol to do so.
Status of This Memo
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 4 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bortzmeyer, et al. Expires 4 February 2027 [Page 1]
Internet-Draft Poisonlicious August 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. The protocol . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
6. Operational Considerations . . . . . . . . . . . . . . . . . 5
7. Related and future work . . . . . . . . . . . . . . . . . . . 5
7.1. Related work . . . . . . . . . . . . . . . . . . . . . . 5
7.2. Future work . . . . . . . . . . . . . . . . . . . . . . . 5
7.2.1. Actual measurement . . . . . . . . . . . . . . . . . 6
7.2.2. Negative answers . . . . . . . . . . . . . . . . . . 6
7.2.3. ECS . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.2.4. Authentication . . . . . . . . . . . . . . . . . . . 6
7.2.5. Dispatching of messages . . . . . . . . . . . . . . . 6
7.2.6. Transport of messages . . . . . . . . . . . . . . . . 6
7.2.7. Packing of messages . . . . . . . . . . . . . . . . . 7
7.2.8. Different responses . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
When an organisation operates a big network of DNS resolvers
[RFC1034] [RFC1035], for instance for an important public resolver
(Section 6 of [RFC9499]), it may be a performance improvement to
distribute the result of the resolution process between the
resolvers. The same applies to resolvers operated by distinct
organisations which have agreed to cooperate. This document
standardizes how to do so, using unicast messages to a set of pre-
configured peers.
Bortzmeyer, et al. Expires 4 February 2027 [Page 2]
Internet-Draft Poisonlicious August 2026
1.1. Requirements Language
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.
1.2. Terminology
Network of resolvers
A set of mutually trusting resolvers working together under a
common policy, often but not necessarily under the same
administration
Peer (or peer resolver)
One of the other resolvers in the network
Originating resolver
A resolver sending data to its peers in the network
Receiving resolver (or receiving peer)
A resolver receiving data from one of its peers in the network
Resolver
As used in Section 6 of [RFC9499]
2. The protocol
When completing a successful DNS resolution, the resolver transmits a
DNS message (with the Q/R bit set, since it is a response) to the
pre-configured peers. No acknowledgment is sent or expected. To
save work, the resolver MAY send the data only if the TTL is higher
than some predefined value.
TSIG [RFC8945] is mandatory to implement but optional to use,
following Section 7 of [RFC3365]. Implementations MUST support it,
so that peers always have one authentication mechanism in common.
Whether a given network of resolvers enables it is outside of the
scope of this document.
The resolver MUST send only data that it is sure of (for instance by
DNSSEC validation or because it came with the AA bit from the queried
server). All the resolvers of the network MUST agree on the same
policy for this assessment. When they are not under the same
administration, this policy MUST be agreed explicitly before
deployment, since it cannot be inferred from a shared administrative
practice.
Bortzmeyer, et al. Expires 4 February 2027 [Page 3]
Internet-Draft Poisonlicious August 2026
Negative answers ([RFC9499], section 3) MUST NOT be transmitted to
peers.
A message of this protocol is a response signed like a query. Since
there is no request MAC (Section 4.3.1 of [RFC8945]), the MAC MUST be
computed over the digest components listed for a request in
Section 5.1 of [RFC8945]. This distinguishes it from an ordinary DNS
response. The TSIG key SHOULD nevertheless be specific to this
protocol. Peers that do not use TSIG need another discriminator, for
instance a dedicated port.
This message MUST be a new message (not the message received by the
resolver from the authoritative name servers) with data composed from
data already obtained and validated by the originating resolver. It
MUST contain an Answer section and MAY contain other sections. (So,
the Question section is not mandatory.)
The EDNS section MUST be a new one, created to fit the needs of
successful transmission to the peer.
Each peer then MAY store the data in its cache. The peer is not
supposed to do DNSSEC validation (there is not always all the
necessary data in the message). After all, the goal is to save work
for the peers, so Section 5.4.1 of [RFC2181] does not apply here.
(Remember all peers trust each other, and have a consistent policy.
The data is as trustworthy as if you validated it yourself.) A
resolver which cannot rely on its peers applying the agreed policy
MUST NOT accept their data. The receiver MAY cache only what is in
the Answer section.
3. IANA Considerations
None. [RFC-Editor: you may delete this section]
4. Security Considerations
The integrity and authenticity of the cached data is of course
critical. DNSSEC would help but it is not yet universally deployed
and, moreover, the peer resolvers should not have to redo the
validation. So, trust between the peer resolvers is expected because
it is the only way for the receiver to be sure of the data. Having
all of the peers under the same administration is the simplest way to
obtain this trust, but it is not the only one.
The channel between peers also needs protection, preferably with
cryptography. ACL and other network techniques are of course useful.
Bortzmeyer, et al. Expires 4 February 2027 [Page 4]
Internet-Draft Poisonlicious August 2026
Sharing one TSIG key across the whole network lets any peer
impersonate any other (Section 10 of [RFC8945]). Using a distinct
key per pair of peers is more important when the peers are not under
the same administration.
5. Privacy Considerations
The records transmitted are public, but the messages contain the
names that the resolvers have resolved, and therefore reveal to an
eavesdropper what their clients looked up [RFC9076]. Removing the
question section does not hide this, since the answer section
contains the owner name. Using an encrypted transport, for instance
DoT [RFC7858] or DoQ [RFC9250], or otherwise protecting the network
path between peers, defeats this leakage and is RECOMMENDED when the
messages travel over the public Internet.
If the originating resolver sends the original question section in
its messages to receiving peers, it can have privacy consequences
[RFC9076], for instance in the case of negative answers. When all
the peers are under the same administration, these consequences are
limited, and the originator SHOULD remove this section or replace it
with dummy data. When the peers are under distinct administrations,
the question section would disclose the queries of one party's
clients to another, and the originator MUST remove it or replace it
with dummy data.
6. Operational Considerations
It is reminded that all resolvers in the network need to trust each
other. This specification is not meant to be deployed between
unrelated resolvers.
The network of peer resolvers has to be configured out-of-band
beforehand. The way to do it is out-of-scope for this specification.
7. Related and future work
7.1. Related work
[I-D.hl-dnsop-cache-filling] describes a mechanism to fill DNS caches
with data. The format is, like in this document, standard DNS as
seen on the wire.
7.2. Future work
Bortzmeyer, et al. Expires 4 February 2027 [Page 5]
Internet-Draft Poisonlicious August 2026
7.2.1. Actual measurement
Measuring the efficiency of caching optimizations is hard because the
performance depends a lot on the actual queries sent and their
timeline. It would be interesting to test on real-world data to
measure the improvement brought by this technology.
7.2.2. Negative answers
In the future, we may allow negative answers to be sent, which would
permit the receivers to use [RFC8020] and/or [RFC8198] to synthesize
negative answers.
Be careful of the risk of overloading receiving peers for instance
when there is a dictionary attack.
7.2.3. ECS
Today, we don't transmit the EDNS record since EDNS is not end-to-
end. But ECS [RFC7871] may be an important information for the
participating resolvers.
7.2.4. Authentication
Standardizing how peers select an alternative authentication
mechanism, such as SIG(0) [RFC2931] or DoT [RFC7858], is future work.
7.2.5. Dispatching of messages
Today, messages following this specification are sent to the proper
handler based on the TSIG key used. It could be an interesting
alternative to use a separate transport port instead.
7.2.6. Transport of messages
Messages could be transmitted in long-lived TCP sessions, too.
If there are 1,000 servers, sending 1,000 messages, or having a full
mesh of 1,000 TCP connections may be too much. It may be interesting
to replace the unicast messages by multicast [RFC5110] (the issues of
multicast on the public Internet do not apply here since we envision
work under only one administration. A network spanning several
administrations would have to face them).
Other protocols may be considered such as MQTT [MQTT] which is well
suited for publish-by-one/consume-by-many, raw protocol buffers [GPB]
or dnstap [dnstap] over them.
Bortzmeyer, et al. Expires 4 February 2027 [Page 6]
Internet-Draft Poisonlicious August 2026
Also, a different organisation of the network of resolvers could be
done in a hub-and-spoke way, in the future.
7.2.7. Packing of messages
It could be interesting to optimize by packing the data in a C-DNS
[RFC8618] flow, sent with TCP (with TLS) or QUIC. (Of course, other
formats/protocols are possible.)
7.2.8. Different responses
When the authoritative servers send different replies depending on
the client, the various peers may send different (and under-
optimized) responses to a receiving peer.
8. References
8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[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/info/rfc2119>.
[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/info/rfc8174>.
[RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
Gudmundsson, O., and B. Wellington, "Secret Key
Transaction Authentication for DNS (TSIG)", STD 93,
RFC 8945, DOI 10.17487/RFC8945, November 2020,
<https://www.rfc-editor.org/info/rfc8945>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
8.2. Informative References
Bortzmeyer, et al. Expires 4 February 2027 [Page 7]
Internet-Draft Poisonlicious August 2026
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61,
RFC 3365, DOI 10.17487/RFC3365, August 2002,
<https://www.rfc-editor.org/info/rfc3365>.
[RFC5110] Savola, P., "Overview of the Internet Multicast Routing
Architecture", RFC 5110, DOI 10.17487/RFC5110, January
2008, <https://www.rfc-editor.org/info/rfc5110>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016,
<https://www.rfc-editor.org/info/rfc7871>.
[RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
November 2016, <https://www.rfc-editor.org/info/rfc8020>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>.
[RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T.,
and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS
Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September
2019, <https://www.rfc-editor.org/info/rfc8618>.
[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
DOI 10.17487/RFC9076, July 2021,
<https://www.rfc-editor.org/info/rfc9076>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
Bortzmeyer, et al. Expires 4 February 2027 [Page 8]
Internet-Draft Poisonlicious August 2026
[I-D.hl-dnsop-cache-filling]
Hoffman, P. E. and M. Larson, "Additional Method for
Filling DNS Caches", Work in Progress, Internet-Draft,
draft-hl-dnsop-cache-filling-00, 2 March 2018,
<https://datatracker.ietf.org/doc/html/draft-hl-dnsop-
cache-filling-00>.
[MQTT] OASIS, "MQTT Version 5.0", 2019, <https://docs.oasis-
open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.docx>.
[GPB] Google Developers, "Protocol Buffers",
<https://protobuf.dev/>.
[dnstap] Edmonds, R., "dnstap", 2014, <https://dnstap.info/>.
Acknowledgements
Original idea at the DNS hackathon (RIPE-NCC / Netnod / DNS-OARC) in
march 2025 at the Netnod office in Stockholm.
Authors' Addresses
Stéphane Bortzmeyer
Afnic
7 avenue du 8 mai 1945
78280 Guyancourt
France
Email: bortzmeyer+ietf@nic.fr
URI: https://www.afnic.fr/
Willem Toorop
NLnet Labs
Science Park 400
1098 XH Amsterdam
Netherlands
Email: willem@nlnetlabs.nl
URI: https://nlnetlabs.nl/
Babak Farrokhi
Quad9
Werdstrasse 2
CH-8004 Zürich
Switzerland
Email: babak@farrokhi.net
URI: https://quad9.net/
Bortzmeyer, et al. Expires 4 February 2027 [Page 9]
Internet-Draft Poisonlicious August 2026
Moin Rahman
The FreeBSD Foundation
3980 Broadway St
Boulder, CO 80304
United States of America
Email: bofh@freebsd.org
URI: https://freebsdfoundation.org/
Ondřej Surý
Internet Systems Consortium
Czech Republic
Email: ondrej@isc.org
Otto Moerbeek
PowerDNS
Netherlands
Email: otto.moerbeek@powerdns.com
Bortzmeyer, et al. Expires 4 February 2027 [Page 10]