idnits 2.17.1 draft-ietf-dprive-xfr-over-tls-10.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 1095 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 1631 -- Looks like a reference, but probably isn't: '2' on line 1635 -- Looks like a reference, but probably isn't: '3' on line 1638 -- Looks like a reference, but probably isn't: '4' on line 1640 -- Looks like a reference, but probably isn't: '5' on line 1642 == 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-10 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: Generic XFR-over-TLS mechanisms as specified in this document 247 AXoT: AXFR-over-TLS 249 IXoT: IXFR over-TLS 251 4. Threat Model 253 The threat model considered here is one where the current contents 254 and size of the zone are considered sensitive and should be protected 255 during transfer. 257 The threat model does not, however, consider the existence of a zone, 258 the act of zone transfer between two entities, nor the identities of 259 the nameservers hosting a zone (including both those acting as hidden 260 primaries/secondaries or directly serving the zone) as sensitive 261 information. The proposed mechanisms does not attempt to obscure 262 such information. The reasons for this include: 264 o much of this information can be obtained by various methods 265 including active scanning of the DNS 267 o an attacker who can monitor network traffic can relatively easily 268 infer relations between nameservers simply from traffic patterns, 269 even when some or all of the traffic is encrypted 271 It is noted that simply using XoT will indicate a desire by the zone 272 owner that the contents of the zone remain confidential and so could 273 be subject to blocking (e.g., via blocking of port 853) if an 274 attacker had such capabilities. However this threat is likely true 275 of any such mechanism that attempts to encrypt data passed between 276 nameservers, e.g., IPsec. 278 5. Design Considerations for XoT 280 o Confidentiality. Clearly using an encrypted transport for zone 281 transfers will defeat zone content leakage that can occur via 282 passive surveillance. 284 o Authentication. Use of single or mutual TLS (mTLS) authentication 285 (in combination with ACLs) can complement and potentially be an 286 alternative to TSIG. 288 o Performance. 290 * Existing AXFR and IXFR mechanisms have the burden of backwards 291 compatibility with older implementations based on the original 292 specifications in [RFC1034] and [RFC1035]. For example, some 293 older AXFR servers don't support using a TCP connection for 294 multiple AXFR sessions or XFRs of different zones because they 295 have not been updated to follow the guidance in [RFC5936]. Any 296 implementation of XoT would obviously be required to implement 297 optimized and interoperable transfers as described in 298 [RFC5936], e.g., transfer of multiple zones over one 299 connection. 301 * Current usage of TCP for IXFR is sub-optimal in some cases i.e. 302 connections are frequently closed after a single IXFR. 304 6. Connection and Data Flows in Existing XFR Mechanisms 306 The original specification for zone transfers in [RFC1034] and 307 [RFC1035] was based on a polling mechanism: a secondary performed a 308 periodic SOA query (based on the refresh timer) to determine if an 309 AXFR was required. 311 [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY 312 respectively, to provide for prompt propagation of zone updates. 313 This has largely replaced AXFR where possible, particularly for 314 dynamically updated zones. 316 [RFC5936] subsequently redefined the specification of AXFR to improve 317 performance and interoperability. 319 In this document we use the term "XFR mechanism" to describe the 320 entire set of message exchanges between a secondary and a primary 321 that concludes in a successful AXFR or IXFR request/response. This 322 set may or may not include 324 o NOTIFY messages 326 o SOA queries 328 o Fallback from IXFR to AXFR 330 o Fallback from IXFR-over-UDP to IXFR-over-TCP 332 The term is used to encompasses the range of permutations that are 333 possible and is useful to distinguish the 'XFR mechanism' from a 334 single XFR request/response exchange. 336 6.1. AXFR Mechanism 338 The figure below provides an outline of an AXFR mechanism including 339 NOTIFYs. 341 Secondary Primary 343 | NOTIFY | 344 | <-------------------------------- | UDP 345 | --------------------------------> | 346 | NOTIFY Response | 347 | | 348 | | 349 | SOA Request | 350 | --------------------------------> | UDP (or part of 351 | <-------------------------------- | a TCP session) 352 | SOA Response | 353 | | 354 | | 355 | | 356 | AXFR Request | --- 357 | --------------------------------> | | 358 | <-------------------------------- | | 359 | AXFR Response 1 | | 360 | (Zone data) | | 361 | | | 362 | <-------------------------------- | | TCP 363 | AXFR Response 2 | | Session 364 | (Zone data) | | 365 | | | 366 | <-------------------------------- | | 367 | AXFR Response 3 | | 368 | (Zone data) | --- 369 | | 371 Figure 1. AXFR Mechanism 373 1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP) 374 from the primary to the secondary. A secondary may also initiate 375 an AXFR based on a refresh timer or scheduled/triggered zone 376 maintenance. 378 2. The secondary will normally (but not always) make a SOA query to 379 the primary to obtain the serial number of the zone held by the 380 primary. 382 3. If the primary serial is higher than the secondaries serial 383 (using Serial Number Arithmetic [RFC1982]), the secondary makes 384 an AXFR request (over TCP) to the primary after which the AXFR 385 data flows in one or more AXFR responses on the TCP connection. 386 [RFC5936] defines this specific step as an 'AXFR session' i.e. as 387 an AXFR query message and the sequence of AXFR response messages 388 returned for it. 390 [RFC5936] re-specified AXFR providing additional guidance beyond that 391 provided in [RFC1034] and [RFC1035] and importantly specified that 392 AXFR must use TCP as the transport protocol. 394 Additionally, sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] provide 395 improved guidance for AXFR clients and servers with regard to re-use 396 of TCP connections for multiple AXFRs and AXFRs of different zones. 397 However [RFC5936] was constrained by having to be backwards 398 compatible with some very early basic implementations of AXFR. For 399 example, it outlines that the SOA query can also happen on this 400 connection. However, this can cause interoperability problems with 401 older implementations that support only the trivial case of one AXFR 402 per connection. 404 6.2. IXFR Mechanism 406 The figure below provides an outline of the IXFR mechanism including 407 NOTIFYs. 409 Secondary Primary 411 | NOTIFY | 412 | <-------------------------------- | UDP 413 | --------------------------------> | 414 | NOTIFY Response | 415 | | 416 | | 417 | SOA Request | 418 | --------------------------------> | UDP or TCP 419 | <-------------------------------- | 420 | SOA Response | 421 | | 422 | | 423 | | 424 | IXFR Request | 425 | --------------------------------> | UDP or TCP 426 | <-------------------------------- | 427 | IXFR Response | 428 | (Zone data) | 429 | | 430 | | --- 431 | IXFR Request | | 432 | --------------------------------> | | Retry over 433 | <-------------------------------- | | TCP if 434 | IXFR Response | | required 435 | (Zone data) | --- 437 Figure 2. IXFR Mechanism 439 1. An IXFR is normally (but not always) preceded by a NOTIFY (over 440 UDP) from the primary to the secondary. A secondary may also 441 initiate an IXFR based on a refresh timer or scheduled/triggered 442 zone maintenance. 444 2. The secondary will normally (but not always) make a SOA query to 445 the primary to obtain the serial number of the zone held by the 446 primary. 448 3. If the primary serial is higher than the secondaries serial 449 (using Serial Number Arithmetic [RFC1982]), the secondary makes 450 an IXFR request to the primary after which the primary sends an 451 IXFR response. 453 [RFC1995] specifies that Incremental Transfer may use UDP if the 454 entire IXFR response can be contained in a single DNS packet, 455 otherwise, TCP is used. In fact it says: 457 "Thus, a client should first make an IXFR query using UDP." 459 So there may be a fourth step above where the client falls back to 460 IXFR-over-TCP. There may also be a fourth step where the secondary 461 must fall back to AXFR because, e.g., the primary does not support 462 IXFR. 464 However it is noted that most widely used open source authoritative 465 nameserver implementations (including both [BIND] and [NSD]) do IXFR 466 using TCP by default in their latest releases. For BIND TCP 467 connections are sometimes used for SOA queries but in general they 468 are not used persistently and close after an IXFR is completed. 470 6.3. Data Leakage of NOTIFY and SOA Message Exchanges 472 This section attempts to presents a rationale for considering 473 encrypting the other messages in the XFR mechanism. 475 Since the SOA of the published zone can be trivially discovered by 476 simply querying the publicly available authoritative servers leakage 477 of this RR is not discussed in the following sections. 479 6.3.1. NOTIFY 481 Unencrypted NOTIFY messages identify configured secondaries on the 482 primary. 484 [RFC1996] also states: 486 "If ANCOUNT>0, then the answer section represents an 487 unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE). 489 But since the only supported QTYPE for NOTIFY is SOA, this does not 490 pose a potential leak. 492 6.3.2. SOA 494 For hidden primaries or secondaries the SOA response leaks only the 495 degree of SOA serial number lag of any downstream secondary. 497 7. Updates to existing specifications 499 For convenience, the term 'XFR-over-TCP' is used in this document to 500 mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements 501 that use that term update both [RFC1995] and [RFC5936], and 502 implicitly also apply to XoT. Differences in behavior specific to 503 XoT are discussed in Section 8. 505 Both [RFC1995] and [RFC5936] were published sometime before TCP was 506 considered a first class transport for DNS. [RFC1995], in fact, says 507 nothing with respect to optimizing IXFRs over TCP or re-using already 508 open TCP connections to perform IXFRs or other queries. Therefore, 509 there arguably is an implicit assumption that a TCP connection is 510 used for one and only one IXFR request. Indeed, many major open 511 source implementations currently take this approach. And whilst 512 [RFC5936] gives guidance on connection re-use for AXFR, it pre-dates 513 more recent specifications describing persistent TCP connections, 514 e.g., [RFC7766], [RFC7828] and AXFR implementations again often make 515 less than optimal use of open connections. 517 Given this, new implementations of XoT will clearly benefit from 518 specific guidance on TCP/TLS connection usage for XFR because this 519 will: 521 o result in more consistent XoT implementations with better 522 interoperability 524 o remove any need for XoT implementations to support legacy behavior 525 that XFR-over-TCP implementations have historically often 526 supported 528 Therefore this document updates both the previous specifications for 529 XFR-over-TCP to clarify that 531 o Implementations MUST use [RFC7766] (DNS Transport over TCP - 532 Implementation Requirements) to optimize the use of TCP 533 connections. 535 o Whilst RFC7766 states that 'DNS clients SHOULD pipeline their 536 queries' on TCP connections, it did not distinguish between XFRs 537 and other queries for this behavior. It is now recognized that 538 XFRs are not as latency sensitive as other queries, and can be 539 significantly more complex for clients to handle both because of 540 the large amount of state that must be kept and because there may 541 be multiple messages in the responses. For these reasons it is 542 clarified here that a valid reason for not pipelining queries is 543 when they are all XFR queries i.e. clients sending multiple XFRs 544 MAY choose not to pipeline those queries. Clients that do not 545 pipeline XFR queries, therefore, have no additional requirements 546 to handle out-of-order or intermingled responses (as described 547 later) since they will never receive them. 549 o Implementations SHOULD use [RFC7828] (The edns-tcp-keepalive EDNS0 550 Option) to manage persistent connections. 552 The following sections include detailed clarifications on the updates 553 to XFR behavior implied in [RFC7766] and how the use of [RFC7828] 554 applies specifically to XFR exchanges. It also discusses how IXFR 555 and AXFR can reuse the same TCP connection. 557 For completeness, we also mention here the recent specification of 558 extended DNS error (EDE) codes [RFC8914]. For zone transfers, when 559 returning REFUSED to a zone transfer request from an 'unauthorized' 560 client (e.g., where the client is not listed in an ACL for zone 561 transfers or does not sign the request with the correct TSIG key), 562 the extended DNS error code 18 (Prohibited) can also be sent. 564 7.1. Update to RFC1995 for IXFR-over-TCP 566 For clarity - an IXFR-over-TCP server compliant with this 567 specification MUST be able to handle multiple concurrent IXoT 568 requests on a single TCP connection (for the same and different 569 zones) and SHOULD send the responses as soon as they are available, 570 which might be out-of-order compared to the requests. 572 7.2. Update to RFC5936 for AXFR-over-TCP 574 For clarity - an AXFR-over-TCP server compliant with this 575 specification MUST be able to handle multiple concurrent AXoT 576 sessions on a single TCP connection (for the same and different 577 zones). The response streams for concurrent AXFRs MAY be 578 intermingled and AXFR-over-TCP clients compliant with this 579 specification which pipeline AXFR requests MUST be able to handle 580 this. 582 7.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP 584 7.3.1. Connection reuse 586 As specified, XFR-over-TCP clients SHOULD re-use any existing open 587 TCP connection when starting any new XFR request to the same primary, 588 and for issuing SOA queries, instead of opening a new connection. 589 The number of TCP connections between a secondary and primary SHOULD 590 be minimized (also see Section 7.4). 592 Valid reasons for not re-using existing connections might include: 594 o as already noted in [RFC7766], separate connections for different 595 zones might be preferred for operational reasons. In this case 596 the number of concurrent connections for zone transfers SHOULD be 597 limited to the total number of zones transferred between the 598 client and server. 600 o reaching a configured limit for the number of outstanding queries 601 or XFR requests allowed on a single TCP connection 603 o the message ID pool has already been exhausted on an open 604 connection 606 o a large number of timeouts or slow responses have occurred on an 607 open connection 609 o an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been 610 received from the server and the client is in the process of 611 closing the connection (see Section 7.3.4) 613 If no TCP connections are currently open, XFR clients MAY send SOA 614 queries over UDP or a new TCP connection. 616 7.3.2. AXFRs and IXFRs on the same connection 618 Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a 619 single TCP connection for both IXFR and AXFR requests. [RFC5936] 620 does make the general statement: 622 "Non-AXFR session traffic can also use an open TCP connection." 624 We clarify here that implementations capable of both AXFR and IXFR 625 and compliant with this specification SHOULD 627 o use the same TCP connection for both AXFR and IXFR requests to the 628 same primary 630 o pipeline such requests (if they pipeline XFR requests in general) 631 and MAY intermingle them 633 o send the response(s) for each request as soon as they are 634 available i.e. responses MAY be sent intermingled 636 7.3.3. XFR limits 638 The server MAY limit the number of concurrent IXFRs, AXFRs or total 639 XFR transfers in progress, or from a given secondary, to protect 640 server resources. Servers SHOULD return SERVFAIL if this limit is 641 hit, since it is a transient error and a retry at a later time might 642 succeed. 644 7.3.4. The edns-tcp-keepalive EDNS0 Option 646 XFR clients that send the edns-tcp-keepalive EDNS0 option on every 647 XFR request provide the server with maximum opportunity to update the 648 edns-tcp-keepalive timeout. The XFR server may use the frequency of 649 recent XFRs to calculate an average update rate as input to the 650 decision of what edns-tcp-keepalive timeout to use. If the server 651 does not support edns-tcp-keepalive the client MAY keep the 652 connection open for a few seconds ([RFC7766] recommends that servers 653 use timeouts of at least a few seconds). 655 Whilst the specification for EDNS0 [RFC6891] does not specifically 656 mention AXFRs, it does say 658 "If an OPT record is present in a received request, compliant 659 responders MUST include an OPT record in their respective 660 responses." 662 We clarify here that if an OPT record is present in a received AXFR 663 request, compliant responders MUST include an OPT record in each of 664 the subsequent AXFR responses. Note that this requirement, combined 665 with the use of edns-tcp-keepalive, enables AXFR servers to signal 666 the desire to close a connection (when existing transactions have 667 competed) due to low resources by sending an edns-tcp-keepalive EDNS0 668 option with a timeout of 0 on any AXFR response. This does not 669 signal that the AXFR is aborted, just that the server wishes to close 670 the connection as soon as possible. 672 7.3.5. Backwards compatibility 674 Certain legacy behaviors were noted in [RFC5936], with provisions 675 that implementations may want to offer options to fallback to legacy 676 behavior when interoperating with servers known not to support 677 [RFC5936]. For purposes of interoperability, IXFR and AXFR 678 implementations may want to continue offering such configuration 679 options, as well as supporting some behaviors that were 680 underspecified prior to this work (e.g., performing IXFR and AXFRs on 681 separate connections). However, XoT implementations should have no 682 need to do so. 684 7.4. Update to RFC7766 686 [RFC7766] made general implementation recommendations with regard to 687 TCP/TLS connection handling: 689 "To mitigate the risk of unintentional server overload, DNS 690 clients MUST take care to minimize the number of concurrent TCP 691 connections made to any individual server. It is RECOMMENDED 692 that for any given client/server interaction there SHOULD be no 693 more than one connection for regular queries, one for zone 694 transfers, and one for each protocol that is being used on top 695 of TCP (for example, if the resolver was using TLS). However, 696 it is noted that certain primary/ secondary configurations with 697 many busy zones might need to use more than one TCP connection 698 for zone transfers for operational reasons (for example, to 699 support concurrent transfers of multiple zones)." 701 Whilst this recommends a particular behavior for the clients using 702 TCP, it does not relax the requirement for servers to handle 'mixed' 703 traffic (regular queries and zone transfers) on any open TCP/TLS 704 connection. It also overlooks the potential that other transports 705 might want to take the same approach with regard to using separate 706 connections for different purposes. 708 This specification for XoT updates the guidance in [RFC7766] to 709 provide the same separation of connection purpose (regular queries 710 and zone transfers) for all transports being used on top of TCP. 712 Therefore, it is RECOMMENDED that for each protocol used on top of 713 TCP in any given client/server interaction there SHOULD be no more 714 than one connection for regular queries and one for zone transfers. 716 As an illustration, it could be imagined that in future such an 717 interaction could hypothetically include one or all of the following: 719 o one TCP connection for regular queries 721 o one TCP connection for zone transfers 723 o one TLS connection for regular queries 725 o one TLS connection for zone transfers 727 o one DoH connection for regular queries 729 o one DoH connection for zone transfers 731 Section 7.3.1 has provided specific details of reasons where more 732 than one connection for a given transport might be required for zone 733 transfers from a particular client. 735 8. XoT specification 737 8.1. TLS versions 739 For improved security all implementations of this specification MUST 740 use only TLS 1.3 [RFC8446] or later. 742 8.2. Port selection 744 The connection for XoT SHOULD be established using port 853, as 745 specified in [RFC7858], unless there is mutual agreement between the 746 secondary and primary to use a port other than port 853 for XoT. 747 There MAY be agreement to use different ports for AXoT and IXoT, or 748 for different zones. 750 8.3. High level XoT descriptions 752 It is useful to note that in XoT it is the secondary that initiates 753 the TLS connection to the primary for a XFR request, so that in terms 754 of connectivity the secondary is the TLS client and the primary the 755 TLS server. 757 The figure below provides an outline of the AXoT mechanism including 758 NOTIFYs. 760 Secondary Primary 762 | NOTIFY | 763 | <-------------------------------- | UDP 764 | --------------------------------> | 765 | NOTIFY Response | 766 | | 767 | | 768 | SOA Request | 769 | --------------------------------> | UDP (or part of 770 | <-------------------------------- | a TCP/TLS session) 771 | SOA Response | 772 | | 773 | | 774 | | 775 | AXFR Request | --- 776 | --------------------------------> | | 777 | <-------------------------------- | | 778 | AXFR Response 1 | | 779 | (Zone data) | | 780 | | | 781 | <-------------------------------- | | TLS 782 | AXFR Response 2 | | Session 783 | (Zone data) | | 784 | | | 785 | <-------------------------------- | | 786 | AXFR Response 3 | | 787 | (Zone data) | --- 788 | | 790 Figure 3. AXoT Mechanism 792 The figure below provides an outline of the IXoT mechanism including 793 NOTIFYs. 795 Secondary Primary 797 | NOTIFY | 798 | <-------------------------------- | UDP 799 | --------------------------------> | 800 | NOTIFY Response | 801 | | 802 | | 803 | SOA Request | 804 | --------------------------------> | UDP (or part of 805 | <-------------------------------- | a TCP/TLS session) 806 | SOA Response | 807 | | 808 | | 809 | | 810 | IXFR Request | --- 811 | --------------------------------> | | 812 | <-------------------------------- | | 813 | IXFR Response | | 814 | (Zone data) | | 815 | | | TLS 816 | | | session 817 | IXFR Request | | 818 | --------------------------------> | | 819 | <-------------------------------- | | 820 | IXFR Response | | 821 | (Zone data) | --- 823 Figure 4. IXoT Mechanism 825 8.4. XoT transfers 827 For a zone transfer between two end points to be considered protected 828 with XoT all XFR requests and response for that zone MUST be sent 829 over TLS connections where at a minimum: 831 o the client MUST authenticate the server by use of an 832 authentication domain name using a Strict Privacy Profile as 833 described in [RFC8310] 835 o the server MUST validate the client is authorized to request or 836 proxy a zone transfer by using one or both of the following: 838 * an IP based ACL (which can be either per-message or per- 839 connection) 841 * Mutual TLS (mTLS) 843 The server MAY also require a valid TSIG/SIG(0) signature, but this 844 alone is not sufficient to authenticate the client or server. 846 Authentication mechanisms are discussed in full in Section 10 and the 847 rationale for the above requirement in Section 11. Transfer group 848 policies are discussed in Section 12. 850 8.5. XoT connections 852 The details in Section 7 about, e.g., persistent connections and XFR 853 message handling are fully applicable to XoT connections as well. 854 However any behavior specified here takes precedence for XoT. 856 If no TLS connections are currently open, XoT clients MAY send SOA 857 queries over UDP or TCP, or TLS. 859 8.6. XoT vs ADoT 861 As noted earlier, there is currently no specification for encryption 862 of connections from recursive resolvers to authoritative servers. 863 Some authoritatives are experimenting with ADoT and opportunistic 864 encryption has also been raised as a possibility; it is therefore 865 highly likely that use of encryption by authoritative servers will 866 evolve in the coming years. 868 This raises questions in the short term with regard to TLS connection 869 and message handling for authoritative servers. In particular, there 870 is likely to be a class of authoritatives that wish to use XoT in the 871 near future with a small number of configured secondaries but that do 872 wish to support DoT for regular queries from recursive in that same 873 time frame. These servers have to potentially cope with probing and 874 direct queries from recursives and from test servers, and also 875 potential attacks that might wish to make use of TLS to overload the 876 server. 878 [RFC5936] clearly states that non-AXFR session traffic can use an 879 open TCP connection, however, this requirement needs to be re- 880 evaluated when considering applying the same model to XoT. Proposing 881 that a server should also start responding to all queries received 882 over TLS just because it has enabled XoT would be equivalent to 883 defining a form of authoritative DoT. This specification does not 884 propose that, but it also does not prohibit servers from answering 885 queries unrelated to XFR exchanges over TLS. Rather, this 886 specification simply outlines in later sections: 888 o how XoT implementations should utilize EDE codes in response to 889 queries on TLS connections they are not willing to answer (see 890 Section 8.7) 892 o the operational and policy options that a XoT server operator has 893 with regard to managing TLS connections and messages (see 894 Appendix A) 896 8.7. Response RCODES 898 XoT clients and servers MUST implement EDE codes. If a XoT server 899 receives non-XoT traffic it is not willing to answer on a TLS 900 connection it SHOULD respond with the extended DNS error code 21 - 901 Not Supported [RFC8914]. XoT clients should not send any further 902 queries of this type to the server for a reasonable period of time 903 (for example, one hour) i.e., long enough that the server 904 configuration or policy might be updated. 906 Historically servers have used the REFUSED RCODE for many situations, 907 and so clients often had no detailed information on which to base an 908 error or fallback path when queries were refused. As a result the 909 client behavior could vary significantly. XoT servers that refuse 910 queries must cater for the fact that client behavior might vary from 911 continually retrying queries regardless of receiving REFUSED to every 912 query, or at the other extreme clients may decide to stop using the 913 server over any transport. This might be because those clients are 914 either non-XoT clients or do not implement EDE codes. 916 8.8. AXoT specifics 918 8.8.1. Padding AXoT responses 920 The goal of padding AXoT responses would be two fold: 922 o to obfuscate the actual size of the transferred zone to minimize 923 information leakage about the entire contents of the zone. 925 o to obfuscate the incremental changes to the zone between SOA 926 updates to minimize information leakage about zone update activity 927 and growth. 929 Note that the re-use of XoT connections for transfers of multiple 930 different zones complicates any attempt to analyze the traffic size 931 and timing to extract information. 933 It is noted here that, depending on the padding policies eventually 934 developed for XoT, the requirement to obfuscate the total zone size 935 might require a server to create 'empty' AXoT responses. That is, 936 AXoT responses that contain no RR's apart from an OPT RR containing 937 the EDNS(0) option for padding. For example, without this capability 938 the maximum size that a tiny zone could be padded to would 939 theoretically be limited if there had to be a minimum of 1 RR per 940 packet. 942 However, as with existing AXFR, the last AXoT response message sent 943 MUST contain the same SOA that was in the first message of the AXoT 944 response series in order to signal the conclusion of the zone 945 transfer. 947 [RFC5936] says: 949 "Each AXFR response message SHOULD contain a sufficient number 950 of RRs to reasonably amortize the per-message overhead, up to 951 the largest number that will fit within a DNS message (taking 952 the required content of the other sections into account, as 953 described below)." 955 'Empty' AXoT responses generated in order to meet a padding 956 requirement will be exceptions to the above statement. For 957 flexibility, future proofing and in order to guarantee support for 958 future padding policies, we state here that secondary implementations 959 MUST be resilient to receiving padded AXoT responses, including 960 'empty' AXoT responses that contain only an OPT RR containing the 961 EDNS(0) option for padding. 963 Recommendation of specific policies for padding AXoT responses are 964 out of scope for this specification. Detailed considerations of such 965 policies and the trade-offs involved are expected to be the subject 966 of future work. 968 8.9. IXoT specifics 970 8.9.1. Condensation of responses 972 [RFC1995] says condensation of responses is optional and MAY be done. 973 Whilst it does add complexity to generating responses it can 974 significantly reduce the size of responses. However any such 975 reduction might be offset by increased message size due to padding. 976 This specification does not update the optionality of condensation 977 for XoT responses. 979 8.9.2. Fallback to AXFR 981 Fallback to AXFR can happen, for example, if the server is not able 982 to provide an IXFR for the requested SOA. Implementations differ in 983 how long they store zone deltas and how many may be stored at any one 984 time. 986 Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD 987 request the AXFR on the already open XoT connection. 989 8.9.3. Padding of IXoT responses 991 The goal of padding IXoT responses would be to obfuscate the 992 incremental changes to the zone between SOA updates to minimize 993 information leakage about zone update activity and growth. Both the 994 size and timing of the IXoT responses could reveal information. 996 IXFR responses can vary in size greatly from the order of 100 bytes 997 for one or two record updates, to tens of thousands of bytes for 998 large dynamic DNSSEC signed zones. The frequency of IXFR responses 999 can also depend greatly on if and how the zone is DNSSEC signed. 1001 In order to guarantee support for future padding policies, we state 1002 here that secondary implementations MUST be resilient to receiving 1003 padded IXoT responses. 1005 Recommendation of specific policies for padding IXoT responses are 1006 out of scope for this specification. Detailed considerations of such 1007 policies and the trade-offs involved are expected to be the subject 1008 of future work. 1010 8.10. Name compression and maximum payload sizes 1012 It is noted here that name compression [RFC1035] can be used in XFR 1013 responses to reduce the size of the payload, however the maximum 1014 value of the offset that can be used in the name compression pointer 1015 structure is 16384. For some DNS implementations this limits the 1016 size of an individual XFR response used in practice to something 1017 around the order of 16kB. In principle, larger payload sizes can be 1018 supported for some responses with more sophisticated approaches 1019 (e.g., by pre-calculating the maximum offset required). 1021 Implementations may wish to offer options to disable name compression 1022 for XoT responses to enable larger payloads. This might be 1023 particularly helpful when padding is used since minimizing the 1024 payload size is not necessarily a useful optimization in this case 1025 and disabling name compression will reduce the resources required to 1026 construct the payload. 1028 9. Multi-primary Configurations 1030 This model can provide flexibility and redundancy particularly for 1031 IXFR. A secondary will receive one or more NOTIFY messages and can 1032 send an SOA to all of the configured primaries. It can then choose 1033 to send an XFR request to the primary with the highest SOA (or other 1034 criteria, e.g., RTT). 1036 When using persistent connections the secondary may have a XoT 1037 connection already open to one or more primaries. Should a secondary 1038 preferentially request an XFR from a primary to which it already has 1039 an open XoT connection or the one with the highest SOA (assuming it 1040 doesn't have a connection open to it already)? 1042 Two extremes can be envisaged here. The first one can be considered 1043 a 'preferred primary connection' model. In this case the secondary 1044 continues to use one persistent connection to a single primary until 1045 it has reason not to. Reasons not to might include the primary 1046 repeatedly closing the connection, long query/response RTTs on 1047 transfers or the SOA of the primary being an unacceptable lag behind 1048 the SOA of an alternative primary. 1050 The other extreme can be considered a 'parallel primary connection' 1051 model. Here a secondary could keep multiple persistent connections 1052 open to all available primaries and only request XFRs from the 1053 primary with the highest serial number. Since normally the number of 1054 secondaries and primaries in direct contact in a transfer group is 1055 reasonably low this might be feasible if latency is the most 1056 significant concern. 1058 Recommendation of a particular scheme is out of scope of this 1059 document but implementations are encouraged to provide configuration 1060 options that allow operators to make choices about this behavior. 1062 10. Authentication mechanisms 1064 To provide context to the requirements in section Section 8.4, this 1065 section provides a brief summary of some of the existing 1066 authentication and validation mechanisms (both transport independent 1067 and TLS specific) that are available when performing zone transfers. 1068 Section 11 then discusses in more details specifically how a 1069 combination of TLS authentication, TSIG and IP based ACLs interact 1070 for XoT. 1072 We classify the mechanisms based on the following properties: 1074 o 'Data Origin Authentication' (DO): Authentication that the DNS 1075 message originated from the party with whom credentials were 1076 shared, and of the data integrity of the message contents (the 1077 originating party may or may not be party operating the far end of 1078 a TCP/TLS connection in a 'proxy' scenario). 1080 o 'Channel Confidentiality' (CC): Confidentiality of the 1081 communication channel between the client and server (i.e. the two 1082 end points of a TCP/TLS connection) from passive surveillance. 1084 o 'Channel Authentication' (CA): Authentication of the identity of 1085 party to whom a TCP/TLS connection is made (this might not be a 1086 direct connection between the primary and secondary in a proxy 1087 scenario). 1089 10.1. TSIG 1091 TSIG [RFC8945] provides a mechanism for two or more parties to use 1092 shared secret keys which can then be used to create a message digest 1093 to protect individual DNS messages. This allows each party to 1094 authenticate that a request or response (and the data in it) came 1095 from the other party, even if it was transmitted over an unsecured 1096 channel or via a proxy. 1098 Properties: Data origin authentication 1100 10.2. SIG(0) 1102 SIG(0) [RFC2931] similarly also provides a mechanism to digitally 1103 sign a DNS message but uses public key authentication, where the 1104 public keys are stored in DNS as KEY RRs and a private key is stored 1105 at the signer. 1107 Properties: Data origin authentication 1109 10.3. TLS 1111 10.3.1. Opportunistic TLS 1113 Opportunistic TLS for DoT is defined in [RFC8310] and can provide a 1114 defense against passive surveillance, providing on-the-wire 1115 confidentiality. Essentially 1117 o clients that know authentication information for a server SHOULD 1118 try to authenticate the server 1120 o however they MAY fallback to using TLS without authentication and 1122 o they MAY fallback to using cleartext if TLS is not available. 1124 As such it does not offer a defense against active attacks (e.g., an 1125 on path active attacker on the connection from client to server), and 1126 is not considered as useful for XoT. 1128 Properties: None guaranteed. 1130 10.3.2. Strict TLS 1132 Strict TLS for DoT [RFC8310] requires that a client is configured 1133 with an authentication domain name (and/or SPKI pinset) that MUST be 1134 used to authenticate the TLS handshake with the server. If 1135 authentication of the server fails, the client will not proceed with 1136 the connection. This provides a defense for the client against 1137 active surveillance, providing client-to-server authentication and 1138 end-to-end channel confidentiality. 1140 Properties: Channel confidentiality and authentication (of the 1141 server). 1143 10.3.3. Mutual TLS 1145 This is an extension to Strict TLS [RFC8310] which requires that a 1146 client is configured with an authentication domain name (and/or SPKI 1147 pinset) and a client certificate. The client offers the certificate 1148 for authentication by the server and the client can authenticate the 1149 server the same way as in Strict TLS. This provides a defense for 1150 both parties against active surveillance, providing bi-directional 1151 authentication and end-to-end channel confidentiality. 1153 Properties: Channel confidentiality and mutual authentication. 1155 10.4. IP Based ACL on the Primary 1157 Most DNS server implementations offer an option to configure an IP 1158 based Access Control List (ACL), which is often used in combination 1159 with TSIG based ACLs to restrict access to zone transfers on primary 1160 servers on a per query basis. 1162 This is also possible with XoT but it must be noted that, as with 1163 TCP, the implementation of such an ACL cannot be enforced on the 1164 primary until an XFR request is received on an established 1165 connection. 1167 As discussed in Appendix A an IP based per connection ACL could also 1168 be implemented where only TLS connections from recognized secondaries 1169 are accepted. 1171 Properties: Channel authentication of the client. 1173 10.5. ZONEMD 1175 For completeness, we also describe Message Digest for DNS Zones 1176 (ZONEMD) [RFC8976] here. The message digest is a mechanism that can 1177 be used to verify the content of a standalone zone. It is designed 1178 to be independent of the transmission channel or mechanism, allowing 1179 a general consumer of a zone to do origin authentication of the 1180 entire zone contents. Note that the current version of [RFC8976] 1181 states: 1183 "As specified herein, ZONEMD is impractical for large, dynamic zones 1184 due to the time and resources required for digest calculation. 1185 However, The ZONEMD record is extensible so that new digest schemes 1186 may be added in the future to support large, dynamic zones." 1188 It is complementary but orthogonal the above mechanisms; and can be 1189 used in conjunction with XoT but is not considered further here. 1191 11. XoT authentication 1193 It is noted that zone transfer scenarios can vary from a simple 1194 single primary/secondary relationship where both servers are under 1195 the control of a single operator to a complex hierarchical structure 1196 which includes proxies and multiple operators. Each deployment 1197 scenario will require specific analysis to determine which 1198 combination of authentication methods are best suited to the 1199 deployment model in question. 1201 The XoT authentication requirement specified in Section 8.4 addresses 1202 the issue of ensuring that the transfers is encrypted between the two 1203 endpoints directly involved in the current transfers. The following 1204 table summarized the properties of a selection of the mechanisms 1205 discussed in Section 10. The two letter acronyms for the properties 1206 are used below and (S) indicates the secondary and (P) indicates the 1207 primary. 1209 +----------------+-------+-------+-------+-------+-------+-------+ 1210 | Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) | 1211 +----------------+-------+-------+-------+-------+-------+-------+ 1212 | Strict TLS | | Y | Y | | Y | | 1213 | Mutual TLS | | Y | Y | | Y | Y | 1214 | ACL on primary | | | | | | Y | 1215 | TSIG | Y | | | Y | | | 1216 +----------------+-------+-------+-------+-------+-------+-------+ 1218 Table 1: Properties of Authentication methods for XoT 1220 Based on this analysis it can be seen that: 1222 o Using just mutual TLS can be considered a standalone solution 1223 since both end points are authenticated 1225 o Using Strict TLS and an IP based ACL on the primary also provides 1226 authentication of both end points 1228 o Additional use of TSIG (or equally SIG(0)) can also provide data 1229 origin authentication which might be desirable for deployments 1230 that include a proxy between the secondary and primary, but is not 1231 part of the XoT requirement because it does nothing to guarantee 1232 channel confidentiality or authentication. 1234 12. Policies for Both AXoT and IXoT 1236 Whilst the protection of the zone contents in a transfer between two 1237 end points can be provided by the XoT protocol, the protection of all 1238 the transfers of a given zone requires operational administration and 1239 policy management. 1241 We call the entire group of servers involved in XFR for a particular 1242 set of zones (all the primaries and all the secondaries) the 1243 'transfer group'. 1245 Within any transfer group both AXFRs and IXFRs for a zone MUST all 1246 use the same policy, e.g., if AXFRs use AXoT then all IXFRs MUST use 1247 IXoT. 1249 In order to assure the confidentiality of the zone information, the 1250 entire transfer group MUST have a consistent policy of requiring 1251 confidentiality. If any do not, this is a weak link for attackers to 1252 exploit. 1254 An individual zone transfer is not considered protected by XoT unless 1255 both the client and server are configured to use only XoT and the 1256 overall zone transfer is not considered protected until all members 1257 of the transfer group are configured to use only XoT with all other 1258 transfers servers (see Section 13). 1260 A XoT policy should specify 1262 o What kind of TLS is required (Strict or Mutual TLS) 1264 o or if an IP based ACL is required. 1266 o (optionally) if TSIG/SIG(0) is required 1267 Since this may require configuration of a number of servers who may 1268 be under the control of different operators the desired consistency 1269 could be hard to enforce and audit in practice. 1271 Certain aspects of the Policies can be relatively easily tested 1272 independently, e.g., by requesting zone transfers without TSIG, from 1273 unauthorized IP addresses or over cleartext DNS. Other aspects such 1274 as if a secondary will accept data without a TSIG digest or if 1275 secondaries are using Strict as opposed to Opportunistic TLS are more 1276 challenging. 1278 The mechanics of co-ordinating or enforcing such policies are out of 1279 the scope of this document but may be the subject of future 1280 operational guidance. 1282 13. Implementation Considerations 1284 Server implementations may want to also offer options that allow ACLs 1285 on a zone to specify that a specific client can use either XoT or 1286 TCP. This would allow for flexibility while clients are migrating to 1287 XoT. 1289 Client implementations may similarly want to offer options to cater 1290 for the multi-primary case where the primaries are migrating to XoT. 1292 14. Operational Considerations 1294 If the options described in Section 13 are available, such 1295 configuration options MUST only be used in a 'migration mode', and 1296 therefore should be used with great care. 1298 It is noted that use of a TLS proxy in front of the primary server is 1299 a simple deployment solution that can enable server side XoT. 1301 15. IANA Considerations 1303 None. 1305 16. Implementation Status 1307 [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] This section records 1308 the status of known implementations of the protocol defined by this 1309 specification at the time of posting of this Internet-Draft, and is 1310 based on a proposal described in [RFC7942]. 1312 A summary of current behavior and implementation status can be found 1313 here: XoT implementation status [1] 1314 Specific recent activity includes: 1316 1. The 1.9.2 version of Unbound [2] includes an option to perform 1317 AXoT (instead of AXFR-over-TCP). 1319 2. There are currently open pull requests against NSD to implement 1321 1. Connection re-use by default during XFR-over-TCP [3] 1323 2. Client side XoT [4] 1325 3. Version 9.17.7 of BIND contained an initial implementation of 1326 DoT, implementation of XoT is planned for early 2021 [5] 1328 Both items 1. and 2.2. listed above require the client (secondary) to 1329 authenticate the server (primary) using a configured authentication 1330 domain name if XoT is used. 1332 17. Security Considerations 1334 This document specifies a security measure against a DNS risk: the 1335 risk that an attacker collects entire DNS zones through eavesdropping 1336 on clear text DNS zone transfers. 1338 This does not mitigate: 1340 o the risk that some level of zone activity might be inferred by 1341 observing zone transfer sizes and timing on encrypted connections 1342 (even with padding applied), in combination with obtaining SOA 1343 records by directly querying authoritative servers. 1345 o the risk that hidden primaries might be inferred or identified via 1346 observation of encrypted connections. 1348 o the risk of zone contents being obtained via zone enumeration 1349 techniques. 1351 Security concerns of DoT are outlined in [RFC7858] and [RFC8310]. 1353 18. Acknowledgements 1355 The authors thank Tony Finch, Benno Overeinder, Shumon Huque and Tim 1356 Wicinski and many other members of DPRIVE for review and discussions. 1358 The authors particularly thank Peter van Dijk, Ondrej Sury, Brian 1359 Dickson and several other open source DNS implementers for valuable 1360 discussion and clarification on the issue associated with pipelining 1361 XFR queries and handling out-of-order/intermingled responses. 1363 19. Contributors 1365 Significant contributions to the document were made by: 1367 Han Zhang 1368 Salesforce 1369 San Francisco, CA 1370 United States 1372 Email: hzhang@salesforce.com 1374 20. Changelog 1376 [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] 1378 draft-ietf-dprive-xfr-over-tls-10 1380 o Address issued raised from IETF Last Call 1382 draft-ietf-dprive-xfr-over-tls-09 1384 o Address issued raised in the AD review 1386 draft-ietf-dprive-xfr-over-tls-08 1388 o RFC2845 -> (obsoleted by) RFC8945 1390 o I-D.ietf-dnsop-dns-zone-digest -> RFC8976 1392 o Minor editorial changes + email update 1394 draft-ietf-dprive-xfr-over-tls-07 1396 o Reference RFC7942 in the implementation status section 1398 o Convert the URIs that will remain on publication to references 1400 o Correct typos in acknowledgments 1402 draft-ietf-dprive-xfr-over-tls-06 1404 o Update text relating to pipelining and connection reuse after WGLC 1405 comments. 1407 o Add link to implementation status matrix 1409 o Various typos 1410 o Remove the open questions that received no comments. 1412 o Add more detail to the implementation section 1414 draft-ietf-dprive-xfr-over-tls-04 1416 o Add Github repository 1418 o Fix typos and references and improve layout. 1420 draft-ietf-dprive-xfr-over-tls-03 1422 o Remove propose to use ALPN 1424 o Clarify updates to both RFC1995 and RFC5936 by adding specific 1425 sections on this 1427 o Add a section on the threat model 1429 o Convert all SVG diagrams to ASCII art 1431 o Add discussions on concurrency limits 1433 o Add discussions on Extended DNS error codes 1435 o Re-work authentication requirements and discussion 1437 o Add appendix discussion TLS connection management 1439 draft-ietf-dprive-xfr-over-tls-02 1441 o Significantly update descriptions for both AXoT and IXoT for 1442 message and connection handling taking into account previous 1443 specifications in more detail 1445 o Add use of APLN and limitations on traffic on XoT connections. 1447 o Add new discussions of padding for both AXoT and IXoT 1449 o Add text on SIG(0) 1451 o Update security considerations 1453 o Move multi-primary considerations to earlier as they are related 1454 to connection handling 1456 o Minor editorial updates 1458 o Add requirement for TLS 1.3. or later 1460 draft-ietf-dprive-xfr-over-tls-00 1462 o Rename after adoption and reference update. 1464 o Add placeholder for SIG(0) discussion 1466 o Update section on ZONEMD 1468 draft-hzpa-dprive-xfr-over-tls-02 1470 o Substantial re-work of the document. 1472 draft-hzpa-dprive-xfr-over-tls-01 1474 o Editorial changes, updates to references. 1476 draft-hzpa-dprive-xfr-over-tls-00 1478 o Initial commit 1480 21. References 1482 21.1. Normative References 1484 [I-D.ietf-dprive-rfc7626-bis] 1485 Wicinski, T., "DNS Privacy Considerations", draft-ietf- 1486 dprive-rfc7626-bis-08 (work in progress), October 2020. 1488 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1489 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1490 . 1492 [RFC1035] Mockapetris, P., "Domain names - implementation and 1493 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1494 November 1987, . 1496 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1497 DOI 10.17487/RFC1995, August 1996, . 1500 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1501 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1502 August 1996, . 1504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1505 Requirement Levels", BCP 14, RFC 2119, 1506 DOI 10.17487/RFC2119, March 1997, . 1509 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1510 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1511 . 1513 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1514 Morris, J., Hansen, M., and R. Smith, "Privacy 1515 Considerations for Internet Protocols", RFC 6973, 1516 DOI 10.17487/RFC6973, July 2013, . 1519 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1520 D. Wessels, "DNS Transport over TCP - Implementation 1521 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1522 . 1524 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 1525 edns-tcp-keepalive EDNS0 Option", RFC 7828, 1526 DOI 10.17487/RFC7828, April 2016, . 1529 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1530 and P. Hoffman, "Specification for DNS over Transport 1531 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1532 2016, . 1534 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1535 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1536 May 2017, . 1538 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1539 for DNS over TLS and DNS over DTLS", RFC 8310, 1540 DOI 10.17487/RFC8310, March 2018, . 1543 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1544 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1545 . 1547 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1548 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1549 January 2019, . 1551 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 1552 Lawrence, "Extended DNS Errors", RFC 8914, 1553 DOI 10.17487/RFC8914, October 2020, . 1556 [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., 1557 Gudmundsson, O., and B. Wellington, "Secret Key 1558 Transaction Authentication for DNS (TSIG)", STD 93, 1559 RFC 8945, DOI 10.17487/RFC8945, November 2020, 1560 . 1562 21.2. Informative References 1564 [BIND] ISC, "BIND 9", 2021, . 1566 [I-D.ietf-dprive-dnsoquic] 1567 Huitema, C., Mankin, A., and S. Dickinson, "Specification 1568 of DNS over Dedicated QUIC Connections", draft-ietf- 1569 dprive-dnsoquic-01 (work in progress), October 2020. 1571 [I-D.ietf-dprive-phase2-requirements] 1572 Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS 1573 Privacy Requirements for Exchanges between Recursive 1574 Resolvers and Authoritative Servers", draft-ietf-dprive- 1575 phase2-requirements-02 (work in progress), November 2020. 1577 [I-D.ietf-tls-esni] 1578 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1579 Encrypted Client Hello", draft-ietf-tls-esni-09 (work in 1580 progress), December 2020. 1582 [I-D.vcelak-nsec5] 1583 Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and 1584 D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of 1585 Existence", draft-vcelak-nsec5-08 (work in progress), 1586 December 2018. 1588 [nist-guide] 1589 Chandramouli, R. and S. Rose, "Secure Domain Name System 1590 (DNS) Deployment Guide", 2013, 1591 . 1594 [NSD] NLnet Labs, "NSD", 2021, 1595 . 1597 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1598 DOI 10.17487/RFC1982, August 1996, . 1601 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 1602 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 1603 2000, . 1605 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1606 Security (DNSSEC) Hashed Authenticated Denial of 1607 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1608 . 1610 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1611 for DNS (EDNS(0))", STD 75, RFC 6891, 1612 DOI 10.17487/RFC6891, April 2013, . 1615 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1616 Code: The Implementation Status Section", BCP 205, 1617 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1618 . 1620 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1621 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1622 . 1624 [RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. 1625 Hardaker, "Message Digest for DNS Zones", RFC 8976, 1626 DOI 10.17487/RFC8976, February 2021, . 1629 21.3. URIs 1631 [1] https://dnsprivacy.org/wiki/display/DP/ 1632 DNS+Privacy+Implementation+Status#DNSPrivacyImplementationStatus- 1633 XFR/XoTImplementationstatus 1635 [2] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ 1636 Changelog 1638 [3] https://github.com/NLnetLabs/nsd/pull/145 1640 [4] https://github.com/NLnetLabs/nsd/pull/149 1642 [5] https://gitlab.isc.org/isc-projects/bind9/-/issues/1784 1644 Appendix A. XoT server connection handling 1646 For completeness, it is noted that an earlier version of the 1647 specification suggested using a XoT specific ALPN to negotiate TLS 1648 connections that supported only a limited set of queries (SOA, XRFs) 1649 however this did not gain support. Reasons given included additional 1650 code complexity and proxies having no natural way to forward the ALPN 1651 signal to DNS nameservers over TCP connections. 1653 A.1. Only listen on TLS on a specific IP address 1655 Obviously a nameserver which hosts a zone and services queries for 1656 the zone on an IP address published in an NS record may wish to use a 1657 separate IP address for listening on TLS for XoT, only publishing 1658 that address to its secondaries. 1660 Pros: Probing of the public IP address will show no support for TLS. 1661 ACLs will prevent zone transfer on all transports on a per query 1662 basis. 1664 Cons: Attackers passively observing traffic will still be able to 1665 observe TLS connections to the separate address. 1667 A.2. Client specific TLS acceptance 1669 Primaries that include IP based ACLs and/or mutual TLS in their 1670 authentication models have the option of only accepting TLS 1671 connections from authorized clients. This could be implemented using 1672 a proxy or directly in DNS implementation. 1674 Pros: Connection management happens at setup time. The maximum 1675 number of TLS connections a server will have to support can be easily 1676 assessed. Once the connection is accepted the server might well be 1677 willing to answer any query on that connection since it is coming 1678 from a configured secondary and a specific response policy on the 1679 connection may not be needed (see below). 1681 Cons: Currently, none of the major open source DNS authoritative 1682 implementations support such an option. 1684 A.3. SNI based TLS acceptance 1686 Primaries could also choose to only accept TLS connections based on 1687 an SNI that was published only to their secondaries. 1689 Pros: Reduces the number of accepted connections. 1691 Cons: As above. For SNIs sent in the clear, this would still allow 1692 attackers passively observing traffic to potentially abuse this 1693 mechanism. The use of Encrypted Client Hello [I-D.ietf-tls-esni] may 1694 be of use here. 1696 A.4. TLS specific response policies 1698 Some primaries might rely on TSIG/SIG(0) combined with per-query IP 1699 based ACLs to authenticate secondaries. In this case the primary 1700 must accept all incoming TLS connections and then apply a TLS 1701 specific response policy on a per query basis. 1703 As an aside, whilst [RFC7766] makes a general purpose distinction to 1704 clients in the usage of connections (between regular queries and zone 1705 transfers) this is not strict and nothing in the DNS protocol 1706 prevents using the same connection for both types of traffic. Hence 1707 a server cannot know the intention of any client that connects to it, 1708 it can only inspect the messages it receives on such a connection and 1709 make per query decisions about whether or not to answer those 1710 queries. 1712 Example policies a XoT server might implement are: 1714 o strict: REFUSE all queries on TLS connections except SOA and 1715 authorized XFR requests 1717 o moderate: REFUSE all queries on TLS connections until one is 1718 received that is signed by a recognized TSIG/SIG(0) key, then 1719 answer all queries on the connection after that 1721 o complex: apply a heuristic to determine which queries on a TLS 1722 connections to REFUSE 1724 o relaxed: answer all non-XoT queries on all TLS connections with 1725 the same policy applied to TCP queries 1727 Pros: Allows for flexible behavior by the server that could be 1728 changed over time. 1730 Cons: The server must handle the burden of accepting all TLS 1731 connections just to perform XFRs with a small number of secondaries. 1732 Client behavior to REFUSED response is not clearly defined (see 1733 below). Currently, none of the major open source DNS authoritative 1734 implementations offer an option for different response policies in 1735 different transports (but could potentially be implemented using a 1736 proxy). 1738 A.4.1. SNI based response policies 1740 In a similar fashion, XoT servers might use the presence of an SNI in 1741 the client hello to determine which response policy to initially 1742 apply to the TLS connections. 1744 Pros: This has to potential to allow a clean distinction between a 1745 XoT service and any future DoT based service for answering recursive 1746 queries. 1748 Cons: As above. 1750 Authors' Addresses 1752 Willem Toorop 1753 NLnet Labs 1754 Science Park 400 1755 Amsterdam 1098 XH 1756 The Netherlands 1758 Email: willem@nlnetlabs.nl 1760 Sara Dickinson 1761 Sinodun IT 1762 Magdalen Centre 1763 Oxford Science Park 1764 Oxford OX4 4GA 1765 United Kingdom 1767 Email: sara@sinodun.com 1769 Shivan Sahib 1770 Salesforce 1771 Vancouver, BC 1772 Canada 1774 Email: shivankaulsahib@gmail.com 1776 Pallavi Aras 1777 Salesforce 1778 Herndon, VA 1779 United States 1781 Email: paras@salesforce.com 1782 Allison Mankin 1783 Salesforce 1784 Herndon, VA 1785 United States 1787 Email: allison.mankin@gmail.com