dprive                                                         W. Toorop
Internet-Draft                                                NLnet Labs
Updates: 1995, 5936, 7766 (if approved)                     S. Dickinson
Intended status: Standards Track                              Sinodun IT
Expires: January 14, May 6, 2021                                            S. Sahib
                                                                 P. Aras
                                                               A. Mankin
                                                              Salesforce
                                                           July 13,
                                                        November 2, 2020

                       DNS Zone Transfer-over-TLS
                   draft-ietf-dprive-xfr-over-tls-02
                   draft-ietf-dprive-xfr-over-tls-03

Abstract

   DNS zone transfers are transmitted in clear text, which gives
   attackers the opportunity to collect the content of a zone by
   eavesdropping on network connections.  The DNS Transaction Signature
   (TSIG) mechanism is specified to restrict direct zone transfer to
   authorized clients only, but it does not add confidentiality.  This
   document specifies use of TLS, rather then clear text, to prevent
   zone contents content collection via passive monitoring of zone transfers. transfers:
   XFR-over-TLS (XoT).  Additionally, this specification updates
   RFC1995, RFC5936 and RFC7766.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 14, May 6, 2021.

Copyright Notice

   Copyright (c) 2020 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
   (http://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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4   5
   3.  Use Cases for XFR-over-TLS  . . . . . . . . . . . . . . . . .   5
     3.1.  Threat model  . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Connection and Data Flows in Existing XFR Mechanisms  . . . .   5   7
     4.1.  AXFR Mechanism  . . . . . . . . . . . . . . . . . . . . .   6   7
     4.2.  IXFR Mechanism  . . . . . . . . . . . . . . . . . . . . .   7   9
     4.3.  Data Leakage of NOTIFY and SOA Message Exchanges  . . . .   8  11
       4.3.1.  NOTIFY  . . . . . . . . . . . . . . . . . . . . . . .   8  11
       4.3.2.  SOA . . . . . . . . . . . . . . . . . . . . . . . . .   8  11
   5.  Connections and Data Flows in XoT .  Updates to existing specifications  . . . . . . . . . . . . .   8  11
     5.1.  TLS versions  Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . .  12
     5.2.  Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . .   8
     5.2.  Connection usage  13
     5.3.  Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . .  13
       5.3.1.  Connection reuse  . . . . . . . . . . . . . . .   8
       5.2.1.  High level XoT descriptions . . .  13
       5.3.2.  AXFRs and IXFRs on the same connection  . . . . . . .  13
       5.3.3.  XFR limits  . . .   9
       5.2.2.  Previous specifications . . . . . . . . . . . . . . .   9
     5.3.  Update to RFC7766 . . .  14
       5.3.4.  The edns-tcp-keepalive EDNS0 Option . . . . . . . . .  14
       5.3.5.  Backwards compatibility . . . . . . . .  10
     5.4.  Connection Establishment . . . . . . .  15
     5.4.  Update to RFC7766 . . . . . . . . .  10
       5.4.1.  Draft Version Identification . . . . . . . . . . .  15
   6.  XoT specification .  11
     5.5.  Port selection . . . . . . . . . . . . . . . . . . . . .  11
     5.6.  AXoT mechanism  16
     6.1.  TLS versions  . . . . . . . . . . . . . . . . . . . . .  11
       5.6.1.  Coverage and relationship to RFC5936 .  16
     6.2.  Port selection  . . . . . . .  12
       5.6.2.  AXoT connection and message handling . . . . . . . .  12
       5.6.3.  Padding AXoT responses . . . . . .  16
     6.3.  High level XoT descriptions . . . . . . . . .  14
     5.7.  IXoT mechanism . . . . . .  16
     6.4.  XoT transfers . . . . . . . . . . . . . . .  15
       5.7.1.  Coverage and relationship to RFC1995 . . . . . . .  18
     6.5.  XoT connections .  15
       5.7.2.  IXoT connection and message handling . . . . . . . .  15
       5.7.3.  Condensation of responses . . . . . . . . . . . .  19
     6.6.  XoT vs ADoT . .  16
       5.7.4.  Fallback to AXFR . . . . . . . . . . . . . . . . . .  16
       5.7.5.  Padding of IXoT responses . . .  19
     6.7.  Response RCODES . . . . . . . . . . .  16
   6.  Multi-primary Configurations . . . . . . . . . .  20
     6.8.  AXoT specifics  . . . . . .  16
   7.  Zone Transfer with DoT - Authentication . . . . . . . . . . .  17
     7.1.  TSIG . . . .  20
       6.8.1.  Padding AXoT responses  . . . . . . . . . . . . . . .  20
     6.9.  IXoT specifics  . . . . . . .  17
     7.2.  SIG(0) . . . . . . . . . . . . . .  21
       6.9.1.  Condensation of responses . . . . . . . . . . .  17
     7.3.  TLS . . .  21
       6.9.2.  Fallback to AXFR  . . . . . . . . . . . . . . . . . .  21
       6.9.3.  Padding of IXoT responses . . . . . .  18
       7.3.1.  Opportunistic . . . . . . . .  22
     6.10. Name compression and maximum payload sizes  . . . . . . .  22
   7.  Multi-primary Configurations  . . . . .  18
       7.3.2.  Strict . . . . . . . . . . .  22
   8.  Authentication mechanisms . . . . . . . . . . . .  18
       7.3.3.  Mutual . . . . . .  23
     8.1.  TSIG  . . . . . . . . . . . . . . . . .  18
     7.4. . . . . . . . . .  24
     8.2.  SIG(0)  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     8.3.  TLS . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
       8.3.1.  Opportunistic TLS . . . . . . . . . . . . . . . . . .  24
       8.3.2.  Strict TLS  . . . . . . . . . . . . . . . . . . . . .  25
       8.3.3.  Mutual TLS  . . . . . . . . . . . . . . . . . . . . .  25
     8.4.  IP Based ACL on the Primary . . . . . . . . . . . . . . .  18
     7.5.  25
     8.5.  ZONEMD  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     7.6.  Comparison of Authentication Methods  26
   9.  XoT authentication  . . . . . . . . . .  19
   8. . . . . . . . . . . .  26
   10. Policies for Both AXFR AXoT and IXFR IXoT . . . . . . . . . . . . . . .  20
   9.  27
   11. Implementation Considerations . . . . . . . . . . . . . . . .  21
   10.  28
   12. Implementation Status . . . . . . . . . . . . . . . . . . . .  21
   11.  28
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     11.1.  Registration of XoT Identification String  . . . . . . .  21
   12.  28
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  21
   13.  28
   15. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  22
   14.  29
   16. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  22
   15.  29
   17. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   16.  29
   18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     16.1.  30
     18.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     16.2.  30
     18.2.  Informative References . . . . . . . . . . . . . . . . .  24
     16.3.  32
     18.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  26
   Authors' Addresses  34
   Appendix A.  XoT server connection handling . . . . . . . . . . .  34
     A.1.  Only listen on TLS on a specific IP address . . . . . . .  34
     A.2.  Client specific TLS acceptance  . . . . .  26

1.  Introduction

   DNS has a number of privacy vulnerabilities, as discussed in detail
   in [RFC7626].  Stub client to recursive resolver query privacy has
   received the most attention to date, with standards track documents
   for both DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) . . . . . . . .  34
     A.3.  SNI based TLS acceptance  . . . . . . . . . . . . . . . .  35
     A.4.  TLS specific response policies  . . . . . . . . . . . . .  35
       A.4.1.  SNI based response policies . . . . . . . . . . . . .  36
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  36

