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

CZ ondrej@isc.org

PowerDNS

NL otto.moerbeek@powerdns.com

General DNSOP Working Group 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. Status information for this document may be found at . Discussion of this document takes place on the dnsop Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction When an organisation operates a big network of DNS resolvers , for instance for an important public resolver , it may be a performance improvement to distribute the result of the resolution process between the resolvers. This document standardizes how to to do so, using blockchains (just kidding) and unicast messages to a set of pre-configured peers. TODO data from Quad9 to show that there is a caching improvement to expect. Measuring the efficiency of caching optimizations is hard!

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 (TODO or resolver set? Or resolver cluster?):

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 . TODO SIG0? DoT? 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. Messages of this protocol are distinguished from other DNS messages by the TSIG key they use (which must therefore be specific to this protocol). TODO or by a dedicated port? 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. TODO privacy risks when sending the question section? (See The EDNS section MUST be a new one, created to fit the needs of successful transmission to the peer. TODO what about ECS 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). TODO cache only what is in the Answer section? See above about assessing the trustiness of the data. TODO talks about the ranking of data. Should we describe it? Since it is supposed to be used inside an organisation, where all peers trust each other, and have a consistent policy, is it necessary? The idea is that the data is as trustworthy as if you validated it yourself.

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 bad privacy consequences TODO: delete this section? Replace it with dummy data?

Operational Considerations It is reminded that all resolvers in the network need to trust each other, probably 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

Negative answers TODO What to do about them? Transmit them? (Be careful of the risk of overloading receving peers for instance when there is a dictionary attack.) Can a receiving peer use and/or to synthetize negative answers since it did not validate data itself?

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). Is the use of a DHT reasonable? Why not MQTT which is well suited for publish-by-one/consume-by-many? What about protocols like protocol buffers? TODO What about dnstap?

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.

This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism. This document obsoletes RFCs 2845 and 4635. OASISi This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK] This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626. ICANN ICANN DNS recursive resolvers do not always have access to the authoritative resolvers from which they need to get information. For example, when the DNS root servers are under DDoS attack, a recursive resolver may not be able to get an answer from any of the root servers. This document describes how resolvers can populate their caches with zone information, and keep their cache populated, using out-of-band mechanisms that do not rely on the DNS protocol. The protocol is primarily designed for the root zone, but can apply to any zone that wants to participate by publishing values to be cached. This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist. This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them. The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances. This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications. This memo also reclassifies several older RFCs to Historic. These RFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse. This memo provides information for the Internet community. This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic- monitoring applications.

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