| Internet-Draft | Poisonlicious | March 2025 |
| Bortzmeyer, et al. | Expires 24 September 2025 | [Page] |
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.¶
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 24 September 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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 blockchains (just kidding) and unicast messages to a set of pre-configured peers.¶
TODO data from Quad9 to show that there is a caching improvment to expect. Measuring the efficiency of caching optimizations is hard!¶
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.¶
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]. TODO SIG0? DoT? No acknowledgment is sent or expected.¶
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? [RFC9076] Force its elision?¶
The EDNS section MUST be a new one, created to fit the needs of successful transmission to the peer. TODO what about ECS [RFC7871]?¶
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 Section 5.4.1 of [RFC2181] 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.¶
None. [RFC-Editor: you may delete this section]¶
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.¶
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.¶
Original idea at the DNS hackathon (RIPE-NCC / Netnod / DNS-OARC) in march 2025 at the Netnod office in Stockholm.¶