Synchronizing caches of DNS resolvers
draft-bortzmeyer-dnsop-poisonlicious-04
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-06-16 | ||
| 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-04
Internet Engineering Task Force S. Bortzmeyer
Internet-Draft Afnic
Intended status: Experimental W. Toorop
Expires: 18 December 2026 NLnet Labs
B. Farrokhi
Quad9
M. Rahman
The FreeBSD Foundation
O. Surý
Internet Systems Consortium
O. Moerbeek
PowerDNS
16 June 2026
Synchronizing caches of DNS resolvers
draft-bortzmeyer-dnsop-poisonlicious-04
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 18 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bortzmeyer, et al. Expires 18 December 2026 [Page 1]
Internet-Draft Poisonlicious June 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 . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . 5
7.2.2. Negative answers . . . . . . . . . . . . . . . . . . 5
7.2.3. ECS . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.2.4. Authentication of messages . . . . . . . . . . . . . 6
7.2.5. Dispatching of messages . . . . . . . . . . . . . . . 6
7.2.6. Transport of messages . . . . . . . . . . . . . . . . 6
7.2.7. Packing of messages . . . . . . . . . . . . . . . . . 6
7.2.8. Different responses . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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 improvment to
distribute the result of the resolution process between the
resolvers. This document standardizes how to to do so, using unicast
messages to a set of pre-configured peers.
Bortzmeyer, et al. Expires 18 December 2026 [Page 2]
Internet-Draft Poisonlicious June 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 resolvers working together 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, authenticating with TSIG [RFC8945]. 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.
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). Since all of the network of resolvers are in the same
organizational domain, they MUST agree on the same policy for this
assessment.
Negative answers ([RFC9499], section 3) MUST NOT be transmitted to
peers.
Messages of this protocol are distinguished from other DNS messages
by the TSIG key they use (which must therefore be specific to this
protocol).
Bortzmeyer, et al. Expires 18 December 2026 [Page 3]
Internet-Draft Poisonlicious June 2026
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.) 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. One way
to do so is to have all of the peers under the same organisational
authority, as mandated here.
For the same reason, the channel between peers must be protected,
preferrably with cryptography (currently, TSIG is mandatory). ACL
and other network techniques are of course useful.
Encryption is less important than authentication since we transmit
only public data. Nevertheless, it is better to be sure that the
channel between the peers is not open to snooping.
5. Privacy Considerations
Confidentiality is currently out of scope for this document. The
communication between the originating resolver and its receiving
peers could be encrypted, for instance with DoT [RFC7858] but it is
not otherwise specified.
Bortzmeyer, et al. Expires 18 December 2026 [Page 4]
Internet-Draft Poisonlicious June 2026
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. These
consequences are limited since all the peers are under the same
administration, anyway. The originator SHOULD remove this section or
replace it with dummy data.
6. Operational Considerations
It is reminded that all resolvers in the network need to trust each
other, being in the same administrative domain. This specification
is not meant to be deployed between unrelated resolvers.
The netwok of peer resolvers have to be configured out-of-band
before. 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
7.2.1. Actual measurement
Measuring the efficiency of caching optimizations is hard because the
performance depend a lot on the actual queries sent and their
timeline. It would be interesting to test on real-world data to
measure the improvment brought by this technology.
7.2.2. Negative answers
If in the future, we may allow negative answers to be sent, which
would permit the receivers to use [RFC8020] and/or [RFC8198] to
synthetize negative answers.
Be careful of the risk of overloading receving 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.
Bortzmeyer, et al. Expires 18 December 2026 [Page 5]
Internet-Draft Poisonlicious June 2026
7.2.4. Authentication of messages
Today, we authenticate only with TSIG [RFC8945]. SIG(0) [RFC2931] or
DoT [RFC7858] may be interesting improvements in the future.
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 no apply here since we envision
work under only one organisation).
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.
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>.
Bortzmeyer, et al. Expires 18 December 2026 [Page 6]
Internet-Draft Poisonlicious June 2026
[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
[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>.
[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>.
Bortzmeyer, et al. Expires 18 December 2026 [Page 7]
Internet-Draft Poisonlicious June 2026
[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>.
[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/
Bortzmeyer, et al. Expires 18 December 2026 [Page 8]
Internet-Draft Poisonlicious June 2026
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/
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 18 December 2026 [Page 9]