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/