--- 1/draft-ietf-dnssd-push-04.txt 2016-01-29 18:15:10.590453236 -0800 +++ 2/draft-ietf-dnssd-push-05.txt 2016-01-29 18:15:10.642454509 -0800 @@ -1,19 +1,19 @@ Internet Engineering Task Force T. Pusateri Internet-Draft Seeking affiliation Intended status: Standards Track S. Cheshire -Expires: July 14, 2016 Apple Inc. - January 11, 2016 +Expires: August 1, 2016 Apple Inc. + January 29, 2016 DNS Push Notifications - draft-ietf-dnssd-push-04 + draft-ietf-dnssd-push-05 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 July 14, 2016. + This Internet-Draft will expire on August 1, 2016. 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 @@ -53,36 +53,36 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. State Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 8 - 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 9 - 6.3. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 12 - 6.4. DNS Push Notification Update Messages . . . . . . . . . . 13 - 6.5. DNS RECONFIRM . . . . . . . . . . . . . . . . . . . . . . 16 - 6.6. DNS Push Notification Termination Message . . . . . . . . 17 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 18 - 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 19 - 7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 19 - 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 19 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 - 10.2. Informative References . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 + 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 10 + 6.3. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 13 + 6.4. DNS Push Notification Update Messages . . . . . . . . . . 14 + 6.5. DNS RECONFIRM . . . . . . . . . . . . . . . . . . . . . . 17 + 6.6. DNS Push Notification Termination Message . . . . . . . . 18 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 19 + 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 20 + 7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 20 + 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 20 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 10.2. Informative References . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction 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 @@ -96,21 +96,21 @@ "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 2. Motivation As the domain name system continues to adapt to new uses and changes in deployment, polling has the potential to burden DNS servers at many levels throughout the network. Other network protocols have successfully deployed a publish/subscribe model to state changes following the Observer design pattern. XMPP Publish-Subscribe - [XEP-0060] and Atom [RFC4287] are examples. While DNS servers are + [XEP0060] and Atom [RFC4287] are examples. While DNS servers are generally highly tuned and capable of a high rate of query/response traffic, adding a publish/subscribe model for tracking changes to DNS records can result in more timely notification of changes with reduced CPU usage and lower network traffic. Multicast DNS [RFC6762] implementations always listen on a well known link-local IP multicast group, and new services and updates are sent 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 @@ -269,32 +269,44 @@ Push Notification server. A client SHOULD share a single TLS/TCP connection for all requests to the same DNS Push Notification server. This shared connection should be used for all DNS Queries and DNS Push Notification Queries queries to that server, and for DNS Update requests too when the "_dns-update-tls._tcp." SRV record indicates that the same server also handles DNS Update requests. This is to reduce unnecessary load on the DNS Push Notification server. For the purposes here, the determination of "same server" is made by - inspecting the target host and port, regardless of the name being + inspecting the target hostname and port, regardless of the name being queried, or what zone if falls within. A given server may support Push Notifications (and possibly DNS Updates too) for multiple DNS zones. When a client discovers that the DNS Push Notification server (and/or DNS Update server) for several different names (including - names that fall within different zones) is the same target host and - port, the client SHOULD use a single shared TCP connection for all - relevant operations on those names. A client SHOULD NOT open + names that fall within different zones) is the same target hostname + and port, the client SHOULD use a single shared TCP connection for + all relevant operations on those names. A client SHOULD NOT open multiple TCP connections to the same target host and port just because the names being queried (or updated) happen to fall within different zones. + Note that the "same server" determination described here is made + using the target hostname given in the SRV record, not the IP + address(es) that the hostname resolves to. If two different target + hostnames happen to resolve to the same IP address(es), then the + client SHOULD NOT recognize these as the "same server" for the + purposes of using a single shared connection to that server. If an + administrator wishes to use a single server for multiple zones and/or + multiple roles (e.g., both DNS Push Notifications and DNS Updates), + and wishes to have clients use a single shared connection for + operations on that server, then the administrator MUST use the same + target hostname in the appropriate SRV records. + However, a single client device may be home to multiple independent client software instances that don't know about each other, so a DNS Push Notification server MUST be prepared to accept multiple connections from the same client IP address. This is undesirable from an efficiency stanpoint, but may be unavoidable in some situations, so a DNS Push Notification server MUST be prepared to accept multiple connections from the same client IP address. 6.1. Discovery @@ -827,31 +840,31 @@ This document defines three DNS OpCodes: SUBSCRIBE with (tentative) value 6, UNSUBSCRIBE with (tentative) value 7, and RECONFIRM with (tentative) value 8. 9. Acknowledgements The authors would like to thank Kiren Sekar and Marc Krochmal for previous work completed in this field. This draft has been improved due to comments from Ran Atkinson, Mark - Delany, and Markus Stenberg. + Delany, Manju Shankar Rao, and Markus Stenberg. 10. References 10.1. Normative References [I-D.ietf-dnsop-5966bis] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation - Requirements", draft-ietf-dnsop-5966bis-05 (work in - progress), December 2015. + Requirements", draft-ietf-dnsop-5966bis-06 (work in + progress), January 2016. [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-05 (work in progress), January 2016. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-11 (work in progress), December 2015. @@ -955,22 +968,21 @@ [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . - [XEP-0060] - Millard, P., Saint-Andre, P., and R. Meijer, "Publish- + [XEP0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish- Subscribe", XSF XEP 0060, July 2010. Authors' Addresses Tom Pusateri Seeking affiliation Hilton Head Island, SC USA Phone: +1 843 473 7394