idnits 2.17.1 draft-ietf-dnssd-push-13.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 (October 29, 2017) is 2361 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-21 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'SN' == Outdated reference: A later version (-20) exists of draft-ietf-dnsop-session-signal-04 == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-07 == 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 (~~), 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 Unaffiliated 4 Intended status: Standards Track S. Cheshire 5 Expires: May 2, 2018 Apple Inc. 6 October 29, 2017 8 DNS Push Notifications 9 draft-ietf-dnssd-push-13 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, as long as the polling rate is not 17 too high. But there exists no mechanism for a client to be 18 asynchronously notified when these changes occur. This document 19 defines a mechanism for a client to be notified of such changes to 20 DNS records, called DNS Push Notifications. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 2, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. State Considerations . . . . . . . . . . . . . . . . . . . . 7 62 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 64 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 12 65 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 13 66 6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 16 67 6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 19 68 6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20 69 6.3.2. PUSH Response . . . . . . . . . . . . . . . . . . . . 23 70 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 24 71 6.4.1. UNSUBSCRIBE Request . . . . . . . . . . . . . . . . . 25 72 6.4.2. UNSUBSCRIBE Response . . . . . . . . . . . . . . . . 27 73 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 29 74 6.5.1. RECONFIRM Request . . . . . . . . . . . . . . . . . . 30 75 6.5.2. RECONFIRM Response . . . . . . . . . . . . . . . . . 32 76 6.6. Client-Initiated Termination . . . . . . . . . . . . . . 34 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 78 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 35 79 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 35 80 7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 36 81 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 36 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 86 10.2. Informative References . . . . . . . . . . . . . . . . . 39 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 89 1. Introduction 91 DNS records may be updated using DNS Update [RFC2136]. Other 92 mechanisms such as a Discovery Proxy [DisProx] can also generate 93 changes to a DNS zone. This document specifies a protocol for DNS 94 clients to subscribe to receive asynchronous notifications of changes 95 to RRSets of interest. It is immediately relevant in the case of DNS 96 Service Discovery [RFC6763] but is not limited to that use case, and 97 provides a general DNS mechanism for DNS record change notifications. 98 Familiarity with the DNS protocol and DNS packet formats is assumed 99 [RFC1034] [RFC1035] [RFC6895]. 101 1.1. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 108 2. Motivation 110 As the domain name system continues to adapt to new uses and changes 111 in deployment, polling has the potential to burden DNS servers at 112 many levels throughout the network. Other network protocols have 113 successfully deployed a publish/subscribe model to state changes 114 following the Observer design pattern [obs]. XMPP Publish-Subscribe 115 [XEP0060] and Atom [RFC4287] are examples. While DNS servers are 116 generally highly tuned and capable of a high rate of query/response 117 traffic, adding a publish/subscribe model for tracking changes to DNS 118 records can result in more timely notification of changes with 119 reduced CPU usage and lower network traffic. 121 Multicast DNS [RFC6762] implementations always listen on a well known 122 link-local IP multicast group, and new services and updates are sent 123 for all group members to receive. Therefore, Multicast DNS already 124 has asynchronous change notification capability. However, when DNS 125 Service Discovery [RFC6763] is used across a wide area network using 126 Unicast DNS (possibly facilitated via a Discovery Proxy [DisProx]) it 127 would be beneficial to have an equivalent capability for Unicast DNS, 128 to allow clients to learn about DNS record changes in a timely manner 129 without polling. 131 The DNS Long-Lived Queries (LLQ) [I-D.sekar-dns-llq] mechanism is an 132 existing deployed solution to provide asynchronous change 133 notifications, used by Apple's Back to My Mac Service [RFC6281] 134 introduced in Mac OS X 10.5 Leopard in 2007. Back to My Mac was 135 designed in an era when the data centre operations staff asserted 136 that it was impossible for a server to handle large numbers of 137 mostly-idle TCP connections, so LLQ had to defined as a UDP-based 138 protocol, effectively replicating much of TCP's connection state 139 management logic in user space, and creating its own poor imitations 140 of existing TCP features like the three-way handshake, flow control, 141 and reliability. 143 This document builds on experience gained with the LLQ protocol, with 144 an improved design. Instead of using UDP, this specification uses 145 TCP, and therefore doesn't need to reinvent existing TCP 146 functionality. Using TCP also gives long-lived low-traffic 147 connections better longevity through NAT gateways without resorting 148 to excessive keepalive traffic. Instead of inventing a new 149 vocabulary of messages to communicate DNS zone changes as LLQ did, 150 this specification adopts the syntax and semantics of DNS Update 151 messages [RFC2136]. 153 3. Overview 155 The existing DNS Update protocol [RFC2136] provides a mechanism for 156 clients to add or delete individual resource records (RRs) or entire 157 resource record sets (RRSets) on the zone's server. 159 This specification adopts a simplified subset of these existing 160 syntax and semantics, and uses them for DNS Push Notification 161 messages going in the opposite direction, from server to client, to 162 communicate changes to a zone. The client subscribes for Push 163 Notifications by connecting to the server and sending DNS message(s) 164 indicating the RRSet(s) of interest. When the client loses interest 165 in updates to these records, it unsubscribes. 167 The DNS Push Notification server for a zone is any server capable 168 of generating the correct change notifications for a name. 169 It may be a master, slave, or stealth name server [RFC7719]. 170 Consequently, the "_dns-push-tls._tcp." SRV record for a 171 zone MAY reference the same target host and port as that zone's 172 "_dns-update-tls._tcp." SRV record. When the same target host 173 and port is offered for both DNS Updates and DNS Push Notifications, 174 a client MAY use a single TCP connection to that server for both DNS 175 Updates and DNS Push Notification Queries. 177 Supporting DNS Updates and DNS Push Notifications on the same server 178 is OPTIONAL. A DNS Push Notification server does NOT also have to 179 support DNS Update. 181 DNS Updates and DNS Push Notifications may be handled on different 182 ports on the same target host, in which case they are not considered 183 to be the "same server" for the purposes of this specification, and 184 communications with these two ports are handled independently. 186 Standard DNS Queries MAY be sent over a DNS Push Notification 187 connection, provided that these are queries for names falling within 188 the server's zone (the in the "_dns-push-tls._tcp." SRV 189 record). The RD (Recursion Desired) bit MUST be zero. If a query is 190 received with the RD bit set, matching records for names falling 191 within the server's zones should be returned with the RA (Recursion 192 Available) bit clear. If the query is for a name not in the server's 193 zone, an error with RCODE NOTAUTH (Not Authoritative) should be 194 returned. 196 DNS Push Notification clients are NOT required to implement DNS 197 Update Prerequisite processing. Prerequisites are used to perform 198 tentative atomic test-and-set type operations when a client updates 199 records on a server, and that concept has no applicability when it 200 comes to an authoritative server informing a client of changes to DNS 201 records. 203 This DNS Push Notification specification includes support for DNS 204 classes, for completeness. However, in practice, it is anticipated 205 that for the foreseeable future the only DNS class in use will be DNS 206 class "IN", as is the reality today with existing DNS servers and 207 clients. A DNS Push Notification server MAY choose to implement only 208 DNS class "IN". If messages are received for a class other than 209 "IN", and that class is not supported, an error with RCODE NOTIMPL 210 (Not Implemented) should be returned. 212 DNS Push Notifications impose less load on the responding server than 213 rapid polling would, but Push Notifications do still have a cost, so 214 DNS Push Notification clients must not recklessly create an excessive 215 number of Push Notification subscriptions. A subscription should 216 only be active when there is a valid reason to need live data (for 217 example, an on-screen display is currently showing the results to the 218 user) and the subscription SHOULD be cancelled as soon as the need 219 for that data ends (for example, when the user dismisses that 220 display). Implementations MAY want to implement idle timeouts, so 221 that if the user ceases interacting with the device, the display 222 showing the result of the DNS Push Notification subscription is 223 automatically dismissed after a certain period of inactivity. For 224 example, if a user presses the "Print" button on their smartphone, 225 and then leaves the phone showing the printer discovery screen until 226 the phone goes to sleep, then the printer discovery screen should be 227 automatically dismissed as the device goes to sleep. If the user 228 does still intend to print, this will require them to press the 229 "Print" button again when they wake their phone up. 231 A DNS Push Notification client must not routinely keep a DNS Push 232 Notification subscription active 24 hours a day, 7 days a week, just 233 to keep a list in memory up to date so that if the user does choose 234 to bring up an on-screen display of that data, it can be displayed 235 really fast. DNS Push Notifications are designed to be fast enough 236 that there is no need to pre-load a "warm" list in memory just in 237 case it might be needed later. 239 Generally, as described in the DNS Stateful Operations specification 240 [StatefulOp], a client must not keep a connection to a server open 241 indefinitely if it has no subscriptions (or other operations) active 242 on that connection. A client MAY close a connection as soon as it 243 becomes idle, and then if needed in the future, open a new connection 244 when required. Alternatively, a client MAY speculatively keep an 245 idle connection open for some time, subject to the constraint that it 246 MUST NOT keep a connection open that has been idle for more than the 247 session's idle timeout (15 seconds by default). 249 4. Transport 251 Implementations of DNS Update [RFC2136] MAY use either User Datagram 252 Protocol (UDP) [RFC0768] or Transmission Control Protocol (TCP) 253 [RFC0793] as the transport protocol, in keeping with the historical 254 precedent that DNS queries must first be sent over UDP [RFC1123]. 255 This requirement to use UDP has subsequently been relaxed [RFC7766]. 257 In keeping with the more recent precedent, DNS Push Notification is 258 defined only for TCP. DNS Push Notification clients MUST use TLS 259 over TCP [RFC7858]. 261 Connection setup over TCP ensures return reachability and alleviates 262 concerns of state overload at the server through anonymous 263 subscriptions. All subscribers are guaranteed to be reachable by the 264 server by virtue of the TCP three-way handshake. Flooding attacks 265 are possible with any protocol, and a benefit of TCP is that there 266 are already established industry best practices to guard against SYN 267 flooding and similar attacks [IPJ.9-4-TCPSYN] [RFC4953]. 269 Use of TCP also allows DNS Push Notifications to take advantage of 270 current and future developments in TCP, such as Multipath TCP (MPTCP) 271 [RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP) 272 [I-D.dukkipati-tcpm-tcp-loss-probe], and so on. 274 Transport Layer Security (TLS) [RFC5246] is well understood and 275 deployed across many protocols running over TCP. It is designed to 276 prevent eavesdropping, tampering, and message forgery. TLS is 277 REQUIRED for every connection between a client subscriber and server 278 in this protocol specification. Additional security measures such as 279 client authentication during TLS negotiation MAY also be employed to 280 increase the trust relationship between client and server. 282 5. State Considerations 284 Each DNS Push Notification server is capable of handling some finite 285 number of Push Notification subscriptions. This number will vary 286 from server to server and is based on physical machine 287 characteristics, network bandwidth, and operating system resource 288 allocation. After a client establishes a connection to a DNS server, 289 each subscription is individually accepted or rejected. Servers may 290 employ various techniques to limit subscriptions to a manageable 291 level. Correspondingly, the client is free to establish simultaneous 292 connections to alternate DNS servers that support DNS Push 293 Notifications for the zone and distribute subscriptions at its 294 discretion. In this way, both clients and servers can react to 295 resource constraints. Token bucket rate limiting schemes are also 296 effective in providing fairness by a server across numerous client 297 requests. 299 6. Protocol Operation 301 The DNS Push Notification protocol is a session-oriented protocol, 302 and makes use of DNS Stateful Operations [StatefulOp]. 304 For details of the DNS Stateful Operations message format refer to 305 the DNS Stateful Operations specification [StatefulOp]. Those 306 details are not repeated here. 308 DNS Push Notification clients and servers MUST support DNS Stateful 309 Operations, but the server SHOULD NOT issue any DNS Stateful 310 Operations messages until after the client has first initiated a DNS 311 Stateful Operation of its own. A single server can support DNS 312 Queries, DNS Updates, and DNS Push Notifications (using DNS Stateful 313 Operations) on the same TCP port, and until the client has sent at 314 least one DNS Stateful Operations message, the server does not know 315 what kind of client has connected to it. Once the client has 316 indicated willingness to use DNS Stateful Operations by sending one 317 of its own, either side of the connection may then initiate further 318 Stateful Operations at any time. 320 A DNS Push Notification exchange begins with the client discovering 321 the appropriate server, using the procedure described in Section 6.1, 322 and then making a TLS/TCP connection to it. 324 A typical DNS Push Notification client will immediately issue a DNS 325 Stateful Operations Keepalive operation to request a session timeout 326 or keepalive interval longer than the the 15-second defaults, but 327 this is not required. A DNS Push Notification client MAY issue other 328 requests on the connection first, and only issue a DNS Stateful 329 Operations Keepalive operation later if it determines that to be 330 necessary. 332 Once the connection is made, the client may then add and remove Push 333 Notification subscriptions. In accordance with the current set of 334 active subscriptions the server sends relevant asynchronous Push 335 Notifications to the client. Note that a client MUST be prepared to 336 receive (and silently ignore) Push Notifications for subscriptions it 337 has previously removed, since there is no way to prevent the 338 situation where a Push Notification is in flight from server to 339 client while the client's UNSUBSCRIBE message cancelling that 340 subscription is simultaneously in flight from client to server. 342 The exchange between client and server terminates when either end 343 closes the TCP connection with a TCP FIN or RST. 345 6.1. Discovery 347 The first step in DNS Push Notification subscription is to discover 348 an appropriate DNS server that supports DNS Push Notifications for 349 the desired zone. 351 The client begins by opening a DNS Session to its normal configured 352 DNS recursive resolver and requesting a Push Notification 353 subscription. If this is successful, then the recursive resolver 354 will make appropriate Push Notification subscriptions on the client's 355 behalf, and the client will recieve appropriate results. If the 356 recursive resolver does not support Push Notification subscriptions, 357 then it will return an error code, and the client should proceed to 358 discover the appropriate server to talk to directly. The client MUST 359 also determine which TCP port on the server is listening for 360 connections, which need not be (and often is not) the typical TCP 361 port 53 used for conventional DNS, or TCP port 853 used for DNS over 362 TLS [RFC7858]. 364 1. The client begins the discovery by sending a DNS query to its 365 local resolver, with record type SOA [RFC1035] for the record to 366 which it wishes to subscribe. As an example, if it wishes to 367 subscribe to PTR records with the name 368 _printers._tcp.foo.example.com, it sends an SOA query for 369 _printers._tcp.foo.example.com. The goal is to determine the 370 authoritative server for _printers._tcp.foo.example.com. 372 2. If the SOA record exists as exactly specified in the query, it is 373 expected to be returned in the Answer section with a NOERROR 374 response code. If the exact SOA record does not exist, the 375 client may get back a NOERROR/NODATA response or it may get back 376 a NXDOMAIN/Name Error response. This depends on the resolver 377 implementation and whether the domain exists. The client is 378 looking for an SOA record to be returned in either the Answer 379 section or the Authority section with a NOERROR response code. 380 If the client receives an NXDOMAIN/Name Error response code or a 381 response containing no SOA record, it should strip the leading 382 label from the query name and if the resulting name has at least 383 one label in it, the client should send a new SOA query, 384 repeating this until a NOERROR response code is received or the 385 query name is empty. In the case of an empty name, the client 386 may retry the operation at a later time, of the client's 387 choosing, such after a change in network attachment. 389 3. In the example above, if an SOA record query is sent for 390 _printers._tcp.foo.example.com and an NXDOMAIN/Name Error is 391 returned with an SOA record in the Authority section for 392 foo.example.com, the client should strip the leading label and 393 query an SOA record for _tcp.foo.example.com. If a NOERROR/ 394 NODATA response is received with an SOA record in the Authority 395 section for foo.example.com, this is sufficent. If an NXDOMAIN/ 396 Name Error response is received, the client should again strip 397 the leading label and query an SOA record for foo.example.com. 398 If the foo.example.com domain exists, this should result in a 399 NOERROR response with the SOA record in the Answer section. If 400 the domain foo.example.com does not exist, the response will 401 likely be an NXDOMAIN/Name Error with an SOA record for 402 example.com in the Authority section. This means the subdomain 403 foo.example.com has not been properly delegated by example.com. 405 4. If a NOERROR/NODATA response is received but contains no SOA in 406 the Authority section, the client could try stripping the leading 407 label and issuing another SOA query. Additional information 408 about negative responses can be found in Section 2 of [RFC2308]. 410 5. Once the SOA is known (either by virtue of being seen in the 411 Answer Section, or in the Authority Section), the client sends a 412 DNS query with type SRV [RFC2782] for the record name 413 "_dns-push-tls._tcp.", where is the owner name of 414 the discovered SOA record. 416 6. For implementors of this specification, an authoritative answer 417 for that SRV record, and only such an answer, will determine 418 whether the zone supports DNS Push Notifications. 420 7. If the SRV record does exist, the SRV "target" contains the name 421 of the server providing DNS Push Notifications for the zone. The 422 port number on which to contact the server is in the SRV record 423 "port" field. The address(es) of the target host MAY be included 424 in the Additional Section, however, the address records SHOULD be 425 authenticated before use as described below in Section 7.2 and 426 [RFC7673]. 428 8. More than one SRV record may be returned. In this case, the 429 "priority" and "weight" values in the returned SRV records are 430 used to determine the order in which to contact the servers for 431 subscription requests. As described in the SRV specification 432 [RFC2782], the server with the lowest "priority" is first 433 contacted. If more than one server has the same "priority", the 434 "weight" indicates the weighted probability that the client 435 should contact that server. Higher weights have higher 436 probabilities of being selected. If a server is not reachable or 437 is not willing to accept a subscription request, then a 438 subsequent server is to be contacted. 440 Each time a client makes a new DNS Push Notification subscription 441 connection, it SHOULD repeat the discovery process in order to 442 determine the preferred DNS server for subscriptions at that time. 443 However, the client device MUST respect the DNS TTL values on records 444 it receives, and store them in its local cache with this lifetime. 445 This means that, as long as the DNS TTL values on the authoritative 446 records were set to reasonable values, repeated application of this 447 discovery process can be completed nearly instantaneously by the 448 client, using only locally-stored cached data. 450 6.2. DNS Push Notification SUBSCRIBE 452 After connecting, and requesting a longer idle timeout and/or 453 keepalive interval if necessary, a DNS Push Notification client then 454 indicates its desire to receive DNS Push Notifications for a given 455 domain name by sending a SUBSCRIBE request over the established TLS 456 connection to the server. A SUBSCRIBE request is encoded in a DNS 457 Stateful Operations [StatefulOp] message. This specification defines 458 a DNS Stateful Operations TLV for DNS Push Notification SUBSCRIBE 459 Requests/Responses (tentatively Stateful Operations Type Code 0x40). 461 The entity that initiates a SUBSCRIBE request is by definition the 462 client. A server should not send a SUBSCRIBE request over an 463 existing connection from a client. If a server does send a SUBSCRIBE 464 request over the connection initiated by a client, it is an error and 465 the client should acknowledge the request with the error response 466 RCODE NOTAUTH (Not Authoritative). 468 6.2.1. SUBSCRIBE Request 470 A SUBSCRIBE request message begins with the standard DNS Stateful 471 Operations 12-byte header [StatefulOp], followed by the SUBSCRIBE 472 TLV. A SUBSCRIBE request message is illustrated below: 474 1 1 1 1 1 1 475 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 476 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 477 | MESSAGE ID | 478 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 479 |QR| Opcode | Z | RCODE | 480 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 481 | QDCOUNT (MUST BE ZERO) | 482 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 483 | ANCOUNT (MUST BE ZERO) | 484 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 485 | NSCOUNT (MUST BE ZERO) | 486 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 487 | ARCOUNT (MUST BE ZERO) | 488 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 489 | SSOP-TYPE = SUBSCRIBE (tentatively 0x40) | 490 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 491 | SSOP-LENGTH (number of octets in SSOP-DATA) | 492 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 493 | | \ 494 \ NAME \ | 495 \ \ | 496 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > SSOP-DATA 497 | TYPE | | 498 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 499 | CLASS | / 500 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 502 Figure 1 504 The MESSAGE ID field MUST be set to a unique value, that the client 505 is not using for any other active operation on this connection. For 506 the purposes here, a MESSAGE ID is in use on this connection if the 507 client has used it in a request for which it has not yet received a 508 response, or if the client has used it for a subscription which it 509 has not yet cancelled using UNSUBSCRIBE. In the SUBSCRIBE response 510 the server MUST echo back the MESSAGE ID value unchanged. 512 The other header fields MUST be set as described in the DNS Stateful 513 Operations specification [StatefulOp]. The DNS Opcode is the 514 Stateful Operations Opcode (tentatively 6). The four count fields 515 MUST be zero, and the corresponding four sections MUST be empty 516 (i.e., absent). 518 The SSOP-TYPE is SUBSCRIBE (tentatively 0x40). The SSOP-LENGTH is 519 the length of the SSOP-DATA that follows, which specifies the name, 520 type, and class of the record(s) being sought. 522 The SSOP-DATA for a SUBSCRIBE request MUST contain exactly one 523 question. The SSOP-DATA for a SUBSCRIBE request has no QDCOUNT field 524 to specify more than one question. Since SUBSCRIBE requests are sent 525 over TCP, multiple SUBSCRIBE request messages can be concatenated in 526 a single TCP stream and packed efficiently into TCP segments. 528 If accepted, the subscription will stay in effect until the client 529 cancels the subscription using UNSUBSCRIBE or until the connection 530 between the client and the server is closed. 532 SUBSCRIBE requests on a given connection MUST be unique. A client 533 MUST NOT send a SUBSCRIBE message that duplicates the NAME, TYPE and 534 CLASS of an existing active subscription on that TLS/TCP connection. 535 For the purpose of this matching, the established DNS case- 536 insensitivity for US-ASCII letters applies (e.g., "example.com" and 537 "Example.com" are the same). If a server receives such a duplicate 538 SUBSCRIBE message this is an error and the server MUST immediately 539 terminate the connection with a TCP RST (or equivalent for other 540 protocols). 542 DNS wildcarding is not supported. That is, a wildcard ("*") in a 543 SUBSCRIBE message matches only a literal wildcard character ("*") in 544 the zone, and nothing else. 546 Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message 547 matches only a literal CNAME record in the zone, and nothing else. 549 A client may SUBSCRIBE to records that are unknown to the server at 550 the time of the request (providing that the name falls within one of 551 the zone(s) the server is responsible for) and this is not an error. 552 The server MUST accept these requests and send Push Notifications if 553 and when matching records are found in the future. 555 If neither TYPE nor CLASS are ANY (255) then this is a specific 556 subscription to changes for the given NAME, TYPE and CLASS. If one 557 or both of TYPE or CLASS are ANY (255) then this subscription matches 558 any type and/or any class, as appropriate. 560 NOTE: A little-known quirk of DNS is that in DNS QUERY requests, 561 QTYPE and QCLASS 255 mean "ANY" not "ALL". They indicate that the 562 server should respond with ANY matching records of its choosing, not 563 necessarily ALL matching records. This can lead to some surprising 564 and unexpected results, where a query returns some valid answers but 565 not all of them, and makes QTYPE=ANY queries less useful than people 566 sometimes imagine. 568 When used in conjunction with SUBSCRIBE, TYPE and CLASS 255 should be 569 interpreted to mean "ALL", not "ANY". After accepting a subscription 570 where one or both of TYPE or CLASS are 255, the server MUST send Push 571 Notification Updates for ALL record changes that match the 572 subscription, not just some of them. 574 6.2.2. SUBSCRIBE Response 576 Each SUBSCRIBE request generates exactly one SUBSCRIBE response from 577 the server. 579 A SUBSCRIBE response message begins with the standard DNS Stateful 580 Operations 12-byte header [StatefulOp], possibly followed by one or 581 more optional Modifier TLVs, such as a Retry Delay Modifier TLV. 583 The MESSAGE ID field MUST echo the value given in the ID field of the 584 SUBSCRIBE request. This is how the client knows which request is 585 being responded to. 587 A SUBSCRIBE response message MUST NOT contain a Stateful Operations 588 Operation TLV. The Stateful Operations Operation TLV is NOT copied 589 from the SUBSCRIBE request. 591 In the SUBSCRIBE response the RCODE indicates whether or not the 592 subscription was accepted. Supported RCODEs are as follows: 594 +------------+-------+----------------------------------------------+ 595 | Mnemonic | Value | Description | 596 +------------+-------+----------------------------------------------+ 597 | NOERROR | 0 | SUBSCRIBE successful. | 598 | FORMERR | 1 | Server failed to process request due to a | 599 | | | malformed request. | 600 | SERVFAIL | 2 | Server failed to process request due to a | 601 | | | problem with the server. | 602 | NXDOMAIN | 3 | NOT APPLICABLE. DNS Push Notification | 603 | | | servers MUST NOT return NXDOMAIN errors in | 604 | | | response to SUBSCRIBE requests. | 605 | NOTIMP | 4 | Server does not recognize DNS Stateful | 606 | | | Operations Opcode. | 607 | REFUSED | 5 | Server refuses to process request for policy | 608 | | | or security reasons. | 609 | NOTAUTH | 9 | Server is not authoritative for the | 610 | | | requested name. | 611 | SSOPNOTIMP | 11 | SUBSCRIBE operation not supported. | 612 +------------+-------+----------------------------------------------+ 614 SUBSCRIBE Response codes 616 This document specifies only these RCODE values for SUBSCRIBE 617 Responses. Servers sending SUBSCRIBE Responses SHOULD use one of 618 these values. However, future circumstances may create situations 619 where other RCODE values are appropriate in SUBSCRIBE Responses, so 620 clients MUST be prepared to accept SUBSCRIBE Responses with any RCODE 621 value. 623 If the server sends a nonzero RCODE in the SUBSCRIBE response, either 624 the client is (at least partially) misconfigured, the server 625 resources are exhausted, or there is some other unknown failure on 626 the server. In any case, the client shouldn't retry the subscription 627 right away. Either end can terminate the connection, but the client 628 may want to try this subscription again, or it may have other 629 successful subscriptions that it doesn't want to abandon. If the 630 server sends a nonzero RCODE then it SHOULD append a Retry Delay 631 Modifier TLV [StatefulOp] to the response specifying a delay before 632 the client attempts this operation again. Recommended values for the 633 delay for different RCODE values are given below: 635 For RCODE = 1 (FORMERR) the delay may be any value selected by the 636 implementer. A value of five minutes is RECOMMENDED, to reduce 637 the risk of high load from defective clients. 639 For RCODE = 2 (SERVFAIL) the delay should be chosen according to 640 the level of server overload and the anticipated duration of that 641 overload. By default, a value of one minute is RECOMMENDED. If a 642 more serious server failure occurs, the delay may be longer in 643 accordance with the specific problem encountered. 645 For RCODE = 4 (NOTIMP), which occurs on a server that doesn't 646 implement DNS Stateful Operations [StatefulOp], it is unlikely 647 that the server will begin supporting DNS Stateful Operations in 648 the next few minutes, so the retry delay SHOULD be one hour. 650 For RCODE = 5 (REFUSED), which occurs on a server that implements 651 DNS Push Notifications, but is currently configured to disallow 652 DNS Push Notifications, the retry delay may be any value selected 653 by the implementer and/or configured by the operator. 654 This is a misconfiguration, since this server is listed in a 655 "_dns-push-tls._tcp." SRV record, but the server itself is 656 not currently configured to support DNS Push Notifications. Since 657 it is possible that the misconfiguration may be repaired at any 658 time, the retry delay should not be set too high. By default, a 659 value of 5 minutes is RECOMMENDED. 661 For RCODE = 9 (NOTAUTH), which occurs on a server that implements 662 DNS Push Notifications, but is not configured to be authoritative 663 for the requested name, the retry delay may be any value selected 664 by the implementer and/or configured by the operator. 665 This is a misconfiguration, since this server is listed in a 666 "_dns-push-tls._tcp." SRV record, but the server itself is 667 not currently configured to support DNS Push Notifications for 668 that zone. Since it is possible that the misconfiguration may be 669 repaired at any time, the retry delay should not be set too high. 670 By default, a value of 5 minutes is RECOMMENDED. 672 For RCODE = 11 (DNS Push SUBSCRIBE operation not supported), which 673 occurs on a server that doesn't implement DNS Push Notifications, 674 it is unlikely that the server will begin supporting DNS Push 675 Notifications in the next few minutes, so the retry delay SHOULD 676 be one hour. 678 For other RCODE values, the retry delay should be set by the 679 server as appropriate for that error condition. By default, a 680 value of 5 minutes is RECOMMENDED. 682 For RCODE = 9 (NOTAUTH), the time delay applies to requests for other 683 names falling within the same zone. Requests for names falling 684 within other zones are not subject to the delay. For all other 685 RCODEs the time delay applies to all subsequent requests to this 686 server. 688 After sending an error response the server MAY allow the connection 689 to remain open, or MAY send a DNS Push Notification Retry Delay 690 Operation TLV instructing the client to close the TCP connection, as 691 described in the DNS Stateful Operations specification [StatefulOp]. 692 Clients MUST correctly handle both cases. 694 6.3. DNS Push Notification Updates 696 Once a subscription has been successfully established, the server 697 generates PUSH messages to send to the client as appropriate. In the 698 case that the answer set was non-empty at the moment the subscription 699 was established, an initial PUSH message will be sent immediately 700 following the SUBSCRIBE Response. Subsequent changes to the answer 701 set are then communicated to the client in subsequent PUSH messages. 703 6.3.1. PUSH Message 705 A PUSH message begins with the standard DNS Stateful Operations 706 12-byte header [StatefulOp], followed by the PUSH TLV. A PUSH 707 message is illustrated below: 709 1 1 1 1 1 1 710 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 711 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 712 | MESSAGE ID | 713 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 714 |QR| Opcode | Z | RCODE | 715 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 716 | QDCOUNT (MUST BE ZERO) | 717 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 718 | ANCOUNT (MUST BE ZERO) | 719 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 720 | NSCOUNT (MUST BE ZERO) | 721 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 722 | ARCOUNT (MUST BE ZERO) | 723 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 724 | SSOP-TYPE = PUSH (tentatively 0x42) | 725 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 726 | SSOP-LENGTH (number of octets in SSOP-DATA) | 727 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 728 \ NAME \ \ 729 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 730 | TYPE | | 731 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 732 | CLASS | | 733 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 734 | RDLEN | | 735 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 736 \ RDATA \ | 737 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > SSOP-DATA 738 \ NAME \ | 739 +--+--+--+--+--+--+- | | 740 | TYPE Repeated | | 741 +--+--+--+--+--+--+- | | 742 | CLASS As | | 743 +--+--+--+--+--+--+- | | 744 | RDLEN Necessary | | 745 +--+--+--+--+--+--+- | | 746 \ RDATA \ / 747 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 749 Figure 2 751 The MESSAGE ID field MUST be set to a unique value, that the server 752 is not currently using for any other active outgoing request that it 753 has sent on this connection. The MESSAGE ID in the outgoing PUSH 754 message is selected by the server and has no relationship to the 755 MESSAGE ID in any of the client subscriptions it may relate to. In 756 the PUSH response the client MUST echo back the MESSAGE ID value 757 unchanged. 759 The other header fields MUST be set as described in the DNS Stateful 760 Operations specification [StatefulOp]. The DNS Opcode is the 761 Stateful Operations Opcode (tentatively 6). The four count fields 762 MUST be zero, and the corresponding four sections MUST be empty 763 (i.e., absent). 765 The SSOP-TYPE is PUSH (tentatively 0x41). The SSOP-LENGTH is the 766 length of the SSOP-DATA that follows, which specifies the changes 767 being communicated. 769 The SSOP-DATA contains one or more Update records. A PUSH Message 770 MUST contain at least one Update record. If a PUSH Message is 771 received that contains no Update records, this is a fatal error, and 772 the receiver MUST immediately terminate the connection with a TCP RST 773 (or equivalent for other protocols). The Update records are 774 formatted in the customary way for Resource Records in DNS messages 775 with the stipulation that DNS name compression is not permitted in 776 DNS Stateful Operations TLVs. Update records in a PUSH Message are 777 interpreted according to the same rules as for DNS Update [RFC2136] 778 messages, namely: 780 Delete all RRsets from a name: 781 TTL=0, CLASS=ANY, RDLENGTH=0, TYPE=ANY. 783 Delete an RRset from a name: 784 TTL=0, CLASS=ANY, RDLENGTH=0; 785 TYPE specifies the RRset being deleted. 787 Delete an individual RR from a name: 788 TTL=0, CLASS=NONE; 789 TYPE, RDLENGTH and RDATA specifies the RR being deleted. 791 Add to an RRset: 792 TTL, CLASS, TYPE, RDLENGTH and RDATA specifies the RR being added. 794 When processing the records received in a PUSH Message, the receiving 795 client MUST validate that the records being added or deleted 796 correspond with at least one currently active subscription on that 797 connection. Specifically, the record name MUST match the name given 798 in the SUBSCRIBE request, subject to the usual established DNS case- 799 insensitivity for US-ASCII letters. If the TYPE in the SUBSCRIBE 800 request was not ANY (255) then the TYPE of the record must match the 801 TYPE given in the SUBSCRIBE request. If the CLASS in the SUBSCRIBE 802 request was not ANY (255) then the CLASS of the record must match the 803 CLASS given in the SUBSCRIBE request. If a matching active 804 subscription on that connection is not found, then that individual 805 record addition/deletion is silently ignored. Processing of other 806 additions and deletions in this message is not affected. The TCP 807 connection is not closed. This is to allow for the unavoidable race 808 condition where a client sends an outbound UNSUBSCRIBE while inbound 809 PUSH messages for that subscription from the server are still in 810 flight. 812 In the case where a single change affects more than one active 813 subscription, only one PUSH message is sent. For example, a PUSH 814 message adding a given record may match both a SUBSCRIBE request with 815 the same TYPE and a different SUBSCRIBE request with TYPE=ANY. It is 816 not the case that two PUSH messages are sent because the new record 817 matches two active subscriptions. 819 The server SHOULD encode change notifications in the most efficient 820 manner possible. For example, when three AAAA records are deleted 821 from a given name, and no other AAAA records exist for that name, the 822 server SHOULD send a "delete an RRset from a name" PUSH message, not 823 three separate "delete an individual RR from a name" PUSH messages. 824 Similarly, when both an SRV and a TXT record are deleted from a given 825 name, and no other records of any kind exist for that name, the 826 server SHOULD send a "delete all RRsets from a name" PUSH message, 827 not two separate "delete an RRset from a name" PUSH messages. 829 A server SHOULD combine multiple change notifications in a single 830 PUSH message when possible, even if those change notifications apply 831 to different subscriptions. Conceptually, a PUSH message is a 832 connection-level mechanism, not a subscription-level mechanism. 834 Reception of a PUSH message by a client generates a PUSH response 835 back to the server. 837 The TTL of an added record is stored by the client and decremented as 838 time passes, with the caveat that for as long as a relevant 839 subscription is active, the TTL does not decrement below 1 second. 840 For as long as a relevant subscription remains active, the client 841 SHOULD assume that when a record goes away the server will notify it 842 of that fact. Consequently, a client does not have to poll to verify 843 that the record is still there. Once a subscription is cancelled 844 (individually, or as a result of the TCP connection being closed) 845 record aging resumes and records are removed from the local cache 846 when their TTL reaches zero. 848 6.3.2. PUSH Response 850 Each PUSH message generates exactly one PUSH response from the 851 receiver. 853 A PUSH response message begins with the standard DNS Stateful 854 Operations 12-byte header [StatefulOp], possibly followed by one or 855 more optional Modifier TLVs. 857 The MESSAGE ID field MUST echo the value given in the ID field of the 858 PUSH message. 860 A PUSH response message MUST NOT contain a Stateful Operations 861 Operation TLV. The Stateful Operations Operation TLV is NOT copied 862 from the PUSH message. 864 In a PUSH response the RCODE MUST be zero. Receiving a PUSH response 865 with a nonzero RCODE is a fatal error, and the receiver MUST 866 immediately terminate the connection with a TCP RST (or equivalent 867 for other protocols). 869 6.4. DNS Push Notification UNSUBSCRIBE 871 To cancel an individual subscription without closing the entire 872 connection, the client sends an UNSUBSCRIBE message over the 873 established TCP connection to the server. The UNSUBSCRIBE message is 874 encoded in a DNS Stateful Operations [StatefulOp] message. This 875 specification defines a DNS Stateful Operations TLV for DNS Push 876 Notification UNSUBSCRIBE Requests/Responses (tentatively Stateful 877 Operations Type Code 0x42). 879 A server MUST NOT initiate an UNSUBSCRIBE request. If a server does 880 send a UNSUBSCRIBE request over the connection initiated by a client, 881 it is an error and the client should acknowledge the request with the 882 error response RCODE NOTAUTH (Not Authoritative). 884 6.4.1. UNSUBSCRIBE Request 886 An UNSUBSCRIBE request message begins with the standard DNS Stateful 887 Operations 12-byte header [StatefulOp], followed by the UNSUBSCRIBE 888 TLV. 890 1 1 1 1 1 1 891 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 892 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 893 | MESSAGE ID | 894 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 895 |QR| Opcode | Z | RCODE | 896 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 897 | QDCOUNT (MUST BE ZERO) | 898 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 899 | ANCOUNT (MUST BE ZERO) | 900 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 901 | NSCOUNT (MUST BE ZERO) | 902 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 903 | ARCOUNT (MUST BE ZERO) | 904 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 905 | SSOP-TYPE = UNSUBSCRIBE (tentatively 0x42) | 906 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 907 | SSOP-LENGTH (2 octets) | 908 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 909 | SUBSCRIBE MESSAGE ID | SSOP-DATA 910 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 912 Figure 3 914 In the UNSUBSCRIBE TLV the SSOP-TYPE is UNSUBSCRIBE (tentatively 915 0x42). The SSOP-LENGTH is 2 octets. 917 The SSOP-DATA contains the MESSAGE ID field of the value given in the 918 ID field of an active SUBSCRIBE request. This is how the server 919 knows which SUBSCRIBE request is being cancelled. After receipt of 920 the UNSUBSCRIBE request, the SUBSCRIBE request is no longer active. 921 If a server receives an UNSUBSCRIBE message where the MESSAGE ID does 922 not match the ID of an active SUBSCRIBE request the server MUST 923 return a response containing RCODE = 3 (NXDOMAIN). 925 It is allowable for the client to issue an UNSUBSCRIBE request for a 926 previous SUBSCRIBE request for which the client has not yet received 927 a SUBSCRIBE response. This is to allow for the case where a client 928 starts and stops a subscription in less than the round-trip time to 929 the server. The client is NOT required to wait for the SUBSCRIBE 930 response before issuing the UNSUBSCRIBE request. A consequence of 931 this is that if the client issues an UNSUBSCRIBE request for an as- 932 yet unacknowledged SUBSCRIBE request, and the SUBSCRIBE request is 933 subsequently unsuccessful for some reason, then when the UNSUBSCRIBE 934 request is eventually processed it will be an UNSUBSCRIBE request for 935 a nonexistent subscription, which will result NXDOMAIN response. 937 6.4.2. UNSUBSCRIBE Response 939 Each UNSUBSCRIBE request generates exactly one UNSUBSCRIBE response 940 from the server. 942 An UNSUBSCRIBE response message begins with the standard DNS Stateful 943 Operations 12-byte header [StatefulOp], possibly followed by one or 944 more optional Modifier TLVs, such as a Retry Delay Modifier TLV. 946 The MESSAGE ID field MUST echo the value given in the ID field of the 947 UNSUBSCRIBE request. This is how the client knows which request is 948 being responded to. 950 An UNSUBSCRIBE response message MUST NOT contain a Stateful 951 Operations Operation TLV. The Stateful Operations Operation TLV is 952 NOT copied from the UNSUBSCRIBE request. 954 In the UNSUBSCRIBE response the RCODE indicates whether or not the 955 unsubscribe request was successful. Supported RCODEs are as follows: 957 +------------+-------+----------------------------------------------+ 958 | Mnemonic | Value | Description | 959 +------------+-------+----------------------------------------------+ 960 | NOERROR | 0 | UNSUBSCRIBE successful. | 961 | FORMERR | 1 | Server failed to process request due to a | 962 | | | malformed request. | 963 | NXDOMAIN | 3 | Specified subscription does not exist. | 964 | NOTIMP | 4 | Server does not recognize DNS Stateful | 965 | | | Operations Opcode. | 966 | SSOPNOTIMP | 11 | UNSUBSCRIBE operation not supported. | 967 +------------+-------+----------------------------------------------+ 969 UNSUBSCRIBE Response codes 971 This document specifies only these RCODE values for UNSUBSCRIBE 972 Responses. Servers sending UNSUBSCRIBE Responses SHOULD use one of 973 these values. However, future circumstances may create situations 974 where other RCODE values are appropriate in UNSUBSCRIBE Responses, so 975 clients MUST be prepared to accept UNSUBSCRIBE Responses with any 976 RCODE value. 978 Having being successfully revoked with a correctly-formatted 979 UNSUBSCRIBE message (resulting in a response with RCODE NOERROR) the 980 previously referenced subscription is no longer active and the server 981 MAY discard the state associated with it immediately, or later, at 982 the server's discretion. 984 Nonzero RCODE values signal some kind of error. 986 RCODE value FORMERR indicates a message format error. 988 RCODE value NXDOMAIN indicates a MESSAGE ID that does not correspond 989 to any active subscription. 991 RCODE values NOTIMP and SSOPNOTIMP should not occur in practice. 993 A server would only generate NOTIMP if it did not support Stateful 994 Operations, and if the server does not support Stateful Operations 995 then it should not be possible for a client to have an active 996 subscription to cancel. 998 Similarly, a server would only generate SSOPNOTIMP if it did not 999 support Push Notifications, and if the server does not support Push 1000 Notifications then it should not be possible for a client to have an 1001 active subscription to cancel. 1003 Nonzero RCODE values other than NXDOMAIN indicate a serious problem 1004 with the client. After sending an error response other than 1005 NXDOMAIN, the server SHOULD send a DNS Stateful Operations Retry 1006 Delay Operation TLV and then close the TCP connection, as described 1007 in the DNS Stateful Operations specification [StatefulOp]. 1009 6.5. DNS Push Notification RECONFIRM 1011 Sometimes, particularly when used with a Discovery Proxy [DisProx], a 1012 DNS Zone may contain stale data. When a client encounters data that 1013 it believe may be stale (e.g., an SRV record referencing a target 1014 host+port that is not responding to connection requests) the client 1015 can send a RECONFIRM request to ask the server to re-verify that the 1016 data is still valid. For a Discovery Proxy, this causes it to issue 1017 new Multicast DNS requests to ascertain whether the target device is 1018 still present. For other types of DNS server, the RECONFIRM 1019 operation is currently undefined, and SHOULD result in a NOERROR 1020 response, but otherwise need not cause any action to occur. Frequent 1021 RECONFIRM operations may be a sign of network unreliability, or some 1022 kind of misconfiguration, so RECONFIRM operations MAY be logged or 1023 otherwise communicated to a human administrator to assist in 1024 detecting, and remedying, such network problems. 1026 If, after receiving a valid RECONFIRM request, the server determines 1027 that the disputed records are in fact no longer valid, then 1028 subsequent DNS PUSH Messages will be generated to inform interested 1029 clients. Thus, one client discovering that a previously-advertised 1030 device (like a network printer) is no longer present has the side 1031 effect of informing all other interested clients that the device in 1032 question is now gone. 1034 6.5.1. RECONFIRM Request 1036 A RECONFIRM request message begins with the standard DNS Stateful 1037 Operations 12-byte header [StatefulOp], followed by the RECONFIRM 1038 TLV. A RECONFIRM request message is illustrated below: 1040 1 1 1 1 1 1 1041 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1042 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1043 | MESSAGE ID | 1044 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1045 |QR| Opcode | Z | RCODE | 1046 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1047 | QDCOUNT (MUST BE ZERO) | 1048 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1049 | ANCOUNT (MUST BE ZERO) | 1050 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1051 | NSCOUNT (MUST BE ZERO) | 1052 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1053 | ARCOUNT (MUST BE ZERO) | 1054 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1055 | SSOP-TYPE = RECONFIRM (tentatively 0x43) | 1056 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1057 | SSOP-LENGTH (number of octets in SSOP-DATA) | 1058 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ 1059 \ NAME \ \ 1060 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1061 | TYPE | | 1062 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1063 | CLASS | > SSOP-DATA 1064 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1065 | RDLEN | | 1066 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1067 \ RDATA \ / 1068 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / 1070 Figure 4 1072 The MESSAGE ID field MUST be set to a unique value, that the client 1073 is not using for any other active operation on this connection. For 1074 the purposes here, a MESSAGE ID is in use on this connection if the 1075 client has used it in a request for which it has not yet received a 1076 response, or if the client has used it for a subscription which it 1077 has not yet cancelled using UNSUBSCRIBE. In the RECONFIRM response 1078 the server MUST echo back the MESSAGE ID value unchanged. 1080 The other header fields MUST be set as described in the DNS Stateful 1081 Operations specification [StatefulOp]. The DNS Opcode is the 1082 Stateful Operations Opcode (tentatively 6). The four count fields 1083 MUST be zero, and the corresponding four sections MUST be empty 1084 (i.e., absent). 1086 The SSOP-TYPE is RECONFIRM (tentatively 0x43). The SSOP-LENGTH is 1087 the length of the data that follows, which specifies the name, type, 1088 class, and content of the record being disputed. 1090 The SSOP-DATA for a RECONFIRM request MUST contain exactly one 1091 record. The SSOP-DATA for a RECONFIRM request has no count field to 1092 specify more than one record. Since RECONFIRM requests are sent over 1093 TCP, multiple RECONFIRM request messages can be concatenated in a 1094 single TCP stream and packed efficiently into TCP segments. 1096 TYPE MUST NOT be the value ANY (255) and CLASS MUST NOT be the value 1097 ANY (255). 1099 DNS wildcarding is not supported. That is, a wildcard ("*") in a 1100 RECONFIRM message matches only a literal wildcard character ("*") in 1101 the zone, and nothing else. 1103 Aliasing is not supported. That is, a CNAME in a RECONFIRM message 1104 matches only a literal CNAME record in the zone, and nothing else. 1106 6.5.2. RECONFIRM Response 1108 Each RECONFIRM request generates exactly one RECONFIRM response from 1109 the server. 1111 A RECONFIRM response message begins with the standard DNS Stateful 1112 Operations 12-byte header [StatefulOp], possibly followed by one or 1113 more optional Modifier TLVs, such as a Retry Delay Modifier TLV. 1115 The MESSAGE ID field MUST echo the value given in the ID field of the 1116 RECONFIRM request. This is how the client knows which request is 1117 being responded to. 1119 A RECONFIRM response message MUST NOT contain a Stateful Operations 1120 Operation TLV. The Stateful Operations Operation TLV is NOT copied 1121 from the RECONFIRM request. 1123 In the RECONFIRM response the RCODE confirms receipt of the 1124 reconfirmation request. Supported RCODEs are as follows: 1126 +------------+-------+----------------------------------------------+ 1127 | Mnemonic | Value | Description | 1128 +------------+-------+----------------------------------------------+ 1129 | NOERROR | 0 | RECONFIRM accepted. | 1130 | FORMERR | 1 | Server failed to process request due to a | 1131 | | | malformed request. | 1132 | SERVFAIL | 2 | Server failed to process request due to a | 1133 | | | problem with the server. | 1134 | NXDOMAIN | 3 | NOT APPLICABLE. DNS Push Notification | 1135 | | | servers MUST NOT return NXDOMAIN errors in | 1136 | | | response to RECONFIRM requests. | 1137 | NOTIMP | 4 | Server does not recognize DNS Stateful | 1138 | | | Operations Opcode. | 1139 | REFUSED | 5 | Server refuses to process request for policy | 1140 | | | or security reasons. | 1141 | NOTAUTH | 9 | Server is not authoritative for the | 1142 | | | requested name. | 1143 | SSOPNOTIMP | 11 | RECONFIRM operation not supported. | 1144 +------------+-------+----------------------------------------------+ 1146 RECONFIRM Response codes 1148 This document specifies only these RCODE values for RECONFIRM 1149 Responses. Servers sending RECONFIRM Responses SHOULD use one of 1150 these values. However, future circumstances may create situations 1151 where other RCODE values are appropriate in RECONFIRM Responses, so 1152 clients MUST be prepared to accept RECONFIRM Responses with any RCODE 1153 value. 1155 Nonzero RCODE values signal some kind of error. 1157 RCODE value FORMERR indicates a message format error, for example 1158 TYPE or CLASS being ANY (255). 1160 RCODE value SERVFAIL indicates that the server has exhausted its 1161 resources or other serious problem occurred. 1163 RCODE values NOTIMP indicates that the server does not support 1164 Stateful Operations, and Stateful Operations is required for 1165 RECONFIRM requests. 1167 RCODE value REFUSED indicates that the server supports RECONFIRM 1168 requests but is currently not configured to accept them from this 1169 client. 1171 RCODE value NOTAUTH indicates that the server is not authoritative 1172 for the requested name, and can do nothing to remedy the apparent 1173 error. Note that there may be future cases in which a server is able 1174 to pass on the RECONFIRM request to the ultimate source of the 1175 information, and in these cases the server should return NOERROR. 1177 RCODE value SSOPNOTIMP indicates that the server does not support 1178 RECONFIRM requests. 1180 Nonzero RCODE values SERVFAIL, REFUSED and SSOPNOTIMP are benign from 1181 the client's point of view. The client may log them to aid in 1182 debugging, but otherwise they require no special action. 1184 Nonzero RCODE values other than these three indicate a serious 1185 problem with the client. After sending an error response other than 1186 one of these three, the server SHOULD send a DNS Stateful Operations 1187 Retry Delay Operation TLV and then close the TCP connection, as 1188 described in the DNS Stateful Operations specification [StatefulOp]. 1190 6.6. Client-Initiated Termination 1192 An individual subscription is terminated by sending an UNSUBSCRIBE 1193 TLV for that specific subscription, or all subscriptions can be 1194 cancelled at once by the client closing the connection. When a 1195 client terminates an individual subscription (via UNSUBSCRIBE) or all 1196 subscriptions on that connection (by closing the connection) it is 1197 signaling to the server that it is longer interested in receiving 1198 those particular updates. It is informing the server that the server 1199 may release any state information it has been keeping with regards to 1200 these particular subscriptions. 1202 After terminating its last subscription on a connection via 1203 UNSUBSCRIBE, a client MAY close the connection immediately, or it may 1204 keep it open if it anticipates performing further operations on that 1205 connection in the future. If a client wishes to keep an idle 1206 connection open, it MUST respect the maximum idle time required by 1207 the server [StatefulOp]. 1209 If a client plans to terminate one or more subscriptions on a 1210 connection and doesn't intend to keep that connection open, then as 1211 an efficiency optimization it MAY instead choose to simply close the 1212 connection, which implicitly terminates all subscriptions on that 1213 connection. This may occur because the client computer is being shut 1214 down, is going to sleep, the application requiring the subscriptions 1215 has terminated, or simply because the last active subscription on 1216 that connection has been cancelled. 1218 When closing a connection, a client will generally do an abortive 1219 disconnect, sending a TCP RST. This immediately discards all 1220 remaining inbound and outbound data, which is appropriate if the 1221 client no longer has any interest in this data. In the BSD Sockets 1222 API, sending a TCP RST is achieved by setting the SO_LINGER option 1223 with a time of 0 seconds and then closing the socket. 1225 If a client has performed operations on this connection that it would 1226 not want lost (like DNS updates) then the client SHOULD do an orderly 1227 disconnect, sending a TCP FIN. In the BSD Sockets API, sending a TCP 1228 FIN is achieved by calling "shutdown(s,SHUT_WR)" and keeping the 1229 socket open until all remaining data has been read from it. 1231 7. Security Considerations 1233 The Strict Privacy Usage Profile for DNS over TLS is strongly 1234 recommended for DNS Push Notifications as defined in Authentication 1235 and (D)TLS Profile for DNS-over-(D)TLS 1236 [I-D.ietf-dprive-dtls-and-tls-profiles]. The Opportunistic Privacy 1237 Usage Profile is permissible as a way to support incremental 1238 deployment of security capabilities. Cleartext connections for DNS 1239 Push Notifications are not permissible. 1241 DNSSEC is RECOMMENDED for the authentication of DNS Push Notification 1242 servers. TLS alone does not provide complete security. TLS 1243 certificate verification can provide reasonable assurance that the 1244 client is really talking to the server associated with the desired 1245 host name, but since the desired host name is learned via a DNS SRV 1246 query, if the SRV query is subverted then the client may have a 1247 secure connection to a rogue server. DNSSEC can provided added 1248 confidence that the SRV query has not been subverted. 1250 7.1. Security Services 1252 It is the goal of using TLS to provide the following security 1253 services: 1255 Confidentiality: All application-layer communication is encrypted 1256 with the goal that no party should be able to decrypt it except 1257 the intended receiver. 1259 Data integrity protection: Any changes made to the communication in 1260 transit are detectable by the receiver. 1262 Authentication: An end-point of the TLS communication is 1263 authenticated as the intended entity to communicate with. 1265 Deployment recommendations on the appropriate key lengths and cypher 1266 suites are beyond the scope of this document. Please refer to TLS 1267 Recommendations [RFC7525] for the best current practices. Keep in 1268 mind that best practices only exist for a snapshot in time and 1269 recommendations will continue to change. Updated versions or errata 1270 may exist for these recommendations. 1272 7.2. TLS Name Authentication 1274 As described in Section 6.1, the client discovers the DNS Push 1275 Notification server using an SRV lookup for the record name 1276 "_dns-push-tls._tcp.". The server connection endpoint SHOULD 1277 then be authenticated using DANE TLSA records for the associated SRV 1278 record. This associates the target's name and port number with a 1279 trusted TLS certificate [RFC7673]. This procedure uses the TLS Sever 1280 Name Indication (SNI) extension [RFC6066] to inform the server of the 1281 name the client has authenticated through the use of TLSA records. 1282 Therefore, if the SRV record passes DNSSEC validation and a TLSA 1283 record matching the target name is useable, an SNI extension must be 1284 used for the target name to ensure the client is connecting to the 1285 server it has authenticated. If the target name does not have a 1286 usable TLSA record, then the use of the SNI extension is optional. 1288 See Authentication and (D)TLS Profile for DNS-over-(D)TLS 1289 [I-D.ietf-dprive-dtls-and-tls-profiles] for more information on 1290 authenticating domain names. Also note that a DNS Push server is an 1291 authoritative server and a DNS Push client is a standard DNS client. 1292 While the terminology in Authentication and (D)TLS Profile for DNS- 1293 over-(D)TLS [I-D.ietf-dprive-dtls-and-tls-profiles] explicitly states 1294 it does not apply to authoritative servers, it does in this case 1295 apply to DNS Push Notification clients and servers. 1297 7.3. TLS Compression 1299 In order to reduce the chances of compression-related attacks, TLS- 1300 level compression SHOULD be disabled when using TLS versions 1.2 and 1301 earlier. In the draft version of TLS 1.3 [I-D.ietf-tls-tls13], TLS- 1302 level compression has been removed completely. 1304 7.4. TLS Session Resumption 1306 TLS Session Resumption is permissible on DNS Push Notification 1307 servers. The server may keep TLS state with Session IDs [RFC5246] or 1308 operate in stateless mode by sending a Session Ticket [RFC5077] to 1309 the client for it to store. However, once the connection is closed, 1310 any existing subscriptions will be dropped. When the TLS session is 1311 resumed, the DNS Push Notification server will not have any 1312 subscription state and will proceed as with any other new connection. 1313 Use of TLS Session Resumption allows a new TLS connection to be set 1314 up more quickly, but the client will still have to recreate any 1315 desired subscriptions. 1317 8. IANA Considerations 1319 This document defines the service name: "_dns-push-tls._tcp". 1320 It is only applicable for the TCP protocol. 1321 This name is to be published in the IANA Service Name Registry 1322 [RFC6335][SN]. 1324 This document defines four DNS Stateful Operations TLV types: 1325 SUBSCRIBE with (tentative) value 0x40 (64), PUSH with (tentative) 1326 value 0x41 (65), UNSUBSCRIBE with (tentative) value 0x42 (66), and 1327 RECONFIRM with (tentative) value 0x43 (67). 1329 9. Acknowledgements 1331 The authors would like to thank Kiren Sekar and Marc Krochmal for 1332 previous work completed in this field. 1334 This draft has been improved due to comments from Ran Atkinson, Tim 1335 Chown, Mark Delany, Ralph Droms, Bernie Volz, Jan Komissar, Manju 1336 Shankar Rao, Markus Stenberg, Dave Thaler, Soraia Zlatkovic, Sara 1337 Dickinson, and Andrew Sullivan. 1339 10. References 1341 10.1. Normative References 1343 [I-D.ietf-tls-tls13] 1344 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1345 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 1346 July 2017. 1348 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1349 DOI 10.17487/RFC0768, August 1980, . 1352 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1353 RFC 793, DOI 10.17487/RFC0793, September 1981, 1354 . 1356 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1357 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1358 . 1360 [RFC1035] Mockapetris, P., "Domain names - implementation and 1361 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1362 November 1987, . 1364 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1365 Application and Support", STD 3, RFC 1123, 1366 DOI 10.17487/RFC1123, October 1989, . 1369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1370 Requirement Levels", BCP 14, RFC 2119, 1371 DOI 10.17487/RFC2119, March 1997, . 1374 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1375 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1376 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1377 . 1379 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1380 specifying the location of services (DNS SRV)", RFC 2782, 1381 DOI 10.17487/RFC2782, February 2000, . 1384 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1385 (TLS) Protocol Version 1.2", RFC 5246, 1386 DOI 10.17487/RFC5246, August 2008, . 1389 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1390 Extensions: Extension Definitions", RFC 6066, 1391 DOI 10.17487/RFC6066, January 2011, . 1394 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1395 Cheshire, "Internet Assigned Numbers Authority (IANA) 1396 Procedures for the Management of the Service Name and 1397 Transport Protocol Port Number Registry", BCP 165, 1398 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1399 . 1401 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1402 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1403 April 2013, . 1405 [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 1406 Based Authentication of Named Entities (DANE) TLSA Records 1407 with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 1408 2015, . 1410 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 1411 D. Wessels, "DNS Transport over TCP - Implementation 1412 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 1413 . 1415 [SN] "Service Name and Transport Protocol Port Number 1416 Registry", . 1419 [StatefulOp] 1420 Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 1421 Mankin, A., and T. Pusateri, "DNS Stateful Operations", 1422 draft-ietf-dnsop-session-signal-04 (work in progress), 1423 September 2017. 1425 10.2. Informative References 1427 [DisProx] Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service 1428 Discovery", draft-ietf-dnssd-hybrid-07 (work in progress), 1429 September 2017. 1431 [I-D.dukkipati-tcpm-tcp-loss-probe] 1432 Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, 1433 "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of 1434 Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work 1435 in progress), February 2013. 1437 [I-D.ietf-dprive-dtls-and-tls-profiles] 1438 Dickinson, S., Gillmor, D., and T. Reddy, "Usage and 1439 (D)TLS Profiles for DNS-over-(D)TLS", draft-ietf-dprive- 1440 dtls-and-tls-profiles-11 (work in progress), September 1441 2017. 1443 [I-D.sekar-dns-llq] 1444 Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- 1445 llq-01 (work in progress), August 2006. 1447 [IPJ.9-4-TCPSYN] 1448 Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The 1449 Internet Protocol Journal, Cisco Systems, Volume 9, 1450 Number 4, December 2006. 1452 [obs] "Observer Pattern", . 1455 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1456 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1457 . 1459 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1460 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 1461 December 2005, . 1463 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 1464 RFC 4953, DOI 10.17487/RFC4953, July 2007, 1465 . 1467 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1468 "Transport Layer Security (TLS) Session Resumption without 1469 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1470 January 2008, . 1472 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 1473 "Understanding Apple's Back to My Mac (BTMM) Service", 1474 RFC 6281, DOI 10.17487/RFC6281, June 2011, 1475 . 1477 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1478 DOI 10.17487/RFC6762, February 2013, . 1481 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1482 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1483 . 1485 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1486 "TCP Extensions for Multipath Operation with Multiple 1487 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1488 . 1490 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1491 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1492 . 1494 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1495 "Recommendations for Secure Use of Transport Layer 1496 Security (TLS) and Datagram Transport Layer Security 1497 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1498 2015, . 1500 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1501 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 1502 2015, . 1504 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1505 and P. Hoffman, "Specification for DNS over Transport 1506 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1507 2016, . 1509 [XEP0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 1510 Subscribe", XSF XEP 0060, July 2010. 1512 Authors' Addresses 1514 Tom Pusateri 1515 Unaffiliated 1516 Raleigh, NC 27608 1517 USA 1519 Phone: +1 919 867 1330 1520 Email: pusateri@bangj.com 1522 Stuart Cheshire 1523 Apple Inc. 1524 1 Infinite Loop 1525 Cupertino, CA 95014 1526 USA 1528 Phone: +1 408 974 3207 1529 Email: cheshire@apple.com