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