RFC 9103

DNS Zone Transfer over TLS

📅 published August 2021, from ietf

Title Block ✨

Okay bestie, let's get the paperwork out of the way first 💅 This one is RFC 9103, titled "DNS Zone Transfer over TLS" 🎀. It was written by W. Toorop (NLnet Labs), S. Dickinson (Sinodun IT), S. Sahib (Brave Software), P. Aras, and A. Mankin (Salesforce) 🫶. It's a Standards Track document, published in August 2021 under ISSN 2070-1721 🌈.

It updates RFC 1995, RFC 5936, and RFC 7766 🔥, so those older specs get some fresh clarifications. It doesn't obsolete anything 💀.

Abstract 💜

Okay so zone transfers are sent in cleartext, which means an attacker can literally eavesdrop on the network and collect the whole zone 😭. TSIG already exists to make sure only authorized clients can do a zone transfer, but it doesn't add confidentiality at all 🙈. So this doc says: wrap zone transfers in TLS instead ✨, which they call XFR over TLS (XoT). It also tweaks RFC 1995 and RFC 5936 for using TCP connections efficiently, and RFC 7766 for how many connections a client and server should have per transport 🦋.

Status of This Memo 🎀

This is an Internet Standards Track document 👑.

It's a product of the IETF and represents the community's consensus. It got public review and was approved by the IESG 💅. If you want more on Internet Standards, check out Section 2 of RFC 7841 🧚. Errata and feedback live at https://www.rfc-editor.org/info/rfc9103 🍓.

Copyright (c) 2021 IETF Trust and the document authors, all rights reserved 💖. It's subject to BCP 78 and the IETF Trust's Legal Provisions, which are in effect on the publication date 📜. Please read them, because they spell out your rights ✨. Any code pulled out of this doc has to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and it comes with no warranty 🫶.

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 🌷

Okay so DNS has a bunch of privacy holes, and [RFC9076] goes through them in detail 🙈. Most of the attention so far has gone to query privacy between stub resolvers and recursive resolvers 💅, with Standards Track docs for DNS over TLS (DoT) [RFC7858] and DNS over HTTPS (DoH) [RFC8484], plus a proposal for DNS over QUIC [DPRIVE-DNSOQUIC] ✨. There's ongoing work on DNS privacy requirements between recursive resolvers and authoritative servers, and some ideas about how authoritative servers might signal DoT support 🦋. But right now there's no RFC that actually defines recursive-to-authoritative DNS over TLS (ADoT) 💀.

[RFC9076] says a stub resolver's DNS query transactions are not public and need protection 🫶. But when it comes to zone transfer [RFC1995] [RFC5936], it only says:

| Privacy risks for the holder of a zone (the risk that someone gets | the data) are discussed in [RFC5155] and [RFC5936].

So wait, why is dumping a whole zone a privacy problem? 🤔 The zone can include names of people used in host names 😭. Best practice is to not put personal info in domain names, but honestly, tons of domains do anyway 🙈. The zone can also reveal locations that hint at where the people in the org are, and it can reference other organizations too 🌍. Examples are:

  • Person-laptop.example.org
  • MX-for-Location.example.org
  • Service-tenant-from-another-org.example.org

On top of that, the full zone exposes every IP address held in the DNS records 🎯. That makes recon and targeting way easier, especially for IPv6 addresses or private networks 💀. There may also be regulatory, policy, or other reasons the full zone contents must be treated as private 🔒.

Neither of the RFCs mentioned in [RFC9076] thinks about someone grabbing the data by eavesdropping on network connections 👀. They only consider enumeration or unauthorized transfer, which the next paragraphs cover 🦋.

Zone enumeration is totally possible for DNSSEC zones that use NSEC 😭. Asking for the authenticated denial-of-existence records lets a client walk the entire zone, no cap 💀. [RFC5155] introduces NSEC3 to make enumeration harder for DNSSEC-signed zones, with the goal of making it as hard to enumerate as an unsigned zone 🧚. It's widely used, but it's been shown that zone walking is still possible for precomputed NSEC3 using attacks like those in [NSEC3-attacks] 😬. That led to more work on an alternative for DNSSEC-authenticated denial of existence (NSEC5 [NSEC5]), but there are still open questions about whether it's practical 🤷‍♀️.

