--- 1/draft-ietf-dnssd-push-07.txt 2016-07-08 17:16:10.465796852 -0700 +++ 2/draft-ietf-dnssd-push-08.txt 2016-07-08 17:16:10.533798553 -0700 @@ -1,19 +1,19 @@ Internet Engineering Task Force T. Pusateri Internet-Draft Seeking affiliation Intended status: Standards Track S. Cheshire -Expires: October 6, 2016 Apple Inc. - April 4, 2016 +Expires: January 9, 2017 Apple Inc. + July 8, 2016 DNS Push Notifications - draft-ietf-dnssd-push-07 + draft-ietf-dnssd-push-08 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. @@ -26,21 +26,21 @@ 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 October 6, 2016. + This Internet-Draft will expire on January 9, 2017. Copyright Notice Copyright (c) 2016 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 @@ -74,20 +74,29 @@ 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction + IMPORTANT NOTE: This document currently references the EDNS(0) TCP + Keepalive option [RFC7828]. As a result of discussions about this + document, the community came to the realization that DNS needs + explicit session-level signaling, to complement the current EDNS(0) + per-message signaling. As a result, work on DNS Session Signaling + [I-D.bellis-dnsop-session-signal] is underway, and this document will + be updated shortly to make use of those new Session Signaling + mechanisms once they are agreed. + DNS records may be updated using DNS Update [RFC2136]. Other mechanisms such as a Hybrid Proxy [I-D.ietf-dnssd-hybrid] can also generate changes to a DNS zone. This document specifies a protocol for Unicast 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. Familiarity with the DNS protocol and DNS packet formats is assumed [RFC1034] [RFC1035] [RFC6895]. @@ -253,32 +262,32 @@ DNS Push Notification server. Over that connection the client then issues DNS operation requests, such as SUBSCRIBE. 4.1. Client-Initiated Termination An individual subscription is terminated by sending an UNSUBSCRIBE message for that specific subscription, or all subscriptions can be cancelled at once by the client closing the connection. When a client terminates an individual subscription (via UNSUBSCRIBE) or all subscriptions on that connection (by closing the connection) it is - signalling to the server that it is longer interested in receiving + signaling to the server that it is longer interested in receiving those particular updates. It is informing the server that the server may release any state information it has been keeping with regards to these particular subscriptions. After terminating its last subscription on a connection via UNSUBSCRIBE, a client MAY close the connection immediately, or it may keep it open if it anticipates performing further operations on that connection in the future. If a client wishes to keep an idle connection open, it MUST continue to meet its keepalive obligations - [I-D.ietf-dnsop-edns-tcp-keepalive] or the server is entitled to - close the connection (see below). + [RFC7828] or the server is entitled to close the connection (see + below). If a client plans to terminate one or more subscriptions on a connection and doesn't intend to keep that connection open, then as an efficiency optimization it MAY instead choose to simply close the connection, which implicitly terminates all subscriptions on that connection. This may occur because the client computer is being shut down, is going to sleep, the application requiring the subscriptions has terminated, or simply because the last active subscription on that connection has been cancelled. @@ -316,28 +325,28 @@ operations. If the server does not close the connection then the client SHOULD continue to use that connection for subsequent operations. Upon receiving a Termination Message from the server (see below), a client MUST immediately close the connection. 4.2. Server-Initiated Termination If a client makes a connection and then fails to send any DNS message - that uses EDNS(0) TCP Keepalive [I-D.ietf-dnsop-edns-tcp-keepalive] - (either SUBSCRIBE, where Keepalive is implicit, or some other DNS - message, with an explicit an EDNS(0) TCP Keepalive option) then after - 30 seconds of inactivity the server SHOULD close the connection. If - no data has been sent on the connection the server MAY abort the - connection with a TCP RST. If data has been sent on the connection - then the server SHOULD close the connection gracefully with a TCP FIN - so that the data is reliably delivered. + that uses EDNS(0) TCP Keepalive [RFC7828] (either SUBSCRIBE, where + Keepalive is implicit, or some other DNS message, with an explicit an + EDNS(0) TCP Keepalive option) then after 30 seconds of inactivity the + server SHOULD close the connection. If no data has been sent on the + connection the server MAY abort the connection with a TCP RST. If + data has been sent on the connection then the server SHOULD close the + connection gracefully with a TCP FIN so that the data is reliably + delivered. In the response to the first successful SUBSCRIBE, the included EDNS(0) TCP Keepalive option specifies the idle timeout so that the client knows the frequency of traffic it must generate to keep the connection alive. If the idle timeout for that connection changes, then the server communicates this by placing an updated EDNS(0) TCP Keepalive option in a subsequent message to the client. At both servers and clients, the generation or reception of any complete request, response, update, or keepalive message resets the @@ -647,26 +656,26 @@ matches only a literal CNAME record in the zone, and nothing else. A client may SUBSCRIBE to records that are unknown to the server at the time of the request (providing that the name falls within one of the zone(s) the server is responsible for) and this is not an error. The server MUST accept these requests and send Push Notifications if and when matches are found in the future. Since all SUBSCRIBE operations are implicitly long-lived operations, the server MUST interpret a SUBSCRIBE request as if it contained an - EDNS(0) TCP Keepalive option [I-D.ietf-dnsop-edns-tcp-keepalive]. A - client MUST NOT include an actual EDNS(0) TCP Keepalive option in the - request, since it is automatic, and implied by the semantics of - SUBSCRIBE. If a server receives a SUBSCRIBE request that does - contain an actual EDNS(0) TCP Keepalive option this is an error and - the server MUST immediately close the TCP connection. + EDNS(0) TCP Keepalive option [RFC7828]. A client MUST NOT include an + actual EDNS(0) TCP Keepalive option in the request, since it is + automatic, and implied by the semantics of SUBSCRIBE. If a server + receives a SUBSCRIBE request that does contain an actual EDNS(0) TCP + Keepalive option this is an error and the server MUST immediately + close the TCP connection. A SUBSCRIBE operation MAY include an explicit EDNS(0) [RFC6891] OPT record where necessary to carry additional EDNS(0) information other than a TCP Keepalive option. The presence of a SUBSCRIBE operation on a connection indicates to the server that the client fully implements EDNS(0) [RFC6891], and can correctly understand any response that conforms to that specification. After receiving a SUBSCRIBE request, the server MAY include OPT record in any of its responses, as needed. @@ -944,23 +953,23 @@ send a "delete all RRsets from a name" update, not two separate "delete an RRset from a name" updates. A server SHOULD combine multiple change notifications in a single Update Message when possible, even if those change notifications apply to different subscriptions. Conceptually, a Push Notification Update Message is a connection-level concept, not a subscription- level concept. Push Notification Update Messages MAY contain an EDNS(0) TCP - Keepalive option [I-D.ietf-dnsop-edns-tcp-keepalive] if the idle - timeout has changed since the last time the server sent an EDNS(0) - TCP Keepalive option on this connection. + Keepalive option [RFC7828] if the idle timeout has changed since the + last time the server sent an EDNS(0) TCP Keepalive option on this + connection. In the event that the server wishes to inform a client of a new idle timeout for the connection, the server MAY combine that with the next message it sends to the client, or the server MAY send an empty Push Notification Update Message (zero records in the Update Section) to carry the EDNS(0) TCP Keepalive option. Clients MUST correctly receive and process the EDNS(0) TCP Keepalive option in both cases. Reception of a Push Notification Update Message does not directly generate a response back to the server. (Updates may indirectly @@ -1118,26 +1127,25 @@ This document specifies only these two RCODE values for Termination Messages. Servers sending Termination Messages SHOULD use one of these two values. However, future circumstances may create situations where other RCODE values are appropriate in Termination Messages, so clients MUST be prepared to accept Termination Messages with any RCODE value. In particular, a Termination Message with RCODE value zero (NOERROR) is still a Termination Message and should be treated as such. The Termination Message MUST contain an EDNS(0) TCP Keepalive option - [I-D.ietf-dnsop-edns-tcp-keepalive]. The client MUST wait for the - time indicated in the EDNS(0) TCP Keepalive option's idle timeout - before attempting any new connections to this server. A client that - receives a Termination Message without an EDNS(0) TCP Keepalive - option SHOULD treat it as equivalent to a TCP Keepalive option with a - zero timeout value. + [RFC7828]. The client MUST wait for the time indicated in the + EDNS(0) TCP Keepalive option's idle timeout before attempting any new + connections to this server. A client that receives a Termination + Message without an EDNS(0) TCP Keepalive option SHOULD treat it as + equivalent to a TCP Keepalive option with a zero timeout value. In the case where the server is rejecting some, but not all, of the existing subscriptions (perhaps because it has been reconfigured and is no longer authoritative for those names) with a REFUSED (5) RCODE, the EDNS(0) TCP Keepalive option's idle timeout MAY be zero, indicating that the client SHOULD attempt to re-establish its subscriptions immediately. In the case where a server is terminating a large number of connections at once (e.g., if the system is restarting) and the @@ -1237,29 +1245,29 @@ previous work completed in this field. This draft has been improved due to comments from Ran Atkinson, Tim Chown, Mark Delany, Ralph Droms, Bernie Volz, Jan Komissar, Manju Shankar Rao, Markus Stenberg, Dave Thaler, and Soraia Zlatkovic. 10. References 10.1. Normative References - [I-D.ietf-dnsop-edns-tcp-keepalive] - Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The - edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns- - tcp-keepalive-06 (work in progress), February 2016. + [I-D.bellis-dnsop-session-signal] + Bellis, R., Cheshire, S., Marcon, J., Mankin, A., and T. + Pusateri, "DNS Session Signaling", draft-bellis-dnsop- + session-signal-00 (work in progress), July 2016. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol - Version 1.3", draft-ietf-tls-tls13-12 (work in progress), - March 2016. + Version 1.3", draft-ietf-tls-tls13-13 (work in progress), + May 2016. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", @@ -1312,20 +1320,25 @@ [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, . [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, . + [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The + edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/ + RFC7828, April 2016, + . + 10.2. Informative References [I-D.ietf-dnssd-hybrid] Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service Discovery", draft-ietf-dnssd-hybrid-03 (work in progress), November 2015. [I-D.ietf-dprive-dns-over-tls] Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over TLS", draft-