draft-ietf-dnssd-push-02.txt   draft-ietf-dnssd-push-03.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: April 21, 2016 Apple Inc. Expires: May 8, 2016 Apple Inc.
October 19, 2015 November 5, 2015
DNS Push Notifications DNS Push Notifications
draft-ietf-dnssd-push-02 draft-ietf-dnssd-push-03
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 April 21, 2016. This Internet-Draft will expire on May 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 11, line 34 skipping to change at page 11, line 34
Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message
matches only a CNAME in the zone, and nothing else. matches only a CNAME 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 and this is not an error. The server MUST the time of the request and this is not an error. The server MUST
accept these requests and send Push Notifications if and when matches accept these requests and send Push Notifications if and when matches
are found in the future. 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
EDNS0 TCP Keepalive option [I-D.wouters-edns-tcp-keepalive]. A EDNS0 TCP Keepalive option [I-D.ietf-dnsop-edns-tcp-keepalive]. A
client MUST NOT include an actual EDNS0 TCP Keepalive option in the client MUST NOT include an actual EDNS0 TCP Keepalive option in the
request, since it is automatic, and implied by the semantics of request, since it is automatic, and implied by the semantics of
SUBSCRIBE. If a server receives a SUBSCRIBE request this is an error SUBSCRIBE. If a server receives a SUBSCRIBE request this is an error
and the server MUST immediately close the TCP connection. In a and the server MUST immediately close the TCP connection. In a
SUBSCRIBE response the server MUST include an EDNS0 TCP Keepalive SUBSCRIBE response the server MUST include an EDNS0 TCP Keepalive
option specifying the idle timeout so that the client knows the option specifying the idle timeout so that the client knows the
frequency of keepalives it must generate to keep the connection frequency of keepalives it must generate to keep the connection
alive. If the client receives a SUBSCRIBE response that does not alive. If the client receives a SUBSCRIBE response that does not
contain an EDNS0 TCP Keepalive option this is an error and the client contain an EDNS0 TCP Keepalive option this is an error and the client
MUST immediately close the TCP connection. MUST immediately close the TCP connection.
skipping to change at page 15, line 11 skipping to change at page 15, line 11
manner possible. For example, when three AAAA records are deleted manner possible. For example, when three AAAA records are deleted
from a given name, and no other AAAA records exist for that name, the from a given name, and no other AAAA records exist for that name, the
server SHOULD send a "delete an RRset from a name" update, not three server SHOULD send a "delete an RRset from a name" update, not three
separate "delete an individual RR from a name" updates. Similarly, separate "delete an individual RR from a name" updates. Similarly,
when both an SRV and a TXT record are deleted from a given name, and when both an SRV and a TXT record are deleted from a given name, and
no other records of any kind exist for that name, the server SHOULD no other records of any kind exist for that name, the server SHOULD
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.
All Push Notification Update Messages MUST contain an EDNS0 TCP All Push Notification Update Messages MUST contain an EDNS0 TCP
Keepalive option [I-D.wouters-edns-tcp-keepalive] specifying the idle Keepalive option [I-D.ietf-dnsop-edns-tcp-keepalive] specifying the
timeout so that the client knows the frequency of keepalives it must idle timeout so that the client knows the frequency of keepalives it
generate to keep the connection alive. If the client receives a Push must generate to keep the connection alive. If the client receives a
Notification Update Message that does not contain an EDNS0 TCP Push Notification Update Message that does not contain an EDNS0 TCP
Keepalive option this is an error and the client MUST immediately Keepalive option this is an error and the client MUST immediately
close the TCP connection. close the TCP connection.
Reception of a Push Notification Update Message results in no Reception of a Push Notification Update Message results in no
response back to the server. response back to the server.
The TTL of an added record is stored by the client and decremented as The TTL of an added record is stored by the client and decremented as
time passes, with the caveat that for as long as a relevant time passes, with the caveat that for as long as a relevant
subscription is active, the TTL does not decrement below 1 second. subscription is active, the TTL does not decrement below 1 second.
For as long as a relevant subscription remains active, the client For as long as a relevant subscription remains active, the client
skipping to change at page 19, line 13 skipping to change at page 19, line 13
Any records in the Prerequisite Section MUST be silently ignored. Any records in the Prerequisite Section MUST be silently ignored.
UPCOUNT MUST be zero, and the Update Section MUST be empty. UPCOUNT MUST be zero, and the Update Section MUST be empty.
Any records in the Update Section MUST be silently ignored. Any records in the Update Section MUST be silently ignored.
ADCOUNT MUST be zero, and the Additional Data Section MUST be empty. ADCOUNT MUST be zero, and the Additional Data Section MUST be empty.
Any records in the Additional Data Section MUST be silently ignored. Any records in the Additional Data Section MUST be silently ignored.
The RCODE MUST contain a code giving the reason for termination. The RCODE MUST contain a code giving the reason for termination.
[Codes to be determined.] The Termination Message MUST contain an [Codes to be determined.] The Termination Message MUST contain an
EDNS0 TCP Keepalive option [I-D.wouters-edns-tcp-keepalive] where the EDNS0 TCP Keepalive option [I-D.ietf-dnsop-edns-tcp-keepalive] where
idle timeout indicates the time the client SHOULD wait before the idle timeout indicates the time the client SHOULD wait before
attempting to reconnect. attempting to reconnect.
7. Acknowledgements 7. 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. This draft has been improved previous work completed in this field. This draft has been improved
due to comments from Ran Atkinson. due to comments from Ran Atkinson.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 21, line 12 skipping to change at page 21, line 12
resumed, the DNS Push Notification server will not have any resumed, the DNS Push Notification server will not have any
subscription state and will proceed as with any other new connection. subscription state and will proceed as with any other new connection.
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-03 (work in Requirements", draft-ietf-dnsop-5966bis-04 (work in
progress), September 2015. progress), November 2015.
[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-04 (work in progress), October 2015.
[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-09 (work in progress), Version 1.3", draft-ietf-tls-tls13-10 (work in progress),
October 2015. October 2015.
[I-D.wouters-edns-tcp-keepalive]
Wouters, P. and J. Abley, "The edns-tcp-keepalive EDNS0
Option", draft-wouters-edns-tcp-keepalive-01 (work in
progress), February 2014.
[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",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
skipping to change at page 22, line 46 skipping to change at page 22, line 46
[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>.
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-01 (work in progress), Discovery", draft-ietf-dnssd-hybrid-02 (work in progress),
October 2015. November 2015.
[I-D.sekar-dns-llq] [I-D.sekar-dns-llq]
Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns-
llq-01 (work in progress), August 2006. llq-01 (work in progress), August 2006.
[IPJ.9-4-TCPSYN] [IPJ.9-4-TCPSYN]
Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The
Internet Protocol Journal, Cisco Systems, Volume 9, Number Internet Protocol Journal, Cisco Systems, Volume 9, Number
4, December 2006. 4, December 2006.
 End of changes. 10 change blocks. 
21 lines changed or deleted 21 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/