[RFC5155] doesn't cover data obtained outside of zone enumeration, and neither does [NSEC5] 🙅‍♀️. Stopping eavesdropping on zone transfers (what this doc is about) is orthogonal to stopping zone enumeration, even though both protect the same information ✨.

[RFC5936] uses TSIG [RFC8945] to authorize clients of a zone transfer and to check data integrity 🔐. It doesn't ask for confidentiality, and TSIG doesn't do encryption either 💔.

Section 8 of the NIST document "Secure Domain Name System (DNS) Deployment Guide" [NIST-GUIDE] goes deeper on restricting zone transfers with Access Control Lists (ACLs) and TSIG 📚. It also mentions that some deployments might protect zone transfers at a lower network layer, like IPsec 🌸.

Also, in all the common open-source implementations, ACLs are applied per query (at the time of writing) 📝. Requests usually happen over TCP connections, so authoritative servers have to accept any TCP connection and then authenticate each zone transfer (XFR) request one by one 😩.

Because AXFR (authoritative transfer) and IXFR (incremental zone transfer) are usually done over TCP by authoritative DNS implementations 🖥️, encrypting zone transfers with TLS [RFC8499], closely based on DoT [RFC7858], seems like an easy win 💖. This document says how to use TLS (1.3 or later) as the transport to stop zone collection from zone transfers 🔥.

This doc also updates the earlier zone transfer specs to clarify and extend them, mostly around TCP usage 🌈:

  • [RFC1995] (IXFR) and [RFC5936] (AXFR) both get more specification on efficient use of TCP connections ⭐.
  • Section 6.2.2 of [RFC7766] ("DNS Transport over TCP - Implementation Requirements") gets a new recommendation about how many connections a client and server should have 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] 📚. As in [RFC8499], the terms 'primary' and 'secondary' are used for two servers doing 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 👑

Part 1 of 7 done, bestie 🫶 Say the word and I'll drop Part 2 with Section 3 (Threat Model) onward 💅💖

3. Threat Model ✨

okay so let's talk about what we're actually protecting here 🔐 The threat model is all about the contents and size of the zone being sensitive, and they need to stay protected while the zone is being transferred 💖

BUT here's the tea: the threat model does not treat these things as secret 🙈

  • the existence of a zone 🌸
  • the fact that a zone transfer is happening between two entities 🦋
  • the identities of the name servers hosting a zone 🧚 (this includes hidden primaries and secondaries, and the ones serving the zone directly)

So the mechanism doesn't even try to hide that stuff 💅 Why? Two big reasons, bestie:

  • a lot of this info can be found through various methods, including actively scanning the DNS 🔍
  • an attacker who can watch network traffic can lowkey figure out how name servers are related just from traffic patterns 👀, even when some or all of that traffic is encrypted (for current deployments, anyway) 🔒

The model also does not cover attacks on whatever triggers a zone transfer, like NOTIFY messages 📣

Also, real talk 💀 simply using XoT tells everyone the zone owner wants the contents kept confidential. So an attacker with the power to do it could block it, for example by blocking port 853 🚫 But ngl, this problem shows up with any mechanism that tries to encrypt data between name servers, IPsec included 🤷‍♀️

4. Design Considerations for XoT 💜

Here are the principles we kept in mind when designing XoT 🎀

Confidentiality 🔐: using an encrypted transport for zone transfers will shut down zone content leakage that can happen through passive surveillance. Slay 💅

Authentication 🫶: single or mutual TLS (mTLS) authentication, used together with ACLs, can complement TSIG and could even be an alternative to it ✨

Performance 🚀:

  • Existing AXFR and IXFR mechanisms are weighed down by backwards compatibility with older implementations built on the original specs in [RFC1034] and [RFC1035] 😭 For example, some older AXFR servers don't support using one TCP connection for multiple AXFR sessions, or for XFRs of different zones, because they haven't been updated to follow the guidance in [RFC5936]. Any XoT implementation would obviously be REQUIRED to implement optimized and interoperable transfers, as described in [RFC5936], e.g., transferring multiple zones over one connection 🧚
  • Current TCP usage for IXFR is suboptimal in some cases, because connections are frequently closed after a single IXFR 💀

