idnits 2.17.1 draft-ietf-dprive-xfr-over-tls-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC1995, updated by this document, for RFC5378 checks: 1994-11-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 20, 2021) is 1092 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1632 -- Looks like a reference, but probably isn't: '2' on line 1636 -- Looks like a reference, but probably isn't: '3' on line 1639 -- Looks like a reference, but probably isn't: '4' on line 1641 -- Looks like a reference, but probably isn't: '5' on line 1643 == Outdated reference: A later version (-09) exists of draft-ietf-dprive-rfc7626-bis-08 ** Downref: Normative reference to an Informational draft: draft-ietf-dprive-rfc7626-bis (ref. 'I-D.ietf-dprive-rfc7626-bis') ** Downref: Normative reference to an Informational RFC: RFC 6973 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-01 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-09 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive W. Toorop 3 Internet-Draft NLnet Labs 4 Updates: 1995, 5936, 7766 (if approved) S. Dickinson 5 Intended status: Standards Track Sinodun IT 6 Expires: October 22, 2021 S. Sahib 7 P. Aras 8 A. Mankin 9 Salesforce 10 April 20, 2021 12 DNS Zone Transfer-over-TLS 13 draft-ietf-dprive-xfr-over-tls-11 15 Abstract 17 DNS zone transfers are transmitted in clear text, which gives 18 attackers the opportunity to collect the content of a zone by 19 eavesdropping on network connections. The DNS Transaction Signature 20 (TSIG) mechanism is specified to restrict direct zone transfer to 21 authorized clients only, but it does not add confidentiality. This 22 document specifies the use of TLS, rather than clear text, to prevent 23 zone content collection via passive monitoring of zone transfers: 24 XFR-over-TLS (XoT). Additionally, this specification updates 25 RFC1995, RFC5936 and RFC7766. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 22, 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Document work via GitHub . . . . . . . . . . . . . . . . . . 5 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Design Considerations for XoT . . . . . . . . . . . . . . . . 6 66 6. Connection and Data Flows in Existing XFR Mechanisms . . . . 7 67 6.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 8 68 6.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 9 69 6.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 11 70 6.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 7. Updates to existing specifications . . . . . . . . . . . . . 11 73 7.1. Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . . 13 74 7.2. Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . . 13 75 7.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . . 13 76 7.3.1. Connection reuse . . . . . . . . . . . . . . . . . . 13 77 7.3.2. AXFRs and IXFRs on the same connection . . . . . . . 14 78 7.3.3. XFR limits . . . . . . . . . . . . . . . . . . . . . 14 79 7.3.4. The edns-tcp-keepalive EDNS0 Option . . . . . . . . . 15 80 7.3.5. Backwards compatibility . . . . . . . . . . . . . . . 15 81 7.4. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 15 82 8. XoT specification . . . . . . . . . . . . . . . . . . . . . . 17 83 8.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 17 84 8.2. Port selection . . . . . . . . . . . . . . . . . . . . . 17 85 8.3. High level XoT descriptions . . . . . . . . . . . . . . . 17 86 8.4. XoT transfers . . . . . . . . . . . . . . . . . . . . . . 19 87 8.5. XoT connections . . . . . . . . . . . . . . . . . . . . . 20 88 8.6. XoT vs ADoT . . . . . . . . . . . . . . . . . . . . . . . 20 89 8.7. Response RCODES . . . . . . . . . . . . . . . . . . . . . 21 90 8.8. AXoT specifics . . . . . . . . . . . . . . . . . . . . . 21 91 8.8.1. Padding AXoT responses . . . . . . . . . . . . . . . 21 92 8.9. IXoT specifics . . . . . . . . . . . . . . . . . . . . . 22 93 8.9.1. Condensation of responses . . . . . . . . . . . . . . 22 94 8.9.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 22 95 8.9.3. Padding of IXoT responses . . . . . . . . . . . . . . 23 96 8.10. Name compression and maximum payload sizes . . . . . . . 23 98 9. Multi-primary Configurations . . . . . . . . . . . . . . . . 23 99 10. Authentication mechanisms . . . . . . . . . . . . . . . . . . 24 100 10.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 10.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 10.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 25 103 10.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . 25 104 10.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 26 105 10.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 26 106 10.4. IP Based ACL on the Primary . . . . . . . . . . . . . . 26 107 10.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 27 108 11. XoT authentication . . . . . . . . . . . . . . . . . . . . . 27 109 12. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 28 110 13. Implementation Considerations . . . . . . . . . . . . . . . . 29 111 14. Operational Considerations . . . . . . . . . . . . . . . . . 29 112 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 113 16. Implementation Status . . . . . . . . . . . . . . . . . . . . 29 114 17. Security Considerations . . . . . . . . . . . . . . . . . . . 30 115 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 116 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 117 20. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31 118 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 119 21.1. Normative References . . . . . . . . . . . . . . . . . . 33 120 21.2. Informative References . . . . . . . . . . . . . . . . . 35 121 21.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 122 Appendix A. XoT server connection handling . . . . . . . . . . . 37 123 A.1. Only listen on TLS on a specific IP address . . . . . . . 37 124 A.2. Client specific TLS acceptance . . . . . . . . . . . . . 37 125 A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 37 126 A.4. TLS specific response policies . . . . . . . . . . . . . 38 127 A.4.1. SNI based response policies . . . . . . . . . . . . . 39 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 130 1. Introduction 132 DNS has a number of privacy vulnerabilities, as discussed in detail 133 in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver 134 query privacy has received the most attention to date, with standards 135 track documents for both DNS-over-TLS (DoT) [RFC7858] and DNS-over- 136 HTTPS (DoH) [RFC8484], and a proposal for DNS-over-QUIC 137 [I-D.ietf-dprive-dnsoquic]. There is ongoing work on DNS privacy 138 requirements for exchanges between recursive resolvers and 139 authoritative servers [I-D.ietf-dprive-phase2-requirements] and some 140 suggestions for how signaling of DoT support by authoritatives might 141 work. However there is currently no RFC that specifically defines 142 recursive to authoritative DNS-over-TLS (ADoT). 144 [I-D.ietf-dprive-rfc7626-bis] established that stub client DNS query 145 transactions are not public and needed protection, but on zone 146 transfer [RFC1995] [RFC5936] it says only: 148 "Privacy risks for the holder of a zone (the risk that someone 149 gets the data) are discussed in [RFC5936] and [RFC5155]." 151 In what way is exposing the full contents of a zone a privacy risk? 152 The contents of the zone could include information such as names of 153 persons used in names of hosts. Best practice is not to use personal 154 information for domain names, but many such domain names exist. The 155 contents of the zone could also include references to locations that 156 allow inference about location information of the individuals 157 associated with the zone's organization. It could also include 158 references to other organizations. Examples of this could be: 160 o Person-laptop.example.org 162 o MX-for-Location.example.org 164 o Service-tenant-from-another-org.example.org 166 Additionally, the full zone contents expose all the IP addresses of 167 endpoints held in the DNS records which can make reconnaissance 168 trivial, particularly for IPv6 addresses. There may also be 169 regulatory, policy or other reasons why the zone contents in full 170 must be treated as private. 172 Neither of the RFCs mentioned in [I-D.ietf-dprive-rfc7626-bis] 173 contemplates the risk that someone gets the data through 174 eavesdropping on network connections, only via enumeration or 175 unauthorized transfer as described in the following paragraphs. 177 Zone enumeration is trivially possible for DNSSEC zones which use 178 NSEC; i.e. queries for the authenticated denial of existences 179 records allow a client to walk through the entire zone contents. 180 [RFC5155] specifies NSEC3, a mechanism to provide measures against 181 zone enumeration for DNSSEC signed zones (a goal was to make it as 182 hard to enumerate an DNSSEC signed zone as an unsigned zone). Whilst 183 this is widely used, zone walking is now possible with NSEC3 due to 184 crypto-breaking advances. This has prompted further work on an 185 alternative mechanism for DNSSEC authenticated denial of existence - 186 NSEC5 [I-D.vcelak-nsec5] - however questions remain over the 187 practicality of this mechanism. 189 [RFC5155] does not address data obtained outside zone enumeration 190 (nor does [I-D.vcelak-nsec5]). Preventing eavesdropping of zone 191 transfers (this draft) is orthogonal to preventing zone enumeration, 192 though they aim to protect the same information. 194 [RFC5936] specifies using TSIG [RFC8945] for authorization of the 195 clients of a zone transfer and for data integrity, but does not 196 express any need for confidentiality, and TSIG does not offer 197 encryption. 199 Section 8 of the NIST guide on 'Secure Domain Name System (DNS) 200 Deployment' [nist-guide] discusses restricting access for zone 201 transfers using ACLs and TSIG in more detail. It also discusses the 202 possibility that specific deployments might choose to use a lower 203 level network layer to protect zone transfers, e.g., IPSec. 205 It is noted that in all the common open source implementations such 206 ACLs are applied on a per query basis. Since requests typically 207 occur on TCP connections authoritatives must cater for accepting any 208 TCP connection and then handling the authentication of each XFR 209 request individually. 211 Because both AXFR and IXFR zone transfers are typically carried out 212 over TCP from authoritative DNS protocol implementations, encrypting 213 zone transfers using TLS, based closely on DoT [RFC7858], seems like 214 a simple step forward. This document specifies how to use TLS (1.3 215 or later) as a transport to prevent zone collection from zone 216 transfers. 218 2. Document work via GitHub 220 [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository 221 for this document is at . Proposed text and editorial changes are very much 223 welcomed there, but any functional changes should always first be 224 discussed on the IETF DPRIVE WG (dns-privacy) mailing list. 226 3. Terminology 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 230 "OPTIONAL" in this document are to be interpreted as described in BCP 231 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 232 capitals, as shown here. 234 Privacy terminology is as described in Section 3 of [RFC6973]. 236 DNS terminology is as described in [RFC8499]. Note that as in 237 [RFC8499], the terms 'primary' and 'secondary' are used for two 238 servers engaged in zone transfers. 240 DoT: DNS-over-TLS as specified in [RFC7858] 242 XFR-over-TCP: Used to mean both IXFR-over-TCP [RFC1995] and AXFR- 243 over-TCP [RFC5936]. 245 XoT: XFR-over-TLS mechanisms as specified in this document which 246 apply to both AXFR-over-TLS and IXFR-over-TLS 248 AXoT: AXFR-over-TLS 250 IXoT: IXFR over-TLS 252 4. Threat Model 254 The threat model considered here is one where the current contents 255 and size of the zone are considered sensitive and should be protected 256 during transfer. 258 The threat model does not, however, consider the existence of a zone, 259 the act of zone transfer between two entities, nor the identities of 260 the nameservers hosting a zone (including both those acting as hidden 261 primaries/secondaries or directly serving the zone) as sensitive 262 information. The proposed mechanisms does not attempt to obscure 263 such information. The reasons for this include: 265 o much of this information can be obtained by various methods 266 including active scanning of the DNS 268 o an attacker who can monitor network traffic can relatively easily 269 infer relations between nameservers simply from traffic patterns, 270 even when some or all of the traffic is encrypted 272 It is noted that simply using XoT will indicate a desire by the zone 273 owner that the contents of the zone remain confidential and so could 274 be subject to blocking (e.g., via blocking of port 853) if an 275 attacker had such capabilities. However this threat is likely true 276 of any such mechanism that attempts to encrypt data passed between 277 nameservers, e.g., IPsec. 279 5. Design Considerations for XoT 281 o Confidentiality. Clearly using an encrypted transport for zone 282 transfers will defeat zone content leakage that can occur via 283 passive surveillance. 285 o Authentication. Use of single or mutual TLS (mTLS) authentication 286 (in combination with ACLs) can complement and potentially be an 287 alternative to TSIG. 289 o Performance. 291 * Existing AXFR and IXFR mechanisms have the burden of backwards 292 compatibility with older implementations based on the original 293 specifications in [RFC1034] and [RFC1035]. For example, some 294 older AXFR servers don't support using a TCP connection for 295 multiple AXFR sessions or XFRs of different zones because they 296 have not been updated to follow the guidance in [RFC5936]. Any 297 implementation of XoT would obviously be required to implement 298 optimized and interoperable transfers as described in 299 [RFC5936], e.g., transfer of multiple zones over one 300 connection. 302 * Current usage of TCP for IXFR is sub-optimal in some cases i.e. 303 connections are frequently closed after a single IXFR. 305 6. Connection and Data Flows in Existing XFR Mechanisms 307 The original specification for zone transfers in [RFC1034] and 308 [RFC1035] was based on a polling mechanism: a secondary performed a 309 periodic SOA query (based on the refresh timer) to determine if an 310 AXFR was required. 312 [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY 313 respectively, to provide for prompt propagation of zone updates. 314 This has largely replaced AXFR where possible, particularly for 315 dynamically updated zones. 317 [RFC5936] subsequently redefined the specification of AXFR to improve 318 performance and interoperability. 320 In this document we use the term "XFR mechanism" to describe the 321 entire set of message exchanges between a secondary and a primary 322 that concludes in a successful AXFR or IXFR request/response. This 323 set may or may not include 325 o NOTIFY messages 327 o SOA queries 329 o Fallback from IXFR to AXFR 331 o Fallback from IXFR-over-UDP to IXFR-over-TCP 333 The term is used to encompasses the range of permutations that are 334 possible and is useful to distinguish the 'XFR mechanism' from a 335 single XFR request/response exchange. 337 6.1. AXFR Mechanism 339 The figure below provides an outline of an AXFR mechanism including 340 NOTIFYs. 342 Secondary Primary 344 | NOTIFY | 345 | <-------------------------------- | UDP 346 | --------------------------------> | 347 | NOTIFY Response | 348 | | 349 | | 350 | SOA Request | 351 | --------------------------------> | UDP (or part of 352 | <-------------------------------- | a TCP session) 353 | SOA Response | 354 | | 355 | | 356 | | 357 | AXFR Request | --- 358 | --------------------------------> | | 359 | <-------------------------------- | | 360 | AXFR Response 1 | | 361 | (Zone data) | | 362 | | | 363 | <-------------------------------- | | TCP 364 | AXFR Response 2 | | Session 365 | (Zone data) | | 366 | | | 367 | <-------------------------------- | | 368 | AXFR Response 3 | | 369 | (Zone data) | --- 370 | | 372 Figure 1. AXFR Mechanism 374 1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP) 375 from the primary to the secondary. A secondary may also initiate 376 an AXFR based on a refresh timer or scheduled/triggered zone 377 maintenance. 379 2. The secondary will normally (but not always) make a SOA query to 380 the primary to obtain the serial number of the zone held by the 381 primary. 383 3. If the primary serial is higher than the secondaries serial 384 (using Serial Number Arithmetic [RFC1982]), the secondary makes 385 an AXFR request (over TCP) to the primary after which the AXFR 386 data flows in one or more AXFR responses on the TCP connection. 387 [RFC5936] defines this specific step as an 'AXFR session' i.e. as 388 an AXFR query message and the sequence of AXFR response messages 389 returned for it. 391 [RFC5936] re-specified AXFR providing additional guidance beyond that 392 provided in [RFC1034] and [RFC1035] and importantly specified that 393 AXFR must use TCP as the transport protocol. 395 Additionally, sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] provide 396 improved guidance for AXFR clients and servers with regard to re-use 397 of TCP connections for multiple AXFRs and AXFRs of different zones. 398 However [RFC5936] was constrained by having to be backwards 399 compatible with some very early basic implementations of AXFR. For 400 example, it outlines that the SOA query can also happen on this 401 connection. However, this can cause interoperability problems with 402 older implementations that support only the trivial case of one AXFR 403 per connection. 405 6.2. IXFR Mechanism 407 The figure below provides an outline of the IXFR mechanism including 408 NOTIFYs. 410 Secondary Primary 412 | NOTIFY | 413 | <-------------------------------- | UDP 414 | --------------------------------> | 415 | NOTIFY Response | 416 | | 417 | | 418 | SOA Request | 419 | --------------------------------> | UDP or TCP 420 | <-------------------------------- | 421 | SOA Response | 422 | | 423 | | 424 | | 425 | IXFR Request | 426 | --------------------------------> | UDP or TCP 427 | <-------------------------------- | 428 | IXFR Response | 429 | (Zone data) | 430 | | 431 | | --- 432 | IXFR Request | | 433 | --------------------------------> | | Retry over 434 | <-------------------------------- | | TCP if 435 | IXFR Response | | required 436 | (Zone data) | --- 438 Figure 2. IXFR Mechanism 440 1. An IXFR is normally (but not always) preceded by a NOTIFY (over 441 UDP) from the primary to the secondary. A secondary may also 442 initiate an IXFR based on a refresh timer or scheduled/triggered 443 zone maintenance. 445 2. The secondary will normally (but not always) make a SOA query to 446 the primary to obtain the serial number of the zone held by the 447 primary. 449 3. If the primary serial is higher than the secondaries serial 450 (using Serial Number Arithmetic [RFC1982]), the secondary makes 451 an IXFR request to the primary after which the primary sends an 452 IXFR response. 454 [RFC1995] specifies that Incremental Transfer may use UDP if the 455 entire IXFR response can be contained in a single DNS packet, 456 otherwise, TCP is used. In fact it says: 458 "Thus, a client should first make an IXFR query using UDP." 460 So there may be a fourth step above where the client falls back to 461 IXFR-over-TCP. There may also be a fourth step where the secondary 462 must fall back to AXFR because, e.g., the primary does not support 463 IXFR. 465 However it is noted that most widely used open source authoritative 466 nameserver implementations (including both [BIND] and [NSD]) do IXFR 467 using TCP by default in their latest releases. For BIND TCP 468 connections are sometimes used for SOA queries but in general they 469 are not used persistently and close after an IXFR is completed. 471 6.3. Data Leakage of NOTIFY and SOA Message Exchanges 473 This section attempts to presents a rationale for considering 474 encrypting the other messages in the XFR mechanism. 476 Since the SOA of the published zone can be trivially discovered by 477 simply querying the publicly available authoritative servers leakage 478 of this RR is not discussed in the following sections. 480 6.3.1. NOTIFY 482 Unencrypted NOTIFY messages identify configured secondaries on the 483 primary. 485 [RFC1996] also states: 487 "If ANCOUNT>0, then the answer section represents an 488 unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE). 490 But since the only supported QTYPE for NOTIFY is SOA, this does not 491 pose a potential leak. 493 6.3.2. SOA 495 For hidden primaries or secondaries the SOA response leaks only the 496 degree of SOA serial number lag of any downstream secondary. 498 7. Updates to existing specifications 500 For convenience, the term 'XFR-over-TCP' is used in this document to 501 mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements 502 that use that term update both [RFC1995] and [RFC5936], and 503 implicitly also apply to XoT. Differences in behavior specific to 504 XoT are discussed in Section 8. 506 Both [RFC1995] and [RFC5936] were published sometime before TCP was 507 considered a first class transport for DNS. [RFC1995], in fact, says 508 nothing with respect to optimizing IXFRs over TCP or re-using already 509 open TCP connections to perform IXFRs or other queries. Therefore, 510 there arguably is an implicit assumption that a TCP connection is 511 used for one and only one IXFR request. Indeed, many major open 512 source implementations currently take this approach. And whilst 513 [RFC5936] gives guidance on connection re-use for AXFR, it pre-dates 514 more recent specifications describing persistent TCP connections, 515 e.g., [RFC7766], [RFC7828] and AXFR implementations again often make 516 less than optimal use of open connections. 518 Given this, new implementations of XoT will clearly benefit from 519 specific guidance on TCP/TLS connection usage for XFR because this 520 will: 522 o result in more consistent XoT implementations with better 523 interoperability 525 o remove any need for XoT implementations to support legacy behavior 526 that XFR-over-TCP implementations have historically often 527 supported 529 Therefore this document updates both the previous specifications for 530 XFR-over-TCP to clarify that 532 o Implementations MUST use [RFC7766] (DNS Transport over TCP - 533 Implementation Requirements) to optimize the use of TCP 534 connections. 536 o Whilst RFC7766 states that 'DNS clients SHOULD pipeline their 537 queries' on TCP connections, it did not distinguish between XFRs 538 and other queries for this behavior. It is now recognized that 539 XFRs are not as latency sensitive as other queries, and can be 540 significantly more complex for clients to handle both because of 541 the large amount of state that must be kept and because there may 542 be multiple messages in the responses. For these reasons it is 543 clarified here that a valid reason for not pipelining queries is 544 when they are all XFR queries i.e. clients sending multiple XFRs 545 MAY choose not to pipeline those queries. Clients that do not 546 pipeline XFR queries, therefore, have no additional requirements 547 to handle out-of-order or intermingled responses (as described 548 later) since they will never receive them. 550 o Implementations SHOULD use [RFC7828] (The edns-tcp-keepalive EDNS0 551 Option) to manage persistent connections. 553 The following sections include detailed clarifications on the updates 554 to XFR behavior implied in [RFC7766] and how the use of [RFC7828] 555 applies specifically to XFR exchanges. It also discusses how IXFR 556 and AXFR can reuse the same TCP connection. 558 For completeness, we also mention here the recent specification of 559 extended DNS error (EDE) codes [RFC8914]. For zone transfers, when 560 returning REFUSED to a zone transfer request from an 'unauthorized' 561 client (e.g., where the client is not listed in an ACL for zone 562 transfers or does not sign the request with the correct TSIG key), 563 the extended DNS error code 18 (Prohibited) can also be sent. 565 7.1. Update to RFC1995 for IXFR-over-TCP 567 For clarity - an IXFR-over-TCP server compliant with this 568 specification MUST be able to handle multiple concurrent IXoT 569 requests on a single TCP connection (for the same and different 570 zones) and SHOULD send the responses as soon as they are available, 571 which might be out-of-order compared to the requests. 573 7.2. Update to RFC5936 for AXFR-over-TCP 575 For clarity - an AXFR-over-TCP server compliant with this 576 specification MUST be able to handle multiple concurrent AXoT 577 sessions on a single TCP connection (for the same and different 578 zones). The response streams for concurrent AXFRs MAY be 579 intermingled and AXFR-over-TCP clients compliant with this 580 specification which pipeline AXFR requests MUST be able to handle 581 this. 583 7.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP 585 7.3.1. Connection reuse 587 As specified, XFR-over-TCP clients SHOULD re-use any existing open 588 TCP connection when starting any new XFR request to the same primary, 589 and for issuing SOA queries, instead of opening a new connection. 590 The number of TCP connections between a secondary and primary SHOULD 591 be minimized (also see Section 7.4). 593 Valid reasons for not re-using existing connections might include: 595 o as already noted in [RFC7766], separate connections for different 596 zones might be preferred for operational reasons. In this case 597 the number of concurrent connections for zone transfers SHOULD be 598 limited to the total number of zones transferred between the 599 client and server. 601 o reaching a configured limit for the number of outstanding queries 602 or XFR requests allowed on a single TCP connection 604 o the message ID pool has already been exhausted on an open 605 connection 607 o a large number of timeouts or slow responses have occurred on an 608 open connection 610 o an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been 611 received from the server and the client is in the process of 612 closing the connection (see Section 7.3.4) 614 If no TCP connections are currently open, XFR clients MAY send SOA 615 queries over UDP or a new TCP connection. 617 7.3.2. AXFRs and IXFRs on the same connection 619 Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a 620 single TCP connection for both IXFR and AXFR requests. [RFC5936] 621 does make the general statement: 623 "Non-AXFR session traffic can also use an open TCP connection." 625 We clarify here that implementations capable of both AXFR and IXFR 626 and compliant with this specification SHOULD 628 o use the same TCP connection for both AXFR and IXFR requests to the 629 same primary 631 o pipeline such requests (if they pipeline XFR requests in general) 632 and MAY intermingle them 634 o send the response(s) for each request as soon as they are 635 available i.e. responses MAY be sent intermingled 637 7.3.3. XFR limits 639 The server MAY limit the number of concurrent IXFRs, AXFRs or total 640 XFR transfers in progress, or from a given secondary, to protect 641 server resources. Servers SHOULD return SERVFAIL if this limit is 642 hit, since it is a transient error and a retry at a later time might 643 succeed. 645 7.3.4. The edns-tcp-keepalive EDNS0 Option 647 XFR clients that send the edns-tcp-keepalive EDNS0 option on every 648 XFR request provide the server with maximum opportunity to update the 649 edns-tcp-keepalive timeout. The XFR server may use the frequency of 650 recent XFRs to calculate an average update rate as input to the 651 decision of what edns-tcp-keepalive timeout to use. If the server 652 does not support edns-tcp-keepalive the client MAY keep the 653 connection open for a few seconds ([RFC7766] recommends that servers 654 use timeouts of at least a few seconds). 656 Whilst the specification for EDNS0 [RFC6891] does not specifically 657 mention AXFRs, it does say 659 "If an OPT record is present in a received request, compliant 660 responders MUST include an OPT record in their respective 661 responses." 663 We clarify here that if an OPT record is present in a received AXFR 664 request, compliant responders MUST include an OPT record in each of 665 the subsequent AXFR responses. Note that this requirement, combined 666 with the use of edns-tcp-keepalive, enables AXFR servers to signal 667 the desire to close a connection (when existing transactions have 668 competed) due to low resources by sending an edns-tcp-keepalive EDNS0 669 option with a timeout of 0 on any AXFR response. This does not 670 signal that the AXFR is aborted, just that the server wishes to close 671 the connection as soon as possible. 673 7.3.5. Backwards compatibility 675 Certain legacy behaviors were noted in [RFC5936], with provisions 676 that implementations may want to offer options to fallback to legacy 677 behavior when interoperating with servers known not to support 678 [RFC5936]. For purposes of interoperability, IXFR and AXFR 679 implementations may want to continue offering such configuration 680 options, as well as supporting some behaviors that were 681 underspecified prior to this work (e.g., performing IXFR and AXFRs on 682 separate connections). However, XoT implementations should have no 683 need to do so. 685 7.4. Update to RFC7766 687 [RFC7766] made general implementation recommendations with regard to 688 TCP/TLS connection handling: 690 "To mitigate the risk of unintentional server overload, DNS 691 clients MUST take care to minimize the number of concurrent TCP 692 connections made to any individual server. It is RECOMMENDED 693 that for any given client/server interaction there SHOULD be no 694 more than one connection for regular queries, one for zone 695 transfers, and one for each protocol that is being used on top 696 of TCP (for example, if the resolver was using TLS). However, 697 it is noted that certain primary/ secondary configurations with 698 many busy zones might need to use more than one TCP connection 699 for zone transfers for operational reasons (for example, to 700 support concurrent transfers of multiple zones)." 702 Whilst this recommends a particular behavior for the clients using 703 TCP, it does not relax the requirement for servers to handle 'mixed' 704 traffic (regular queries and zone transfers) on any open TCP/TLS 705 connection. It also overlooks the potential that other transports 706 might want to take the same approach with regard to using separate 707 connections for different purposes. 709 This specification for XoT updates the guidance in [RFC7766] to 710 provide the same separation of connection purpose (regular queries 711 and zone transfers) for all transports being used on top of TCP. 713 Therefore, it is RECOMMENDED that for each protocol used on top of 714 TCP in any given client/server interaction there SHOULD be no more 715 than one connection for regular queries and one for zone transfers. 717 As an illustration, it could be imagined that in future such an 718 interaction could hypothetically include one or all of the following: 720 o one TCP connection for regular queries 722 o one TCP connection for zone transfers 724 o one TLS connection for regular queries 726 o one TLS connection for zone transfers 728 o one DoH connection for regular queries 730 o one DoH connection for zone transfers 732 Section 7.3.1 has provided specific details of reasons where more 733 than one connection for a given transport might be required for zone 734 transfers from a particular client. 736 8. XoT specification 738 8.1. TLS versions 740 For improved security all implementations of this specification MUST 741 use only TLS 1.3 [RFC8446] or later. 743 8.2. Port selection 745 The connection for XoT SHOULD be established using port 853, as 746 specified in [RFC7858], unless there is mutual agreement between the 747 secondary and primary to use a port other than port 853 for XoT. 748 There MAY be agreement to use different ports for AXoT and IXoT, or 749 for different zones. 751 8.3. High level XoT descriptions 753 It is useful to note that in XoT it is the secondary that initiates 754 the TLS connection to the primary for a XFR request, so that in terms 755 of connectivity the secondary is the TLS client and the primary the 756 TLS server. 758 The figure below provides an outline of the AXoT mechanism including 759 NOTIFYs. 761 Secondary Primary 763 | NOTIFY | 764 | <-------------------------------- | UDP 765 | --------------------------------> | 766 | NOTIFY Response | 767 | | 768 | | 769 | SOA Request | 770 | --------------------------------> | UDP (or part of 771 | <-------------------------------- | a TCP/TLS session) 772 | SOA Response | 773 | | 774 | | 775 | | 776 | AXFR Request | --- 777 | --------------------------------> | | 778 | <-------------------------------- | | 779 | AXFR Response 1 | | 780 | (Zone data) | | 781 | | | 782 | <-------------------------------- | | TLS 783 | AXFR Response 2 | | Session 784 | (Zone data) | | 785 | | | 786 | <-------------------------------- | | 787 | AXFR Response 3 | | 788 | (Zone data) | --- 789 | | 791 Figure 3. AXoT Mechanism 793 The figure below provides an outline of the IXoT mechanism including 794 NOTIFYs. 796 Secondary Primary 798 | NOTIFY | 799 | <-------------------------------- | UDP 800 | --------------------------------> | 801 | NOTIFY Response | 802 | | 803 | | 804 | SOA Request | 805 | --------------------------------> | UDP (or part of 806 | <-------------------------------- | a TCP/TLS session) 807 | SOA Response | 808 | | 809 | | 810 | | 811 | IXFR Request | --- 812 | --------------------------------> | | 813 | <-------------------------------- | | 814 | IXFR Response | | 815 | (Zone data) | | 816 | | | TLS 817 | | | session 818 | IXFR Request | | 819 | --------------------------------> | | 820 | <-------------------------------- | | 821 | IXFR Response | | 822 | (Zone data) | --- 824 Figure 4. IXoT Mechanism 826 8.4. XoT transfers 828 For a zone transfer between two end points to be considered protected 829 with XoT all XFR requests and response for that zone MUST be sent 830 over TLS connections where at a minimum: 832 o the client MUST authenticate the server by use of an 833 authentication domain name using a Strict Privacy Profile as 834 described in [RFC8310] 836 o the server MUST validate the client is authorized to request or 837 proxy a zone transfer by using one or both of the following: 839 * an IP based ACL (which can be either per-message or per- 840 connection) 842 * Mutual TLS (mTLS) 844 The server MAY also require a valid TSIG/SIG(0) signature, but this 845 alone is not sufficient to authenticate the client or server. 847 Authentication mechanisms are discussed in full in Section 10 and the 848 rationale for the above requirement in Section 11. Transfer group 849 policies are discussed in Section 12. 851 8.5. XoT connections 853 The details in Section 7 about, e.g., persistent connections and XFR 854 message handling are fully applicable to XoT connections as well. 855 However any behavior specified here takes precedence for XoT. 857 If no TLS connections are currently open, XoT clients MAY send SOA 858 queries over UDP or TCP, or TLS. 860 8.6. XoT vs ADoT 862 As noted earlier, there is currently no specification for encryption 863 of connections from recursive resolvers to authoritative servers. 864 Some authoritatives are experimenting with ADoT and opportunistic 865 encryption has also been raised as a possibility; it is therefore 866 highly likely that use of encryption by authoritative servers will 867 evolve in the coming years. 869 This raises questions in the short term with regard to TLS connection 870 and message handling for authoritative servers. In particular, there 871 is likely to be a class of authoritatives that wish to use XoT in the 872 near future with a small number of configured secondaries but that do 873 wish to support DoT for regular queries from recursive in that same 874 time frame. These servers have to potentially cope with probing and 875 direct queries from recursives and from test servers, and also 876 potential attacks that might wish to make use of TLS to overload the 877 server. 879 [RFC5936] clearly states that non-AXFR session traffic can use an 880 open TCP connection, however, this requirement needs to be re- 881 evaluated when considering applying the same model to XoT. Proposing 882 that a server should also start responding to all queries received 883 over TLS just because it has enabled XoT would be equivalent to 884 defining a form of authoritative DoT. This specification does not 885 propose that, but it also does not prohibit servers from answering 886 queries unrelated to XFR exchanges over TLS. Rather, this 887 specification simply outlines in later sections: 889 o how XoT implementations should utilize EDE codes in response to 890 queries on TLS connections they are not willing to answer (see 891 Section 8.7) 893 o the operational and policy options that a XoT server operator has 894 with regard to managing TLS connections and messages (see 895 Appendix A) 897 8.7. Response RCODES 899 XoT clients and servers MUST implement EDE codes. If a XoT server 900 receives non-XoT traffic it is not willing to answer on a TLS 901 connection it SHOULD respond with the extended DNS error code 21 - 902 Not Supported [RFC8914]. XoT clients should not send any further 903 queries of this type to the server for a reasonable period of time 904 (for example, one hour) i.e., long enough that the server 905 configuration or policy might be updated. 907 Historically servers have used the REFUSED RCODE for many situations, 908 and so clients often had no detailed information on which to base an 909 error or fallback path when queries were refused. As a result the 910 client behavior could vary significantly. XoT servers that refuse 911 queries must cater for the fact that client behavior might vary from 912 continually retrying queries regardless of receiving REFUSED to every 913 query, or at the other extreme clients may decide to stop using the 914 server over any transport. This might be because those clients are 915 either non-XoT clients or do not implement EDE codes. 917 8.8. AXoT specifics 919 8.8.1. Padding AXoT responses 921 The goal of padding AXoT responses would be two fold: 923 o to obfuscate the actual size of the transferred zone to minimize 924 information leakage about the entire contents of the zone. 926 o to obfuscate the incremental changes to the zone between SOA 927 updates to minimize information leakage about zone update activity 928 and growth. 930 Note that the re-use of XoT connections for transfers of multiple 931 different zones complicates any attempt to analyze the traffic size 932 and timing to extract information. 934 It is noted here that, depending on the padding policies eventually 935 developed for XoT, the requirement to obfuscate the total zone size 936 might require a server to create 'empty' AXoT responses. That is, 937 AXoT responses that contain no RR's apart from an OPT RR containing 938 the EDNS(0) option for padding. For example, without this capability 939 the maximum size that a tiny zone could be padded to would 940 theoretically be limited if there had to be a minimum of 1 RR per 941 packet. 943 However, as with existing AXFR, the last AXoT response message sent 944 MUST contain the same SOA that was in the first message of the AXoT 945 response series in order to signal the conclusion of the zone 946 transfer. 948 [RFC5936] says: 950 "Each AXFR response message SHOULD contain a sufficient number 951 of RRs to reasonably amortize the per-message overhead, up to 952 the largest number that will fit within a DNS message (taking 953 the required content of the other sections into account, as 954 described below)." 956 'Empty' AXoT responses generated in order to meet a padding 957 requirement will be exceptions to the above statement. For 958 flexibility, future proofing and in order to guarantee support for 959 future padding policies, we state here that secondary implementations 960 MUST be resilient to receiving padded AXoT responses, including 961 'empty' AXoT responses that contain only an OPT RR containing the 962 EDNS(0) option for padding. 964 Recommendation of specific policies for padding AXoT responses are 965 out of scope for this specification. Detailed considerations of such 966 policies and the trade-offs involved are expected to be the subject 967 of future work. 969 8.9. IXoT specifics 971 8.9.1. Condensation of responses 973 [RFC1995] says condensation of responses is optional and MAY be done. 974 Whilst it does add complexity to generating responses it can 975 significantly reduce the size of responses. However any such 976 reduction might be offset by increased message size due to padding. 977 This specification does not update the optionality of condensation 978 for XoT responses. 980 8.9.2. Fallback to AXFR 982 Fallback to AXFR can happen, for example, if the server is not able 983 to provide an IXFR for the requested SOA. Implementations differ in 984 how long they store zone deltas and how many may be stored at any one 985 time. 987 Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD 988 request the AXFR on the already open XoT connection. 990 8.9.3. Padding of IXoT responses 992 The goal of padding IXoT responses would be to obfuscate the 993 incremental changes to the zone between SOA updates to minimize 994 information leakage about zone update activity and growth. Both the 995 size and timing of the IXoT responses could reveal information. 997 IXFR responses can vary in size greatly from the order of 100 bytes 998 for one or two record updates, to tens of thousands of bytes for 999 large dynamic DNSSEC signed zones. The frequency of IXFR responses 1000 can also depend greatly on if and how the zone is DNSSEC signed. 1002 In order to guarantee support for future padding policies, we state 1003 here that secondary implementations MUST be resilient to receiving 1004 padded IXoT responses. 1006 Recommendation of specific policies for padding IXoT responses are 1007 out of scope for this specification. Detailed considerations of such 1008 policies and the trade-offs involved are expected to be the subject 1009 of future work. 1011 8.10. Name compression and maximum payload sizes 1013 It is noted here that name compression [RFC1035] can be used in XFR 1014 responses to reduce the size of the payload, however the maximum 1015 value of the offset that can be used in the name compression pointer 1016 structure is 16384. For some DNS implementations this limits the 1017 size of an individual XFR response used in practice to something 1018 around the order of 16kB. In principle, larger payload sizes can be 1019 supported for some responses with more sophisticated approaches 1020 (e.g., by pre-calculating the maximum offset required). 1022 Implementations may wish to offer options to disable name compression 1023 for XoT responses to enable larger payloads. This might be 1024 particularly helpful when padding is used since minimizing the 1025 payload size is not necessarily a useful optimization in this case 1026 and disabling name compression will reduce the resources required to 1027 construct the payload. 1029 9. Multi-primary Configurations 1031 This model can provide flexibility and redundancy particularly for 1032 IXFR. A secondary will receive one or more NOTIFY messages and can 1033 send an SOA to all of the configured primaries. It can then choose 1034 to send an XFR request to the primary with the highest SOA (or other 1035 criteria, e.g., RTT). 1037 When using persistent connections the secondary may have a XoT 1038 connection already open to one or more primaries. Should a secondary 1039 preferentially request an XFR from a primary to which it already has 1040 an open XoT connection or the one with the highest SOA (assuming it 1041 doesn't have a connection open to it already)? 1043 Two extremes can be envisaged here. The first one can be considered 1044 a 'preferred primary connection' model. In this case the secondary 1045 continues to use one persistent connection to a single primary until 1046 it has reason not to. Reasons not to might include the primary 1047 repeatedly closing the connection, long query/response RTTs on 1048 transfers or the SOA of the primary being an unacceptable lag behind 1049 the SOA of an alternative primary. 1051 The other extreme can be considered a 'parallel primary connection' 1052 model. Here a secondary could keep multiple persistent connections 1053 open to all available primaries and only request XFRs from the 1054 primary with the highest serial number. Since normally the number of 1055 secondaries and primaries in direct contact in a transfer group is 1056 reasonably low this might be feasible if latency is the most 1057 significant concern. 1059 Recommendation of a particular scheme is out of scope of this 1060 document but implementations are encouraged to provide configuration 1061 options that allow operators to make choices about this behavior. 1063 10. Authentication mechanisms 1065 To provide context to the requirements in section Section 8.4, this 1066 section provides a brief summary of some of the existing 1067 authentication and validation mechanisms (both transport independent 1068 and TLS specific) that are available when performing zone transfers. 1069 Section 11 then discusses in more details specifically how a 1070 combination of TLS authentication, TSIG and IP based ACLs interact 1071 for XoT. 1073 We classify the mechanisms based on the following properties: 1075 o 'Data Origin Authentication' (DO): Authentication that the DNS 1076 message originated from the party with whom credentials were 1077 shared, and of the data integrity of the message contents (the 1078 originating party may or may not be party operating the far end of 1079 a TCP/TLS connection in a 'proxy' scenario). 1081 o 'Channel Confidentiality' (CC): Confidentiality of the 1082 communication channel between the client and server (i.e. the two 1083 end points of a TCP/TLS connection) from passive surveillance. 1085 o 'Channel Authentication' (CA): Authentication of the identity of 1086 party to whom a TCP/TLS connection is made (this might not be a 1087 direct connection between the primary and secondary in a proxy 1088 scenario). 1090 10.1. TSIG 1092 TSIG [RFC8945] provides a mechanism for two or more parties to use 1093 shared secret keys which can then be used to create a message digest 1094 to protect individual DNS messages. This allows each party to 1095 authenticate that a request or response (and the data in it) came 1096 from the other party, even if it was transmitted over an unsecured 1097 channel or via a proxy. 1099 Properties: Data origin authentication 1101 10.2. SIG(0) 1103 SIG(0) [RFC2931] similarly also provides a mechanism to digitally 1104 sign a DNS message but uses public key authentication, where the 1105 public keys are stored in DNS as KEY RRs and a private key is stored 1106 at the signer. 1108 Properties: Data origin authentication 1110 10.3. TLS 1112 10.3.1. Opportunistic TLS 1114 Opportunistic TLS for DoT is defined in [RFC8310] and can provide a 1115 defense against passive surveillance, providing on-the-wire 1116 confidentiality. Essentially 1118 o clients that know authentication information for a server SHOULD 1119 try to authenticate the server 1121 o however they MAY fallback to using TLS without authentication and 1123 o they MAY fallback to using cleartext if TLS is not available. 1125 As such it does not offer a defense against active attacks (e.g., an 1126 on path active attacker on the connection from client to server), and 1127 is not considered as useful for XoT. 1129 Properties: None guaranteed. 1131 10.3.2. Strict TLS 1133 Strict TLS for DoT [RFC8310] requires that a client is configured 1134 with an authentication domain name (and/or SPKI pinset) that MUST be 1135 used to authenticate the TLS handshake with the server. If 1136 authentication of the server fails, the client will not proceed with 1137 the connection. This provides a defense for the client against 1138 active surveillance, providing client-to-server authentication and 1139 end-to-end channel confidentiality. 1141 Properties: Channel confidentiality and authentication (of the 1142 server). 1144 10.3.3. Mutual TLS 1146 This is an extension to Strict TLS [RFC8310] which requires that a 1147 client is configured with an authentication domain name (and/or SPKI 1148 pinset) and a client certificate. The client offers the certificate 1149 for authentication by the server and the client can authenticate the 1150 server the same way as in Strict TLS. This provides a defense for 1151 both parties against active surveillance, providing bi-directional 1152 authentication and end-to-end channel confidentiality. 1154 Properties: Channel confidentiality and mutual authentication. 1156 10.4. IP Based ACL on the Primary 1158 Most DNS server implementations offer an option to configure an IP 1159 based Access Control List (ACL), which is often used in combination 1160 with TSIG based ACLs to restrict access to zone transfers on primary 1161 servers on a per query basis. 1163 This is also possible with XoT but it must be noted that, as with 1164 TCP, the implementation of such an ACL cannot be enforced on the 1165 primary until an XFR request is received on an established 1166 connection. 1168 As discussed in Appendix A an IP based per connection ACL could also 1169 be implemented where only TLS connections from recognized secondaries 1170 are accepted. 1172 Properties: Channel authentication of the client. 1174 10.5. ZONEMD 1176 For completeness, we also describe Message Digest for DNS Zones 1177 (ZONEMD) [RFC8976] here. The message digest is a mechanism that can 1178 be used to verify the content of a standalone zone. It is designed 1179 to be independent of the transmission channel or mechanism, allowing 1180 a general consumer of a zone to do origin authentication of the 1181 entire zone contents. Note that the current version of [RFC8976] 1182 states: 1184 "As specified herein, ZONEMD is impractical for large, dynamic zones 1185 due to the time and resources required for digest calculation. 1186 However, The ZONEMD record is extensible so that new digest schemes 1187 may be added in the future to support large, dynamic zones." 1189 It is complementary but orthogonal the above mechanisms; and can be 1190 used in conjunction with XoT but is not considered further here. 1192 11. XoT authentication 1194 It is noted that zone transfer scenarios can vary from a simple 1195 single primary/secondary relationship where both servers are under 1196 the control of a single operator to a complex hierarchical structure 1197 which includes proxies and multiple operators. Each deployment 1198 scenario will require specific analysis to determine which 1199 combination of authentication methods are best suited to the 1200 deployment model in question. 1202 The XoT authentication requirement specified in Section 8.4 addresses 1203 the issue of ensuring that the transfers is encrypted between the two 1204 endpoints directly involved in the current transfers. The following 1205 table summarized the properties of a selection of the mechanisms 1206 discussed in Section 10. The two letter acronyms for the properties 1207 are used below and (S) indicates the secondary and (P) indicates the 1208 primary. 1210 +----------------+-------+-------+-------+-------+-------+-------+ 1211 | Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) | 1212 +----------------+-------+-------+-------+-------+-------+-------+ 1213 | Strict TLS | | Y | Y | | Y | | 1214 | Mutual TLS | | Y | Y | | Y | Y | 1215 | ACL on primary | | | | | | Y | 1216 | TSIG | Y | | | Y | | | 1217 +----------------+-------+-------+-------+-------+-------+-------+ 1219 Table 1: Properties of Authentication methods for XoT 1221 Based on this analysis it can be seen that: 1223 o Using just mutual TLS can be considered a standalone solution 1224 since both end points are authenticated 1226 o Using Strict TLS and an IP based ACL on the primary also provides 1227 authentication of both end points 1229 o Additional use of TSIG (or equally SIG(0)) can also provide data 1230 origin authentication which might be desirable for deployments 1231 that include a proxy between the secondary and primary, but is not 1232 part of the XoT requirement because it does nothing to guarantee 1233 channel confidentiality or authentication. 1235 12. Policies for Both AXoT and IXoT 1237 Whilst the protection of the zone contents in a transfer between two 1238 end points can be provided by the XoT protocol, the protection of all 1239 the transfers of a given zone requires operational administration and 1240 policy management. 1242 We call the entire group of servers involved in XFR for a particular 1243 set of zones (all the primaries and all the secondaries) the 1244 'transfer group'. 1246 Within any transfer group both AXFRs and IXFRs for a zone MUST all 1247 use the same policy, e.g., if AXFRs use AXoT then all IXFRs MUST use 1248 IXoT. 1250 In order to assure the confidentiality of the zone information, the 1251 entire transfer group MUST have a consistent policy of requiring 1252 confidentiality. If any do not, this is a weak link for attackers to 1253 exploit. 1255 An individual zone transfer is not considered protected by XoT unless 1256 both the client and server are configured to use only XoT and the 1257 overall zone transfer is not considered protected until all members 1258 of the transfer group are configured to use only XoT with all other 1259 transfers servers (see Section 13). 1261 A XoT policy should specify 1263 o What kind of TLS is required (Strict or Mutual TLS) 1265 o or if an IP based ACL is required. 1267 o (optionally) if TSIG/SIG(0) is required 1268 Since this may require configuration of a number of servers who may 1269 be under the control of different operators the desired consistency 1270 could be hard to enforce and audit in practice. 1272 Certain aspects of the Policies can be relatively easily tested 1273 independently, e.g., by requesting zone transfers without TSIG, from 1274 unauthorized IP addresses or over cleartext DNS. Other aspects such 1275 as if a secondary will accept data without a TSIG digest or if 1276 secondaries are using Strict as opposed to Opportunistic TLS are more 1277 challenging. 1279 The mechanics of co-ordinating or enforcing such policies are out of 1280 the scope of this document but may be the subject of future 1281 operational guidance. 1283 13. Implementation Considerations 1285 Server implementations may want to also offer options that allow ACLs 1286 on a zone to specify that a specific client can use either XoT or 1287 TCP. This would allow for flexibility while clients are migrating to 1288 XoT. 1290 Client implementations may similarly want to offer options to cater 1291 for the multi-primary case where the primaries are migrating to XoT. 1293 14. Operational Considerations 1295 If the options described in Section 13 are available, such 1296 configuration options MUST only be used in a 'migration mode', and 1297 therefore should be used with great care. 1299 It is noted that use of a TLS proxy in front of the primary server is 1300 a simple deployment solution that can enable server side XoT. 1302 15. IANA Considerations 1304 None. 1306 16. Implementation Status 1308 [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] This section records 1309 the status of known implementations of the protocol defined by this 1310 specification at the time of posting of this Internet-Draft, and is 1311 based on a proposal described in [RFC7942]. 1313 A summary of current behavior and implementation status can be found 1314 here: XoT implementation status [1] 1315 Specific recent activity includes: 1317 1. The 1.9.2 version of Unbound [2] includes an option to perform 1318 AXoT (instead of AXFR-over-TCP). 1320 2. There are currently open pull requests against NSD to implement 1322 1. Connection re-use by default during XFR-over-TCP [3] 1324 2. Client side XoT [4] 1326 3. Version 9.17.7 of BIND contained an initial implementation of 1327 DoT, implementation of XoT is planned for early 2021 [5] 1329 Both items 1. and 2.2. listed above require the client (secondary) to 1330 authenticate the server (primary) using a configured authentication 1331 domain name if XoT is used. 1333 17. Security Considerations 1335 This document specifies a security measure against a DNS risk: the 1336 risk that an attacker collects entire DNS zones through eavesdropping 1337 on clear text DNS zone transfers. 1339 This does not mitigate: 1341 o the risk that some level of zone activity might be inferred by 1342 observing zone transfer sizes and timing on encrypted connections 1343 (even with padding applied), in combination with obtaining SOA 1344 records by directly querying authoritative servers. 1346 o the risk that hidden primaries might be inferred or identified via 1347 observation of encrypted connections. 1349 o the risk of zone contents being obtained via zone enumeration 1350 techniques. 1352 Security concerns of DoT are outlined in [RFC7858] and [RFC8310]. 1354 18. Acknowledgements 1356 The authors thank Tony Finch, Benno Overeinder, Shumon Huque and Tim 1357 Wicinski and many other members of DPRIVE for review and discussions. 1359 The authors particularly thank Peter van Dijk, Ondrej Sury, Brian 1360 Dickson and several other open source DNS implementers for valuable 1361 discussion and clarification on the issue associated with pipelining 1362 XFR queries and handling out-of-order/intermingled responses. 1364 19. Contributors 1366 Significant contributions to the document were made by: 1368 Han Zhang 1369 Salesforce 1370 San Francisco, CA 1371 United States 1373 Email: hzhang@salesforce.com 1375 20. Changelog 1377 [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] 1379 draft-ietf-dprive-xfr-over-tls-10 1381 o Address issued raised from IETF Last Call 1383 draft-ietf-dprive-xfr-over-tls-09 1385 o Address issued raised in the AD review 1387 draft-ietf-dprive-xfr-over-tls-08 1389 o RFC2845 -> (obsoleted by) RFC8945 1391 o I-D.ietf-dnsop-dns-zone-digest -> RFC8976 1393 o Minor editorial changes + email update 1395 draft-ietf-dprive-xfr-over-tls-07 1397 o Reference RFC7942 in the implementation status section 1399 o Convert the URIs that will remain on publication to references 1401 o Correct typos in acknowledgments 1403 draft-ietf-dprive-xfr-over-tls-06 1405 o Update text relating to pipelining and connection reuse after WGLC 1406 comments. 1408 o Add link to implementation status matrix 1410 o Various typos 1411 o Remove the open questions that received no comments. 1413 o Add more detail to the implementation section 1415 draft-ietf-dprive-xfr-over-tls-04 1417 o Add Github repository 1419 o Fix typos and references and improve layout. 1421 draft-ietf-dprive-xfr-over-tls-03 1423 o Remove propose to use ALPN 1425 o Clarify updates to both RFC1995 and RFC5936 by adding specific 1426 sections on this 1428 o Add a section on the threat model 1430 o Convert all SVG diagrams to ASCII art 1432 o Add discussions on concurrency limits 1434 o Add discussions on Extended DNS error codes 1436 o Re-work authentication requirements and discussion 1438 o Add appendix discussion TLS connection management 1440 draft-ietf-dprive-xfr-over-tls-02 1442 o Significantly update descriptions for both AXoT and IXoT for 1443 message and connection handling taking into account previous 1444 specifications in more detail 1446 o Add use of APLN and limitations on traffic on XoT connections. 1448 o Add new discussions of padding for both AXoT and IXoT 1450 o Add text on SIG(0) 1452 o Update security considerations 1454 o Move multi-primary considerations to earlier as they are related 1455 to connection handling 1457 o Minor editorial updates 1459 o Add requirement for TLS 1.3. or later 1461 draft-ietf-dprive-xfr-over-tls-00 1463 o Rename after adoption and reference update. 1465 o Add placeholder for SIG(0) discussion 1467 o Update section on ZONEMD 1469 draft-hzpa-dprive-xfr-over-tls-02 1471 o Substantial re-work of the document. 1473 draft-hzpa-dprive-xfr-over-tls-01 1475 o Editorial changes, updates to references. 1477 draft-hzpa-dprive-xfr-over-tls-00 1479 o Initial commit 1481 21. References 1483 21.1. Normative References 1485 [I-D.ietf-dprive-rfc7626-bis] 1486 Wicinski, T., "DNS Privacy Considerations", draft-ietf- 1487 dprive-rfc7626-bis-08 (work in progress), October 2020. 1489 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1490 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1491 . 1493 [RFC1035] Mockapetris, P., "Domain names - implementation and 1494 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1495 November 1987, . 1497 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1498 DOI 10.17487/RFC1995, August 1996, . 1501 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1502 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1503 August 1996, . 1505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1506 Requirement Levels", BCP 14, RFC 2119, 1507 DOI 10.17487/RFC2119, March 1997, . 1510 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1511 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1512 . 1514 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1515 Morris, J., Hansen, M., and R. Smith, "Privacy 1516 Considerations for Internet Protocols", RFC 6973, 1517 DOI 10.17487/RFC6973, July 2013, . 1520 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1521 D. Wessels, "DNS Transport over TCP - Implementation 1522 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1523 . 1525 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 1526 edns-tcp-keepalive EDNS0 Option", RFC 7828, 1527 DOI 10.17487/RFC7828, April 2016, . 1530 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1531 and P. Hoffman, "Specification for DNS over Transport 1532 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1533 2016, . 1535 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1536 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1537 May 2017, . 1539 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1540 for DNS over TLS and DNS over DTLS", RFC 8310, 1541 DOI 10.17487/RFC8310, March 2018, . 1544 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1545 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1546 . 1548 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1549 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1550 January 2019, . 1552 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 1553 Lawrence, "Extended DNS Errors", RFC 8914, 1554 DOI 10.17487/RFC8914, October 2020, . 1557 [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., 1558 Gudmundsson, O., and B. Wellington, "Secret Key 1559 Transaction Authentication for DNS (TSIG)", STD 93, 1560 RFC 8945, DOI 10.17487/RFC8945, November 2020, 1561 . 1563 21.2. Informative References 1565 [BIND] ISC, "BIND 9", 2021, . 1567 [I-D.ietf-dprive-dnsoquic] 1568 Huitema, C., Mankin, A., and S. Dickinson, "Specification 1569 of DNS over Dedicated QUIC Connections", draft-ietf- 1570 dprive-dnsoquic-01 (work in progress), October 2020. 1572 [I-D.ietf-dprive-phase2-requirements] 1573 Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS 1574 Privacy Requirements for Exchanges between Recursive 1575 Resolvers and Authoritative Servers", draft-ietf-dprive- 1576 phase2-requirements-02 (work in progress), November 2020. 1578 [I-D.ietf-tls-esni] 1579 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1580 Encrypted Client Hello", draft-ietf-tls-esni-09 (work in 1581 progress), December 2020. 1583 [I-D.vcelak-nsec5] 1584 Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and 1585 D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of 1586 Existence", draft-vcelak-nsec5-08 (work in progress), 1587 December 2018. 1589 [nist-guide] 1590 Chandramouli, R. and S. Rose, "Secure Domain Name System 1591 (DNS) Deployment Guide", 2013, 1592 . 1595 [NSD] NLnet Labs, "NSD", 2021, 1596 . 1598 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1599 DOI 10.17487/RFC1982, August 1996, . 1602 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1603 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 1604 2000, . 1606 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1607 Security (DNSSEC) Hashed Authenticated Denial of 1608 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1609 . 1611 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1612 for DNS (EDNS(0))", STD 75, RFC 6891, 1613 DOI 10.17487/RFC6891, April 2013, . 1616 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1617 Code: The Implementation Status Section", BCP 205, 1618 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1619 . 1621 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1622 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1623 . 1625 [RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. 1626 Hardaker, "Message Digest for DNS Zones", RFC 8976, 1627 DOI 10.17487/RFC8976, February 2021, . 1630 21.3. URIs 1632 [1] https://dnsprivacy.org/wiki/display/DP/ 1633 DNS+Privacy+Implementation+Status#DNSPrivacyImplementationStatus- 1634 XFR/XoTImplementationstatus 1636 [2] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ 1637 Changelog 1639 [3] https://github.com/NLnetLabs/nsd/pull/145 1641 [4] https://github.com/NLnetLabs/nsd/pull/149 1643 [5] https://gitlab.isc.org/isc-projects/bind9/-/issues/1784 1645 Appendix A. XoT server connection handling 1647 For completeness, it is noted that an earlier version of the 1648 specification suggested using a XoT specific ALPN to negotiate TLS 1649 connections that supported only a limited set of queries (SOA, XRFs) 1650 however this did not gain support. Reasons given included additional 1651 code complexity and proxies having no natural way to forward the ALPN 1652 signal to DNS nameservers over TCP connections. 1654 A.1. Only listen on TLS on a specific IP address 1656 Obviously a nameserver which hosts a zone and services queries for 1657 the zone on an IP address published in an NS record may wish to use a 1658 separate IP address for listening on TLS for XoT, only publishing 1659 that address to its secondaries. 1661 Pros: Probing of the public IP address will show no support for TLS. 1662 ACLs will prevent zone transfer on all transports on a per query 1663 basis. 1665 Cons: Attackers passively observing traffic will still be able to 1666 observe TLS connections to the separate address. 1668 A.2. Client specific TLS acceptance 1670 Primaries that include IP based ACLs and/or mutual TLS in their 1671 authentication models have the option of only accepting TLS 1672 connections from authorized clients. This could be implemented using 1673 a proxy or directly in DNS implementation. 1675 Pros: Connection management happens at setup time. The maximum 1676 number of TLS connections a server will have to support can be easily 1677 assessed. Once the connection is accepted the server might well be 1678 willing to answer any query on that connection since it is coming 1679 from a configured secondary and a specific response policy on the 1680 connection may not be needed (see below). 1682 Cons: Currently, none of the major open source DNS authoritative 1683 implementations support such an option. 1685 A.3. SNI based TLS acceptance 1687 Primaries could also choose to only accept TLS connections based on 1688 an SNI that was published only to their secondaries. 1690 Pros: Reduces the number of accepted connections. 1692 Cons: As above. For SNIs sent in the clear, this would still allow 1693 attackers passively observing traffic to potentially abuse this 1694 mechanism. The use of Encrypted Client Hello [I-D.ietf-tls-esni] may 1695 be of use here. 1697 A.4. TLS specific response policies 1699 Some primaries might rely on TSIG/SIG(0) combined with per-query IP 1700 based ACLs to authenticate secondaries. In this case the primary 1701 must accept all incoming TLS connections and then apply a TLS 1702 specific response policy on a per query basis. 1704 As an aside, whilst [RFC7766] makes a general purpose distinction to 1705 clients in the usage of connections (between regular queries and zone 1706 transfers) this is not strict and nothing in the DNS protocol 1707 prevents using the same connection for both types of traffic. Hence 1708 a server cannot know the intention of any client that connects to it, 1709 it can only inspect the messages it receives on such a connection and 1710 make per query decisions about whether or not to answer those 1711 queries. 1713 Example policies a XoT server might implement are: 1715 o strict: REFUSE all queries on TLS connections except SOA and 1716 authorized XFR requests 1718 o moderate: REFUSE all queries on TLS connections until one is 1719 received that is signed by a recognized TSIG/SIG(0) key, then 1720 answer all queries on the connection after that 1722 o complex: apply a heuristic to determine which queries on a TLS 1723 connections to REFUSE 1725 o relaxed: answer all non-XoT queries on all TLS connections with 1726 the same policy applied to TCP queries 1728 Pros: Allows for flexible behavior by the server that could be 1729 changed over time. 1731 Cons: The server must handle the burden of accepting all TLS 1732 connections just to perform XFRs with a small number of secondaries. 1733 Client behavior to REFUSED response is not clearly defined (see 1734 below). Currently, none of the major open source DNS authoritative 1735 implementations offer an option for different response policies in 1736 different transports (but could potentially be implemented using a 1737 proxy). 1739 A.4.1. SNI based response policies 1741 In a similar fashion, XoT servers might use the presence of an SNI in 1742 the client hello to determine which response policy to initially 1743 apply to the TLS connections. 1745 Pros: This has to potential to allow a clean distinction between a 1746 XoT service and any future DoT based service for answering recursive 1747 queries. 1749 Cons: As above. 1751 Authors' Addresses 1753 Willem Toorop 1754 NLnet Labs 1755 Science Park 400 1756 Amsterdam 1098 XH 1757 The Netherlands 1759 Email: willem@nlnetlabs.nl 1761 Sara Dickinson 1762 Sinodun IT 1763 Magdalen Centre 1764 Oxford Science Park 1765 Oxford OX4 4GA 1766 United Kingdom 1768 Email: sara@sinodun.com 1770 Shivan Sahib 1771 Salesforce 1772 Vancouver, BC 1773 Canada 1775 Email: shivankaulsahib@gmail.com 1777 Pallavi Aras 1778 Salesforce 1779 Herndon, VA 1780 United States 1782 Email: paras@salesforce.com 1783 Allison Mankin 1784 Salesforce 1785 Herndon, VA 1786 United States 1788 Email: allison.mankin@gmail.com