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

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.¶

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

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

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.¶

7. XoT Specification

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

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

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).¶

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.¶

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

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.¶

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:¶

Authors' Addresses