1.  Introduction

   DNS has a number of privacy vulnerabilities, as discussed in detail
   in [RFC7626].  Stub client to recursive resolver query privacy 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
   [I-D.ietf-dprive-dnsoquic].  There is ongoing work on DNS privacy
   requirements for exchanges between recursive resolvers and
   authoritative servers [I-D.ietf-dprive-phase2-requirements] and some
   suggestions for how signaling of DoT support by authoritatives might
   work, e.g., [I-D.vandijk-dprive-ds-dot-signal-and-pin].  However
   there is currently no RFC that specifically defines recursive to
   authoritative
   support for DNS-over-TLS. DNS-over-TLS (ADoT).

   [RFC7626] established that stub client DNS query transactions are not
   public and needed 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 [RFC5936] and [RFC5155]."

   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:

   o  Person-laptop.example.org

   o  MX-for-Location.example.org

   o  Service-tenant-from-another-org.example.org

   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 [RFC7626] contemplates the risk that
   someone gets the data through eavesdropping on network connections,
   only via enumeration or unauthorized transfer as described in the
   following paragraphs.

   [RFC5155] specifies NSEC3 to prevent zone enumeration, which

   Zone enumeration is when trivially possible for DNSSEC zones which use
   NSEC; i.e.  queries for the authenticated denial of existences
   records of DNSSEC allow a client to walk through the entire zone.  Note that the need 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 an DNSSEC signed zone as an unsigned zone).  Whilst
   this protection also motivates NSEC5 [I-D.vcelak-nsec5]; is widely used, zone walking is now possible with NSEC3 due to
   crypto-breaking advances,
   and advances.  This has prompted further work on an
   alternative mechanism for DNSSEC authenticated denial of existence -
   NSEC5 is a response to [I-D.vcelak-nsec5] - however questions remain over the
   practicality of this problem. mechanism.

   [RFC5155] does not address data obtained outside zone enumeration
   (nor does [I-D.vcelak-nsec5]).  Preventing eavesdropping of zone
   transfers (this draft) is orthogonal to preventing zone enumeration,
   though they aim to protect the same information.

   [RFC5936] specifies using TSIG [RFC2845] 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.  Some operators use SSH tunneling or IPSec to encrypt the
   transfer data.

   Because both AXFR and IXFR

   Section 8 of the NIST guide on 'Secure Domain Name System (DNS)
   Deployment' [nist-guide] discusses restricting access for zone
   transfers using ACLs and TSIG in more detail.  It is noted that in
   all the common open source implementations such ACLs are applied on a
   per query basis.  Since requests typically carried out
   over occur on TCP connections
   authoritatives must cater for accepting any TCP connection and then
   handling the authentication of each XFR request individually.

   Because both AXFR and IXFR zone transfers are typically carried out
   over TCP from authoritative DNS protocol implementations, encrypting
   zone transfers using TLS, based closely on DoT [RFC7858], seems like
   a simple step forward.  This document specifies how to use TLS as a
   transport to prevent zone collection from zone transfers.

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] and [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Privacy terminology is as described in Section 3 of [RFC6973].

   Note that in this document we choose to use the terms 'primary' and
   'secondary' for two servers engaged in zone transfers.

   DNS terminology is as described in [RFC8499].

   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: Generic XFR-over-TLS mechanisms as specified in this document

   AXoT: AXFR-over-TLS

   IXoT: IXFR over-TLS

3.  Use Cases for XFR-over-TLS

   o  Confidentiality.  Clearly using an encrypted transport for zone
      transfers will defeat zone content leakage that can occur via
      passive surveillance.

   o  Authentication.  Use of single or mutual TLS (mTLS) authentication
      (in combination with ACLs) can complement and potentially be an
      alternative to TSIG.

   o  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 XFR-over-TLS (XoT) would obviously be required
      to implement optimized and interoperable transfers as described in
      [RFC5936], e.g., transfer of multiple zones over one connection.

   o  Performance.  Current usage of TCP for IXFR is sub-optimal in some
      cases i.e.  connections are frequently closed after a single IXFR.

3.1.  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 nameservers hosting a zone (including both those acting as hidden
   primaries/secondaries or directly serving the zone) as sensitive
   information.  The proposed mechanisms does not attempt to obscure
   such information.  The reasons for this include:

   o  much of this information can be obtained by various methods
      including active scanning of the DNS

   o  an attacker who can monitor network traffic can relatively easily
      infer relations between nameservers simply from traffic patterns,
      even when some or all of the traffic is encrypted

   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
   nameservers e.g.  IPsec.

4.  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 SOA query (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 we use the phrase "XFR mechanism" to describe the
   entire set of message exchanges between a secondary and a primary
   that concludes in a successful AXFR or IXFR request/response.  This
   set may or may not include

   o  NOTIFY messages

   o  SOA queries

   o  Fallback from IXFR to AXFR

   o  Fallback from IXFR-over-UDP to IXFR-over-TCP

   The term is used to encompasses the range of permutations that are
   possible and is useful to distinguish the 'XFR mechanism' from a
   single XFR request/response exchange.

4.1.  AXFR Mechanism

   The figure below provides an outline of an AXFR mechanism including
   NOTIFYs.

          Secondary                            Primary

              |              NOTIFY               |
              | <-------------------------------- |  UPD
              | --------------------------------> |
              |          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]

   1.  An AXFR is often (but not always) preceded by a NOTIFY (over UDP)
       from the primary to the secondary.  A secondary may also initiate
       an AXFR based on a refresh timer or scheduled/triggered zone
       maintenance.

   2.  The secondary will normally (but not always) make a SOA query to
       the primary to obtain the serial number of the zone held by the
       primary.

   3.  If the primary serial is higher than the secondaries serial
       (using Serial Number Arithmetic [RFC1982]), the secondary makes
       an AXFR request (over TCP) to the primary after which the AXFR
       data flows in one or more AXFR responses on the TCP connection.
       [RFC5936] specifies defines this specific step as an 'AXFR session' i.e. as
       an AXFR query message and the sequence of AXFR response messages
       returned for it.

   [RFC5936] re-specified AXFR providing additional guidance beyond that
   provided in [RFC1034] and [RFC1035] and importantly specified that
   AXFR must use TCP as the transport protocol
   but details that there is no restriction in the protocol that a
   single TCP connection must be used only protocol.

   Additionally, sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] provide
   improved guidance for a single AXFR exchange,
   or even solely clients and servers with regard to re-use
   of TCP connections for XFRs. multiple AXFRs and AXFRs of different zones.
   However [RFC5936] was constrained by having to be backwards
   compatible with some very early basic implementations of AXFR.  For
   example, it outlines that the SOA query can also happen on this
   connection.  However, this can cause interoperability problems with
   older implementations that support only the trivial case of one AXFR
   per connection.

   Further details of the limitations in existing AXFR implementations
   are outlined in [RFC5936].

4.2.  IXFR Mechanism

   The figure below provides an outline of the IXFR mechanism including
   NOTIFYs.

          Secondary                            Primary

              |              NOTIFY               |
              | <-------------------------------- |  UPD
              | --------------------------------> |
              |          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 1. IXFR Mechanism [2]

   1.  An IXFR is normally (but not always) preceded by a NOTIFY (over
       UDP) from the primary to the secondary.  A secondary may also
       initiate an IXFR based on a refresh timer or scheduled/triggered
       zone maintenance.

   2.  The secondary will normally (but not always) make a SOA query to
       the primary to obtain the serial number of the zone held by the
       primary.

   3.  If the primary serial is higher than the secondaries serial
       (using Serial Number Arithmetic [RFC1982]), the secondary makes
       an IXFR request to the primary after the primary sends an IXFR
       response.

   [RFC1995] specifies that Incremental Transfer may use UDP if the
   entire IXFR response can be contained in a single DNS packet,
   otherwise, TCP is used.  In fact is says in non-normative language: it says:

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

   So there may be a forth fourth step above where the client falls back to
   IXFR-over-TCP.  There may also be a forth fourth step where the secondary
   must fall back to AXFR because, e.g., the primary does not support
   IXFR.

   However it is noted that at least two most widely used open source authoritative
   nameserver implementations (BIND [3] (including both BIND [1] and NSD [4]) [2]) do
   IXFR using TCP by default in their latest releases.  For BIND TCP
   connections are sometimes used for SOA queries but in general they
   are not used persistently and close after an IXFR is completed.

   It is noted that the specification for IXFR was published well before
   TCP was considered a first class transport for DNS.  This document
   therefore updates [RFC1995] to state that DNS implementations that
   support IXFR-over-TCP MUST use [RFC7766] to optimize the use of TCP
   connections and SHOULD use [RFC7858] to manage persistent
   connections.

4.3.  Data Leakage of NOTIFY and SOA Message Exchanges

   This section attempts to presents a rationale for also considering
   encrypting the other messages in the XFR mechanism.

   Since the SOA of the published zone can be trivially discovered by
   simply querying the publicly available authoritative servers leakage
   of this RR is not discussed in the following sections.

4.3.1.  NOTIFY

   Unencrypted NOTIFY messages identify configured secondaries on the
   primary.

   [RFC1996] also states:

       "If ANCOUNT>0, then the answer section represents an
       unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE).

   But since the only supported QTYPE for NOTIFY is SOA, this does not
   pose a potential leak.

4.3.2.  SOA

   For hidden primaries or secondaries the SOA response leaks only the
   degree of lag of any downstream secondary.

5.  Connections and Data Flows in XoT

5.1.  TLS versions  Updates to existing specifications

   For improved security all implementations of this specification MUST
   use only TLS 1.3 [RFC8446] or later.

5.2.  Connection usage

   It convenience, the phrase 'XFR-over-TCP' is useful used in this document
   to note mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements
   that in these mechanisms use it is the secondary
   that initiates the TLS connection update both [RFC1995] and [RFC5936], and implicitly also
   apply to the primary for a XFR request,
   so that XoT.  Differences in terms of connectivity the secondary is the TLS client and
   the primary the TLS server.

   The details behavior specific to XoT are discussed
   in [RFC7766], [RFC7858] and [RFC8310] about, e.g.,
   persistent connection Section 6.

   Both [RFC1995] and message handling are fully applicable to
   XoT as well.  However any behavior specified here takes precedence
   for XoT.

5.2.1.  High level XoT descriptions

   The figure below provides an outline of the AXoT mechanism including
   NOTIFYs.

   Figure 3: AXoT mechanism [5]

   The figure below provides an outline of the IXoT mechanism including
   NOTIFYs.

   Figure 4: IXoT mechanism [6]

5.2.2.  Previous specifications

   We note that whilst [RFC5936] already recommends were published sometime before TCP was
   considered a first class transport for DNS.  [RFC1995], in fact, says
   nothing with respect to optimizing IXFRs over TCP or re-using already
   open TCP
   connections, it does state:

      "Non-AXFR session traffic can also use connections to perform IXFRs or other queries.  Therefore,
   there arguably is an implicit assumption (probably unintentional)
   that a TCP connection is used for one and only one IXFR request.
   Indeed, several open source implementations currently take this
   approach.  And whilst [RFC5936] gives guidance on connection re-use
   for AXFR, it pre-dates more recent specifications describing
   persistent TCP connection."

   when discussing AXFR-over-TCP.  It defines an AXFR session as an AXFR
   query message connections e.g.  [RFC7626], [RFC7828] and the sequence of AXFR response messages returned
   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
   it.  Note that XFR because this excludes
   will:

   o  result in more consistent XoT implementations with better
      interoperability

   o  remove any SOA queries issued as part of the
   overall AXFR mechanism.  This requirement needs need for XoT implementations to be re-evaluated
   when considering applying support legacy behavior
      that XFR-over-TCP implementations have historically often
      supported

   Therefore this document updates both the same model previous specifications for
   XFR-over-TCP to XoT since

   o  There is no guarantee clarify that a XoT server (which is very likely, but
      not necessarily, a purely authoritative server) will also support
      DoT for regular queries.  Requiring a purely authoritative server
      to also respond to any query implementations MUST use [RFC7766] (DNS
   Transport over a TLS connection would be
      equivalent to defining a form of authoritative DoT.  We consider
      this TCP - Implementation Requirements) to be out optimize the use
   of scope for this document, which is focussed
      purely on zone transfers.

   o  It would, however, be optimal for XoT TCP connections and SHOULD use [RFC7828] (The edns-tcp-keepalive
   EDNS0 Option) to manage persistent connections.

   The following sections include detailed clarifications on the capability updates
   to
      send SOA queries over an already open TLS connection.

   Moreover, it is worth noting that XFR behavior implied in [RFC7766] made general
   implementation recommendations with regard to TCP/TLS connection
   handling:

      "To mitigate and how the risk use of unintentional server overload, DNS
      clients MUST take care [RFC7828]
   applies specifically to minimize XFR exchanges.  It also discusses how IXFR
   and AXFR can reuse the number of concurrent same TCP
      connections made connection.

   For completeness, we also mention here the recent specification of
   extended DNS error (EDE) codes [RFC8914].  For zone transfers, when
   returning REFUSED to any individual server. It a zone transfer request to an 'unauthorized'
   client (e.g. where the client is RECOMMENDED
      that for any given client/server interaction there SHOULD be no
      more than one connection for regular queries, one not listed in an ACL for zone
      transfers, and one
   transfers or does not sign the request with the correct TSIG key),
   the extended DNS error code 18 (Prohibited) can also be sent.

