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/