Afnic

7 avenue du 8 mai 1945 Guyancourt 78280 FR bortzmeyer+ietf@nic.fr https://www.afnic.fr/

NLnet Labs

Science Park 400 Amsterdam 1098 XH NL willem@nlnetlabs.nl https://nlnetlabs.nl/

Quad9

Werdstrasse 2 Zürich 8004 CH babak@farrokhi.net https://quad9.net/

The FreeBSD Foundation

3980 Broadway St Boulder CO 80304 US bofh@freebsd.org https://freebsdfoundation.org/

Internet Systems Consortium

Czech Republic ondrej@isc.org

PowerDNS

NL otto.moerbeek@powerdns.com

General Internet Engineering Task Force DNS DNSSEC optimization caching Network 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.

Introduction When an organisation operates a big network of DNS resolvers , for instance for an important public resolver (), 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.

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 when, and only when, they appear in all capitals, as shown here.

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

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 . 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 (, 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). This message MAY be the message received by the resolver from the authoritative name servers or it MAY be a new message with data composed from data already obtained by the resolver, for instance without the question section (this would help a bit with privacy ). 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 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.

IANA Considerations None. [RFC-Editor: you may delete this section]

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.

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 but it is not otherwise specified. If the originating resolver sends the original question section in its messages to receiving peers, it can have privacy consequences . These consequences are limited since all the peers are under the same administration, anyway. The originator MAY remove this section or replace it with dummy data.

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.

Related and future work

Related work describes a mechanism to fill DNS caches with data. The format is, like in this document, standard DNS as seen on the wire.

Future work

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.

Negative answers If in the future, we may allow negative answers to be sent, which would permit the receivers to use and/or to synthetize negative answers. Be careful of the risk of overloading receving peers for instance when there is a dictionary attack.

ECS Today, we don't transmit the EDNS record since EDNS is not end-to-end. But ECS may be an important information for the participating resolvers.

Authentication of messages Today, we authenticate only with TSIG . SIG(0) or DoT may be interesting improvements in the future.

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.

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 (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 which is well suited for publish-by-one/consume-by-many, raw protocol buffers or dnstap over them.

Packing of messages It could be interesting to optimize by packing the data in a C-DNS flow, sent with TCP (with TLS) or QUIC. (Of course, other formats/protocols are possible.)

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.

References Normative References Informative References OASIS Google Developers

Acknowledgements Original idea at the DNS hackathon (RIPE-NCC / Netnod / DNS-OARC) in march 2025 at the Netnod office in Stockholm.