5.1.  Update to RFC1995 for each protocol that is being used IXFR-over-TCP

   For clarity - an IXFR-over-TCP server compliant with this
   specification MUST be able to handle multiple concurrent IXoT
   requests on top
      of a single TCP connection (for example, if the resolver was using TLS). However,
      it is noted that certain primary/ secondary configurations with
      many busy zones same and different
   zones) and SHOULD send the responses as soon as they are available,
   which might need to use more than one TCP connection
      for zone transfers for operational reasons (for example, be out-of-order compared to
      support concurrent transfers of multiple zones)."

   Whilst this recommends a particular behavior for the clients using
   TCP, it does not relax the requirement requests.

5.2.  Update to RFC5936 for servers AXFR-over-TCP

   For clarity - an AXFR-over-TCP server compliant with this
   specification MUST be able to handle 'mixed'
   traffic (regular queries and zone transfers) multiple concurrent AXoT
   sessions on any open TCP/TLS
   connection.  It also overlooks the potential that other transports
   might want to take a single TCP connection (for the same approach and different
   zones).  The response streams for concurrent AXFRs MAY be
   intermingled and AXFR-over-TCP clients compliant with regard this
   specification MUST be able to using separate
   connections for different purposes. handle this.

5.3.  Update  Updates to RFC7766

   This specification RFC1995 and RFC5936 for XoT updates the guidance in [RFC7766] XFR-over-TCP

5.3.1.  Connection reuse

   As specified, XFR-over-TCP clients SHOULD re-use any existing open
   TCP connection when starting any new XFR request to
   provide the same separation of connection purpose (regular queries primary,
   and zone transfers) for all transports being used on top issuing SOA queries, instead of TCP.
   Therefore, it is RECOMMENDED that for each protocol used on top opening a new connection.
   The number of TCP in any given client/server interaction there connections between a secondary and primary SHOULD
   be no more
   than one connection minimized (also see Section 5.4).

   Valid reasons for regular queries and one not re-using existing connections might include:

   o  reaching a configured limit for zone transfers.
   We provide specific details in the following sections number of reasons
   where more than one outstanding queries
      or XFR requests allowed on a single TCP connection might be required for zone transfers.

5.4.  Connection Establishment

   This specification additionally limits the scope of XoT as defined
   here to be

   o  the use of dedicated TLS connections (XoT connections) to
   exchange only traffic specific to enabling zone transfers.  The set
   of transactions supported message ID pool has already been exhausted on such connections is limited to:

   o  AXFR an open
      connection

   o  IXFR  a large number of timeouts or slow responses have occurred on an
      open connection

   o  SOA  an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been
      received from the server and the client is collectively referred to hereafter as 'XoT traffic'.

   Such connections MUST use an ALPN token in the process of 'xot' during
      closing the TLS
   handshake connection (see Section 11).

   In 5.3.4)

   If no TCP connections are currently open, XFR clients MAY send SOA
   queries over UDP or a new TCP connection.

5.3.2.  AXFRs and IXFRs on the absence of DNS specific capability signaling mechanisms this
   greatly simplifies same connection

   Neither [RFC1995] nor [RFC5936] explicitly discuss the implementation use of XoT such that a XoT exchange
   can occur between any primary
   single TCP connection for both IXFR and secondary regardless of AXFR requests.  [RFC5936]
   does make the role of
   each (e.g. purely authoritative, recursive resolver general state:

      "Non-AXFR session traffic can also
   authoritatively hosting zones, stub) or use an open TCP connection."

   We clarify here that implementations capable of other DNS transport
   capability each may have.  It also clearly makes XoT support
   orthogonal both AXFR and IXFR
   and compliant with this specification SHOULD

   o  use the same TCP connection for both AXFR and IXFR requests to any set of zone transfer authentication mechanisms
   chosen by the two parties.

   XoT clients MUST only send XoT traffic on XoT connections.  If a XoT
   server receives traffic other than XoT traffic on a XoT connection it
   MUST respond with the extended DNS error code 21 - Not Supported
   [I-D.ietf-dnsop-extended-error].  It SHOULD treat this as protocol
   error
      same primary

   o  pipeline such request and close the connection.

   With the update to [RFC7766] guidance above, clients are free to open
   separate connections to MAY intermingle them

   o  send the server to make any other queries they may
   need over either TLS, TCP or UDP.  A specification response(s) for connections
   that support both XoT traffic and non-XoT traffic may each request as soon as they are
      available i.e. responses MAY be sent intermingled

5.3.3.  XFR limits

   The server MAY limit the subject number of concurrent IXFRs, AXFRs or total
   XFR transfers in progress, or from a future work.

5.4.1.  Draft Version Identification

   _RFC Editor's Note:_ Please remove this section prior given secondary, to publication
   of a final version of this document.

   Only implementations of protect
   server resources.

   [OPEN QUESTION] Testing has shown that BIND returns SERVFAIL if the final, published RFC can identify
   themselves as "xot".  Until such an RFC exists, implementations MUST
   NOT identify themselves using
   limit on concurrent transfers is reached since this string.

   Implementations of draft versions of the protocol MUST add the string
   "-" and the corresponding draft number to the identifier.  For
   example, draft-ietf-dprive-xfr-over-tls-02 is identified using the
   string "xot-02".

5.5.  Port selection

   The connection for XoT SHOULD be established using port 853, regarded as
   specified in [RFC7858], unless there is mutual agreement between the
   secondary a
   soft limit and primary to use a port other than port 853 for XoT.
   There MAY retry can/should succeed.  Should there be agreement to use different ports for AXoT and IXoT.

5.6.  AXoT mechanism
5.6.1.  Coverage and relationship a
   specific recommendation here about what is returned re: SERVFAIL vs
   REFUSED?

   [OPEN QUESTION] Is there a desire to RFC5936

   [RFC5936] re-specified AXFR providing define an additional guidance beyond XFR
   specific EDE code so that
   provided in [RFC1034] and [RFC1035].  For example, sections 4.1,
   4.1.1 and 4.1.2 of [RFC5936] provide improved guidance for AXFR
   clients and servers with regard to re-use of connections for multiple
   AXFRs and AXFRs of different zones.  However [RFC5936] a client can determine why a specific XFR
   request was
   constrained by having to be backwards compatible with some very early
   basic implementations of AXFR.

   Here we specify some optimized behaviors for AXoT, based closely on
   those in [RFC5936], but without the constraint of backwards
   compatibility since it is expected that all implementations of AXoT
   fully implement the behavior described here.

   Where any behavior is not explicitly described here, the behavior
   specified declined in [RFC5936] MUST be followed.  Any behavior specified here
   takes precedence for AXoT implementations over that this case e.g., Max concurrent XFR: too may
   concurrent transfers in [RFC5936].

5.6.2.  AXoT connection and message handling

   The first paragraph of Section 4.1.1 of [RFC5936] says that progress.  It could potentially contain a
   retry delay, or at least clients
   SHOULD close the connection when there is no 'apparent need' to use
   the connection can apply a reasonable back-off for some time period.

   For AXoT this requirement is updated: AXoT clients and servers SHOULD
   use EDNS0 Keepalive [RFC7828] to establish
   the connection timeouts retry.  This could avoid retry storms which have been observed to
   be used.
   actually increase the load on primaries in certain scenarios.

5.3.4.  The client SHOULD edns-tcp-keepalive EDNS0 Option

   XFR clients that send the edns-tcp-keepalive EDNS0 Keepalive option on every
   AXoT
   XFR request sent so that provide the server has every with maximum opportunity to update the Keepalive
   edns-tcp-keepalive timeout.  The AXoT XFR server may use the frequency of
   recent AXFRs XFRs to calculate an average update rate as input to the
   decision of what EDNS0 Keepalive edns-tcp-keepalive timeout to use.  If the server
   does not support EDNS0 Keepalive edns-tcp-keepalive the client MAY keep the
   connection open for a few seconds ([RFC7766] recommends that servers
   use timeouts of at least a few seconds).

   Whilst the specification for EDNS0 [RFC6891]  does not specifically
   mention AXFRs, it does say

       "If an OPT record is present in a received request, compliant
       responders MUST include an OPT record in their respective
       responses."

   We clarify here that if an OPT record is present in a received AXoT AXFR
   request, compliant responders MUST include an OPT record in each of
   the subsequent AXoT AXFR responses.  Note that this requirement, combined
   with the use of EDNS0 Keepalive, edns-tcp-keepalive, enables AXoT AXFR servers to signal
   the desire to close a connection (when existing transactions have
   competed) due to low resources by sending an edns-tcp-keepalive EDNS0
   Keepalive
   option with a timeout of 0 on any AXoT response (in the
   absence of another way to AXFR response.  This does not
   signal that the AXFR is aborted, just that the abort of a AXoT transfer).

   An AXoT server MUST be able wishes to handle multiple AXFR requests on a
   single XoT close
   the connection (for the same as soon as possible.

5.3.5.  Backwards compatibility

   Certain legacy behaviors were noted in [RFC5936], with provisos that
   implementations may want to offer options to fallback to legacy
   behavior when interoperating with servers known not to support
   [RFC5936].  For purposes of interoperability, IXFR and different zones).

   [RFC5936] says:

       "An AXFR client MAY use an already opened TCP connection
   implementations may want to continue offering such configuration
   options, as well as supporting some behaviors that were
   underspecified prior to
       start an AXFR session. Using an existing open connection is
       RECOMMENDED over opening a new connection. (Non-AXFR session
       traffic can also use an open connection.)"

   For AXoT this requirement is updated: AXoT clients SHOULD re-use an
   existing open work (e.g. performing IXFR and AXFRs on
   separate connections).  However, XoT connection when starting any new AXoT session implementations should have no
   need to do so.

