idnits 2.17.1 draft-ietf-dnssd-push-10.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 (March 13, 2017) is 2601 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 (-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 (-20) exists of draft-ietf-dnsop-session-signal-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'SN' == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-06 == 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 (==), 6 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: September 14, 2017 Apple Inc. 6 March 13, 2017 8 DNS Push Notifications 9 draft-ietf-dnssd-push-10 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 17 for a client to be asynchronously notified when these changes occur. 18 This document defines a mechanism for a client to be notified 19 of such 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 September 14, 2017. 38 Copyright Notice 40 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. State Considerations . . . . . . . . . . . . . . . . . . . . 8 61 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 9 62 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 12 64 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 13 65 6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 15 66 6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 18 67 6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 19 68 6.3.2. PUSH Response . . . . . . . . . . . . . . . . . . . . 21 69 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 22 70 6.4.1. UNSUBSCRIBE Request . . . . . . . . . . . . . . . . . 23 71 6.4.2. UNSUBSCRIBE Response . . . . . . . . . . . . . . . . 24 72 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 26 73 6.5.1. RECONFIRM Request . . . . . . . . . . . . . . . . . . 26 74 6.5.2. RECONFIRM Response . . . . . . . . . . . . . . . . . 28 75 6.6. Client-Initiated Termination . . . . . . . . . . . . . . 30 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 77 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 31 78 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 31 79 7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 32 80 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 32 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 33 85 10.2. Informative References . . . . . . . . . . . . . . . . . 34 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 88 1. Introduction 90 DNS records may be updated using DNS Update [RFC2136]. Other 91 mechanisms such as a Discovery Proxy [DisProx] can also generate 92 changes to a DNS zone. This document specifies a protocol for DNS 93 clients to subscribe to receive asynchronous notifications of changes 94 to RRSets of interest. It is immediately relevant in the case of DNS 95 Service Discovery [RFC6763] but is not limited to that use case, and 96 provides a general DNS mechanism for DNS record change notifications. 97 Familiarity with the DNS protocol and DNS packet formats is assumed 98 [RFC1034] [RFC1035] [RFC6895]. 100 1.1. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in 105 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 107 2. Motivation 109 As the domain name system continues to adapt to new uses and changes 110 in deployment, polling has the potential to burden DNS servers at 111 many levels throughout the network. Other network protocols have 112 successfully deployed a publish/subscribe model to state changes 113 following the Observer design pattern [obs]. XMPP Publish-Subscribe 114 [XEP0060] and Atom [RFC4287] are examples. While DNS servers are 115 generally highly tuned and capable of a high rate of query/response 116 traffic, adding a publish/subscribe model for tracking changes to DNS 117 records can result in more timely notification of changes with 118 reduced CPU usage and lower network traffic. 120 Multicast DNS [RFC6762] implementations always listen on a well known 121 link-local IP multicast group, and new services and updates are sent 122 for all group members to receive. Therefore, Multicast DNS already 123 has asynchronous change notification capability. However, when DNS 124 Service Discovery [RFC6763] is used across a wide area network using 125 Unicast DNS (possibly facilitated via a Discovery Proxy [DisProx]) it 126 would be beneficial to have an equivalent capability for Unicast DNS, 127 to allow clients to learn about DNS record changes in a timely manner 128 without polling. 130 The DNS Long-Lived Queries (LLQ) [I-D.sekar-dns-llq] mechanism is an 131 existing deployed solution to provide asynchronous change 132 notifications, used by Apple's Back to My Mac Service [RFC6281]. 133 Back to My Mac was designed in an era when the data centre operations 134 staff asserted that it was impossible for a server to handle large 135 numbers of mostly-idle TCP connections, so LLQ had to defined as a 136 UDP-based protocol, effectively replicating much of TCP's connection 137 state management logic in user space, and creating its own poor 138 imitations of existing TCP features like the three-way handshake, 139 flow control, and reliability. 141 This document builds on experience gained with the LLQ protocol, with 142 an improved design. Instead of using UDP, this specification uses 143 TCP, and therefore doesn't need to reinvent existing TCP 144 functionality. Using TCP also gives long-lived low-traffic 145 connections better longevity through NAT gateways without resorting 146 to excessive keepalive traffic [SessSig]. Instead of inventing a new 147 vocabulary of messages to communicate DNS zone changes as LLQ did, 148 this specification adopts the syntax and semantics of DNS Update 149 messages [RFC2136]. 151 3. Overview 153 The existing DNS Update protocol [RFC2136] provides a mechanism for 154 clients to add or delete individual resource records (RRs) or entire 155 resource record sets (RRSets) on the zone's server. 157 This specification adopts a simplified subset of these existing 158 syntax and semantics, and uses them for DNS Push Notification 159 messages going in the opposite direction, from server to client, to 160 communicate changes to a zone. The client subscribes for Push 161 Notifications by connecting to the server and sending DNS message(s) 162 indicating the RRSet(s) of interest. When the client loses interest 163 in updates to these records, it unsubscribes. 165 The DNS Push Notification server for a zone is any server capable 166 of generating the correct change notifications for a name. 167 It may be a master, slave, or stealth name server [RFC1996]. 168 Consequently, the "_dns-push-tls._tcp." SRV record for a 169 zone MAY reference the same target host and port as that zone's 170 "_dns-update-tls._tcp." SRV record. When the same target host 171 and port is offered for both DNS Updates and DNS Push Notifications, 172 a client MAY use a single TCP connection to that server for both DNS 173 Updates and DNS Push Notification Queries. 175 Supporting DNS Updates and DNS Push Notifications on the same server 176 is OPTIONAL. A DNS Push Notification server does NOT also have to 177 support DNS Update. 179 DNS Updates and DNS Push Notifications may be handled on different 180 ports on the same target host, in which case they are not considered 181 to be the "same server" for the purposes of this specification, and 182 communications with these two ports are handled independently. 184 Standard DNS Queries MAY be sent over a DNS Push Notification 185 connection, provided that these are queries for names falling within 186 the server's zone (the in the "_dns-push-tls._tcp." SRV 187 record). The RD (Recursion Desired) bit MUST be zero. 189 DNS Push Notification clients are NOT required to implement DNS 190 Update Prerequisite processing. Prerequisites are used to perform 191 tentative atomic test-and-set type operations when a client updates 192 records on a server, and that concept has no applicability when it 193 comes to an authoritative server informing a client of changes to DNS 194 records. 196 This DNS Push Notification specification includes support for DNS 197 classes, for completeness. However, in practice, it is anticipated 198 that for the foreseeable future the only DNS class in use will be DNS 199 class "IN", as is the reality today with existing DNS servers and 200 clients. A DNS Push Notification server MAY choose to implement only 201 DNS class "IN". 203 DNS Push Notifications impose less load on the responding server than 204 rapid polling would, but Push Notifications do still have a cost, so 205 DNS Push Notification clients MUST NOT recklessly create an excessive 206 number of Push Notification subscriptions. A subscription SHOULD 207 only be active when there is a valid reason to need live data (for 208 example, an on-screen display is currently showing the results to the 209 user) and the subscription SHOULD be cancelled as soon as the need 210 for that data ends (for example, when the user dismisses that 211 display). Implementations MAY want to implement idle timeouts, so 212 that if the user ceases interacting with the device, the display 213 showing the result of the DNS Push Notification subscription is 214 automatically dismissed after a certain period of inactivity. For 215 example, if a user presses the "Print" button on their smartphone, 216 and then leaves the phone showing the printer discovery screen until 217 the phone goes to sleep, then the printer discovery screen should be 218 automatically dismissed as the device goes to sleep. If the user 219 does still intend to print, this will require them to press the 220 "Print" button again when they wake their phone up. 222 A DNS Push Notification client MUST NOT routinely keep a DNS Push 223 Notification subscription active 24 hours a day, 7 days a week, just 224 to keep a list in memory up to date so that if the user does choose 225 to bring up an on-screen display of that data, it can be displayed 226 really fast. DNS Push Notifications are designed to be fast enough 227 that there is no need to pre-load a "warm" list in memory just in 228 case it might be needed later. 230 Generally, as described in the DNS Session Signaling specification 231 [SessSig], a client MUST NOT keep a connection to a server open 232 indefinitely if it has no subscriptions (or other operations) active 233 on that connection. A client MAY close a connection as soon as it 234 becomes idle, and then if needed in the future, open a new connection 235 when required. Alternatively, a client MAY speculatively keep an 236 idle connection open for some time, subject to the constraint that it 237 MUST NOT keep a connection open that has been idle for more than the 238 session's idle timeout (15 seconds by default). 240 4. Transport 242 Implementations of DNS Update [RFC2136] MAY use either User Datagram 243 Protocol (UDP) [RFC0768] or Transmission Control Protocol (TCP) 244 [RFC0793] as the transport protocol, in keeping with the historical 245 precedent that DNS queries must first be sent over UDP [RFC1123]. 246 This requirement to use UDP has subsequently been relaxed [RFC7766]. 248 In keeping with the more recent precedent, DNS Push Notification is 249 defined only for TCP. DNS Push Notification clients MUST use TLS 250 over TCP. 252 Connection setup over TCP ensures return reachability and alleviates 253 concerns of state overload at the server through anonymous 254 subscriptions. All subscribers are guaranteed to be reachable by the 255 server by virtue of the TCP three-way handshake. Flooding attacks 256 are possible with any protocol, and a benefit of TCP is that there 257 are already established industry best practices to guard against SYN 258 flooding and similar attacks [IPJ.9-4-TCPSYN] [RFC4953]. 260 Use of TCP also allows DNS Push Notifications to take advantage of 261 current and future developments in TCP, such as Multipath TCP (MPTCP) 262 [RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP) 263 [I-D.dukkipati-tcpm-tcp-loss-probe], and so on. 265 Transport Layer Security (TLS) [RFC5246] is well understood and 266 deployed across many protocols running over TCP. It is designed to 267 prevent eavesdropping, tampering, or message forgery. TLS is 268 REQUIRED for every connection between a client subscriber and server 269 in this protocol specification. Additional security measures such as 270 client authentication during TLS negotiation MAY also be employed to 271 increase the trust relationship between client and server. 273 Additional authentication of the SRV target using DNSSEC verification 274 and DANE TLSA records [RFC7673] is strongly encouraged. See below in 275 Section 7.2 for details. 277 5. State Considerations 279 Each DNS Push Notification server is capable of handling some finite 280 number of Push Notification subscriptions. This number will vary 281 from server to server and is based on physical machine 282 characteristics, network bandwidth, and operating system resource 283 allocation. After a client establishes a connection to a DNS server, 284 each subscription is individually accepted or rejected. Servers may 285 employ various techniques to limit subscriptions to a manageable 286 level. Correspondingly, the client is free to establish simultaneous 287 connections to alternate DNS servers that support DNS Push 288 Notifications for the zone and distribute subscriptions at its 289 discretion. In this way, both clients and servers can react to 290 resource constraints. Token bucket rate limiting schemes are also 291 effective in providing fairness by a server across numerous client 292 requests. 294 6. Protocol Operation 296 The DNS Push Notification protocol is a session-oriented protocol, 297 and makes use of DNS Session Signaling [SessSig]. 299 For details of the DNS Session Signaling message format refer to the 300 DNS Session Signaling specification [SessSig]. Those details are not 301 repeated here. 303 DNS Push Notification clients and servers MUST support DNS Session 304 Signaling, but the server MUST NOT issue any DNS Session Signaling 305 operations until after the client has first initiated a DNS Session 306 Signaling operation of its own. A single server can support DNS 307 Queries, DNS Updates, and DNS Push Notifications (using DNS Session 308 Signaling) on the same TCP port, and until the client has sent at 309 least one DNS Session Signaling operation the server does not know 310 what kind of client has connected to it. Once the client has 311 indicated willingness to use DNS Session Signaling operations by 312 sending one of its own, either side of the connection may then 313 initiate further Session Signaling operations at any time. 315 A DNS Push Notification exchange begins with the client discovering 316 the appropriate server, using the procedure described in Section 6.1, 317 and then making a TLS/TCP connection to it. 319 A typical DNS Push Notification client will immediately issue a DNS 320 Session Signaling Keepalive operation to request a session timeout or 321 keepalive interval longer than the the 15-second defaults, but this 322 is NOT REQUIRED. A DNS Push Notification client MAY issue other 323 requests on the connection first, and only issue a DNS Session 324 Signaling Keepalive operation later if it determines that to be 325 necessary. 327 Once the connection is made, the client may then add and remove Push 328 Notification subscriptions. In accordance with the current set of 329 active subscriptions the server sends relevant asynchronous Push 330 Notifications to the client. Note that a client MUST be prepared to 331 receive (and silently ignore) Push Notifications for subscriptions it 332 has previously removed, since there is no way to prevent the 333 situation where a Push Notification is in flight from server to 334 client while the client's UNSUBSCRIBE message cancelling that 335 subscription is simultaneously in flight from client to server. 337 The exchange between client and server terminates when either end 338 closes the TCP connection with a TCP FIN or RST. 340 6.1. Discovery 342 The first step in DNS Push Notification subscription is to discover 343 an appropriate DNS server that supports DNS Push Notifications for 344 the desired zone. The client MUST also determine which TCP port on 345 the server is listening for connections, which need not be (and often 346 is not) the typical TCP port 53 used for conventional DNS, or TCP 347 port 853 used for DNS over TLS [RFC7858]. 349 1. The client begins the discovery by sending a DNS query to its 350 local resolver, with record type SOA [RFC1035], for the domain 351 name to which it wishes to subscribe. 353 2. If the SOA record exists, it MUST be returned in the Answer 354 Section of the response. If not, the local resolver SHOULD 355 include the SOA record for the zone of the requested name in the 356 Authority Section. 358 3. If no SOA record is returned, the client then strips off the 359 leading label from the requested name. If the resulting name has 360 at least one label in it, the client sends a new SOA query and 361 processing continues at step 2 above. If the resulting name is 362 empty (the root label) then this is a network configuration error 363 and the client gives up. The client MAY retry the operation at a 364 later time, of the client's choosing, such after a change in 365 network attachment. 367 4. Once the SOA is known (either by virtue of being seen in the 368 Answer Section, or in the Authority Section), the client sends a 369 DNS query with type SRV [RFC2782] for the record name 370 "_dns-push-tls._tcp.", where is the owner name of 371 the discovered SOA record. 373 5. If the zone in question does not offer DNS Push Notifications 374 then SRV record MUST NOT exist and the SRV query will return a 375 negative answer. 377 6. If the zone in question is set up to offer DNS Push Notifications 378 then this SRV record MUST exist. The SRV "target" contains the 379 name of the server providing DNS Push Notifications for the zone. 380 The port number on which to contact the server is in the SRV 381 record "port" field. The address(es) of the target host MAY be 382 included in the Additional Section, however, the address records 383 SHOULD be authenticated before use as described below in 384 Section 7.2 [RFC7673]. 386 7. More than one SRV record may be returned. In this case, the 387 "priority" and "weight" values in the returned SRV records are 388 used to determine the order in which to contact the servers for 389 subscription requests. As described in the SRV specification 390 [RFC2782], the server with the lowest "priority" is first 391 contacted. If more than one server has the same "priority", the 392 "weight" indicates the weighted probability that the client 393 should contact that server. Higher weights have higher 394 probabilities of being selected. If a server is not reachable or 395 is not willing to accept a subscription request, then a 396 subsequent server is to be contacted. 398 Each time a client makes a new DNS Push Notification subscription 399 connection, it SHOULD repeat the discovery process in order to 400 determine the preferred DNS server for subscriptions at that time. 402 Note that this repeated discovery step is typically very fast and 403 typically results in no queries on the network. The client device 404 MUST respect the DNS TTL values on records it receives, and store 405 them in its local cache with this lifetime. This means that, as long 406 as the DNS TTL values on the authoritative records were set to 407 reasonable values, repeated application of this discovery process can 408 be completed nearly instantaneously by the client, using only 409 locally-stored cached data. 411 6.2. DNS Push Notification SUBSCRIBE 413 After connecting, and requesting a longer idle timeout and/or 414 keepalive interval if necessary, a DNS Push Notification client then 415 indicates its desire to receive DNS Push Notifications for a given 416 domain name by sending a SUBSCRIBE request over the established TLS 417 connection to the server. A SUBSCRIBE request is encoded in a DNS 418 Session Signaling [SessSig] message. This specification defines a 419 DNS Session Signaling TLV for DNS Push Notification SUBSCRIBE 420 Requests/Responses (tentatively Session Signaling Type Code 0x40). 422 A server MUST NOT initiate a SUBSCRIBE request. 424 6.2.1. SUBSCRIBE Request 426 A SUBSCRIBE request message begins with the standard DNS Session 427 Signaling 12-byte header [SessSig], followed by the SUBSCRIBE TLV. 428 The SSOP-DATA for the the SUBSCRIBE TLV is as follows: 430 1 1 1 1 1 1 431 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 432 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 433 | | 434 \ NAME \ 435 \ \ 436 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 437 | TYPE | 438 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 439 | CLASS | 440 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 442 Figure 1 444 The MESSAGE ID field MUST be set to a unique value, that the client 445 is not using for any other active operation on this connection. For 446 the purposes here, a MESSAGE ID is in use on this connection if the 447 client has used it in a request for which it has not yet received a 448 response, or if if the client has used it for a subscription which it 449 has not yet cancelled using UNSUBSCRIBE. In the SUBSCRIBE response 450 the server MUST echo back the MESSAGE ID value unchanged. 452 In the SUBSCRIBE TLV the SSOP-TYPE is SUBSCRIBE (tentatively 0x40). 453 The SSOP-LENGTH is the length of the SSOP-DATA that follows, which 454 specifies the name, type, and class of the record(s) being sought. 456 A SUBSCRIBE request MUST contain exactly one question. The SUBSCRIBE 457 TLV has no QDCOUNT field to specify more than one question. Since 458 SUBSCRIBE requests are sent over TCP, multiple SUBSCRIBE request 459 messages can be concatenated in a single TCP stream and packed 460 efficiently into TCP segments. 462 If accepted, the subscription will stay in effect until the client 463 cancels the subscription using UNSUBSCRIBE or until the connection 464 between the client and the server is closed. 466 SUBSCRIBE requests on a given connection MUST be unique. A client 467 MUST NOT send a SUBSCRIBE message that duplicates the NAME, TYPE and 468 CLASS of an existing active subscription on that TLS/TCP connection. 469 For the purpose of this matching, the established DNS case- 470 insensitivity for US-ASCII letters applies (e.g., "foo.com" and 471 "Foo.com" are the same). If a server receives such a duplicate 472 SUBSCRIBE message this is an error and the server MUST immediately 473 immediately terminate the connection with a TCP RST (or equivalent 474 for other protocols). 476 DNS wildcarding is not supported. That is, a wildcard ("*") in a 477 SUBSCRIBE message matches only a literal wildcard character ("*") in 478 the zone, and nothing else. 480 Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message 481 matches only a literal CNAME record in the zone, and nothing else. 483 A client may SUBSCRIBE to records that are unknown to the server at 484 the time of the request (providing that the name falls within one of 485 the zone(s) the server is responsible for) and this is not an error. 486 The server MUST accept these requests and send Push Notifications if 487 and when matching records are found in the future. 489 If neither TYPE nor CLASS are ANY (255) then this is a specific 490 subscription to changes for the given NAME, TYPE and CLASS. If one 491 or both of TYPE or CLASS are ANY (255) then this subscription matches 492 any type and/or any class, as appropriate. 494 NOTE: A little-known quirk of DNS is that in DNS QUERY requests, 495 QTYPE and QCLASS 255 mean "ANY" not "ALL". They indicate that the 496 server should respond with ANY matching records of its choosing, not 497 necessarily ALL matching records. This can lead to some surprising 498 and unexpected results, were a query returns some valid answers but 499 not all of them, and makes QTYPE=ANY queries less useful than people 500 sometimes imagine. 502 When used in conjunction with SUBSCRIBE, TYPE and CLASS 255 should be 503 interpreted to mean "ALL", not "ANY". After accepting a subscription 504 where one or both of TYPE or CLASS are 255, the server MUST send Push 505 Notification Updates for ALL record changes that match the 506 subscription, not just some of them. 508 6.2.2. SUBSCRIBE Response 510 Each SUBSCRIBE request generates exactly one SUBSCRIBE response from 511 the server. 513 A SUBSCRIBE response message begins with the standard DNS Session 514 Signaling 12-byte header [SessSig], possibly followed by one or more 515 optional Modifier TLVs, such as a Retry Delay Modifier TLV. 517 The MESSAGE ID field MUST echo the value given in the ID field of the 518 SUBSCRIBE request. This is how the client knows which request is 519 being responded to. 521 A SUBSCRIBE response message MUST NOT contain a Session Signaling 522 Operation TLV. The Session Signaling Operation TLV is NOT copied 523 from the SUBSCRIBE request. 525 In the SUBSCRIBE response the RCODE indicates whether or not the 526 subscription was accepted. Supported RCODEs are as follows: 528 +------------+-------+----------------------------------------------+ 529 | Mnemonic | Value | Description | 530 +------------+-------+----------------------------------------------+ 531 | NOERROR | 0 | SUBSCRIBE successful. | 532 | FORMERR | 1 | Server failed to process request due to a | 533 | | | malformed request. | 534 | SERVFAIL | 2 | Server failed to process request due to | 535 | | | resource exhaustion. | 536 | NXDOMAIN | 3 | NOT APPLICABLE. DNS Push Notification | 537 | | | servers MUST NOT return NXDOMAIN errors in | 538 | | | response to SUBSCRIBE requests. | 539 | NOTIMP | 4 | Server does not recognize DNS Session | 540 | | | Signaling Opcode. | 541 | REFUSED | 5 | Server refuses to process request for policy | 542 | | | or security reasons. | 543 | NOTAUTH | 9 | Server is not authoritative for the | 544 | | | requested name. | 545 | SSOPNOTIMP | 11 | SUBSCRIBE operation not supported. | 546 +------------+-------+----------------------------------------------+ 548 SUBSCRIBE Response codes 550 This document specifies only these RCODE values for SUBSCRIBE 551 Responses. Servers sending SUBSCRIBE Responses SHOULD use one of 552 these values. However, future circumstances may create situations 553 where other RCODE values are appropriate in SUBSCRIBE Responses, so 554 clients MUST be prepared to accept SUBSCRIBE Responses with any RCODE 555 value. 557 If the server sends a nonzero RCODE in the SUBSCRIBE response, either 558 the client is (at least partially) misconfigured or the server 559 resources are exhausted. In either case, the client shouldn't retry 560 the subscription right away. Either end can terminate the 561 connection, but the client may want to try this subscription again or 562 it may have other successful subscriptions that it doesn't want to 563 abandon. If the server sends a nonzero RCODE then it SHOULD append a 564 Retry Delay Modifier TLV [SessSig] to the response specifying a delay 565 before the client attempts this operation again. Recommended values 566 for the delay for different RCODE values are given below: 568 For RCODE = 1 (FORMERR) the delay may be any value selected by the 569 implementer. A value of five minutes is RECOMMENDED, to reduce 570 the risk of high load from defective clients. 572 For RCODE = 2 (SERVFAIL), which occurs due to resource exhaustion, 573 the delay should be chosen according to the level of server 574 overload and the anticipated duration of that overload. By 575 default, a value of one minute is RECOMMENDED. 577 For RCODE = 4 (NOTIMP), which occurs on a server that doesn't 578 implement DNS Session Signaling [SessSig], it is unlikely that the 579 server will begin supporting DNS Session Signaling in the next few 580 minutes, so the retry delay SHOULD be one hour. 582 For RCODE = 5 (REFUSED), which occurs on a server that implements 583 DNS Push Notifications, but is currently configured to disallow 584 DNS Push Notifications, the retry delay may be any value selected 585 by the implementer and/or configured by the operator. 586 This is a misconfiguration, since this server is listed in a 587 "_dns-push-tls._tcp." SRV record, but the server itself is 588 not currently configured to support DNS Push Notifications. Since 589 it is possible that the misconfiguration may be repaired at any 590 time, the retry delay should not be set too high. By default, a 591 value of 5 minutes is RECOMMENDED. 593 For RCODE = 9 (NOTAUTH), which occurs on a server that implements 594 DNS Push Notifications, but is not configured to be authoritative 595 for the requested name, the retry delay may be any value selected 596 by the implementer and/or configured by the operator. 597 This is a misconfiguration, since this server is listed in a 598 "_dns-push-tls._tcp." SRV record, but the server itself is 599 not currently configured to support DNS Push Notifications for 600 that zone. Since it is possible that the misconfiguration may be 601 repaired at any time, the retry delay should not be set too high. 602 By default, a value of 5 minutes is RECOMMENDED. 604 For RCODE = 11 (DNS Push SUBSCRIBE operation not supported), which 605 occurs on a server that doesn't implement DNS Push Notifications, 606 it is unlikely that the server will begin supporting DNS Push 607 Notifications in the next few minutes, so the retry delay SHOULD 608 be one hour. 610 For other RCODE values, the retry delay should be set by the 611 server as appropriate for that error condition. By default, a 612 value of 5 minutes is RECOMMENDED. 614 For RCODE = 9 (NOTAUTH), the time delay applies to requests for other 615 names falling within the same zone. Requests for names falling 616 within other zones are not subject to the delay. For all other 617 RCODEs the time delay applies to all subsequent requests to this 618 server. 620 After sending an error response the server MAY allow the connection 621 to remain open, or MAY send a DNS Push Notification Retry Delay 622 Operation TLV and then close the TCP connection, as described in the 623 DNS Session Signaling specification [SessSig]. Clients MUST 624 correctly handle both cases. 626 6.3. DNS Push Notification Updates 628 Once a subscription has been successfully established, the server 629 generates PUSH messages to send to the client as appropriate. In the 630 case that the answer set was non-empty at the moment the subscription 631 was established, an initial PUSH message will be sent immediately 632 following the SUBSCRIBE Response. Subsequent changes to the answer 633 set are then communicated to the client in subsequent PUSH messages. 635 6.3.1. PUSH Message 637 A PUSH message begins with the standard DNS Session Signaling 12-byte 638 header [SessSig], followed by the PUSH TLV. 640 The MESSAGE ID field MUST be set to a unique value, that the server 641 is not currently using for any other active outgoing request that it 642 has sent on this connection. The MESSAGE ID in the outgoing PUSH 643 message is selected by the server and has no relationship to the 644 MESSAGE ID in any of the client subscriptions it may relate to. In 645 the PUSH response the client MUST echo back the MESSAGE ID value 646 unchanged. 648 In the PUSH TLV the SSOP-TYPE is PUSH (tentatively 0x41). The SSOP- 649 LENGTH is the length of the SSOP-DATA that follows, which specifies 650 the changes being communicated. 652 The SSOP-DATA contains one or more Update records, in customary 653 Resource Record format, as used in DNS Update [RFC2136] messages. A 654 PUSH Message MUST contain at least one Update record. If a PUSH 655 Message is received that contains no Update records this is a fatal 656 error, and the receiver MUST immediately terminate the connection 657 with a TCP RST (or equivalent for other protocols). 659 The SSOP-DATA contains the relevant change information for the 660 client, formatted identically to a DNS Update [RFC2136]. To recap: 662 Delete all RRsets from a name: 663 TTL=0, CLASS=ANY, RDLENGTH=0, TYPE=ANY. 665 Delete an RRset from a name: 666 TTL=0, CLASS=ANY, RDLENGTH=0; 667 TYPE specifies the RRset being deleted. 669 Delete an individual RR from a name: 670 TTL=0, CLASS=NONE; 671 TYPE, RDLENGTH and RDATA specifies the RR being deleted. 673 Add to an RRset: 674 TTL, CLASS, TYPE, RDLENGTH and RDATA specifies the RR being added. 676 When processing the records received in a PUSH Message, the receiving 677 client MUST validate that the records being added or deleted 678 correspond with at least one currently active subscription on that 679 connection. Specifically, the record name MUST match the name given 680 in the SUBSCRIBE request, subject to the usual established DNS case- 681 insensitivity for US-ASCII letters. If the TYPE in the SUBSCRIBE 682 request was not ANY (255) then the TYPE of the record must match the 683 TYPE given in the SUBSCRIBE request. If the CLASS in the SUBSCRIBE 684 request was not ANY (255) then the CLASS of the record must match the 685 CLASS given in the SUBSCRIBE request. If a matching active 686 subscription on that connection is not found, then that individual 687 record addition/deletion is silently ignored. Processing of other 688 additions and deletions in this message is not affected. The TCP 689 connection is not closed. This is to allow for the unavoidable race 690 condition where a client sends an outbound UNSUBSCRIBE while inbound 691 PUSH messages for that subscription from the server are still in 692 flight. 694 In the case where a single change affects more than one active 695 subscription, only one PUSH message is sent. For example, a PUSH 696 message adding a given record may match both a SUBSCRIBE request with 697 the same TYPE and a different SUBSCRIBE request with TYPE=ANY. It is 698 not the case that two PUSH messages are sent because the new record 699 matches two active subscriptions. 701 The server SHOULD encode change notifications in the most efficient 702 manner possible. For example, when three AAAA records are deleted 703 from a given name, and no other AAAA records exist for that name, the 704 server SHOULD send a "delete an RRset from a name" PUSH message, not 705 three separate "delete an individual RR from a name" PUSH messages. 706 Similarly, when both an SRV and a TXT record are deleted from a given 707 name, and no other records of any kind exist for that name, the 708 server SHOULD send a "delete all RRsets from a name" PUSH message, 709 not two separate "delete an RRset from a name" PUSH messages. 711 A server SHOULD combine multiple change notifications in a single 712 PUSH message when possible, even if those change notifications apply 713 to different subscriptions. Conceptually, a PUSH message is a 714 connection-level mechanism, not a subscription-level mechanism. 716 Reception of a PUSH message by a client generates a PUSH response 717 back to the server. 719 The TTL of an added record is stored by the client and decremented as 720 time passes, with the caveat that for as long as a relevant 721 subscription is active, the TTL does not decrement below 1 second. 722 For as long as a relevant subscription remains active, the client 723 SHOULD assume that when a record goes away the server will notify it 724 of that fact. Consequently, a client does not have to poll to verify 725 that the record is still there. Once a subscription is cancelled 726 (individually, or as a result of the TCP connection being closed) 727 record ageing resumes and records are removed from the local cache 728 when their TTL reaches zero. 730 6.3.2. PUSH Response 732 Each PUSH message generates exactly one PUSH response from the 733 receiver. 735 A PUSH response message begins with the standard DNS Session 736 Signaling 12-byte header [SessSig], possibly followed by one or more 737 optional Modifier TLVs, such as a Retry Delay Modifier TLV. 739 The MESSAGE ID field MUST echo the value given in the ID field of the 740 PUSH message. 742 A PUSH response message MUST NOT contain a Session Signaling 743 Operation TLV. The Session Signaling Operation TLV is NOT copied 744 from the PUSH message. 746 In a PUSH response the RCODE MUST be zero. Receiving a PUSH response 747 with a nonzero RCODE is a fatal error, and the receiver MUST 748 immediately terminate the connection with a TCP RST (or equivalent 749 for other protocols). 751 6.4. DNS Push Notification UNSUBSCRIBE 753 To cancel an individual subscription without closing the entire 754 connection, the client sends an UNSUBSCRIBE message over the 755 established TCP connection to the server. The UNSUBSCRIBE message is 756 encoded in a DNS Session Signaling [SessSig] message. This 757 specification defines a DNS Session Signaling TLV for DNS Push 758 Notification UNSUBSCRIBE Requests/Responses (tentatively Session 759 Signaling Type Code 0x42). 761 A server MUST NOT initiate an UNSUBSCRIBE request. 763 6.4.1. UNSUBSCRIBE Request 765 An UNSUBSCRIBE request message begins with the standard DNS Session 766 Signaling 12-byte header [SessSig], followed by the UNSUBSCRIBE TLV. 768 In the UNSUBSCRIBE TLV the SSOP-TYPE is UNSUBSCRIBE (tentatively 769 0x42). The SSOP-LENGTH is zero. There is no SSOP-DATA for 770 UNSUBSCRIBE. 772 The MESSAGE ID field MUST match the value given in the ID field of an 773 active SUBSCRIBE request. This is how the server knows which 774 SUBSCRIBE request is being cancelled. After receipt of the 775 UNSUBSCRIBE request, the SUBSCRIBE request is no longer active. If a 776 server receives an UNSUBSCRIBE message where the MESSAGE ID does not 777 match the ID of an active SUBSCRIBE request the server MUST return a 778 response containing RCODE = 3 (NXDOMAIN). 780 It is allowable for the client to issue an UNSUBSCRIBE request for a 781 previous SUBSCRIBE request for which the client has not yet received 782 a SUBSCRIBE response. This is to allow for the case where a client 783 starts and stops a subscription in less than the round-trip time to 784 the server. The client is NOT required to wait for the SUBSCRIBE 785 response before issuing the UNSUBSCRIBE request. A consequence of 786 this is that if the client issues an UNSUBSCRIBE request for an as- 787 yet unacknowledged SUBSCRIBE request, and the SUBSCRIBE request is 788 subsequently unsuccessful for some reason, then when the UNSUBSCRIBE 789 request is eventually processed it will be an UNSUBSCRIBE request for 790 a nonexistent subscription, which will result NXDOMAIN response. 792 Note that when the client issues an UNSUBSCRIBE request for an as-yet 793 unacknowledged SUBSCRIBE request, at that moment the client will have 794 two outstanding DNS Session Signaling operations with same MESSAGE 795 ID, a SUBSCRIBE request and an UNSUBSCRIBE request, which will both 796 receive responses, in that order. When the client has multiple 797 outstanding DNS Session Signaling operations with same MESSAGE ID, 798 care should be taken that when a DNS Session Signaling response 799 message is received for that MESSAGE ID, it is associated with the 800 *first* unacknowledged request. 802 6.4.2. UNSUBSCRIBE Response 804 Each UNSUBSCRIBE request generates exactly one UNSUBSCRIBE response 805 from the server. 807 An UNSUBSCRIBE response message begins with the standard DNS Session 808 Signaling 12-byte header [SessSig], possibly followed by one or more 809 optional Modifier TLVs, such as a Retry Delay Modifier TLV. 811 The MESSAGE ID field MUST echo the value given in the ID field of the 812 UNSUBSCRIBE request. This is how the client knows which request is 813 being responded to. 815 An UNSUBSCRIBE response message MUST NOT contain a Session Signaling 816 Operation TLV. The Session Signaling Operation TLV is NOT copied 817 from the UNSUBSCRIBE request. 819 In the UNSUBSCRIBE response the RCODE indicates whether or not the 820 unsubscribe request was successful. Supported RCODEs are as follows: 822 +------------+-------+----------------------------------------------+ 823 | Mnemonic | Value | Description | 824 +------------+-------+----------------------------------------------+ 825 | NOERROR | 0 | UNSUBSCRIBE successful. | 826 | FORMERR | 1 | Server failed to process request due to a | 827 | | | malformed request. | 828 | NXDOMAIN | 3 | Specified subscription does not exist. | 829 | NOTIMP | 4 | Server does not recognize DNS Session | 830 | | | Signaling Opcode. | 831 | SSOPNOTIMP | 11 | UNSUBSCRIBE operation not supported. | 832 +------------+-------+----------------------------------------------+ 834 UNSUBSCRIBE Response codes 836 This document specifies only these RCODE values for UNSUBSCRIBE 837 Responses. Servers sending UNSUBSCRIBE Responses SHOULD use one of 838 these values. However, future circumstances may create situations 839 where other RCODE values are appropriate in UNSUBSCRIBE Responses, so 840 clients MUST be prepared to accept UNSUBSCRIBE Responses with any 841 RCODE value. 843 Having being successfully revoked with a correctly-formatted 844 UNSUBSCRIBE message (resulting in a response with RCODE NOERROR) the 845 previously referenced subscription is no longer active and the server 846 MAY discard the state associated with it immediately, or later, at 847 the server's discretion. 849 Nonzero RCODE values signal some kind of error. 851 RCODE value FORMERR indicates a message format error. 853 RCODE value NXDOMAIN indicates a MESSAGE ID that does not correspond 854 to any active subscription. 856 RCODE values NOTIMP and SSOPNOTIMP should not occur in practice. 858 A server would only generate NOTIMP if it did not support Session 859 Signaling, and if the server does not support Session Signaling then 860 it should not be possible for a client to have an active subscription 861 to cancel. 863 Similarly, a server would only generate SSOPNOTIMP if it did not 864 support Push Notifications, and if the server does not support Push 865 Notifications then it should not be possible for a client to have an 866 active subscription to cancel. 868 Nonzero RCODE values other than NXDOMAIN indicate a serious problem 869 with the client. After sending an error response other than 870 NXDOMAIN, the server SHOULD send a DNS Session Signaling Retry Delay 871 Operation TLV and then close the TCP connection, as described in the 872 DNS Session Signaling specification [SessSig]. 874 6.5. DNS Push Notification RECONFIRM 876 Sometimes, particularly when used with a Discovery Proxy [DisProx], a 877 DNS Zone may contain stale data. When a client encounters data that 878 it believe may be stale (e.g., an SRV record referencing a target 879 host+port that is not responding to connection requests) the client 880 can send a RECONFIRM request to ask the server to re-verify that the 881 data is still valid. For a Discovery Proxy, this causes it to issue 882 new Multicast DNS requests to ascertain whether the target device is 883 still present. For other types of DNS server, the RECONFIRM 884 operation is currently undefined, and SHOULD result in a NOERROR 885 response, but otherwise need not cause any action to occur. Frequent 886 RECONFIRM operations may be a sign of network unreliability, or some 887 kind of misconfiguration, so RECONFIRM operations MAY be logged or 888 otherwise communicated to a human administrator to assist in 889 detecting, and remedying, such network problems. 891 If, after receiving a valid RECONFIRM request, the server determines 892 that the disputed records are in fact no longer valid, then 893 subsequent DNS PUSH Messages will be generated to inform interested 894 clients. Thus, one client discovering that a previously-advertised 895 device (like a network printer) is no longer present has the side 896 effect of informing all other interested clients that the device in 897 question is now gone. 899 6.5.1. RECONFIRM Request 901 A RECONFIRM request message begins with the standard DNS Session 902 Signaling 12-byte header [SessSig], followed by the RECONFIRM TLV. 903 The SSOP-DATA for the the RECONFIRM TLV is as follows: 905 1 1 1 1 1 1 906 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 907 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 908 | | 909 \ NAME \ 910 \ \ 911 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 912 | TYPE | 913 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 914 | CLASS | 915 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 916 | RDLEN | 917 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 918 | | 919 \ RDATA \ 920 \ \ 921 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 923 Figure 2 925 The MESSAGE ID field MUST be set to a unique value, that the client 926 is not using for any other active operation on this connection. For 927 the purposes here, a MESSAGE ID is in use on this connection if the 928 client has used it in a request for which it has not yet received a 929 response, or if if the client has used it for a subscription which it 930 has not yet cancelled using UNSUBSCRIBE. In the RECONFIRM response 931 the server MUST echo back the MESSAGE ID value unchanged. 933 In the RECONFIRM TLV the SSOP-TYPE is RECONFIRM (tentatively 0x43). 934 The SSOP-LENGTH is the length of the data that follows, which 935 specifies the name, type, class, and content of the record being 936 disputed. 938 A RECONFIRM request MUST contain exactly one record. The RECONFIRM 939 TLV has no count field to specify more than one record. Since 940 RECONFIRM requests are sent over TCP, multiple RECONFIRM request 941 messages can be concatenated in a single TCP stream and packed 942 efficiently into TCP segments. 944 TYPE MUST NOT be the value ANY (255) and CLASS MUST NOT be the value 945 ANY (255). 947 DNS wildcarding is not supported. That is, a wildcard ("*") in a 948 RECONFIRM message matches only a literal wildcard character ("*") in 949 the zone, and nothing else. 951 Aliasing is not supported. That is, a CNAME in a RECONFIRM message 952 matches only a literal CNAME record in the zone, and nothing else. 954 6.5.2. RECONFIRM Response 956 Each RECONFIRM request generates exactly one RECONFIRM response from 957 the server. 959 A RECONFIRM response message begins with the standard DNS Session 960 Signaling 12-byte header [SessSig], possibly followed by one or more 961 optional Modifier TLVs, such as a Retry Delay Modifier TLV. 963 The MESSAGE ID field MUST echo the value given in the ID field of the 964 RECONFIRM request. This is how the client knows which request is 965 being responded to. 967 A RECONFIRM response message MUST NOT contain a Session Signaling 968 Operation TLV. The Session Signaling Operation TLV is NOT copied 969 from the RECONFIRM request. 971 In the RECONFIRM response the RCODE confirms receipt of the 972 reconfirmation request. Supported RCODEs are as follows: 974 +------------+-------+----------------------------------------------+ 975 | Mnemonic | Value | Description | 976 +------------+-------+----------------------------------------------+ 977 | NOERROR | 0 | RECONFIRM accepted. | 978 | FORMERR | 1 | Server failed to process request due to a | 979 | | | malformed request. | 980 | SERVFAIL | 2 | Server failed to process request due to | 981 | | | resource exhaustion. | 982 | NXDOMAIN | 3 | NOT APPLICABLE. DNS Push Notification | 983 | | | servers MUST NOT return NXDOMAIN errors in | 984 | | | response to RECONFIRM requests. | 985 | NOTIMP | 4 | Server does not recognize DNS Session | 986 | | | Signaling Opcode. | 987 | REFUSED | 5 | Server refuses to process request for policy | 988 | | | or security reasons. | 989 | NOTAUTH | 9 | Server is not authoritative for the | 990 | | | requested name. | 991 | SSOPNOTIMP | 11 | RECONFIRM operation not supported. | 992 +------------+-------+----------------------------------------------+ 994 RECONFIRM Response codes 996 This document specifies only these RCODE values for RECONFIRM 997 Responses. Servers sending RECONFIRM Responses SHOULD use one of 998 these values. However, future circumstances may create situations 999 where other RCODE values are appropriate in RECONFIRM Responses, so 1000 clients MUST be prepared to accept RECONFIRM Responses with any RCODE 1001 value. 1003 Nonzero RCODE values signal some kind of error. 1005 RCODE value FORMERR indicates a message format error, for example 1006 TYPE or CLASS being ANY (255). 1008 RCODE value SERVFAIL indicates that the server is overloaded. 1010 RCODE values NOTIMP indicates that the server does not support 1011 Session Signaling, and Session Signaling is required for RECONFIRM 1012 requests. 1014 RCODE value REFUSED indicates that the server supports RECONFIRM 1015 requests but is currently not configured to accept them from this 1016 client. 1018 RCODE value NOTAUTH indicates that the server is not authoritative 1019 for the requested name, and can do nothing to remedy the apparent 1020 error. Note that there may be future cases in which a server is able 1021 to pass on the RECONFIRM request to the ultimate source of the 1022 information, and in these cases the server should return NOERROR. 1024 RCODE value SSOPNOTIMP indicates that the server does not support 1025 RECONFIRM requests. 1027 Similarly, a server would only generate SSOPNOTIMP if it did not 1028 support Push Notifications, and if the server does not support Push 1029 Notifications then it should not be possible for a client to have an 1030 active subscription to cancel. 1032 Nonzero RCODE values SERVFAIL, REFUSED and SSOPNOTIMP are benign from 1033 the client's point of view. The client may log them to aid in 1034 debugging, but otherwise they require no special action. 1036 Nonzero RCODE values other than these three indicate a serious 1037 problem with the client. After sending an error response other than 1038 one of these three, the server SHOULD send a DNS Session Signaling 1039 Retry Delay Operation TLV and then close the TCP connection, as 1040 described in the DNS Session Signaling specification [SessSig]. 1042 6.6. Client-Initiated Termination 1044 An individual subscription is terminated by sending an UNSUBSCRIBE 1045 TLV for that specific subscription, or all subscriptions can be 1046 cancelled at once by the client closing the connection. When a 1047 client terminates an individual subscription (via UNSUBSCRIBE) or all 1048 subscriptions on that connection (by closing the connection) it is 1049 signaling to the server that it is longer interested in receiving 1050 those particular updates. It is informing the server that the server 1051 may release any state information it has been keeping with regards to 1052 these particular subscriptions. 1054 After terminating its last subscription on a connection via 1055 UNSUBSCRIBE, a client MAY close the connection immediately, or it may 1056 keep it open if it anticipates performing further operations on that 1057 connection in the future. If a client wishes to keep an idle 1058 connection open, it MUST respect the maximum idle time required by 1059 the server [SessSig]. 1061 If a client plans to terminate one or more subscriptions on a 1062 connection and doesn't intend to keep that connection open, then as 1063 an efficiency optimization it MAY instead choose to simply close the 1064 connection, which implicitly terminates all subscriptions on that 1065 connection. This may occur because the client computer is being shut 1066 down, is going to sleep, the application requiring the subscriptions 1067 has terminated, or simply because the last active subscription on 1068 that connection has been cancelled. 1070 When closing a connection, a client will generally do an abortive 1071 disconnect, sending a TCP RST. This immediately discards all 1072 remaining inbound and outbound data, which is appropriate if the 1073 client no longer has any interest in this data. In the BSD Sockets 1074 API, sending a TCP RST is achieved by setting the SO_LINGER option 1075 with a time of 0 seconds and then closing the socket. 1077 If a client has performed operations on this connection that it would 1078 not want lost (like DNS updates) then the client SHOULD do an orderly 1079 disconnect, sending a TCP FIN. In the BSD Sockets API, sending a TCP 1080 FIN is achieved by calling "shutdown(s,SHUT_WR)" and keeping the 1081 socket open until all remaining data has been read from it. 1083 7. Security Considerations 1085 TLS support is REQUIRED in DNS Push Notifications. There is no 1086 provision for opportunistic encryption using a mechanism like 1087 "STARTTLS". 1089 DNSSEC is RECOMMENDED for DNS Push Notifications. TLS alone does not 1090 provide complete security. TLS certificate verification can provide 1091 reasonable assurance that the client is really talking to the server 1092 associated with the desired host name, but since the desired host 1093 name is learned via a DNS SRV query, if the SRV query is subverted 1094 then the client may have a secure connection to a rogue server. 1095 DNSSEC can provided added confidence that the SRV query has not been 1096 subverted. 1098 7.1. Security Services 1100 It is the goal of using TLS to provide the following security 1101 services: 1103 Confidentiality: All application-layer communication is encrypted 1104 with the goal that no party should be able to decrypt it except 1105 the intended receiver. 1107 Data integrity protection: Any changes made to the communication in 1108 transit are detectable by the receiver. 1110 Authentication: An end-point of the TLS communication is 1111 authenticated as the intended entity to communicate with. 1113 Deployment recommendations on the appropriate key lengths and cypher 1114 suites are beyond the scope of this document. Please refer to TLS 1115 Recommendations [RFC7525] for the best current practices. Keep in 1116 mind that best practices only exist for a snapshot in time and 1117 recommendations will continue to change. Updated versions or errata 1118 may exist for these recommendations. 1120 7.2. TLS Name Authentication 1122 As described in Section 6.1, the client discovers the DNS Push 1123 Notification server using an SRV lookup for the record name 1124 "_dns-push-tls._tcp.". The server connection endpoint SHOULD 1125 then be authenticated using DANE TLSA records for the associated SRV 1126 record. This associates the target's name and port number with a 1127 trusted TLS certificate [RFC7673]. This procedure uses the TLS Sever 1128 Name Indication (SNI) extension [RFC6066] to inform the server of the 1129 name the client has authenticated through the use of TLSA records. 1130 Therefore, if the SRV record passes DNSSEC validation and a TLSA 1131 record matching the target name is useable, an SNI extension MUST be 1132 used for the target name to ensure the client is connecting to the 1133 server it has authenticated. If the target name does not have a 1134 usable TLSA record, then the use of the SNI extension is optional. 1136 7.3. TLS Compression 1138 In order to reduce the chances of compression-related attacks, TLS- 1139 level compression SHOULD be disabled when using TLS versions 1.2 and 1140 earlier. In the draft version of TLS 1.3 [I-D.ietf-tls-tls13], TLS- 1141 level compression has been removed completely. 1143 7.4. TLS Session Resumption 1145 TLS Session Resumption is permissible on DNS Push Notification 1146 servers. The server may keep TLS state with Session IDs [RFC5246] or 1147 operate in stateless mode by sending a Session Ticket [RFC5077] to 1148 the client for it to store. However, once the connection is closed, 1149 any existing subscriptions will be dropped. When the TLS session is 1150 resumed, the DNS Push Notification server will not have any 1151 subscription state and will proceed as with any other new connection. 1152 Use of TLS Session Resumption allows a new TLS connection to be set 1153 up more quickly, but the client will still have to recreate any 1154 desired subscriptions. 1156 8. IANA Considerations 1158 This document defines the service name: "_dns-push-tls._tcp". 1159 It is only applicable for the TCP protocol. 1160 This name is to be published in the IANA Service Name Registry 1161 [RFC6335][SN]. 1163 This document defines three DNS Session Signaling TLV types: 1164 SUBSCRIBE with (tentative) value 0x40 (64), PUSH with (tentative) 1165 value 0x41 (65), UNSUBSCRIBE with (tentative) value 0x42 (66), and 1166 RECONFIRM with (tentative) value 0x43 (67). 1168 9. Acknowledgements 1170 The authors would like to thank Kiren Sekar and Marc Krochmal for 1171 previous work completed in this field. 1173 This draft has been improved due to comments from Ran Atkinson, Tim 1174 Chown, Mark Delany, Ralph Droms, Bernie Volz, Jan Komissar, Manju 1175 Shankar Rao, Markus Stenberg, Dave Thaler, and Soraia Zlatkovic. 1177 10. References 1179 10.1. Normative References 1181 [I-D.ietf-tls-tls13] 1182 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1183 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 1184 October 2016. 1186 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1187 DOI 10.17487/RFC0768, August 1980, 1188 . 1190 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1191 RFC 793, DOI 10.17487/RFC0793, September 1981, 1192 . 1194 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1195 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1196 . 1198 [RFC1035] Mockapetris, P., "Domain names - implementation and 1199 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1200 November 1987, . 1202 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1203 Application and Support", STD 3, RFC 1123, 1204 DOI 10.17487/RFC1123, October 1989, 1205 . 1207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1208 Requirement Levels", BCP 14, RFC 2119, 1209 DOI 10.17487/RFC2119, March 1997, 1210 . 1212 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1213 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1214 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1215 . 1217 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1218 specifying the location of services (DNS SRV)", RFC 2782, 1219 DOI 10.17487/RFC2782, February 2000, 1220 . 1222 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1223 (TLS) Protocol Version 1.2", RFC 5246, 1224 DOI 10.17487/RFC5246, August 2008, 1225 . 1227 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1228 Extensions: Extension Definitions", RFC 6066, 1229 DOI 10.17487/RFC6066, January 2011, 1230 . 1232 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1233 Cheshire, "Internet Assigned Numbers Authority (IANA) 1234 Procedures for the Management of the Service Name and 1235 Transport Protocol Port Number Registry", BCP 165, 1236 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1237 . 1239 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1240 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1241 April 2013, . 1243 [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1244 Based Authentication of Named Entities (DANE) TLSA Records 1245 with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 1246 2015, . 1248 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1249 D. Wessels, "DNS Transport over TCP - Implementation 1250 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1251 . 1253 [SessSig] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1254 Mankin, A., and T. Pusateri, "DNS Session Signaling", 1255 draft-ietf-dnsop-session-signal-02 (work in progress), 1256 March 2017. 1258 [SN] "Service Name and Transport Protocol Port Number 1259 Registry", . 1262 10.2. Informative References 1264 [DisProx] Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service 1265 Discovery", draft-ietf-dnssd-hybrid-06 (work in progress), 1266 March 2017. 1268 [I-D.dukkipati-tcpm-tcp-loss-probe] 1269 Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 1270 "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of 1271 Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work 1272 in progress), February 2013. 1274 [I-D.sekar-dns-llq] 1275 Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- 1276 llq-01 (work in progress), August 2006. 1278 [IPJ.9-4-TCPSYN] 1279 Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The 1280 Internet Protocol Journal, Cisco Systems, Volume 9, 1281 Number 4, December 2006. 1283 [obs] "Observer Pattern", . 1286 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1287 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1288 August 1996, . 1290 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1291 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 1292 December 2005, . 1294 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 1295 RFC 4953, DOI 10.17487/RFC4953, July 2007, 1296 . 1298 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1299 "Transport Layer Security (TLS) Session Resumption without 1300 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1301 January 2008, . 1303 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 1304 "Understanding Apple's Back to My Mac (BTMM) Service", 1305 RFC 6281, DOI 10.17487/RFC6281, June 2011, 1306 . 1308 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1309 DOI 10.17487/RFC6762, February 2013, 1310 . 1312 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1313 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1314 . 1316 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1317 "TCP Extensions for Multipath Operation with Multiple 1318 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1319 . 1321 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1322 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1323 . 1325 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1326 "Recommendations for Secure Use of Transport Layer 1327 Security (TLS) and Datagram Transport Layer Security 1328 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1329 2015, . 1331 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1332 and P. Hoffman, "Specification for DNS over Transport 1333 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1334 2016, . 1336 [XEP0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1337 Subscribe", XSF XEP 0060, July 2010. 1339 Authors' Addresses 1341 Tom Pusateri 1342 Seeking affiliation 1343 Hilton Head Island, SC 1344 USA 1346 Phone: +1 843 473 7394 1347 Email: pusateri@bangj.com 1349 Stuart Cheshire 1350 Apple Inc. 1351 1 Infinite Loop 1352 Cupertino, CA 95014 1353 USA 1355 Phone: +1 408 974 3207 1356 Email: cheshire@apple.com