idnits 2.17.1 draft-ietf-dprive-xfr-over-tls-07.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 (February 16, 2021) is 1164 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 1611 -- Looks like a reference, but probably isn't: '2' on line 1615 -- Looks like a reference, but probably isn't: '3' on line 1618 -- Looks like a reference, but probably isn't: '4' on line 1620 -- Looks like a reference, but probably isn't: '5' on line 1622 ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Downref: Normative reference to an Informational RFC: RFC 6973 ** Obsolete normative reference: RFC 7626 (Obsoleted by RFC 9076) ** 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: 4 errors (**), 0 flaws (~~), 4 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: August 20, 2021 S. Sahib 7 P. Aras 8 A. Mankin 9 Salesforce 10 February 16, 2021 12 DNS Zone Transfer-over-TLS 13 draft-ietf-dprive-xfr-over-tls-07 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 August 20, 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. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 6 65 4.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Connection and Data Flows in Existing XFR Mechanisms . . . . 7 67 5.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 7 68 5.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 9 69 5.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 11 70 5.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6. Updates to existing specifications . . . . . . . . . . . . . 11 73 6.1. Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . . 13 74 6.2. Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . . 13 75 6.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . . 13 76 6.3.1. Connection reuse . . . . . . . . . . . . . . . . . . 13 77 6.3.2. AXFRs and IXFRs on the same connection . . . . . . . 14 78 6.3.3. XFR limits . . . . . . . . . . . . . . . . . . . . . 14 79 6.3.4. The edns-tcp-keepalive EDNS0 Option . . . . . . . . . 15 80 6.3.5. Backwards compatibility . . . . . . . . . . . . . . . 15 81 6.4. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 15 82 7. XoT specification . . . . . . . . . . . . . . . . . . . . . . 17 83 7.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 17 84 7.2. Port selection . . . . . . . . . . . . . . . . . . . . . 17 85 7.3. High level XoT descriptions . . . . . . . . . . . . . . . 17 86 7.4. XoT transfers . . . . . . . . . . . . . . . . . . . . . . 19 87 7.5. XoT connections . . . . . . . . . . . . . . . . . . . . . 20 88 7.6. XoT vs ADoT . . . . . . . . . . . . . . . . . . . . . . . 20 89 7.7. Response RCODES . . . . . . . . . . . . . . . . . . . . . 21 90 7.8. AXoT specifics . . . . . . . . . . . . . . . . . . . . . 21 91 7.8.1. Padding AXoT responses . . . . . . . . . . . . . . . 21 92 7.9. IXoT specifics . . . . . . . . . . . . . . . . . . . . . 22 93 7.9.1. Condensation of responses . . . . . . . . . . . . . . 22 94 7.9.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 22 95 7.9.3. Padding of IXoT responses . . . . . . . . . . . . . . 23 96 7.10. Name compression and maximum payload sizes . . . . . . . 23 98 8. Multi-primary Configurations . . . . . . . . . . . . . . . . 23 99 9. Authentication mechanisms . . . . . . . . . . . . . . . . . . 24 100 9.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 9.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 9.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 103 9.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . . 25 104 9.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 26 105 9.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 26 106 9.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 26 107 9.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 27 108 10. XoT authentication . . . . . . . . . . . . . . . . . . . . . 27 109 11. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 28 110 12. Implementation Considerations . . . . . . . . . . . . . . . . 29 111 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 112 14. Implementation Status . . . . . . . . . . . . . . . . . . . . 29 113 15. Security Considerations . . . . . . . . . . . . . . . . . . . 30 114 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 115 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 116 18. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31 117 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 118 19.1. Normative References . . . . . . . . . . . . . . . . . . 33 119 19.2. Informative References . . . . . . . . . . . . . . . . . 34 120 19.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 121 Appendix A. XoT server connection handling . . . . . . . . . . . 36 122 A.1. Only listen on TLS on a specific IP address . . . . . . . 36 123 A.2. Client specific TLS acceptance . . . . . . . . . . . . . 37 124 A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 37 125 A.4. TLS specific response policies . . . . . . . . . . . . . 37 126 A.4.1. SNI based response policies . . . . . . . . . . . . . 38 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 129 1. Introduction 131 DNS has a number of privacy vulnerabilities, as discussed in detail 132 in [RFC7626]. Stub client to recursive resolver query privacy has 133 received the most attention to date, with standards track documents 134 for both DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) 135 [RFC8484], and a proposal for DNS-over-QUIC 136 [I-D.ietf-dprive-dnsoquic]. There is ongoing work on DNS privacy 137 requirements for exchanges between recursive resolvers and 138 authoritative servers [I-D.ietf-dprive-phase2-requirements] and some 139 suggestions for how signaling of DoT support by authoritatives might 140 work, e.g., [I-D.vandijk-dprive-ds-dot-signal-and-pin]. However 141 there is currently no RFC that specifically defines recursive to 142 authoritative DNS-over-TLS (ADoT). 144 [RFC7626] established that stub client DNS query transactions are not 145 public and needed protection, but on zone transfer [RFC1995] 146 [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 There may also be regulatory, policy or other reasons why the zone 167 contents in full must be treated as private. 169 Neither of the RFCs mentioned in [RFC7626] contemplates the risk that 170 someone gets the data through eavesdropping on network connections, 171 only via enumeration or unauthorized transfer as described in the 172 following paragraphs. 174 Zone enumeration is trivially possible for DNSSEC zones which use 175 NSEC; i.e. queries for the authenticated denial of existences 176 records allow a client to walk through the entire zone contents. 177 [RFC5155] specifies NSEC3, a mechanism to provide measures against 178 zone enumeration for DNSSEC signed zones (a goal was to make it as 179 hard to enumerate an DNSSEC signed zone as an unsigned zone). Whilst 180 this is widely used, zone walking is now possible with NSEC3 due to 181 crypto-breaking advances. This has prompted further work on an 182 alternative mechanism for DNSSEC authenticated denial of existence - 183 NSEC5 [I-D.vcelak-nsec5] - however questions remain over the 184 practicality of this mechanism. 186 [RFC5155] does not address data obtained outside zone enumeration 187 (nor does [I-D.vcelak-nsec5]). Preventing eavesdropping of zone 188 transfers (this draft) is orthogonal to preventing zone enumeration, 189 though they aim to protect the same information. 191 [RFC5936] specifies using TSIG [RFC2845] for authorization of the 192 clients of a zone transfer and for data integrity, but does not 193 express any need for confidentiality, and TSIG does not offer 194 encryption. Some operators use SSH tunneling or IPSec to encrypt the 195 transfer data. 197 Section 8 of the NIST guide on 'Secure Domain Name System (DNS) 198 Deployment' [nist-guide] discusses restricting access for zone 199 transfers using ACLs and TSIG in more detail. It is noted that in 200 all the common open source implementations such ACLs are applied on a 201 per query basis. Since requests typically occur on TCP connections 202 authoritatives must cater for accepting any TCP connection and then 203 handling the authentication of each XFR request individually. 205 Because both AXFR and IXFR zone transfers are typically carried out 206 over TCP from authoritative DNS protocol implementations, encrypting 207 zone transfers using TLS, based closely on DoT [RFC7858], seems like 208 a simple step forward. This document specifies how to use TLS as a 209 transport to prevent zone collection from zone transfers. 211 2. Document work via GitHub 213 [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository 214 for this document is at . Proposed text and editorial changes are very much 216 welcomed there, but any functional changes should always first be 217 discussed on the IETF DPRIVE WG (dns-privacy) mailing list. 219 3. Terminology 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 223 "OPTIONAL" in this document are to be interpreted as described in BCP 224 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 225 capitals, as shown here. 227 Privacy terminology is as described in Section 3 of [RFC6973]. 229 Note that in this document we choose to use the terms 'primary' and 230 'secondary' for two servers engaged in zone transfers. 232 DNS terminology is as described in [RFC8499]. 234 DoT: DNS-over-TLS as specified in [RFC7858] 236 XFR-over-TCP: Used to mean both IXFR-over-TCP [RFC1995] and AXFR- 237 over-TCP [RFC5936]. 239 XoT: Generic XFR-over-TLS mechanisms as specified in this document 241 AXoT: AXFR-over-TLS 243 IXoT: IXFR over-TLS 245 4. Use Cases for XFR-over-TLS 247 o Confidentiality. Clearly using an encrypted transport for zone 248 transfers will defeat zone content leakage that can occur via 249 passive surveillance. 251 o Authentication. Use of single or mutual TLS (mTLS) authentication 252 (in combination with ACLs) can complement and potentially be an 253 alternative to TSIG. 255 o Performance. Existing AXFR and IXFR mechanisms have the burden of 256 backwards compatibility with older implementations based on the 257 original specifications in [RFC1034] and [RFC1035]. For example, 258 some older AXFR servers don't support using a TCP connection for 259 multiple AXFR sessions or XFRs of different zones because they 260 have not been updated to follow the guidance in [RFC5936]. Any 261 implementation of XFR-over-TLS (XoT) would obviously be required 262 to implement optimized and interoperable transfers as described in 263 [RFC5936], e.g., transfer of multiple zones over one connection. 265 o Performance. Current usage of TCP for IXFR is sub-optimal in some 266 cases i.e. connections are frequently closed after a single IXFR. 268 4.1. Threat model 270 The threat model considered here is one where the current contents 271 and size of the zone are considered sensitive and should be protected 272 during transfer. 274 The threat model does not, however, consider the existence of a zone, 275 the act of zone transfer between two entities, nor the identities of 276 the nameservers hosting a zone (including both those acting as hidden 277 primaries/secondaries or directly serving the zone) as sensitive 278 information. The proposed mechanisms does not attempt to obscure 279 such information. The reasons for this include: 281 o much of this information can be obtained by various methods 282 including active scanning of the DNS 284 o an attacker who can monitor network traffic can relatively easily 285 infer relations between nameservers simply from traffic patterns, 286 even when some or all of the traffic is encrypted 288 It is noted that simply using XoT will indicate a desire by the zone 289 owner that the contents of the zone remain confidential and so could 290 be subject to blocking (e.g. via blocking of port 853) if an attacker 291 had such capabilities. However this threat is likely true of any 292 such mechanism that attempts to encrypt data passed between 293 nameservers e.g. IPsec. 295 5. Connection and Data Flows in Existing XFR Mechanisms 297 The original specification for zone transfers in [RFC1034] and 298 [RFC1035] was based on a polling mechanism: a secondary performed a 299 periodic SOA query (based on the refresh timer) to determine if an 300 AXFR was required. 302 [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY 303 respectively, to provide for prompt propagation of zone updates. 304 This has largely replaced AXFR where possible, particularly for 305 dynamically updated zones. 307 [RFC5936] subsequently redefined the specification of AXFR to improve 308 performance and interoperability. 310 In this document we use the term "XFR mechanism" to describe the 311 entire set of message exchanges between a secondary and a primary 312 that concludes in a successful AXFR or IXFR request/response. This 313 set may or may not include 315 o NOTIFY messages 317 o SOA queries 319 o Fallback from IXFR to AXFR 321 o Fallback from IXFR-over-UDP to IXFR-over-TCP 323 The term is used to encompasses the range of permutations that are 324 possible and is useful to distinguish the 'XFR mechanism' from a 325 single XFR request/response exchange. 327 5.1. AXFR Mechanism 329 The figure below provides an outline of an AXFR mechanism including 330 NOTIFYs. 332 Secondary Primary 334 | NOTIFY | 335 | <-------------------------------- | UDP 336 | --------------------------------> | 337 | NOTIFY Response | 338 | | 339 | | 340 | SOA Request | 341 | --------------------------------> | UDP (or part of 342 | <-------------------------------- | a TCP session) 343 | SOA Response | 344 | | 345 | | 346 | | 347 | AXFR Request | --- 348 | --------------------------------> | | 349 | <-------------------------------- | | 350 | AXFR Response 1 | | 351 | (Zone data) | | 352 | | | 353 | <-------------------------------- | | TCP 354 | AXFR Response 2 | | Session 355 | (Zone data) | | 356 | | | 357 | <-------------------------------- | | 358 | AXFR Response 3 | | 359 | (Zone data) | --- 360 | | 362 Figure 1. AXFR Mechanism 364 1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP) 365 from the primary to the secondary. A secondary may also initiate 366 an AXFR based on a refresh timer or scheduled/triggered zone 367 maintenance. 369 2. The secondary will normally (but not always) make a SOA query to 370 the primary to obtain the serial number of the zone held by the 371 primary. 373 3. If the primary serial is higher than the secondaries serial 374 (using Serial Number Arithmetic [RFC1982]), the secondary makes 375 an AXFR request (over TCP) to the primary after which the AXFR 376 data flows in one or more AXFR responses on the TCP connection. 377 [RFC5936] defines this specific step as an 'AXFR session' i.e. as 378 an AXFR query message and the sequence of AXFR response messages 379 returned for it. 381 [RFC5936] re-specified AXFR providing additional guidance beyond that 382 provided in [RFC1034] and [RFC1035] and importantly specified that 383 AXFR must use TCP as the transport protocol. 385 Additionally, sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] provide 386 improved guidance for AXFR clients and servers with regard to re-use 387 of TCP connections for multiple AXFRs and AXFRs of different zones. 388 However [RFC5936] was constrained by having to be backwards 389 compatible with some very early basic implementations of AXFR. For 390 example, it outlines that the SOA query can also happen on this 391 connection. However, this can cause interoperability problems with 392 older implementations that support only the trivial case of one AXFR 393 per connection. 395 5.2. IXFR Mechanism 397 The figure below provides an outline of the IXFR mechanism including 398 NOTIFYs. 400 Secondary Primary 402 | NOTIFY | 403 | <-------------------------------- | UDP 404 | --------------------------------> | 405 | NOTIFY Response | 406 | | 407 | | 408 | SOA Request | 409 | --------------------------------> | UDP or TCP 410 | <-------------------------------- | 411 | SOA Response | 412 | | 413 | | 414 | | 415 | IXFR Request | 416 | --------------------------------> | UDP or TCP 417 | <-------------------------------- | 418 | IXFR Response | 419 | (Zone data) | 420 | | 421 | | --- 422 | IXFR Request | | 423 | --------------------------------> | | Retry over 424 | <-------------------------------- | | TCP if 425 | IXFR Response | | required 426 | (Zone data) | --- 428 Figure 1. IXFR Mechanism 430 1. An IXFR is normally (but not always) preceded by a NOTIFY (over 431 UDP) from the primary to the secondary. A secondary may also 432 initiate an IXFR based on a refresh timer or scheduled/triggered 433 zone maintenance. 435 2. The secondary will normally (but not always) make a SOA query to 436 the primary to obtain the serial number of the zone held by the 437 primary. 439 3. If the primary serial is higher than the secondaries serial 440 (using Serial Number Arithmetic [RFC1982]), the secondary makes 441 an IXFR request to the primary after the primary sends an IXFR 442 response. 444 [RFC1995] specifies that Incremental Transfer may use UDP if the 445 entire IXFR response can be contained in a single DNS packet, 446 otherwise, TCP is used. In fact it says: 448 "Thus, a client should first make an IXFR query using UDP." 450 So there may be a fourth step above where the client falls back to 451 IXFR-over-TCP. There may also be a fourth step where the secondary 452 must fall back to AXFR because, e.g., the primary does not support 453 IXFR. 455 However it is noted that most widely used open source authoritative 456 nameserver implementations (including both [BIND] and [NSD] do IXFR 457 using TCP by default in their latest releases. For BIND TCP 458 connections are sometimes used for SOA queries but in general they 459 are not used persistently and close after an IXFR is completed. 461 5.3. Data Leakage of NOTIFY and SOA Message Exchanges 463 This section attempts to presents a rationale for considering 464 encrypting the other messages in the XFR mechanism. 466 Since the SOA of the published zone can be trivially discovered by 467 simply querying the publicly available authoritative servers leakage 468 of this RR is not discussed in the following sections. 470 5.3.1. NOTIFY 472 Unencrypted NOTIFY messages identify configured secondaries on the 473 primary. 475 [RFC1996] also states: 477 "If ANCOUNT>0, then the answer section represents an 478 unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE). 480 But since the only supported QTYPE for NOTIFY is SOA, this does not 481 pose a potential leak. 483 5.3.2. SOA 485 For hidden primaries or secondaries the SOA response leaks only the 486 degree of lag of any downstream secondary. 488 6. Updates to existing specifications 490 For convenience, the term 'XFR-over-TCP' is used in this document to 491 mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements 492 that use that term update both [RFC1995] and [RFC5936], and 493 implicitly also apply to XoT. Differences in behavior specific to 494 XoT are discussed in Section 7. 496 Both [RFC1995] and [RFC5936] were published sometime before TCP was 497 considered a first class transport for DNS. [RFC1995], in fact, says 498 nothing with respect to optimizing IXFRs over TCP or re-using already 499 open TCP connections to perform IXFRs or other queries. Therefore, 500 there arguably is an implicit assumption (probably unintentional) 501 that a TCP connection is used for one and only one IXFR request. 502 Indeed, many major open source implementations currently take this 503 approach. And whilst [RFC5936] gives guidance on connection re-use 504 for AXFR, it pre-dates more recent specifications describing 505 persistent TCP connections e.g. [RFC7766], [RFC7828] and AXFR 506 implementations again often make less than optimal use of open 507 connections. 509 Given this, new implementations of XoT will clearly benefit from 510 specific guidance on TCP/TLS connection usage for XFR because this 511 will: 513 o result in more consistent XoT implementations with better 514 interoperability 516 o remove any need for XoT implementations to support legacy behavior 517 that XFR-over-TCP implementations have historically often 518 supported 520 Therefore this document updates both the previous specifications for 521 XFR-over-TCP to clarify that 523 o Implementations MUST use [RFC7766] (DNS Transport over TCP - 524 Implementation Requirements) to optimize the use of TCP 525 connections. 527 o Whilst RFC7766 states that 'DNS clients SHOULD pipeline their 528 queries' on TCP connections, it did not distinguish between XFRs 529 and other queries for this behavior. It is now recognized that 530 XFRs are not as latency sensitive as other queries, and can be 531 significantly more complex for clients to handle both because of 532 the large amount of state that must be kept and because there may 533 be multiple messages in the responses. For these reasons it is 534 clarified here that a valid reason for not pipelining queries is 535 when they are all XFR queries i.e. clients sending multiple XFRs 536 MAY choose not to pipeline those queries. Clients that do not 537 pipeline XFR queries, therefore, have no additional requirements 538 to handle out-of-order or intermingled responses (as described 539 later) since they will never receive them. 541 o Implementations SHOULD use [RFC7828] (The edns-tcp-keepalive EDNS0 542 Option) to manage persistent connections. 544 The following sections include detailed clarifications on the updates 545 to XFR behavior implied in [RFC7766] and how the use of [RFC7828] 546 applies specifically to XFR exchanges. It also discusses how IXFR 547 and AXFR can reuse the same TCP connection. 549 For completeness, we also mention here the recent specification of 550 extended DNS error (EDE) codes [RFC8914]. For zone transfers, when 551 returning REFUSED to a zone transfer request to an 'unauthorized' 552 client (e.g. where the client is not listed in an ACL for zone 553 transfers or does not sign the request with the correct TSIG key), 554 the extended DNS error code 18 (Prohibited) can also be sent. 556 6.1. Update to RFC1995 for IXFR-over-TCP 558 For clarity - an IXFR-over-TCP server compliant with this 559 specification MUST be able to handle multiple concurrent IXoT 560 requests on a single TCP connection (for the same and different 561 zones) and SHOULD send the responses as soon as they are available, 562 which might be out-of-order compared to the requests. 564 6.2. Update to RFC5936 for AXFR-over-TCP 566 For clarity - an AXFR-over-TCP server compliant with this 567 specification MUST be able to handle multiple concurrent AXoT 568 sessions on a single TCP connection (for the same and different 569 zones). The response streams for concurrent AXFRs MAY be 570 intermingled and AXFR-over-TCP clients compliant with this 571 specification which pipeline AXFR requests MUST be able to handle 572 this. 574 6.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP 576 6.3.1. Connection reuse 578 As specified, XFR-over-TCP clients SHOULD re-use any existing open 579 TCP connection when starting any new XFR request to the same primary, 580 and for issuing SOA queries, instead of opening a new connection. 581 The number of TCP connections between a secondary and primary SHOULD 582 be minimized (also see Section 6.4). 584 Valid reasons for not re-using existing connections might include: 586 o as already noted in [RFC7766], separate connections for different 587 zones might be preferred for operational reasons. In this case 588 the number of concurrent connections for zone transfers SHOULD be 589 limited to the total number of zones transferred between the 590 client and server. 592 o reaching a configured limit for the number of outstanding queries 593 or XFR requests allowed on a single TCP connection 595 o the message ID pool has already been exhausted on an open 596 connection 598 o a large number of timeouts or slow responses have occurred on an 599 open connection 601 o an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been 602 received from the server and the client is in the process of 603 closing the connection (see Section 6.3.4) 605 If no TCP connections are currently open, XFR clients MAY send SOA 606 queries over UDP or a new TCP connection. 608 6.3.2. AXFRs and IXFRs on the same connection 610 Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a 611 single TCP connection for both IXFR and AXFR requests. [RFC5936] 612 does make the general statement: 614 "Non-AXFR session traffic can also use an open TCP connection." 616 We clarify here that implementations capable of both AXFR and IXFR 617 and compliant with this specification SHOULD 619 o use the same TCP connection for both AXFR and IXFR requests to the 620 same primary 622 o pipeline such requests (if they pipeline XFR requests in general) 623 and MAY intermingle them 625 o send the response(s) for each request as soon as they are 626 available i.e. responses MAY be sent intermingled 628 6.3.3. XFR limits 630 The server MAY limit the number of concurrent IXFRs, AXFRs or total 631 XFR transfers in progress, or from a given secondary, to protect 632 server resources. Servers SHOULD return SERVFAIL if this limit is 633 hit, since it is a transient error and a retry at a later time might 634 succeed. 636 6.3.4. The edns-tcp-keepalive EDNS0 Option 638 XFR clients that send the edns-tcp-keepalive EDNS0 option on every 639 XFR request provide the server with maximum opportunity to update the 640 edns-tcp-keepalive timeout. The XFR server may use the frequency of 641 recent XFRs to calculate an average update rate as input to the 642 decision of what edns-tcp-keepalive timeout to use. If the server 643 does not support edns-tcp-keepalive the client MAY keep the 644 connection open for a few seconds ([RFC7766] recommends that servers 645 use timeouts of at least a few seconds). 647 Whilst the specification for EDNS0 [RFC6891] does not specifically 648 mention AXFRs, it does say 650 "If an OPT record is present in a received request, compliant 651 responders MUST include an OPT record in their respective 652 responses." 654 We clarify here that if an OPT record is present in a received AXFR 655 request, compliant responders MUST include an OPT record in each of 656 the subsequent AXFR responses. Note that this requirement, combined 657 with the use of edns-tcp-keepalive, enables AXFR servers to signal 658 the desire to close a connection (when existing transactions have 659 competed) due to low resources by sending an edns-tcp-keepalive EDNS0 660 option with a timeout of 0 on any AXFR response. This does not 661 signal that the AXFR is aborted, just that the server wishes to close 662 the connection as soon as possible. 664 6.3.5. Backwards compatibility 666 Certain legacy behaviors were noted in [RFC5936], with provisions 667 that implementations may want to offer options to fallback to legacy 668 behavior when interoperating with servers known not to support 669 [RFC5936]. For purposes of interoperability, IXFR and AXFR 670 implementations may want to continue offering such configuration 671 options, as well as supporting some behaviors that were 672 underspecified prior to this work (e.g. performing IXFR and AXFRs on 673 separate connections). However, XoT implementations should have no 674 need to do so. 676 6.4. Update to RFC7766 678 [RFC7766] made general implementation recommendations with regard to 679 TCP/TLS connection handling: 681 "To mitigate the risk of unintentional server overload, DNS 682 clients MUST take care to minimize the number of concurrent TCP 683 connections made to any individual server. It is RECOMMENDED 684 that for any given client/server interaction there SHOULD be no 685 more than one connection for regular queries, one for zone 686 transfers, and one for each protocol that is being used on top 687 of TCP (for example, if the resolver was using TLS). However, 688 it is noted that certain primary/ secondary configurations with 689 many busy zones might need to use more than one TCP connection 690 for zone transfers for operational reasons (for example, to 691 support concurrent transfers of multiple zones)." 693 Whilst this recommends a particular behavior for the clients using 694 TCP, it does not relax the requirement for servers to handle 'mixed' 695 traffic (regular queries and zone transfers) on any open TCP/TLS 696 connection. It also overlooks the potential that other transports 697 might want to take the same approach with regard to using separate 698 connections for different purposes. 700 This specification for XoT updates the guidance in [RFC7766] to 701 provide the same separation of connection purpose (regular queries 702 and zone transfers) for all transports being used on top of TCP. 704 Therefore, it is RECOMMENDED that for each protocol used on top of 705 TCP in any given client/server interaction there SHOULD be no more 706 than one connection for regular queries and one for zone transfers. 708 As an illustration, it could be imagined that in future such an 709 interaction could hypothetically include one or all of the following: 711 o one TCP connection for regular queries 713 o one TCP connection for zone transfers 715 o one TLS connection for regular queries 717 o one TLS connection for zone transfers 719 o one DoH connection for regular queries 721 o one DoH connection for zone transfers 723 Section 6.3.1 has provided specific details of reasons where more 724 than one connection for a given transport might be required for zone 725 transfers from a particular client. 727 7. XoT specification 729 7.1. TLS versions 731 For improved security all implementations of this specification MUST 732 use only TLS 1.3 [RFC8446] or later. 734 7.2. Port selection 736 The connection for XoT SHOULD be established using port 853, as 737 specified in [RFC7858], unless there is mutual agreement between the 738 secondary and primary to use a port other than port 853 for XoT. 739 There MAY be agreement to use different ports for AXoT and IXoT, or 740 for different zones. 742 7.3. High level XoT descriptions 744 It is useful to note that in XoT it is the secondary that initiates 745 the TLS connection to the primary for a XFR request, so that in terms 746 of connectivity the secondary is the TLS client and the primary the 747 TLS server. 749 The figure below provides an outline of the AXoT mechanism including 750 NOTIFYs. 752 Secondary Primary 754 | NOTIFY | 755 | <-------------------------------- | UDP 756 | --------------------------------> | 757 | NOTIFY Response | 758 | | 759 | | 760 | SOA Request | 761 | --------------------------------> | UDP (or part of 762 | <-------------------------------- | a TCP/TLS session) 763 | SOA Response | 764 | | 765 | | 766 | | 767 | AXFR Request | --- 768 | --------------------------------> | | 769 | <-------------------------------- | | 770 | AXFR Response 1 | | 771 | (Zone data) | | 772 | | | 773 | <-------------------------------- | | TLS 774 | AXFR Response 2 | | Session 775 | (Zone data) | | 776 | | | 777 | <-------------------------------- | | 778 | AXFR Response 3 | | 779 | (Zone data) | --- 780 | | 782 Figure 3. AXoT Mechanism 784 The figure below provides an outline of the IXoT mechanism including 785 NOTIFYs. 787 Secondary Primary 789 | NOTIFY | 790 | <-------------------------------- | UDP 791 | --------------------------------> | 792 | NOTIFY Response | 793 | | 794 | | 795 | SOA Request | 796 | --------------------------------> | UDP (or part of 797 | <-------------------------------- | a TCP/TLS session) 798 | SOA Response | 799 | | 800 | | 801 | | 802 | IXFR Request | --- 803 | --------------------------------> | | 804 | <-------------------------------- | | 805 | IXFR Response | | 806 | (Zone data) | | 807 | | | TLS 808 | | | session 809 | IXFR Request | | 810 | --------------------------------> | | 811 | <-------------------------------- | | 812 | IXFR Response | | 813 | (Zone data) | --- 815 Figure 1. IXoT Mechanism 817 7.4. XoT transfers 819 For a zone transfer between two end points to be considered protected 820 with XoT all XFR requests and response for that zone MUST be sent 821 over TLS connections where at a minimum: 823 o the client MUST authenticate the server by use of an 824 authentication domain name using a Strict Privacy Profile as 825 described in [RFC8310] 827 o the server MUST validate the client is authorized to request or 828 proxy a zone transfer by using one or both of the following: 830 * an IP based ACL (which can be either per-message or per- 831 connection) 833 * Mutual TLS (mTLS) 835 The server MAY also require a valid TSIG/SIG(0) signature, but this 836 alone is not sufficient to authenticate the client or server. 838 Authentication mechanisms are discussed in full in Section 9 and the 839 rationale for the above requirement in Section 10. Transfer group 840 policies are discussed in Section 11. 842 7.5. XoT connections 844 The details in Section 6 about e.g., persistent connections and XFR 845 message handling are fully applicable to XoT connections as well. 846 However any behavior specified here takes precedence for XoT. 848 If no TLS connections are currently open, XoT clients MAY send SOA 849 queries over UDP or TCP, or TLS. 851 7.6. XoT vs ADoT 853 As noted earlier, there is currently no specification for encryption 854 of connections from recursive resolvers to authoritative servers. 855 Some authoritatives are experimenting with ADoT and opportunistic 856 encryption has also been raised as a possibility; it is therefore 857 highly likely that use of encryption by authoritative servers will 858 evolve in the coming years. 860 This raises questions in the short term,S.S. with regard to TLS 861 connection and message handling for authoritative servers. In 862 particular, there is likely to be a class of authoritatives that wish 863 to use XoT in the near future with a small number of configured 864 secondaries but that do wish to support DoT for regular queries from 865 recursive in that same time frame. These servers have to potentially 866 cope with probing and direct queries from recursives and from test 867 servers, and also potential attacks that might wish to make use of 868 TLS to overload the server. 870 [RFC5936] clearly states that non-AXFR session traffic can use an 871 open TCP connection, however, this requirement needs to be re- 872 evaluated when considering applying the same model to XoT. Proposing 873 that a server should also start responding to all queries received 874 over TLS just because it has enabled XoT would be equivalent to 875 defining a form of authoritative DoT. This specification does not 876 propose that, but it also does not prohibit servers from answering 877 queries unrelated to XFR exchanges over TLS. Rather, this 878 specification simply outlines in later sections: 880 o how XoT implementations should utilize EDE codes in response to 881 queries on TLS connections they are not willing to answer (see 882 Section 7.7) 884 o the operational and policy options that a XoT server operator has 885 with regard to managing TLS connections and messages (see 886 Appendix A) 888 7.7. Response RCODES 890 XoT clients and servers MUST implement EDE codes. If a XoT server 891 receives non-XoT traffic it is not willing to answer on a TLS 892 connection it SHOULD respond with the extended DNS error code 21 - 893 Not Supported [RFC8914]. XoT clients should not send any further 894 queries of this type to the server for a reasonable period of time 895 (for example, one hour) i.e., long enough that the server 896 configuration or policy might be updated. 898 Historically servers have used the REFUSED RCODE for many situations, 899 and so clients often had no detailed information on which to base an 900 error or fallback path when queries were refused. As a result the 901 client behavior could vary significantly. XoT servers that refuse 902 queries must cater for the fact that client behavior might vary from 903 continually retrying queries regardless of receiving REFUSED to every 904 query, or at the other extreme clients may decide to stop using the 905 server over any transport. This might be because those clients are 906 either non-XoT clients or do not implement EDE codes. 908 7.8. AXoT specifics 910 7.8.1. Padding AXoT responses 912 The goal of padding AXoT responses would be two fold: 914 o to obfuscate the actual size of the transferred zone to minimize 915 information leakage about the entire contents of the zone. 917 o to obfuscate the incremental changes to the zone between SOA 918 updates to minimize information leakage about zone update activity 919 and growth. 921 Note that the re-use of XoT connections for transfers of multiple 922 different zones complicates any attempt to analyze the traffic size 923 and timing to extract information. 925 It is noted here that, depending on the padding policies eventually 926 developed for XoT, the requirement to obfuscate the total zone size 927 might require a server to create 'empty' AXoT responses. That is, 928 AXoT responses that contain no RR's apart from an OPT RR containing 929 the EDNS(0) option for padding. For example, without this capability 930 the maximum size that a tiny zone could be padded to would 931 theoretically be limited if there had to be a minimum of 1 RR per 932 packet. 934 However, as with existing AXFR, the last AXoT response message sent 935 MUST contain the same SOA that was in the first message of the AXoT 936 response series in order to signal the conclusion of the zone 937 transfer. 939 [RFC5936] says: 941 "Each AXFR response message SHOULD contain a sufficient number 942 of RRs to reasonably amortize the per-message overhead, up to 943 the largest number that will fit within a DNS message (taking 944 the required content of the other sections into account, as 945 described below)." 947 'Empty' AXoT responses generated in order to meet a padding 948 requirement will be exceptions to the above statement. For 949 flexibility, future proofing and in order to guarantee support for 950 future padding policies, we state here that secondary implementations 951 MUST be resilient to receiving padded AXoT responses, including 952 'empty' AXoT responses that contain only an OPT RR containing the 953 EDNS(0) option for padding. 955 Recommendation of specific policies for padding AXoT responses are 956 out of scope for this specification. Detailed considerations of such 957 policies and the trade-offs involved are expected to be the subject 958 of future work. 960 7.9. IXoT specifics 962 7.9.1. Condensation of responses 964 [RFC1995] says condensation of responses is optional and MAY be done. 965 Whilst it does add complexity to generating responses it can 966 significantly reduce the size of responses. However any such 967 reduction might be offset by increased message size due to padding. 968 This specification does not update the optionality of condensation 969 for XoT responses. 971 7.9.2. Fallback to AXFR 973 Fallback to AXFR can happen, for example, if the server is not able 974 to provide an IXFR for the requested SOA. Implementations differ in 975 how long they store zone deltas and how many may be stored at any one 976 time. 978 Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD 979 request the AXFR on the already open XoT connection. 981 7.9.3. Padding of IXoT responses 983 The goal of padding IXoT responses would be to obfuscate the 984 incremental changes to the zone between SOA updates to minimize 985 information leakage about zone update activity and growth. Both the 986 size and timing of the IXoT responses could reveal information. 988 IXFR responses can vary in size greatly from the order of 100 bytes 989 for one or two record updates, to tens of thousands of bytes for 990 large dynamic DNSSEC signed zones. The frequency of IXFR responses 991 can also depend greatly on if and how the zone is DNSSEC signed. 993 In order to guarantee support for future padding policies, we state 994 here that secondary implementations MUST be resilient to receiving 995 padded IXoT responses. 997 Recommendation of specific policies for padding IXoT responses are 998 out of scope for this specification. Detailed considerations of such 999 policies and the trade-offs involved are expected to be the subject 1000 of future work. 1002 7.10. Name compression and maximum payload sizes 1004 It is noted here that name compression [RFC1035] can be used in XFR 1005 responses to reduce the size of the payload, however the maximum 1006 value of the offset that can be used in the name compression pointer 1007 structure is 16384. For some DNS implementations this limits the 1008 size of an individual XFR response used in practice to something 1009 around the order of 16kB. In principle, larger payload sizes can be 1010 supported for some responses with more sophisticated approaches (e.g. 1011 by pre-calculating the maximum offset required). 1013 Implementations may wish to offer options to disable name compression 1014 for XoT responses to enable larger payloads. This might be 1015 particularly helpful when padding is used since minimizing the 1016 payload size is not necessarily a useful optimization in this case 1017 and disabling name compression will reduce the resources required to 1018 construct the payload. 1020 8. Multi-primary Configurations 1022 Also known as multi-master configurations this model can provide 1023 flexibility and redundancy particularly for IXFR. A secondary will 1024 receive one or more NOTIFY messages and can send an SOA to all of the 1025 configured primaries. It can then choose to send an XFR request to 1026 the primary with the highest SOA (or other criteria, e.g., RTT). 1028 When using persistent connections the secondary may have a XoT 1029 connection already open to one or more primaries. Should a secondary 1030 preferentially request an XFR from a primary to which it already has 1031 an open XoT connection or the one with the highest SOA (assuming it 1032 doesn't have a connection open to it already)? 1034 Two extremes can be envisaged here. The first one can be considered 1035 a 'preferred primary connection' model. In this case the secondary 1036 continues to use one persistent connection to a single primary until 1037 it has reason not to. Reasons not to might include the primary 1038 repeatedly closing the connection, long RTTs on transfers or the SOA 1039 of the primary being an unacceptable lag behind the SOA of an 1040 alternative primary. 1042 The other extreme can be considered a 'parallel primary connection' 1043 model. Here a secondary could keep multiple persistent connections 1044 open to all available primaries and only request XFRs from the 1045 primary with the highest serial number. Since normally the number of 1046 secondaries and primaries in direct contact in a transfer group is 1047 reasonably low this might be feasible if latency is the most 1048 significant concern. 1050 Recommendation of a particular scheme is out of scope of this 1051 document but implementations are encouraged to provide configuration 1052 options that allow operators to make choices about this behavior. 1054 9. Authentication mechanisms 1056 To provide context to the requirements in section Section 7.4, this 1057 section provides a brief summary of some of the existing 1058 authentication and validation mechanisms (both transport independent 1059 and TLS specific) that are available when performing zone transfers. 1060 Section 10 then discusses in more details specifically how a 1061 combination of TLS authentication, TSIG and IP based ACLs interact 1062 for XoT. 1064 We classify the mechanisms based on the following properties: 1066 o 'Data Origin Authentication' (DO): Authentication that the DNS 1067 message originated from the party with whom credentials were 1068 shared, and of the data integrity of the message contents (the 1069 originating party may or may not be party operating the far end of 1070 a TCP/TLS connection in a 'proxy' scenario). 1072 o 'Channel Confidentiality' (CC): Confidentiality of the 1073 communication channel between the client and server (i.e. the two 1074 end points of a TCP/TLS connection) from passive surveillance. 1076 o 'Channel Authentication' (CA): Authentication of the identity of 1077 party to whom a TCP/TLS connection is made (this might not be a 1078 direct connection between the primary and secondary in a proxy 1079 scenario). 1081 9.1. TSIG 1083 TSIG [RFC2845] provides a mechanism for two or more parties to use 1084 shared secret keys which can then be used to create a message digest 1085 to protect individual DNS messages. This allows each party to 1086 authenticate that a request or response (and the data in it) came 1087 from the other party, even if it was transmitted over an unsecured 1088 channel or via a proxy. 1090 Properties: Data origin authentication 1092 9.2. SIG(0) 1094 SIG(0) [RFC2931] similarly also provides a mechanism to digitally 1095 sign a DNS message but uses public key authentication, where the 1096 public keys are stored in DNS as KEY RRs and a private key is stored 1097 at the signer. 1099 Properties: Data origin authentication 1101 9.3. TLS 1103 9.3.1. Opportunistic TLS 1105 Opportunistic TLS for DoT is defined in [RFC8310] and can provide a 1106 defense against passive surveillance, providing on-the-wire 1107 confidentiality. Essentially 1109 o clients that know authentication information for a server SHOULD 1110 try to authenticate the server 1112 o however they MAY fallback to using TLS without authentication and 1114 o they MAY fallback to using cleartext if TLS is not available. 1116 As such it does not offer a defense against active attacks (e.g. a 1117 MitM attack on the connection from client to server), and is not 1118 considered as useful for XoT. 1120 Properties: None guaranteed. 1122 9.3.2. Strict TLS 1124 Strict TLS for DoT [RFC8310] requires that a client is configured 1125 with an authentication domain name (and/or SPKI pinset) that MUST be 1126 used to authenticate the TLS handshake with the server. If 1127 authentication of the server fails, the client will not proceed with 1128 the connection. This provides a defense for the client against 1129 active surveillance, providing client-to-server authentication and 1130 end-to-end channel confidentiality. 1132 Properties: Channel confidentiality and authentication (of the 1133 server). 1135 9.3.3. Mutual TLS 1137 This is an extension to Strict TLS [RFC8310] which requires that a 1138 client is configured with an authentication domain name (and/or SPKI 1139 pinset) and a client certificate. The client offers the certificate 1140 for authentication by the server and the client can authentic the 1141 server the same way as in Strict TLS. This provides a defense for 1142 both parties against active surveillance, providing bi-directional 1143 authentication and end-to-end channel confidentiality. 1145 Properties: Channel confidentiality and mutual authentication. 1147 9.4. IP Based ACL on the Primary 1149 Most DNS server implementations offer an option to configure an IP 1150 based Access Control List (ACL), which is often used in combination 1151 with TSIG based ACLs to restrict access to zone transfers on primary 1152 servers on a per query basis. 1154 This is also possible with XoT but it must be noted that, as with 1155 TCP, the implementation of such an ACL cannot be enforced on the 1156 primary until an XFR request is received on an established 1157 connection. 1159 As discussed in Appendix A an IP based per connection ACL could also 1160 be implemented where only TLS connections from recognized secondaries 1161 are accepted. 1163 Properties: Channel authentication of the client. 1165 9.5. ZONEMD 1167 For completeness, we also describe Message Digest for DNS Zones 1168 (ZONEMD) [I-D.ietf-dnsop-dns-zone-digest] here. The message digest 1169 is a mechanism that can be used to verify the content of a standalone 1170 zone. It is designed to be independent of the transmission channel 1171 or mechanism, allowing a general consumer of a zone to do origin 1172 authentication of the entire zone contents. Note that the current 1173 version of [I-D.ietf-dnsop-dns-zone-digest] states: 1175 "As specified herein, ZONEMD is impractical for large, dynamic zones 1176 due to the time and resources required for digest calculation. 1177 However, The ZONEMD record is extensible so that new digest schemes 1178 may be added in the future to support large, dynamic zones." 1180 It is complementary but orthogonal the above mechanisms; and can be 1181 used in conjunction with XoT but is not considered further here. 1183 10. XoT authentication 1185 It is noted that zone transfer scenarios can vary from a simple 1186 single primary/secondary relationship where both servers are under 1187 the control of a single operator to a complex hierarchical structure 1188 which includes proxies and multiple operators. Each deployment 1189 scenario will require specific analysis to determine which 1190 combination of authentication methods are best suited to the 1191 deployment model in question. 1193 The XoT authentication requirement specified in Section 7.4 addresses 1194 the issue of ensuring that the transfers is encrypted between the two 1195 endpoints directly involved in the current transfers. The following 1196 table summarized the properties of a selection of the mechanisms 1197 discussed in Section 9. The two letter acronyms for the properties 1198 are used below and (S) indicates the secondary and (P) indicates the 1199 primary. 1201 +----------------+-------+-------+-------+-------+-------+-------+ 1202 | Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) | 1203 +----------------+-------+-------+-------+-------+-------+-------+ 1204 | Strict TLS | | Y | Y | | Y | | 1205 | Mutual TLS | | Y | Y | | Y | Y | 1206 | ACL on primary | | | | | | Y | 1207 | TSIG | Y | | | Y | | | 1208 +----------------+-------+-------+-------+-------+-------+-------+ 1210 Table 1: Properties of Authentication methods for XoT 1212 Based on this analysis it can be seen that: 1214 o Using just mutual TLS can be considered a standalone solution 1215 since both end points are authenticated 1217 o Using Strict TLS and an IP based ACL on the primary also provides 1218 authentication of both end points 1220 o Additional use of TSIG (or equally SIG(0)) can also provide data 1221 origin authentication which might be desirable for deployments 1222 that include a proxy between the secondary and primary, but is not 1223 part of the XoT requirement because it does nothing to guarantee 1224 channel confidentiality or authentication. 1226 11. Policies for Both AXoT and IXoT 1228 Whilst the protection of the zone contents in a transfer between two 1229 end points can be provided by the XoT protocol, the protection of all 1230 the transfers of a given zone requires operational administration and 1231 policy management. 1233 We call the entire group of servers involved in XFR for a particular 1234 set of zones (all the primaries and all the secondaries) the 1235 'transfer group'. 1237 Within any transfer group both AXFRs and IXFRs for a zone MUST all 1238 use the same policy, e.g., if AXFRs use AXoT all IXFRs MUST use IXoT. 1240 In order to assure the confidentiality of the zone information, the 1241 entire transfer group MUST have a consistent policy of requiring 1242 confidentiality. If any do not, this is a weak link for attackers to 1243 exploit. 1245 An individual zone transfer is not considered protected by XoT unless 1246 both the client and server are configured to use only XoT and the 1247 overall zone transfer is not considered protected until all members 1248 of the transfer group are configured to use only XoT with all other 1249 transfers servers (see Section 12). 1251 A XoT policy should specify 1253 o What kind of TLS is required (Strict or Mutual TLS) 1255 o or if an IP based ACL is required. 1257 o (optionally) if TSIG/SIG(0) is required 1259 Since this may require configuration of a number of servers who may 1260 be under the control of different operators the desired consistency 1261 could be hard to enforce and audit in practice. 1263 Certain aspects of the Policies can be relatively easily tested 1264 independently, e.g., by requesting zone transfers without TSIG, from 1265 unauthorized IP addresses or over cleartext DNS. Other aspects such 1266 as if a secondary will accept data without a TSIG digest or if 1267 secondaries are using Strict as opposed to Opportunistic TLS are more 1268 challenging. 1270 The mechanics of co-ordinating or enforcing such policies are out of 1271 the scope of this document but may be the subject of future 1272 operational guidance. 1274 12. Implementation Considerations 1276 Server implementations may want to also offer options that allow ACLs 1277 on a zone to specify that a specific client can use either XoT or 1278 TCP. This would allow for flexibility while clients are migrating to 1279 XoT. 1281 Client implementations may similarly want to offer options to cater 1282 for the multi-primary case where the primaries are migrating to XoT. 1284 Such configuration options MUST only be used in a 'migration mode' 1285 though, and therefore should be used with care. 1287 It is noted that use of a TLS proxy in front of the primary server is 1288 a simple deployment solution that can enable server side XoT. 1290 13. IANA Considerations 1292 None. 1294 14. Implementation Status 1296 [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] This section records 1297 the status of known implementations of the protocol defined by this 1298 specification at the time of posting of this Internet-Draft, and is 1299 based on a proposal described in [RFC7942]. 1301 A summary of current behavior and implementation status can be found 1302 here: XoT implementation status [1] 1304 Specific recent activity includes: 1306 1. The 1.9.2 version of Unbound [2] includes an option to perform 1307 AXoT (instead of AXFR-over-TCP). 1309 2. There are currently open pull requests against NSD to implement 1310 1. Connection re-use by default during XFR-over-TCP [3] 1312 2. Client side XFR-over-TLS [4] 1314 3. Version 9.17.7 of BIND contained an initial implementation of 1315 DoT, implementation of XoT is planned for early 2021 [5] 1317 Both items 1. and 2.2. listed above require the client (secondary) to 1318 authenticate the server (primary) using a configured authentication 1319 domain name if XoT is used. 1321 15. Security Considerations 1323 This document specifies a security measure against a DNS risk: the 1324 risk that an attacker collects entire DNS zones through eavesdropping 1325 on clear text DNS zone transfers. 1327 This does not mitigate: 1329 o the risk that some level of zone activity might be inferred by 1330 observing zone transfer sizes and timing on encrypted connections 1331 (even with padding applied), in combination with obtaining SOA 1332 records by directly querying authoritative servers. 1334 o the risk that hidden primaries might be inferred or identified via 1335 observation of encrypted connections. 1337 o the risk of zone contents being obtained via zone enumeration 1338 techniques. 1340 Security concerns of DoT are outlined in [RFC7858] and [RFC8310]. 1342 16. Acknowledgements 1344 The authors thank Tony Finch, Benno Overeinder, Shumon Huque and Tim 1345 Wicinski and many other members of DPRIVE for review and discussions. 1347 The authors particularly thank Peter van Dijk, Ondrej Sury, Brian 1348 Dickson and several other open source DNS implementors for valuable 1349 discussion and clarification on the issue associated with pipelining 1350 XFR queries and handling out-of-order/intermingled responses. 1352 17. Contributors 1354 Significant contributions to the document were made by: 1356 Han Zhang 1357 Salesforce 1358 San Francisco, CA 1359 United States 1361 Email: hzhang@salesforce.com 1363 18. Changelog 1365 draft-ietf-dprive-xfr-over-tls-07 1367 o Reference RFC7942 in the implementation status section 1369 o Convert the URIs that will remain on publication to references 1371 o Correct typos in acknowledgments 1373 draft-ietf-dprive-xfr-over-tls-06 1375 o Update text relating to pipelining and connection reuse after WGLC 1376 comments. 1378 o Add link to implementation status matrix 1380 o Various typos 1382 draft-ietf-dprive-xfr-over-tls-05 1384 o Remove the open questions that received no comments. 1386 o Add more detail to the implementation section 1388 draft-ietf-dprive-xfr-over-tls-04 1390 o Add Github repository 1392 o Fix typos and references and improve layout. 1394 draft-ietf-dprive-xfr-over-tls-03 1396 o Remove propose to use ALPN 1398 o Clarify updates to both RFC1995 and RFC5936 by adding specific 1399 sections on this 1401 o Add a section on the threat model 1403 o Convert all SVG diagrams to ASCII art 1405 o Add discussions on concurrency limits 1406 o Add discussions on Extended DNS error codes 1408 o Re-work authentication requirements and discussion 1410 o Add appendix discussion TLS connection management 1412 draft-ietf-dprive-xfr-over-tls-02 1414 o Significantly update descriptions for both AXoT and IXoT for 1415 message and connection handling taking into account previous 1416 specifications in more detail 1418 o Add use of APLN and limitations on traffic on XoT connections. 1420 o Add new discussions of padding for both AXoT and IXoT 1422 o Add text on SIG(0) 1424 o Update security considerations 1426 o Move multi-primary considerations to earlier as they are related 1427 to connection handling 1429 draft-ietf-dprive-xfr-over-tls-01 1431 o Minor editorial updates 1433 o Add requirement for TLS 1.3. or later 1435 draft-ietf-dprive-xfr-over-tls-00 1437 o Rename after adoption and reference update. 1439 o Add placeholder for SIG(0) discussion 1441 o Update section on ZONEMD 1443 draft-hzpa-dprive-xfr-over-tls-02 1445 o Substantial re-work of the document. 1447 draft-hzpa-dprive-xfr-over-tls-01 1449 o Editorial changes, updates to references. 1451 draft-hzpa-dprive-xfr-over-tls-00 1453 o Initial commit 1455 19. References 1457 19.1. Normative References 1459 [I-D.vcelak-nsec5] 1460 Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and 1461 D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of 1462 Existence", draft-vcelak-nsec5-08 (work in progress), 1463 December 2018. 1465 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1466 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1467 . 1469 [RFC1035] Mockapetris, P., "Domain names - implementation and 1470 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1471 November 1987, . 1473 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1474 DOI 10.17487/RFC1995, August 1996, . 1477 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1478 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1479 August 1996, . 1481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1482 Requirement Levels", BCP 14, RFC 2119, 1483 DOI 10.17487/RFC2119, March 1997, . 1486 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 1487 Wellington, "Secret Key Transaction Authentication for DNS 1488 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 1489 . 1491 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1492 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1493 . 1495 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1496 Morris, J., Hansen, M., and R. Smith, "Privacy 1497 Considerations for Internet Protocols", RFC 6973, 1498 DOI 10.17487/RFC6973, July 2013, . 1501 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 1502 DOI 10.17487/RFC7626, August 2015, . 1505 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1506 D. Wessels, "DNS Transport over TCP - Implementation 1507 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1508 . 1510 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 1511 edns-tcp-keepalive EDNS0 Option", RFC 7828, 1512 DOI 10.17487/RFC7828, April 2016, . 1515 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1516 and P. Hoffman, "Specification for DNS over Transport 1517 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1518 2016, . 1520 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1521 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1522 May 2017, . 1524 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1525 for DNS over TLS and DNS over DTLS", RFC 8310, 1526 DOI 10.17487/RFC8310, March 2018, . 1529 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1530 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1531 . 1533 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1534 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1535 January 2019, . 1537 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 1538 Lawrence, "Extended DNS Errors", RFC 8914, 1539 DOI 10.17487/RFC8914, October 2020, . 1542 19.2. Informative References 1544 [BIND] ISC, "BIND 9", 2021, . 1546 [I-D.ietf-dnsop-dns-zone-digest] 1547 Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. 1548 Hardaker, "Message Digest for DNS Zones", draft-ietf- 1549 dnsop-dns-zone-digest-14 (work in progress), October 2020. 1551 [I-D.ietf-dprive-dnsoquic] 1552 Huitema, C., Mankin, A., and S. Dickinson, "Specification 1553 of DNS over Dedicated QUIC Connections", draft-ietf- 1554 dprive-dnsoquic-01 (work in progress), October 2020. 1556 [I-D.ietf-dprive-phase2-requirements] 1557 Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS 1558 Privacy Requirements for Exchanges between Recursive 1559 Resolvers and Authoritative Servers", draft-ietf-dprive- 1560 phase2-requirements-02 (work in progress), November 2020. 1562 [I-D.ietf-tls-esni] 1563 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1564 Encrypted Client Hello", draft-ietf-tls-esni-09 (work in 1565 progress), December 2020. 1567 [I-D.vandijk-dprive-ds-dot-signal-and-pin] 1568 Dijk, P., Geuze, R., and E. Bretelle, "Signalling 1569 Authoritative DoT support in DS records, with key 1570 pinning", draft-vandijk-dprive-ds-dot-signal-and-pin-01 1571 (work in progress), July 2020. 1573 [nist-guide] 1574 Chandramouli, R. and S. Rose, "Secure Domain Name System 1575 (DNS) Deployment Guide", 2013, 1576 . 1579 [NSD] NLnet Labs, "NSD", 2021, 1580 . 1582 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1583 DOI 10.17487/RFC1982, August 1996, . 1586 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1587 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 1588 2000, . 1590 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1591 Security (DNSSEC) Hashed Authenticated Denial of 1592 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1593 . 1595 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1596 for DNS (EDNS(0))", STD 75, RFC 6891, 1597 DOI 10.17487/RFC6891, April 2013, . 1600 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1601 Code: The Implementation Status Section", BCP 205, 1602 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1603 . 1605 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1606 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1607 . 1609 19.3. URIs 1611 [1] https://dnsprivacy.org/wiki/display/DP/ 1612 DNS+Privacy+Implementation+Status#DNSPrivacyImplementationStatus- 1613 XFR/XoTImplementationstatus 1615 [2] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ 1616 Changelog 1618 [3] https://github.com/NLnetLabs/nsd/pull/145 1620 [4] https://github.com/NLnetLabs/nsd/pull/149 1622 [5] https://gitlab.isc.org/isc-projects/bind9/-/issues/1784 1624 Appendix A. XoT server connection handling 1626 For completeness, it is noted that an earlier version of the 1627 specification suggested using a XoT specific ALPN to negotiate TLS 1628 connections that supported only a limited set of queries (SOA, XRFs) 1629 however this did not gain support. Reasons given included additional 1630 code complexity and proxies having no natural way to forward the ALPN 1631 signal to DNS nameservers over TCP connections. 1633 A.1. Only listen on TLS on a specific IP address 1635 Obviously a nameserver which hosts a zone and services queries for 1636 the zone on an IP address published in an NS record may wish to use a 1637 separate IP address for listening on TLS for XoT, only publishing 1638 that address to its secondaries. 1640 Pros: Probing of the public IP address will show no support for TLS. 1641 ACLs will prevent zone transfer on all transports on a per query 1642 basis. 1644 Cons: Attackers passively observing traffic will still be able to 1645 observe TLS connections to the separate address. 1647 A.2. Client specific TLS acceptance 1649 Primaries that include IP based ACLs and/or mutual TLS in their 1650 authentication models have the option of only accepting TLS 1651 connections from authorized clients. This could be implemented using 1652 a proxy or directly in DNS implementation. 1654 Pros: Connection management happens at setup time. The maximum 1655 number of TLS connections a server will have to support can be easily 1656 assessed. Once the connection is accepted the server might well be 1657 willing to answer any query on that connection since it is coming 1658 from a configured secondary and a specific response policy on the 1659 connection may not be needed (see below). 1661 Cons: Currently, none of the major open source DNS authoritative 1662 implementations support such an option. 1664 A.3. SNI based TLS acceptance 1666 Primaries could also choose to only accept TLS connections based on 1667 an SNI that was published only to their secondaries. 1669 Pros: Reduces the number of accepted connections. 1671 Cons: As above. For SNIs sent in the clear, this would still allow 1672 attackers passively observing traffic to potentially abuse this 1673 mechanism. The use of Encrypted Client Hello [I-D.ietf-tls-esni] may 1674 be of use here. 1676 A.4. TLS specific response policies 1678 Some primaries might rely on TSIG/SIG(0) combined with per-query IP 1679 based ACLs to authenticate secondaries. In this case the primary 1680 must accept all incoming TLS connections and then apply a TLS 1681 specific response policy on a per query basis. 1683 As an aside, whilst [RFC7766] makes a general purpose distinction to 1684 clients in the usage of connections (between regular queries and zone 1685 transfers) this is not strict and nothing in the DNS protocol 1686 prevents using the same connection for both types of traffic. Hence 1687 a server cannot know the intention of any client that connects to it, 1688 it can only inspect the messages it receives on such a connection and 1689 make per query decisions about whether or not to answer those 1690 queries. 1692 Example policies a XoT server might implement are: 1694 o strict: REFUSE all queries on TLS connections except SOA and 1695 authorized XFR requests 1697 o moderate: REFUSE all queries on TLS connections until one is 1698 received that is signed by a recognized TSIG/SIG(0) key, then 1699 answer all queries on the connection after that 1701 o complex: apply a heuristic to determine which queries on a TLS 1702 connections to REFUSE 1704 o relaxed: answer all non-XoT queries on all TLS connections with 1705 the same policy applied to TCP queries 1707 Pros: Allows for flexible behavior by the server that could be 1708 changed over time. 1710 Cons: The server must handle the burden of accepting all TLS 1711 connections just to perform XFRs with a small number of secondaries. 1712 Client behavior to REFUSED response is not clearly defined (see 1713 below). Currently, none of the major open source DNS authoritative 1714 implementations offer an option for different response policies in 1715 different transports (but could potentially be implemented using a 1716 proxy). 1718 A.4.1. SNI based response policies 1720 In a similar fashion, XoT servers might use the presence of an SNI in 1721 the client hello to determine which response policy to initially 1722 apply to the TLS connections. 1724 Pros: This has to potential to allow a clean distinction between a 1725 XoT service and any future DoT based service for answering recursive 1726 queries. 1728 Cons: As above. 1730 Authors' Addresses 1732 Willem Toorop 1733 NLnet Labs 1734 Science Park 400 1735 Amsterdam 1098 XH 1736 The Netherlands 1738 Email: willem@nlnetlabs.nl 1739 Sara Dickinson 1740 Sinodun IT 1741 Magdalen Centre 1742 Oxford Science Park 1743 Oxford OX4 4GA 1744 United Kingdom 1746 Email: sara@sinodun.com 1748 Shivan Sahib 1749 Salesforce 1750 Vancouver, BC 1751 Canada 1753 Email: ssahib@salesforce.com 1755 Pallavi Aras 1756 Salesforce 1757 Herndon, VA 1758 United States 1760 Email: paras@salesforce.com 1762 Allison Mankin 1763 Salesforce 1764 Herndon, VA 1765 United States 1767 Email: allison.mankin@gmail.com