5.4.  Update to RFC7766

   [RFC7766] made general implementation recommendations with regard to
   TCP/TLS connection handling:

      "To mitigate the same primary, and for issuing SOA queries, instead risk of opening a
   new connection.  The unintentional server overload, DNS
      clients MUST take care to minimize the number of XoT concurrent TCP
      connections between a secondary
   and primary made to any individual server. It is RECOMMENDED
      that for any given client/server interaction there SHOULD be minimized.

   Valid reasons no
      more than one connection for not re-using existing connections might include:

   o  reaching a configured limit regular queries, one for the number of outstanding queries
      allowed on a single XoT connection

   o  the message ID pool has already been exhausted zone
      transfers, and one for each protocol that is being used on an open
      connection

   o  a large number top
      of timeouts or slow responses have occurred on an
      open connection

   o  an EDNS0 Keepalive option with a timeout of 0 has been received
      from the server and TCP (for example, if the client resolver was using TLS). However,
      it is in the process of closing the
      connection

   If no XoT connections are currently open, AXoT clients MAY send SOA
   queries over UDP, TCP or TLS.

   [RFC5936] says:

      "Some old AXFR clients expect each response message to contain
      only a single RR. To interoperate noted that certain primary/ secondary configurations with such clients, the server
      MAY restrict response messages
      many busy zones might need to a single RR."

   This is opposed use more than one TCP connection
      for zone transfers for operational reasons (for example, to the normal behavior
      support concurrent transfers of containing multiple zones)."

   Whilst this recommends a sufficient
   number of RRs to reasonably amortize particular behavior for the per-message overhead.  We
   clarify here that AXoT clients MUST be able using
   TCP, it does not relax the requirement for servers to handle responses that
   include multiple RRs, up to 'mixed'
   traffic (regular queries and zone transfers) on any open TCP/TLS
   connection.  It also overlooks the largest number potential that will fit within a
   DNS message (taking the required content of the other sections into
   account, as described here and in [RFC5936]).  This removes any
   burden on AXoT servers of having transports
   might want to accommodate a configuration
   option or support for restricting responses take the same approach with regard to containing only a
   single RR.

   An AXoT client SHOULD pipeline AXFR requests using separate
   connections for different zones on a
   single purposes.

   This specification for XoT connection.  An AXoT server SHOULD respond updates the guidance in [RFC7766] to those
   requests as soon as
   provide the response is available i.e. potentially out of
   order.

5.6.3.  Padding AXoT responses

   The goal same separation of padding AXoT responses would be two fold:

   o  to obfuscate the actual size of the transferred connection purpose (regular queries
   and zone to minimize
      information leakage about the entire contents transfers) for all transports being used on top of the zone.

   o  to obfuscate the incremental changes to the zone between SOA
      updates to minimize information leakage about zone update activity
      and growth.

   Note TCP.
   Therefore, it is RECOMMENDED that the re-use of XoT connections for transfers each protocol used on top of multiple
   different zones complicates
   TCP in any attempt to analyze the traffic size given client/server interaction there SHOULD be no more
   than one connection for regular queries and timing to extract information.

   We note here that any requirement to obfuscate the total one for zone size is
   likely to require a server to create 'empty' AXoT responses.  That
   is, AXoT responses that contain no RR's apart from transfers.
   As an OPT RR
   containing the EDNS(0) option for padding.  However, as with existing
   AXFR, the last AXoT response message sent MUST contain the same SOA illustration, it could be imagined that was in the first message future such an
   interaction could hypothetically include one or all of the AXoT response series following:

   o  one TCP connection for regular queries

   o  one TCP connection for zone transfers

   o  one TLS connection for regular queries

   o  one TLS connection for zone transfers

   o  one DoH connection for regular queries

   o  one DoH connection for zone transfers

   We provide specific details in order to
   signal the conclusion later sections of the zone transfer.

   [RFC5936] says:

      "Each AXFR response message SHOULD contain reasons where
   more than one connection for 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 given transport might be required content for
   zone transfers from a particular client.

6.  XoT specification

6.1.  TLS versions

   For improved security all implementations of the other sections into account, this specification MUST
   use only TLS 1.3 [RFC8446] or later.

6.2.  Port selection

   The connection for XoT SHOULD be established using port 853, as
      described below)."

   'Empty' AXoT responses generated
   specified in order [RFC7858], unless there is mutual agreement between the
   secondary and primary to meet use a padding
   requirement will port other than port 853 for XoT.
   There MAY be exceptions to the above statement.  In order agreement to
   guarantee support use different ports for future padding policies, we state here AXoT and IXoT, or
   for different zones.

6.3.  High level XoT descriptions

   It is useful to note that in XoT it is the secondary implementations MUST be resilient to receiving padded AXoT
   responses, including 'empty' AXoT responses that contain only an OPT
   RR containing initiates
   the EDNS(0) option for padding.

   Recommendation of specific policies for padding AXoT responses are
   out of scope TLS connection to the primary for this specification.  Detailed considerations a XFR request, so that in terms
   of such
   policies connectivity the secondary is the TLS client and the trade-offs involved are expected to be primary the subject
   TLS server.

   The figure below provides an outline of future work.

5.7.  IXoT the AXoT mechanism

5.7.1.  Coverage and relationship to RFC1995

   [RFC1995] says nothing with respect to optimizing IXFRs over TCP or
   re-using already open TCP connections to perform IXFRs or other
   queries.  Therefore, there arguably is an implicit assumption
   (probably unintentional) that including
   NOTIFYs.

        Secondary                            Primary

            |              NOTIFY               |
            | <-------------------------------- |  UPD
            | --------------------------------> |
            |          NOTIFY Response          |
            |                                   |
            |                                   |
            |            SOA Request            |
            | --------------------------------> |  UDP (or part of
            | <-------------------------------- |  a TCP connection is used for one and
   only one TCP/TLS session)
            |           SOA Response            |
            |                                   |
            |                                   |
            |                                   |
            |            AXFR Request           | ---
            | --------------------------------> |   |
            | <-------------------------------- |   |
            |          AXFR Response 1          |   |
            |             (Zone data)           |   |
            |                                   |   |
            | <-------------------------------- |   | TLS
            |          AXFR Response 2          |   | Session
            |             (Zone data)           |   |
            |                                   |   |
            | <-------------------------------- |   |
            |          AXFR Response 3          |   |
            |             (Zone data)           | ---
            |                                   |

                   Figure 3. AXoT Mechanism

   The figure below provides an outline of the IXoT mechanism including
   NOTIFYs.

        Secondary                            Primary

            |              NOTIFY               |
            | <-------------------------------- |  UPD
            | --------------------------------> |
            |          NOTIFY Response          |
            |                                   |
            |                                   |
            |            SOA Request            |
            | --------------------------------> |  UDP (or part of
            | <-------------------------------- |  a TCP/TLS session)
            |           SOA Response            |
            |                                   |
            |                                   |
            |                                   |
            |            IXFR request.  Indeed, several open source implementations
   currently take this approach.

   We provide new guidance here specific to Request           | ---
            | --------------------------------> |    |
            | <-------------------------------- |    |
            |            IXFR Response          |    |
            |             (Zone data)           |    |
            |                                   |    | TLS
            |                                   |    | session
            |            IXFR Request           |    |
            | --------------------------------> |    |
            | <-------------------------------- |    |
            |            IXFR Response          |    |
            |             (Zone data)           | ---

                   Figure 1. IXoT that aligns Mechanism

6.4.  XoT transfers

   For a zone transfer between two end points to be considered protected
   with the
   guidance in [RFC5936] for AXFR, that in section Section 5.6 for AXoT, XoT all XFR requests and with that response for performant TCP/TLS usage in [RFC7766] and
   [RFC7858].

   Where any behavior is not explicitly described here, the behavior
   specified in [RFC1995] that zone MUST be followed.  Any behavior specified here
   takes precedence for IXoT implementations sent
   over that in [RFC1995].

5.7.2.  IXoT connection and message handling

   In TLS connections where at a manner entirely analogous to that minimum:

   o  the client MUST authenticate the server by use of an
      authentication domain name using a Strict Privacy Profile as
      described in paragraph 2 of
   Section 5.6.2 IXoT clients and servers SHOULD use EDNS0 Keepalive
   [RFC7828] to establish [RFC8310]

   o  the connection timeouts to be used.

   An IXoT server MUST be able validate the client is authorized to handle multiple IXoT requests on request or
      proxy a
   single XoT connection (for zone transfer by using one or both of the same and different zones).

   IXoT clients SHOULD re-use following:

      *  an existing open XoT connection when
   making any new IXoT request to the same primary, and for issuing SOA
   queries, instead of opening a new connection. IP based ACL (which can be either per-message or per-
         connection)

      *  Mutual TLS (mTLS)

   The number of XoT
   connections between server MAY also require a secondary and primary SHOULD be minimized.

   Valid reasons for valid TSIG/SIG(0) signature, but this
   alone is not re-using existing connections sufficient to authenticate the client or server.

   Authentication mechanisms are discussed in full in Section 8 and the same as
   those described
   rationale for the above requirement in Section 9.  Transfer group
   policies are discussed in Section 10.

