idnits 2.17.00 (12 Aug 2021) /tmp/idnits58932/draft-zatda-dprive-xfr-using-dso-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 8, 2019) is 1041 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 902 == Missing Reference: 'RFC7719' is mentioned on line 195, but not defined ** Obsolete undefined reference: RFC 7719 (Obsoleted by RFC 8499) == Missing Reference: 'RFC8446' is mentioned on line 299, but not defined == Outdated reference: A later version (-02) exists of draft-hzpa-dprive-xfr-over-tls-01 == Outdated reference: draft-ietf-dnssd-push has been published as RFC 8765 ** Downref: Normative reference to an Informational RFC: RFC 6973 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 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 Intended status: Standards Track Salesforce 5 Expires: January 9, 2020 W. Toorop 6 NLnet Labs 7 S. Dickinson 8 Sinodun IT 9 A. Mankin 10 Salesforce 11 July 8, 2019 13 DNS Zone Transfer using DNS Stateful Operations 14 draft-zatda-dprive-xfr-using-dso-00 16 Abstract 18 DNS zone transfers are transmitted in clear text, which gives 19 attackers the opportunity to collect the content of a zone by 20 eavesdropping on network connections. This document specifies use of 21 DNS Stateful Operations to enable a subscribe/publish mechanism for 22 zone transfers reducing the over head introduced by NOTITY/SOA 23 interactions prior to zone transfer request. This additionally 24 prevents zone contents collection via passive monitoring of zone 25 transfers by restricting XFR using DSO to require TLS. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Use Cases for XFR-using-DSO . . . . . . . . . . . . . . . . . 4 64 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6. State Considerations . . . . . . . . . . . . . . . . . . . . 5 67 7. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 68 7.1. XuD SUBSCRIBE-XFR . . . . . . . . . . . . . . . . . . . . 6 69 7.1.1. SUBSCRIBE-XFR Request . . . . . . . . . . . . . . . . 7 70 7.1.2. SUBSCRIBE-XFR Response . . . . . . . . . . . . . . . 9 71 7.2. XuD Notifications . . . . . . . . . . . . . . . . . . . . 12 72 7.2.1. DSO-IXFR Message . . . . . . . . . . . . . . . . . . 13 73 7.2.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 14 74 7.3. XuD UNSUBSCRIBE-XFR . . . . . . . . . . . . . . . . . . . 15 75 7.3.1. UNSUBSCRIBE-XFR Message . . . . . . . . . . . . . . . 15 76 7.4. Authentication . . . . . . . . . . . . . . . . . . . . . 17 77 7.5. Multi-primary configurations . . . . . . . . . . . . . . 17 78 7.6. DNS Stateful Operations TLV Context Summary . . . . . . . 17 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 9. Implementation Considerations . . . . . . . . . . . . . . . . 18 81 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 83 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 84 13. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 14.1. Normative References . . . . . . . . . . . . . . . . . . 19 87 14.2. Informative References . . . . . . . . . . . . . . . . . 20 88 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 [I-D.hzpa-dprive-xfr-over-tls] enumerates the existing issues with 94 clear text XFR mechanisms, outlines some use cases for using 95 encrypted channels for zone transfer and also describes using TLS for 96 zone transfers. It additionally discusses the various authentication 97 mechanisms that can be used to provide data and channel 98 authentication, and channel confidentiality. 100 This draft describes the use of a DSO [RFC8490] based protocol to 101 perform zone transfers. This mechanism is heavily based on an 102 existing use of DSO where DNS clients can subscribe to receive 103 asynchronous notifications of changes to RRSets of interest: DNS PUSH 104 Notifications [I-D.ietf-dnssd-push]. That specification was 105 developed with DNS Service Discovery in mind, this document describes 106 an analogous protocol (XFR-using-DSO) where DNS clients can subscribe 107 to receive asynchronous notifications of changes to zones of 108 interest, it is developed with efficient and confidential zone 109 transfers between primaries and secondaries in mind. 111 In the XFR-using-DSO model, a DSO connection is first opened between 112 the client and server, the client can then subscribe to one or more 113 zones to be notified of changes and the server can publish changes to 114 the zone over the connection. Clients can choose to unsubscribe from 115 zone updates at any time. 117 Servers could also use the DSO session to send command-style messages 118 to the client, for example, to instruct a client to stop serving a 119 zone or delete a zone. No such commands are defined in this version 120 of the specification, but will likely be added in a future version. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 Privacy terminology is as described in Section 3 of [RFC6973]. 132 DNS terminology is as described in [RFC8499]. 134 Note that in this document we choose to use the terms 'primary' and 135 'secondary' for two servers engaged in zone transfers. 137 DoT: DNS-over-TLS as specified in [RFC7858] 139 XuD: XFR-using-DOS mechanisms as specified in this document 141 3. Use Cases for XFR-using-DSO 143 This section includes additional use cases in addition to those 144 specified in [I-D.hzpa-dprive-xfr-over-tls] that XuD can offer. 146 o Confidentiality. Since this mechanism could, in principle, 147 eliminate the need for NOTIFY and SOA queries it can provide 148 complete confidentiality for the entire zone transfer mechanism. 150 o Security. For some network configurations it is not desirable to 151 have port 53 on the secondary open to an untrusted network for the 152 sole purpose of receiving NOTIFYs. NOTIFYs can also be trivially 153 spoofed unless secured with TSIG. For the DSO case, secondaries 154 could initiate DSO connections to the primary and following that 155 server-initiated DSO NOTIFY messages could be sent on that 156 connection which could simultaneously be used for SOA and IXFR 157 requests. This would allow a firewall to be restricted to just 158 allowing outgoing connections from secondary to primary. Note 159 that a similar but more constrained mechanism exists for IXFR 160 whereby a short refresh period can be configured which triggers 161 periodic SOA/IXFR requests from the secondary. TODO: Look at the 162 details of the NSD implementation. 164 o Performance. For the DSO case, a new subscribe/publish mechanism 165 could be envisaged that greatly reducing the number of messages 166 required to perform one transfer. 168 o Improved error handling and retries. In the DSO case new explicit 169 error codes could be defined that allow a server to indicate the 170 reason for a failed or aborted XFR request. Also a new client 171 initiated message could be used to gracefully cancel AXFRs. 173 o New command channel. For the DSO case it would be possible to 174 include new server-initiated 'control' commands e.g. 'stop serving 175 this zone', 'delete this zone'. 177 QUESTION: Is there any case where the primary might want to initiate 178 the DSO connection to the secondary? 180 4. Overview 182 The figure below provides an outline of the XuD protocol. 184 Figure 1: XuD protocol [1] 186 A DNS XuD client subscribes for zone notifications for a particular 187 zone by connecting to the appropriate authoritative server for that 188 zone, and sending DSO message(s) indicating the zone(s) of interest. 190 When the client loses interest in receiving further updates to these 191 zones, it unsubscribes. 193 The authoritative server for a DNS zone is any server capable of 194 generating the correct change notifications for a zone. It may be a 195 primary, secondary, or stealth name server [RFC7719]. 197 Standard DNS Queries MAY be sent over a XuD (i.e., DSO) session. For 198 any zone for which the server is authoritative, it MUST respond 199 authoritatively for queries on names falling within that zone both 200 for normal DNS queries and for XuD subscriptions. For names for 201 which the server is acting as a recursive resolver, e.g. when the 202 server is the local recursive resolver, for any query for which it 203 supports XuD subscriptions, it MUST also support standard queries. 205 XuD imposes less load on the responding server than rapid polling 206 would, but XuD notifications do still have a cost, so XuD clients 207 MUST only create XuD subscriptions for zones they are authorised to 208 transfer. 210 Generally, as described in the DNS Stateful Operations specification 211 [RFC8490], a client must not keep a session to a server open 212 indefinitely if it has no subscriptions (or other operations) active 213 on that session. A client MAY close a session as soon as it becomes 214 idle, and then if needed in the future, open a new session when 215 required. Alternatively, a client MAY speculatively keep an idle 216 session open for some time, subject to the constraint that it MUST 217 NOT keep a session open that has been idle for more than the 218 session's idle timeout (15 seconds by default) [RFC8490]. 220 5. Transport 222 XuD clients MUST use DNS Stateful Operations [RFC8490] running over 223 TLS over TCP [RFC7858]. 225 The connection for XuD SHOULD be established using port 853, as 226 specified in [RFC7858], unless there is mutual agreement between the 227 secondary and primary to use a port other than port 853 for XuD. 229 QUESTION: Is there a use case to allow XuD over TCP where 230 confidentiality is not an issue e.g when the zone contents are 231 already publicly available? 233 6. State Considerations 235 Each XuD server is capable of handling some finite number of XuD 236 subscriptions. This number will vary from server to server and is 237 based on physical machine characteristics, network bandwidth, and 238 operating system resource allocation. After a client establishes a 239 session to a DNS server, each subscription is individually accepted 240 or rejected. Servers may employ various techniques to limit 241 subscriptions to a manageable level. Correspondingly, the client is 242 free to establish simultaneous sessions to alternate DNS servers that 243 support XuDs for the zone and distribute subscriptions at the 244 client's discretion. In this way, both clients and servers can react 245 to resource constraints. 247 7. Protocol Operation 249 The XuD protocol is a session-oriented protocol, and makes use of DNS 250 Stateful Operations (DSO) [RFC8490]. 252 For details of the DSO message format refer to the DNS Stateful 253 Operations specification [RFC8490]. Those details are not repeated 254 here. 256 XuD clients and servers MUST support DSO. A single server can 257 support DNS Queries, DNS Updates, and XuD (using DSO) on the same TCP 258 port. 260 A XuD exchange begins with the client making a TLS/TCP connection to 261 the appropriate server. 263 A typical XuD client will immediately issue a DSO Keepalive operation 264 to request a session timeout and/or keepalive interval longer than 265 the the 15-second default values, but this is not required. A XuD 266 client MAY issue other requests on the session first, and only issue 267 a DSO Keepalive operation later if it determines that to be 268 necessary. Sending either a DSO Keepalive operation or a XuD 269 subscription over the TLS/TCP connection to the server signals the 270 client's support of DSO and serves to establish a DSO session. 272 In accordance with the current set of active subscriptions, the 273 server sends relevant asynchronous XuD notifications to the client. 274 Note that a client MUST be prepared to receive (and silently ignore) 275 XuD notifications for subscriptions it has previously removed, since 276 there is no way to prevent the situation where a XuD notification is 277 in flight from server to client while the client's unsubscribe 278 message cancelling that subscription is simultaneously in flight from 279 client to server. 281 7.1. XuD SUBSCRIBE-XFR 283 After connecting, and requesting a longer idle timeout and/or 284 keepalive interval if necessary, a XuD client then indicates its 285 desire to receive XuD notifications for a given zone by sending a 286 SUBSCRIBE-XFR request to the server. A SUBSCRIBE-XFR request is 287 encoded in a DSO message [RFC8490]. This specification defines a 288 primary DSO TLV for XuD SUBSCRIBE-XFR Requests (tentatively DSO Type 289 Code 0x50). 291 DSO messages with the SUBSCRIBE-XFR TLV as the Primary TLV are not 292 permitted in early data. 294 The entity that initiates a SUBSCRIBE-XFR request is by definition 295 the client. A server MUST NOT send a SUBSCRIBE-XFR request over an 296 existing session from a client. If a server does send a SUBSCRIBE- 297 XFR request over a DSO session initiated by a client, this is a fatal 298 error and the client should immediately abort the connection with a 299 TLS close_notify alert. See Section 6.1 of [RFC8446]. 301 TODO: Need to define a DSO version of TSIG to cover the SUBSCRIBE-XFR 302 and DSO-XFR responses, since the Additional section count in DSO 303 message MUST be zero. Note the client only needs to use TSIG in the 304 SUBSCRIBE-XFR message to prove it is authorised to request zone 305 transfers, but all DSO-XFR messages should be signed if primary TSIG 306 is required for the authentication model in use. 308 7.1.1. SUBSCRIBE-XFR Request 310 A SUBSCRIBE-XFR request begins with the standard DSO 12-byte header 311 [RFC8490], followed by the SUBSCRIBE-XFR primary TLV. A SUBSCRIBE- 312 XFR request message is illustrated in Figure 2. 314 The MESSAGE ID field MUST be set to a unique value, that the client 315 is not using for any other active operation on this DSO session. For 316 the purposes here, a MESSAGE ID is in use on this session if the 317 client has used it in a request for which it has not yet received a 318 response, or if the client has used it for a subscription which it 319 has not yet cancelled using UNSUBSCRIBE-XFR. In the SUBSCRIBE-XFR 320 response the server MUST echo back the MESSAGE ID value unchanged. 322 The other header fields MUST be set as described in the DSO 323 specification [RFC8490]. The DNS OPCODE field contains the OPCODE 324 value for DNS Stateful Operations (6). The four count fields MUST be 325 zero, and the corresponding four sections MUST be empty (i.e., 326 absent). 328 The DSO-TYPE is SUBSCRIBE-XFR (tentatively 0x50). 330 The DSO-LENGTH is the length of the DSO-DATA that follows, which 331 specifies the name and class of the zone and optionally the SOA value 332 of the client's version of the zone. 334 If the client has no copy of the zone it MUST omit the SOA value to 335 indicate to the server that a DSO-AXFR is required in response (see 336 the next section). 338 1 1 1 1 1 1 339 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 340 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 341 | MESSAGE ID | \ 342 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 343 |QR| OPCODE(6) | Z | RCODE | | 344 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 345 | QDCOUNT (MUST BE ZERO) | | 346 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER 347 | ANCOUNT (MUST BE ZERO) | | 348 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 349 | NSCOUNT (MUST BE ZERO) | | 350 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 351 | ARCOUNT (MUST BE ZERO) | / 352 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 353 | DSO-TYPE = SUBSCRIBE-XFR (tentatively 0x50) | 354 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 355 | DSO-LENGTH (number of octets in DSO-DATA) | 356 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 357 | | \ 358 \ NAME \ | 359 \ \ | 360 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA 361 | CLASS | | 362 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 363 | SOA value | / 364 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 366 Figure 2: SUBSCRIBE-XFR Request 368 The DSO-DATA for a SUBSCRIBE-XFR request MUST contain exactly one 369 NAME, CLASS and SOA value. Since SUBSCRIBE-XFR requests are sent 370 over TCP, multiple SUBSCRIBE-XFR DSO request messages can be 371 concatenated in a single TCP stream and packed efficiently into TCP 372 segments. 374 If accepted, the subscription will stay in effect until the client 375 cancels the subscription using UNSUBSCRIBE-XFR or until the DSO 376 session between the client and the server is closed. 378 SUBSCRIBE-XFR requests on a given session MUST be unique. A client 379 MUST NOT send a SUBSCRIBE-XFR message that duplicates the NAME, CLASS 380 and SOA value of an existing active subscription on that DSO session. 381 For the purpose of this matching, the established DNS case- 382 insensitivity for US-ASCII letters applies (e.g., "example.com" and 383 "Example.com" are the same). If a server receives such a duplicate 384 SUBSCRIBE-XFR message this is an error and the server MUST 385 immediately terminate the connection with a TLS close_notify alert. 387 QUESTION: Is there a use case where a client may want to signal that 388 the version of the zone it holds has been updated via another 389 mechanism and the zone transfer should restart from a different SOA 390 than that currently exchanged between client and server? 392 DNS wildcarding is not supported. SUBSCRIBE-XFR requests received 393 for zones containing wildcards are considered an error (see below). 395 A CLASS of 'ANY' (255) is not supported. 397 7.1.2. SUBSCRIBE-XFR Response 399 Each SUBSCRIBE-XFR request generates exactly one SUBSCRIBE-XFR 400 response from the server. A SUBSCRIBE-XFR request message is 401 illustrated in Figure 3. 403 A SUBSCRIBE-XFR response begins with the standard DSO 12-byte header 404 [RFC8490]. The QR bit in the header is set indicating it is a 405 response. The header MAY be followed by one or more optional TLVs, 406 such as a Retry Delay TLV. 408 The MESSAGE ID field MUST echo the value given in the Message ID 409 field of the SUBSCRIBE-XFR request. This is how the client knows 410 which request is being responded to. 412 A SUBSCRIBE-XFR response message MUST NOT include a SUBSCRIBE-XFR 413 TLV. If a client receives a SUBSCRIBE-XFR response message 414 containing a SUBSCRIBE-XFR TLV then the response message is processed 415 but the SUBSCRIBE-XFR TLV MUST be silently ignored. 417 1 1 1 1 1 1 418 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 419 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 420 | MESSAGE ID | \ 421 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 422 |QR| OPCODE(6) | Z | RCODE | | 423 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 424 | QDCOUNT (MUST BE ZERO) | | 425 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER 426 | ANCOUNT (MUST BE ZERO) | | 427 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 428 | NSCOUNT (MUST BE ZERO) | | 429 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 430 | ARCOUNT (MUST BE ZERO) | / 431 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 433 Figure 3: SUBSCRIBE-XFR Response Message 435 In the SUBSCRIBE-XFR response the RCODE indicates whether or not the 436 subscription was accepted. Supported RCODEs are as follows: 438 +-----------+-------+-----------------------------------------------+ 439 | Mnemonic | Value | Description | 440 +-----------+-------+-----------------------------------------------+ 441 | NOERROR | 0 | SUBSCRIBE-XFR successful. | 442 | FORMERR | 1 | Server failed to process request due to a | 443 | | | malformed request. | 444 | SERVFAIL | 2 | Server failed to process request due to a | 445 | | | problem with the server. | 446 | NOTIMP | 4 | Server does not implement DSO. | 447 | REFUSED | 5 | Server refuses to process request for policy | 448 | | | or security reasons. | 449 | NOTAUTH | 9 | Server is not authoritative for the requested | 450 | | | name. | 451 | DSOTYPENI | 11 | SUBSCRIBE-XFR operation not supported. | 452 +-----------+-------+-----------------------------------------------+ 454 Table 1: SUBSCRIBE-XFR Response codes 456 This document specifies only these RCODE values for SUBSCRIBE-XFR 457 Responses. Servers sending SUBSCRIBE-XFR Responses SHOULD use one of 458 these values. Note that NXDOMAIN is not a valid RCODE in response to 459 a SUBSCRIBE-XFR Request. However, future circumstances may create 460 situations where other RCODE values are appropriate in SUBSCRIBE-XFR 461 Responses, so clients MUST be prepared to accept SUBSCRIBE-XFR 462 Responses with any other RCODE value. 464 If the server sends a nonzero RCODE in the SUBSCRIBE-XFR response, 465 that means: 467 a the client is (at least partially) misconfigured, 469 b the server resources are exhausted, or 471 c there is some other unknown failure on the server. 473 In any case, the client shouldn't retry the subscription to this 474 server right away. If a client has other authoritative servers 475 configured for a given zone an alternative server can be tried 476 immediately. 478 If the client has other successful subscriptions to this server, 479 these subscriptions remain even though additional subscriptions may 480 be refused. Neither the client nor the server are required to close 481 the connection, although, either end may choose to do so. 483 If the server sends a nonzero RCODE then it SHOULD append a Retry 484 Delay TLV [RFC8490] to the response specifying a delay before the 485 client attempts this operation again. Recommended values for the 486 delay for different RCODE values are given below. These recommended 487 values apply both to the default values a server should place in the 488 Retry Delay TLV, and the default values a client should assume if the 489 server provides no Retry Delay TLV. 491 For RCODE = 1 (FORMERR) the delay may be any value selected by the 492 implementer. A value of five minutes is RECOMMENDED, to reduce the 493 risk of high load from defective clients. 495 For RCODE = 2 (SERVFAIL) the delay should be chosen according to the 496 level of server overload and the anticipated duration of that 497 overload. By default, a value of one minute is RECOMMENDED. If a 498 more serious server failure occurs, the delay may be longer in 499 accordance with the specific problem encountered. 501 For RCODE = 4 (NOTIMP), which occurs on a server that doesn't 502 implement DNS Stateful Operations [RFC8490], it is unlikely that the 503 server will begin supporting DSO in the next few minutes, so the 504 retry delay SHOULD be one hour. Note that in such a case, a server 505 that doesn't implement DSO is unlikely to place a Retry Delay TLV in 506 its response, so this recommended value in particular applies to what 507 a client should assume by default. 509 For RCODE = 5 (REFUSED), which occurs on a server that implements 510 XuDs, but is currently configured to disallow XuDs, the retry delay 511 may be any value selected by the implementer and/or configured by the 512 operator. Since it is possible that the misconfiguration may be 513 repaired at any time, the retry delay should not be set too high. By 514 default, a value of 5 minutes is RECOMMENDED. 516 For RCODE = 9 (NOTAUTH), which occurs on a server that implements 517 XuDs, but is not configured to be authoritative for the requested 518 name, the retry delay may be any value selected by the implementer 519 and/or configured by the operator. Since it is possible that the 520 misconfiguration may be repaired at any time, the retry delay should 521 not be set too high. By default, a value of 5 minutes is 522 RECOMMENDED. 524 For RCODE = 11 (DSOTYPENI), which occurs on a server that implements 525 DSO but doesn't implement XuD, it is unlikely that the server will 526 begin supporting XuD in the next few minutes, so the retry delay 527 SHOULD be one hour. 529 For other RCODE values, the retry delay should be set by the server 530 as appropriate for that error condition. By default, a value of 5 531 minutes is RECOMMENDED. 533 For RCODE = 9 (NOTAUTH), the time delay applies to requests for other 534 names falling within the same zone. Requests for names falling 535 within other zones are not subject to the delay. For all other 536 RCODEs the time delay applies to all subsequent requests to this 537 server. 539 After sending an error response the server MAY allow the session to 540 remain open, or MAY send a Retry Delay Operation TLV instructing the 541 client to close the session, as described in the DSO specification 542 [RFC8490]. Clients MUST correctly handle both cases. 544 7.2. XuD Notifications 546 Once a subscription has been successfully established, the server 547 generates DSO-IXFR messages to send to the client as appropriate. In 548 the case that the server could not provide a DSO-IXFR message based 549 on the SOA received from the client an initial DSO-AXFR message will 550 be sent immediately following the SUBSCRIBE-XFR Response. Subsequent 551 changes to the zone are then communicated to the client in subsequent 552 DSO-IXFR messages. 554 Until an UNSUBSCRIBE-XFR message is received the server MUST assume 555 that the client is updating the client's version of the zone with the 556 notifications sent and can therefore hold state on the SOA version 557 the client holds. It MUST use this to generate the DSO-IXFR messages 558 sent on a XuD session. 560 7.2.1. DSO-IXFR Message 562 A DSO-IXFR unidirectional message begins with the standard DSO 563 12-byte header [RFC8490], followed by the DSO-IXFR primary TLV. A 564 DSO-IXFR message is illustrated in Figure 4. 566 In accordance with the definition of DSO unidirectional messages, the 567 MESSAGE ID field MUST be zero. There is no client response to a DSO- 568 IXFR message. 570 The other header fields MUST be set as described in the DSO 571 specification [RFC8490]. The DNS OPCODE field contains the OPCODE 572 value for DNS Stateful Operations (6). The four count fields MUST be 573 zero, and the corresponding four sections MUST be empty (i.e., 574 absent). 576 The DSO-TYPE is DSO-IXFR (tentatively 0x51). 578 The DSO-LENGTH is the length of the DSO-DATA that follows, which 579 specifies the changes being communicated. 581 The DSO-DATA contains one or more change notifications. A DSO-IXFR 582 Message MUST contain at least one change notification. If a DSO-IXFR 583 Message is received that contains no change notifications, this is a 584 fatal error, and the receiver MUST immediately terminate the 585 connection with a TLS close_notify alert. 587 1 1 1 1 1 1 588 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 589 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 590 | MESSAGE ID (MUST BE ZERO) | \ 591 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 592 |QR| OPCODE(6) | Z | RCODE | | 593 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 594 | QDCOUNT (MUST BE ZERO) | | 595 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER 596 | ANCOUNT (MUST BE ZERO) | | 597 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 598 | NSCOUNT (MUST BE ZERO) | | 599 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 600 | ARCOUNT (MUST BE ZERO) | / 601 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 602 | DSO-TYPE = DSO-IXFR (tentatively 0x51) | 603 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 604 | DSO-LENGTH (number of octets in DSO-DATA) | 605 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 606 | | \ 607 | | | 608 | IXFR BODY AS PER RFC1995 | > DSO-DATA 609 | | | 610 | | / 611 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 613 Figure 4: DSO-IXFR Message 615 The DSO-DATA in a DSO-IXFR message is identical to the contents of a 616 [RFC1995] IXFR message that would be sent to communicate the same 617 zone incremental zone transfer over UDP or TCP i.e. the set of one or 618 more difference sequences that follow the DNS Header in an IXFR 619 message. 621 When processing the records received in a DSO-IXFR Message, the 622 receiving client MUST validate that the zone being updated correspond 623 with at least one currently active subscription on that session. 624 Specifically, the SOA name and CLASS MUST match the SOA name and 625 CLASS given in a SUBSCRIBE-XFR request, subject to the usual 626 established DNS case-insensitivity for US-ASCII letters. 628 7.2.2. Fallback to AXFR 630 The format of the DSO-AXFR message is a standard DSO header with DSO- 631 TYPE of DSO-AXFR (tentatively DSO Type Code 0x52) and the body is 632 identical to a [RFC5936] AXFR response body. 634 TODO: More detail here. 636 If the SUBSCRIBE-XFR message contained no SOA value, the server MUST 637 send a DSO-AXFR message as its first message on the connection. 639 Alternatively if incremental zone transfer is not available, the 640 entire zone MAY be returned in a DSO-AXFR message. 642 QUESTION: Should we bother with a separate DSO-AXFR message or just 643 allow full zone transfer inside the DSO-IXFR message as with 644 [RFC1995] IXFR? A separate message type makes is more explicit and 645 IXFR was constrained by having to respond to a IXFR request. 647 7.3. XuD UNSUBSCRIBE-XFR 649 To cancel an individual subscription without closing the entire DSO 650 session, the client sends an UNSUBSCRIBE-XFR message over the 651 established DSO session to the server. The UNSUBSCRIBE-XFR message 652 is encoded as a DSO unidirectional message [RFC8490]. This 653 specification defines a primary unidirectional DSO TLV for XuD 654 UNSUBSCRIBE-XFR Messages (tentatively DSO Type Code 0x53). 656 A server MUST NOT initiate an UNSUBSCRIBE-XFR message. If a server 657 does send an UNSUBSCRIBE-XFR message over a DSO session initiated by 658 a client, this is a fatal error and the client should immediately 659 abort the connection with a TLS close_notify alert. 661 7.3.1. UNSUBSCRIBE-XFR Message 663 An UNSUBSCRIBE-XFR unidirectional message begins with the standard 664 DSO 12-byte header [RFC8490], followed by the UNSUBSCRIBE-XFR primary 665 TLV. An UNSUBSCRIBE-XFR message is illustrated in Figure 5. 667 In accordance with the definition of DSO unidirectional messages, the 668 MESSAGE ID field MUST be zero. There is no server response to an 669 UNSUBSCRIBE-XFR message. 671 The other header fields MUST be set as described in the DSO 672 specification [RFC8490]. The DNS OPCODE field contains the OPCODE 673 value for DNS Stateful Operations (6). The four count fields MUST be 674 zero, and the corresponding four sections MUST be empty (i.e., 675 absent). 677 The DSO-TYPE is UNSUBSCRIBE-XFR (tentatively 0x53). 679 The DSO-LENGTH field contains the value 2, the length of the 2-octet 680 MESSAGE ID contained in the DSO-DATA. 682 The DSO-DATA contains the value given in the MESSAGE ID field of an 683 active SUBSCRIBE-XFR request. This is how the server knows which 684 SUBSCRIBE-XFR request is being cancelled. After receipt of the 685 UNSUBSCRIBE-XFR message, the SUBSCRIBE-XFR request is no longer 686 active. 688 It is allowable for the client to issue an UNSUBSCRIBE-XFR message 689 for a previous SUBSCRIBE-XFR request for which the client has not yet 690 received a SUBSCRIBE-XFR response. This is to allow for the case 691 where a client starts and stops a subscription in less than the 692 round-trip time to the server. The client is NOT required to wait 693 for the SUBSCRIBE-XFR response before issuing the UNSUBSCRIBE-XFR 694 message. 696 Consequently, it is possible for a server to receive an UNSUBSCRIBE- 697 XFR message that does not match any currently active subscription. 698 This can occur when a client sends a SUBSCRIBE-XFR request, which 699 subsequently fails and returns an error code, but the client sent an 700 UNSUBSCRIBE-XFR message before it became aware that the SUBSCRIBE-XFR 701 request had failed. Because of this, servers MUST silently ignore 702 UNSUBSCRIBE-XFR messages that do not match any currently active 703 subscription. 705 1 1 1 1 1 1 706 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 707 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 708 | MESSAGE ID (MUST BE ZERO) | \ 709 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 710 |QR| OPCODE(6) | Z | RCODE | | 711 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 712 | QDCOUNT (MUST BE ZERO) | | 713 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER 714 | ANCOUNT (MUST BE ZERO) | | 715 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 716 | NSCOUNT (MUST BE ZERO) | | 717 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 718 | ARCOUNT (MUST BE ZERO) | / 719 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 720 | DSO-TYPE = UNSUBSCRIBE-XFR (tentatively 0x53) | 721 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 722 | DSO-LENGTH (2) | 723 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 724 | SUBSCRIBE-XFR MESSAGE ID | > DSO-DATA 725 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 727 Figure 5: UNSUBSCRIBE-XFR Message 729 QUESTION: Do we need the equivalent of a RECONFIRM message from DNS 730 PUSH Notifications [I-D.ietf-dnssd-push]? 732 7.4. Authentication 734 The authentication considerations are largely the same as those 735 presented in [I-D.hzpa-dprive-xfr-over-tls]. 737 7.5. Multi-primary configurations 739 The multi-primary considerations share some of the same issues as 740 those presented in [I-D.hzpa-dprive-xfr-over-tls] but are different 741 because the client is not performing SOA queries. 743 TODO: More detail required here. 745 7.6. DNS Stateful Operations TLV Context Summary 747 This document defines four new DSO TLVs. As suggested in Section 8.2 748 of the DNS Stateful Operations specification [RFC8490], the valid 749 contexts of these new TLV types are summarized below. 751 The client TLV contexts are: 753 C-P: Client request message, primary TLV 755 C-U: Client unidirectional message, primary TLV 757 C-A: Client request or unidirectional message, additional TLV 759 CRP: Response back to client, primary TLV 761 CRA: Response back to client, additional TLV 763 +-----------------+-----+-----+-----+-----+-----+ 764 | TLV Type | C-P | C-U | C-A | CRP | CRA | 765 +-----------------+-----+-----+-----+-----+-----+ 766 | SUBSCRIBE-XFR | X | | | | | 767 | DSO-IXFR | | | | | | 768 | DSO-AXFR | | | | | | 769 | UNSUBSCRIBE-XFR | | X | | | | 770 +-----------------+-----+-----+-----+-----+-----+ 772 Table 2: DSO TLV Client Context Summary 774 The server TLV contexts are: 776 S-P: Server request message, primary TLV 778 S-U: Server unidirectional message, primary TLV 779 S-A: Server request or unidirectional message, additional TLV 781 SRP: Response back to server, primary TLV 783 SRA: Response back to server, additional TLV 785 +-----------------+-----+-----+-----+-----+-----+ 786 | TLV Type | S-P | S-U | S-A | SRP | SRA | 787 +-----------------+-----+-----+-----+-----+-----+ 788 | SUBSCRIBE-XFR | | | | | | 789 | DSO-IXFR | | X | | | | 790 | DSO-AXFR | | X | | | | 791 | UNSUBSCRIBE-XFR | | | | | | 792 +-----------------+-----+-----+-----+-----+-----+ 794 Table 3: DSO TLV Server Context Summary 796 8. IANA Considerations 798 This document also defines four new DNS Stateful Operation TLV types 799 to be recorded in the IANA DSO Type Code Registry. 801 +-----------------+----------+----------+--------------+------------+ 802 | Name | Value | Early | Status | Definition | 803 | | | Data | | | 804 +-----------------+----------+----------+--------------+------------+ 805 | SUBSCRIBE-XFR | TBA | NO | Standards | Section | 806 | | (0x50) | | Track | 7.1 | 807 | DSO-IXFR | TBA | NA | Standards | Section | 808 | | (0x51) | | Track | 7.1 | 809 | DSO-AXFR | TBA | NA | Standards | Section | 810 | | (0x51) | | Track | 7.2 | 811 | UNSUBSCRIBE-XFR | TBA | NA | Standards | Section | 812 | | (0x52) | | Track | 7.2 | 813 +-----------------+----------+----------+--------------+------------+ 815 Table 5: IANA DSO TLV Type Code Assignment 817 9. Implementation Considerations 819 TBD 821 10. Implementation Status 823 TBD 825 11. Security Considerations 827 This document specifies a security measure against a DNS risk: the 828 risk that an attacker collects entire DNS zones through eavesdropping 829 on clear text DNS zone transfers. It presents a new Security 830 Consideration for DNS. Some questions to discuss are: 832 o Should DoT in this new case be required to use only TLS 1.3 and 833 higher to avoid residual exposure? 835 o How should padding be used in IXFR? 837 o Should there be an option to 'pad' an AXFR response (i.e. a set of 838 AXFR responses on a given connection) to hide the zone size? 840 12. Acknowledgements 842 13. Changelog 844 draft-zatda-dprive-xfr-using-dso-00 846 o Initial commit 848 14. References 850 14.1. Normative References 852 [I-D.hzpa-dprive-xfr-over-tls] 853 Zhang, H., Aras, P., Toorop, W., Dickinson, S., and A. 854 Mankin, "DNS Zone Transfer over TLS", draft-hzpa-dprive- 855 xfr-over-tls-01 (work in progress), March 2019. 857 [I-D.ietf-dnssd-push] 858 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 859 draft-ietf-dnssd-push-21 (work in progress), July 2019. 861 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 862 Requirement Levels", BCP 14, RFC 2119, 863 DOI 10.17487/RFC2119, March 1997, . 866 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 867 Morris, J., Hansen, M., and R. Smith, "Privacy 868 Considerations for Internet Protocols", RFC 6973, 869 DOI 10.17487/RFC6973, July 2013, . 872 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 873 and P. Hoffman, "Specification for DNS over Transport 874 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 875 2016, . 877 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 878 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 879 May 2017, . 881 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 882 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 883 January 2019, . 885 14.2. Informative References 887 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 888 DOI 10.17487/RFC1995, August 1996, . 891 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 892 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 893 . 895 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 896 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 897 RFC 8490, DOI 10.17487/RFC8490, March 2019, 898 . 900 14.3. URIs 902 [1] https://github.com/Sinodun/draft-xfr-using-dso/blob/master/draft- 903 01-svg/XuD_Protocol.svg 905 Authors' Addresses 907 Han Zhang 908 Salesforce 909 San Francisco, CA 910 United States 912 Email: hzhang@salesforce.com 913 Pallavi Aras 914 Salesforce 915 Herndon, VA 916 United States 918 Email: paras@salesforce.com 920 Willem Toorop 921 NLnet Labs 922 Science Park 400 923 Amsterdam 1098 XH 924 The Netherlands 926 Email: willem@nlnetlabs.nl 928 Sara Dickinson 929 Sinodun IT 930 Magdalen Centre 931 Oxford Science Park 932 Oxford OX4 4GA 933 United Kingdom 935 Email: sara@sinodun.com 937 Allison Mankin 938 Salesforce 939 Herndon, VA 940 United States 942 Email: allison.mankin@gmail.com