diff options
Diffstat (limited to 'doc/rfc/rfc9103.txt')
| -rw-r--r-- | doc/rfc/rfc9103.txt | 1696 |
1 files changed, 1696 insertions, 0 deletions
diff --git a/doc/rfc/rfc9103.txt b/doc/rfc/rfc9103.txt new file mode 100644 index 0000000..18a3f9c --- /dev/null +++ b/doc/rfc/rfc9103.txt @@ -0,0 +1,1696 @@ + + + + +Internet Engineering Task Force (IETF) W. Toorop +Request for Comments: 9103 NLnet Labs +Updates: 1995, 5936, 7766 S. Dickinson +Category: Standards Track Sinodun IT +ISSN: 2070-1721 S. Sahib + Brave Software + P. Aras + A. Mankin + Salesforce + August 2021 + + + DNS Zone Transfer over TLS + +Abstract + + DNS zone transfers are transmitted in cleartext, which gives + attackers the opportunity to collect the content of a zone by + eavesdropping on network connections. The DNS Transaction Signature + (TSIG) mechanism is specified to restrict direct zone transfer to + authorized clients only, but it does not add confidentiality. This + document specifies the use of TLS, rather than cleartext, to prevent + zone content collection via passive monitoring of zone transfers: XFR + over TLS (XoT). Additionally, this specification updates RFC 1995 + and RFC 5936 with respect to efficient use of TCP connections and RFC + 7766 with respect to the recommended number of connections between a + client and server for each transport. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9103. + +Copyright Notice + + Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Threat Model + 4. Design Considerations for XoT + 5. Connection and Data Flows in Existing XFR Mechanisms + 5.1. AXFR Mechanism + 5.2. IXFR Mechanism + 5.3. Data Leakage of NOTIFY and SOA Message Exchanges + 5.3.1. NOTIFY + 5.3.2. SOA + 6. Updates to Existing Specifications + 6.1. Update to RFC 1995 for IXFR over TCP + 6.2. Update to RFC 5936 for AXFR over TCP + 6.3. Updates to RFCs 1995 and 5936 for XFR over TCP + 6.3.1. Connection Reuse + 6.3.2. AXFRs and IXFRs on the Same Connection + 6.3.3. XFR Limits + 6.3.4. The edns-tcp-keepalive EDNS(0) Option + 6.3.5. Backwards Compatibility + 6.4. Update to RFC 7766 + 7. XoT Specification + 7.1. Connection Establishment + 7.2. TLS Versions + 7.3. Port Selection + 7.4. High-Level XoT Descriptions + 7.5. XoT Transfers + 7.6. XoT Connections + 7.7. XoT vs. ADoT + 7.8. Response RCODES + 7.9. AXoT Specifics + 7.9.1. Padding AXoT Responses + 7.10. IXoT Specifics + 7.10.1. Condensation of Responses + 7.10.2. Fallback to AXFR + 7.10.3. Padding of IXoT Responses + 7.11. Name Compression and Maximum Payload Sizes + 8. Multi-primary Configurations + 9. Authentication Mechanisms + 9.1. TSIG + 9.2. SIG(0) + 9.3. TLS + 9.3.1. Opportunistic TLS + 9.3.2. Strict TLS + 9.3.3. Mutual TLS + 9.4. IP-Based ACL on the Primary + 9.5. ZONEMD + 10. XoT Authentication + 11. Policies for Both AXoT and IXoT + 12. Implementation Considerations + 13. Operational Considerations + 14. IANA Considerations + 15. Security Considerations + 16. References + 16.1. Normative References + 16.2. Informative References + Appendix A. XoT Server Connection Handling + A.1. Listening Only on a Specific IP Address for TLS + A.2. Client-Specific TLS Acceptance + A.3. SNI-Based TLS Acceptance + A.4. Transport-Specific Response Policies + A.4.1. SNI-Based Response Policies + Acknowledgements + Contributors + Authors' Addresses + +1. Introduction + + DNS has a number of privacy vulnerabilities, as discussed in detail + in [RFC9076]. Query privacy between stub resolvers and recursive + resolvers has received the most attention to date, with Standards + Track documents for both DNS over TLS (DoT) [RFC7858] and DNS over + HTTPS (DoH) [RFC8484] and a proposal for DNS over QUIC + [DPRIVE-DNSOQUIC]. There is ongoing work on DNS privacy requirements + for exchanges between recursive resolvers and authoritative servers + and some suggestions for how signaling of DoT support by + authoritative name servers might work. However, there is currently + no RFC that specifically defines recursive-to-authoritative DNS over + TLS (ADoT). + + [RFC9076] establishes that a stub resolver's DNS query transactions + are not public and that they need protection, but, on zone transfer + [RFC1995] [RFC5936], it says only: + + | Privacy risks for the holder of a zone (the risk that someone gets + | the data) are discussed in [RFC5155] and [RFC5936]. + + In what way is exposing the full contents of a zone a privacy risk? + The contents of the zone could include information such as names of + persons used in names of hosts. Best practice is not to use personal + information for domain names, but many such domain names exist. The + contents of the zone could also include references to locations that + allow inference about location information of the individuals + associated with the zone's organization. It could also include + references to other organizations. Examples of this could be: + + * Person-laptop.example.org + + * MX-for-Location.example.org + + * Service-tenant-from-another-org.example.org + + Additionally, the full zone contents expose all the IP addresses of + endpoints held in the DNS records, which can make reconnaissance and + attack targeting easier, particularly for IPv6 addresses or private + networks. There may also be regulatory, policy, or other reasons why + the zone contents in full must be treated as private. + + Neither of the RFCs mentioned in [RFC9076] contemplate the risk that + someone gets the data through eavesdropping on network connections, + only via enumeration or unauthorized transfer, as described in the + following paragraphs. + + Zone enumeration is trivially possible for DNSSEC zones that use + NSEC, i.e., queries for the authenticated denial-of-existence records + allow a client to walk through the entire zone contents. [RFC5155] + specifies NSEC3, a mechanism to provide measures against zone + enumeration for DNSSEC-signed zones (a goal was to make it as hard to + enumerate a DNSSEC-signed zone as an unsigned zone). Whilst this is + widely used, it has been demonstrated that zone walking is possible + for precomputed NSEC3 using attacks, such as those described in + [NSEC3-attacks]. This prompted further work on an alternative + mechanism for DNSSEC-authenticated denial of existence (NSEC5 + [NSEC5]); however, questions remain over the practicality of this + mechanism. + + [RFC5155] does not address data obtained outside zone enumeration + (nor does [NSEC5]). Preventing eavesdropping of zone transfers (as + described in this document) is orthogonal to preventing zone + enumeration, though they aim to protect the same information. + + [RFC5936] specifies using TSIG [RFC8945] for authorization of the + clients of a zone transfer and for data integrity but does not + express any need for confidentiality, and TSIG does not offer + encryption. + + Section 8 of the NIST document "Secure Domain Name System (DNS) + Deployment Guide" [NIST-GUIDE] discusses restricting access for zone + transfers using Access Control Lists (ACLs) and TSIG in more detail. + It also discusses the possibility that specific deployments might + choose to use a lower-level network layer to protect zone transfers, + e.g., IPsec. + + It is noted that in all the common open-source implementations such + ACLs are applied on a per-query basis (at the time of writing). + Since requests typically occur on TCP connections, authoritative + servers must therefore accept any TCP connection and then handle the + authentication of each zone transfer (XFR) request individually. + + Because both AXFR (authoritative transfer) and IXFR (incremental zone + transfer) are typically carried out over TCP from authoritative DNS + protocol implementations, encrypting zone transfers using TLS + [RFC8499] -- based closely on DoT [RFC7858] -- seems like a simple + step forward. This document specifies how to use TLS (1.3 or later) + as a transport to prevent zone collection from zone transfers. + + This document also updates the previous specifications for zone + transfers to clarify and extend them, mainly with respect to TCP + usage: + + * [RFC1995] (IXFR) and [RFC5936] (AXFR) are both updated to add + further specification on efficient use of TCP connections. + + * Section 6.2.2 of [RFC7766] ("DNS Transport over TCP - + Implementation Requirements") is updated with a new recommendation + about the number of connections between a client and server for + each transport. + +2. Terminology + + 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. + + Privacy terminology is as described in Section 3 of [RFC6973]. + + DNS terminology is as described in [RFC8499]. Note that, as in + [RFC8499], the terms 'primary' and 'secondary' are used for two + servers engaged in zone transfers. + + DoT: DNS over TLS, as specified in [RFC7858] + + XFR over TCP: Used to mean both IXFR over TCP [RFC1995] and AXFR + over TCP [RFC5936] + + XoT: XFR-over-TLS mechanisms, as specified in this document, which + apply to both AXFR over TLS and IXFR over TLS (XoT is + pronounced 'zot' since X here stands for 'zone transfer') + + AXoT: AXFR over TLS + + IXoT: IXFR over TLS + +3. Threat Model + + The threat model considered here is one where the current contents + and size of the zone are considered sensitive and should be protected + during transfer. + + The threat model does not, however, consider the existence of a zone, + the act of zone transfer between two entities, nor the identities of + the name servers hosting a zone (including both those acting as + hidden primaries/secondaries or directly serving the zone) as + sensitive information. The proposed mechanism does not attempt to + obscure such information. The reasons for this include: + + * much of this information can be obtained by various methods, + including active scanning of the DNS, and + + * an attacker who can monitor network traffic can rather easily + infer relations between name servers simply from traffic patterns, + even when some or all of the traffic is encrypted (in terms of + current deployments). + + The model does not consider attacks on the mechanisms that trigger a + zone transfer, e.g., NOTIFY messages. + + It is noted that simply using XoT will indicate a desire by the zone + owner that the contents of the zone remain confidential and so could + be subject to blocking (e.g., via blocking of port 853) if an + attacker had such capabilities. However, this threat is likely true + of any such mechanism that attempts to encrypt data passed between + name servers, e.g., IPsec. + +4. Design Considerations for XoT + + The following principles were considered in the design for XoT: + + Confidentiality: Clearly using an encrypted transport for zone + transfers will defeat zone content leakage that can occur via + passive surveillance. + + Authentication: Use of single or mutual TLS (mTLS) authentication + (in combination with ACLs) can complement and potentially be an + alternative to TSIG. + + Performance: + * Existing AXFR and IXFR mechanisms have the burden of backwards + compatibility with older implementations based on the original + specifications in [RFC1034] and [RFC1035]. For example, some + older AXFR servers don't support using a TCP connection for + multiple AXFR sessions or XFRs of different zones because they + have not been updated to follow the guidance in [RFC5936]. Any + implementation of XoT would obviously be required to implement + optimized and interoperable transfers, as described in + [RFC5936], e.g., transfer of multiple zones over one + connection. + + * Current usage of TCP for IXFR is suboptimal in some cases, + i.e., connections are frequently closed after a single IXFR. + +5. Connection and Data Flows in Existing XFR Mechanisms + + The original specification for zone transfers in [RFC1034] and + [RFC1035] was based on a polling mechanism: a secondary performed a + periodic query for the SOA (start of zone authority) record (based on + the refresh timer) to determine if an AXFR was required. + + [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY, + respectively, to provide for prompt propagation of zone updates. + This has largely replaced AXFR where possible, particularly for + dynamically updated zones. + + [RFC5936] subsequently redefined the specification of AXFR to improve + performance and interoperability. + + In this document, the term 'XFR mechanism' is used to describe the + entire set of message exchanges between a secondary and a primary + that concludes with a successful AXFR or IXFR request/response. This + set may or may not include: + + * NOTIFY messages + + * SOA queries + + * Fallback from IXFR to AXFR + + * Fallback from IXFR over UDP to IXFR over TCP + + The term is used to encompass the range of permutations that are + possible and is useful to distinguish the 'XFR mechanism' from a + single XFR request/response exchange. + +5.1. AXFR Mechanism + + The figure below provides an outline of an AXFR mechanism including + NOTIFYs. + + Secondary Primary + + | NOTIFY | + | <-------------------------------- | UDP + | --------------------------------> | + | NOTIFY Response | + | | + | | + | SOA Request | + | --------------------------------> | UDP (or part of + | <-------------------------------- | a TCP session) + | SOA Response | + | | + | | + | | + | AXFR Request | --- + | --------------------------------> | | + | <-------------------------------- | | + | AXFR Response 1 | | + | (Zone data) | | + | | | + | <-------------------------------- | | TCP + | AXFR Response 2 | | Session + | (Zone data) | | + | | | + | <-------------------------------- | | + | AXFR Response 3 | | + | (Zone data) | --- + | | + + Figure 1: AXFR Mechanism + + 1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP) + from the primary to the secondary. A secondary may also initiate + an AXFR based on a refresh timer or scheduled/triggered zone + maintenance. + + 2. The secondary will normally (but not always) make an SOA query to + the primary to obtain the serial number of the zone held by the + primary. + + 3. If the primary serial is higher than the secondary's serial + (using Serial Number Arithmetic [RFC1982]), the secondary makes + an AXFR request (over TCP) to the primary, after which the AXFR + data flows in one or more AXFR responses on the TCP connection. + [RFC5936] defines this specific step as an 'AXFR session', i.e., + as an AXFR query message and the sequence of AXFR response + messages returned for it. + + [RFC5936] re-specified AXFR, providing additional guidance beyond + that provided in [RFC1034] and [RFC1035] and importantly specified + that AXFR must use TCP as the transport protocol. + + Additionally, Sections 4.1, 4.1.1, and 4.1.2 of [RFC5936] provide + improved guidance for AXFR clients and servers with regard to reuse + of TCP connections for multiple AXFRs and AXFRs of different zones. + However, [RFC5936] was constrained by having to be backwards + compatible with some very early basic implementations of AXFR. For + example, it outlines that the SOA query can also happen on this + connection. However, this can cause interoperability problems with + older implementations that support only the trivial case of one AXFR + per connection. + +5.2. IXFR Mechanism + + The figure below provides an outline of the IXFR mechanism including + NOTIFYs. + + Secondary Primary + + | NOTIFY | + | <-------------------------------- | UDP + | --------------------------------> | + | NOTIFY Response | + | | + | | + | SOA Request | + | --------------------------------> | UDP or TCP + | <-------------------------------- | + | SOA Response | + | | + | | + | | + | IXFR Request | + | --------------------------------> | UDP or TCP + | <-------------------------------- | + | IXFR Response | + | (Zone data) | + | | + | | --- + | IXFR Request | | + | --------------------------------> | | Retry over + | <-------------------------------- | | TCP if + | IXFR Response | | required + | (Zone data) | --- + + Figure 2: IXFR Mechanism + + 1. An IXFR is normally (but not always) preceded by a NOTIFY (over + UDP) from the primary to the secondary. A secondary may also + initiate an IXFR based on a refresh timer or scheduled/triggered + zone maintenance. + + 2. The secondary will normally (but not always) make an SOA query to + the primary to obtain the serial number of the zone held by the + primary. + + 3. If the primary serial is higher than the secondary's serial + (using Serial Number Arithmetic [RFC1982]), the secondary makes + an IXFR request to the primary, after which the primary sends an + IXFR response. + + [RFC1995] specifies that IXFR may use UDP if the entire IXFR response + can be contained in a single DNS packet, otherwise, TCP is used. In + fact, it says: + + | Thus, a client should first make an IXFR query using UDP. + + So there may be a fourth step above where the client falls back to + IXFR over TCP. There may also be an additional step where the + secondary must fall back to AXFR because, e.g., the primary does not + support IXFR. + + However, it is noted that most of the widely used open-source + implementations of authoritative name servers (including both [BIND] + and [NSD]) do IXFR using TCP by default in their latest releases. + For BIND, TCP connections are sometimes used for SOA queries, but, in + general, they are not used persistently and are closed after an IXFR + is completed. + +5.3. Data Leakage of NOTIFY and SOA Message Exchanges + + This section presents a rationale for considering the encryption of + the other messages in the XFR mechanism. + + Since the SOA of the published zone can be trivially discovered by + simply querying the publicly available authoritative servers, leakage + of this resource record (RR) via such a direct query is not discussed + in the following sections. + +5.3.1. NOTIFY + + Unencrypted NOTIFY messages identify configured secondaries on the + primary. + + [RFC1996] also states: + + | If ANCOUNT>0, then the answer section represents an unsecure hint + | at the new RRset for this <QNAME,QCLASS,QTYPE>. + + But since the only query type (QTYPE) for NOTIFY defined at the time + of this writing is SOA, this does not pose a potential leak. + +5.3.2. SOA + + For hidden XFR servers (either primaries or secondaries), an SOA + response directly from that server only additionally leaks the degree + of SOA serial number lag of any downstream secondary of that server. + +6. Updates to Existing Specifications + + For convenience, the term 'XFR over TCP' is used in this document to + mean both IXFR over TCP and AXFR over TCP; therefore, statements that + use that term update both [RFC1995] and [RFC5936] and implicitly also + apply to XoT. Differences in behavior specific to XoT are discussed + in Section 7. + + Both [RFC1995] and [RFC5936] were published sometime before TCP + became a widely supported transport for DNS. [RFC1995], in fact, + says nothing with respect to optimizing IXFRs over TCP or reusing + already open TCP connections to perform IXFRs or other queries. + Therefore, there arguably is an implicit assumption that a TCP + connection is used for one and only one IXFR request. Indeed, many + major open-source implementations take this approach (at the time of + this writing). And whilst [RFC5936] gives guidance on connection + reuse for AXFR, it predates more recent specifications describing + persistent TCP connections (e.g., [RFC7766], [RFC7828]), and AXFR + implementations again often make less-than-optimal use of open + connections. + + Given this, new implementations of XoT will clearly benefit from + specific guidance on TCP/TLS connection usage for XFR, because this + will: + + * result in more consistent XoT implementations with better + interoperability and + + * remove any need for XoT implementations to support legacy behavior + for XoT connections that XFR-over-TCP implementations have + historically often supported. + + Therefore, this document updates both the previous specifications for + XFR over TCP ([RFC1995] and [RFC5936]) to clarify that: + + * Implementations MUST use [RFC7766] ("DNS Transport over TCP - + Implementation Requirements") to optimize the use of TCP + connections. + + * Whilst [RFC7766] states that "DNS clients SHOULD pipeline their + queries" on TCP connections, it did not distinguish between XFRs + and other queries for this behavior. It is now recognized that + XFRs are not as latency sensitive as other queries and can be + significantly more complex for clients to handle, both because of + the large amount of state that must be kept and because there may + be multiple messages in the responses. For these reasons, it is + clarified here that a valid reason for not pipelining queries is + when they are all XFR queries, i.e., clients sending multiple XFRs + MAY choose not to pipeline those queries. Clients that do not + pipeline XFR queries therefore have no additional requirements to + handle out-of-order or intermingled responses (as described + later), since they will never receive them. + + * Implementations SHOULD use the edns-tcp-keepalive EDNS(0) option + [RFC7828] to manage persistent connections. This is more flexible + than the alternative of simply using fixed timeouts. + + The following sections include detailed clarifications on the updates + to XFR behavior implied in [RFC7766] and how the use of [RFC7828] + applies specifically to XFR exchanges. They also discuss how IXFR + and AXFR can reuse the same TCP connection. + + For completeness, the recent specification of extended DNS error + (EDE) codes [RFC8914] is also mentioned here. For zone transfers, + when returning REFUSED to a zone transfer request from an + 'unauthorized' client (e.g., where the client is not listed in an ACL + for zone transfers or does not sign the request with a valid TSIG + key), the extended DNS error code 18 - Prohibited can also be sent. + +6.1. Update to RFC 1995 for IXFR over TCP + + For clarity, an IXFR-over-TCP server compliant with this + specification MUST be able to handle multiple concurrent IXoT + requests on a single TCP connection (for the same and different + zones) and SHOULD send the responses as soon as they are available, + which might be out of order compared to the requests. + +6.2. Update to RFC 5936 for AXFR over TCP + + For clarity, an AXFR-over-TCP server compliant with this + specification MUST be able to handle multiple concurrent AXoT + sessions on a single TCP connection (for the same and different + zones). The response streams for concurrent AXFRs MAY be + intermingled, and AXFR-over-TCP clients compliant with this + specification, which pipeline AXFR requests, MUST be able to handle + this. + +6.3. Updates to RFCs 1995 and 5936 for XFR over TCP + +6.3.1. Connection Reuse + + As specified, XFR-over-TCP clients SHOULD reuse any existing open TCP + connection when starting any new XFR request to the same primary, and + for issuing SOA queries, instead of opening a new connection. The + number of TCP connections between a secondary and primary SHOULD be + minimized (also see Section 6.4). + + Valid reasons for not reusing existing connections might include: + + * As already noted in [RFC7766], separate connections for different + zones might be preferred for operational reasons. In this case, + the number of concurrent connections for zone transfers SHOULD be + limited to the total number of zones transferred between the + client and server. + + * A configured limit for the number of outstanding queries or XFR + requests allowed on a single TCP connection has been reached. + + * The message ID pool has already been exhausted on an open + connection. + + * A large number of timeouts or slow responses have occurred on an + open connection. + + * An edns-tcp-keepalive EDNS(0) option with a timeout of 0 has been + received from the server, and the client is in the process of + closing the connection (see Section 6.3.4). + + If no TCP connections are currently open, XFR clients MAY send SOA + queries over UDP or a new TCP connection. + +6.3.2. AXFRs and IXFRs on the Same Connection + + Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a + single TCP connection for both IXFR and AXFR requests. [RFC5936] + does make the general statement: + + | Non-AXFR session traffic can also use an open connection. + + In this document, the above is clarified to indicate that + implementations capable of both AXFR and IXFR and compliant with this + specification SHOULD: + + * use the same TCP connection for both AXFR and IXFR requests to the + same primary, + + * pipeline such requests (if they pipeline XFR requests in general) + and MAY intermingle them, and + + * send the response(s) for each request as soon as they are + available, i.e., responses MAY be sent intermingled. + + For some current implementations, adding all the above functionality + would introduce significant code complexity. In such a case, there + will need to be an assessment of the trade-off between that and the + performance benefits of the above for XFR. + +6.3.3. XFR Limits + + The server MAY limit the number of concurrent IXFRs, AXFRs, or total + XFR transfers in progress (or from a given secondary) to protect + server resources. Servers SHOULD return SERVFAIL if this limit is + hit, since it is a transient error and a retry at a later time might + succeed (there is no previous specification for this behavior). + +6.3.4. The edns-tcp-keepalive EDNS(0) Option + + XFR clients that send the edns-tcp-keepalive EDNS(0) option on every + XFR request provide the server with maximum opportunity to update the + edns-tcp-keepalive timeout. The XFR server may use the frequency of + recent XFRs to calculate an average update rate as input to the + decision of what edns-tcp-keepalive timeout to use. If the server + does not support edns-tcp-keepalive, the client MAY keep the + connection open for a few seconds ([RFC7766] recommends that servers + use timeouts of at least a few seconds). + + Whilst the specification for EDNS(0) [RFC6891] does not specifically + mention AXFRs, it does say: + + | If an OPT record is present in a received request, compliant + | responders MUST include an OPT record in their respective + | responses. + + In this document, the above is clarified to indicate that if an OPT + record is present in a received AXFR request, compliant responders + MUST include an OPT record in each of the subsequent AXFR responses. + Note that this requirement, combined with the use of edns-tcp- + keepalive, enables AXFR servers to signal the desire to close a + connection (when existing transactions have competed) due to low + resources by sending an edns-tcp-keepalive EDNS(0) option with a + timeout of 0 on any AXFR response. This does not signal that the + AXFR is aborted, just that the server wishes to close the connection + as soon as possible. + +6.3.5. Backwards Compatibility + + Certain legacy behaviors were noted in [RFC5936], with provisions + that implementations may want to offer options to fallback to legacy + behavior when interoperating with servers known to not support + [RFC5936]. For purposes of interoperability, IXFR and AXFR + implementations may want to continue offering such configuration + options, as well as supporting some behaviors that were + underspecified prior to this work (e.g., performing IXFR and AXFRs on + separate connections). However, XoT connections should have no need + to do so. + +6.4. Update to RFC 7766 + + [RFC7766] made general implementation recommendations with regard to + TCP/TLS connection handling: + + | To mitigate the risk of unintentional server overload, DNS clients + | MUST take care to minimize the number of concurrent TCP + | connections made to any individual server. It is RECOMMENDED that + | for any given client/server interaction there SHOULD be no more + | than one connection for regular queries, one for zone transfers, + | and one for each protocol that is being used on top of TCP (for + | example, if the resolver was using TLS). However, it is noted + | that certain primary/ secondary configurations with many busy + | zones might need to use more than one TCP connection for zone + | transfers for operational reasons (for example, to support + | concurrent transfers of multiple zones). + + Whilst this recommends a particular behavior for the clients using + TCP, it does not relax the requirement for servers to handle 'mixed' + traffic (regular queries and zone transfers) on any open TCP/TLS + connection. It also overlooks the potential that other transports + might want to take the same approach with regard to using separate + connections for different purposes. + + This specification updates the above general guidance in [RFC7766] to + provide the same separation of connection purpose (regular queries + and zone transfers) for all transports being used on top of TCP. + + Therefore, it is RECOMMENDED that for each protocol used on top of + TCP in any given client/server interaction there SHOULD be no more + than one connection for regular queries and one for zone transfers. + + As an illustration, it could be imagined that in the future such an + interaction could hypothetically include one or all of the following: + + * one TCP connection for regular queries + + * one TCP connection for zone transfers + + * one TLS connection for regular queries + + * one TLS connection for zone transfers + + * one DoH connection for regular queries + + * one DoH connection for zone transfers + + Section 6.3.1 provides specific details of the reasons why more than + one connection for a given transport might be required for zone + transfers from a particular client. + +7. XoT Specification + +7.1. Connection Establishment + + During connection establishment, the Application-Layer Protocol + Negotiation (ALPN) token "dot" [DoT-ALPN] MUST be selected in the TLS + handshake. + +7.2. TLS Versions + + All implementations of this specification MUST use only TLS 1.3 + [RFC8446] or later. + +7.3. Port Selection + + The connection for XoT SHOULD be established using port 853, as + specified in [RFC7858], unless there is mutual agreement between the + primary and secondary to use a port other than port 853 for XoT. + There MAY be agreement to use different ports for AXoT and IXoT or + for different zones. + +7.4. High-Level XoT Descriptions + + It is useful to note that in XoT it is the secondary that initiates + the TLS connection to the primary for an XFR request so that, in + terms of connectivity, the secondary is the TLS client and the + primary is the TLS server. + + The figure below provides an outline of the AXoT mechanism including + NOTIFYs. + + Secondary Primary + + | NOTIFY | + | <-------------------------------- | UDP + | --------------------------------> | + | NOTIFY Response | + | | + | | + | SOA Request | + | --------------------------------> | UDP (or part of + | <-------------------------------- | a TCP/TLS session) + | SOA Response | + | | + | | + | | + | AXFR Request | --- + | --------------------------------> | | + | <-------------------------------- | | + | AXFR Response 1 | | + | (Zone data) | | + | | | + | <-------------------------------- | | TLS + | AXFR Response 2 | | Session + | (Zone data) | | + | | | + | <-------------------------------- | | + | AXFR Response 3 | | + | (Zone data) | --- + | | + + Figure 3: AXoT Mechanism + + The figure below provides an outline of the IXoT mechanism including + NOTIFYs. + + Secondary Primary + + | NOTIFY | + | <-------------------------------- | UDP + | --------------------------------> | + | NOTIFY Response | + | | + | | + | SOA Request | + | --------------------------------> | UDP (or part of + | <-------------------------------- | a TCP/TLS session) + | SOA Response | + | | + | | + | | + | IXFR Request | --- + | --------------------------------> | | + | <-------------------------------- | | + | IXFR Response | | + | (Zone data) | | + | | | TLS + | | | session + | IXFR Request | | + | --------------------------------> | | + | <-------------------------------- | | + | IXFR Response | | + | (Zone data) | --- + + Figure 4: IXoT Mechanism + +7.5. XoT Transfers + + For a zone transfer between two endpoints to be considered protected + with XoT, all XFR requests and responses for that zone MUST be sent + over TLS connections, where at a minimum: + + * The client MUST authenticate the server by use of an + authentication domain name using a Strict Privacy profile, as + described in [RFC8310]. + + * The server MUST validate the client is authorized to request or + proxy a zone transfer by using one or both of the following + methods: + + - mutual TLS (mTLS) + + - an IP-based ACL (which can be either per message or per + connection) combined with a valid TSIG/SIG(0) signature on the + XFR request + + If only one method is selected, then mTLS is preferred because it + provides strong cryptographic protection at both endpoints. + + Authentication mechanisms are discussed in full in Section 9, and the + rationale for the above requirement is discussed in Section 10. + Transfer group policies are discussed in Section 11. + +7.6. XoT Connections + + The details in Section 6 about, e.g., persistent connections and XFR + message handling, are fully applicable to XoT connections as well. + However, any behavior specified here takes precedence for XoT. + + If no TLS connections are currently open, XoT clients MAY send SOA + queries over UDP, TCP, or TLS. + +7.7. XoT vs. ADoT + + As noted earlier, there is currently no specification for encryption + of connections from recursive resolvers to authoritative servers. + Some authoritative servers are experimenting with ADoT, and + opportunistic encryption has also been raised as a possibility; + therefore, it is highly likely that use of encryption by + authoritative servers will evolve in the coming years. + + This raises questions in the short term with regard to TLS connection + and message handling for authoritative servers. In particular, there + is likely to be a class of authoritative servers that wish to use XoT + in the near future with a small number of configured secondaries but + that do not wish to support DoT for regular queries from recursives + in that same time frame. These servers have to potentially cope with + probing and direct queries from recursives and from test servers and + also potential attacks that might wish to make use of TLS to overload + the server. + + [RFC5936] clearly states that non-AXFR session traffic can use an + open connection; however, this requirement needs to be reevaluated + when considering the application of the same model to XoT. Proposing + that a server should also start responding to all queries received + over TLS just because it has enabled XoT would be equivalent to + defining a form of authoritative DoT. This specification does not + propose that, but it also does not prohibit servers from answering + queries unrelated to XFR exchanges over TLS. Rather, this + specification simply outlines in later sections: + + * the utilization of EDE codes by XoT servers in response to queries + on TLS connections that they are not willing to answer (see + Section 7.8) + + * the operational and policy options that an operator of a XoT + server has with regard to managing TLS connections and messages + (see Appendix A) + +7.8. Response RCODES + + XoT clients and servers MUST implement EDE codes. If a XoT server + receives non-XoT traffic it is not willing to answer on a TLS + connection, it SHOULD respond with REFUSED and the extended DNS error + code 21 - Not Supported [RFC8914]. XoT clients should not send any + further queries of this type to the server for a reasonable period of + time (for example, one hour), i.e., long enough that the server + configuration or policy might be updated. + + Historically, servers have used the REFUSED RCODE for many + situations; therefore, clients often had no detailed information on + which to base an error or fallback path when queries were refused. + As a result, the client behavior could vary significantly. XoT + servers that refuse queries must cater to the fact that client + behavior might vary from continually retrying queries regardless of + receiving REFUSED to every query or, at the other extreme, clients + may decide to stop using the server over any transport. This might + be because those clients are either non-XoT clients or do not + implement EDE codes. + +7.9. AXoT Specifics + +7.9.1. Padding AXoT Responses + + The goal of padding AXoT responses is two fold: + + * to obfuscate the actual size of the transferred zone to minimize + information leakage about the entire contents of the zone + + * to obfuscate the incremental changes to the zone between SOA + updates to minimize information leakage about zone update activity + and growth + + Note that the reuse of XoT connections for transfers of multiple + different zones slightly complicates any attempt to analyze the + traffic size and timing to extract information. Also, effective + padding may require the state to be kept because zones may grow and/ + or shrink over time. + + It is noted here that, depending on the padding policies eventually + developed for XoT, the requirement to obfuscate the total zone size + might require a server to create 'empty' AXoT responses, that is, + AXoT responses that contain no RRs apart from an OPT RR containing + the EDNS(0) option for padding. For example, without this + capability, the maximum size that a tiny zone could be padded to + would theoretically be limited if there had to be a minimum of 1 RR + per packet. + + However, as with existing AXFR, the last AXoT response message sent + MUST contain the same SOA that was in the first message of the AXoT + response series in order to signal the conclusion of the zone + transfer. + + [RFC5936] says: + + | Each AXFR response message SHOULD contain a sufficient number of + | RRs to reasonably amortize the per-message overhead, up to the + | largest number that will fit within a DNS message (taking the + | required content of the other sections into account, as described + | below). + + 'Empty' AXoT responses generated in order to meet a padding + requirement will be exceptions to the above statement. For + flexibility, for future proofing, and in order to guarantee support + for future padding policies, it is stated here that secondary + implementations MUST be resilient to receiving padded AXoT responses, + including 'empty' AXoT responses that contain only an OPT RR + containing the EDNS(0) option for padding. + + Recommendations of specific policies for padding AXoT responses are + out of scope for this specification. Detailed considerations of such + policies and the trade-offs involved are expected to be the subject + of future work. + +7.10. IXoT Specifics + +7.10.1. Condensation of Responses + + [RFC1995] says that condensation of responses is optional and MAY be + done. Whilst it does add complexity to generating responses, it can + significantly reduce the size of responses. However, any such + reduction might be offset by increased message size due to padding. + This specification does not update the optionality of condensation + for XoT responses. + +7.10.2. Fallback to AXFR + + Fallback to AXFR can happen, for example, if the server is not able + to provide an IXFR for the requested SOA. Implementations differ in + how long they store zone deltas and how many may be stored at any one + time. + + Just as with IXFR over TCP, after a failed IXFR, an IXoT client + SHOULD request the AXFR on the already open XoT connection. + +7.10.3. Padding of IXoT Responses + + The goal of padding IXoT responses is to obfuscate the incremental + changes to the zone between SOA updates to minimize information + leakage about zone update activity and growth. Both the size and + timing of the IXoT responses could reveal information. + + IXFR responses can vary greatly in size from the order of 100 bytes + for one or two record updates to tens of thousands of bytes for + large, dynamic DNSSEC-signed zones. The frequency of IXFR responses + can also depend greatly on if and how the zone is DNSSEC signed. + + In order to guarantee support for future padding policies, it is + stated here that secondary implementations MUST be resilient to + receiving padded IXoT responses. + + Recommendation of specific policies for padding IXoT responses are + out of scope for this specification. Detailed considerations of such + padding policies, the use of traffic obfuscation techniques (such as + generating fake XFR traffic), and the trade-offs involved are + expected to be the subject of future work. + +7.11. Name Compression and Maximum Payload Sizes + + It is noted here that name compression [RFC1035] can be used in XFR + responses to reduce the size of the payload; however, the maximum + value of the offset that can be used in the name compression pointer + structure is 16384. For some DNS implementations, this limits the + size of an individual XFR response used in practice to something + around the order of 16 KB. In principle, larger payload sizes can be + supported for some responses with more sophisticated approaches + (e.g., by precalculating the maximum offset required). + + Implementations may wish to offer options to disable name compression + for XoT responses to enable larger payloads. This might be + particularly helpful when padding is used, since minimizing the + payload size is not necessarily a useful optimization in this case + and disabling name compression will reduce the resources required to + construct the payload. + +8. Multi-primary Configurations + + This model can provide flexibility and redundancy, particularly for + IXFR. A secondary will receive one or more NOTIFY messages and can + send an SOA to all of the configured primaries. It can then choose + to send an XFR request to the primary with the highest SOA (or based + on other criteria, e.g., RTT). + + When using persistent connections, the secondary may have a XoT + connection already open to one or more primaries. Should a secondary + preferentially request an XFR from a primary to which it already has + an open XoT connection or the one with the highest SOA (assuming it + doesn't have a connection open to it already)? + + Two extremes can be envisaged here. The first one can be considered + a 'preferred primary connection' model. In this case, the secondary + continues to use one persistent connection to a single primary until + it has reason not to. Reasons not to might include the primary + repeatedly closing the connection, long query/response RTTs on + transfers, or the SOA of the primary being an unacceptable lag behind + the SOA of an alternative primary. + + The other extreme can be considered a 'parallel primary connection' + model. Here, a secondary could keep multiple persistent connections + open to all available primaries and only request XFRs from the + primary with the highest serial number. Since normally the number of + secondaries and primaries in direct contact in a transfer group is + reasonably low, this might be feasible if latency is the most + significant concern. + + Recommendation of a particular scheme is out of scope of this + document, but implementations are encouraged to provide configuration + options that allow operators to make choices about this behavior. + +9. Authentication Mechanisms + + To provide context to the requirements in Section 7.5, this section + provides a brief summary of some of the existing authentication and + validation mechanisms (both transport independent and TLS specific) + that are available when performing zone transfers. Section 10 then + discusses in more detail specifically how a combination of TLS + authentication, TSIG, and IP-based ACLs interact for XoT. + + In this document, the mechanisms are classified based on the + following properties: + + Data Origin Authentication (DO): + Authentication 1) of the fact that the DNS message originated from + the party with whom credentials were shared and 2) of the data + integrity of the message contents (the originating party may or + may not be the party operating the far end of a TCP/TLS connection + in a 'proxy' scenario). + + Channel Confidentiality (CC): + Confidentiality of the communication channel between the client + and server (i.e., the two endpoints of a TCP/TLS connection) from + passive surveillance. + + Channel Authentication (CA): + Authentication of the identity of the party to whom a TCP/TLS + connection is made (this might not be a direct connection between + the primary and secondary in a proxy scenario). + +9.1. TSIG + + TSIG [RFC8945] provides a mechanism for two or more parties to use + shared secret keys that can then be used to create a message digest + to protect individual DNS messages. This allows each party to + authenticate that a request or response (and the data in it) came + from the other party, even if it was transmitted over an unsecured + channel or via a proxy. + + Properties: Data origin authentication. + +9.2. SIG(0) + + SIG(0) [RFC2931] similarly provides a mechanism to digitally sign a + DNS message but uses public key authentication, where the public keys + are stored in DNS as KEY RRs and a private key is stored at the + signer. + + Properties: Data origin authentication. + +9.3. TLS + +9.3.1. Opportunistic TLS + + Opportunistic TLS for DoT is defined in [RFC8310] and can provide a + defense against passive surveillance, providing on-the-wire + confidentiality. Essentially: + + * if clients know authentication information for a server, they + SHOULD try to authenticate the server, + + * if this fails or clients do not know the information, they MAY + fallback to using TLS without authentication, or + + * clients MAY fallback to using cleartext if TLS is not available. + + As such, it does not offer a defense against active attacks (e.g., an + on-path active attacker on the connection from client to server) and + is not considered as useful for XoT. + + Properties: None guaranteed. + +9.3.2. Strict TLS + + Strict TLS for DoT [RFC8310] requires that a client is configured + with an authentication domain name (and/or Subject Public Key Info + (SPKI) pin set) that MUST be used to authenticate the TLS handshake + with the server. If authentication of the server fails, the client + will not proceed with the connection. This provides a defense for + the client against active surveillance, providing client-to-server + authentication and end-to-end channel confidentiality. + + Properties: Channel confidentiality and channel authentication (of + the server). + +9.3.3. Mutual TLS + + This is an extension to Strict TLS [RFC8310] that requires that a + client is configured with an authentication domain name (and/or SPKI + pin set) and a client certificate. The client offers the certificate + for authentication by the server, and the client can authenticate the + server the same way as in Strict TLS. This provides a defense for + both parties against active surveillance, providing bidirectional + authentication and end-to-end channel confidentiality. + + Properties: Channel confidentiality and mutual channel + authentication. + +9.4. IP-Based ACL on the Primary + + Most DNS server implementations offer an option to configure an IP- + based ACL, which is often used in combination with TSIG-based ACLs to + restrict access to zone transfers on primary servers on a per-query + basis. + + This is also possible with XoT, but it must be noted that, as with + TCP, the implementation of such an ACL cannot be enforced on the + primary until an XFR request is received on an established + connection. + + As discussed in Appendix A, an IP-based per-connection ACL could also + be implemented where only TLS connections from recognized secondaries + are accepted. + + Properties: Channel authentication of the client. + +9.5. ZONEMD + + For completeness, ZONEMD [RFC8976] ("Message Digest for DNS Zones") + is described here. The ZONEMD message digest is a mechanism that can + be used to verify the content of a standalone zone. It is designed + to be independent of the transmission channel or mechanism, allowing + a general consumer of a zone to do origin authentication of the + entire zone contents. Note that the current version of [RFC8976] + states: + + | As specified herein, ZONEMD is impractical for large, dynamic + | zones due to the time and resources required for digest + | calculation. However, the ZONEMD record is extensible so that new + | digest schemes may be added in the future to support large, + | dynamic zones. + + It is complementary but orthogonal to the above mechanisms and can be + used in conjunction with XoT but is not considered further here. + +10. XoT Authentication + + It is noted that zone transfer scenarios can vary from a simple + single primary/secondary relationship where both servers are under + the control of a single operator to a complex hierarchical structure + that includes proxies and multiple operators. Each deployment + scenario will require specific analysis to determine which + combination of authentication methods are best suited to the + deployment model in question. + + The XoT authentication requirement specified in Section 7.5 addresses + the issue of ensuring that the transfers are encrypted between the + two endpoints directly involved in the current transfers. The + following table summarizes the properties of a selection of the + mechanisms discussed in Section 9. The two-letter abbreviations for + the properties are used below: (S) indicates the secondary and (P) + indicates the primary. + + +================+=======+=======+=======+=======+=======+=======+ + | Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) | + +================+=======+=======+=======+=======+=======+=======+ + | Strict TLS | | Y | Y | | Y | | + +----------------+-------+-------+-------+-------+-------+-------+ + | Mutual TLS | | Y | Y | | Y | Y | + +----------------+-------+-------+-------+-------+-------+-------+ + | ACL on primary | | | | | | Y | + +----------------+-------+-------+-------+-------+-------+-------+ + | TSIG | Y | | | Y | | | + +----------------+-------+-------+-------+-------+-------+-------+ + + Table 1: Properties of Authentication Methods for XoT + + Based on this analysis, it can be seen that: + + * Using just mutual TLS can be considered a standalone solution + since both endpoints are cryptographically authenticated. + + * Using secondary-side Strict TLS with a primary-side IP-based ACL + and TSIG/SIG(0) combination provides sufficient protection to be + acceptable. + + Using just an IP-based ACL could be susceptible to attacks that can + spoof TCP IP addresses; using TSIG/SIG(0) alone could be susceptible + to attacks that were able to capture such messages should they be + accidentally sent in cleartext by any server with the key. + +11. Policies for Both AXoT and IXoT + + Whilst the protection of the zone contents in a transfer between two + endpoints can be provided by the XoT protocol, the protection of all + the transfers of a given zone requires operational administration and + policy management. + + The entire group of servers involved in XFR for a particular set of + zones (all the primaries and all the secondaries) is called the + 'transfer group'. + + In order to assure the confidentiality of the zone information, the + entire transfer group MUST have a consistent policy of using XoT. If + any do not, this is a weak link for attackers to exploit. For + clarification, this means that within any transfer group both AXFRs + and IXFRs for a zone MUST all use XoT. + + An individual zone transfer is not considered protected by XoT unless + both the client and server are configured to use only XoT, and the + overall zone transfer is not considered protected until all members + of the transfer group are configured to use only XoT with all other + transfers servers (see Section 12). + + A XoT policy MUST specify if: + + * mutual TLS is used and/or + + * an IP-based ACL and TSIG/SIG(0) combination is used. + + Since this may require configuration of a number of servers who may + be under the control of different operators, the desired consistency + could be hard to enforce and audit in practice. + + Certain aspects of the policies can be relatively easy to test + independently, e.g., by requesting zone transfers without TSIG, from + unauthorized IP addresses or over cleartext DNS. Other aspects, such + as if a secondary will accept data without a TSIG digest or if + secondaries are using Strict as opposed to Opportunistic TLS, are + more challenging. + + The mechanics of coordinating or enforcing such policies are out of + the scope of this document but may be the subject of future + operational guidance. + +12. Implementation Considerations + + Server implementations may want to also offer options that allow ACLs + on a zone to specify that a specific client can use either XoT or + TCP. This would allow for flexibility while clients are migrating to + XoT. + + Client implementations may similarly want to offer options to cater + to the multi-primary case where the primaries are migrating to XoT. + +13. Operational Considerations + + If the options described in Section 12 are available, such + configuration options MUST only be used in a 'migration mode' and + therefore should be used with great care. + + It is noted that use of a TLS proxy in front of the primary server is + a simple deployment solution that can enable server-side XoT. + +14. IANA Considerations + + This document has no IANA actions. + +15. Security Considerations + + This document specifies a security measure against a DNS risk: the + risk that an attacker collects entire DNS zones through eavesdropping + on cleartext DNS zone transfers. + + This does not mitigate: + + * the risk that some level of zone activity might be inferred by + observing zone transfer sizes and timing on encrypted connections + (even with padding applied), in combination with obtaining SOA + records by directly querying authoritative servers, + + * the risk that hidden primaries might be inferred or identified via + observation of encrypted connections, or + + * the risk of zone contents being obtained via zone enumeration + techniques. + + Security concerns of DoT are outlined in [RFC7858] and [RFC8310]. + +16. References + +16.1. Normative References + + [DoT-ALPN] IANA, "TLS Application-Layer Protocol Negotiation (ALPN) + Protocol IDs", <https://www.iana.org/assignments/tls- + extensiontype-values/>. + + [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>. + + [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + DOI 10.17487/RFC1995, August 1996, + <https://www.rfc-editor.org/info/rfc1995>. + + [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, + August 1996, <https://www.rfc-editor.org/info/rfc1996>. + + [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>. + + [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>. + + [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol + (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, + <https://www.rfc-editor.org/info/rfc5936>. + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + <https://www.rfc-editor.org/info/rfc6973>. + + [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and + D. Wessels, "DNS Transport over TCP - Implementation + Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, + <https://www.rfc-editor.org/info/rfc7766>. + + [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The + edns-tcp-keepalive EDNS0 Option", RFC 7828, + DOI 10.17487/RFC7828, April 2016, + <https://www.rfc-editor.org/info/rfc7828>. + + [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>. + + [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>. + + [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles + for DNS over TLS and DNS over DTLS", RFC 8310, + DOI 10.17487/RFC8310, March 2018, + <https://www.rfc-editor.org/info/rfc8310>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, + January 2019, <https://www.rfc-editor.org/info/rfc8499>. + + [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. + Lawrence, "Extended DNS Errors", RFC 8914, + DOI 10.17487/RFC8914, October 2020, + <https://www.rfc-editor.org/info/rfc8914>. + + [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>. + +16.2. Informative References + + [BIND] ISC, "BIND 9.16.16", <https://www.isc.org/bind/>. + + [DPRIVE-DNSOQUIC] + Huitema, C., Dickinson, S., and A. Mankin, "Specification + of DNS over Dedicated QUIC Connections", Work in Progress, + Internet-Draft, draft-ietf-dprive-dnsoquic-03, 12 July + 2021, <https://datatracker.ietf.org/doc/html/draft-ietf- + dprive-dnsoquic-03>. + + [NIST-GUIDE] + Chandramouli, R. and S. Rose, "Secure Domain Name System + (DNS) Deployment Guide", September 2013, + <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ + NIST.SP.800-81-2.pdf>. + + [NSD] NLnet Labs, "NSD 4.3.6", + <https://www.nlnetlabs.nl/projects/nsd/about/>. + + [NSEC3-attacks] + Goldberg, S., Naor, N., Papadopoulos, D., Reyzin, L., + Vasant, S., and A. Ziv, "Stretching NSEC3 to the Limit: + Efficient Zone Enumeration Attacks on NSEC3 Variants", + February 2015, + <https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf>. + + [NSEC5] Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and + D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of + Existence", Work in Progress, Internet-Draft, draft- + vcelak-nsec5-08, 29 December 2018, + <https://datatracker.ietf.org/doc/html/draft-vcelak- + nsec5-08>. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + DOI 10.17487/RFC1982, August 1996, + <https://www.rfc-editor.org/info/rfc1982>. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, + <https://www.rfc-editor.org/info/rfc5155>. + + [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms + for DNS (EDNS(0))", STD 75, RFC 6891, + DOI 10.17487/RFC6891, April 2013, + <https://www.rfc-editor.org/info/rfc6891>. + + [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS + (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, + <https://www.rfc-editor.org/info/rfc8484>. + + [RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. + Hardaker, "Message Digest for DNS Zones", RFC 8976, + DOI 10.17487/RFC8976, February 2021, + <https://www.rfc-editor.org/info/rfc8976>. + + [RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076, + DOI 10.17487/RFC9076, July 2021, + <https://www.rfc-editor.org/info/rfc9076>. + + [TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS + Encrypted Client Hello", Work in Progress, Internet-Draft, + draft-ietf-tls-esni-13, 12 August 2021, + <https://datatracker.ietf.org/doc/html/draft-ietf-tls- + esni-13>. + +Appendix A. XoT Server Connection Handling + + This appendix provides a non-normative outline of the pros and cons + of XoT server connection-handling options. + + For completeness, it is noted that an earlier draft version of this + document suggested using a XoT-specific ALPN to negotiate TLS + connections that supported only a limited set of queries (SOA, XFRs); + however, this did not gain support. Reasons given included + additional code complexity and the fact that XoT and ADoT are both + DNS wire format and so should share the "dot" ALPN. + +A.1. Listening Only on a Specific IP Address for TLS + + Obviously, a name server that hosts a zone and services queries for + the zone on an IP address published in an NS record may wish to use a + separate IP address for XoT to listen for TLS, only publishing that + address to its secondaries. + + Pros: Probing of the public IP address will show no support for TLS. + ACLs will prevent zone transfer on all transports on a per-query + basis. + + Cons: Attackers passively observing traffic will still be able to + observe TLS connections to the separate address. + +A.2. Client-Specific TLS Acceptance + + Primaries that include IP-based ACLs and/or mutual TLS in their + authentication models have the option of only accepting TLS + connections from authorized clients. This could be implemented + either using a proxy or directly in the DNS implementation. + + Pros: Connection management happens at setup time. The maximum + number of TLS connections a server will have to support can be + easily assessed. Once the connection is accepted, the server + might well be willing to answer any query on that connection since + it is coming from a configured secondary, and a specific response + policy on the connection may not be needed (see below). + + Cons: Currently, none of the major open-source implementations of a + DNS authoritative server support such an option. + +A.3. SNI-Based TLS Acceptance + + Primaries could also choose to only accept TLS connections based on a + Server Name Indication (SNI) that was published only to their + secondaries. + + Pros: Reduces the number of accepted connections. + + Cons: As above. Also, this is not a recommended use of SNI. For + SNIs sent in the clear, this would still allow attackers passively + observing traffic to potentially abuse this mechanism. The use of + Encrypted Client Hello [TLS-ESNI] may be of use here. + +A.4. Transport-Specific Response Policies + + Some primaries might rely on TSIG/SIG(0) combined with per-query, IP- + based ACLs to authenticate secondaries. In this case, the primary + must accept all incoming TLS/TCP connections and then apply a + transport-specific response policy on a per-query basis. + + As an aside, whilst [RFC7766] makes a general purpose distinction in + the advice to clients about their usage of connections (between + regular queries and zone transfers), this is not strict, and nothing + in the DNS protocol prevents using the same connection for both types + of traffic. Hence, a server cannot know the intention of any client + that connects to it; it can only inspect the messages it receives on + such a connection and make per-query decisions about whether or not + to answer those queries. + + Example policies a XoT server might implement are: + + strict: REFUSE all queries on TLS connections, except SOA and + authorized XFR requests + + moderate: REFUSE all queries on TLS connections until one is + received that is signed by a recognized TSIG/SIG(0) key, + then answer all queries on the connection after that + + complex: apply a heuristic to determine which queries on a TLS + connections to REFUSE + + relaxed: answer all non-XoT queries on all TLS connections with + the same policy applied to TCP queries + + Pros: Allows for flexible behavior by the server that could be + changed over time. + + Cons: The server must handle the burden of accepting all TLS + connections just to perform XFRs with a small number of + secondaries. Client behavior to a REFUSED response is not clearly + defined (see Section 7.8). Currently, none of the major open- + source implementations of a DNS authoritative server offer an + option for different response policies in different transports + (but such functionality could potentially be implemented using a + proxy). + +A.4.1. SNI-Based Response Policies + + In a similar fashion, XoT servers might use the presence of an SNI in + the Client Hello to determine which response policy to initially + apply to the TLS connections. + + Pros: This has the potential to allow a clean distinction between a + XoT service and any future DoT-based service for answering + recursive queries. + + Cons: As above. + +Acknowledgements + + The authors thank Tony Finch, Benno Overeinder, Shumon Huque, Tim + Wicinski, and many other members of DPRIVE for review and + discussions. + + The authors particularly thank Peter van Dijk, Ondrej Sury, Brian + Dickson, and several other open-source DNS implementers for valuable + discussion and clarification on the issue associated with pipelining + XFR queries and handling out-of-order/intermingled responses. + +Contributors + + Significant contributions to the document were made by: + + Han Zhang + Salesforce + San Francisco, CA + United States of America + + Email: hzhang@salesforce.com + + +Authors' Addresses + + Willem Toorop + NLnet Labs + Science Park 400 + 1098 XH Amsterdam + Netherlands + + Email: willem@nlnetlabs.nl + + + Sara Dickinson + Sinodun IT + Magdalen Centre + Oxford Science Park + Oxford + OX4 4GA + United Kingdom + + Email: sara@sinodun.com + + + Shivan Sahib + Brave Software + Vancouver BC + Canada + + Email: shivankaulsahib@gmail.com + + + Pallavi Aras + Salesforce + Herndon, VA + United States of America + + Email: paras@salesforce.com + + + Allison Mankin + Salesforce + Herndon, VA + United States of America + + Email: allison.mankin@gmail.com |