6.5.  XoT connections

   The details in Section 5.6.2 5 about e.g., persistent connections and XFR
   message handling are fully applicable to XoT connections as well.
   However any behavior specified here takes precedence for XoT.

   If no XoT TLS connections are currently open, IXoT XoT clients MAY send SOA
   queries over UDP, TCP UDP or TCP, or TLS.

   An IXoT client SHOULD pipeline IXFR requests for different zones on a
   single

6.6.  XoT connection.  An IXoT server SHOULD respond to those
   requests as soon as the response vs ADoT

   As noted earlier, there is available i.e. potentially out of
   order.

5.7.3.  Condensation of responses

   [RFC1995] says condensation currently no specification for encryption
   of responses is optional and MAY be done.
   Whilst it does add complexity connections from recursive resolvers to generating responses authoritative servers.
   Some authoritatives are experimenting with ADoT and opportunistic
   encryption has also been raised as a possibility; it can
   significantly reduce the size is therefore
   highly likely that use of responses.  However any such
   reduction might be offset encryption by increased message size due to padding. authoritative servers will
   evolve in the coming years.

   This specification does not update raises questions in the optionality of condensation.

5.7.4.  Fallback to AXFR

   Fallback short term,S.S. with regard to AXFR can happen, TLS
   connection and message handling for example, if the server authoritative servers.  In
   particular, there is not able likely to provide an IXFR for the requested SOA.  Implementations differ in
   how long they store zone deltas and how many may be stored at any one
   time.

   After a failed IXFR a IXoT client SHOULD request the AXFR on the
   already open XoT connection.

5.7.5.  Padding of IXoT responses

   The goal class of padding IXoT responses would be to obfuscate the
   incremental changes to the zone between SOA updates authoritatives that wish
   to minimize
   information leakage about zone update activity and growth.  Both the
   size and timing of the IXoT responses could reveal information.

   IXFR responses can vary use XoT in size greatly from the order of 100 bytes
   for one or two record updates, to tens of thousands of bytes for
   large dynamic DNSSEC signed zones.  The frequency near future with a small number of IXFR responses
   can also depend greatly on if and how the zone is DNSSEC signed.

   In order configured
   secondaries but that do wish to guarantee support DoT for future padding policies, we state
   here regular queries from
   recursive in that secondary implementations MUST be resilient same time frame.  These servers have to receiving
   padded IXoT responses.

   Recommendation of specific policies for padding IXoT responses are
   out of scope for this specification.  Detailed considerations of such
   policies potentially
   cope with probing and the trade-offs involved are expected to be the subject
   of future work.

6.  Multi-primary Configurations

   Also known as multi-master configurations this model can provide
   flexibility direct queries from recursives and redundancy particularly for IXFR.  A secondary will
   receive one or more NOTIFY messages from test
   servers, and can send an SOA also potential attacks that might wish to all make use of
   TLS to overload the
   configured primaries.  It server.

   [RFC5936] clearly states that non-AXFR session traffic can then choose to send use an XFR request
   open TCP connection, however, this requirement needs to be re-
   evaluated when considering applying the primary with the highest SOA (or other criteria, e.g., RTT).

   When using persistent connections the secondary may have a XoT
   connection already open same model to one or more primaries.  Should a secondary
   preferentially request an XFR from XoT.  Proposing
   that a primary server should also start responding to which all queries received
   over TLS just because it already has
   an open enabled 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 would be considered equivalent to
   defining a 'preferred primary connection' model.  In form of authoritative DoT.  This specification does not
   propose that, but it also does not prohibit servers from answering
   queries unrelated to XFR exchanges over TLS.  Rather, this case the secondary
   continues
   specification simply outlines in later sections:

   o  how XoT implementations should utilize EDE codes in response to use one persistent connection
      queries on TLS connections they are not willing to answer (see
      Section 6.7)

   o  the operational and policy options that a single primary until
   it XoT server operator has reason not to.  Reasons
      with regard to managing TLS connections and messages (see
      Appendix A)

6.7.  Response RCODES

   XoT clients and servers MUST implement EDE codes.  If a XoT server
   receives non-XoT traffic it is not willing to might include the primary
   repeatedly closing the connection, long RTTs answer on transfers or a TLS
   connection it SHOULD respond with the SOA extended DNS error code 21 -
   Not Supported [RFC8914].  XoT clients should not send any further
   queries of this type to the primary being an unacceptable lag behind the SOA of an
   alternative primary.

   The other extreme can be considered server for 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 reasonable period of
   secondaries and primaries in direct contact in a transfer group is
   reasonably low this might be feasible if latency is time
   (for example, one hour) i.e., long enough that the most
   significant concern.

   Recommendation of a particular scheme is out of scope of this
   document but implementations are encouraged to provide server
   configuration
   options that allow operators to make choices about or policy might be updated.

   [OPEN QUESTION] Should this behavior.

7.  Zone Transfer with DoT - Authentication

7.1.  TSIG

   TSIG [RFC2845] provides a mechanism for two instead be Prohibited (by policy), or more parties to use
   shared secret keys which can then
   should a new EDE be created for this case?

   Historically servers have used the REFUSED RCODE for many situations,
   and so clients often had no detailed information on which to create base an
   error or fallback path when queries were refused.  As a message digest
   to protect individual DNS messages.  This allows each party to
   authenticate result the
   client behavior could vary significantly.  XoT severs that a request or response (and refuse
   queries must cater for the data in it) came fact that client behavior might vary from
   continually retrying queries regardless of receiving REFUSED to every
   query, or at the other party, even if it was transmitted extreme clients may decide to stop using the
   server over an unsecured
   channel any transport.  This might be because those clients are
   either non-XoT clients or via a proxy.  It provides party-to-party data
   authentication, but do not hop-to-hop channel authentication or
   confidentiality.

7.2.  SIG(0)

   SIG(0) [RFC2535] similarly also provides a mechanism implement EDE codes.

6.8.  AXoT specifics

6.8.1.  Padding AXoT responses

   The goal of padding AXoT responses would be two fold:

   o  to digitally
   sign a DNS message but uses public key authentication, where obfuscate the
   public keys are stored in DNS as KEY RRs and a private key is stored
   at actual size of the signer.  It also provides party-to-party data authentication,
   but not hop-to-hop channel authentication or confidentiality.

7.3.  TLS

7.3.1.  Opportunistic

   Opportunistic TLS [RFC8310] provides a defense against passive
   surveillance, providing on-the-wire confidentiality.

7.3.2.  Strict

   Strict TLS [RFC8310] requires that a client is configured with an
   authentication domain name (and/or SPKI pinset) that should be used transferred zone to authenticate minimize
      information leakage about the TLS handshake with entire contents of the server.  This additionally
   provides a defense for zone.

   o  to obfuscate the client against active surveillance,
   providing client-to-server authentication and end-to-end channel
   confidentiality.

7.3.3.  Mutual

   This is an extension incremental changes to Strict TLS [RFC8310] which requires that a
   client is configured with an authentication domain name (and/or SPKI
   pinset) the zone between SOA
      updates to minimize information leakage about zone update activity
      and a client certificate.  The client offers growth.

   Note that the certificate re-use of XoT connections for authentication by transfers of multiple
   different zones complicates any attempt to analyze the server traffic size
   and timing to extract information.

   It is noted here that, depending on the client can authentic padding policies eventually
   developed for XoT, the
   server requirement to obfuscate the same way as in Strict TLS.  This provides total zone size
   might require a defense for
   both parties against active surveillance, providing bi-directional
   authentication and end-to-end channel confidentiality.

7.4.  IP Based ACL on the Primary

   Most DNS server implementations offer an option to configure create 'empty' AXoT responses.  That is,
   AXoT responses that contain no RR's apart from an IP
   based Access Control List (ACL), which is often used in combination
   with TSIG based ACLs to restrict access to zone transfers on primary
   servers.

   This is also possible with XoT but it must be noted that as with TCP OPT RR containing
   the implementation of such an ACL cannot be enforced on EDNS(0) option for padding.  For example, without this capability
   the primary
   until maximum size that a XFR request is received on an established connection.

   If control were to tiny zone could be any more fine-grained than this then a
   separate, dedicated port would need padded to be agreed between primary and
   secondary for XoT such that implementations would
   theoretically be able to refuse
   connections on that port limited if there had to all clients except those configured as
   secondaries.

7.5.  ZONEMD

   Message Digest for DNS Zones (ZONEMD)
   [I-D.ietf-dnsop-dns-zone-digest] digest is be a mechanism minimum of 1 RR per
   packet.

   However, as with existing AXFR, the last AXoT response message sent
   MUST contain the same SOA that can be
   used to verify was in the content first message of a standalone zone.  It is designed the AXoT
   response series in order to
   be independent signal the conclusion of the transmission channel or mechanism, allowing zone
   transfer.

   [RFC5936] says:

      "Each AXFR response message SHOULD contain a
   general consumer sufficient number
      of a zone RRs to do origin authentication of reasonably amortize the entire
   zone contents.  Note per-message overhead, up to
      the largest number that will fit within a DNS message (taking
      the current version required content of
   [I-D.ietf-dnsop-dns-zone-digest] states:

   "As specified at this time, ZONEMD is not designed for use in large,
   dynamic zones due to the time and resources required for digest
   calculation.  The ZONEMD record other sections into account, as
      described in this document includes
   fields reserved for future work below)."

   'Empty' AXoT responses generated in order to meet a padding
   requirement will be exceptions to support large, dynamic zones."

   It is complementary the above mechanisms statement.  For
   flexibility, future proofing and can be used in
   conjunction with XoT but is not considered further.