5. Connection and Data Flows in Existing XFR Mechanisms 🦋

okay so the original spec for zone transfers in [RFC1034] and [RFC1035] was based on polling 📊 A secondary would periodically query for the SOA (start of zone authority) record, based on the refresh timer, to figure out whether it needed an AXFR.

Then [RFC1995] and [RFC1996] came along and introduced IXFR and NOTIFY, respectively, so updates could propagate promptly 🚀 This has mostly replaced AXFR wherever possible, especially for dynamically updated zones.

[RFC5936] later redefined AXFR to improve performance and interoperability ✨

In this document, the term 'XFR mechanism' describes the whole set of message exchanges between a secondary and a primary that ends with a successful AXFR or IXFR request/response 🎀 That 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 covers all the possible permutations, and it helps tell the 'XFR mechanism' apart from a single XFR request/response exchange 💅

5.1. AXFR Mechanism 🌈

Here's the outline of an AXFR mechanism, NOTIFYs included:

   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 start an AXFR based on a refresh timer or scheduled/triggered zone maintenance ⏰
  2. The secondary will normally (but not always) send an SOA query to the primary to get the serial number of the zone the primary holds 🔍
  3. If the primary serial is higher than the secondary's serial (using Serial Number Arithmetic [RFC1982]), the secondary sends an AXFR request (over TCP) to the primary 🚀 After that, the AXFR data flows in one or more AXFR responses on the TCP connection. [RFC5936] calls this specific step an 'AXFR session', meaning an AXFR query message plus the sequence of AXFR response messages returned for it 💜

[RFC5936] re-specified AXFR, adding extra guidance beyond what [RFC1034] and [RFC1035] provided, and, importantly, specified that AXFR MUST use TCP as its transport protocol 🔐

Also, Sections 4.1, 4.1.1, and 4.1.2 of [RFC5936] give improved guidance for AXFR clients and servers on reusing TCP connections for multiple AXFRs and for AXFRs of different zones 🎀 But [RFC5936] had to stay backwards compatible with some very early, basic AXFR implementations 😩 For example, it describes how the SOA query can also happen on this same connection. Unfortunately, that can cause interoperability problems with older implementations that only support the trivial case of one AXFR per connection 💀

5.2. IXFR Mechanism 🦋

Here's the outline of the IXFR mechanism, NOTIFYs included:

   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 start an IXFR based on a refresh timer or scheduled/triggered zone maintenance ⏰
  2. The secondary will normally (but not always) send an SOA query to the primary to get the serial number of the zone the primary holds 🔍
  3. If the primary serial is higher than the secondary's serial (using Serial Number Arithmetic [RFC1982]), the secondary sends an IXFR request to the primary, and then the primary sends back an IXFR response 🔄

[RFC1995] specifies that IXFR MAY use UDP if the entire IXFR response can fit in a single DNS packet, and otherwise TCP is used. Here's what it actually says:

Thus, a client should first make an IXFR query using UDP.

So there might be a fourth step above, where the client falls back to IXFR over TCP 🔁 There could also be an extra step where the secondary has to fall back to AXFR because, for example, the primary doesn't support IXFR 😬

That said, it's worth noting that most of the widely used open-source authoritative name server implementations (including both [BIND] and [NSD]) do IXFR over TCP by default in their latest releases 🎉 For BIND, TCP connections are sometimes used for SOA queries too, but in general they aren't used persistently and get closed once an IXFR is completed 👋

5.3. Data Leakage of NOTIFY and SOA Message Exchanges 🕵️‍♀️

This section gives the reasoning for considering encryption of the other messages in the XFR mechanism 🔐

Since the SOA of the published zone can be trivially discovered by just querying the publicly available authoritative servers, leakage of this resource record (RR) through such a direct query is not discussed in the following sections 🙈

5.3.1. NOTIFY 📣

Unencrypted NOTIFY messages identify the 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) defined for NOTIFY at the time of writing is SOA, this doesn't pose a potential leak 💅

5.3.2. SOA 🔍

