idnits 2.17.1 draft-ietf-dnssd-push-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2017) is 2498 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-20 ** 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 (-11) exists of draft-ietf-dprive-dtls-and-tls-profiles-10 == 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) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 2 errors (**), 0 flaws (~~), 6 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: December 19, 2017 Apple Inc. 6 June 17, 2017 8 DNS Push Notifications 9 draft-ietf-dnssd-push-11 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 December 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. State Considerations . . . . . . . . . . . . . . . . . . . . 7 61 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 62 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 63 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 11 64 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . 22 69 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 23 70 6.4.1. UNSUBSCRIBE Request . . . . . . . . . . . . . . . . . 24 71 6.4.2. UNSUBSCRIBE Response . . . . . . . . . . . . . . . . 26 72 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 28 73 6.5.1. RECONFIRM Request . . . . . . . . . . . . . . . . . . 29 74 6.5.2. RECONFIRM Response . . . . . . . . . . . . . . . . . 31 75 6.6. Client-Initiated Termination . . . . . . . . . . . . . . 33 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 77 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 34 78 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 34 79 7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 35 80 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 35 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 85 10.2. Informative References . . . . . . . . . . . . . . . . . 38 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 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. 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 [RFC7719]. 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. If a query is 188 received with the RD bit set, matching records for names falling 189 within the server's zones should be returned with the RA (Recursion 190 Available) bit clear. If the query is for a name not in the server's 191 zone, an error with RCODE NOTAUTH (Not Authoritative) should be 192 returned. 194 DNS Push Notification clients are NOT required to implement DNS 195 Update Prerequisite processing. Prerequisites are used to perform 196 tentative atomic test-and-set type operations when a client updates 197 records on a server, and that concept has no applicability when it 198 comes to an authoritative server informing a client of changes to DNS 199 records. 201 This DNS Push Notification specification includes support for DNS 202 classes, for completeness. However, in practice, it is anticipated 203 that for the foreseeable future the only DNS class in use will be DNS 204 class "IN", as is the reality today with existing DNS servers and 205 clients. A DNS Push Notification server MAY choose to implement only 206 DNS class "IN". If messages are received for a class other than 207 "IN", and that class is not supported, an error with RCODE NOTIMPL 208 (Not Implemented) should be returned. 210 DNS Push Notifications impose less load on the responding server than 211 rapid polling would, but Push Notifications do still have a cost, so 212 DNS Push Notification clients must not recklessly create an excessive 213 number of Push Notification subscriptions. A subscription should 214 only be active when there is a valid reason to need live data (for 215 example, an on-screen display is currently showing the results to the 216 user) and the subscription SHOULD be cancelled as soon as the need 217 for that data ends (for example, when the user dismisses that 218 display). Implementations MAY want to implement idle timeouts, so 219 that if the user ceases interacting with the device, the display 220 showing the result of the DNS Push Notification subscription is 221 automatically dismissed after a certain period of inactivity. For 222 example, if a user presses the "Print" button on their smartphone, 223 and then leaves the phone showing the printer discovery screen until 224 the phone goes to sleep, then the printer discovery screen should be 225 automatically dismissed as the device goes to sleep. If the user 226 does still intend to print, this will require them to press the 227 "Print" button again when they wake their phone up. 229 A DNS Push Notification client must not routinely keep a DNS Push 230 Notification subscription active 24 hours a day, 7 days a week, just 231 to keep a list in memory up to date so that if the user does choose 232 to bring up an on-screen display of that data, it can be displayed 233 really fast. DNS Push Notifications are designed to be fast enough 234 that there is no need to pre-load a "warm" list in memory just in 235 case it might be needed later. 237 Generally, as described in the DNS Session Signaling specification 238 [SessSig], a client must not keep a connection to a server open 239 indefinitely if it has no subscriptions (or other operations) active 240 on that connection. A client MAY close a connection as soon as it 241 becomes idle, and then if needed in the future, open a new connection 242 when required. Alternatively, a client MAY speculatively keep an 243 idle connection open for some time, subject to the constraint that it 244 MUST NOT keep a connection open that has been idle for more than the 245 session's idle timeout (15 seconds by default). 247 4. Transport 249 Implementations of DNS Update [RFC2136] MAY use either User Datagram 250 Protocol (UDP) [RFC0768] or Transmission Control Protocol (TCP) 251 [RFC0793] as the transport protocol, in keeping with the historical 252 precedent that DNS queries must first be sent over UDP [RFC1123]. 253 This requirement to use UDP has subsequently been relaxed [RFC7766]. 255 In keeping with the more recent precedent, DNS Push Notification is 256 defined only for TCP. DNS Push Notification clients MUST use TLS 257 over TCP, see RFC 7858 [RFC7858]. 259 Connection setup over TCP ensures return reachability and alleviates 260 concerns of state overload at the server through anonymous 261 subscriptions. All subscribers are guaranteed to be reachable by the 262 server by virtue of the TCP three-way handshake. Flooding attacks 263 are possible with any protocol, and a benefit of TCP is that there 264 are already established industry best practices to guard against SYN 265 flooding and similar attacks [IPJ.9-4-TCPSYN] [RFC4953]. 267 Use of TCP also allows DNS Push Notifications to take advantage of 268 current and future developments in TCP, such as Multipath TCP (MPTCP) 269 [RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP) 270 [I-D.dukkipati-tcpm-tcp-loss-probe], and so on. 272 Transport Layer Security (TLS) [RFC5246] is well understood and 273 deployed across many protocols running over TCP. It is designed to 274 prevent eavesdropping, tampering, or message forgery. TLS is 275 REQUIRED for every connection between a client subscriber and server 276 in this protocol specification. Additional security measures such as 277 client authentication during TLS negotiation MAY also be employed to 278 increase the trust relationship between client and server. 280 5. State Considerations 282 Each DNS Push Notification server is capable of handling some finite 283 number of Push Notification subscriptions. This number will vary 284 from server to server and is based on physical machine 285 characteristics, network bandwidth, and operating system resource 286 allocation. After a client establishes a connection to a DNS server, 287 each subscription is individually accepted or rejected. Servers may 288 employ various techniques to limit subscriptions to a manageable 289 level. Correspondingly, the client is free to establish simultaneous 290 connections to alternate DNS servers that support DNS Push 291 Notifications for the zone and distribute subscriptions at its 292 discretion. In this way, both clients and servers can react to 293 resource constraints. Token bucket rate limiting schemes are also 294 effective in providing fairness by a server across numerous client 295 requests. 297 6. Protocol Operation 299 The DNS Push Notification protocol is a session-oriented protocol, 300 and makes use of DNS Session Signaling [SessSig]. 302 For details of the DNS Session Signaling message format refer to the 303 DNS Session Signaling specification [SessSig]. Those details are not 304 repeated here. 306 DNS Push Notification clients and servers MUST support DNS Session 307 Signaling, but the server SHOULD NOT issue any DNS Session Signaling 308 operations until after the client has first initiated a DNS Session 309 Signaling operation of its own. A single server can support DNS 310 Queries, DNS Updates, and DNS Push Notifications (using DNS Session 311 Signaling) on the same TCP port, and until the client has sent at 312 least one DNS Session Signaling operation the server does not know 313 what kind of client has connected to it. Once the client has 314 indicated willingness to use DNS Session Signaling operations by 315 sending one of its own, either side of the connection may then 316 initiate further Session Signaling operations at any time. 318 A DNS Push Notification exchange begins with the client discovering 319 the appropriate server, using the procedure described in Section 6.1, 320 and then making a TLS/TCP connection to it. 322 A typical DNS Push Notification client will immediately issue a DNS 323 Session Signaling Keepalive operation to request a session timeout or 324 keepalive interval longer than the the 15-second defaults, but this 325 is not required. A DNS Push Notification client MAY issue other 326 requests on the connection first, and only issue a DNS Session 327 Signaling Keepalive operation later if it determines that to be 328 necessary. 330 Once the connection is made, the client may then add and remove Push 331 Notification subscriptions. In accordance with the current set of 332 active subscriptions the server sends relevant asynchronous Push 333 Notifications to the client. Note that a client MUST be prepared to 334 receive (and silently ignore) Push Notifications for subscriptions it 335 has previously removed, since there is no way to prevent the 336 situation where a Push Notification is in flight from server to 337 client while the client's UNSUBSCRIBE message cancelling that 338 subscription is simultaneously in flight from client to server. 340 The exchange between client and server terminates when either end 341 closes the TCP connection with a TCP FIN or RST. 343 6.1. Discovery 345 The first step in DNS Push Notification subscription is to discover 346 an appropriate DNS server that supports DNS Push Notifications for 347 the desired zone. The client MUST also determine which TCP port on 348 the server is listening for connections, which need not be (and often 349 is not) the typical TCP port 53 used for conventional DNS, or TCP 350 port 853 used for DNS over TLS [RFC7858]. 352 1. The client begins the discovery by sending a DNS query to its 353 local resolver, with record type SOA [RFC1035] for the record to 354 which it wishes to subscribe. As an example, if it wishes to 355 subscribe to PTR records with the name 356 _printers._tcp.foo.example.com, it sends an SOA query for 357 _printers._tcp.foo.example.com. The goal is to determine the 358 authoritative server for foo.example.com. 360 2. If the SOA record exists as exactly specified in the query, it is 361 expected to be returned in the Answer section with a NOERROR 362 response code. If the exact SOA record does not exist, the 363 client may get back a NOERROR/NODATA response or it may get back 364 a NXDOMAIN/Name Error response. This depends on the resolver 365 implementation and whether the domain exists. The client is 366 looking for an SOA record to be returned in either the Answer 367 section or the Authority section with a NOERROR response code. 368 If the client receives an NXDOMAIN/Name Error response code, it 369 should strip the leading label from the query name and if the 370 resulting name has at least one label in it, the client should 371 send a new SOA query, repeating this until a NOERROR response 372 code is received or the query name is empty. In the case of an 373 empty name, the client may retry the operation at a later time, 374 of the client's choosing, such after a change in network 375 attachment. 377 3. In the example above, if an SOA record query is sent for 378 _printers._tcp.foo.example.com and an NXDOMAIN/Name Error is 379 returned with an SOA record in the Authority section for 380 foo.example.com, the client should strip the leading label and 381 query an SOA record for _tcp.foo.example.com. If a NOERROR/ 382 NODATA response is received with an SOA record in the Authority 383 section for foo.example.com, this is sufficent. If an NXDOMAIN/ 384 Name Error response is received, the client should again strip 385 the leading label and query an SOA record for foo.example.com. 386 If the foo.example.com domain exists, this should result in a 387 NOERROR response with the SOA record in the Answer section. If 388 the domain foo.example.com does not exist, the response will 389 likely be an NXDOMAIN/Name Error with an SOA record for 390 example.com in the Authority section. This means the subdomain 391 foo.example.com has not been properly delegated by example.com. 393 4. If a NOERROR/NODATA response is received but contains no SOA in 394 the Authority section, the client could try stripping the leading 395 label and issuing another SOA query. Additional information 396 about negative responses can be found in Section 2 of [RFC2308]. 398 5. Once the SOA is known (either by virtue of being seen in the 399 Answer Section, or in the Authority Section), the client sends a 400 DNS query with type SRV [RFC2782] for the record name 401 "_dns-push-tls._tcp.", where is the owner name of 402 the discovered SOA record. 404 6. For implementors of this specification, an authoritative answer 405 for that SRV record, and only such an answer, will determine 406 whether the zone supports DNS Push Notifications. 408 7. If the SRV record does exist, the SRV "target" contains the name 409 of the server providing DNS Push Notifications for the zone. The 410 port number on which to contact the server is in the SRV record 411 "port" field. The address(es) of the target host MAY be included 412 in the Additional Section, however, the address records SHOULD be 413 authenticated before use as described below in Section 7.2 and 414 [RFC7673]. 416 8. More than one SRV record may be returned. In this case, the 417 "priority" and "weight" values in the returned SRV records are 418 used to determine the order in which to contact the servers for 419 subscription requests. As described in the SRV specification 420 [RFC2782], the server with the lowest "priority" is first 421 contacted. If more than one server has the same "priority", the 422 "weight" indicates the weighted probability that the client 423 should contact that server. Higher weights have higher 424 probabilities of being selected. If a server is not reachable or 425 is not willing to accept a subscription request, then a 426 subsequent server is to be contacted. 428 Each time a client makes a new DNS Push Notification subscription 429 connection, it SHOULD repeat the discovery process in order to 430 determine the preferred DNS server for subscriptions at that time. 431 However, the client device MUST respect the DNS TTL values on records 432 it receives, and store them in its local cache with this lifetime. 433 This means that, as long as the DNS TTL values on the authoritative 434 records were set to reasonable values, repeated application of this 435 discovery process can be completed nearly instantaneously by the 436 client, using only locally-stored cached data. 438 6.2. DNS Push Notification SUBSCRIBE 440 After connecting, and requesting a longer idle timeout and/or 441 keepalive interval if necessary, a DNS Push Notification client then 442 indicates its desire to receive DNS Push Notifications for a given 443 domain name by sending a SUBSCRIBE request over the established TLS 444 connection to the server. A SUBSCRIBE request is encoded in a DNS 445 Session Signaling [SessSig] message. This specification defines a 446 DNS Session Signaling TLV for DNS Push Notification SUBSCRIBE 447 Requests/Responses (tentatively Session Signaling Type Code 0x40). 449 The entity that initiates a SUBSCRIBE request is by definition the 450 client. A server should not send a SUBSCRIBE request over an 451 existing connection from a client. If a server does send a SUBSCRIBE 452 request over the connection initiated by a client, it is an error and 453 the client should acknowledge the request with the error response 454 RCODE NOTAUTH (Not Authoritative). 456 6.2.1. SUBSCRIBE Request 458 A SUBSCRIBE request message begins with the standard DNS Session 459 Signaling 12-byte header [SessSig], followed by the SUBSCRIBE TLV. A 460 SUBSCRIBE request message is illustrated below: 462 1 1 1 1 1 1 463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 464 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 465 | MESSAGE ID | 466 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 467 |QR| Opcode | Z | RCODE | 468 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 469 | QDCOUNT (MUST BE ZERO) | 470 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 471 | ANCOUNT (MUST BE ZERO) | 472 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 473 | NSCOUNT (MUST BE ZERO) | 474 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 475 | ARCOUNT (MUST BE ZERO) | 476 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 477 | SSOP-TYPE = SUBSCRIBE (tentatively 0x40) | 478 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 479 | SSOP-LENGTH (number of octets in SSOP-DATA) | 480 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 481 | | \ 482 \ NAME \ | 483 \ \ | 484 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > SSOP-DATA 485 | TYPE | | 486 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 487 | CLASS | / 488 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 490 Figure 1 492 The MESSAGE ID field MUST be set to a unique value, that the client 493 is not using for any other active operation on this connection. For 494 the purposes here, a MESSAGE ID is in use on this connection if the 495 client has used it in a request for which it has not yet received a 496 response, or if the client has used it for a subscription which it 497 has not yet cancelled using UNSUBSCRIBE. In the SUBSCRIBE response 498 the server MUST echo back the MESSAGE ID value unchanged. 500 The other header fields MUST be set as described in the DNS Session 501 Signaling specification [SessSig]. The DNS Opcode is the Session 502 Signaling Opcode (tentatively 6). The four count fields MUST be 503 empty, and the corresponding four sections MUST be empty (i.e., 504 absent). 506 The SSOP-TYPE is SUBSCRIBE (tentatively 0x40). The SSOP-LENGTH is 507 the length of the SSOP-DATA that follows, which specifies the name, 508 type, and class of the record(s) being sought. 510 The SSOP-DATA for a SUBSCRIBE request MUST contain exactly one 511 question. The SSOP-DATA for a SUBSCRIBE request has no QDCOUNT field 512 to specify more than one question. Since SUBSCRIBE requests are sent 513 over TCP, multiple SUBSCRIBE request messages can be concatenated in 514 a single TCP stream and packed efficiently into TCP segments. 516 If accepted, the subscription will stay in effect until the client 517 cancels the subscription using UNSUBSCRIBE or until the connection 518 between the client and the server is closed. 520 SUBSCRIBE requests on a given connection MUST be unique. A client 521 MUST NOT send a SUBSCRIBE message that duplicates the NAME, TYPE and 522 CLASS of an existing active subscription on that TLS/TCP connection. 523 For the purpose of this matching, the established DNS case- 524 insensitivity for US-ASCII letters applies (e.g., "foo.com" and 525 "Foo.com" are the same). If a server receives such a duplicate 526 SUBSCRIBE message this is an error and the server MUST immediately 527 terminate the connection with a TCP RST (or equivalent for other 528 protocols). 530 DNS wildcarding is not supported. That is, a wildcard ("*") in a 531 SUBSCRIBE message matches only a literal wildcard character ("*") in 532 the zone, and nothing else. 534 Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message 535 matches only a literal CNAME record in the zone, and nothing else. 537 A client may SUBSCRIBE to records that are unknown to the server at 538 the time of the request (providing that the name falls within one of 539 the zone(s) the server is responsible for) and this is not an error. 540 The server MUST accept these requests and send Push Notifications if 541 and when matching records are found in the future. 543 If neither TYPE nor CLASS are ANY (255) then this is a specific 544 subscription to changes for the given NAME, TYPE and CLASS. If one 545 or both of TYPE or CLASS are ANY (255) then this subscription matches 546 any type and/or any class, as appropriate. 548 NOTE: A little-known quirk of DNS is that in DNS QUERY requests, 549 QTYPE and QCLASS 255 mean "ANY" not "ALL". They indicate that the 550 server should respond with ANY matching records of its choosing, not 551 necessarily ALL matching records. This can lead to some surprising 552 and unexpected results, where a query returns some valid answers but 553 not all of them, and makes QTYPE=ANY queries less useful than people 554 sometimes imagine. 556 When used in conjunction with SUBSCRIBE, TYPE and CLASS 255 should be 557 interpreted to mean "ALL", not "ANY". After accepting a subscription 558 where one or both of TYPE or CLASS are 255, the server MUST send Push 559 Notification Updates for ALL record changes that match the 560 subscription, not just some of them. 562 6.2.2. SUBSCRIBE Response 564 Each SUBSCRIBE request generates exactly one SUBSCRIBE response from 565 the server. 567 A SUBSCRIBE response message begins with the standard DNS Session 568 Signaling 12-byte header [SessSig], possibly followed by one or more 569 optional Modifier TLVs, such as a Retry Delay Modifier TLV. 571 The MESSAGE ID field MUST echo the value given in the ID field of the 572 SUBSCRIBE request. This is how the client knows which request is 573 being responded to. 575 A SUBSCRIBE response message MUST NOT contain a Session Signaling 576 Operation TLV. The Session Signaling Operation TLV is NOT copied 577 from the SUBSCRIBE request. 579 In the SUBSCRIBE response the RCODE indicates whether or not the 580 subscription was accepted. Supported RCODEs are as follows: 582 +------------+-------+----------------------------------------------+ 583 | Mnemonic | Value | Description | 584 +------------+-------+----------------------------------------------+ 585 | NOERROR | 0 | SUBSCRIBE successful. | 586 | FORMERR | 1 | Server failed to process request due to a | 587 | | | malformed request. | 588 | SERVFAIL | 2 | Server failed to process request due to a | 589 | | | problem with the server. | 590 | NXDOMAIN | 3 | NOT APPLICABLE. DNS Push Notification | 591 | | | servers MUST NOT return NXDOMAIN errors in | 592 | | | response to SUBSCRIBE requests. | 593 | NOTIMP | 4 | Server does not recognize DNS Session | 594 | | | Signaling Opcode. | 595 | REFUSED | 5 | Server refuses to process request for policy | 596 | | | or security reasons. | 597 | NOTAUTH | 9 | Server is not authoritative for the | 598 | | | requested name. | 599 | SSOPNOTIMP | 11 | SUBSCRIBE operation not supported. | 600 +------------+-------+----------------------------------------------+ 602 SUBSCRIBE Response codes 604 This document specifies only these RCODE values for SUBSCRIBE 605 Responses. Servers sending SUBSCRIBE Responses SHOULD use one of 606 these values. However, future circumstances may create situations 607 where other RCODE values are appropriate in SUBSCRIBE Responses, so 608 clients MUST be prepared to accept SUBSCRIBE Responses with any RCODE 609 value. 611 If the server sends a nonzero RCODE in the SUBSCRIBE response, either 612 the client is (at least partially) misconfigured, the server 613 resources are exhausted, or there is some other unknown failure on 614 the server. In any case, the client shouldn't retry the subscription 615 right away. Either end can terminate the connection, but the client 616 may want to try this subscription again or it may have other 617 successful subscriptions that it doesn't want to abandon. If the 618 server sends a nonzero RCODE then it SHOULD append a Retry Delay 619 Modifier TLV [SessSig] to the response specifying a delay before the 620 client attempts this operation again. Recommended values for the 621 delay for different RCODE values are given below: 623 For RCODE = 1 (FORMERR) the delay may be any value selected by the 624 implementer. A value of five minutes is RECOMMENDED, to reduce 625 the risk of high load from defective clients. 627 For RCODE = 2 (SERVFAIL) the delay should be chosen according to 628 the level of server overload and the anticipated duration of that 629 overload. By default, a value of one minute is RECOMMENDED. If a 630 more serious server failure occurs, the delay may be longer in 631 accordance with the specific problem encountered. 633 For RCODE = 4 (NOTIMP), which occurs on a server that doesn't 634 implement DNS Session Signaling [SessSig], it is unlikely that the 635 server will begin supporting DNS Session Signaling in the next few 636 minutes, so the retry delay SHOULD be one hour. 638 For RCODE = 5 (REFUSED), which occurs on a server that implements 639 DNS Push Notifications, but is currently configured to disallow 640 DNS Push Notifications, the retry delay may be any value selected 641 by the implementer and/or configured by the operator. 642 This is a misconfiguration, since this server is listed in a 643 "_dns-push-tls._tcp." SRV record, but the server itself is 644 not currently configured to support DNS Push Notifications. Since 645 it is possible that the misconfiguration may be repaired at any 646 time, the retry delay should not be set too high. By default, a 647 value of 5 minutes is RECOMMENDED. 649 For RCODE = 9 (NOTAUTH), which occurs on a server that implements 650 DNS Push Notifications, but is not configured to be authoritative 651 for the requested name, the retry delay may be any value selected 652 by the implementer and/or configured by the operator. 653 This is a misconfiguration, since this server is listed in a 654 "_dns-push-tls._tcp." SRV record, but the server itself is 655 not currently configured to support DNS Push Notifications for 656 that zone. Since it is possible that the misconfiguration may be 657 repaired at any time, the retry delay should not be set too high. 658 By default, a value of 5 minutes is RECOMMENDED. 660 For RCODE = 11 (DNS Push SUBSCRIBE operation not supported), which 661 occurs on a server that doesn't implement DNS Push Notifications, 662 it is unlikely that the server will begin supporting DNS Push 663 Notifications in the next few minutes, so the retry delay SHOULD 664 be one hour. 666 For other RCODE values, the retry delay should be set by the 667 server as appropriate for that error condition. By default, a 668 value of 5 minutes is RECOMMENDED. 670 For RCODE = 9 (NOTAUTH), the time delay applies to requests for other 671 names falling within the same zone. Requests for names falling 672 within other zones are not subject to the delay. For all other 673 RCODEs the time delay applies to all subsequent requests to this 674 server. 676 After sending an error response the server MAY allow the connection 677 to remain open, or MAY send a DNS Push Notification Retry Delay 678 Operation TLV asserting the client close the TCP connection, as 679 described in the DNS Session Signaling specification [SessSig]. 680 Clients MUST correctly handle both cases. 682 6.3. DNS Push Notification Updates 684 Once a subscription has been successfully established, the server 685 generates PUSH messages to send to the client as appropriate. In the 686 case that the answer set was non-empty at the moment the subscription 687 was established, an initial PUSH message will be sent immediately 688 following the SUBSCRIBE Response. Subsequent changes to the answer 689 set are then communicated to the client in subsequent PUSH messages. 691 6.3.1. PUSH Message 693 A PUSH message begins with the standard DNS Session Signaling 12-byte 694 header [SessSig], followed by the PUSH TLV. A PUSH message is 695 illustrated below: 697 1 1 1 1 1 1 698 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 699 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 700 | MESSAGE ID | 701 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 702 |QR| Opcode | Z | RCODE | 703 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 704 | QDCOUNT (MUST BE ZERO) | 705 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 706 | ANCOUNT (MUST BE ZERO) | 707 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 708 | NSCOUNT (MUST BE ZERO) | 709 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 710 | ARCOUNT (MUST BE ZERO) | 711 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 712 | SSOP-TYPE = PUSH (tentatively 0x42) | 713 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 714 | SSOP-LENGTH (number of octets in SSOP-DATA) | 715 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 716 \ NAME \ \ 717 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 718 | TYPE | | 719 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 720 | CLASS | | 721 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 722 | RDLEN | | 723 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 724 \ RDATA \ | 725 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > SSOP-DATA 726 \ NAME \ | 727 +--+--+--+--+--+--+- | | 728 | TYPE Repeated | | 729 +--+--+--+--+--+--+- | | 730 | CLASS As | | 731 +--+--+--+--+--+--+- | | 732 | RDLEN Necessary | | 733 +--+--+--+--+--+--+- | | 734 \ RDATA \ / 735 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 737 Figure 2 739 The MESSAGE ID field MUST be set to a unique value, that the server 740 is not currently using for any other active outgoing request that it 741 has sent on this connection. The MESSAGE ID in the outgoing PUSH 742 message is selected by the server and has no relationship to the 743 MESSAGE ID in any of the client subscriptions it may relate to. In 744 the PUSH response the client MUST echo back the MESSAGE ID value 745 unchanged. 747 The other header fields MUST be set as described in the DNS Session 748 Signaling specification [SessSig]. The DNS Opcode is the Session 749 Signaling Opcode (tentatively 6). The four count fields MUST be 750 empty, and the corresponding four sections MUST be empty (i.e., 751 absent). 753 The SSOP-TYPE is PUSH (tentatively 0x41). The SSOP-LENGTH is the 754 length of the SSOP-DATA that follows, which specifies the changes 755 being communicated. 757 The SSOP-DATA contains one or more Update records. A PUSH Message 758 MUST contain at least one Update record. If a PUSH Message is 759 received that contains no Update records, this is a fatal error, and 760 the receiver MUST immediately terminate the connection with a TCP RST 761 (or equivalent for other protocols). The Update records are 762 formatted in the customary way for Resource Records in DNS messages 763 with the stipulation that DNS name compression is not permitted in 764 DNS Session Signaling TLVs. Update records in a PUSH Message are 765 interpreted according to the same rules as for DNS Update [RFC2136] 766 messages, namely: 768 Delete all RRsets from a name: 769 TTL=0, CLASS=ANY, RDLENGTH=0, TYPE=ANY. 771 Delete an RRset from a name: 772 TTL=0, CLASS=ANY, RDLENGTH=0; 773 TYPE specifies the RRset being deleted. 775 Delete an individual RR from a name: 776 TTL=0, CLASS=NONE; 777 TYPE, RDLENGTH and RDATA specifies the RR being deleted. 779 Add to an RRset: 780 TTL, CLASS, TYPE, RDLENGTH and RDATA specifies the RR being added. 782 When processing the records received in a PUSH Message, the receiving 783 client MUST validate that the records being added or deleted 784 correspond with at least one currently active subscription on that 785 connection. Specifically, the record name MUST match the name given 786 in the SUBSCRIBE request, subject to the usual established DNS case- 787 insensitivity for US-ASCII letters. If the TYPE in the SUBSCRIBE 788 request was not ANY (255) then the TYPE of the record must match the 789 TYPE given in the SUBSCRIBE request. If the CLASS in the SUBSCRIBE 790 request was not ANY (255) then the CLASS of the record must match the 791 CLASS given in the SUBSCRIBE request. If a matching active 792 subscription on that connection is not found, then that individual 793 record addition/deletion is silently ignored. Processing of other 794 additions and deletions in this message is not affected. The TCP 795 connection is not closed. This is to allow for the unavoidable race 796 condition where a client sends an outbound UNSUBSCRIBE while inbound 797 PUSH messages for that subscription from the server are still in 798 flight. 800 In the case where a single change affects more than one active 801 subscription, only one PUSH message is sent. For example, a PUSH 802 message adding a given record may match both a SUBSCRIBE request with 803 the same TYPE and a different SUBSCRIBE request with TYPE=ANY. It is 804 not the case that two PUSH messages are sent because the new record 805 matches two active subscriptions. 807 The server SHOULD encode change notifications in the most efficient 808 manner possible. For example, when three AAAA records are deleted 809 from a given name, and no other AAAA records exist for that name, the 810 server SHOULD send a "delete an RRset from a name" PUSH message, not 811 three separate "delete an individual RR from a name" PUSH messages. 812 Similarly, when both an SRV and a TXT record are deleted from a given 813 name, and no other records of any kind exist for that name, the 814 server SHOULD send a "delete all RRsets from a name" PUSH message, 815 not two separate "delete an RRset from a name" PUSH messages. 817 A server SHOULD combine multiple change notifications in a single 818 PUSH message when possible, even if those change notifications apply 819 to different subscriptions. Conceptually, a PUSH message is a 820 connection-level mechanism, not a subscription-level mechanism. 822 Reception of a PUSH message by a client generates a PUSH response 823 back to the server. 825 The TTL of an added record is stored by the client and decremented as 826 time passes, with the caveat that for as long as a relevant 827 subscription is active, the TTL does not decrement below 1 second. 828 For as long as a relevant subscription remains active, the client 829 SHOULD assume that when a record goes away the server will notify it 830 of that fact. Consequently, a client does not have to poll to verify 831 that the record is still there. Once a subscription is cancelled 832 (individually, or as a result of the TCP connection being closed) 833 record aging resumes and records are removed from the local cache 834 when their TTL reaches zero. 836 6.3.2. PUSH Response 838 Each PUSH message generates exactly one PUSH response from the 839 receiver. 841 A PUSH response message begins with the standard DNS Session 842 Signaling 12-byte header [SessSig], possibly followed by one or more 843 optional Modifier TLVs, such as a Retry Delay Modifier TLV. 845 The MESSAGE ID field MUST echo the value given in the ID field of the 846 PUSH message. 848 A PUSH response message MUST NOT contain a Session Signaling 849 Operation TLV. The Session Signaling Operation TLV is NOT copied 850 from the PUSH message. 852 In a PUSH response the RCODE MUST be zero. Receiving a PUSH response 853 with a nonzero RCODE is a fatal error, and the receiver MUST 854 immediately terminate the connection with a TCP RST (or equivalent 855 for other protocols). 857 6.4. DNS Push Notification UNSUBSCRIBE 859 To cancel an individual subscription without closing the entire 860 connection, the client sends an UNSUBSCRIBE message over the 861 established TCP connection to the server. The UNSUBSCRIBE message is 862 encoded in a DNS Session Signaling [SessSig] message. This 863 specification defines a DNS Session Signaling TLV for DNS Push 864 Notification UNSUBSCRIBE Requests/Responses (tentatively Session 865 Signaling Type Code 0x42). 867 A server MUST NOT initiate an UNSUBSCRIBE request. If a server does 868 send a UNSUBSCRIBE request over the connection initiated by a client, 869 it is an error and the client should acknowledge the request with the 870 error response RCODE NOTAUTH (Not Authoritative). 872 6.4.1. UNSUBSCRIBE Request 874 An UNSUBSCRIBE request message begins with the standard DNS Session 875 Signaling 12-byte header [SessSig], followed by the UNSUBSCRIBE TLV. 877 1 1 1 1 1 1 878 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 879 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 880 | MESSAGE ID | 881 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 882 |QR| Opcode | Z | RCODE | 883 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 884 | QDCOUNT (MUST BE ZERO) | 885 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 886 | ANCOUNT (MUST BE ZERO) | 887 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 888 | NSCOUNT (MUST BE ZERO) | 889 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 890 | ARCOUNT (MUST BE ZERO) | 891 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 892 | SSOP-TYPE = UNSUBSCRIBE (tentatively 0x42) | 893 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 894 | SSOP-LENGTH (2 octets) | 895 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 896 | SUBSCRIBE MESSAGE ID | SSOP-DATA 897 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 899 Figure 3 901 In the UNSUBSCRIBE TLV the SSOP-TYPE is UNSUBSCRIBE (tentatively 902 0x42). The SSOP-LENGTH is 2 octets. 904 The SSOP-DATA contains the MESSAGE ID field of the value given in the 905 ID field of an active SUBSCRIBE request. This is how the server 906 knows which SUBSCRIBE request is being cancelled. After receipt of 907 the UNSUBSCRIBE request, the SUBSCRIBE request is no longer active. 908 If a server receives an UNSUBSCRIBE message where the MESSAGE ID does 909 not match the ID of an active SUBSCRIBE request the server MUST 910 return a response containing RCODE = 3 (NXDOMAIN). 912 It is allowable for the client to issue an UNSUBSCRIBE request for a 913 previous SUBSCRIBE request for which the client has not yet received 914 a SUBSCRIBE response. This is to allow for the case where a client 915 starts and stops a subscription in less than the round-trip time to 916 the server. The client is NOT required to wait for the SUBSCRIBE 917 response before issuing the UNSUBSCRIBE request. A consequence of 918 this is that if the client issues an UNSUBSCRIBE request for an as- 919 yet unacknowledged SUBSCRIBE request, and the SUBSCRIBE request is 920 subsequently unsuccessful for some reason, then when the UNSUBSCRIBE 921 request is eventually processed it will be an UNSUBSCRIBE request for 922 a nonexistent subscription, which will result NXDOMAIN response. 924 6.4.2. UNSUBSCRIBE Response 926 Each UNSUBSCRIBE request generates exactly one UNSUBSCRIBE response 927 from the server. 929 An UNSUBSCRIBE response message begins with the standard DNS Session 930 Signaling 12-byte header [SessSig], possibly followed by one or more 931 optional Modifier TLVs, such as a Retry Delay Modifier TLV. 933 The MESSAGE ID field MUST echo the value given in the ID field of the 934 UNSUBSCRIBE request. This is how the client knows which request is 935 being responded to. 937 An UNSUBSCRIBE response message MUST NOT contain a Session Signaling 938 Operation TLV. The Session Signaling Operation TLV is NOT copied 939 from the UNSUBSCRIBE request. 941 In the UNSUBSCRIBE response the RCODE indicates whether or not the 942 unsubscribe request was successful. Supported RCODEs are as follows: 944 +------------+-------+----------------------------------------------+ 945 | Mnemonic | Value | Description | 946 +------------+-------+----------------------------------------------+ 947 | NOERROR | 0 | UNSUBSCRIBE successful. | 948 | FORMERR | 1 | Server failed to process request due to a | 949 | | | malformed request. | 950 | NXDOMAIN | 3 | Specified subscription does not exist. | 951 | NOTIMP | 4 | Server does not recognize DNS Session | 952 | | | Signaling Opcode. | 953 | SSOPNOTIMP | 11 | UNSUBSCRIBE operation not supported. | 954 +------------+-------+----------------------------------------------+ 956 UNSUBSCRIBE Response codes 958 This document specifies only these RCODE values for UNSUBSCRIBE 959 Responses. Servers sending UNSUBSCRIBE Responses SHOULD use one of 960 these values. However, future circumstances may create situations 961 where other RCODE values are appropriate in UNSUBSCRIBE Responses, so 962 clients MUST be prepared to accept UNSUBSCRIBE Responses with any 963 RCODE value. 965 Having being successfully revoked with a correctly-formatted 966 UNSUBSCRIBE message (resulting in a response with RCODE NOERROR) the 967 previously referenced subscription is no longer active and the server 968 MAY discard the state associated with it immediately, or later, at 969 the server's discretion. 971 Nonzero RCODE values signal some kind of error. 973 RCODE value FORMERR indicates a message format error. 975 RCODE value NXDOMAIN indicates a MESSAGE ID that does not correspond 976 to any active subscription. 978 RCODE values NOTIMP and SSOPNOTIMP should not occur in practice. 980 A server would only generate NOTIMP if it did not support Session 981 Signaling, and if the server does not support Session Signaling then 982 it should not be possible for a client to have an active subscription 983 to cancel. 985 Similarly, a server would only generate SSOPNOTIMP if it did not 986 support Push Notifications, and if the server does not support Push 987 Notifications then it should not be possible for a client to have an 988 active subscription to cancel. 990 Nonzero RCODE values other than NXDOMAIN indicate a serious problem 991 with the client. After sending an error response other than 992 NXDOMAIN, the server SHOULD send a DNS Session Signaling Retry Delay 993 Operation TLV and then close the TCP connection, as described in the 994 DNS Session Signaling specification [SessSig]. 996 6.5. DNS Push Notification RECONFIRM 998 Sometimes, particularly when used with a Discovery Proxy [DisProx], a 999 DNS Zone may contain stale data. When a client encounters data that 1000 it believe may be stale (e.g., an SRV record referencing a target 1001 host+port that is not responding to connection requests) the client 1002 can send a RECONFIRM request to ask the server to re-verify that the 1003 data is still valid. For a Discovery Proxy, this causes it to issue 1004 new Multicast DNS requests to ascertain whether the target device is 1005 still present. For other types of DNS server, the RECONFIRM 1006 operation is currently undefined, and SHOULD result in a NOERROR 1007 response, but otherwise need not cause any action to occur. Frequent 1008 RECONFIRM operations may be a sign of network unreliability, or some 1009 kind of misconfiguration, so RECONFIRM operations MAY be logged or 1010 otherwise communicated to a human administrator to assist in 1011 detecting, and remedying, such network problems. 1013 If, after receiving a valid RECONFIRM request, the server determines 1014 that the disputed records are in fact no longer valid, then 1015 subsequent DNS PUSH Messages will be generated to inform interested 1016 clients. Thus, one client discovering that a previously-advertised 1017 device (like a network printer) is no longer present has the side 1018 effect of informing all other interested clients that the device in 1019 question is now gone. 1021 6.5.1. RECONFIRM Request 1023 A RECONFIRM request message begins with the standard DNS Session 1024 Signaling 12-byte header [SessSig], followed by the RECONFIRM TLV. A 1025 RECONFIRM request message is illustrated below: 1027 1 1 1 1 1 1 1028 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1029 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1030 | MESSAGE ID | 1031 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1032 |QR| Opcode | Z | RCODE | 1033 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1034 | QDCOUNT (MUST BE ZERO) | 1035 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1036 | ANCOUNT (MUST BE ZERO) | 1037 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1038 | NSCOUNT (MUST BE ZERO) | 1039 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1040 | ARCOUNT (MUST BE ZERO) | 1041 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1042 | SSOP-TYPE = RECONFIRM (tentatively 0x43) | 1043 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1044 | SSOP-LENGTH (number of octets in SSOP-DATA) | 1045 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 1046 \ NAME \ \ 1047 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1048 | TYPE | | 1049 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1050 | CLASS | > SSOP-DATA 1051 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1052 | RDLEN | | 1053 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1054 \ RDATA \ / 1055 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 1057 Figure 4 1059 The MESSAGE ID field MUST be set to a unique value, that the client 1060 is not using for any other active operation on this connection. For 1061 the purposes here, a MESSAGE ID is in use on this connection if the 1062 client has used it in a request for which it has not yet received a 1063 response, or if the client has used it for a subscription which it 1064 has not yet cancelled using UNSUBSCRIBE. In the RECONFIRM response 1065 the server MUST echo back the MESSAGE ID value unchanged. 1067 The other header fields MUST be set as described in the DNS Session 1068 Signaling specification [SessSig]. The DNS Opcode is the Session 1069 Signaling Opcode (tentatively 6). The four count fields MUST be 1070 empty, and the corresponding four sections MUST be empty (i.e., 1071 absent). 1073 The SSOP-TYPE is RECONFIRM (tentatively 0x43). The SSOP-LENGTH is 1074 the length of the data that follows, which specifies the name, type, 1075 class, and content of the record being disputed. 1077 The SSOP-DATA for a RECONFIRM request MUST contain exactly one 1078 record. The SSOP-DATA for a RECONFIRM request has no count field to 1079 specify more than one record. Since RECONFIRM requests are sent over 1080 TCP, multiple RECONFIRM request messages can be concatenated in a 1081 single TCP stream and packed efficiently into TCP segments. 1083 TYPE MUST NOT be the value ANY (255) and CLASS MUST NOT be the value 1084 ANY (255). 1086 DNS wildcarding is not supported. That is, a wildcard ("*") in a 1087 RECONFIRM message matches only a literal wildcard character ("*") in 1088 the zone, and nothing else. 1090 Aliasing is not supported. That is, a CNAME in a RECONFIRM message 1091 matches only a literal CNAME record in the zone, and nothing else. 1093 6.5.2. RECONFIRM Response 1095 Each RECONFIRM request generates exactly one RECONFIRM response from 1096 the server. 1098 A RECONFIRM response message begins with the standard DNS Session 1099 Signaling 12-byte header [SessSig], possibly followed by one or more 1100 optional Modifier TLVs, such as a Retry Delay Modifier TLV. 1102 The MESSAGE ID field MUST echo the value given in the ID field of the 1103 RECONFIRM request. This is how the client knows which request is 1104 being responded to. 1106 A RECONFIRM response message MUST NOT contain a Session Signaling 1107 Operation TLV. The Session Signaling Operation TLV is NOT copied 1108 from the RECONFIRM request. 1110 In the RECONFIRM response the RCODE confirms receipt of the 1111 reconfirmation request. Supported RCODEs are as follows: 1113 +------------+-------+----------------------------------------------+ 1114 | Mnemonic | Value | Description | 1115 +------------+-------+----------------------------------------------+ 1116 | NOERROR | 0 | RECONFIRM accepted. | 1117 | FORMERR | 1 | Server failed to process request due to a | 1118 | | | malformed request. | 1119 | SERVFAIL | 2 | Server failed to process request due to a | 1120 | | | problem with the server. | 1121 | NXDOMAIN | 3 | NOT APPLICABLE. DNS Push Notification | 1122 | | | servers MUST NOT return NXDOMAIN errors in | 1123 | | | response to RECONFIRM requests. | 1124 | NOTIMP | 4 | Server does not recognize DNS Session | 1125 | | | Signaling Opcode. | 1126 | REFUSED | 5 | Server refuses to process request for policy | 1127 | | | or security reasons. | 1128 | NOTAUTH | 9 | Server is not authoritative for the | 1129 | | | requested name. | 1130 | SSOPNOTIMP | 11 | RECONFIRM operation not supported. | 1131 +------------+-------+----------------------------------------------+ 1133 RECONFIRM Response codes 1135 This document specifies only these RCODE values for RECONFIRM 1136 Responses. Servers sending RECONFIRM Responses SHOULD use one of 1137 these values. However, future circumstances may create situations 1138 where other RCODE values are appropriate in RECONFIRM Responses, so 1139 clients MUST be prepared to accept RECONFIRM Responses with any RCODE 1140 value. 1142 Nonzero RCODE values signal some kind of error. 1144 RCODE value FORMERR indicates a message format error, for example 1145 TYPE or CLASS being ANY (255). 1147 RCODE value SERVFAIL indicates that the server has exhausted its 1148 resources or other serious problem occurred. 1150 RCODE values NOTIMP indicates that the server does not support 1151 Session Signaling, and Session Signaling is required for RECONFIRM 1152 requests. 1154 RCODE value REFUSED indicates that the server supports RECONFIRM 1155 requests but is currently not configured to accept them from this 1156 client. 1158 RCODE value NOTAUTH indicates that the server is not authoritative 1159 for the requested name, and can do nothing to remedy the apparent 1160 error. Note that there may be future cases in which a server is able 1161 to pass on the RECONFIRM request to the ultimate source of the 1162 information, and in these cases the server should return NOERROR. 1164 RCODE value SSOPNOTIMP indicates that the server does not support 1165 RECONFIRM requests. 1167 Similarly, a server would only generate SSOPNOTIMP if it did not 1168 support Push Notifications, and if the server does not support Push 1169 Notifications then it should not be possible for a client to have an 1170 active subscription to cancel. 1172 Nonzero RCODE values SERVFAIL, REFUSED and SSOPNOTIMP are benign from 1173 the client's point of view. The client may log them to aid in 1174 debugging, but otherwise they require no special action. 1176 Nonzero RCODE values other than these three indicate a serious 1177 problem with the client. After sending an error response other than 1178 one of these three, the server SHOULD send a DNS Session Signaling 1179 Retry Delay Operation TLV and then close the TCP connection, as 1180 described in the DNS Session Signaling specification [SessSig]. 1182 6.6. Client-Initiated Termination 1184 An individual subscription is terminated by sending an UNSUBSCRIBE 1185 TLV for that specific subscription, or all subscriptions can be 1186 cancelled at once by the client closing the connection. When a 1187 client terminates an individual subscription (via UNSUBSCRIBE) or all 1188 subscriptions on that connection (by closing the connection) it is 1189 signaling to the server that it is longer interested in receiving 1190 those particular updates. It is informing the server that the server 1191 may release any state information it has been keeping with regards to 1192 these particular subscriptions. 1194 After terminating its last subscription on a connection via 1195 UNSUBSCRIBE, a client MAY close the connection immediately, or it may 1196 keep it open if it anticipates performing further operations on that 1197 connection in the future. If a client wishes to keep an idle 1198 connection open, it MUST respect the maximum idle time required by 1199 the server [SessSig]. 1201 If a client plans to terminate one or more subscriptions on a 1202 connection and doesn't intend to keep that connection open, then as 1203 an efficiency optimization it MAY instead choose to simply close the 1204 connection, which implicitly terminates all subscriptions on that 1205 connection. This may occur because the client computer is being shut 1206 down, is going to sleep, the application requiring the subscriptions 1207 has terminated, or simply because the last active subscription on 1208 that connection has been cancelled. 1210 When closing a connection, a client will generally do an abortive 1211 disconnect, sending a TCP RST. This immediately discards all 1212 remaining inbound and outbound data, which is appropriate if the 1213 client no longer has any interest in this data. In the BSD Sockets 1214 API, sending a TCP RST is achieved by setting the SO_LINGER option 1215 with a time of 0 seconds and then closing the socket. 1217 If a client has performed operations on this connection that it would 1218 not want lost (like DNS updates) then the client SHOULD do an orderly 1219 disconnect, sending a TCP FIN. In the BSD Sockets API, sending a TCP 1220 FIN is achieved by calling "shutdown(s,SHUT_WR)" and keeping the 1221 socket open until all remaining data has been read from it. 1223 7. Security Considerations 1225 The Strict Privacy Usage Profile for DNS over TLS is strongly 1226 recommended for DNS Push Notifications as defined in Authentication 1227 and (D)TLS Profile for DNS-over-(D)TLS 1228 [I-D.ietf-dprive-dtls-and-tls-profiles]. The Opportunistic Privacy 1229 Usage Profile is permissible as a way to support incremental 1230 deployment of security capabilities. Cleartext connections for DNS 1231 Push Notifications are not permissible. 1233 DNSSEC is RECOMMENDED for the authentication of DNS Push Notification 1234 servers. TLS alone does not provide complete security. TLS 1235 certificate verification can provide reasonable assurance that the 1236 client is really talking to the server associated with the desired 1237 host name, but since the desired host name is learned via a DNS SRV 1238 query, if the SRV query is subverted then the client may have a 1239 secure connection to a rogue server. DNSSEC can provided added 1240 confidence that the SRV query has not been subverted. 1242 7.1. Security Services 1244 It is the goal of using TLS to provide the following security 1245 services: 1247 Confidentiality: All application-layer communication is encrypted 1248 with the goal that no party should be able to decrypt it except 1249 the intended receiver. 1251 Data integrity protection: Any changes made to the communication in 1252 transit are detectable by the receiver. 1254 Authentication: An end-point of the TLS communication is 1255 authenticated as the intended entity to communicate with. 1257 Deployment recommendations on the appropriate key lengths and cypher 1258 suites are beyond the scope of this document. Please refer to TLS 1259 Recommendations [RFC7525] for the best current practices. Keep in 1260 mind that best practices only exist for a snapshot in time and 1261 recommendations will continue to change. Updated versions or errata 1262 may exist for these recommendations. 1264 7.2. TLS Name Authentication 1266 As described in Section 6.1, the client discovers the DNS Push 1267 Notification server using an SRV lookup for the record name 1268 "_dns-push-tls._tcp.". The server connection endpoint SHOULD 1269 then be authenticated using DANE TLSA records for the associated SRV 1270 record. This associates the target's name and port number with a 1271 trusted TLS certificate [RFC7673]. This procedure uses the TLS Sever 1272 Name Indication (SNI) extension [RFC6066] to inform the server of the 1273 name the client has authenticated through the use of TLSA records. 1274 Therefore, if the SRV record passes DNSSEC validation and a TLSA 1275 record matching the target name is useable, an SNI extension must be 1276 used for the target name to ensure the client is connecting to the 1277 server it has authenticated. If the target name does not have a 1278 usable TLSA record, then the use of the SNI extension is optional. 1280 See Authentication and (D)TLS Profile for DNS-over-(D)TLS 1281 [I-D.ietf-dprive-dtls-and-tls-profiles] for more information on 1282 authenticating domain names. Also note that a DNS Push server is an 1283 authoritative server and a DNS Push client is a standard DNS client. 1284 While the terminology in Authentication and (D)TLS Profile for DNS- 1285 over-(D)TLS [I-D.ietf-dprive-dtls-and-tls-profiles] explicitly states 1286 it does not apply to authoritative servers, it does in this case 1287 apply to DNS Push Notification clients and servers. 1289 7.3. TLS Compression 1291 In order to reduce the chances of compression-related attacks, TLS- 1292 level compression SHOULD be disabled when using TLS versions 1.2 and 1293 earlier. In the draft version of TLS 1.3 [I-D.ietf-tls-tls13], TLS- 1294 level compression has been removed completely. 1296 7.4. TLS Session Resumption 1298 TLS Session Resumption is permissible on DNS Push Notification 1299 servers. The server may keep TLS state with Session IDs [RFC5246] or 1300 operate in stateless mode by sending a Session Ticket [RFC5077] to 1301 the client for it to store. However, once the connection is closed, 1302 any existing subscriptions will be dropped. When the TLS session is 1303 resumed, the DNS Push Notification server will not have any 1304 subscription state and will proceed as with any other new connection. 1305 Use of TLS Session Resumption allows a new TLS connection to be set 1306 up more quickly, but the client will still have to recreate any 1307 desired subscriptions. 1309 8. IANA Considerations 1311 This document defines the service name: "_dns-push-tls._tcp". 1312 It is only applicable for the TCP protocol. 1313 This name is to be published in the IANA Service Name Registry 1314 [RFC6335][SN]. 1316 This document defines four DNS Session Signaling TLV types: SUBSCRIBE 1317 with (tentative) value 0x40 (64), PUSH with (tentative) value 0x41 1318 (65), UNSUBSCRIBE with (tentative) value 0x42 (66), and RECONFIRM 1319 with (tentative) value 0x43 (67). 1321 9. Acknowledgements 1323 The authors would like to thank Kiren Sekar and Marc Krochmal for 1324 previous work completed in this field. 1326 This draft has been improved due to comments from Ran Atkinson, Tim 1327 Chown, Mark Delany, Ralph Droms, Bernie Volz, Jan Komissar, Manju 1328 Shankar Rao, Markus Stenberg, Dave Thaler, Soraia Zlatkovic, Sara 1329 Dickinson, and Andrew Sullivan. 1331 10. References 1333 10.1. Normative References 1335 [I-D.ietf-tls-tls13] 1336 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1337 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 1338 April 2017. 1340 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1341 DOI 10.17487/RFC0768, August 1980, 1342 . 1344 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1345 RFC 793, DOI 10.17487/RFC0793, September 1981, 1346 . 1348 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1349 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1350 . 1352 [RFC1035] Mockapetris, P., "Domain names - implementation and 1353 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1354 November 1987, . 1356 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1357 Application and Support", STD 3, RFC 1123, 1358 DOI 10.17487/RFC1123, October 1989, 1359 . 1361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1362 Requirement Levels", BCP 14, RFC 2119, 1363 DOI 10.17487/RFC2119, March 1997, 1364 . 1366 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1367 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1368 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1369 . 1371 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1372 specifying the location of services (DNS SRV)", RFC 2782, 1373 DOI 10.17487/RFC2782, February 2000, 1374 . 1376 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1377 (TLS) Protocol Version 1.2", RFC 5246, 1378 DOI 10.17487/RFC5246, August 2008, 1379 . 1381 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1382 Extensions: Extension Definitions", RFC 6066, 1383 DOI 10.17487/RFC6066, January 2011, 1384 . 1386 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1387 Cheshire, "Internet Assigned Numbers Authority (IANA) 1388 Procedures for the Management of the Service Name and 1389 Transport Protocol Port Number Registry", BCP 165, 1390 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1391 . 1393 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1394 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1395 April 2013, . 1397 [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1398 Based Authentication of Named Entities (DANE) TLSA Records 1399 with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 1400 2015, . 1402 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1403 D. Wessels, "DNS Transport over TCP - Implementation 1404 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1405 . 1407 [SessSig] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1408 Mankin, A., and T. Pusateri, "DNS Session Signaling", 1409 draft-ietf-dnsop-session-signal-02 (work in progress), 1410 March 2017. 1412 [SN] "Service Name and Transport Protocol Port Number 1413 Registry", . 1416 10.2. Informative References 1418 [DisProx] Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service 1419 Discovery", draft-ietf-dnssd-hybrid-06 (work in progress), 1420 March 2017. 1422 [I-D.dukkipati-tcpm-tcp-loss-probe] 1423 Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 1424 "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of 1425 Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work 1426 in progress), February 2013. 1428 [I-D.ietf-dprive-dtls-and-tls-profiles] 1429 Dickinson, S., Gillmor, D., and T. Reddy, "Usage and 1430 (D)TLS Profiles for DNS-over-(D)TLS", draft-ietf-dprive- 1431 dtls-and-tls-profiles-10 (work in progress), June 2017. 1433 [I-D.sekar-dns-llq] 1434 Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- 1435 llq-01 (work in progress), August 2006. 1437 [IPJ.9-4-TCPSYN] 1438 Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The 1439 Internet Protocol Journal, Cisco Systems, Volume 9, 1440 Number 4, December 2006. 1442 [obs] "Observer Pattern", . 1445 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1446 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1447 . 1449 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1450 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 1451 December 2005, . 1453 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 1454 RFC 4953, DOI 10.17487/RFC4953, July 2007, 1455 . 1457 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1458 "Transport Layer Security (TLS) Session Resumption without 1459 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1460 January 2008, . 1462 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 1463 "Understanding Apple's Back to My Mac (BTMM) Service", 1464 RFC 6281, DOI 10.17487/RFC6281, June 2011, 1465 . 1467 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1468 DOI 10.17487/RFC6762, February 2013, 1469 . 1471 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1472 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1473 . 1475 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1476 "TCP Extensions for Multipath Operation with Multiple 1477 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1478 . 1480 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1481 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1482 . 1484 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1485 "Recommendations for Secure Use of Transport Layer 1486 Security (TLS) and Datagram Transport Layer Security 1487 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1488 2015, . 1490 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1491 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 1492 2015, . 1494 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1495 and P. Hoffman, "Specification for DNS over Transport 1496 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1497 2016, . 1499 [XEP0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1500 Subscribe", XSF XEP 0060, July 2010. 1502 Authors' Addresses 1504 Tom Pusateri 1505 Seeking affiliation 1506 Hilton Head Island, SC 1507 USA 1509 Phone: +1 843 473 7394 1510 Email: pusateri@bangj.com 1512 Stuart Cheshire 1513 Apple Inc. 1514 1 Infinite Loop 1515 Cupertino, CA 95014 1516 USA 1518 Phone: +1 408 974 3207 1519 Email: cheshire@apple.com