7.6.  Comparison of Authentication Methods

   The Table below compares order to guarantee support for
   future padding policies, we state here that secondary implementations
   MUST be resilient to receiving padded AXoT responses, including
   'empty' AXoT responses that contain only an OPT RR containing the properties
   EDNS(0) option for padding.

   Recommendation of a selection specific policies for padding AXoT responses are
   out of the above
   methods in terms scope for this specification.  Detailed considerations of what protection they provide such
   policies and the trade-offs involved are expected to be the secondary subject
   of future work.

6.9.  IXoT specifics

6.9.1.  Condensation of responses

   [RFC1995] says condensation of responses is optional and
   primary servers during XoT in terms of:

   o  'Data Auth': Authentication that MAY be done.
   Whilst it does add complexity to generating responses it can
   significantly reduce the DNS message data is signed size of responses.  However any such
   reduction might be offset by
      the party with whom credentials were shared (the signing party may
      or may increased message size due to padding.
   This specification does not be party operating update the far end optionality of a TCP/TLS connection
      in a 'proxy' scenario).  For the primary the TSIG on the XFR
      request confirms that condensation
   for XoT responses.

6.9.2.  Fallback to AXFR

   Fallback to AXFR can happen, for example, if the requesting party server is authorized not able
   to
      request zone data, provide an IXFR for the secondary it authenticates the zone
      data that is received.

   o  'Channel Conf': Confidentiality requested SOA.  Implementations differ in
   how long they store zone deltas and how many may be stored at any one
   time.

   Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD
   request the AXFR on the already open XoT connection.

6.9.3.  Padding of IXoT responses

   The goal of padding IXoT responses would be to obfuscate the communication channel
   incremental changes to the zone between SOA updates to minimize
   information leakage about zone update activity and growth.  Both the client
   size and server (i.e. timing of the IXoT responses could reveal information.

   IXFR responses can vary in size greatly from the order of 100 bytes
   for one or two end points record updates, to tens of a TCP/
      TLS connection).

   o  Channel Auth: Authentication thousands of bytes for
   large dynamic DNSSEC signed zones.  The frequency of IXFR responses
   can also depend greatly on if and how the identity zone is DNSSEC signed.

   In order to guarantee support for future padding policies, we state
   here that secondary implementations MUST be resilient to receiving
   padded IXoT responses.

   Recommendation of party specific policies for padding IXoT responses are
   out of scope for this specification.  Detailed considerations of such
   policies and the trade-offs involved are expected to whom a
      TCP/TLS connection is made (this might not be a direct connection
      between the primary subject
   of future work.

6.10.  Name compression and secondary in a proxy scenario). maximum payload sizes

   It is noted here that zone transfer scenarios name compression [RFC1035] can vary from a simple
   single primary/secondary relationship where both servers are under be used in XFR
   responses to reduce the control size of a single operator to a complex hierarchical structure
   which includes proxies and multiple operators.  Each deployment
   scenario will require specific analysis to determine which
   authentication methods are best suited to the deployment model in
   question.

   Table 1: Properties payload, however the maximum
   value of Authentication methods for XoT [7]

   Based on this analysis it the offset that can be seen that:

   o  A combination of Opportunistic TLS and TSIG provides both data
      authentication and channel confidentiality for both parties.
      However used in the name compression pointer
   structure is 16384.  For some DNS implementations this does not stop a MitM attack on limits the channel which
      could be
   size of an individual XFR response used in practice to gather zone data.

   o  Using just mutual TLS something
   around the order of 16kB.  In principle, larger payload sizes can be considered a standalone solution if
   supported for some responses with more sophisticated approaches (e.g.
   by pre-calculating the secondary has reason maximum offset required).

   Implementations may wish to place equivalent trust offer options to disable name compression
   for XoT responses to enable larger payloads.  This might be
   particularly helpful when padding is used since minimizing the
   payload size is not necessarily a useful optimization in channel
      authentication as data authentication, e.g., this case
   and disabling name compression will reduce the same operator
      runs both resources required to
   construct the primary payload.

7.  Multi-primary Configurations

   Also known as multi-master configurations this model can provide
   flexibility and secondary.

   o  Using TSIG, Strict TLS redundancy particularly for IXFR.  A secondary will
   receive one or more NOTIFY messages and can send an ACL on the primary provides SOA to all 3
      properties for both parties with probably the lowest operational
      overhead.

