draft-ietf-dnssd-push-04.txt   draft-ietf-dnssd-push-05.txt 
Internet Engineering Task Force T. Pusateri Internet Engineering Task Force T. Pusateri
Internet-Draft Seeking affiliation Internet-Draft Seeking affiliation
Intended status: Standards Track S. Cheshire Intended status: Standards Track S. Cheshire
Expires: July 14, 2016 Apple Inc. Expires: August 1, 2016 Apple Inc.
January 11, 2016 January 29, 2016
DNS Push Notifications DNS Push Notifications
draft-ietf-dnssd-push-04 draft-ietf-dnssd-push-05
Abstract Abstract
The Domain Name System (DNS) was designed to return matching records The Domain Name System (DNS) was designed to return matching records
efficiently for queries for data that is relatively static. When efficiently for queries for data that is relatively static. When
those records change frequently, DNS is still efficient at returning those records change frequently, DNS is still efficient at returning
the updated results when polled. But there exists no mechanism for a the updated results when polled. But there exists no mechanism for a
client to be asynchronously notified when these changes occur. This client to be asynchronously notified when these changes occur. This
document defines a mechanism for a client to be notified of such document defines a mechanism for a client to be notified of such
changes to DNS records, called DNS Push Notifications. changes to DNS records, called DNS Push Notifications.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. State Considerations . . . . . . . . . . . . . . . . . . . . 6 5. State Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 9 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 10
6.3. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 12 6.3. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 13
6.4. DNS Push Notification Update Messages . . . . . . . . . . 13 6.4. DNS Push Notification Update Messages . . . . . . . . . . 14
6.5. DNS RECONFIRM . . . . . . . . . . . . . . . . . . . . . . 16 6.5. DNS RECONFIRM . . . . . . . . . . . . . . . . . . . . . . 17
6.6. DNS Push Notification Termination Message . . . . . . . . 17 6.6. DNS Push Notification Termination Message . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Security Services . . . . . . . . . . . . . . . . . . . . 18 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 19
7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 19 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 20
7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 19 7.3. TLS Compression . . . . . . . . . . . . . . . . . . . . . 20
7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 19 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
DNS records may be updated using DNS Update [RFC2136]. Other DNS records may be updated using DNS Update [RFC2136]. Other
mechanisms such as a Hybrid Proxy [I-D.ietf-dnssd-hybrid] can also mechanisms such as a Hybrid Proxy [I-D.ietf-dnssd-hybrid] can also
generate changes to a DNS zone. This document specifies a protocol generate changes to a DNS zone. This document specifies a protocol
for Unicast DNS clients to subscribe to receive asynchronous for Unicast DNS clients to subscribe to receive asynchronous
notifications of changes to RRSets of interest. It is immediately notifications of changes to RRSets of interest. It is immediately
relevant in the case of DNS Service Discovery [RFC6763] but is not 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 limited to that use case and provides a general DNS mechanism for DNS
skipping to change at page 3, line 19 skipping to change at page 3, line 19
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
2. Motivation 2. Motivation
As the domain name system continues to adapt to new uses and changes As the domain name system continues to adapt to new uses and changes
in deployment, polling has the potential to burden DNS servers at in deployment, polling has the potential to burden DNS servers at
many levels throughout the network. Other network protocols have many levels throughout the network. Other network protocols have
successfully deployed a publish/subscribe model to state changes successfully deployed a publish/subscribe model to state changes
following the Observer design pattern. XMPP Publish-Subscribe 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 generally highly tuned and capable of a high rate of query/response
traffic, adding a publish/subscribe model for tracking changes to DNS traffic, adding a publish/subscribe model for tracking changes to DNS
records can result in more timely notification of changes with records can result in more timely notification of changes with
reduced CPU usage and lower network traffic. reduced CPU usage and lower network traffic.
Multicast DNS [RFC6762] implementations always listen on a well known Multicast DNS [RFC6762] implementations always listen on a well known
link-local IP multicast group, and new services and updates are sent link-local IP multicast group, and new services and updates are sent
for all group members to receive. Therefore, Multicast DNS already for all group members to receive. Therefore, Multicast DNS already
has asynchronous change notification capability. However, when DNS has asynchronous change notification capability. However, when DNS
Service Discovery [RFC6763] is used across a wide area network using Service Discovery [RFC6763] is used across a wide area network using
skipping to change at page 7, line 33 skipping to change at page 7, line 33
Push Notification server. A client SHOULD share a single TLS/TCP Push Notification server. A client SHOULD share a single TLS/TCP
connection for all requests to the same DNS Push Notification server. connection for all requests to the same DNS Push Notification server.
This shared connection should be used for all DNS Queries and DNS This shared connection should be used for all DNS Queries and DNS
Push Notification Queries queries to that server, and for DNS Update Push Notification Queries queries to that server, and for DNS Update
requests too when the "_dns-update-tls._tcp.<zone>" SRV record requests too when the "_dns-update-tls._tcp.<zone>" SRV record
indicates that the same server also handles DNS Update requests. indicates that the same server also handles DNS Update requests.
This is to reduce unnecessary load on the DNS Push Notification This is to reduce unnecessary load on the DNS Push Notification
server. server.
For the purposes here, the determination of "same server" is made by 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 queried, or what zone if falls within. A given server may support
Push Notifications (and possibly DNS Updates too) for multiple DNS Push Notifications (and possibly DNS Updates too) for multiple DNS
zones. When a client discovers that the DNS Push Notification server zones. When a client discovers that the DNS Push Notification server
(and/or DNS Update server) for several different names (including (and/or DNS Update server) for several different names (including
names that fall within different zones) is the same target host and names that fall within different zones) is the same target hostname
port, the client SHOULD use a single shared TCP connection for all and port, the client SHOULD use a single shared TCP connection for
relevant operations on those names. A client SHOULD NOT open all relevant operations on those names. A client SHOULD NOT open
multiple TCP connections to the same target host and port just multiple TCP connections to the same target host and port just
because the names being queried (or updated) happen to fall within because the names being queried (or updated) happen to fall within
different zones. 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 However, a single client device may be home to multiple independent
client software instances that don't know about each other, so a DNS client software instances that don't know about each other, so a DNS
Push Notification server MUST be prepared to accept multiple Push Notification server MUST be prepared to accept multiple
connections from the same client IP address. This is undesirable connections from the same client IP address. This is undesirable
from an efficiency stanpoint, but may be unavoidable in some from an efficiency stanpoint, but may be unavoidable in some
situations, so a DNS Push Notification server MUST be prepared to situations, so a DNS Push Notification server MUST be prepared to
accept multiple connections from the same client IP address. accept multiple connections from the same client IP address.
6.1. Discovery 6.1. Discovery
skipping to change at page 20, line 21 skipping to change at page 21, line 21
This document defines three DNS OpCodes: SUBSCRIBE with (tentative) This document defines three DNS OpCodes: SUBSCRIBE with (tentative)
value 6, UNSUBSCRIBE with (tentative) value 7, and RECONFIRM with value 6, UNSUBSCRIBE with (tentative) value 7, and RECONFIRM with
(tentative) value 8. (tentative) value 8.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Kiren Sekar and Marc Krochmal for The authors would like to thank Kiren Sekar and Marc Krochmal for
previous work completed in this field. previous work completed in this field.
This draft has been improved due to comments from Ran Atkinson, Mark 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. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-dnsop-5966bis] [I-D.ietf-dnsop-5966bis]
Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", draft-ietf-dnsop-5966bis-05 (work in Requirements", draft-ietf-dnsop-5966bis-06 (work in
progress), December 2015. progress), January 2016.
[I-D.ietf-dnsop-edns-tcp-keepalive] [I-D.ietf-dnsop-edns-tcp-keepalive]
Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns- edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns-
tcp-keepalive-05 (work in progress), January 2016. tcp-keepalive-05 (work in progress), January 2016.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-11 (work in progress), Version 1.3", draft-ietf-tls-tls13-11 (work in progress),
December 2015. December 2015.
skipping to change at page 23, line 11 skipping to change at page 24, line 11
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>. <http://www.rfc-editor.org/info/rfc6763>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
[XEP-0060] [XEP0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
Subscribe", XSF XEP 0060, July 2010. Subscribe", XSF XEP 0060, July 2010.
Authors' Addresses Authors' Addresses
Tom Pusateri Tom Pusateri
Seeking affiliation Seeking affiliation
Hilton Head Island, SC Hilton Head Island, SC
USA USA
Phone: +1 843 473 7394 Phone: +1 843 473 7394
 End of changes. 11 change blocks. 
30 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/