DNS Zone Transfer over TLS
updates
Extracted elements (29)
A XoT-specific ALPN (to restrict TLS connections to SOA and XFR queries only) was proposed in an earlier draft but rejected. Reasons: additional code complexity and the fact that XoT and ADoT both use DNS wire format and should share the 'dot' ALPN token.
Opportunistic TLS is explicitly deemed not useful for XoT because it offers no defense against active attacks such as an on-path attacker. XoT requires at minimum Strict TLS so the secondary can cryptographically authenticate the primary before sending zone transfer requests.
Padding of AXoT responses serves two goals: obfuscating the total size of the transferred zone and obfuscating incremental changes between SOA updates. Effective padding may require stateful tracking since zones grow and shrink over time. Empty AXoT responses (containing only an OPT RR with padding) must be supported to meet padding requirements for small zones.
The threat model does not treat the existence of a zone, the act of zone transfer, or the identities of name servers as sensitive information, because much of this can be obtained via active DNS scanning and traffic patterns reveal server relationships even when traffic is encrypted.
After a failed IXFR over XoT, an IXoT client SHOULD request the AXFR on the already open XoT connection rather than opening a new connection. Fallback to AXFR occurs when the primary cannot provide IXFR for the requested SOA serial.
Legacy fallback behaviors documented in RFC 5936 (e.g., performing IXFR and AXFR on separate connections) may remain available in existing XFR-over-TCP implementations for backwards compatibility, but XoT connections have no need to support such legacy behaviors since XoT implementations are required to follow optimized TCP usage from the start.
XoT servers that do not wish to support DoT for general recursive queries may refuse non-XFR queries on TLS connections with REFUSED and EDE code 21. However, servers must cater to non-XoT clients and non-EDE clients whose behavior upon REFUSED varies from continual retry to complete abandonment of the server across all transports.
A XoT policy MUST specify whether mutual TLS is used and/or whether an IP-based ACL and TSIG/SIG(0) combination is used for authenticating zone transfers.
All implementations of XoT MUST use only TLS 1.3 or later. No earlier versions of TLS are permitted for XoT connections.
An AXFR-over-TCP server compliant with this specification MUST be able to handle multiple concurrent AXFR sessions on a single TCP connection. Response streams for concurrent AXFRs MAY be intermingled, and pipelining clients MUST be able to handle intermingled responses.
An IXFR-over-TCP server compliant with this specification MUST be able to handle multiple concurrent IXFR requests on a single TCP connection for the same and different zones, and SHOULD send responses as soon as available, which may be out of order relative to the requests.
During TLS connection establishment for XoT, the ALPN token "dot" MUST be selected in the TLS handshake.
For a zone transfer to be considered protected with XoT, all XFR requests and responses for that zone MUST be sent over TLS. The client MUST authenticate the server via a Strict Privacy profile (RFC 8310), and the server MUST validate the client is authorized using mTLS and/or an IP-based ACL combined with a valid TSIG/SIG(0) signature.
If an OPT record is present in a received AXFR request, compliant responders MUST include an OPT record in each subsequent AXFR response. This enables servers to signal a desire to close a connection via edns-tcp-keepalive with a timeout of 0.
Implementations MUST use RFC 7766 to optimize the use of TCP connections for zone transfers. XFR clients sending multiple XFRs MAY choose not to pipeline those queries, as XFRs are not as latency sensitive as other queries and carry significantly more state.
Implementations SHOULD use the edns-tcp-keepalive EDNS(0) option (RFC 7828) to manage persistent connections for XFR transfers, as this is more flexible than fixed timeouts. Servers that do not support edns-tcp-keepalive allow the client to keep the connection open for a few seconds.
It is RECOMMENDED that for each protocol used on top of TCP in a given client/server interaction there SHOULD be no more than one connection for regular queries and one for zone transfers. This updates RFC 7766's guidance and extends it beyond TCP to all transports.
Secondary implementations MUST be resilient to receiving padded AXoT responses, including 'empty' AXoT responses that contain only an OPT RR with the EDNS(0) padding option and no DNS resource records. Secondary implementations MUST also be resilient to receiving padded IXoT responses.
Servers MAY limit the number of concurrent IXFRs, AXFRs, or total XFR transfers. Servers SHOULD return SERVFAIL when this limit is hit, since it is a transient error and a retry at a later time might succeed.
The connection for XoT SHOULD be established using port 853, as specified in RFC 7858, unless there is mutual agreement between primary and secondary to use a different port. Different ports MAY be used for AXoT and IXoT or for different zones.
The entire transfer group (all primaries and secondaries for a set of zones) MUST have a consistent policy of using XoT. Both AXFRs and IXFRs for a zone MUST all use XoT; any member not using XoT is a weak link for attackers to exploit.
The last AXoT response message 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.
XFR-over-TCP clients SHOULD reuse any existing open TCP connection when starting a new XFR request to the same primary or issuing SOA queries, rather than opening a new connection. The number of TCP connections between a secondary and primary SHOULD be minimized.
XoT clients and servers MUST implement EDE (Extended DNS Error) 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 EDE code 21 - Not Supported.
DNS zone contents are privacy-sensitive: they may include personal information embedded in hostnames, location references, inter-organizational relationships, and all endpoint IP addresses including private IPv6 addresses. Full zone exposure facilitates reconnaissance and attack targeting, and there may be regulatory reasons requiring confidentiality, motivating encrypted zone transfers.
Authentication mechanisms for XoT are classified by three properties: Data Origin Authentication (DO) — verifies message origin and integrity; Channel Confidentiality (CC) — encrypts the connection; Channel Authentication (CA) — authenticates the connection endpoint identity. mTLS provides CC and CA for both sides; TSIG provides DO for both sides; IP-based ACL provides CA for the client only.
The 'transfer group' is the entire set of servers involved in XFR for a particular set of zones (all primaries and secondaries). Consistent XoT policy across the entire transfer group is required for confidentiality; a single non-XoT member is a weak link.
XoT (XFR-over-TLS) is the protocol defined in this document for performing DNS zone transfers over TLS 1.3+. AXoT refers to AXFR over TLS; IXoT refers to IXFR over TLS. In XoT, the secondary acts as the TLS client and the primary acts as the TLS server.
XoT mitigates zone content collection via passive eavesdropping on cleartext zone transfers. It does not mitigate: inference of zone activity from encrypted connection sizes and timing; identification of hidden primaries from encrypted connection patterns; or zone content collection via zone enumeration techniques such as NSEC walking.