idnits 2.17.1 draft-ietf-dprive-xfr-over-tls-01.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 (May 20, 2020) is 1436 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 818 -- Looks like a reference, but probably isn't: '2' on line 821 -- Looks like a reference, but probably isn't: '3' on line 824 -- Looks like a reference, but probably isn't: '4' on line 826 == Missing Reference: 'RFC7828' is mentioned on line 353, but not defined == Missing Reference: 'RFC8446' is mentioned on line 363, but not defined -- Looks like a reference, but probably isn't: '5' on line 828 -- Looks like a reference, but probably isn't: '6' on line 831 -- Looks like a reference, but probably isn't: '7' on line 834 -- Looks like a reference, but probably isn't: '8' on line 838 == Outdated reference: A later version (-09) exists of draft-ietf-dprive-rfc7626-bis-05 ** 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-07 -- 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: November 21, 2020 NLnet Labs 7 S. Dickinson 8 Sinodun IT 9 A. Mankin 10 Salesforce 11 May 20, 2020 13 DNS Zone Transfer-over-TLS 14 draft-ietf-dprive-xfr-over-tls-01 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 November 21, 2020. 43 Copyright Notice 45 Copyright (c) 2020 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. TLS versions . . . . . . . . . . . . . . . . . . . . . . 8 72 5.3. AXoT mechanism . . . . . . . . . . . . . . . . . . . . . 8 73 5.4. IXoT mechanism . . . . . . . . . . . . . . . . . . . . . 9 74 5.4.1. Fallback to AXFR . . . . . . . . . . . . . . . . . . 10 75 6. Zone Transfer with DoT - Authentication . . . . . . . . . . . 10 76 6.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 6.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 6.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6.3.1. Opportunistic . . . . . . . . . . . . . . . . . . . . 11 80 6.3.2. Strict . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.3.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 11 82 6.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 11 83 6.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 6.6. Comparison of Authentication Methods . . . . . . . . . . 12 85 7. Policies for Both AXFR and IXFR . . . . . . . . . . . . . . . 13 86 8. Multi-primary Configurations . . . . . . . . . . . . . . . . 14 87 9. Implementation Considerations . . . . . . . . . . . . . . . . 14 88 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 89 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 90 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 92 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 15.1. Normative References . . . . . . . . . . . . . . . . . . 16 95 15.2. Informative References . . . . . . . . . . . . . . . . . 17 96 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 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 XoT: Generic XFR-over-TLS mechanisms as specified in this document 172 AXoT: AXFR-over-TLS 174 IXoT: IXFR over-TLS 176 3. Use Cases for XFR-over-TLS 178 o Confidentiality. Clearly using an encrypted transport for zone 179 transfers will defeat zone content leakage that can occur via 180 passive surveillance. 182 o Authentication. Use of single or mutual TLS authentication (in 183 combination with ACLs) can complement and potentially be an 184 alternative to TSIG. 186 o Performance. Existing AXFR and IXFR mechanisms have the burden of 187 backwards compatibility with older implementations based on the 188 original specifications in [RFC1034] and [RFC1035]. For example, 189 some older AXFR servers don't support using a TCP connection for 190 multiple AXFR sessions or XFRs of different zones because they 191 have not been updated to follow the guidance in [RFC5936]. Any 192 implementation of XFR-over-TLS would obviously be required to 193 implement optimized and interoperable transfers as described in 194 [RFC5936] e.g. transfer of multiple zones over one connection. 196 o Performance. Current usage of TCP for IXFR is sub-optimal in some 197 cases i.e. connections are frequently closed after a single IXFR. 199 4. Connection and Data Flows in Existing XFR Mechanisms 201 The original specification for zone transfers in [RFC1034] and 202 [RFC1035] was based on a polling mechanism: a secondary performed a 203 periodic SOA query (based on the refresh timer) to determine if an 204 AXFR was required. 206 [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY 207 respectively, to provide for prompt propagation of zone updates. 208 This has largely replaced AXFR where possible, particularly for 209 dynamically updated zones. 211 [RFC5936] subsequently redefined the specification of AXFR to improve 212 performance and interoperability. 214 In this document we use the phrase "XFR mechanism" to describe the 215 entire set of message exchanges between a secondary and a primary 216 that concludes in a successful AXFR or IXFR request/response. This 217 set may or may not include 219 o NOTIFY messages 221 o SOA queries 223 o Fallback from IXFR to AXFR 225 o Fallback from IXFR-over-UDP to IXFR-over-TCP 227 The term is used to encompasses the range of permutations that are 228 possible and is useful to distinguish the 'XFR mechanism' from a 229 single XFR request/response exchange. 231 4.1. AXFR Mechanism 233 The figure below provides an outline of an AXFR mechanism including 234 NOTIFYs. 236 Figure 1. AXFR Mechanism [1] 237 1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP) 238 from the primary to the secondary. A secondary may also initiate 239 an AXFR based on a refresh timer or scheduled/triggered zone 240 maintenance. 242 2. The secondary will normally (but not always) make a SOA query to 243 the primary to obtain the serial number of the zone held by the 244 primary. 246 3. If the primary serial is higher than the secondaries serial 247 (using Serial Number Arithmetic [RFC1982]), the secondary makes 248 an AXFR request (over TCP) to the primary after which the AXFR 249 data flows in one or more AXFR responses on the TCP connection. 251 [RFC5936] specifies that AXFR must use TCP as the transport protocol 252 but details that there is no restriction in the protocol that a 253 single TCP session must be used only for a single AXFR exchange, or 254 even solely for XFRs. For example, it outlines that the SOA query 255 can also happen on this connection. However, this can cause 256 interoperability problems with older implementations that support 257 only the trivial case of one AXFR per connection. 259 Further details of the limitations in existing AXFR implementations 260 are outlined in [RFC5936]. 262 It is noted that unless the NOTIFY is sent over a trusted 263 communication channel and/or signed by TSIG is can be spoofed causing 264 unnecessary zone transfer attempts. 266 Similarly unless the SOA query is sent over a trusted communication 267 channel and/or signed by TSIG the response can, in principle, be 268 spoofed causing a secondary to incorrectly believe its version of the 269 zone is update to date. Repeated successful attacks on the SOA could 270 result in a secondary serving stale zone data. 272 4.2. IXFR Mechanism 274 The figure below provides an outline of the IXFR mechanism including 275 NOTIFYs. 277 Figure 1. IXFR Mechanism [2] 279 1. An IXFR is normally (but not always) preceded by a NOTIFY (over 280 UDP) from the primary to the secondary. A secondary may also 281 initiate an IXFR based on a refresh timer or scheduled/triggered 282 zone maintenance. 284 2. The secondary will normally (but not always) make a SOA query to 285 the primary to obtain the serial number of the zone held by the 286 primary. 288 3. If the primary serial is higher than the secondaries serial 289 (using Serial Number Arithmetic [RFC1982]), the secondary makes 290 an IXFR request to the primary after the primary sends an IXFR 291 response. 293 [RFC1995] specifies that Incremental Transfer may use UDP if the 294 entire IXFR response can be contained in a single DNS packet, 295 otherwise, TCP is used. In fact is says in non-normative language: 297 "Thus, a client should first make an IXFR query using UDP." 299 So there may be a forth step above where the client falls back to 300 IXFR-over-TCP. There may also be a forth step where the secondary 301 must fall back to AXFR because e.g. the primary does not support 302 IXFR. 304 However it is noted that at least two widely used open source 305 authoritative nameserver implementations (BIND [3] and NSD [4]) do 306 IXFR using TCP by default in their latest releases. For BIND TCP 307 connections are sometimes used for SOA queries but in general they 308 are not used persistently and close after an IXFR is completed. 310 It is noted that the specification for IXFR was published well before 311 TCP was considered a first class transport for DNS. This document 312 therefore updates [RFC1995] to state that DNS implementations that 313 support IXFR-over-TCP MUST use [RFC7766] to optimise the use of TCP 314 connections and SHOULD use [RFC7858] to manage persistent 315 connections. 317 4.3. Data Leakage of NOTIFY and SOA Message Exchanges 319 This section attempts to presents a rationale for also encrypting the 320 other messages in the XFR mechanism. 322 Since the SOA of the published zone can be trivially discovered by 323 simply querying the publicly available authoritative servers leakage 324 of this RR is not discussed in the following sections. 326 4.3.1. NOTIFY 328 Unencrypted NOTIFY messages identify configured secondaries on the 329 primary. 331 [RFC1996] also states: 333 "If ANCOUNT>0, then the answer section represents an unsecure hint at 334 the new RRset for this . 336 But since the only supported QTYPE for NOTIFY is SOA, this does not 337 pose a potential leak. 339 4.3.2. SOA 341 For hidden primaries or secondaries the SOA response leaks the degree 342 of lag of any downstream secondary. 344 5. Connection and Data Flows in XoT 346 5.1. Performance Considerations 348 The details in [RFC7766], [RFC7858] and [RFC8310] about e.g. using 349 persistent connections and TLS Session Resumption [RFC5077] are fully 350 applicable to XFR-over-TLS as well. 352 It is RECOMMENDED that clients and servers that support XoT also 353 implement EDNS0 Keepalive [RFC7828]. 355 It is useful to note that in these mechanisms it is the secondary 356 that initiates the TLS connection to the primary for a XFR request, 357 so that in terms of connectivity the secondary is the TLS client and 358 the primary the TLS server. 360 5.2. TLS versions 362 For improved security all implementations of this specification MUST 363 use only TLS 1.3 [RFC8446] or later. 365 5.3. AXoT mechanism 367 The figure below provides an outline of the AXoT mechanism including 368 NOTIFYs. 370 Figure 3: AXoT mechanism [5] 372 The connection for AXFR-over-TLS SHOULD be established using port 373 853, as specified in [RFC7858], unless there is mutual agreement 374 between the secondary and primary to use a port other than port 853 375 for XFR-over-TLS. 377 All implementations that support XoT MUST fully implement [RFC5953] 378 behavior on TLS connections. 380 Sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] describe guidance for AXFR 381 clients and servers with regard to re-use of sessions for multiple 382 AXFRs, AXFRs of different zones and using TCP session for other 383 queries including SOA. 385 For clarity we restate here that an AXoT client MAY use an already 386 opened TLS connection to send a AXFR request. Using an existing open 387 connection is RECOMMENDED over opening a new connection. (Non-AXoT 388 session traffic can also use an open connection.) 390 For clarity we additionally state here that an AXoT client MAY use an 391 already opened TLS connection to send a SOA request. Using an 392 existing open connection is RECOMMENDED over opening a new 393 connection. 395 QUESTION: Should there be a requirement that the SOA is always done 396 on a TLS connection if the XFR is? For the case when no transfer is 397 required this could be unnecessary overhead. 399 5.4. IXoT mechanism 401 The figure below provides an outline of the IXoT mechanism including 402 NOTIFYs. 404 Figure 4: IXoT mechanism [6] 406 The connection for IXFR-over-TLS SHOULD be established using port 407 853, as specified in [RFC7858], unless there is mutual agreement 408 between the secondary and primary to use a port other than port 853 409 for XFR-over-TLS. 411 [RFC1995] says nothing with respect to optimizing IXFRs over TCP or 412 re-using already open TCP connections to perform IXFRs or other 413 queries. We provide guidance here that aligns with the guidance in 414 [RFC5936] for AXFR and with that for performant TCP/TLS usage in 415 [RFC7766] and [RFC7858]. 417 An IXoT client MAY use an already opened TLS connection to send a 418 IXFR request. Using an existing open connection is RECOMMENDED over 419 opening a new connection. (Non-IXoT session traffic can also use an 420 open connection.) 422 An IXoT client MAY use an already open TLS connection to send an SOA 423 query. Using an existing open connection is RECOMMENDED over opening 424 a new connection. 426 An IXoT server MUST be able to handle multiple IXoT requests on a 427 single TLS connection, as well as to handle other query/response 428 transactions over it. 430 An IXoT client MAY keep an existing TLS session open in the 431 expectation it is likely to need to perform an IXFR in the near 432 future. The client may use the frequency of recent IXFRs to 433 calculate an average update rate and then use EDNS0 Keepalive to 434 request an appropriate timeout from the server (if the server 435 supports EDNS0 Keepalive). If the server does not support EDNS0 436 Keepalive the client MAY keep the connection open for a few seconds 437 ([RFC7766] recommends that servers use timeouts of at least a few 438 seconds). 440 An IXoT client MAY pipeline IXFR requests for different zones on a 441 single TLS connection. AN IXoT server MAY respond to those requests 442 out of order. 444 QUESTION: Since this is a new specification should there be a 445 requirement that IXoT servers are RECOMMENDED to condense responses 446 as described in Section 6 of [RFC1995]. [RFC1995] document says this 447 is optional and MAY be done but it can significantly reduce the size 448 of responses and may have implications for padding? 450 5.4.1. Fallback to AXFR 452 Fallback to AXFR can happen, for example, if the server is not able 453 to provide an IXFR for the requested SOA. Implementations differ in 454 how long they store zone deltas and how many may be stored at any one 455 time. 457 After a failed IXFR a IXoT client SHOULD request the AXFR on the 458 already open TLS connection. 460 6. Zone Transfer with DoT - Authentication 462 6.1. TSIG 464 TSIG [RFC2845] provides a mechanism for two parties to exchange 465 secret keys which can then be used to create a message digest to 466 protect individual DNS messages. This allows each party to 467 authenticate that a request or response (and the data in it) came 468 from the other party, even if it was transmitted-over-an unsecured 469 channel or via a proxy. It provides party-to-party data 470 authentication, but not hop-to-hop channel authentication or 471 confidentiality. 473 6.2. SIG(0) 475 TBD 477 6.3. TLS 479 6.3.1. Opportunistic 481 Opportunistic TLS [RFC8310] provides a defence against passive 482 surveillance, providing on-the-wire confidentiality. 484 6.3.2. Strict 486 Strict TLS [RFC8310] requires that a client is configured with an 487 authentication domain name (and/or SPKI pinset) that should be used 488 to authenticate the TLS handshake with the server. This additionally 489 provides a defense for the client against active surveillance, 490 providing client-to-server authentication and end-to-end channel 491 confidentiality. 493 6.3.3. Mutual 495 This is an extension to Strict TLS [RFC8310] which requires that a 496 client is configured with an authentication domain name (and/or SPKI 497 pinset) and a client certificate. The client offers the certificate 498 for authentication by the server and the client can authentic the 499 server the same way as in Strict TLS. This provides a defense for 500 both parties against active surveillance, providing bi-directional 501 authentication and end-to-end channel confidentiality. 503 6.4. IP Based ACL on the Primary 505 Most DNS server implementations offer an option to configure an IP 506 based Access Control List (ACL), which is often used in combination 507 with TSIG based ACLs to restrict access to zone transfers on primary 508 servers. 510 This is also possible with XoT but it must be noted that as with TCP 511 the implementation of such an ACL cannot be enforced on the primary 512 until a XFR request is received on an established connection. 514 If control were to be any more fine-grained than this then a 515 separate, dedicated port would need to be agreed between primary and 516 secondary for XoT such that implementations would be able to refuse 517 connections on that port to all clients except those configured as 518 secondaries. 520 6.5. ZONEMD 522 Message Digest for DNS Zones (ZONEMD) 523 [I-D.ietf-dnsop-dns-zone-digest] digest is a mechanism that can be 524 used to verify the content of a standalone zone. It is designed to 525 be independent of the transmission channel or mechanism, allowing a 526 general consumer of a zone to do origin authentication of the entire 527 zone contents. Note that the current version of 528 [I-D.ietf-dnsop-dns-zone-digest] states: 530 "As specified at this time, ZONEMD is not designed for use in large, 531 dynamic zones due to the time and resources required for digest 532 calculation. The ZONEMD record described in this document includes 533 fields reserved for future work to support large, dynamic zones." 535 It is complementary the above mechanisms and can be used in 536 conjunction with XFR-over-TLS but is not considered further. 538 6.6. Comparison of Authentication Methods 540 The Table below compares the properties of each of the above methods 541 in terms of what protection they provide to the secondary and primary 542 servers during XoT in terms of: 544 o 'Data Auth': Authentication that the DNS message data is signed by 545 the party with whom credentials were shared (the signing party may 546 or may not be party operating the far end of a TCP/TLS connection 547 in a 'proxy' scenario). For the primary the TSIG on the XFR 548 request confirms that the requesting party is authorized to 549 request zone data, for the secondary it authenticates the zone 550 data that is received. 552 o 'Channel Conf': Confidentiality of the communication channel 553 between the client and server (i.e. the two end points of a TCP/ 554 TLS connection). 556 o Channel Auth: Authentication of the identity of party to whom a 557 TCP/TLS connection is made (this might not be a direct connection 558 between the primary and secondary in a proxy scenario). 560 It is noted that zone transfer scenarios can vary from a simple 561 single primary/secondary relationship where both servers are under 562 the control of a single operator to a complex hierarchical structure 563 which includes proxies and multiple operators. Each deployment 564 scenario will require specific analysis to determine which 565 authentication methods are best suited to the deployment model in 566 question. 568 Table 1: Properties of Authentication methods for XoT [7] 570 Based on this analysis it can be seen that: 572 o A combination of Opportunistic TLS and TSIG provides both data 573 authentication and channel confidentiality for both parties. 574 However this does not stop a MitM attack on the channel which 575 could be used to gather zone data. 577 o Using just mutual TLS can be considered a standalone solution if 578 the secondary has reason to place equivalent trust in channel 579 authentication as data authentication e.g. the same operator runs 580 both the primary and secondary. 582 o Using TSIG, Strict TLS and an ACL on the primary provides all 3 583 properties for both parties with probably the lowest operational 584 overhead. 586 7. Policies for Both AXFR and IXFR 588 We call the entire group of servers involved in XFR (all the 589 primaries and all the secondaries) the 'transfer group'. 591 Within any transfer group both AXFRs and IXFRs for a zone SHOULD all 592 use the same policy e.g. if AXFRs use AXoT all IXFRs SHOULD use IXoT. 594 In order to assure the confidentiality of the zone information, the 595 entire transfer group MUST have a consistent policy of requiring 596 confidentiality. If any do not, this is a weak link for attackers to 597 exploit. 599 A XoT policy should specify 601 o If TSIG is required 603 o What kind of TLS is required (Opportunistic, Strict or mTLS) 605 o If IP based ACLs should also be used. 607 Since this may require configuration of a number of servers who may 608 be under the control of different operators the desired consistency 609 could be hard to enforce and audit in practice. 611 Certain aspects of the Policies can be relatively easily tested 612 independently e.g. by requesting zone transfers without TSIG, from 613 unauthorized IP addresses or over cleartext DNS. Other aspects such 614 as if a secondary will accept data without a TSIG digest or if 615 secondaries are using Strict as opposed to Opportunistic TLS are more 616 challenging. 618 NOTE: The authors request feedback on this challenge and welcome 619 suggestions of how to practically manage this. 621 8. Multi-primary Configurations 623 Also known as multi-master configurations this model can provide 624 flexibility and redundancy particularly for IXFR. A secondary will 625 receive one or more NOTIFY messages and can send an SOA to all of the 626 configured primaries. It can then choose to send an IXFR request to 627 the primary with the highest SOA (or other criteria e.g. RTT). 629 When using persistent connections the secondary may have a TLS 630 connection already open to one or more primaries. Should a secondary 631 preferentially request an IXFR from a primary to which it already has 632 an open TLS connection or the one with the highest SOA (assuming it 633 doesn't have a connection open to it already)? 635 Two extremes can be envisaged here. In the first case the secondary 636 continues to use one persistent connection to a single primary until 637 it has reason not to. Reasons not to might include the primary 638 repeatedly closing the connection, long RTTs on transfers or the SOA 639 of the primary being an unacceptable lag behind the SOA of an 640 alternative primary. 642 At the other extreme a primary could keep multiple persistent 643 connections open to all available primaries and only request IXFRs 644 from the primary with the highest serial number. Since normally the 645 number of secondaries and primaries in direct contact in a transfer 646 group is reasonably low this might be feasible if latency is the most 647 significant concern. 649 9. Implementation Considerations 651 TBD 653 10. Implementation Status 655 The 1.9.2 version of Unbound [8] includes an option to perform AXFR- 656 over-TLS (instead of TCP). This requires the client (secondary) to 657 authenticate the server (primary) using a configured authentication 658 domain name. 660 It is noted that use of a TLS proxy in front of the primary server is 661 a simple deployment solution that can enable server side XoT. 663 11. IANA Considerations 665 TBD 667 12. Security Considerations 669 This document specifies a security measure against a DNS risk: the 670 risk that an attacker collects entire DNS zones through eavesdropping 671 on clear text DNS zone transfers. It presents a new Security 672 Consideration for DNS. Some questions to discuss are: 674 o How should padding be used in IXFR? 676 o Should there be an option to 'pad' an AXFR response (i.e. a set of 677 AXFR responses on a given connection) to hide the zone size? 679 13. Acknowledgements 681 The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for 682 review and discussions. 684 14. Changelog 686 draft-ietf-dprive-xfr-over-tls-00 688 o Minor editorial updates 690 o Add requirement for TLS 1.3. or later 692 draft-ietf-dprive-xfr-over-tls-00 694 o Rename after adoption and reference update. 696 o Add placeholder for SIG(0) discussion 698 o Update section on ZONEMD 700 draft-hzpa-dprive-xfr-over-tls-02 702 o Substantial re-work of the document. 704 draft-hzpa-dprive-xfr-over-tls-01 706 o Editorial changes, updates to references. 708 draft-hzpa-dprive-xfr-over-tls-00 710 o Initial commit 712 15. References 714 15.1. Normative References 716 [I-D.ietf-dprive-rfc7626-bis] 717 Bortzmeyer, S. and S. Dickinson, "DNS Privacy 718 Considerations", draft-ietf-dprive-rfc7626-bis-05 (work in 719 progress), May 2020. 721 [I-D.vcelak-nsec5] 722 Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and 723 D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of 724 Existence", draft-vcelak-nsec5-08 (work in progress), 725 December 2018. 727 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 728 DOI 10.17487/RFC1995, August 1996, . 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, 733 DOI 10.17487/RFC2119, March 1997, . 736 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 737 Wellington, "Secret Key Transaction Authentication for DNS 738 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 739 . 741 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 742 "Transport Layer Security (TLS) Session Resumption without 743 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 744 January 2008, . 746 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 747 Security (DNSSEC) Hashed Authenticated Denial of 748 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 749 . 751 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 752 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 753 . 755 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 756 Morris, J., Hansen, M., and R. Smith, "Privacy 757 Considerations for Internet Protocols", RFC 6973, 758 DOI 10.17487/RFC6973, July 2013, . 761 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 762 and P. Hoffman, "Specification for DNS over Transport 763 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 764 2016, . 766 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 767 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 768 May 2017, . 770 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 771 for DNS over TLS and DNS over DTLS", RFC 8310, 772 DOI 10.17487/RFC8310, March 2018, . 775 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 776 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 777 . 779 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 780 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 781 January 2019, . 783 15.2. Informative References 785 [I-D.ietf-dnsop-dns-zone-digest] 786 Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. 787 Hardaker, "Message Digest for DNS Zones", draft-ietf- 788 dnsop-dns-zone-digest-07 (work in progress), April 2020. 790 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 791 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 792 . 794 [RFC1035] Mockapetris, P., "Domain names - implementation and 795 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 796 November 1987, . 798 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 799 DOI 10.17487/RFC1982, August 1996, . 802 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 803 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 804 August 1996, . 806 [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport 807 Model for the Simple Network Management Protocol (SNMP)", 808 RFC 5953, DOI 10.17487/RFC5953, August 2010, 809 . 811 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 812 D. Wessels, "DNS Transport over TCP - Implementation 813 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 814 . 816 15.3. URIs 818 [1] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ 819 blob/02_updates/02-draft-svg/AXFR_mechanism.svg 821 [2] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ 822 blob/02_updates/02-draft-svg/IXFR%20mechanism.svg 824 [3] https://www.isc.org/bind/ 826 [4] https://www.nlnetlabs.nl/projects/nsd/about/ 828 [5] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ 829 blob/02_updates/02-draft-svg/AXoT_mechanism_1.svg 831 [6] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ 832 blob/02_updates/02-draft-svg/IXoT_mechanism_1.svg 834 [7] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ 835 blob/02_updates/02-draft-svg/ 836 Properties_of_Authentication_methods_for_XoT.svg 838 [8] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ 839 Changelog 841 Authors' Addresses 843 Han Zhang 844 Salesforce 845 San Francisco, CA 846 United States 848 Email: hzhang@salesforce.com 849 Pallavi Aras 850 Salesforce 851 Herndon, VA 852 United States 854 Email: paras@salesforce.com 856 Willem Toorop 857 NLnet Labs 858 Science Park 400 859 Amsterdam 1098 XH 860 The Netherlands 862 Email: willem@nlnetlabs.nl 864 Sara Dickinson 865 Sinodun IT 866 Magdalen Centre 867 Oxford Science Park 868 Oxford OX4 4GA 869 United Kingdom 871 Email: sara@sinodun.com 873 Allison Mankin 874 Salesforce 875 Herndon, VA 876 United States 878 Email: allison.mankin@gmail.com