8.  Policies for Both AXFR and IXFR

   We call the entire group of servers involved in the
   configured primaries.  It can then choose to send an XFR (all request to
   the
   primaries and all primary with the secondaries) highest SOA (or other criteria, e.g., RTT).

   When using persistent connections the 'transfer group'.

   Within any transfer group both AXFRs and IXFRs for secondary may have a zone SHOULD all
   use the same policy, e.g., if AXFRs use AXoT all IXFRs SHOULD use
   IXoT.

   In order XoT
   connection already open to assure the confidentiality of the zone information, the
   entire transfer group MUST have one or more primaries.  Should a consistent policy of requiring
   confidentiality.  If any do not, this is secondary
   preferentially request an XFR from a weak link for attackers primary to
   exploit.

   A which it already has
   an open XoT policy should specify

   o  If TSIG or SIG(0) is required

   o  What kind of TLS is required (Opportunistic, Strict connection or mTLS)

   o  If IP based ACLs should also the one with the highest SOA (assuming it
   doesn't have a connection open to it already)?

   Two extremes can be used.

   Since envisaged here.  The first one can be considered
   a 'preferred primary connection' model.  In this may require configuration of case the secondary
   continues to use one persistent connection to a number of servers who may
   be under single primary until
   it has reason not to.  Reasons not to might include the control of different operators primary
   repeatedly closing the desired consistency
   could be hard to enforce and audit in practice.

   Certain aspects connection, long RTTs on transfers or the SOA
   of the Policies primary being an unacceptable lag behind the SOA of an
   alternative primary.

   The other extreme can be relatively easily tested
   independently, e.g., by requesting zone transfers without TSIG, from
   unauthorized IP addresses or over cleartext DNS.  Other aspects such
   as if considered a 'parallel primary connection'
   model.  Here a secondary will accept data without 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 TSIG digest or transfer group is
   reasonably low this might be feasible if
   secondaries are using Strict as opposed to Opportunistic TLS are more
   challenging.

   The mechanics latency is the most
   significant concern.

   Recommendation of co-ordinating or enforcing such policies are a particular scheme is out of
   the scope of this
   document but may be the subject of future
   operational guidance.

9.  Implementation Considerations

   TBD

10.  Implementation Status

   The 1.9.2 version of Unbound [8] includes an option implementations are encouraged to perform AXoT
   (instead of AXFR-over-TCP).  This requires the client (secondary) provide configuration
   options that allow operators to make choices about this behavior.

8.  Authentication mechanisms

   To provide context to
   authenticate the server (primary) using requirements in section Section 6.4, this
   section provides a configured authentication
   domain name.

   It is noted that use brief summary of a TLS proxy in front some of the primary server is
   a simple deployment solution existing
   authentication and validation mechanisms (both transport independent
   and TLS specific) that can enable server side XoT.

11.  IANA Considerations

11.1.  Registration of XoT Identification String

   This document creates are available when performing zone transfers.
   Section 9 then discusses in more details specifically how a new registration for the identification
   combination of
   XoT in TLS authentication, TSIG and IP based ACLs interact
   for XoT.

   We classify the "Application Layer Protocol Negotiation (ALPN) Protocol
   IDs" registry [RFC7301].

   The "xot" string identifies XoT:

   Protocol: XoT

   Identification Sequence: 0x64 0x6F 0x72 ("xot")

   Specification: This document

12.  Security Considerations

   This document specifies a security measure against a DNS risk: mechanisms based on the
   risk following properties:

   o  'Data Origin Authentication' (DO): Authentication that an attacker collects entire DNS zones through eavesdropping
   on clear text the DNS zone transfers.

   This does not mitigate:

   o
      message originated from 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 party with obtaining SOA
      records by directly querying authoritative servers.

   o  the risk that hidden primaries might be inferred or identified via
      observation whom credentials were
      shared, and of encrypted connections.

   o the risk of zone contents being obtained via zone enumeration
      techniques.

   Security concerns data integrity of DoT are outlined in [RFC7858] and [RFC8310].

13.  Acknowledgements

   The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for
   review and discussions.

14.  Contributors

   Significant contributions to the document were made by:

   Han Zhang
   Salesforce
   San Francisco, CA
   United States

   Email: hzhang@salesforce.com

15.  Changelog

   draft-ietf-dprive-xfr-over-tls-02

   o  Significantly update descriptions for both AXoT and IXoT for message and contents (the
      originating party may or may not be party operating the far end of
      a TCP/TLS connection handling taking into account previous
      specifications in more detail a 'proxy' scenario).

   o  Add use  'Channel Confidentiality' (CC): Confidentiality of APLN the
      communication channel between the client and limitations on traffic on XoT connections.

   o  Add new discussions server (i.e. the two
      end points of padding for both AXoT and IXoT

   o  Add text on SIG(0)

   o  Update security considerations a TCP/TLS connection) from passive surveillance.

   o  Move multi-primary considerations to earlier as they are related  'Channel Authentication' (CA): Authentication of the identity of
      party to whom a TCP/TLS connection handling

   draft-ietf-dprive-xfr-over-tls-01
   o  Minor editorial updates

   o  Add requirement for TLS 1.3. or later

   draft-ietf-dprive-xfr-over-tls-00

   o  Rename after adoption is made (this might not be a
      direct connection between the primary and reference update.

   o  Add placeholder for SIG(0) discussion

   o  Update section on ZONEMD

   draft-hzpa-dprive-xfr-over-tls-02

   o  Substantial re-work of the document.

   draft-hzpa-dprive-xfr-over-tls-01

   o  Editorial changes, updates to references.

   draft-hzpa-dprive-xfr-over-tls-00

   o  Initial commit

16.  References

16.1.  Normative References

   [I-D.vcelak-nsec5]
              Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and
              D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of
              Existence", draft-vcelak-nsec5-08 (work in progress),
              December 2018.

   [RFC1995]  Ohta, M., "Incremental Zone Transfer secondary in DNS", RFC 1995,
              DOI 10.17487/RFC1995, August 1996, <https://www.rfc-
              editor.org/info/rfc1995>.

   [RFC2119]  Bradner, S., "Key words a proxy
      scenario).

8.1.  TSIG

   TSIG [RFC2845] provides a mechanism for two or more parties to use
   shared secret keys which can then be used to create a message digest
   to protect individual DNS messages.  This allows each party to
   authenticate that a request or response (and the data in RFCs it) came
   from the other party, even if it was transmitted over an unsecured
   channel or via a proxy.

   Properties: Data origin authentication

8.2.  SIG(0)

   SIG(0) [RFC2535] similarly also provides a mechanism to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., digitally
   sign a DNS message but uses public key authentication, where the
   public keys are stored in DNS as KEY RRs and B.
              Wellington, "Secret Key Transaction Authentication a private key is stored
   at the signer.

   Properties: Data origin authentication

8.3.  TLS

8.3.1.  Opportunistic TLS

   Opportunistic TLS for DNS
              (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
              <https://www.rfc-editor.org/info/rfc2845>.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., DoT is defined in [RFC8310] and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
              <https://www.rfc-editor.org/info/rfc5155>.

   [RFC5936]  Lewis, E. can provide a
   defense against passive surveillance, providing on-the-wire
   confidentiality.  Essentially

   o  clients that know authentication information for a server SHOULD
      try to authenticate the server

   o  however they MAY fallback to using TLS without authentication and A. Hoenes, Ed., "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
              <https://www.rfc-editor.org/info/rfc5936>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M.,

   o  they MAY fallback to using cleartext is TLS is not available.

   As such it does not offer a defense against active attacks (e.g. a
   MitM attack on the connection from client to server), and R. Smith, "Privacy
              Considerations is not
   considered as useful for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
              editor.org/info/rfc6973>.

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
              DOI 10.17487/RFC7626, August 2015, <https://www.rfc-
              editor.org/info/rfc7626>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification XoT.

   Properties: None guaranteed.

8.3.2.  Strict TLS

   Strict TLS for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>. DoT [RFC8310]  Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
              for DNS over requires that a client is configured
   with an authentication domain name (and/or SPKI pinset) that MUST be
   used to authenticate the TLS handshake with the server.  If
   authentication of the server fails, the client will not proceed with
   the connection.  This provides a defense for the client against
   active surveillance, providing client-to-server authentication and DNS over DTLS", RFC 8310,
              DOI 10.17487/RFC8310, March 2018, <https://www.rfc-
              editor.org/info/rfc8310>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

   [RFC8499]  Hoffman, P., Sullivan, A.,
   end-to-end channel confidentiality.

   Properties: Channel confidentiality and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

16.2.  Informative References

   [I-D.ietf-dnsop-dns-zone-digest]
              Wessels, D., Barber, P., Weinberg, M., Kumari, W., authentication (of the
   server).

8.3.3.  Mutual TLS

   This is an extension to Strict TLS [RFC8310] which requires that a
   client is configured with an authentication domain name (and/or SPKI
   pinset) and W.
              Hardaker, "Message Digest a client certificate.  The client offers the certificate
   for DNS Zones", draft-ietf-
              dnsop-dns-zone-digest-08 (work in progress), June 2020.

   [I-D.ietf-dnsop-extended-error]
              Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
              Lawrence, "Extended DNS Errors", draft-ietf-dnsop-
              extended-error-16 (work in progress), May 2020.

   [I-D.ietf-dprive-dnsoquic]
              Huitema, C., Mankin, A., authentication by the server and S. Dickinson, "Specification
              of DNS over Dedicated QUIC Connections", draft-ietf-
              dprive-dnsoquic-00 (work the client can authentic the
   server the same way as in progress), April 2020.

   [I-D.ietf-dprive-phase2-requirements]
              Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS
              Privacy Requirements Strict TLS.  This provides a defense for Exchanges between Recursive
              Resolvers
   both parties against active surveillance, providing bi-directional
   authentication and Authoritative Servers", draft-ietf-dprive-
              phase2-requirements-01 (work in progress), June 2020.

   [I-D.vandijk-dprive-ds-dot-signal-and-pin]
              Dijk, P., Geuze, R., end-to-end channel confidentiality.

   Properties: Channel confidentiality and E. Bretelle, "Signalling
              Authoritative DoT support mutual authentication.

8.4.  IP Based ACL on the Primary

   Most DNS server implementations offer an option to configure an IP
   based Access Control List (ACL), which is often used in DS records, combination
   with key
              pinning", draft-vandijk-dprive-ds-dot-signal-and-pin-00
              (work in progress), May 2020.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - TSIG based ACLs to restrict access to zone transfers on primary
   servers on a per query basis.

   This is also possible with XoT but it must be noted that, as with
   TCP, the implementation of such an ACL cannot be enforced on the
   primary until an XFR request is received on an established
   connection.

   As discussed in Appendix A an IP based per connection ACL could also
   be implemented where only TLS connections from recognized secondaries
   are accepted.

   Properties: Channel authentication of the client.

8.5.  ZONEMD

   For completeness, we also describe Message Digest for DNS Zones
   (ZONEMD) [I-D.ietf-dnsop-dns-zone-digest] here.  The message digest
   is a mechanism that can be used to verify the content of a standalone
   zone.  It is designed to be independent of the transmission channel
   or mechanism, allowing a general consumer of a zone to do origin
   authentication of the entire zone contents.  Note that the current
   version of [I-D.ietf-dnsop-dns-zone-digest] states:

   "As specified herein, ZONEMD is impractical for large, dynamic zones
   due to the time and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC1982]  Elz, R. resources required for digest calculation.
   However, The ZONEMD record is extensible so that new digest schemes
   may be added in the future to support large, dynamic zones."

   It is complementary but orthogonal the above mechanisms; and can be
   used in conjunction with XoT but is not considered further here.

9.  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
   which 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 6.4 addresses
   the issue of ensuring that the transfers is encrypted between the two
   endpoints directly involved in the current transfers.  The following
   table summarized the properties of a selection of the mechanisms
   discussed in Section 8.  The two letter acronyms for the properties
   are used below and (S) indicates the secondary and (P) indicates the
   primary.

    +----------------+-------+-------+-------+-------+-------+-------+
    | Method         | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) |
    +----------------+-------+-------+-------+-------+-------+-------+
    | Strict TLS     |       |   Y   |   Y   |       |   Y   |       |
    | Mutual TLS     |       |   Y   |   Y   |       |   Y   |   Y   |
    | ACL on primary |       |       |       |       |       |   Y   |
    | TSIG           |   Y   |       |       |   Y   |       |       |
    +----------------+-------+-------+-------+-------+-------+-------+

   Table 1: Properties of Authentication methods for XoT

   Based on this analysis it can be seen that:

   o  Using just mutual TLS can be considered a standalone solution
      since both end points are authenticated

   o  Using Strict TLS and an IP based ACL on the primary also provides
      authentication of both end points

   o  Additional use of TSIG (or equally SIG(0)) can also provide data
      origin authentication which might be desirable for deployments
      that include a proxy between the secondary and primary, but is not
      part of the XoT requirement because it does nothing to guarantee
      channel confidentiality or authentication.

10.  Policies for Both AXoT and IXoT

   Whilst the protection of the zone contents in a transfer between two
   end points can be provided by the XoT protocol, the protection of all
   the transfers of a given zone requires operational administration and
   policy management.

   We call the entire group of servers involved in XFR for a particular
   set of zones (all the primaries and all the secondaries) the
   'transfer group'.

   Within any transfer group both AXFRs and IXFRs for a zone MUST all
   use the same policy, e.g., if AXFRs use AXoT all IXFRs MUST use IXoT.

   In order to assure the confidentiality of the zone information, the
   entire transfer group MUST have a consistent policy of requiring
   confidentiality.  If any do not, this is a weak link for attackers to
   exploit.

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

   A XoT policy should specify

   o  What kind of TLS is required (Strict or Mutual TLS)

   o  or if an IP based ACL is required.

   o  (optionally) if TSIG/SIG(0) is required

   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 easily tested
   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 co-ordinating or enforcing such policies are out of
   the scope of this document but may be the subject of future
   operational guidance.

11.  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
   for the multi-primary case where the primaries are migrating to XoT.

   Such configuration options MUST only be used in a 'migration mode'
   though and therefore should be used with care.

12.  Implementation Status

   The 1.9.2 version of Unbound [3] includes an option to perform AXoT
   (instead of AXFR-over-TCP).  This requires the client (secondary) to
   authenticate the server (primary) using a configured authentication
   domain name.

   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.

13.  IANA Considerations

14.  Security Considerations

   This document specifies a security measure against a DNS risk: the
   risk that an attacker collects entire DNS zones through eavesdropping
   on clear text DNS zone transfers.

   This does not mitigate:

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

   o  the risk that hidden primaries might be inferred or identified via
      observation of encrypted connections.

   o  the risk of zone contents being obtained via zone enumeration
      techniques.

   Security concerns of DoT are outlined in [RFC7858] and [RFC8310].

15.  Acknowledgements

   The authors thank Tony Finch, Peter van Dijk, Benno Overeinder,
   Shumon Huque and Tim Wicinski for review and discussions.

16.  Contributors

   Significant contributions to the document were made by:

   Han Zhang
   Salesforce
   San Francisco, CA
   United States

   Email: hzhang@salesforce.com

