idnits 2.17.1 draft-ietf-dprive-xfr-over-tls-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1995, but the abstract doesn't seem to mention this, which it should. 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 (November 18, 2019) is 1619 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) == Missing Reference: 'RFC5836' is mentioned on line 193, but not defined -- Looks like a reference, but probably isn't: '1' on line 801 -- Looks like a reference, but probably isn't: '2' on line 804 -- Looks like a reference, but probably isn't: '3' on line 807 -- Looks like a reference, but probably isn't: '4' on line 809 == Missing Reference: 'RFC7828' is mentioned on line 356, but not defined -- Looks like a reference, but probably isn't: '5' on line 811 -- Looks like a reference, but probably isn't: '6' on line 814 -- Looks like a reference, but probably isn't: '7' on line 817 -- Looks like a reference, but probably isn't: '8' on line 821 == Outdated reference: A later version (-09) exists of draft-ietf-dprive-rfc7626-bis-02 ** Downref: Normative reference to an Informational draft: draft-ietf-dprive-rfc7626-bis (ref. 'I-D.ietf-dprive-rfc7626-bis') ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 6973 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) == Outdated reference: A later version (-14) exists of draft-ietf-dnsop-dns-zone-digest-02 -- Obsolete informational reference (is this intentional?): RFC 5953 (Obsoleted by RFC 6353) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive H. Zhang 3 Internet-Draft P. Aras 4 Updates: 1995 (if approved) Salesforce 5 Intended status: Standards Track W. Toorop 6 Expires: May 21, 2020 NLnet Labs 7 S. Dickinson 8 Sinodun IT 9 A. Mankin 10 Salesforce 11 November 18, 2019 13 DNS Zone Transfer-over-TLS 14 draft-ietf-dprive-xfr-over-tls-00 16 Abstract 18 DNS zone transfers are transmitted in clear text, which gives 19 attackers the opportunity to collect the content of a zone by 20 eavesdropping on network connections. The DNS Transaction Signature 21 (TSIG) mechanism is specified to restrict direct zone transfer to 22 authorized clients only, but it does not add confidentiality. This 23 document specifies use of DNS-over-TLS to prevent zone contents 24 collection via passive monitoring of zone transfers. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 21, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 4 63 4. Connection and Data Flows in Existing XFR Mechanisms . . . . 5 64 4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 6 66 4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 7 67 4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5. Connection and Data Flows in XoT . . . . . . . . . . . . . . 8 70 5.1. Performance Considerations . . . . . . . . . . . . . . . 8 71 5.2. AXoT mechanism . . . . . . . . . . . . . . . . . . . . . 8 72 5.3. IXoT mechanism . . . . . . . . . . . . . . . . . . . . . 9 73 5.3.1. Fallback to AXFR . . . . . . . . . . . . . . . . . . 10 74 6. Zone Transfer with DoT - Authentication . . . . . . . . . . . 10 75 6.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 6.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 6.3.1. Opportunistic . . . . . . . . . . . . . . . . . . . . 10 79 6.3.2. Strict . . . . . . . . . . . . . . . . . . . . . . . 10 80 6.3.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 10 81 6.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 11 82 6.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 6.6. Comparison of Authentication Methods . . . . . . . . . . 11 84 7. Policies for Both AXFR and IXFR . . . . . . . . . . . . . . . 12 85 8. Multi-primary Configurations . . . . . . . . . . . . . . . . 13 86 9. Implementation Considerations . . . . . . . . . . . . . . . . 14 87 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 91 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 15.1. Normative References . . . . . . . . . . . . . . . . . . 15 94 15.2. Informative References . . . . . . . . . . . . . . . . . 17 95 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 99 1. Introduction 101 DNS has a number of privacy vulnerabilities, as discussed in detail 102 in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver 103 query privacy has received the most attention to date. There are now 104 standards track documents for three encryption capabilities for stub 105 to recursive queries and more work going on to guide deployment of 106 specifically DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) 107 [RFC8484]. 109 [I-D.ietf-dprive-rfc7626-bis] established that stub client DNS query 110 transactions are not public and needed protection, but on zone 111 transfer [RFC1995] [RFC5936] it says only: 113 "Privacy risks for the holder of a zone (the risk that someone gets 114 the data) are discussed in [RFC5936] and [RFC5155]." 116 In what way is exposing the full contents of a zone a privacy risk? 117 The contents of the zone could include information such as names of 118 persons used in names of hosts. Best practice is not to use personal 119 information for domain names, but many such domain names exist. 120 There may also be regulatory, policy or other reasons why the zone 121 contents in full must be treated as private. 123 Neither of the RFCs mentioned in [I-D.ietf-dprive-rfc7626-bis] 124 contemplates the risk that someone gets the data through 125 eavesdropping on network connections, only via enumeration or 126 unauthorized transfer as described in the following paragraphs. 128 [RFC5155] specifies NSEC3 to prevent zone enumeration, which is when 129 queries for the authenticated denial of existences records of DNSSEC 130 allow a client to walk through the entire zone. Note that the need 131 for this protection also motivates NSEC5 [I-D.vcelak-nsec5]; zone 132 walking is now possible with NSEC3 due to crypto-breaking advances, 133 and NSEC5 is a response to this problem. 135 [RFC5155] does not address data obtained outside zone enumeration 136 (nor does [I-D.vcelak-nsec5]). Preventing eavesdropping of zone 137 transfers (this draft) is orthogonal to preventing zone enumeration, 138 though they aim to protect the same information. 140 [RFC5936] specifies using TSIG [RFC2845] for authorization of the 141 clients of a zone transfer and for data integrity, but does not 142 express any need for confidentiality, and TSIG does not offer 143 encryption. Some operators use SSH tunneling or IPSec to encrypt the 144 transfer data. 146 Because the AXFR zone transfer is typically carried out-over-TCP from 147 authoritative DNS protocol implementations, encrypting AXFR using 148 DNS-over-TLS [RFC7858] seems like a simple step forward. This 149 document specifies how to use DoT to prevent zone collection from 150 zone transfers, including discussion of approaches for IXFR, which 151 uses UDP or TCP. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 Privacy terminology is as described in Section 3 of [RFC6973]. 163 Note that in this document we choose to use the terms 'primary' and 164 'secondary' for two servers engaged in zone transfers. 166 DNS terminology is as described in [RFC8499]. 168 DoT: DNS-over-TLS as specified in [RFC7858] 170 DoH: DNS-over-HTTPS as specified in [RFC8484] 172 XoT: Generic XFR-over-TLS mechanisms as specified in this document 174 AXoT: AXFR-over-TLS 176 IXoT: IXFR over-TLS 178 3. Use Cases for XFR-over-TLS 180 o Confidentiality. Clearly using an encrypted transport for zone 181 transfers will defeat zone content leakage that can occur via 182 passive surveillance. 184 o Authentication. Use of single or mutual TLS authentication (in 185 combination with ACLs) can complement and potentially be an 186 alternative to TSIG. 188 o Performance. Existing AXFR and IXFR mechanisms have the burden of 189 backwards compatibility with older implementations based on the 190 original specifications in [RFC1034] and [RFC1035]. For example, 191 some older AXFR servers don't support using a TCP connection for 192 multiple AXFR sessions or XFRs of different zones because they 193 have not been updated to follow the guidance in [RFC5836]. Any 194 implementation of XFR-over-TLS would obviously be required to 195 implement optimized and interoperable transfers as described in 196 [RFC5936] e.g. transfer of multiple zones-over-one connection. 198 o Performance. Current usage of TCP for IXFR is sub-optimal in some 199 cases i.e. connections are frequently closed after a single IXFR. 201 4. Connection and Data Flows in Existing XFR Mechanisms 203 The original specification for zone transfers in [RFC1034] and 204 [RFC1035] was based on a polling mechanism: a secondary performed a 205 periodic SOA query (based on the refresh timer) to determine if an 206 AXFR was required. 208 [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY 209 respectively, to provide for prompt propagation of zone updates. 210 This has largely replaced AXFR where possible, particularly for 211 dynamically updated zones. 213 [RFC5936] subsequently redefined the specification of AXFR to improve 214 performance and interoperability. 216 In this document we use the phrase "XFR mechanism" to describe the 217 entire set of message exchanges between a secondary and a primary 218 that concludes in a successful AXFR or IXFR request/response. This 219 set may or may not include 221 o NOTIFY messages 223 o SOA queries 225 o Fallback from IXFR to AXFR 227 o Fallback from IXFR-over-UDP to IXFR-over-TCP 229 The term is used to encompasses the range of permutations that are 230 possible and is useful to distinguish the 'XFR mechanism' from a 231 single XFR request/response exchange. 233 4.1. AXFR Mechanism 235 The figure below provides an outline of an AXFR mechanism including 236 NOTIFYs. 238 Figure 1. AXFR Mechanism [1] 240 1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP) 241 from the primary to the secondary. A secondary may also initiate 242 an AXFR based on a refresh timer or scheduled/triggered zone 243 maintenance. 245 2. The secondary will normally (but not always) make a SOA query to 246 the primary to obtain the serial number of the zone held by the 247 primary. 249 3. If the primary serial is higher than the secondaries serial 250 (using Serial Number Arithmetic [RFC1982]), the secondary makes 251 an AXFR request (over TCP) to the primary after which the AXFR 252 data flows in one or more AXFR responses on the TCP connection. 254 [RFC5936] specifies that AXFR must use TCP as the transport protocol 255 but details that there is no restriction in the protocol that a 256 single TCP session must be used only for a single AXFR exchange, or 257 even solely for XFRs. For example, it outlines that the SOA query 258 can also happen on this connection. However, this can cause 259 interoperability problems with older implementations that support 260 only the trivial case of one AXFR per connection. 262 Further details of the limitations in existing AXFR implementations 263 are outlined in [RFC5936]. 265 It is noted that unless the NOTIFY is sent over a trusted 266 communication channel and/or signed by TSIG is can be spoofed causing 267 unnecessary zone transfer attempts. 269 Similarly unless the SOA query is sent over a trusted communication 270 channel and/or signed by TSIG the response can, in principle, be 271 spoofed causing a secondary to incorrectly believe its version of the 272 zone is update to date. Repeated successful attacks on the SOA could 273 result in a secondary serving stale zone data. 275 4.2. IXFR Mechanism 277 The figure below provides an outline of the IXFR mechanism including 278 NOTIFYs. 280 Figure 1. IXFR Mechanism [2] 282 1. An IXFR is normally (but not always) preceded by a NOTIFY (over 283 UDP) from the primary to the secondary. A secondary may also 284 initiate an IXFR based on a refresh timer or scheduled/triggered 285 zone maintenance. 287 2. The secondary will normally (but not always) make a SOA query to 288 the primary to obtain the serial number of the zone held by the 289 primary. 291 3. If the primary serial is higher than the secondaries serial 292 (using Serial Number Arithmetic [RFC1982]), the secondary makes 293 an IXFR request to the primary after the primary sends an IXFR 294 response. 296 [RFC1995] specifies that Incremental Transfer may use UDP if the 297 entire IXFR response can be contained in a single DNS packet, 298 otherwise, TCP is used. In fact is says in non-normative language: 300 "Thus, a client should first make an IXFR query using UDP." 302 So there may be a forth step above where the client falls back to 303 IXFR-over-TCP. There may also be a forth step where the secondary 304 must fall back to AXFR because e.g. the primary does not support 305 IXFR. 307 However it is noted that at least two widely used open source 308 authoritative nameserver implementations (BIND [3] and NSD [4]) do 309 IXFR using TCP by default in their latest releases. For BIND TCP 310 connections are sometimes used for SOA queries but in general they 311 are not used persistently and close after an IXFR is completed. 313 It is noted that the specification for IXFR was published well before 314 TCP was considered a first class transport for DNS. This document 315 therefore updates [RFC1995] to state that DNS implementations that 316 support IXFR-over-TCP MUST use [RFC7766] to optimise the use of TCP 317 connections and SHOULD use [RFC7858] to manage persistent 318 connections. 320 4.3. Data Leakage of NOTIFY and SOA Message Exchanges 322 This section attempts to presents a rationale for also encrypting the 323 other messages in the XFR mechanism. 325 Since the SOA of the published zone can be trivially discovered by 326 simply querying the publicly available authoritative servers leakage 327 RR of this is not discussed in the following sections. 329 4.3.1. NOTIFY 331 Unencrypted NOTIFY messages identify configured secondaries on the 332 primary. 334 [RFC1996] also states: 336 "If ANCOUNT>0, then the answer section represents an unsecure hint at 337 the new RRset for this . 339 But since the only supported QTYPE for NOTIFY is SOA, this does not 340 pose a potential leak. 342 4.3.2. SOA 344 For hidden primaries or secondaries the SOA response leaks the degree 345 of lag of any downstream secondary. 347 5. Connection and Data Flows in XoT 349 5.1. Performance Considerations 351 The details in [RFC7766], [RFC7858] and [RFC8310] about e.g. using 352 persistent connections and TLS Session Resumption [RFC5077] are fully 353 applicable to XFR-over-TLS as well. 355 It is RECOMMENDED that clients and servers that support XoT also 356 implement EDNS0 Keepalive [RFC7828]. 358 5.2. AXoT mechanism 360 The figure below provides an outline of the AXoT mechanism including 361 NOTIFYs. 363 Figure 3: AXoT mechanism [5] 365 All implementations that support XoT MUST fully implement [RFC5953] 366 behavior on TLS connections. 368 Sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] describe guidance for AXFR 369 clients and servers with regard to re-use of sessions for multiple 370 AXFRs, AXFRs of different zones and using TCP session for other 371 queries including SOA. 373 For clarity we restate here that an AXoT client MAY use an already 374 opened TLS connection to send a AXFR request. Using an existing open 375 connection is RECOMMENDED over opening a new connection. (Non-AXoT 376 session traffic can also use an open connection.) 378 For clarity we additionally state here that an AXoT client MAY use an 379 already opened TLS connection to send a SOA request. Using an 380 existing open connection is RECOMMENDED over opening a new 381 connection. 383 The connection for AXFR-over-TLS SHOULD be established using port 384 853, as specified in [RFC7858], unless there is mutual agreement 385 between the secondary and primary to use a port other than port 853 386 for XFR-over-TLS. 388 QUESTION: Should there be a requirement that the SOA is always done 389 on a TLS connection if the XFR is? For the case when no transfer is 390 required this could be unnecessary overhead. 392 5.3. IXoT mechanism 394 The figure below provides an outline of the IXoT mechanism including 395 NOTIFYs. 397 Figure 4: IXoT mechanism [6] 399 The connection for IXFR-over-TLS SHOULD be established using port 400 853, as specified in [RFC7858], unless there is mutual agreement 401 between the secondary and primary to use a port other than port 853 402 for XFR-over-TLS. 404 [RFC1995] says nothing with respect to optimizing IXFRs over TCP or 405 re-using already open TCP connections to perform IXFRs or other 406 queries. We provide guidance here that aligns with the guidance in 407 [RFC5936] for AXFR and with that for performant TCP/TLS usage in 408 [RFC7766] and [RFC7858]. 410 An IXoT client MAY use an already opened TLS connection to send a 411 IXFR request. Using an existing open connection is RECOMMENDED over 412 opening a new connection. (Non-IXoT session traffic can also use an 413 open connection.) 415 An IXoT client MAY use an already open TLS connection to send an SOA 416 query. Using an existing open connection is RECOMMENDED over opening 417 a new connection. 419 An IXoT server MUST be able to handle multiple IXoT requests on a 420 single TLS connection, as well as to handle other query/response 421 transactions over it. 423 An IXoT client MAY keep an existing TLS session open in the 424 expectation it is likely to need to perform an IXFR in the near 425 future. The client may use the frequency of recent IXFRs to 426 calculate an average update rate and then use EDNS0 Keepalive to 427 request an appropriate timeout from the server (if the server 428 supports EDNS0 Keepalive). If the server does not support EDNS0 429 Keepalive the client MAY keep the connection open for a few seconds 430 ([RFC7766] recommends that servers use timeouts of at least a few 431 seconds). 433 An IXoT client MAY pipeline IXFR requests for different zones on a 434 single TLS connection. AN IXoT server MAY respond to those requests 435 out of order. 437 5.3.1. Fallback to AXFR 439 Fallback to AXFR can happen, for example, if the server is not able 440 to provide an IXFR for the requested SOA. Implementations differ in 441 how long they store zone deltas and how many may be stored at any one 442 time. 444 After a failed IXFR a IXoT client SHOULD request the AXFR on the 445 already open TLS connection. 447 6. Zone Transfer with DoT - Authentication 449 6.1. TSIG 451 TSIG [RFC2845] provides a mechanism for two parties to exchange 452 secret keys which can then be used to create a message digest to 453 protect individual DNS messages. This allows each party to 454 authenticate that a request or response (and the data in it) came 455 from the other party, even if it was transmitted-over-an unsecured 456 channel or via a proxy. It provides party-to-party data 457 authentication, but not hop-to-hop channel authentication or 458 confidentiality. 460 6.2. SIG(0) 462 TBD 464 6.3. TLS 466 6.3.1. Opportunistic 468 Opportunistic TLS [RFC8310] provides a defence against passive 469 surveillance, providing on-the-wire confidentiality. 471 6.3.2. Strict 473 Strict TLS [RFC8310] requires that a client is configured with an 474 authentication domain name (and/or SPKI pinset) that should be used 475 to authenticate the TLS handshake with the server. This additionally 476 provides a defense for the client against active surveillance, 477 providing client-to-server authentication and end-to-end channel 478 confidentiality. 480 6.3.3. Mutual 482 This is an extension to Strict TLS [RFC8310] which requires that a 483 client is configured with an authentication domain name (and/or SPKI 484 pinset) and a client certificate. The client offers the certificate 485 for authentication by the server and the client can authentic the 486 server the same way as in Strict TLS. This provides a defense for 487 both parties against active surveillance, providing bi-directional 488 authentication and end-to-end channel confidentiality. 490 6.4. IP Based ACL on the Primary 492 Most DNS server implementations offer an option to configure an IP 493 based Access Control List (ACL), which is often used in combination 494 with TSIG based ACLs to restrict access to zone transfers on primary 495 servers. 497 This is also possible with XoT but it must be noted that as with TCP 498 the implementation of such and ACL cannot be enforced on the primary 499 until a XFR request is received on an established connection. 501 If control were to be any more fine-grained than this then a separate 502 port would be required for XoT such that implementations would be 503 able to refuse connections on that port to all clients except those 504 configured as secondaries. 506 6.5. ZONEMD 508 Message Digest for DNS Zones (ZONEMD) 509 [I-D.ietf-dnsop-dns-zone-digest] digest is a mechanism that can be 510 used to verify the content of a standalone zone. It is designed to 511 be independent of the transmission channel or mechanism, allowing a 512 general consumer of a zone to do origin authentication of the entire 513 zone contents. Note that the current version of 514 [I-D.ietf-dnsop-dns-zone-digest] states: 516 "As specified at this time, ZONEMD is not designed for use in large, 517 dynamic zones due to the time and resources required for digest 518 calculation. The ZONEMD record described in this document includes 519 fields reserved for future work to support large, dynamic zones." 521 It is complementary the above mechanisms and can be used in 522 conjunction with XFR-over-TLS but is not considered further. 524 6.6. Comparison of Authentication Methods 526 The Table below compares the properties of each of the above methods 527 in terms of what protection they provide to the secondary and primary 528 servers during XoT in terms of: 530 o 'Data Auth': Authentication that the DNS message data is signed by 531 the party with whom credentials were shared (the signing party may 532 or may not be party operating the far end of a TCP/TLS connection 533 in a 'proxy' scenario). For the primary the TSIG on the XFR 534 request confirms that the requesting party is authorized to 535 request zone data, for the secondary it authenticates the zone 536 data that is received. 538 o 'Channel Conf': Confidentiality of the communication channel 539 between the client and server (i.e. the two end points of a TCP/ 540 TLS connection). 542 o Channel Auth: Authentication of the identity of party to whom a 543 TCP/TLS connection is made (this might not be a direct connection 544 between the primary and secondary in a proxy scenario). 546 It is noted that zone transfer scenarios can vary from a simple 547 single primary/secondary relationship where both servers are under 548 the control of a single operator to a complex hierarchical structure 549 which includes proxies and multiple operators. Each deployment 550 scenario will require specific analysis to determine which 551 authentication methods are best suited to the deployment model in 552 question. 554 Table 1: Properties of Authentication methods for XoT [7] 556 Based on this analysis it can be seen that: 558 o A combination of Opportunistic TLS and TSIG provides both data 559 authentication and channel confidentiality for both parties. 560 However this does not stop a MitM attack on the channel which 561 could be used to gather zone data. 563 o Using just mutual TLS can be considered a standalone solution if 564 the secondary has reason to place equivalent trust in channel 565 authentication as data authentication e.g. the same operator runs 566 both the primary and secondary. 568 o Using TSIG, Strict TLS and an ACL on the primary provides all 3 569 properties for both parties with probably the lowest operational 570 overhead. 572 7. Policies for Both AXFR and IXFR 574 We call the entire group of servers involved in XFR (all the 575 primaries and all the secondaries) the 'transfer group'. 577 Within any transfer group both AXFRs and IXFRs for a zone SHOULD all 578 use the same policy e.g. if AXFRs use AXoT all IXFRs SHOULD use IXoT. 580 In order to assure the confidentiality of the zone information, the 581 entire transfer group MUST have a consistent policy of requiring 582 confidentiality. If any do not, this is a weak link for attackers to 583 exploit. 585 A XoT policy should specify 587 o If TSIG is required 589 o What kind of TLS is required (Opportunistic, Strict or mTLS) 591 o If IP based ACLs should also be used. 593 Since this may require configuration of a number of servers who may 594 be under the control of different operators the desired consistency 595 could be hard to enforce and audit in practice. 597 Certain aspects of the Policies can be relatively easily tested 598 independently e.g. by requesting zone transfers without TSIG, from 599 unauthorized IP addresses or over cleartext DNS. Other aspects such 600 as if a secondary will accept data without a TSIG digest or if 601 secondaries are using Strict as opposed to Opportunistic TLS are more 602 challenging. 604 NOTE: The authors request feedback on this challenge and welcome 605 suggestions of how to practically manage this. 607 8. Multi-primary Configurations 609 Also known as multi-master configurations this model can provide 610 flexibility and redundancy particularly for IXFR. A secondary will 611 receive one or more NOTIFY messages and can send an SOA to all of the 612 configured primaries. It can then choose to send an IXFR request to 613 the primary with the highest SOA (or other criteria e.g. RTT). 615 When using persistent connections the secondary may have a TLS 616 connection already open to one or more primaries. Should a secondary 617 preferentially request an IXFR from a primary to which it already has 618 an open TLS connection or the one with the highest SOA (assuming it 619 doesn't have a connection open to it already)? 621 Two extremes can be envisaged here. In the first case the secondary 622 continues to use one persistent connection to a single primary until 623 it has reason not to. Reasons not to might include the primary 624 repeatedly closing the connection, long RTTs on transfers or the SOA 625 of the primary being an unacceptable lag behind the SOA of an 626 alternative primary. 628 At the other extreme a primary could keep multiple persistent 629 connections open to all available primaries and only request IXFRs 630 from the primary with the highest serial number. Since normally the 631 number of secondaries and primaries in direct contact in a transfer 632 group is reasonably low this might be feasible if latency is the most 633 significant concern. 635 9. Implementation Considerations 637 TBD 639 10. Implementation Status 641 The 1.9.2 version of Unbound [8] includes an option to perform AXFR- 642 over-TLS (instead of TCP). This requires the client (secondary) to 643 authenticate the server (primary) using a configured authentication 644 domain name. 646 It is noted that use of a TLS proxy in front of the primary server is 647 a simple deployment solution that can enable server side XoT. 649 11. IANA Considerations 651 TBD 653 12. Security Considerations 655 This document specifies a security measure against a DNS risk: the 656 risk that an attacker collects entire DNS zones through eavesdropping 657 on clear text DNS zone transfers. It presents a new Security 658 Consideration for DNS. Some questions to discuss are: 660 o Should DoT in this new case be required to use only TLS 1.3 and 661 higher to avoid residual exposure? 663 o How should padding be used in IXFR? 665 o Should there be an option to 'pad' an AXFR response (i.e. a set of 666 AXFR responses on a given connection) to hide the zone size? 668 13. Acknowledgements 670 The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for 671 review and discussions. 673 14. Changelog 675 draft-ietf-dprive-xfr-over-tls-00 677 o Rename after adoption and reference update. 679 o Add placeholder for SIG(0) discussion 681 o Update section on ZONEMD 683 draft-hzpa-dprive-xfr-over-tls-02 685 o Substantial re-work of the document. 687 draft-hzpa-dprive-xfr-over-tls-01 689 o Editorial changes, updates to references. 691 draft-hzpa-dprive-xfr-over-tls-00 693 o Initial commit 695 15. References 697 15.1. Normative References 699 [I-D.ietf-dprive-rfc7626-bis] 700 Bortzmeyer, S. and S. Dickinson, "DNS Privacy 701 Considerations", draft-ietf-dprive-rfc7626-bis-02 (work in 702 progress), October 2019. 704 [I-D.vcelak-nsec5] 705 Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and 706 D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of 707 Existence", draft-vcelak-nsec5-08 (work in progress), 708 December 2018. 710 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 711 DOI 10.17487/RFC1995, August 1996, . 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, 716 DOI 10.17487/RFC2119, March 1997, . 719 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 720 Wellington, "Secret Key Transaction Authentication for DNS 721 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 722 . 724 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 725 "Transport Layer Security (TLS) Session Resumption without 726 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 727 January 2008, . 729 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 730 Security (DNSSEC) Hashed Authenticated Denial of 731 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 732 . 734 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 735 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 736 . 738 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 739 Morris, J., Hansen, M., and R. Smith, "Privacy 740 Considerations for Internet Protocols", RFC 6973, 741 DOI 10.17487/RFC6973, July 2013, . 744 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 745 and P. Hoffman, "Specification for DNS over Transport 746 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 747 2016, . 749 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 750 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 751 May 2017, . 753 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 754 for DNS over TLS and DNS over DTLS", RFC 8310, 755 DOI 10.17487/RFC8310, March 2018, . 758 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 759 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 760 . 762 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 763 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 764 January 2019, . 766 15.2. Informative References 768 [I-D.ietf-dnsop-dns-zone-digest] 769 Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. 770 Hardaker, "Message Digest for DNS Zones", draft-ietf- 771 dnsop-dns-zone-digest-02 (work in progress), October 2019. 773 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 774 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 775 . 777 [RFC1035] Mockapetris, P., "Domain names - implementation and 778 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 779 November 1987, . 781 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 782 DOI 10.17487/RFC1982, August 1996, . 785 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 786 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 787 August 1996, . 789 [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport 790 Model for the Simple Network Management Protocol (SNMP)", 791 RFC 5953, DOI 10.17487/RFC5953, August 2010, 792 . 794 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 795 D. Wessels, "DNS Transport over TCP - Implementation 796 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 797 . 799 15.3. URIs 801 [1] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ 802 blob/02_updates/02-draft-svg/AXFR_mechanism.svg 804 [2] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ 805 blob/02_updates/02-draft-svg/IXFR%20mechanism.svg 807 [3] https://www.isc.org/bind/ 809 [4] https://www.nlnetlabs.nl/projects/nsd/about/ 811 [5] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ 812 blob/02_updates/02-draft-svg/AXoT_mechanism_1.svg 814 [6] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ 815 blob/02_updates/02-draft-svg/IXoT_mechanism_1.svg 817 [7] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ 818 blob/02_updates/02-draft-svg/ 819 Properties_of_Authentication_methods_for_XoT.svg 821 [8] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ 822 Changelog 824 Authors' Addresses 826 Han Zhang 827 Salesforce 828 San Francisco, CA 829 United States 831 Email: hzhang@salesforce.com 833 Pallavi Aras 834 Salesforce 835 Herndon, VA 836 United States 838 Email: paras@salesforce.com 840 Willem Toorop 841 NLnet Labs 842 Science Park 400 843 Amsterdam 1098 XH 844 The Netherlands 846 Email: willem@nlnetlabs.nl 848 Sara Dickinson 849 Sinodun IT 850 Magdalen Centre 851 Oxford Science Park 852 Oxford OX4 4GA 853 United Kingdom 855 Email: sara@sinodun.com 856 Allison Mankin 857 Salesforce 858 Herndon, VA 859 United States 861 Email: allison.mankin@gmail.com