idnits 2.17.1 draft-ietf-dprive-xfr-over-tls-02.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. -- The draft header indicates that this document updates RFC7766, 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 (July 13, 2020) is 1381 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 1184 -- Looks like a reference, but probably isn't: '2' on line 1187 -- Looks like a reference, but probably isn't: '3' on line 1190 -- Looks like a reference, but probably isn't: '4' on line 1192 == Missing Reference: 'RFC8446' is mentioned on line 368, but not defined -- Looks like a reference, but probably isn't: '5' on line 1194 -- Looks like a reference, but probably isn't: '6' on line 1197 == Missing Reference: 'RFC7828' is mentioned on line 686, but not defined -- Looks like a reference, but probably isn't: '7' on line 1200 -- Looks like a reference, but probably isn't: '8' on line 1204 == Missing Reference: 'RFC7301' is mentioned on line 967, but not defined ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Downref: Normative reference to an Informational RFC: RFC 6973 ** Obsolete normative reference: RFC 7626 (Obsoleted by RFC 9076) ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) == Outdated reference: A later version (-14) exists of draft-ietf-dnsop-dns-zone-digest-08 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-00 == Outdated reference: A later version (-02) exists of draft-ietf-dprive-phase2-requirements-01 == Outdated reference: A later version (-01) exists of draft-vandijk-dprive-ds-dot-signal-and-pin-00 -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 13 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, 7766 (if approved) S. Dickinson 5 Intended status: Standards Track Sinodun IT 6 Expires: January 14, 2021 S. Sahib 7 P. Aras 8 A. Mankin 9 Salesforce 10 July 13, 2020 12 DNS Zone Transfer-over-TLS 13 draft-ietf-dprive-xfr-over-tls-02 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 use of TLS, rather then clear text, to prevent 23 zone contents collection via passive monitoring of zone transfers. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 14, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 5 62 4. Connection and Data Flows in Existing XFR Mechanisms . . . . 5 63 4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 8 66 4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Connections and Data Flows in XoT . . . . . . . . . . . . . . 8 69 5.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 8 70 5.2. Connection usage . . . . . . . . . . . . . . . . . . . . 8 71 5.2.1. High level XoT descriptions . . . . . . . . . . . . . 9 72 5.2.2. Previous specifications . . . . . . . . . . . . . . . 9 73 5.3. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 10 74 5.4. Connection Establishment . . . . . . . . . . . . . . . . 10 75 5.4.1. Draft Version Identification . . . . . . . . . . . . 11 76 5.5. Port selection . . . . . . . . . . . . . . . . . . . . . 11 77 5.6. AXoT mechanism . . . . . . . . . . . . . . . . . . . . . 11 78 5.6.1. Coverage and relationship to RFC5936 . . . . . . . . 12 79 5.6.2. AXoT connection and message handling . . . . . . . . 12 80 5.6.3. Padding AXoT responses . . . . . . . . . . . . . . . 14 81 5.7. IXoT mechanism . . . . . . . . . . . . . . . . . . . . . 15 82 5.7.1. Coverage and relationship to RFC1995 . . . . . . . . 15 83 5.7.2. IXoT connection and message handling . . . . . . . . 15 84 5.7.3. Condensation of responses . . . . . . . . . . . . . . 16 85 5.7.4. Fallback to AXFR . . . . . . . . . . . . . . . . . . 16 86 5.7.5. Padding of IXoT responses . . . . . . . . . . . . . . 16 87 6. Multi-primary Configurations . . . . . . . . . . . . . . . . 16 88 7. Zone Transfer with DoT - Authentication . . . . . . . . . . . 17 89 7.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 7.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 7.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 7.3.1. Opportunistic . . . . . . . . . . . . . . . . . . . . 18 93 7.3.2. Strict . . . . . . . . . . . . . . . . . . . . . . . 18 94 7.3.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 18 95 7.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 18 96 7.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 7.6. Comparison of Authentication Methods . . . . . . . . . . 19 98 8. Policies for Both AXFR and IXFR . . . . . . . . . . . . . . . 20 99 9. Implementation Considerations . . . . . . . . . . . . . . . . 21 100 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 101 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 102 11.1. Registration of XoT Identification String . . . . . . . 21 103 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 104 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 105 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 106 15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 107 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 108 16.1. Normative References . . . . . . . . . . . . . . . . . . 23 109 16.2. Informative References . . . . . . . . . . . . . . . . . 24 110 16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 113 1. Introduction 115 DNS has a number of privacy vulnerabilities, as discussed in detail 116 in [RFC7626]. Stub client to recursive resolver query privacy has 117 received the most attention to date, with standards track documents 118 for both DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) 119 [RFC8484], and a proposal for DNS-over-QUIC 120 [I-D.ietf-dprive-dnsoquic]. There is ongoing work on DNS privacy 121 requirements for exchanges between recursive resolvers and 122 authoritative servers [I-D.ietf-dprive-phase2-requirements] and some 123 suggestions for how signaling of DoT support by authoritatives might 124 work, e.g., [I-D.vandijk-dprive-ds-dot-signal-and-pin]. However 125 there is currently no RFC that specifically defines authoritative 126 support for DNS-over-TLS. 128 [RFC7626] established that stub client DNS query transactions are not 129 public and needed protection, but on zone transfer [RFC1995] 130 [RFC5936] it says only: 132 "Privacy risks for the holder of a zone (the risk that someone 133 gets the data) are discussed in [RFC5936] and [RFC5155]." 135 In what way is exposing the full contents of a zone a privacy risk? 136 The contents of the zone could include information such as names of 137 persons used in names of hosts. Best practice is not to use personal 138 information for domain names, but many such domain names exist. The 139 contents of the zone could also include references to locations that 140 allow inference about location information of the individuals 141 associated with the zone's organization. It could also include 142 references to other organizations. Examples of this could be: 144 o Person-laptop.example.org 145 o MX-for-Location.example.org 147 o Service-tenant-from-another-org.example.org 149 There may also be regulatory, policy or other reasons why the zone 150 contents in full must be treated as private. 152 Neither of the RFCs mentioned in [RFC7626] contemplates the risk that 153 someone gets the data through eavesdropping on network connections, 154 only via enumeration or unauthorized transfer as described in the 155 following paragraphs. 157 [RFC5155] specifies NSEC3 to prevent zone enumeration, which is when 158 queries for the authenticated denial of existences records of DNSSEC 159 allow a client to walk through the entire zone. Note that the need 160 for this protection also motivates NSEC5 [I-D.vcelak-nsec5]; zone 161 walking is now possible with NSEC3 due to crypto-breaking advances, 162 and NSEC5 is a response to this problem. 164 [RFC5155] does not address data obtained outside zone enumeration 165 (nor does [I-D.vcelak-nsec5]). Preventing eavesdropping of zone 166 transfers (this draft) is orthogonal to preventing zone enumeration, 167 though they aim to protect the same information. 169 [RFC5936] specifies using TSIG [RFC2845] for authorization of the 170 clients of a zone transfer and for data integrity, but does not 171 express any need for confidentiality, and TSIG does not offer 172 encryption. Some operators use SSH tunneling or IPSec to encrypt the 173 transfer data. 175 Because both AXFR and IXFR zone transfers are typically carried out 176 over TCP from authoritative DNS protocol implementations, encrypting 177 zone transfers using TLS, based closely on DoT [RFC7858], seems like 178 a simple step forward. This document specifies how to use TLS as a 179 transport to prevent zone collection from zone transfers. 181 2. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 185 "OPTIONAL" in this document are to be interpreted as described in BCP 186 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 187 capitals, as shown here. 189 Privacy terminology is as described in Section 3 of [RFC6973]. 191 Note that in this document we choose to use the terms 'primary' and 192 'secondary' for two servers engaged in zone transfers. 194 DNS terminology is as described in [RFC8499]. 196 DoT: DNS-over-TLS as specified in [RFC7858] 198 XoT: Generic XFR-over-TLS mechanisms as specified in this document 200 AXoT: AXFR-over-TLS 202 IXoT: IXFR over-TLS 204 3. Use Cases for XFR-over-TLS 206 o Confidentiality. Clearly using an encrypted transport for zone 207 transfers will defeat zone content leakage that can occur via 208 passive surveillance. 210 o Authentication. Use of single or mutual TLS authentication (in 211 combination with ACLs) can complement and potentially be an 212 alternative to TSIG. 214 o Performance. Existing AXFR and IXFR mechanisms have the burden of 215 backwards compatibility with older implementations based on the 216 original specifications in [RFC1034] and [RFC1035]. For example, 217 some older AXFR servers don't support using a TCP connection for 218 multiple AXFR sessions or XFRs of different zones because they 219 have not been updated to follow the guidance in [RFC5936]. Any 220 implementation of XFR-over-TLS (XoT) would obviously be required 221 to implement optimized and interoperable transfers as described in 222 [RFC5936], e.g., transfer of multiple zones over one connection. 224 o Performance. Current usage of TCP for IXFR is sub-optimal in some 225 cases i.e. connections are frequently closed after a single IXFR. 227 4. Connection and Data Flows in Existing XFR Mechanisms 229 The original specification for zone transfers in [RFC1034] and 230 [RFC1035] was based on a polling mechanism: a secondary performed a 231 periodic SOA query (based on the refresh timer) to determine if an 232 AXFR was required. 234 [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY 235 respectively, to provide for prompt propagation of zone updates. 236 This has largely replaced AXFR where possible, particularly for 237 dynamically updated zones. 239 [RFC5936] subsequently redefined the specification of AXFR to improve 240 performance and interoperability. 242 In this document we use the phrase "XFR mechanism" to describe the 243 entire set of message exchanges between a secondary and a primary 244 that concludes in a successful AXFR or IXFR request/response. This 245 set may or may not include 247 o NOTIFY messages 249 o SOA queries 251 o Fallback from IXFR to AXFR 253 o Fallback from IXFR-over-UDP to IXFR-over-TCP 255 The term is used to encompasses the range of permutations that are 256 possible and is useful to distinguish the 'XFR mechanism' from a 257 single XFR request/response exchange. 259 4.1. AXFR Mechanism 261 The figure below provides an outline of an AXFR mechanism including 262 NOTIFYs. 264 Figure 1. AXFR Mechanism [1] 266 1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP) 267 from the primary to the secondary. A secondary may also initiate 268 an AXFR based on a refresh timer or scheduled/triggered zone 269 maintenance. 271 2. The secondary will normally (but not always) make a SOA query to 272 the primary to obtain the serial number of the zone held by the 273 primary. 275 3. If the primary serial is higher than the secondaries serial 276 (using Serial Number Arithmetic [RFC1982]), the secondary makes 277 an AXFR request (over TCP) to the primary after which the AXFR 278 data flows in one or more AXFR responses on the TCP connection. 280 [RFC5936] specifies that AXFR must use TCP as the transport protocol 281 but details that there is no restriction in the protocol that a 282 single TCP connection must be used only for a single AXFR exchange, 283 or even solely for XFRs. For example, it outlines that the SOA query 284 can also happen on this connection. However, this can cause 285 interoperability problems with older implementations that support 286 only the trivial case of one AXFR per connection. 288 Further details of the limitations in existing AXFR implementations 289 are outlined in [RFC5936]. 291 4.2. IXFR Mechanism 293 The figure below provides an outline of the IXFR mechanism including 294 NOTIFYs. 296 Figure 1. IXFR Mechanism [2] 298 1. An IXFR is normally (but not always) preceded by a NOTIFY (over 299 UDP) from the primary to the secondary. A secondary may also 300 initiate an IXFR based on a refresh timer or scheduled/triggered 301 zone maintenance. 303 2. The secondary will normally (but not always) make a SOA query to 304 the primary to obtain the serial number of the zone held by the 305 primary. 307 3. If the primary serial is higher than the secondaries serial 308 (using Serial Number Arithmetic [RFC1982]), the secondary makes 309 an IXFR request to the primary after the primary sends an IXFR 310 response. 312 [RFC1995] specifies that Incremental Transfer may use UDP if the 313 entire IXFR response can be contained in a single DNS packet, 314 otherwise, TCP is used. In fact is says in non-normative language: 316 "Thus, a client should first make an IXFR query using UDP." 318 So there may be a forth step above where the client falls back to 319 IXFR-over-TCP. There may also be a forth step where the secondary 320 must fall back to AXFR because, e.g., the primary does not support 321 IXFR. 323 However it is noted that at least two widely used open source 324 authoritative nameserver implementations (BIND [3] and NSD [4]) do 325 IXFR using TCP by default in their latest releases. For BIND TCP 326 connections are sometimes used for SOA queries but in general they 327 are not used persistently and close after an IXFR is completed. 329 It is noted that the specification for IXFR was published well before 330 TCP was considered a first class transport for DNS. This document 331 therefore updates [RFC1995] to state that DNS implementations that 332 support IXFR-over-TCP MUST use [RFC7766] to optimize the use of TCP 333 connections and SHOULD use [RFC7858] to manage persistent 334 connections. 336 4.3. Data Leakage of NOTIFY and SOA Message Exchanges 338 This section attempts to presents a rationale for also encrypting the 339 other messages in the XFR mechanism. 341 Since the SOA of the published zone can be trivially discovered by 342 simply querying the publicly available authoritative servers leakage 343 of this RR is not discussed in the following sections. 345 4.3.1. NOTIFY 347 Unencrypted NOTIFY messages identify configured secondaries on the 348 primary. 350 [RFC1996] also states: 352 "If ANCOUNT>0, then the answer section represents an 353 unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE). 355 But since the only supported QTYPE for NOTIFY is SOA, this does not 356 pose a potential leak. 358 4.3.2. SOA 360 For hidden primaries or secondaries the SOA response leaks the degree 361 of lag of any downstream secondary. 363 5. Connections and Data Flows in XoT 365 5.1. TLS versions 367 For improved security all implementations of this specification MUST 368 use only TLS 1.3 [RFC8446] or later. 370 5.2. Connection usage 372 It is useful to note that in these mechanisms it is the secondary 373 that initiates the TLS connection to the primary for a XFR request, 374 so that in terms of connectivity the secondary is the TLS client and 375 the primary the TLS server. 377 The details in [RFC7766], [RFC7858] and [RFC8310] about, e.g., 378 persistent connection and message handling are fully applicable to 379 XoT as well. However any behavior specified here takes precedence 380 for XoT. 382 5.2.1. High level XoT descriptions 384 The figure below provides an outline of the AXoT mechanism including 385 NOTIFYs. 387 Figure 3: AXoT mechanism [5] 389 The figure below provides an outline of the IXoT mechanism including 390 NOTIFYs. 392 Figure 4: IXoT mechanism [6] 394 5.2.2. Previous specifications 396 We note that whilst [RFC5936] already recommends re-using open TCP 397 connections, it does state: 399 "Non-AXFR session traffic can also use an open TCP connection." 401 when discussing AXFR-over-TCP. It defines an AXFR session as an AXFR 402 query message and the sequence of AXFR response messages returned for 403 it. Note that this excludes any SOA queries issued as part of the 404 overall AXFR mechanism. This requirement needs to be re-evaluated 405 when considering applying the same model to XoT since 407 o There is no guarantee that a XoT server (which is very likely, but 408 not necessarily, a purely authoritative server) will also support 409 DoT for regular queries. Requiring a purely authoritative server 410 to also respond to any query over a TLS connection would be 411 equivalent to defining a form of authoritative DoT. We consider 412 this to be out of scope for this document, which is focussed 413 purely on zone transfers. 415 o It would, however, be optimal for XoT to include the capability to 416 send SOA queries over an already open TLS connection. 418 Moreover, it is worth noting that [RFC7766] made general 419 implementation recommendations with regard to TCP/TLS connection 420 handling: 422 "To mitigate the risk of unintentional server overload, DNS 423 clients MUST take care to minimize the number of concurrent TCP 424 connections made to any individual server. It is RECOMMENDED 425 that for any given client/server interaction there SHOULD be no 426 more than one connection for regular queries, one for zone 427 transfers, and one for each protocol that is being used on top 428 of TCP (for example, if the resolver was using TLS). However, 429 it is noted that certain primary/ secondary configurations with 430 many busy zones might need to use more than one TCP connection 431 for zone transfers for operational reasons (for example, to 432 support concurrent transfers of multiple zones)." 434 Whilst this recommends a particular behavior for the clients using 435 TCP, it does not relax the requirement for servers to handle 'mixed' 436 traffic (regular queries and zone transfers) on any open TCP/TLS 437 connection. It also overlooks the potential that other transports 438 might want to take the same approach with regard to using separate 439 connections for different purposes. 441 5.3. Update to RFC7766 443 This specification for XoT updates the guidance in [RFC7766] to 444 provide the same separation of connection purpose (regular queries 445 and zone transfers) for all transports being used on top of TCP. 446 Therefore, it is RECOMMENDED that for each protocol used on top of 447 TCP in any given client/server interaction there SHOULD be no more 448 than one connection for regular queries and one for zone transfers. 449 We provide specific details in the following sections of reasons 450 where more than one connection might be required for zone transfers. 452 5.4. Connection Establishment 454 This specification additionally limits the scope of XoT as defined 455 here to be the use of dedicated TLS connections (XoT connections) to 456 exchange only traffic specific to enabling zone transfers. The set 457 of transactions supported on such connections is limited to: 459 o AXFR 461 o IXFR 463 o SOA 465 and is collectively referred to hereafter as 'XoT traffic'. 467 Such connections MUST use an ALPN token of 'xot' during the TLS 468 handshake (see Section 11). 470 In the absence of DNS specific capability signaling mechanisms this 471 greatly simplifies the implementation of XoT such that a XoT exchange 472 can occur between any primary and secondary regardless of the role of 473 each (e.g. purely authoritative, recursive resolver also 474 authoritatively hosting zones, stub) or of other DNS transport 475 capability each may have. It also clearly makes XoT support 476 orthogonal to any set of zone transfer authentication mechanisms 477 chosen by the two parties. 479 XoT clients MUST only send XoT traffic on XoT connections. If a XoT 480 server receives traffic other than XoT traffic on a XoT connection it 481 MUST respond with the extended DNS error code 21 - Not Supported 482 [I-D.ietf-dnsop-extended-error]. It SHOULD treat this as protocol 483 error and close the connection. 485 With the update to [RFC7766] guidance above, clients are free to open 486 separate connections to the server to make any other queries they may 487 need over either TLS, TCP or UDP. A specification for connections 488 that support both XoT traffic and non-XoT traffic may be the subject 489 of a future work. 491 5.4.1. Draft Version Identification 493 _RFC Editor's Note:_ Please remove this section prior to publication 494 of a final version of this document. 496 Only implementations of the final, published RFC can identify 497 themselves as "xot". Until such an RFC exists, implementations MUST 498 NOT identify themselves using this string. 500 Implementations of draft versions of the protocol MUST add the string 501 "-" and the corresponding draft number to the identifier. For 502 example, draft-ietf-dprive-xfr-over-tls-02 is identified using the 503 string "xot-02". 505 5.5. Port selection 507 The connection for XoT SHOULD be established using port 853, as 508 specified in [RFC7858], unless there is mutual agreement between the 509 secondary and primary to use a port other than port 853 for XoT. 510 There MAY be agreement to use different ports for AXoT and IXoT. 512 5.6. AXoT mechanism 513 5.6.1. Coverage and relationship to RFC5936 515 [RFC5936] re-specified AXFR providing additional guidance beyond that 516 provided in [RFC1034] and [RFC1035]. For example, sections 4.1, 517 4.1.1 and 4.1.2 of [RFC5936] provide improved guidance for AXFR 518 clients and servers with regard to re-use of connections for multiple 519 AXFRs and AXFRs of different zones. However [RFC5936] was 520 constrained by having to be backwards compatible with some very early 521 basic implementations of AXFR. 523 Here we specify some optimized behaviors for AXoT, based closely on 524 those in [RFC5936], but without the constraint of backwards 525 compatibility since it is expected that all implementations of AXoT 526 fully implement the behavior described here. 528 Where any behavior is not explicitly described here, the behavior 529 specified in [RFC5936] MUST be followed. Any behavior specified here 530 takes precedence for AXoT implementations over that in [RFC5936]. 532 5.6.2. AXoT connection and message handling 534 The first paragraph of Section 4.1.1 of [RFC5936] says that clients 535 SHOULD close the connection when there is no 'apparent need' to use 536 the connection for some time period. 538 For AXoT this requirement is updated: AXoT clients and servers SHOULD 539 use EDNS0 Keepalive [RFC7828] to establish the connection timeouts to 540 be used. The client SHOULD send the EDNS0 Keepalive option on every 541 AXoT request sent so that the server has every opportunity to update 542 the Keepalive timeout. The AXoT server may use the frequency of 543 recent AXFRs to calculate an average update rate as input to the 544 decision of what EDNS0 Keepalive timeout to use. If the server does 545 not support EDNS0 Keepalive the client MAY keep the connection open 546 for a few seconds ([RFC7766] recommends that servers use timeouts of 547 at least a few seconds). 549 Whilst the specification for EDNS0 [RFC6891] does not specifically 550 mention AXFRs, it does say 552 "If an OPT record is present in a received request, compliant 553 responders MUST include an OPT record in their respective 554 responses." 556 We clarify here that if an OPT record is present in a received AXoT 557 request, compliant responders MUST include an OPT record in each of 558 the subsequent AXoT responses. Note that this requirement, combined 559 with the use of EDNS0 Keepalive, enables AXoT servers to signal the 560 desire to close a connection due to low resources by sending an EDNS0 561 Keepalive option with a timeout of 0 on any AXoT response (in the 562 absence of another way to signal the abort of a AXoT transfer). 564 An AXoT server MUST be able to handle multiple AXFR requests on a 565 single XoT connection (for the same and different zones). 567 [RFC5936] says: 569 "An AXFR client MAY use an already opened TCP connection to 570 start an AXFR session. Using an existing open connection is 571 RECOMMENDED over opening a new connection. (Non-AXFR session 572 traffic can also use an open connection.)" 574 For AXoT this requirement is updated: AXoT clients SHOULD re-use an 575 existing open XoT connection when starting any new AXoT session to 576 the same primary, and for issuing SOA queries, instead of opening a 577 new connection. The number of XoT connections between a secondary 578 and primary SHOULD be minimized. 580 Valid reasons for not re-using existing connections might include: 582 o reaching a configured limit for the number of outstanding queries 583 allowed on a single XoT connection 585 o the message ID pool has already been exhausted on an open 586 connection 588 o a large number of timeouts or slow responses have occurred on an 589 open connection 591 o an EDNS0 Keepalive option with a timeout of 0 has been received 592 from the server and the client is in the process of closing the 593 connection 595 If no XoT connections are currently open, AXoT clients MAY send SOA 596 queries over UDP, TCP or TLS. 598 [RFC5936] says: 600 "Some old AXFR clients expect each response message to contain 601 only a single RR. To interoperate with such clients, the server 602 MAY restrict response messages to a single RR." 604 This is opposed to the normal behavior of containing a sufficient 605 number of RRs to reasonably amortize the per-message overhead. We 606 clarify here that AXoT clients MUST be able to handle responses that 607 include multiple RRs, up to the largest number that will fit within a 608 DNS message (taking the required content of the other sections into 609 account, as described here and in [RFC5936]). This removes any 610 burden on AXoT servers of having to accommodate a configuration 611 option or support for restricting responses to containing only a 612 single RR. 614 An AXoT client SHOULD pipeline AXFR requests for different zones on a 615 single XoT connection. An AXoT server SHOULD respond to those 616 requests as soon as the response is available i.e. potentially out of 617 order. 619 5.6.3. Padding AXoT responses 621 The goal of padding AXoT responses would be two fold: 623 o to obfuscate the actual size of the transferred zone to minimize 624 information leakage about the entire contents of the zone. 626 o to obfuscate the incremental changes to the zone between SOA 627 updates to minimize information leakage about zone update activity 628 and growth. 630 Note that the re-use of XoT connections for transfers of multiple 631 different zones complicates any attempt to analyze the traffic size 632 and timing to extract information. 634 We note here that any requirement to obfuscate the total zone size is 635 likely to require a server to create 'empty' AXoT responses. That 636 is, AXoT responses that contain no RR's apart from an OPT RR 637 containing the EDNS(0) option for padding. However, as with existing 638 AXFR, the last AXoT response message sent MUST contain the same SOA 639 that was in the first message of the AXoT response series in order to 640 signal the conclusion of the zone transfer. 642 [RFC5936] says: 644 "Each AXFR response message SHOULD contain a sufficient number 645 of RRs to reasonably amortize the per-message overhead, up to 646 the largest number that will fit within a DNS message (taking 647 the required content of the other sections into account, as 648 described below)." 650 'Empty' AXoT responses generated in order to meet a padding 651 requirement will be exceptions to the above statement. In order to 652 guarantee support for future padding policies, we state here that 653 secondary implementations MUST be resilient to receiving padded AXoT 654 responses, including 'empty' AXoT responses that contain only an OPT 655 RR containing the EDNS(0) option for padding. 657 Recommendation of specific policies for padding AXoT responses are 658 out of scope for this specification. Detailed considerations of such 659 policies and the trade-offs involved are expected to be the subject 660 of future work. 662 5.7. IXoT mechanism 664 5.7.1. Coverage and relationship to RFC1995 666 [RFC1995] says nothing with respect to optimizing IXFRs over TCP or 667 re-using already open TCP connections to perform IXFRs or other 668 queries. Therefore, there arguably is an implicit assumption 669 (probably unintentional) that a TCP connection is used for one and 670 only one IXFR request. Indeed, several open source implementations 671 currently take this approach. 673 We provide new guidance here specific to IXoT that aligns with the 674 guidance in [RFC5936] for AXFR, that in section Section 5.6 for AXoT, 675 and with that for performant TCP/TLS usage in [RFC7766] and 676 [RFC7858]. 678 Where any behavior is not explicitly described here, the behavior 679 specified in [RFC1995] MUST be followed. Any behavior specified here 680 takes precedence for IXoT implementations over that in [RFC1995]. 682 5.7.2. IXoT connection and message handling 684 In a manner entirely analogous to that described in paragraph 2 of 685 Section 5.6.2 IXoT clients and servers SHOULD use EDNS0 Keepalive 686 [RFC7828] to establish the connection timeouts to be used. 688 An IXoT server MUST be able to handle multiple IXoT requests on a 689 single XoT connection (for the same and different zones). 691 IXoT clients SHOULD re-use an existing open XoT connection when 692 making any new IXoT request to the same primary, and for issuing SOA 693 queries, instead of opening a new connection. The number of XoT 694 connections between a secondary and primary SHOULD be minimized. 696 Valid reasons for not re-using existing connections are the same as 697 those described in Section 5.6.2 699 If no XoT connections are currently open, IXoT clients MAY send SOA 700 queries over UDP, TCP or TLS. 702 An IXoT client SHOULD pipeline IXFR requests for different zones on a 703 single XoT connection. An IXoT server SHOULD respond to those 704 requests as soon as the response is available i.e. potentially out of 705 order. 707 5.7.3. Condensation of responses 709 [RFC1995] says condensation of responses is optional and MAY be done. 710 Whilst it does add complexity to generating responses it can 711 significantly reduce the size of responses. However any such 712 reduction might be offset by increased message size due to padding. 713 This specification does not update the optionality of condensation. 715 5.7.4. Fallback to AXFR 717 Fallback to AXFR can happen, for example, if the server is not able 718 to provide an IXFR for the requested SOA. Implementations differ in 719 how long they store zone deltas and how many may be stored at any one 720 time. 722 After a failed IXFR a IXoT client SHOULD request the AXFR on the 723 already open XoT connection. 725 5.7.5. Padding of IXoT responses 727 The goal of padding IXoT responses would be to obfuscate the 728 incremental changes to the zone between SOA updates to minimize 729 information leakage about zone update activity and growth. Both the 730 size and timing of the IXoT responses could reveal information. 732 IXFR responses can vary in size greatly from the order of 100 bytes 733 for one or two record updates, to tens of thousands of bytes for 734 large dynamic DNSSEC signed zones. The frequency of IXFR responses 735 can also depend greatly on if and how the zone is DNSSEC signed. 737 In order to guarantee support for future padding policies, we state 738 here that secondary implementations MUST be resilient to receiving 739 padded IXoT responses. 741 Recommendation of specific policies for padding IXoT responses are 742 out of scope for this specification. Detailed considerations of such 743 policies and the trade-offs involved are expected to be the subject 744 of future work. 746 6. Multi-primary Configurations 748 Also known as multi-master configurations this model can provide 749 flexibility and redundancy particularly for IXFR. A secondary will 750 receive one or more NOTIFY messages and can send an SOA to all of the 751 configured primaries. It can then choose to send an XFR request to 752 the primary with the highest SOA (or other criteria, e.g., RTT). 754 When using persistent connections the secondary may have a XoT 755 connection already open to one or more primaries. Should a secondary 756 preferentially request an XFR from a primary to which it already has 757 an open XoT connection or the one with the highest SOA (assuming it 758 doesn't have a connection open to it already)? 760 Two extremes can be envisaged here. The first one can be considered 761 a 'preferred primary connection' model. In this case the secondary 762 continues to use one persistent connection to a single primary until 763 it has reason not to. Reasons not to might include the primary 764 repeatedly closing the connection, long RTTs on transfers or the SOA 765 of the primary being an unacceptable lag behind the SOA of an 766 alternative primary. 768 The other extreme can be considered a 'parallel primary connection' 769 model. Here a secondary could keep multiple persistent connections 770 open to all available primaries and only request XFRs from the 771 primary with the highest serial number. Since normally the number of 772 secondaries and primaries in direct contact in a transfer group is 773 reasonably low this might be feasible if latency is the most 774 significant concern. 776 Recommendation of a particular scheme is out of scope of this 777 document but implementations are encouraged to provide configuration 778 options that allow operators to make choices about this behavior. 780 7. Zone Transfer with DoT - Authentication 782 7.1. TSIG 784 TSIG [RFC2845] provides a mechanism for two or more parties to use 785 shared secret keys which can then be used to create a message digest 786 to protect individual DNS messages. This allows each party to 787 authenticate that a request or response (and the data in it) came 788 from the other party, even if it was transmitted over an unsecured 789 channel or via a proxy. It provides party-to-party data 790 authentication, but not hop-to-hop channel authentication or 791 confidentiality. 793 7.2. SIG(0) 795 SIG(0) [RFC2535] similarly also provides a mechanism to digitally 796 sign a DNS message but uses public key authentication, where the 797 public keys are stored in DNS as KEY RRs and a private key is stored 798 at the signer. It also provides party-to-party data authentication, 799 but not hop-to-hop channel authentication or confidentiality. 801 7.3. TLS 803 7.3.1. Opportunistic 805 Opportunistic TLS [RFC8310] provides a defense against passive 806 surveillance, providing on-the-wire confidentiality. 808 7.3.2. Strict 810 Strict TLS [RFC8310] requires that a client is configured with an 811 authentication domain name (and/or SPKI pinset) that should be used 812 to authenticate the TLS handshake with the server. This additionally 813 provides a defense for the client against active surveillance, 814 providing client-to-server authentication and end-to-end channel 815 confidentiality. 817 7.3.3. Mutual 819 This is an extension to Strict TLS [RFC8310] which requires that a 820 client is configured with an authentication domain name (and/or SPKI 821 pinset) and a client certificate. The client offers the certificate 822 for authentication by the server and the client can authentic the 823 server the same way as in Strict TLS. This provides a defense for 824 both parties against active surveillance, providing bi-directional 825 authentication and end-to-end channel confidentiality. 827 7.4. IP Based ACL on the Primary 829 Most DNS server implementations offer an option to configure an IP 830 based Access Control List (ACL), which is often used in combination 831 with TSIG based ACLs to restrict access to zone transfers on primary 832 servers. 834 This is also possible with XoT but it must be noted that as with TCP 835 the implementation of such an ACL cannot be enforced on the primary 836 until a XFR request is received on an established connection. 838 If control were to be any more fine-grained than this then a 839 separate, dedicated port would need to be agreed between primary and 840 secondary for XoT such that implementations would be able to refuse 841 connections on that port to all clients except those configured as 842 secondaries. 844 7.5. ZONEMD 846 Message Digest for DNS Zones (ZONEMD) 847 [I-D.ietf-dnsop-dns-zone-digest] digest is a mechanism that can be 848 used to verify the content of a standalone zone. It is designed to 849 be independent of the transmission channel or mechanism, allowing a 850 general consumer of a zone to do origin authentication of the entire 851 zone contents. Note that the current version of 852 [I-D.ietf-dnsop-dns-zone-digest] states: 854 "As specified at this time, ZONEMD is not designed for use in large, 855 dynamic zones due to the time and resources required for digest 856 calculation. The ZONEMD record described in this document includes 857 fields reserved for future work to support large, dynamic zones." 859 It is complementary the above mechanisms and can be used in 860 conjunction with XoT but is not considered further. 862 7.6. Comparison of Authentication Methods 864 The Table below compares the properties of a selection of the above 865 methods in terms of what protection they provide to the secondary and 866 primary servers during XoT in terms of: 868 o 'Data Auth': Authentication that the DNS message data is signed by 869 the party with whom credentials were shared (the signing party may 870 or may not be party operating the far end of a TCP/TLS connection 871 in a 'proxy' scenario). For the primary the TSIG on the XFR 872 request confirms that the requesting party is authorized to 873 request zone data, for the secondary it authenticates the zone 874 data that is received. 876 o 'Channel Conf': Confidentiality of the communication channel 877 between the client and server (i.e. the two end points of a TCP/ 878 TLS connection). 880 o Channel Auth: Authentication of the identity of party to whom a 881 TCP/TLS connection is made (this might not be a direct connection 882 between the primary and secondary in a proxy scenario). 884 It is noted that zone transfer scenarios can vary from a simple 885 single primary/secondary relationship where both servers are under 886 the control of a single operator to a complex hierarchical structure 887 which includes proxies and multiple operators. Each deployment 888 scenario will require specific analysis to determine which 889 authentication methods are best suited to the deployment model in 890 question. 892 Table 1: Properties of Authentication methods for XoT [7] 894 Based on this analysis it can be seen that: 896 o A combination of Opportunistic TLS and TSIG provides both data 897 authentication and channel confidentiality for both parties. 898 However this does not stop a MitM attack on the channel which 899 could be used to gather zone data. 901 o Using just mutual TLS can be considered a standalone solution if 902 the secondary has reason to place equivalent trust in channel 903 authentication as data authentication, e.g., the same operator 904 runs both the primary and secondary. 906 o Using TSIG, Strict TLS and an ACL on the primary provides all 3 907 properties for both parties with probably the lowest operational 908 overhead. 910 8. Policies for Both AXFR and IXFR 912 We call the entire group of servers involved in XFR (all the 913 primaries and all the secondaries) the 'transfer group'. 915 Within any transfer group both AXFRs and IXFRs for a zone SHOULD all 916 use the same policy, e.g., if AXFRs use AXoT all IXFRs SHOULD use 917 IXoT. 919 In order to assure the confidentiality of the zone information, the 920 entire transfer group MUST have a consistent policy of requiring 921 confidentiality. If any do not, this is a weak link for attackers to 922 exploit. 924 A XoT policy should specify 926 o If TSIG or SIG(0) is required 928 o What kind of TLS is required (Opportunistic, Strict or mTLS) 930 o If IP based ACLs should also be used. 932 Since this may require configuration of a number of servers who may 933 be under the control of different operators the desired consistency 934 could be hard to enforce and audit in practice. 936 Certain aspects of the Policies can be relatively easily tested 937 independently, e.g., by requesting zone transfers without TSIG, from 938 unauthorized IP addresses or over cleartext DNS. Other aspects such 939 as if a secondary will accept data without a TSIG digest or if 940 secondaries are using Strict as opposed to Opportunistic TLS are more 941 challenging. 943 The mechanics of co-ordinating or enforcing such policies are out of 944 the scope of this document but may be the subject of future 945 operational guidance. 947 9. Implementation Considerations 949 TBD 951 10. Implementation Status 953 The 1.9.2 version of Unbound [8] includes an option to perform AXoT 954 (instead of AXFR-over-TCP). This requires the client (secondary) to 955 authenticate the server (primary) using a configured authentication 956 domain name. 958 It is noted that use of a TLS proxy in front of the primary server is 959 a simple deployment solution that can enable server side XoT. 961 11. IANA Considerations 963 11.1. Registration of XoT Identification String 965 This document creates a new registration for the identification of 966 XoT in the "Application Layer Protocol Negotiation (ALPN) Protocol 967 IDs" registry [RFC7301]. 969 The "xot" string identifies XoT: 971 Protocol: XoT 973 Identification Sequence: 0x64 0x6F 0x72 ("xot") 975 Specification: This document 977 12. Security Considerations 979 This document specifies a security measure against a DNS risk: the 980 risk that an attacker collects entire DNS zones through eavesdropping 981 on clear text DNS zone transfers. 983 This does not mitigate: 985 o the risk that some level of zone activity might be inferred by 986 observing zone transfer sizes and timing on encrypted connections 987 (even with padding applied), in combination with obtaining SOA 988 records by directly querying authoritative servers. 990 o the risk that hidden primaries might be inferred or identified via 991 observation of encrypted connections. 993 o the risk of zone contents being obtained via zone enumeration 994 techniques. 996 Security concerns of DoT are outlined in [RFC7858] and [RFC8310]. 998 13. Acknowledgements 1000 The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for 1001 review and discussions. 1003 14. Contributors 1005 Significant contributions to the document were made by: 1007 Han Zhang 1008 Salesforce 1009 San Francisco, CA 1010 United States 1012 Email: hzhang@salesforce.com 1014 15. Changelog 1016 draft-ietf-dprive-xfr-over-tls-02 1018 o Significantly update descriptions for both AXoT and IXoT for 1019 message and connection handling taking into account previous 1020 specifications in more detail 1022 o Add use of APLN and limitations on traffic on XoT connections. 1024 o Add new discussions of padding for both AXoT and IXoT 1026 o Add text on SIG(0) 1028 o Update security considerations 1030 o Move multi-primary considerations to earlier as they are related 1031 to connection handling 1033 draft-ietf-dprive-xfr-over-tls-01 1034 o Minor editorial updates 1036 o Add requirement for TLS 1.3. or later 1038 draft-ietf-dprive-xfr-over-tls-00 1040 o Rename after adoption and reference update. 1042 o Add placeholder for SIG(0) discussion 1044 o Update section on ZONEMD 1046 draft-hzpa-dprive-xfr-over-tls-02 1048 o Substantial re-work of the document. 1050 draft-hzpa-dprive-xfr-over-tls-01 1052 o Editorial changes, updates to references. 1054 draft-hzpa-dprive-xfr-over-tls-00 1056 o Initial commit 1058 16. References 1060 16.1. Normative References 1062 [I-D.vcelak-nsec5] 1063 Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and 1064 D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of 1065 Existence", draft-vcelak-nsec5-08 (work in progress), 1066 December 2018. 1068 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1069 DOI 10.17487/RFC1995, August 1996, . 1072 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1073 Requirement Levels", BCP 14, RFC 2119, 1074 DOI 10.17487/RFC2119, March 1997, . 1077 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 1078 Wellington, "Secret Key Transaction Authentication for DNS 1079 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 1080 . 1082 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1083 Security (DNSSEC) Hashed Authenticated Denial of 1084 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1085 . 1087 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1088 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1089 . 1091 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1092 Morris, J., Hansen, M., and R. Smith, "Privacy 1093 Considerations for Internet Protocols", RFC 6973, 1094 DOI 10.17487/RFC6973, July 2013, . 1097 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 1098 DOI 10.17487/RFC7626, August 2015, . 1101 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1102 and P. Hoffman, "Specification for DNS over Transport 1103 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1104 2016, . 1106 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1107 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1108 May 2017, . 1110 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1111 for DNS over TLS and DNS over DTLS", RFC 8310, 1112 DOI 10.17487/RFC8310, March 2018, . 1115 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1116 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1117 . 1119 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1120 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1121 January 2019, . 1123 16.2. Informative References 1125 [I-D.ietf-dnsop-dns-zone-digest] 1126 Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. 1127 Hardaker, "Message Digest for DNS Zones", draft-ietf- 1128 dnsop-dns-zone-digest-08 (work in progress), June 2020. 1130 [I-D.ietf-dnsop-extended-error] 1131 Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 1132 Lawrence, "Extended DNS Errors", draft-ietf-dnsop- 1133 extended-error-16 (work in progress), May 2020. 1135 [I-D.ietf-dprive-dnsoquic] 1136 Huitema, C., Mankin, A., and S. Dickinson, "Specification 1137 of DNS over Dedicated QUIC Connections", draft-ietf- 1138 dprive-dnsoquic-00 (work in progress), April 2020. 1140 [I-D.ietf-dprive-phase2-requirements] 1141 Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS 1142 Privacy Requirements for Exchanges between Recursive 1143 Resolvers and Authoritative Servers", draft-ietf-dprive- 1144 phase2-requirements-01 (work in progress), June 2020. 1146 [I-D.vandijk-dprive-ds-dot-signal-and-pin] 1147 Dijk, P., Geuze, R., and E. Bretelle, "Signalling 1148 Authoritative DoT support in DS records, with key 1149 pinning", draft-vandijk-dprive-ds-dot-signal-and-pin-00 1150 (work in progress), May 2020. 1152 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1153 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1154 . 1156 [RFC1035] Mockapetris, P., "Domain names - implementation and 1157 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1158 November 1987, . 1160 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1161 DOI 10.17487/RFC1982, August 1996, . 1164 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1165 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1166 August 1996, . 1168 [RFC2535] Eastlake 3rd, D., "Domain Name System Security 1169 Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, 1170 . 1172 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1173 for DNS (EDNS(0))", STD 75, RFC 6891, 1174 DOI 10.17487/RFC6891, April 2013, . 1177 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1178 D. Wessels, "DNS Transport over TCP - Implementation 1179 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1180 . 1182 16.3. URIs 1184 [1] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/ 1185 master/02-draft-dprive-svg/AXFR_mechanism.svg 1187 [2] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/ 1188 master/02-draft-dprive-svg/IXFR_mechanism.svg 1190 [3] https://www.isc.org/bind/ 1192 [4] https://www.nlnetlabs.nl/projects/nsd/about/ 1194 [5] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/ 1195 master/02-draft-dprive-svg/AXoT_mechanism.svg 1197 [6] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/ 1198 master/02-draft-dprive-svg/IXoT_mechanism.svg 1200 [7] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ 1201 blob/02_updates/02-draft-svg/ 1202 Properties_of_Authentication_methods_for_XoT.svg 1204 [8] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ 1205 Changelog 1207 Authors' Addresses 1209 Willem Toorop 1210 NLnet Labs 1211 Science Park 400 1212 Amsterdam 1098 XH 1213 The Netherlands 1215 Email: willem@nlnetlabs.nl 1216 Sara Dickinson 1217 Sinodun IT 1218 Magdalen Centre 1219 Oxford Science Park 1220 Oxford OX4 4GA 1221 United Kingdom 1223 Email: sara@sinodun.com 1225 Shivan Sahib 1226 Salesforce 1227 Vancouver, BC 1228 Canada 1230 Email: ssahib@salesforce.com 1232 Pallavi Aras 1233 Salesforce 1234 Herndon, VA 1235 United States 1237 Email: paras@salesforce.com 1239 Allison Mankin 1240 Salesforce 1241 Herndon, VA 1242 United States 1244 Email: allison.mankin@gmail.com