idnits 2.17.1 draft-ietf-dnssd-push-09.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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (October 31, 2016) is 2734 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) == Outdated reference: A later version (-20) exists of draft-ietf-dnsop-session-signal-00 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-03 == Outdated reference: A later version (-06) exists of draft-sekar-dns-llq-01 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Pusateri 3 Internet-Draft Seeking affiliation 4 Intended status: Standards Track S. Cheshire 5 Expires: May 4, 2017 Apple Inc. 6 October 31, 2016 8 DNS Push Notifications 9 draft-ietf-dnssd-push-09 11 Abstract 13 The Domain Name System (DNS) was designed to return matching records 14 efficiently for queries for data that is relatively static. When 15 those records change frequently, DNS is still efficient at returning 16 the updated results when polled. But there exists no mechanism for a 17 client to be asynchronously notified when these changes occur. This 18 document defines a mechanism for a client to be notified of such 19 changes to DNS records, called DNS Push Notifications. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 4, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. State Considerations . . . . . . . . . . . . . . . . . . . . 6 61 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 62 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 10 64 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 11 65 6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 14 66 6.3. DNS Push Notification Update Messages . . . . . . . . . . 18 67 6.3.1. PUSH Message format . . . . . . . . . . . . . . . . . 18 68 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 21 69 6.4.1. UNSUBSCRIBE Request . . . . . . . . . . . . . . . . . 22 70 6.4.2. UNSUBSCRIBE Response . . . . . . . . . . . . . . . . 24 71 6.5. DNS Session Signaling Push Notification RECONFIRM . . . . 26 72 6.6. Client-Initiated Termination . . . . . . . . . . . . . . 28 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 74 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 29 75 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 29 76 7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 30 77 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 30 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 82 10.2. Informative References . . . . . . . . . . . . . . . . . 32 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 85 1. Introduction 87 DNS records may be updated using DNS Update [RFC2136]. Other 88 mechanisms such as a Hybrid Proxy [I-D.ietf-dnssd-hybrid] can also 89 generate changes to a DNS zone. This document specifies a protocol 90 for DNS clients to subscribe to receive asynchronous notifications of 91 changes to RRSets of interest. It is immediately relevant in the 92 case of DNS Service Discovery [RFC6763] but is not limited to that 93 use case, and provides a general DNS mechanism for DNS record change 94 notifications. Familiarity with the DNS protocol and DNS packet 95 formats is assumed [RFC1034] [RFC1035] [RFC6895]. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in 102 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 104 2. Motivation 106 As the domain name system continues to adapt to new uses and changes 107 in deployment, polling has the potential to burden DNS servers at 108 many levels throughout the network. Other network protocols have 109 successfully deployed a publish/subscribe model to state changes 110 following the Observer design pattern [obs]. XMPP Publish-Subscribe 111 [XEP0060] and Atom [RFC4287] are examples. While DNS servers are 112 generally highly tuned and capable of a high rate of query/response 113 traffic, adding a publish/subscribe model for tracking changes to DNS 114 records can result in more timely notification of changes with 115 reduced CPU usage and lower network traffic. 117 Multicast DNS [RFC6762] implementations always listen on a well known 118 link-local IP multicast group, and new services and updates are sent 119 for all group members to receive. Therefore, Multicast DNS already 120 has asynchronous change notification capability. However, when DNS 121 Service Discovery [RFC6763] is used across a wide area network using 122 Unicast DNS (possibly facilitated via a Hybrid Proxy 123 [I-D.ietf-dnssd-hybrid]) it would be beneficial to have an equivalent 124 capability for Unicast DNS, to allow clients to learn about DNS 125 record changes in a timely manner without polling. 127 DNS Long-Lived Queries (LLQ) [I-D.sekar-dns-llq] is an existing 128 deployed solution to provide asynchronous change notifications. Even 129 though it can be used over TCP, LLQ is defined primarily as a UDP- 130 based protocol, and as such it defines its own equivalents of 131 existing TCP features like the three-way handshake, flow control, and 132 reliability. This document builds on experience gained with the LLQ 133 protocol, with an improved design. Instead of using UDP, this 134 specification uses long-lived TCP connections 135 [I-D.ietf-dnsop-session-signal], and therefore doesn't need to 136 reinvent existing TCP functionality. Instead of inventing a new 137 vocabulary of messages to communicate DNS zone changes, this 138 specification adopts the syntax and semantics of DNS Update messages 139 [RFC2136]. 141 DNS Push Notifications impose less load on the responding server than 142 rapid polling would, but Push Notifications do still have a cost, so 143 DNS Push Notification clients MUST NOT recklessly create an excessive 144 number of Push Notification subscriptions. A subscription SHOULD 145 only be active when there is a valid reason to need live data (for 146 example, an on-screen display is currently showing the results to the 147 user) and the subscription SHOULD be cancelled as soon as the need 148 for that data ends (for example, when the user dismisses that 149 display). Implementations MAY want to implement idle timeouts, so 150 that if the user ceases interacting with the device, the display 151 showing the result of the DNS Push Notification subscription is 152 automatically dismissed after a certain period of inactivity. For 153 example, if a user presses the "Print" button on their smartphone, 154 and then leaves the phone showing the printer discovery screen until 155 the phone goes to sleep, then the printer discovery screen should be 156 automatically dismissed as the device goes to sleep. If the user 157 does still intend to print, this will require them to press the 158 "Print" button again when they wake their phone up. 160 A DNS Push Notification client MUST NOT routinely keep a DNS Push 161 Notification subscription active 24 hours a day 7 days a week just to 162 keep a list in memory up to date so that it will be really fast if 163 the user does choose to bring up an on-screen display of that data. 164 DNS Push Notifications are designed to be fast enough that there is 165 no need to pre-load a "warm" list in memory just in case it might be 166 needed later. 168 Generally, a client SHOULD NOT keep a connection to a server open 169 indefinitely if it has no active subscriptions on that connection. 170 After 30 seconds with no active subscriptions the client SHOULD close 171 the idle connection, and, if needed in the future, open a new 172 connection. 174 3. Overview 176 The existing DNS Update protocol [RFC2136] provides a mechanism for 177 clients to add or delete individual resource records (RRs) or entire 178 resource record sets (RRSets) on the zone's server. 180 This specification adopts a simplified subset of these existing 181 syntax and semantics, and uses them for DNS Push Notification 182 messages going in the opposite direction, from server to client, to 183 communicate changes to a zone. The client subscribes for Push 184 Notifications by connecting to the server and sending DNS message(s) 185 indicating the RRSet(s) of interest. When the client loses interest 186 in updates to these records, it unsubscribes. 188 The DNS Push Notification server for a zone is any server capable 189 of generating the correct change notifications for a name. 190 It may be a master, slave, or stealth name server [RFC1996]. 191 Consequently, the "_dns-push-tls._tcp." SRV record for a 192 zone MAY reference the same target host and port as that zone's 193 "_dns-update-tls._tcp." SRV record. When the same target host 194 and port is offered for both DNS Updates and DNS Push Notifications, 195 a client MAY use a single TCP connection to that server for both DNS 196 Updates and DNS Push Notification Queries. 198 Supporting DNS Updates and DNS Push Notifications on the same server 199 is OPTIONAL. A DNS Push Notification server does NOT also have to 200 support DNS Update. 202 DNS Updates and DNS Push Notifications may be handled on different 203 ports on the same target host, in which case they are not considered 204 to be the "same server" for the purposes of this specification, and 205 communications with these two ports are handled independently. 207 Standard DNS Queries MAY be sent over a DNS Push Notification 208 connection, provided that these are queries for names falling within 209 the server's zone (the in the "_dns-push-tls._tcp." SRV 210 record). The RD (Recursion Desired) bit MUST be zero. 212 DNS Push Notification clients are NOT required to implement DNS 213 Update Prerequisite processing. Prerequisites are used to perform 214 tentative atomic test-and-set type operations when a client updates 215 records on a server, and that concept has no applicability when it 216 comes to an authoritative server informing a client of changes to DNS 217 records. 219 This DNS Push Notification specification includes support for DNS 220 classes, for completeness. However, in practice, it is anticipated 221 that for the foreseeable future the only DNS class in use will be DNS 222 class "IN", as is the reality today with existing DNS servers and 223 clients. A DNS Push Notification server MAY choose to implement only 224 DNS class "IN". 226 4. Transport 228 Implementations of DNS Update [RFC2136] MAY use either User Datagram 229 Protocol (UDP) [RFC0768] or Transmission Control Protocol (TCP) 230 [RFC0793] as the transport protocol, in keeping with the historical 231 precedent that DNS queries must first be sent over UDP [RFC1123]. 232 This requirement to use UDP has subsequently been relaxed [RFC7766]. 234 In keeping with the more recent precedent, DNS Push Notification is 235 defined only for TCP. DNS Push Notification clients MUST use TLS 236 over TCP. 238 Connection setup over TCP ensures return reachability and alleviates 239 concerns of state overload at the server through anonymous 240 subscriptions. All subscribers are guaranteed to be reachable by the 241 server by virtue of the TCP three-way handshake. Flooding attacks 242 are possible with any protocol, and a benefit of TCP is that there 243 are already established industry best practices to guard against SYN 244 flooding and similar attacks [IPJ.9-4-TCPSYN] [RFC4953]. 246 Use of TCP also allows DNS Push Notifications to take advantage of 247 current and future developments in TCP, such as Multipath TCP (MPTCP) 248 [RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP) 249 [I-D.dukkipati-tcpm-tcp-loss-probe], and so on. 251 Transport Layer Security (TLS) [RFC5246] is well understood and 252 deployed across many protocols running over TCP. It is designed to 253 prevent eavesdropping, tampering, or message forgery. TLS is 254 REQUIRED for every connection between a client subscriber and server 255 in this protocol specification. Additional security measures such as 256 client authentication during TLS negotiation MAY also be employed to 257 increase the trust relationship between client and server. 259 Additional authentication of the SRV target using DNSSEC verification 260 and DANE TLSA records [RFC7673] is strongly encouraged. See below in 261 Section 7.2 for details. 263 5. State Considerations 265 Each DNS Push Notification server is capable of handling some finite 266 number of Push Notification subscriptions. This number will vary 267 from server to server and is based on physical machine 268 characteristics, network bandwidth, and operating system resource 269 allocation. After a client establishes a connection to a DNS server, 270 each record subscription is individually accepted or rejected. 271 Servers may employ various techniques to limit subscriptions to a 272 manageable level. Correspondingly, the client is free to establish 273 simultaneous connections to alternate DNS servers that support DNS 274 Push Notifications for the zone and distribute record subscriptions 275 at its discretion. In this way, both clients and servers can react 276 to resource constraints. Token bucket rate limiting schemes are also 277 effective in providing fairness by a server across numerous client 278 requests. 280 6. Protocol Operation 282 The DNS Push Notification protocol is a session-oriented protocol, 283 and makes use of DNS Session Signaling 284 [I-D.ietf-dnsop-session-signal]. 286 DNS Push Notification clients and servers MUST support DNS Session 287 Signaling, but the server must not issue any DNS Session Signaling 288 operations until after the client has first initiated a DNS Session 289 Signaling operation of its own. A single server can support DNS 290 Queries, DNS Updates, and DNS Push Notifications (using DNS Session 291 Signaling) on the same TCP port, and until the client has sent at 292 least one DNS Session Signaling operation the server does not know 293 what kind of client has connected to it. Once the client has 294 indicated willingness to use DNS Session Signaling operations by 295 sending one of its own, either side of the connection may then 296 initiate further Session Signaling operations at any time. 298 A DNS Push Notification exchange begins with the client discovering 299 the appropriate server, using the procedure described in Section 6.1, 300 and then making a TLS/TCP connection to it. 302 A typical DNS Push Notification client will immediately issue a DNS 303 Session Signaling Idle Timeout operation to request a session timeout 304 longer than the the 30-second default, but this is NOT REQUIRED. A 305 DNS Push Notification client MAY issue other requests on the 306 connection first, and only issue a DNS Session Signaling Idle Timeout 307 operation later if it determines that to be necessary. 309 Once the connection is made, the client may then add and remove Push 310 Notification subscriptions. In accordance with the current set of 311 active subscriptions the server sends relevant asynchronous Push 312 Notifications to the client. Note that a client MUST be prepared to 313 receive (and silently ignore) Push Notifications for subscriptions it 314 has previously removed, since there is no way to prevent the 315 situation where a Push Notification is in flight from server to 316 client while the client's UNSUBSCRIBE message cancelling that 317 subscription is simultaneously in flight from client to server. 319 The exchange between client and server terminates when either end 320 closes the TCP connection with a TCP FIN or RST. 322 6.1. Discovery 324 The first step in DNS Push Notification subscription is to discover 325 an appropriate DNS server that supports DNS Push Notifications for 326 the desired zone. The client MUST also determine which TCP port on 327 the server is listening for connections, which need not be (and often 328 is not) the typical TCP port 53 used for conventional DNS, or TCP 329 port 853 used for DNS over TLS [RFC7858]. 331 1. The client begins the discovery by sending a DNS query to the 332 local resolver with record type SOA [RFC1035] for the name of the 333 record it wishes to subscribe. 335 2. If the SOA record exists, it MUST be returned in the Answer 336 Section of the response. If not, the local resolver SHOULD 337 include the SOA record for the zone of the requested name in the 338 Authority Section. 340 3. If no SOA record is returned, the client then strips off the 341 leading label from the requested name. If the resulting name has 342 at least one label in it, the client sends a new SOA query and 343 processing continues at step 2 above. If the resulting name is 344 empty (the root label) then this is a network configuration error 345 and the client gives up. The client MAY retry the operation at a 346 later time. 348 4. Once the SOA is known (either by virtue of being seen in the 349 Answer Section, or in the Authority Section), the client sends a 350 DNS query with type SRV [RFC2782] for the record name 351 "_dns-push-tls._tcp.", where is the owner name of 352 the discovered SOA record. 354 5. If the zone in question does not offer DNS Push Notifications 355 then SRV record MUST NOT exist and the SRV query will return a 356 negative answer. 358 6. If the zone in question is set up to offer DNS Push Notifications 359 then this SRV record MUST exist. The SRV "target" contains the 360 name of the server providing DNS Push Notifications for the zone. 361 The port number on which to contact the server is in the SRV 362 record "port" field. The address(es) of the target host MAY be 363 included in the Additional Section, however, the address records 364 SHOULD be authenticated before use as described below in 365 Section 7.2 [RFC7673]. 367 7. More than one SRV record may be returned. In this case, the 368 "priority" and "weight" values in the returned SRV records are 369 used to determine the order in which to contact the servers for 370 subscription requests. As described in the SRV specification 371 [RFC2782], the server with the lowest "priority" is first 372 contacted. If more than one server has the same "priority", the 373 "weight" indicates the weighted probability that the client 374 should contact that server. Higher weights have higher 375 probabilities of being selected. If a server is not reachable or 376 is not willing to accept a subscription request, then a 377 subsequent server is to be contacted. 379 Each time a client makes a new DNS Push Notification subscription 380 connection, it SHOULD repeat the discovery process in order to 381 determine the preferred DNS server for subscriptions at that time. 383 Note that this repeated discovery step is typically very fast and 384 typically results in no queries on the network. The client device 385 MUST respect the DNS TTL values on records it receives, and store 386 them in its local cache with this lifetime. This means that, as long 387 as the DNS TTL values on the authoritative records were set to 388 reasonable values, repeated application of this discovery process can 389 be completed nearly instantaneously by the client, using only 390 locally-stored data. 392 6.2. DNS Push Notification SUBSCRIBE 394 After connecting, and requesting a longer idle timeout if necessary, 395 a DNS Push Notification client then indicates its desire to receive 396 DNS Push Notifications for a given domain name by sending a SUBSCRIBE 397 request over the established TLS connection to the server. A 398 SUBSCRIBE request is encoded in a DNS Session Signaling 399 [I-D.ietf-dnsop-session-signal] message. This specification defines 400 a new DNS Session Signaling TLV for DNS Push Notification SUBSCRIBE 401 Requests/Responses (tentatively Session Signaling Type Code 64). 403 A server may not initiate a SUBSCRIBE request. 405 6.2.1. SUBSCRIBE Request 407 A SUBSCRIBE request message begins with the standard DNS Session 408 Signaling 4-byte header [I-D.ietf-dnsop-session-signal], followed by 409 the SUBSCRIBE TLV. 411 1 1 1 1 1 1 412 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 413 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 414 | MESSAGE ID | 415 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 416 |QR| Opcode | Z | RCODE | 417 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 418 | SSOP-TYPE (SUBSCRIBE) | 419 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 420 | SSOP-LENGTH | 421 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 422 | | 423 \ QNAME \ 424 \ \ 425 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 426 | QTYPE | 427 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 428 | QCLASS | 429 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 431 Figure 1 433 The MESSAGE ID field MUST be set to a unique value, that the client 434 is not using for any other active operation on this connection. For 435 the purposes here, a MESSAGE ID is in use on this connection if the 436 client has used it in a request for which it has not yet received a 437 response, or if if the client has used it for a subscription which it 438 has not yet cancelled using UNSUBSCRIBE. In the SUBSCRIBE response 439 the server MUST echo back the MESSAGE ID value unchanged. 441 In a request the DNS Header QR bit MUST be zero. 443 The DNS Header Opcode field holds the Session Signaling Opcode value 444 (tentatively 6). 446 The Z bits MUST be zero on transmission, and MUST be silently ignored 447 on reception. 449 The return code (RCODE) field MUST be set to 0 in a request. 451 In the SUBSCRIBE TLV the SSOP-TYPE is SUBSCRIBE (tentatively 64). 452 The SSOP-LENGTH is the length of the data that follows, which 453 specifies the name, type, and class of the record(s) being sought. 455 A SUBSCRIBE request MUST contain exactly one question. There is no 456 QCOUNT field to specify more than one question. Since SUBSCRIBE 457 requests are sent over TCP, multiple SUBSCRIBE requests can be 458 concatenated in a single TCP stream and packed efficiently into TCP 459 segments. 461 If accepted, the subscription will stay in effect until the client 462 cancels the subscription using UNSUBSCRIBE or until the connection 463 between the client and the server is closed. 465 SUBSCRIBE requests on a given connection MUST be unique. A client 466 MUST NOT send a SUBSCRIBE message that duplicates the QNAME, QTYPE 467 and QCLASS of an existing active subscription on that TLS/TCP 468 connection. For the purpose of this matching, the established DNS 469 case-insensitivity for US-ASCII letters applies (e.g., "foo.com" and 470 "Foo.com" are the same). If a server receives such a duplicate 471 SUBSCRIBE message this is an error and the server MUST immediately 472 close the TCP connection. 474 DNS wildcarding is not supported. That is, a wildcard ("*") in a 475 SUBSCRIBE message matches only a literal wildcard character ("*") in 476 the zone, and nothing else. 478 Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message 479 matches only a literal CNAME record in the zone, and nothing else. 481 A client may SUBSCRIBE to records that are unknown to the server at 482 the time of the request (providing that the name falls within one of 483 the zone(s) the server is responsible for) and this is not an error. 484 The server MUST accept these requests and send Push Notifications if 485 and when matching records are found in the future. 487 If neither QTYPE nor QCLASS are ANY (255) then this is a specific 488 subscription to changes for the given QNAME, QTYPE and QCLASS. If 489 one or both of QTYPE or QCLASS are ANY (255) then this subscription 490 matches any type and/or any class, as appropriate. 492 NOTE: A little-known quirk of DNS is that in DNS QUERY requests, 493 QTYPE and QCLASS 255 mean "ANY" not "ALL". They indicate that the 494 server should respond with ANY matching records of its choosing, not 495 necessarily ALL matching records. This can lead to some surprising 496 and unexpected results, were a query returns some valid answers but 497 not all of them, and makes QTYPE=ANY queries less useful than people 498 sometimes imagine. 500 When used in conjunction with SUBSCRIBE, QTYPE and QCLASS 255 should 501 be interpreted to mean "ALL", not "ANY". After accepting a 502 subscription where one or both of QTYPE or QCLASS are 255, the server 503 MUST send Push Notification Updates for ALL record changes that match 504 the subscription, not just some of them. 506 6.2.2. SUBSCRIBE Response 508 Each SUBSCRIBE request generates exactly one SUBSCRIBE response from 509 the server. 511 A SUBSCRIBE response message begins with the standard DNS Session 512 Signaling 4-byte header [I-D.ietf-dnsop-session-signal], possibly 513 followed by one or more optional modifier TLVs such as a Terminate 514 modifier TLV [I-D.ietf-dnsop-session-signal]. 516 1 1 1 1 1 1 517 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 518 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 519 | MESSAGE ID | 520 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 521 |QR| Opcode | Z | RCODE | 522 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 524 Figure 2 526 The MESSAGE ID field MUST echo the value given in the ID field of the 527 SUBSCRIBE request. This is how the client knows which request is 528 being responded to. 530 In a response the DNS Header QR bit MUST be one. 531 If the QR bit is not one the message is not a response. 533 The DNS Header Opcode field holds the Session Signaling Opcode value 534 (tentatively 6). 536 The Z bits MUST be zero on transmission, and MUST be silently ignored 537 on reception. 539 In the SUBSCRIBE response the RCODE indicates whether or not the 540 subscription was accepted. Supported RCODEs are as follows: 542 +------------+-------+----------------------------------------------+ 543 | Mnemonic | Value | Description | 544 +------------+-------+----------------------------------------------+ 545 | NOERROR | 0 | SUBSCRIBE successful. | 546 | FORMERR | 1 | Server failed to process request due to a | 547 | | | malformed request. | 548 | SERVFAIL | 2 | Server failed to process request due to | 549 | | | resource exhaustion. | 550 | NXDOMAIN | 3 | NOT APPLICABLE. DNS Push Notification | 551 | | | servers MUST NOT return NXDOMAIN errors in | 552 | | | response to SUBSCRIBE requests. | 553 | NOTIMP | 4 | Server does not recognize DNS Session | 554 | | | Signaling Opcode. | 555 | REFUSED | 5 | Server refuses to process request for policy | 556 | | | or security reasons. | 557 | NOTAUTH | 9 | Server is not authoritative for the | 558 | | | requested name. | 559 | SSOPNOTIMP | 11 | SUBSCRIBE operation not supported. | 560 +------------+-------+----------------------------------------------+ 562 SUBSCRIBE Response codes 564 This document specifies only these RCODE values for SUBSCRIBE 565 Responses. Servers sending SUBSCRIBE Responses SHOULD use one of 566 these values. However, future circumstances may create situations 567 where other RCODE values are appropriate in SUBSCRIBE Responses, so 568 clients MUST be prepared to accept SUBSCRIBE Responses with any RCODE 569 value. 571 If the server sends a nonzero RCODE in the SUBSCRIBE response, either 572 the client is (at least partially) misconfigured or the server 573 resources are exhausted. In either case, the client shouldn't retry 574 the subscription right away. Either end can terminate the 575 connection, but the client may want to try this subscription again or 576 it may have other successful subscriptions that it doesn't want to 577 abandon. If the server sends a nonzero RCODE then it SHOULD append a 578 Terminate modifier TLV [I-D.ietf-dnsop-session-signal] to the 579 response specifying a delay before the client attempts this operation 580 again. Recommended values for the delay for different RCODE values 581 are given below: 583 For RCODE = 1 (FORMERR) the delay may be any value selected by the 584 implementer. A value of five minutes is RECOMMENDED, to avoid 585 high load from defective clients. 587 For RCODE = 2 (SERVFAIL), which occurs due to resource exhaustion, 588 the delay should be chosen according to the level of server 589 overload and the anticipated duration of that overload. By 590 default, a value of one minute is RECOMMENDED. 592 For RCODE = 4 (NOTIMP), which occurs on a server that doesn't 593 implement DNS Session Signaling [I-D.ietf-dnsop-session-signal], 594 it is unlikely that the server will begin supporting DNS Session 595 Signaling in the next few minutes, so the retry delay SHOULD be 596 one hour. 598 For RCODE = 5 (REFUSED), which occurs on a server that implements 599 DNS Push Notifications, but is currently configured to disallow 600 DNS Push Notifications, the retry delay may be any value selected 601 by the implementer and/or configured by the operator. 602 This is a misconfiguration, since this server is listed in a 603 "_dns-push-tls._tcp." SRV record, but the server itself is 604 not currently configured to support DNS Push Notifications. Since 605 it is possible that the misconfiguration may be repaired at any 606 time, the retry delay should not be set too high. By default, a 607 value of 5 minutes is RECOMMENDED. 609 For RCODE = 9 (NOTAUTH), which occurs on a server that implements 610 DNS Push Notifications, but is not configured to be authoritative 611 for the requested name, the retry delay may be any value selected 612 by the implementer and/or configured by the operator. 613 This is a misconfiguration, since this server is listed in a 614 "_dns-push-tls._tcp." SRV record, but the server itself is 615 not currently configured to support DNS Push Notifications for 616 that zone. Since it is possible that the misconfiguration may be 617 repaired at any time, the retry delay should not be set too high. 618 By default, a value of 5 minutes is RECOMMENDED. 620 For RCODE = 11 (DNS Push SUBSCRIBE operation not supported), which 621 occurs on a server that doesn't implement DNS Push Notifications, 622 it is unlikely that the server will begin supporting DNS Push 623 Notifications in the next few minutes, so the retry delay SHOULD 624 be one hour. 626 For other RCODE values, the retry delay should be set by the 627 server as appropriate for that error condition. By default, a 628 value of 5 minutes is RECOMMENDED. 630 For RCODE = 9 (NOTAUTH), the time delay applies to requests for other 631 names falling within the same zone. Requests for names falling 632 within other zones are not subject to the delay. For all other 633 RCODEs the time delay applies to all subsequent requests to this 634 server. 636 After sending an error response the server MAY allow the connection 637 to remain open, or MAY send a DNS Push Notification Terminate Session 638 operation TLV and then close the TCP connection, as described in the 639 DNS Session Signaling specification [I-D.ietf-dnsop-session-signal]. 640 Clients MUST correctly handle both cases. 642 6.3. DNS Push Notification Update Messages 644 Once a subscription has been successfully established, the server 645 generates PUSH messages to send to the client as appropriate. An 646 initial PUSH message will be sent immediately in the case that the 647 answer set was non-empty at the moment the subscription was 648 established. Subsequent changes to the answer set are then 649 communicated to the client in subsequent PUSH messages. 651 6.3.1. PUSH Message format 653 A PUSH message begins with the standard DNS Session Signaling 4-byte 654 header [I-D.ietf-dnsop-session-signal], followed by the PUSH TLV. 656 The format of PUSH messages borrows from the existing DNS Update 657 [RFC2136] protocol, with some simplifications. 659 1 1 1 1 1 1 660 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 661 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 662 | MESSAGE ID | 663 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 664 |QR| Opcode | Z | RCODE | 665 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 666 | SSOP-TYPE (PUSH) | 667 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 668 | SSOP-LENGTH | 669 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 670 | UPCOUNT | 671 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 672 | | 673 \ Resource Records... \ 674 \ \ 675 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 677 Figure 3 679 The MESSAGE ID field MUST be set to zero on transmission, and 680 silently ignored on reception. A PUSH message could potentially 681 match more than one subscription, or could relate to a subscription 682 that the client has just cancelled with an UNSUBSCRIBE message, so 683 the MESSAGE ID field serves no useful purpose. 685 In a PUSH message the DNS Header QR bit MUST be zero. 687 The DNS Header Opcode field holds the Session Signaling Opcode value 688 (tentatively 6). 690 The Z bits MUST be zero on transmission, and MUST be silently ignored 691 on reception. 693 The return code (RCODE) field MUST be set to 0 in a request. 695 In the PUSH message TLV the SSOP-TYPE is PUSH (tentatively 65). The 696 SSOP-LENGTH is the length of the SSOP-DATA that follows. 698 The SSOP-DATA contains a two-byte count of the number of records that 699 follow, followed by the records, in customary Resource Record format 700 (as used in DNS Update [RFC2136] messages). 702 The SSOP-DATA contains the relevant change information for the 703 client, formatted identically to a DNS Update [RFC2136]. To recap: 705 Delete all RRsets from a name: 706 TTL=0, CLASS=ANY, RDLENGTH=0, TYPE=ANY. 708 Delete an RRset from a name: 709 TTL=0, CLASS=ANY, RDLENGTH=0; 710 TYPE specifies the RRset being deleted. 712 Delete an individual RR from a name: 713 TTL=0, CLASS=NONE; 714 TYPE, RDLENGTH and RDATA specifies the RR being deleted. 716 Add to an RRset: 717 TTL, CLASS, TYPE, RDLENGTH and RDATA specifies the RR being added. 719 When processing the records received in a PUSH Message, the receiving 720 client MUST validate that the records being added or deleted 721 correspond with at least one currently active subscription on that 722 connection. Specifically, the record name MUST match the name given 723 in the SUBSCRIBE request, subject to the usual established DNS case- 724 insensitivity for US-ASCII letters. If the QTYPE in the SUBSCRIBE 725 request was not ANY (255) then the TYPE of the record must match the 726 QTYPE given in the SUBSCRIBE request. If the QCLASS in the SUBSCRIBE 727 request was not ANY (255) then the CLASS of the record must match the 728 QCLASS given in the SUBSCRIBE request. If a matching active 729 subscription on that connection is not found, then that individual 730 record addition/deletion is silently ignored. Processing of other 731 additions and deletions in this message is not affected. The TCP 732 connection is not closed. This is to allow for the unavoidable race 733 condition where a client sends an outbound UNSUBSCRIBE while inbound 734 PUSH messages for that subscription from the server are still in 735 flight. 737 In the case where a single change affects more than one active 738 subscription, only one PUSH message is sent. For example, a PUSH 739 message adding a given record may match both a SUBSCRIBE request with 740 the same QTYPE and a different SUBSCRIBE request with QTYPE=ANY. It 741 is not the case that two PUSH messages are sent because the new 742 record matches two active subscriptions. 744 The server SHOULD encode change notifications in the most efficient 745 manner possible. For example, when three AAAA records are deleted 746 from a given name, and no other AAAA records exist for that name, the 747 server SHOULD send a "delete an RRset from a name" PUSH message, not 748 three separate "delete an individual RR from a name" PUSH messages. 749 Similarly, when both an SRV and a TXT record are deleted from a given 750 name, and no other records of any kind exist for that name, the 751 server SHOULD send a "delete all RRsets from a name" PUSH message, 752 not two separate "delete an RRset from a name" PUSH messages. 754 A server SHOULD combine multiple change notifications in a single 755 PUSH message when possible, even if those change notifications apply 756 to different subscriptions. Conceptually, a PUSH messages is a 757 connection-level concept, not a subscription-level concept. 759 Reception of a PUSH message does not directly generate a response 760 back to the server. (Updates may indirectly generate other 761 operations; e.g., a Push Notification Update Message declaring the 762 appearance of a PTR record could lead to a query for the SRV record 763 named in the rdata of that PTR record [RFC6763].) 765 The TTL of an added record is stored by the client and decremented as 766 time passes, with the caveat that for as long as a relevant 767 subscription is active, the TTL does not decrement below 1 second. 768 For as long as a relevant subscription remains active, the client 769 SHOULD assume that when a record goes away the server will notify it 770 of that fact. Consequently, a client does not have to poll to verify 771 that the record is still there. Once a subscription is cancelled 772 (individually, or as a result of the TCP connection being closed) 773 record ageing resumes and records are removed from the local cache 774 when their TTL reaches zero. 776 6.4. DNS Push Notification UNSUBSCRIBE 778 To cancel an individual subscription without closing the entire 779 connection, the client sends an UNSUBSCRIBE message over the 780 established TCP connection to the server. The UNSUBSCRIBE message is 781 encoded in a DNS Session Signaling [I-D.ietf-dnsop-session-signal] 782 message. This specification defines a new DNS Session Signaling TLV 783 for DNS Push Notification UNSUBSCRIBE Requests/Responses (tentatively 784 Session Signaling Type Code 66). 786 A server may not initiate an UNSUBSCRIBE request. 788 6.4.1. UNSUBSCRIBE Request 790 An UNSUBSCRIBE request message begins with the standard DNS Session 791 Signaling 4-byte header [I-D.ietf-dnsop-session-signal], followed by 792 the UNSUBSCRIBE TLV. 794 1 1 1 1 1 1 795 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 796 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 797 | MESSAGE ID | 798 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 799 |QR| Opcode | Z | RCODE | 800 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 801 | SSOP-TYPE (UNSUBSCRIBE) | 802 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 803 | SSOP-LENGTH (0) | 804 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 806 Figure 4 808 The MESSAGE ID field MUST match the value given in the ID field of an 809 active SUBSCRIBE request. This is how the server knows which 810 SUBSCRIBE request is being cancelled. After receipt of the 811 UNSUBSCRIBE request, the SUBSCRIBE request is no longer active. If a 812 server receives an UNSUBSCRIBE message where the MESSAGE ID does not 813 match the ID of an active SUBSCRIBE request this is an error and the 814 the server MUST return a response containing RCODE = 1 (FORMERR). In 815 the UNSUBSCRIBE response the server MUST echo back the MESSAGE ID 816 value unchanged. It is allowable for the client to issue an 817 UNSUBSCRIBE request for a previous SUBSCRIBE request for which the 818 client has not yet received a SUBSCRIBE response. This is to allow 819 for the case where a client starts and stops a subscription in less 820 than the round-trip time to the server. The client is NOT required 821 to wait for the SUBSCRIBE response before issuing the UNSUBSCRIBE 822 request. 824 In a request the DNS Header QR bit MUST be zero. 826 The DNS Header Opcode field holds the Session Signaling Opcode value 827 (tentatively 6). 829 The Z bits MUST be zero on transmission, and MUST be silently ignored 830 on reception. 832 The return code (RCODE) field MUST be set to 0 in a request. 834 In the UNSUBSCRIBE TLV the SSOP-TYPE is UNSUBSCRIBE (tentatively 66). 836 The SSOP-LENGTH is zero. 838 6.4.2. UNSUBSCRIBE Response 840 Each UNSUBSCRIBE request generates exactly one UNSUBSCRIBE response 841 from the server. 843 An UNSUBSCRIBE response message contains with the standard DNS 844 Session Signaling 4-byte header [I-D.ietf-dnsop-session-signal]. 846 1 1 1 1 1 1 847 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 848 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 849 | MESSAGE ID | 850 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 851 |QR| Opcode | Z | RCODE | 852 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 854 Figure 5 856 The MESSAGE ID field MUST echo the value given in the ID field of the 857 UNSUBSCRIBE request. This is how the client knows which request is 858 being responded to. 860 In a response the DNS Header QR bit MUST be one. 861 If the QR bit is not one the message is not a response. 863 The DNS Header Opcode field holds the Session Signaling Opcode value 864 (tentatively 6). 866 The Z bits MUST be zero on transmission, and MUST be silently ignored 867 on reception. 869 In the UNSUBSCRIBE response the RCODE indicates whether or not the 870 unsubscribe request was successful. Supported RCODEs are as follows: 872 +------------+-------+----------------------------------------------+ 873 | Mnemonic | Value | Description | 874 +------------+-------+----------------------------------------------+ 875 | NOERROR | 0 | UNSUBSCRIBE successful. | 876 | FORMERR | 1 | Server failed to process request due to a | 877 | | | malformed request. | 878 | NOTIMP | 4 | Server does not recognize DNS Session | 879 | | | Signaling Opcode. | 880 | SSOPNOTIMP | 11 | UNSUBSCRIBE operation not supported. | 881 +------------+-------+----------------------------------------------+ 883 UNSUBSCRIBE Response codes 885 This document specifies only these RCODE values for UNSUBSCRIBE 886 Responses. Servers sending UNSUBSCRIBE Responses SHOULD use one of 887 these values. However, future circumstances may create situations 888 where other RCODE values are appropriate in UNSUBSCRIBE Responses, so 889 clients MUST be prepared to accept UNSUBSCRIBE Responses with any 890 RCODE value. 892 Having being successfully revoked with a correctly-formatted 893 UNSUBSCRIBE message (resulting in a response with RCODE NOERROR) the 894 previously referenced subscription is no longer active and the server 895 MAY discard the state associated with it immediately, or later, at 896 the server's discretion. 898 Nonzero RCODE values signal some kind of error. 900 RCODE value FORMERR indicates an incorrect MESSAGE ID or other 901 message format error. 903 RCODE values NOTIMP and SSOPNOTIMP should not occur in practice. 905 A server would only generate NOTIMP if it did not support Session 906 Signaling, and if the server does not support Session Signaling then 907 it should not be possible for a client to have an active subscription 908 to cancel. 910 Similarly, a server would only generate SSOPNOTIMP if it did not 911 support Push Notifications, and if the server does not support Push 912 Notifications then it should not be possible for a client to have an 913 active subscription to cancel. 915 All nonzero RCODE values indicate a serious problem with the client. 916 After sending an error response, the server SHOULD send a DNS Push 917 Notification Terminate Session operation TLV and then close the TCP 918 connection, as described in the DNS Session Signaling specification 919 [I-D.ietf-dnsop-session-signal]. 921 6.5. DNS Session Signaling Push Notification RECONFIRM 923 Sometimes, particularly when used with a Hybrid Proxy 924 [I-D.ietf-dnssd-hybrid], a DNS Zone may contain stale data. When a 925 client encounters data that it believe may be stale (e.g., an SRV 926 record referencing a target host+port that is not responding to 927 connection requests) the client can send a RECONFIRM message to 928 request that the server re-verify that the data is still valid. For 929 a Hybrid Proxy, this causes it to issue new Multicast DNS requests to 930 ascertain whether the target device is still present. For other 931 types of DNS server, the RECONFIRM operation is currently undefined 932 and SHOULD be silently ignored. 934 A RECONFIRM request is formatted identically to a SUBSCRIBE request, 935 except that the TLV type is RECONFIRM (tentatively 67) instead of 936 SUBSCRIBE. Additionally, QTYPE MUST NOT be the value ANY (255) and 937 QCLASS MUST NOT be the value ANY (255). 939 Like all DNS Session Signaling [I-D.ietf-dnsop-session-signal] 940 requests, a RECONFIRM request MUST contain a unique MESSAGE ID, not 941 currently in use in this session. 943 A RECONFIRM request generates exactly one RECONFIRM response from the 944 server, formatted identically to a SUBSCRIBE response, which echoes 945 back the unique MESSAGE ID from the RECONFIRM request. 947 In the RECONFIRM response the RCODE indicates whether or not the 948 request was successful. Supported RCODEs are as follows: 950 +------------+-------+----------------------------------------------+ 951 | Mnemonic | Value | Description | 952 +------------+-------+----------------------------------------------+ 953 | NOERROR | 0 | RECONFIRM successful. | 954 | FORMERR | 1 | Server failed to process request due to a | 955 | | | malformed request. | 956 | NOTIMP | 4 | Server does not recognize DNS Session | 957 | | | Signaling Opcode. | 958 | SSOPNOTIMP | 11 | RECONFIRM operation not supported. | 959 +------------+-------+----------------------------------------------+ 961 RECONFIRM Response codes 963 This document specifies only these RCODE values for RECONFIRM 964 Responses. Servers sending RECONFIRM Responses SHOULD use one of 965 these values. However, future circumstances may create situations 966 where other RCODE values are appropriate in RECONFIRM Responses, so 967 clients MUST be prepared to accept RECONFIRM Responses with any RCODE 968 value. 970 A correctly-formatted RECONFIRM message results in a response with 971 RCODE NOERROR. 973 Nonzero RCODE values signal some kind of error. If the server sends 974 a nonzero RCODE then it SHOULD append a Terminate modifier TLV 975 [I-D.ietf-dnsop-session-signal] to the response specifying a delay 976 before the client attempts this operation again. The RECOMMENDED 977 value for the delay is five minutes. For serious errors, after 978 sending the error response, the server SHOULD send a DNS Push 979 Notification Terminate Session operation TLV and then close the TCP 980 connection, as described in the DNS Session Signaling specification 981 [I-D.ietf-dnsop-session-signal]. 983 If, after receiving a valid RECONFIRM request, the server determines 984 that the records are in fact no longer valid, then subsequent DNS 985 PUSH Messages will be generated to inform interested clients. Thus, 986 one client discovering that a previously-advertised printer is no 987 longer present has the side effect of informing all other interested 988 clients that the printer in question is now gone. 990 6.6. Client-Initiated Termination 992 An individual subscription is terminated by sending an UNSUBSCRIBE 993 TLV for that specific subscription, or all subscriptions can be 994 cancelled at once by the client closing the connection. When a 995 client terminates an individual subscription (via UNSUBSCRIBE) or all 996 subscriptions on that connection (by closing the connection) it is 997 signaling to the server that it is longer interested in receiving 998 those particular updates. It is informing the server that the server 999 may release any state information it has been keeping with regards to 1000 these particular subscriptions. 1002 After terminating its last subscription on a connection via 1003 UNSUBSCRIBE, a client MAY close the connection immediately, or it may 1004 keep it open if it anticipates performing further operations on that 1005 connection in the future. If a client wishes to keep an idle 1006 connection open, it MUST continue to meet its keepalive obligations 1007 [I-D.ietf-dnsop-session-signal] or the server is entitled to close 1008 the connection (see below). 1010 If a client plans to terminate one or more subscriptions on a 1011 connection and doesn't intend to keep that connection open, then as 1012 an efficiency optimization it MAY instead choose to simply close the 1013 connection, which implicitly terminates all subscriptions on that 1014 connection. This may occur because the client computer is being shut 1015 down, is going to sleep, the application requiring the subscriptions 1016 has terminated, or simply because the last active subscription on 1017 that connection has been cancelled. 1019 When closing a connection, a client will generally do an abortive 1020 disconnect, sending a TCP RST. This immediately discards all 1021 remaining inbound and outbound data, which is appropriate if the 1022 client no longer has any interest in this data. In the BSD Sockets 1023 API, sending a TCP RST is achieved by setting the SO_LINGER option 1024 with a time of 0 seconds and then closing the socket. 1026 If a client has performed operations on this connection that it would 1027 not want lost (like DNS updates) then the client SHOULD do an orderly 1028 disconnect, sending a TCP FIN. In the BSD Sockets API, sending a TCP 1029 FIN is achieved by calling "shutdown(s,SHUT_WR)" and keeping the 1030 socket open until all remaining data has been read from it. 1032 7. Security Considerations 1034 TLS support is REQUIRED in DNS Push Notifications. There is no 1035 provision for opportunistic encryption using a mechanism like 1036 "STARTTLS". 1038 DNSSEC is RECOMMENDED for DNS Push Notifications. TLS alone does not 1039 provide complete security. TLS certificate verification can provide 1040 reasonable assurance that the client is really talking to the server 1041 associated with the desired host name, but since the desired host 1042 name is learned via a DNS SRV query, if the SRV query is subverted 1043 then the client may have a secure connection to a rogue server. 1044 DNSSEC can provided added confidence that the SRV query has not been 1045 subverted. 1047 7.1. Security Services 1049 It is the goal of using TLS to provide the following security 1050 services: 1052 Confidentiality: All application-layer communication is encrypted 1053 with the goal that no party should be able to decrypt it except 1054 the intended receiver. 1056 Data integrity protection: Any changes made to the communication in 1057 transit are detectable by the receiver. 1059 Authentication: An end-point of the TLS communication is 1060 authenticated as the intended entity to communicate with. 1062 Deployment recommendations on the appropriate key lengths and cypher 1063 suites are beyond the scope of this document. Please refer to TLS 1064 Recommendations [RFC7525] for the best current practices. Keep in 1065 mind that best practices only exist for a snapshot in time and 1066 recommendations will continue to change. Updated versions or errata 1067 may exist for these recommendations. 1069 7.2. TLS Name Authentication 1071 As described in Section 6.1, the client discovers the DNS Push 1072 Notification server using an SRV lookup for the record name 1073 "_dns-push-tls._tcp.". The server connection endpoint SHOULD 1074 then be authenticated using DANE TLSA records for the associated SRV 1075 record. This associates the target's name and port number with a 1076 trusted TLS certificate [RFC7673]. This procedure uses the TLS Sever 1077 Name Indication (SNI) extension [RFC6066] to inform the server of the 1078 name the client has authenticated through the use of TLSA records. 1079 Therefore, if the SRV record passes DNSSEC validation and a TLSA 1080 record matching the target name is useable, an SNI extension MUST be 1081 used for the target name to ensure the client is connecting to the 1082 server it has authenticated. If the target name does not have a 1083 usable TLSA record, then the use of the SNI extension is optional. 1085 7.3. TLS Compression 1087 In order to reduce the chances of compression-related attacks, TLS- 1088 level compression SHOULD be disabled when using TLS versions 1.2 and 1089 earlier. In the draft version of TLS 1.3 [I-D.ietf-tls-tls13], TLS- 1090 level compression has been removed completely. 1092 7.4. TLS Session Resumption 1094 TLS Session Resumption is permissible on DNS Push Notification 1095 servers. The server may keep TLS state with Session IDs [RFC5246] or 1096 operate in stateless mode by sending a Session Ticket [RFC5077] to 1097 the client for it to store. However, once the connection is closed, 1098 any existing subscriptions will be dropped. When the TLS session is 1099 resumed, the DNS Push Notification server will not have any 1100 subscription state and will proceed as with any other new connection. 1101 Use of TLS Session Resumption allows a new TLS connection to be set 1102 up more quickly, but the client will still have to recreate any 1103 desired subscriptions. 1105 8. IANA Considerations 1107 This document defines the service name: "_dns-push-tls._tcp". 1108 It is only applicable for the TCP protocol. 1109 This name is to be published in the IANA Service Name Registry. 1111 This document defines three DNS Session Signaling TLV types: 1112 SUBSCRIBE with (tentative) value 64, PUSH with (tentative) value 65, 1113 UNSUBSCRIBE with (tentative) value 66, and RECONFIRM with (tentative) 1114 value 67. 1116 9. Acknowledgements 1118 The authors would like to thank Kiren Sekar and Marc Krochmal for 1119 previous work completed in this field. 1121 This draft has been improved due to comments from Ran Atkinson, Tim 1122 Chown, Mark Delany, Ralph Droms, Bernie Volz, Jan Komissar, Manju 1123 Shankar Rao, Markus Stenberg, Dave Thaler, and Soraia Zlatkovic. 1125 10. References 1127 10.1. Normative References 1129 [I-D.ietf-dnsop-session-signal] 1130 Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1131 Mankin, A., and T. Pusateri, "DNS Session Signaling", 1132 draft-ietf-dnsop-session-signal-00 (work in progress), 1133 August 2016. 1135 [I-D.ietf-tls-tls13] 1136 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1137 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 1138 October 2016. 1140 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1141 DOI 10.17487/RFC0768, August 1980, 1142 . 1144 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1145 RFC 793, DOI 10.17487/RFC0793, September 1981, 1146 . 1148 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1149 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1150 . 1152 [RFC1035] Mockapetris, P., "Domain names - implementation and 1153 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1154 November 1987, . 1156 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1157 Application and Support", STD 3, RFC 1123, 1158 DOI 10.17487/RFC1123, October 1989, 1159 . 1161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1162 Requirement Levels", BCP 14, RFC 2119, 1163 DOI 10.17487/RFC2119, March 1997, 1164 . 1166 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1167 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1168 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1169 . 1171 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1172 specifying the location of services (DNS SRV)", RFC 2782, 1173 DOI 10.17487/RFC2782, February 2000, 1174 . 1176 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1177 (TLS) Protocol Version 1.2", RFC 5246, 1178 DOI 10.17487/RFC5246, August 2008, 1179 . 1181 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1182 Extensions: Extension Definitions", RFC 6066, 1183 DOI 10.17487/RFC6066, January 2011, 1184 . 1186 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1187 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1188 April 2013, . 1190 [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1191 Based Authentication of Named Entities (DANE) TLSA Records 1192 with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 1193 2015, . 1195 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1196 D. Wessels, "DNS Transport over TCP - Implementation 1197 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1198 . 1200 10.2. Informative References 1202 [I-D.dukkipati-tcpm-tcp-loss-probe] 1203 Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 1204 "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of 1205 Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work 1206 in progress), February 2013. 1208 [I-D.ietf-dnssd-hybrid] 1209 Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service 1210 Discovery", draft-ietf-dnssd-hybrid-03 (work in progress), 1211 February 2016. 1213 [I-D.sekar-dns-llq] 1214 Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- 1215 llq-01 (work in progress), August 2006. 1217 [IPJ.9-4-TCPSYN] 1218 Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The 1219 Internet Protocol Journal, Cisco Systems, Volume 9, 1220 Number 4, December 2006. 1222 [obs] "Observer Pattern", . 1225 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1226 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1227 August 1996, . 1229 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1230 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 1231 December 2005, . 1233 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 1234 RFC 4953, DOI 10.17487/RFC4953, July 2007, 1235 . 1237 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1238 "Transport Layer Security (TLS) Session Resumption without 1239 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1240 January 2008, . 1242 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1243 DOI 10.17487/RFC6762, February 2013, 1244 . 1246 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1247 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1248 . 1250 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1251 "TCP Extensions for Multipath Operation with Multiple 1252 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1253 . 1255 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1256 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1257 . 1259 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1260 "Recommendations for Secure Use of Transport Layer 1261 Security (TLS) and Datagram Transport Layer Security 1262 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1263 2015, . 1265 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1266 and P. Hoffman, "Specification for DNS over Transport 1267 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1268 2016, . 1270 [XEP0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1271 Subscribe", XSF XEP 0060, July 2010. 1273 Authors' Addresses 1275 Tom Pusateri 1276 Seeking affiliation 1277 Hilton Head Island, SC 1278 USA 1280 Phone: +1 843 473 7394 1281 Email: pusateri@bangj.com 1283 Stuart Cheshire 1284 Apple Inc. 1285 1 Infinite Loop 1286 Cupertino, CA 95014 1287 USA 1289 Phone: +1 408 974 3207 1290 Email: cheshire@apple.com