--- 1/draft-ietf-dnssd-push-11.txt 2017-07-03 17:14:18.176578640 -0700 +++ 2/draft-ietf-dnssd-push-12.txt 2017-07-03 17:14:18.252580462 -0700 @@ -1,46 +1,47 @@ Internet Engineering Task Force T. Pusateri Internet-Draft Seeking affiliation Intended status: Standards Track S. Cheshire -Expires: December 19, 2017 Apple Inc. - June 17, 2017 +Expires: January 3, 2018 Apple Inc. + July 2, 2017 DNS Push Notifications - draft-ietf-dnssd-push-11 + draft-ietf-dnssd-push-12 Abstract The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning - the updated results when polled. But there exists no mechanism - for a client to be asynchronously notified when these changes occur. - This document defines a mechanism for a client to be notified - of such changes to DNS records, called DNS Push Notifications. + the updated results when polled, as long as the polling rate is not + too high. But there exists no mechanism for a client to be + asynchronously notified when these changes occur. This document + defines a mechanism for a client to be notified of such changes to + DNS records, called DNS Push Notifications. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 19, 2017. + This Internet-Draft will expire on January 3, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -53,44 +54,44 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. State Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 - 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 11 - 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 12 - 6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 15 - 6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 18 - 6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 19 - 6.3.2. PUSH Response . . . . . . . . . . . . . . . . . . . . 22 - 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 23 - 6.4.1. UNSUBSCRIBE Request . . . . . . . . . . . . . . . . . 24 - 6.4.2. UNSUBSCRIBE Response . . . . . . . . . . . . . . . . 26 - 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 28 - 6.5.1. RECONFIRM Request . . . . . . . . . . . . . . . . . . 29 - 6.5.2. RECONFIRM Response . . . . . . . . . . . . . . . . . 31 - 6.6. Client-Initiated Termination . . . . . . . . . . . . . . 33 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 - 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 34 - 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 34 - 7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 35 - 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 35 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 - 10.2. Informative References . . . . . . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 12 + 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 13 + 6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 16 + 6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 19 + 6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20 + 6.3.2. PUSH Response . . . . . . . . . . . . . . . . . . . . 23 + 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 24 + 6.4.1. UNSUBSCRIBE Request . . . . . . . . . . . . . . . . . 25 + 6.4.2. UNSUBSCRIBE Response . . . . . . . . . . . . . . . . 27 + 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 29 + 6.5.1. RECONFIRM Request . . . . . . . . . . . . . . . . . . 30 + 6.5.2. RECONFIRM Response . . . . . . . . . . . . . . . . . 32 + 6.6. Client-Initiated Termination . . . . . . . . . . . . . . 34 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 + 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 35 + 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 35 + 7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 36 + 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 36 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 10.2. Informative References . . . . . . . . . . . . . . . . . 39 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction DNS records may be updated using DNS Update [RFC2136]. Other mechanisms such as a Discovery Proxy [DisProx] can also generate changes to a DNS zone. This document specifies a protocol for DNS clients to subscribe to receive asynchronous notifications of changes to RRSets of interest. It is immediately relevant in the case of DNS Service Discovery [RFC6763] but is not limited to that use case, and provides a general DNS mechanism for DNS record change notifications. @@ -122,28 +123,29 @@ for all group members to receive. Therefore, Multicast DNS already has asynchronous change notification capability. However, when DNS Service Discovery [RFC6763] is used across a wide area network using Unicast DNS (possibly facilitated via a Discovery Proxy [DisProx]) it would be beneficial to have an equivalent capability for Unicast DNS, to allow clients to learn about DNS record changes in a timely manner without polling. The DNS Long-Lived Queries (LLQ) [I-D.sekar-dns-llq] mechanism is an existing deployed solution to provide asynchronous change - notifications, used by Apple's Back to My Mac Service [RFC6281]. - Back to My Mac was designed in an era when the data centre operations - staff asserted that it was impossible for a server to handle large - numbers of mostly-idle TCP connections, so LLQ had to defined as a - UDP-based protocol, effectively replicating much of TCP's connection - state management logic in user space, and creating its own poor - imitations of existing TCP features like the three-way handshake, - flow control, and reliability. + notifications, used by Apple's Back to My Mac Service [RFC6281] + introduced in Mac OS X 10.5 Leopard in 2007. Back to My Mac was + designed in an era when the data centre operations staff asserted + that it was impossible for a server to handle large numbers of + mostly-idle TCP connections, so LLQ had to defined as a UDP-based + protocol, effectively replicating much of TCP's connection state + management logic in user space, and creating its own poor imitations + of existing TCP features like the three-way handshake, flow control, + and reliability. This document builds on experience gained with the LLQ protocol, with an improved design. Instead of using UDP, this specification uses TCP, and therefore doesn't need to reinvent existing TCP functionality. Using TCP also gives long-lived low-traffic connections better longevity through NAT gateways without resorting to excessive keepalive traffic. Instead of inventing a new vocabulary of messages to communicate DNS zone changes as LLQ did, this specification adopts the syntax and semantics of DNS Update messages [RFC2136]. @@ -247,38 +249,38 @@ 4. Transport Implementations of DNS Update [RFC2136] MAY use either User Datagram Protocol (UDP) [RFC0768] or Transmission Control Protocol (TCP) [RFC0793] as the transport protocol, in keeping with the historical precedent that DNS queries must first be sent over UDP [RFC1123]. This requirement to use UDP has subsequently been relaxed [RFC7766]. In keeping with the more recent precedent, DNS Push Notification is defined only for TCP. DNS Push Notification clients MUST use TLS - over TCP, see RFC 7858 [RFC7858]. + over TCP [RFC7858]. Connection setup over TCP ensures return reachability and alleviates concerns of state overload at the server through anonymous subscriptions. All subscribers are guaranteed to be reachable by the server by virtue of the TCP three-way handshake. Flooding attacks are possible with any protocol, and a benefit of TCP is that there are already established industry best practices to guard against SYN flooding and similar attacks [IPJ.9-4-TCPSYN] [RFC4953]. Use of TCP also allows DNS Push Notifications to take advantage of current and future developments in TCP, such as Multipath TCP (MPTCP) [RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP) [I-D.dukkipati-tcpm-tcp-loss-probe], and so on. Transport Layer Security (TLS) [RFC5246] is well understood and deployed across many protocols running over TCP. It is designed to - prevent eavesdropping, tampering, or message forgery. TLS is + prevent eavesdropping, tampering, and message forgery. TLS is REQUIRED for every connection between a client subscriber and server in this protocol specification. Additional security measures such as client authentication during TLS negotiation MAY also be employed to increase the trust relationship between client and server. 5. State Considerations Each DNS Push Notification server is capable of handling some finite number of Push Notification subscriptions. This number will vary from server to server and is based on physical machine @@ -337,49 +339,59 @@ client while the client's UNSUBSCRIBE message cancelling that subscription is simultaneously in flight from client to server. The exchange between client and server terminates when either end closes the TCP connection with a TCP FIN or RST. 6.1. Discovery The first step in DNS Push Notification subscription is to discover an appropriate DNS server that supports DNS Push Notifications for - the desired zone. The client MUST also determine which TCP port on - the server is listening for connections, which need not be (and often - is not) the typical TCP port 53 used for conventional DNS, or TCP - port 853 used for DNS over TLS [RFC7858]. + the desired zone. + + The client begins by opening a DNS Session to its normal configured + DNS recursive resolver and requesting a Push Notification + subscription. If this is successful, then the recursive resolver + will make appropriate Push Notification subscriptions on the client's + behalf, and the client will recieve appropriate results. If the + recursive resolver does not support Push Notification subscriptions, + then it will return an error code, and the client should proceed to + discover the appropriate server to talk to directly. The client MUST + also determine which TCP port on the server is listening for + connections, which need not be (and often is not) the typical TCP + port 53 used for conventional DNS, or TCP port 853 used for DNS over + TLS [RFC7858]. 1. The client begins the discovery by sending a DNS query to its local resolver, with record type SOA [RFC1035] for the record to which it wishes to subscribe. As an example, if it wishes to subscribe to PTR records with the name _printers._tcp.foo.example.com, it sends an SOA query for _printers._tcp.foo.example.com. The goal is to determine the - authoritative server for foo.example.com. + authoritative server for _printers._tcp.foo.example.com. 2. If the SOA record exists as exactly specified in the query, it is expected to be returned in the Answer section with a NOERROR response code. If the exact SOA record does not exist, the client may get back a NOERROR/NODATA response or it may get back a NXDOMAIN/Name Error response. This depends on the resolver implementation and whether the domain exists. The client is looking for an SOA record to be returned in either the Answer section or the Authority section with a NOERROR response code. - If the client receives an NXDOMAIN/Name Error response code, it - should strip the leading label from the query name and if the - resulting name has at least one label in it, the client should - send a new SOA query, repeating this until a NOERROR response - code is received or the query name is empty. In the case of an - empty name, the client may retry the operation at a later time, - of the client's choosing, such after a change in network - attachment. + If the client receives an NXDOMAIN/Name Error response code or a + response containing no SOA record, it should strip the leading + label from the query name and if the resulting name has at least + one label in it, the client should send a new SOA query, + repeating this until a NOERROR response code is received or the + query name is empty. In the case of an empty name, the client + may retry the operation at a later time, of the client's + choosing, such after a change in network attachment. 3. In the example above, if an SOA record query is sent for _printers._tcp.foo.example.com and an NXDOMAIN/Name Error is returned with an SOA record in the Authority section for foo.example.com, the client should strip the leading label and query an SOA record for _tcp.foo.example.com. If a NOERROR/ NODATA response is received with an SOA record in the Authority section for foo.example.com, this is sufficent. If an NXDOMAIN/ Name Error response is received, the client should again strip the leading label and query an SOA record for foo.example.com. @@ -493,43 +505,43 @@ is not using for any other active operation on this connection. For the purposes here, a MESSAGE ID is in use on this connection if the client has used it in a request for which it has not yet received a response, or if the client has used it for a subscription which it has not yet cancelled using UNSUBSCRIBE. In the SUBSCRIBE response the server MUST echo back the MESSAGE ID value unchanged. The other header fields MUST be set as described in the DNS Session Signaling specification [SessSig]. The DNS Opcode is the Session Signaling Opcode (tentatively 6). The four count fields MUST be - empty, and the corresponding four sections MUST be empty (i.e., + zero, and the corresponding four sections MUST be empty (i.e., absent). The SSOP-TYPE is SUBSCRIBE (tentatively 0x40). The SSOP-LENGTH is the length of the SSOP-DATA that follows, which specifies the name, type, and class of the record(s) being sought. The SSOP-DATA for a SUBSCRIBE request MUST contain exactly one question. The SSOP-DATA for a SUBSCRIBE request has no QDCOUNT field to specify more than one question. Since SUBSCRIBE requests are sent over TCP, multiple SUBSCRIBE request messages can be concatenated in a single TCP stream and packed efficiently into TCP segments. If accepted, the subscription will stay in effect until the client cancels the subscription using UNSUBSCRIBE or until the connection between the client and the server is closed. SUBSCRIBE requests on a given connection MUST be unique. A client MUST NOT send a SUBSCRIBE message that duplicates the NAME, TYPE and CLASS of an existing active subscription on that TLS/TCP connection. For the purpose of this matching, the established DNS case- - insensitivity for US-ASCII letters applies (e.g., "foo.com" and - "Foo.com" are the same). If a server receives such a duplicate + insensitivity for US-ASCII letters applies (e.g., "example.com" and + "Example.com" are the same). If a server receives such a duplicate SUBSCRIBE message this is an error and the server MUST immediately terminate the connection with a TCP RST (or equivalent for other protocols). DNS wildcarding is not supported. That is, a wildcard ("*") in a SUBSCRIBE message matches only a literal wildcard character ("*") in the zone, and nothing else. Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message matches only a literal CNAME record in the zone, and nothing else. @@ -606,21 +618,21 @@ these values. However, future circumstances may create situations where other RCODE values are appropriate in SUBSCRIBE Responses, so clients MUST be prepared to accept SUBSCRIBE Responses with any RCODE value. If the server sends a nonzero RCODE in the SUBSCRIBE response, either the client is (at least partially) misconfigured, the server resources are exhausted, or there is some other unknown failure on the server. In any case, the client shouldn't retry the subscription right away. Either end can terminate the connection, but the client - may want to try this subscription again or it may have other + may want to try this subscription again, or it may have other successful subscriptions that it doesn't want to abandon. If the server sends a nonzero RCODE then it SHOULD append a Retry Delay Modifier TLV [SessSig] to the response specifying a delay before the client attempts this operation again. Recommended values for the delay for different RCODE values are given below: For RCODE = 1 (FORMERR) the delay may be any value selected by the implementer. A value of five minutes is RECOMMENDED, to reduce the risk of high load from defective clients. @@ -668,21 +680,21 @@ value of 5 minutes is RECOMMENDED. For RCODE = 9 (NOTAUTH), the time delay applies to requests for other names falling within the same zone. Requests for names falling within other zones are not subject to the delay. For all other RCODEs the time delay applies to all subsequent requests to this server. After sending an error response the server MAY allow the connection to remain open, or MAY send a DNS Push Notification Retry Delay - Operation TLV asserting the client close the TCP connection, as + Operation TLV instructing the client to close the TCP connection, as described in the DNS Session Signaling specification [SessSig]. Clients MUST correctly handle both cases. 6.3. DNS Push Notification Updates Once a subscription has been successfully established, the server generates PUSH messages to send to the client as appropriate. In the case that the answer set was non-empty at the moment the subscription was established, an initial PUSH message will be sent immediately following the SUBSCRIBE Response. Subsequent changes to the answer @@ -740,21 +752,21 @@ is not currently using for any other active outgoing request that it has sent on this connection. The MESSAGE ID in the outgoing PUSH message is selected by the server and has no relationship to the MESSAGE ID in any of the client subscriptions it may relate to. In the PUSH response the client MUST echo back the MESSAGE ID value unchanged. The other header fields MUST be set as described in the DNS Session Signaling specification [SessSig]. The DNS Opcode is the Session Signaling Opcode (tentatively 6). The four count fields MUST be - empty, and the corresponding four sections MUST be empty (i.e., + zero, and the corresponding four sections MUST be empty (i.e., absent). The SSOP-TYPE is PUSH (tentatively 0x41). The SSOP-LENGTH is the length of the SSOP-DATA that follows, which specifies the changes being communicated. The SSOP-DATA contains one or more Update records. A PUSH Message MUST contain at least one Update record. If a PUSH Message is received that contains no Update records, this is a fatal error, and the receiver MUST immediately terminate the connection with a TCP RST @@ -833,21 +845,21 @@ record aging resumes and records are removed from the local cache when their TTL reaches zero. 6.3.2. PUSH Response Each PUSH message generates exactly one PUSH response from the receiver. A PUSH response message begins with the standard DNS Session Signaling 12-byte header [SessSig], possibly followed by one or more - optional Modifier TLVs, such as a Retry Delay Modifier TLV. + optional Modifier TLVs. The MESSAGE ID field MUST echo the value given in the ID field of the PUSH message. A PUSH response message MUST NOT contain a Session Signaling Operation TLV. The Session Signaling Operation TLV is NOT copied from the PUSH message. In a PUSH response the RCODE MUST be zero. Receiving a PUSH response with a nonzero RCODE is a fatal error, and the receiver MUST @@ -1060,21 +1072,21 @@ is not using for any other active operation on this connection. For the purposes here, a MESSAGE ID is in use on this connection if the client has used it in a request for which it has not yet received a response, or if the client has used it for a subscription which it has not yet cancelled using UNSUBSCRIBE. In the RECONFIRM response the server MUST echo back the MESSAGE ID value unchanged. The other header fields MUST be set as described in the DNS Session Signaling specification [SessSig]. The DNS Opcode is the Session Signaling Opcode (tentatively 6). The four count fields MUST be - empty, and the corresponding four sections MUST be empty (i.e., + zero, and the corresponding four sections MUST be empty (i.e., absent). The SSOP-TYPE is RECONFIRM (tentatively 0x43). The SSOP-LENGTH is the length of the data that follows, which specifies the name, type, class, and content of the record being disputed. The SSOP-DATA for a RECONFIRM request MUST contain exactly one record. The SSOP-DATA for a RECONFIRM request has no count field to specify more than one record. Since RECONFIRM requests are sent over TCP, multiple RECONFIRM request messages can be concatenated in a @@ -1157,25 +1169,20 @@ RCODE value NOTAUTH indicates that the server is not authoritative for the requested name, and can do nothing to remedy the apparent error. Note that there may be future cases in which a server is able to pass on the RECONFIRM request to the ultimate source of the information, and in these cases the server should return NOERROR. RCODE value SSOPNOTIMP indicates that the server does not support RECONFIRM requests. - Similarly, a server would only generate SSOPNOTIMP if it did not - support Push Notifications, and if the server does not support Push - Notifications then it should not be possible for a client to have an - active subscription to cancel. - Nonzero RCODE values SERVFAIL, REFUSED and SSOPNOTIMP are benign from the client's point of view. The client may log them to aid in debugging, but otherwise they require no special action. Nonzero RCODE values other than these three indicate a serious problem with the client. After sending an error response other than one of these three, the server SHOULD send a DNS Session Signaling Retry Delay Operation TLV and then close the TCP connection, as described in the DNS Session Signaling specification [SessSig].