For hidden XFR servers (either primaries or secondaries), an SOA response coming directly from that server additionally leaks the degree of SOA serial number lag of any downstream secondary of that server 😱

6. Updates to Existing Specifications 🎀

okay so bestie, for convenience this doc uses "XFR over TCP" as a catch-all for both IXFR over TCP and AXFR over TCP 💅. So whenever a statement uses that term, it updates both [RFC1995] and [RFC5936], and it implicitly applies to XoT too. The XoT-specific differences get their own spot in Section 7 🦋.

Both [RFC1995] and [RFC5936] came out before TCP was a widely supported transport for DNS 🌸. [RFC1995] doesn't say anything about optimizing IXFRs over TCP or reusing already open TCP connections for IXFRs or other queries 🙈. So there's kind of an implicit assumption that one TCP connection gets used for one and only one IXFR request. Lots of major open-source implementations do exactly that (at the time of writing) 💀. And while [RFC5936] does give guidance on connection reuse for AXFR, it's older than the newer persistent-TCP specs like [RFC7766] and [RFC7828], so AXFR implementations often don't make the best use of open connections either 😭.

Given all that, new XoT implementations will clearly benefit from specific guidance on TCP/TLS connection usage for XFR, because it 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.

So this document updates both of the older XFR-over-TCP specs ([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] says that "DNS clients SHOULD pipeline their queries" on TCP connections, it didn't separate XFRs from other queries for this behavior. We know now that XFRs aren't as latency sensitive as other queries, and they can be a LOT more complex for clients to handle, because there's a huge amount of state to keep track of and there may be multiple messages in the responses 🧠. So it's clarified here that a valid reason for not pipelining queries is when they are all XFR queries. In other words, clients sending multiple XFRs MAY choose not to pipeline those queries. Clients that don't pipeline XFR queries have no extra requirements for handling out-of-order or intermingled responses (as described later), since they'll never receive them 🫶.
  • Implementations SHOULD use the edns-tcp-keepalive EDNS(0) option [RFC7828] to manage persistent connections. This is more flexible than just using fixed timeouts ✨.

The following sections go into detail on the updates to XFR behavior implied by [RFC7766], and on how [RFC7828] applies specifically to XFR exchanges. They also cover how IXFR and AXFR can reuse the same TCP connection 🧦.

For completeness, the recent extended DNS error (EDE) codes spec [RFC8914] gets a mention here too 🧾. For zone transfers, when a server returns REFUSED to a zone transfer request from an 'unauthorized' client (like a client that isn't listed in an ACL for zone transfers, or one that doesn't sign the request with a valid TSIG key), it can also send extended DNS error code 18 - Prohibited. 💅

6.1. Update to RFC 1995 for IXFR over TCP

okay so for clarity, an IXFR-over-TCP server that's compliant with this specification MUST be able to handle multiple concurrent IXoT requests on a single TCP connection (for the same and different zones) 🔥. It SHOULD also send the responses as soon as they're 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 that's 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 that are compliant with this specification and pipeline AXFR requests MUST be able to handle that 💜.

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 they start any new XFR request to the same primary, and when they issue SOA queries, instead of opening a new connection 🔁. The number of TCP connections between a secondary and a primary SHOULD be minimized (also see Section 6.4) ✨.

Valid reasons for NOT reusing existing connections might include the following, bestie 🙈:

  • 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 over a new TCP connection 🦋.

6.3.2. AXFRs and IXFRs on the Same Connection

Okay, neither [RFC1995] nor [RFC5936] explicitly talks about using a single TCP connection for both IXFR and AXFR requests 🤔. [RFC5936] does make this general statement:

Non-AXFR session traffic can also use an open connection.

In this document, that's clarified to mean that implementations which can do both AXFR and IXFR, and which are 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're available, i.e., responses MAY be sent intermingled.

Real talk though, for some current implementations, adding all of the above would bring in a lot of code complexity 😩. In that case, there will need to be an assessment of the trade-off between that complexity 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 gets hit. It's a transient error, so a retry at a later time might succeed (there's 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 give the server the 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 deciding what edns-tcp-keepalive timeout to use. If the server doesn't 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 EDNS(0) spec [RFC6891] doesn't 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, that's clarified to mean 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 📦. Here's the iconic part: this requirement, combined with edns-tcp-keepalive, lets AXFR servers signal that they want to close a connection (once existing transactions have completed) because resources are low. They do it by sending an edns-tcp-keepalive EDNS(0) option with a timeout of 0 on any AXFR response 🙅‍♀️. This does NOT mean the AXFR is aborted. It just means the server wants 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 fall back to legacy behavior when interoperating with servers known to not support [RFC5936] 🕰️. For interoperability purposes, IXFR and AXFR implementations may want to keep offering such configuration options, as well as supporting some behaviors that were underspecified before 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 about 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 clients using TCP, it doesn't relax the requirement for servers to handle 'mixed' traffic (regular queries and zone transfers) on any open TCP/TLS connection 🌀. It also overlooks the possibility that other transports might want to take the same approach, using separate connections for different purposes.

This specification updates that 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 the 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 ✨

Okay bestie, default move: XoT SHOULD be set up on port 853, as laid out in [RFC7858] 💅 The only exception is if the primary and secondary mutually agree on a different port for XoT. 🎀 There MAY be agreement to use different ports for AXoT and IXoT, or for different zones. 🦋

7.4. High-Level XoT Descriptions 🌸

Lowkey important detail: in XoT, it's the secondary that starts the TLS connection to the primary when it wants an XFR. 🫶 So connection-wise, the secondary is the TLS client and the primary is the TLS server. 👑

Here's the AXoT flow, NOTIFYs included 👀

   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

And here's the IXoT version, NOTIFYs included 🧚

   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 🔐

Main character rule: for a zone transfer between two endpoints to count as protected by XoT, every XFR request and response for that zone MUST be sent over TLS connections. 💀 At a minimum:

  • The client MUST authenticate the server using an authentication domain name, with a Strict Privacy profile as described in [RFC8310]. 🫶
  • The server MUST validate that the client is authorized to request or proxy a zone transfer, using one or both of these 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 gets picked, mTLS is preferred, because it gives strong cryptographic protection at both endpoints. 👑

Authentication mechanisms are covered in full in Section 9. The reasoning behind the requirement above is in Section 10. Transfer group policies are in Section 11. 📚

7.6. XoT Connections 🦋

Everything in Section 6 about things like persistent connections and XFR message handling fully applies to XoT connections too. ✨ But anything specified here takes precedence for XoT, so keep that in mind 🙈

If no TLS connections are open right now, XoT clients MAY send SOA queries over UDP, TCP, or TLS. 🌈

7.7. XoT vs. ADoT 🌸

As mentioned earlier, there's currently no spec for encrypting connections from recursive resolvers to authoritative servers. 😭 Some authoritative servers are experimenting with ADoT, and opportunistic encryption has also come up as a possibility. So it's highly likely that encryption use by authoritative servers will evolve over the next few years. 🔥

This creates short-term questions about TLS connection and message handling for authoritative servers. Specifically, there's likely to be a group of authoritative servers that want XoT soon, with a small number of configured secondaries, but don't want to support DoT for regular queries from recursives during that same stretch. 💅 These servers might end up dealing with probing and direct queries from recursives and test servers, plus possible attacks that try to use TLS to overload the server. 😬

[RFC5936] clearly says non-AXFR session traffic can use an open connection. 🧚 However, that requirement needs to be re-evaluated before applying the same model to XoT. Saying a server should also start answering every query received over TLS just because it turned on XoT would basically be defining a form of authoritative DoT. 🙅‍♀️ This specification doesn't propose that. It also doesn't prohibit servers from answering queries unrelated to XFR exchanges over TLS. Instead, this specification just outlines the following in later sections:

  • the use of EDE codes by XoT servers in response to queries on TLS connections they're not willing to answer (see Section 7.8) 🎀
  • the operational and policy options an XoT server operator has for managing TLS connections and messages (see Appendix A) 🍓

7.8. Response RCODES 🚫

XoT clients and servers MUST implement EDE codes. 🔥 If an XoT server gets non-XoT traffic on a TLS connection that it's not willing to answer, 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 that server for a reasonable period of time (for example, one hour). That gives the server enough time for its configuration or policy to get updated. ⏳

Servers have historically used the REFUSED RCODE for lots of situations, so clients often had no detailed info to base an error or fallback path on when queries got refused. 😩 Because of that, client behavior could vary a lot. XoT servers that refuse queries have to be ready for that. Some clients might keep retrying regardless of getting REFUSED, others might refuse every single query, and at the other extreme, clients may decide to stop using the server over any transport. 🙈 This could happen because those clients are either non-XoT clients or don't implement EDE codes. 💜

7.9. AXoT Specifics 🌷

7.9.1. Padding AXoT Responses 🫧

Padding AXoT responses has a two-fold goal:

  • to hide the actual size of the transferred zone, so there's less info leaked about the entire contents of the zone 🔒
  • to hide the incremental changes to the zone between SOA updates, so there's less info leaked about zone update activity and growth 📈

Reusing XoT connections to transfer multiple different zones makes it a bit harder to analyze traffic size and timing for info. 🕵️‍♀️ Also, effective padding may need state to be kept, because zones can grow and/or shrink over time. 🌊

Depending on the padding policies eventually developed for XoT, the requirement to hide the total zone size might mean a server has to create 'empty' AXoT responses. 🫥 Those are AXoT responses containing no RRs apart from an OPT RR that carries the EDNS(0) option for padding. For example, without this capability, the maximum size a tiny zone could be padded to would theoretically be limited if there had to be at least 1 RR per packet. 🧮

Still, just like existing AXFR, the last AXoT response message sent MUST contain the same SOA that was in the first message of the AXoT response series, to signal the end 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 made to meet a padding requirement are exceptions to that statement. 🙈 For flexibility and future-proofing, and to guarantee support for future padding policies, this specification states that secondary implementations MUST be resilient to receiving padded AXoT responses. That includes 'empty' AXoT responses that contain only an OPT RR with the EDNS(0) option for padding. 🛡️

Specific recommendations for padding AXoT responses are out of scope for this spec. 🙅‍♀️ Detailed considerations of such policies and their trade-offs are expected to be future work. 🔮

7.10. IXoT Specifics 🎀

7.10.1. Condensation of Responses 🧩

[RFC1995] says condensation of responses is optional and MAY be done. 💖 It does add complexity to generating responses, but it can significantly shrink response size. Still, 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 🔁

Falling back to AXFR can happen, for example, when the server can't provide an IXFR for the requested SOA. 🤷‍♀️ Implementations differ in how long they store zone deltas and how many they can hold at any one time. 📦

Just like 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 ✨

okay so bestie, the whole point of padding IXoT responses is to hide the tiny incremental changes happening to the zone between SOA updates 🙈 That way nobody can snoop on how much zone update activity is going on or how fast the zone is growing. And it's not just the size! Timing can leak stuff too 👀

IXFR responses are all over the place size-wise 💅 We're talking around 100 bytes for one or two record updates, all the way up to tens of thousands of bytes for big, dynamic DNSSEC-signed zones. How often IXFR responses show up can also depend a LOT on whether and how the zone is DNSSEC signed 🔥

Okay, the big one 👑 To guarantee support for future padding policies, it's stated here that secondary implementations MUST be resilient to receiving padded IXoT responses. No skipping this one, bestie!

Specific recommendations for padding IXoT responses are out of scope for this specification 🫶 The deep dives on padding policies, traffic obfuscation techniques (like generating fake XFR traffic), and all the trade-offs involved are expected to be future work 🧚

7.11. Name Compression and Maximum Payload Sizes 💌

It's noted here that name compression [RFC1035] can be used in XFR responses to shrink the payload 📦 BUT, the maximum value of the offset that can be used in the name compression pointer structure is 16384. For some DNS implementations, this limits an individual XFR response used in practice to something around 16 KB. Yikes, right? 😭 In principle, larger payload sizes can be supported for some responses with more sophisticated approaches (e.g., by precalculating the maximum offset required). Galaxy brain energy 🌌

Implementations may wish to offer options to disable name compression for XoT responses so they can go bigger 🎀 This might be especially helpful when padding is used, since minimizing the payload size isn't necessarily a useful optimization in that case. Plus, disabling name compression reduces the resources needed to build the payload. Efficient and iconic 💖

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. Then it can 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 already have a XoT connection open to one or more primaries 🌸 So should a secondary preferentially request an XFR from a primary it already has an open XoT connection to, or the one with the highest SOA (assuming it doesn't already have a connection open to that one)? Big decision energy 🤔

There are two extremes here 🎭 The first one is basically the 'preferred primary connection' model. The secondary keeps using 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. Loyal but not blind 💜

The other extreme is the '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 the number of secondaries and primaries in direct contact in a transfer group is normally reasonably low, this might be feasible if latency is the most significant concern. Multitasking queen 👑

Recommendation of a particular scheme is out of scope for this document, but implementations are encouraged to provide configuration options that let operators make choices about this behavior ⭐

9. Authentication Mechanisms 🔐

To give context to the requirements in Section 7.5, this section gives a quick 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 gets into the nitty-gritty of how 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 lets each party check that a request or response (and the data in it) came from the other party, even if it was sent over an unsecured channel or via a proxy. Secret handshake vibes 🤫

Properties: Data origin authentication.

9.2. SIG(0) ✍️

SIG(0) [RFC2931] similarly provides a mechanism to digitally sign a DNS message, but it uses public key authentication. The public keys are stored in DNS as KEY RRs, and a private key is stored at the signer. Signature drip 💅

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, giving 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 fall back to using TLS without authentication, or
  • clients MAY fall back 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. Not the one 🙅‍♀️

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 gives the client a defense against active surveillance, providing client-to-server authentication and end-to-end channel confidentiality. Locked in 🔐

Properties: Channel confidentiality and channel authentication (of the server).

9.3.3. Mutual TLS

This is an extension to Strict TLS [RFC8310] that requires a client to be 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 gives a defense for both parties against active surveillance, providing bidirectional authentication and end-to-end channel confidentiality. Both sides are verified, bestie 🫶

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 has to be noted that, as with TCP, the implementation of such an ACL can't be enforced on the primary until an XFR request is received on an established connection. Gatekeeping has its limits 🙃

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's designed to be independent of the transmission channel or mechanism, so a general consumer of a zone can 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's complementary but orthogonal to the above mechanisms and can be used in conjunction with XoT, but it isn't considered further here 🌷

10. XoT Authentication 🛡️

It's noted that zone transfer scenarios can range 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 need specific analysis to figure out which combination of authentication methods suits that deployment model.

The XoT authentication requirement specified in Section 7.5 deals with making sure transfers are encrypted between the two endpoints directly involved in the current transfers 🔏 The table below sums up 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, here's the tea ☕

  • Using just mutual TLS can be considered a standalone solution, since both endpoints are cryptographically authenticated. Main character solo act 👑
  • Using secondary-side Strict TLS with a primary-side IP-based ACL and TSIG/SIG(0) combination provides sufficient protection to be acceptable. Team player energy 🫶

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. Yikes, don't let the key leak 😭💀

11. Policies for Both AXoT and IXoT ✨

okay so XoT can protect the zone contents on a single transfer between two endpoints 🔐 but protecting every transfer of a zone is a whole operational and policy job 🫶

The whole crew of servers involved in XFR for a set of zones (all the primaries and all the secondaries) is called the 'transfer group' 🌸

For the zone info to stay confidential, the entire transfer group MUST have a consistent policy of using XoT 💅 If even one server doesn't, that's a weak link attackers will totally go after 😭 To be clear: inside any transfer group, both AXFRs and IXFRs for a zone MUST all use XoT 🎀

An individual zone transfer doesn't count as protected by XoT unless both the client and the server are set up to use only XoT. The overall zone transfer isn't protected until every member of the transfer group is set up to use only XoT with all the other transfer 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.

Real talk, this can mean configuring a bunch of servers that might belong to different operators 🙈 So that consistency can be super hard to enforce and audit in practice 💀

Some parts of the policy are pretty easy to test on your own, like requesting zone transfers without TSIG, from unauthorized IP addresses, or over cleartext DNS 🔍 Other stuff is trickier to check, like whether a secondary will accept data without a TSIG digest, or whether secondaries are using Strict TLS instead of Opportunistic TLS 🧐

How to coordinate or enforce these policies is out of scope for this doc, but it might get its own operational guidance later 🌈

12. Implementation Considerations 🧚

Server implementations may want to also offer options that let ACLs on a zone say a specific client can use either XoT or TCP 🍓 That gives everyone some flexibility while clients are migrating to XoT 🦋

Client implementations may similarly want to offer options for the multi-primary case, where the primaries are migrating to XoT 💜

13. Operational Considerations ⭐

If the options from Section 12 are available, those configuration options MUST only be used in a 'migration mode' 🚧 So they should be used with great care 😬

Also, a TLS proxy sitting 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 is a security measure against a DNS risk: the risk that an attacker collects entire DNS zones just by eavesdropping on cleartext DNS zone transfers 👀

This does NOT mitigate the following, so don't get too comfy 😭
  • the risk that some level of zone activity could be inferred by watching zone transfer sizes and timing on encrypted connections (even with padding applied), combined with grabbing SOA records by directly querying authoritative servers 🕵️
  • the risk that hidden primaries could be inferred or identified by watching encrypted connections, or
  • the risk of zone contents being obtained via zone enumeration techniques 💀

The security concerns of DoT are outlined in [RFC7858] and [RFC8310] 🔐

16. References 📚

16.1. Normative References

16.2. Informative References

Appendix A. XoT Server Connection Handling 🎀

This appendix is a non-normative outline of the pros and cons of XoT server connection-handling options 💖

For completeness, an earlier draft of this document suggested a XoT-specific ALPN to negotiate TLS connections that supported only a limited set of queries (SOA, XFRs) 🌙 That didn't gain support, though. The reasons given included extra code complexity and the fact that XoT and ADoT both use DNS wire format, so they 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 answers queries for it on an IP address published in an NS record might want to use a separate IP address for XoT to listen for TLS 👑 It would only publish that address to its secondaries 🤫

  • Pros: Probing the public IP address shows no support for TLS 🙌 ACLs prevent zone transfer on all transports on a per-query basis 🔒
  • Cons: Attackers passively observing traffic can still see TLS connections to the separate address 👀

A.2. Client-Specific TLS Acceptance 🔐

Okay so, primaries that use IP-based ACLs and/or mutual TLS in their authentication models get the option to only accept TLS connections from authorized clients 🫶. This can be done with a proxy or directly in the DNS implementation ✨.

Pros: Connection management happens at setup time 💅. You can easily figure out the maximum number of TLS connections a server will have to support 📊. Once a connection is accepted, the server might honestly be happy to answer any query on it, since it's coming from a configured secondary 🥰. A specific response policy on that connection may not even be needed (more on that below 👀).

Cons: Currently, none of the major open-source authoritative DNS server implementations support this 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: It reduces the number of accepted connections 📉.

Cons: Same as above 🙄. Also, this is not a recommended use of SNI 🚩. When SNIs are sent in the clear, attackers who are passively watching traffic could potentially abuse this mechanism 👀. 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 💬, [RFC7766] does make a general-purpose distinction in its advice to clients about how they use connections (regular queries versus zone transfers), but it isn't strict 🤷‍♀️. Nothing in the DNS protocol stops anyone from using the same connection for both types of traffic. So a server cannot know the intention of any client that connects to it. It can only inspect the messages it receives on that connection and make per-query decisions about whether or not to answer them 🧐.

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: This allows for flexible behavior from the server, which can be changed over time 🌈.

Cons: The server has to carry the burden of accepting all TLS connections just to do XFRs with a small number of secondaries 😩. Client behavior in response to a REFUSED response is not clearly defined (see Section 7.8) 🫠. Currently, none of the major open-source authoritative DNS server implementations offer an option for different response policies per transport. Such functionality could potentially be built with a proxy, though 🛠️.

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 decide which response policy to initially apply to TLS connections 🪄.

Pros: This has the potential to allow a clean split between XoT service and any future DoT-based service for answering recursive queries 👑.

Cons: Same 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

Han, you're a whole legend 💖

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

And that's the whole spec, bestie 🌈✨👑

📦 where this page comes from