17.  Changelog

   draft-ietf-dprive-xfr-over-tls-03

   o  Remove propose to use ALPN

   o  Clarify updates to both RFC1995 and RFC5936 by adding specific
      sections on this

   o  Add a section on the threat model

   o  Convert all SVG diagrams to ASCII art

   o  Add discussions on concurrency limits

   o  Add discussions on Extended DNS error codes

   o  Re-work authentication requirements and discussion

   o  Add appendix discussion TLS connection management

   draft-ietf-dprive-xfr-over-tls-02
   o  Significantly update descriptions for both AXoT and IXoT for
      message and connection handling taking into account previous
      specifications in more detail

   o  Add use of APLN and limitations on traffic on XoT connections.

   o  Add new discussions of padding for both AXoT and IXoT

   o  Add text on SIG(0)

   o  Update security considerations

   o  Move multi-primary considerations to earlier as they are related
      to connection handling

   draft-ietf-dprive-xfr-over-tls-01

   o  Minor editorial updates

   o  Add requirement for TLS 1.3. or later

   draft-ietf-dprive-xfr-over-tls-00

   o  Rename after adoption and reference update.

   o  Add placeholder for SIG(0) discussion

   o  Update section on ZONEMD

   draft-hzpa-dprive-xfr-over-tls-02

   o  Substantial re-work of the document.

   draft-hzpa-dprive-xfr-over-tls-01

   o  Editorial changes, updates to references.

   draft-hzpa-dprive-xfr-over-tls-00

   o  Initial commit

18.  References

18.1.  Normative References

   [I-D.vcelak-nsec5]
              Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and
              D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of
              Existence", draft-vcelak-nsec5-08 (work in progress),
              December 2018.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              DOI 10.17487/RFC1995, August 1996, <https://www.rfc-
              editor.org/info/rfc1995>.

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
              August 1996, <https://www.rfc-editor.org/info/rfc1996>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
              <https://www.rfc-editor.org/info/rfc2845>.

   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
              <https://www.rfc-editor.org/info/rfc5936>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
              editor.org/info/rfc6973>.

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
              DOI 10.17487/RFC7626, August 2015, <https://www.rfc-
              editor.org/info/rfc7626>.

   [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
              D. Wessels, "DNS Transport over TCP - Implementation
              Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
              <https://www.rfc-editor.org/info/rfc7766>.

   [RFC7828]  Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
              edns-tcp-keepalive EDNS0 Option", RFC 7828,
              DOI 10.17487/RFC7828, April 2016, <https://www.rfc-
              editor.org/info/rfc7828>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8310]  Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
              for DNS over TLS and DNS over DTLS", RFC 8310,
              DOI 10.17487/RFC8310, March 2018, <https://www.rfc-
              editor.org/info/rfc8310>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

   [RFC8914]  Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
              Lawrence, "Extended DNS Errors", RFC 8914,
              DOI 10.17487/RFC8914, October 2020, <https://www.rfc-
              editor.org/info/rfc8914>.

18.2.  Informative References

   [I-D.ietf-dnsop-dns-zone-digest]
              Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
              Hardaker, "Message Digest for DNS Zones", draft-ietf-
              dnsop-dns-zone-digest-14 (work in progress), October 2020.

   [I-D.ietf-dprive-dnsoquic]
              Huitema, C., Mankin, A., and S. Dickinson, "Specification
              of DNS over Dedicated QUIC Connections", draft-ietf-
              dprive-dnsoquic-01 (work in progress), October 2020.

   [I-D.ietf-dprive-phase2-requirements]
              Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS
              Privacy Requirements for Exchanges between Recursive
              Resolvers and Authoritative Servers", draft-ietf-dprive-
              phase2-requirements-01 (work in progress), June 2020.

   [I-D.ietf-tls-esni]
              Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
              Encrypted Client Hello", draft-ietf-tls-esni-08 (work in
              progress), October 2020.

   [I-D.vandijk-dprive-ds-dot-signal-and-pin]
              Dijk, P., Geuze, R., and E. Bretelle, "Signalling
              Authoritative DoT support in DS records, with key
              pinning", draft-vandijk-dprive-ds-dot-signal-and-pin-01
              (work in progress), July 2020.

   [nist-guide]
              Chandramouli, R. and S. Rose, "Secure Domain Name System
              (DNS) Deployment Guide", 2013,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-81-2.pdf>.

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              DOI 10.17487/RFC1982, August 1996, <https://www.rfc-
              editor.org/info/rfc1982>.

   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
              Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
              <https://www.rfc-editor.org/info/rfc2535>.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
              <https://www.rfc-editor.org/info/rfc5155>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013, <https://www.rfc-
              editor.org/info/rfc6891>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

18.3.  URIs

   [1] https://www.isc.org/bind/

   [2] https://www.nlnetlabs.nl/projects/nsd/about/

   [3] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/
       Changelog

Appendix A.  XoT server connection handling

   For completeness, it is noted that an earlier version of the
   specification suggested using a XoT specific ALPN to negotiate TLS
   connections that supported only a limited set of queries (SOA, XRFs)
   however this did not gain support.  Reasons given included additional
   code complexity and proxies having no natural way to forward the ALPN
   signal to DNS nameservers over TCP connections.

A.1.  Only listen on TLS on a specific IP address

   Obviously a nameserver which hosts a zone and services queries for
   the zone on an IP address published in an NS record may wish to use a
   separate IP address for listening on TLS for XoT, only publishing
   that address to its secondaries.

   Pros: Probing of the public IP address will show no support for TLS.
   ACLs will prevent zone transfer on all transports on a per query
   basis.

   Cons: Attackers passively observing traffic will still be able to
   observe TLS connections to the separate address.

A.2.  Client specific TLS acceptance

   Primaries that include IP based ACLs and/or mutual TLS in their
   authentication models have the option of only accepting TLS
   connections from authorized clients.  This could be implemented using
   a proxy or directly in DNS implementation.

   Pros: Connection management happens at setup time.  The maximum
   number of TLS connections a server will have to support can be easily
   assessed.  Once the connection is accepted the server might well be
   willing to answer any query on that connection since it is coming
   from a configured secondary and a specific response policy on the
   connection may not be needed (see below).

   Cons: Currently, none of the major open source DNS authoritative
   implementations support such an option.

A.3.  SNI based TLS acceptance

   Primaries could also choose to only accept TLS connections based on
   an SNI that was published only to their secondaries.

   Pros: Reduces the number of accepted connections.

   Cons: As above.  For SNIs sent in the clear, this would still allow
   attackers passively observing traffic to potentially abuse this
   mechanism.  The use of Encrypted Client Hello [I-D.ietf-tls-esni] may
   be of use here.

A.4.  TLS 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 connections and then apply a TLS
   specific response policy on a per query basis.

   As an aside, whilst [RFC7766] makes a general purpose distinction to
   clients in the usage of connections (between regular queries and zone
   transfers) this is not strict and nothing in the DNS protocol
   prevents using the same connection for both types of traffic.  Hence
   a server cannot know the intention of any client that connects to it,
   it can only inspect the messages it receives on such a connection and
   make per query decisions about whether or not to answer those
   queries.

   Example policies a XoT server might implement are:

   o  strict: REFUSE all queries on TLS connections except SOA and R. Bush, "Serial Number Arithmetic", RFC 1982,
              DOI 10.17487/RFC1982, August 1996, <https://www.rfc-
              editor.org/info/rfc1982>.

   [RFC1996]  Vixie, P., "A Mechanism
      authorized XFR requests

   o  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

   o  complex: apply a heuristic to determine which queries on a TLS
      connections to REFUSE

   o  relaxed: answer all non-XoT queries on all TLS connections with
      the same policy applied to TCP queries

   Pros: Allows for Prompt Notification flexible behavior by the server that could be
   changed over time.

   Cons: The server must handle the burden of Zone
              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
              August 1996, <https://www.rfc-editor.org/info/rfc1996>.

   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
              Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
              <https://www.rfc-editor.org/info/rfc2535>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for accepting all TLS
   connections just to perform XFRs with a small number of secondaries.

   Client behavior to REFUSED response is not clearly defined (see
   below).  Currently, none of the major open source DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013, <https://www.rfc-
              editor.org/info/rfc6891>.

   [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., authoritative
   implementations offer an option for different response policies in
   different transports (but could potentially be implemented using a
   proxy).

A.4.1.  SNI based response policies

   In a similar fashion, XoT servers might use the presence of an SNI in
   the client hello to determine which response policy to initially
   apply to the TLS connections.

   Pros: This has to potential to allow a clean distinction between a
   XoT service and
              D. Wessels, "DNS Transport over TCP - Implementation
              Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
              <https://www.rfc-editor.org/info/rfc7766>.

16.3.  URIs

   [1] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/
       master/02-draft-dprive-svg/AXFR_mechanism.svg

   [2] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/
       master/02-draft-dprive-svg/IXFR_mechanism.svg

   [3] https://www.isc.org/bind/

   [4] https://www.nlnetlabs.nl/projects/nsd/about/

   [5] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/
       master/02-draft-dprive-svg/AXoT_mechanism.svg

   [6] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/
       master/02-draft-dprive-svg/IXoT_mechanism.svg

   [7] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/
       blob/02_updates/02-draft-svg/
       Properties_of_Authentication_methods_for_XoT.svg

   [8] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/
       Changelog any future DoT based service for answering recursive
   queries.

   Cons: As above.

Authors' Addresses

   Willem Toorop
   NLnet Labs
   Science Park 400
   Amsterdam  1098 XH
   The 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
   Salesforce
   Vancouver, BC
   Canada

   Email: ssahib@salesforce.com
   Pallavi Aras
   Salesforce
   Herndon, VA
   United States

   Email: paras@salesforce.com

   Allison Mankin
   Salesforce
   Herndon, VA
   United States

   Email: allison.mankin@gmail.com