--- 1/draft-ietf-dnssd-push-02.txt 2015-11-05 02:38:36.299631778 -0800 +++ 2/draft-ietf-dnssd-push-03.txt 2015-11-05 02:38:36.419634702 -0800 @@ -1,19 +1,19 @@ Internet Engineering Task Force T. Pusateri Internet-Draft Seeking affiliation Intended status: Standards Track S. Cheshire -Expires: April 21, 2016 Apple Inc. - October 19, 2015 +Expires: May 8, 2016 Apple Inc. + November 5, 2015 DNS Push Notifications - draft-ietf-dnssd-push-02 + draft-ietf-dnssd-push-03 Abstract The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -440,21 +440,21 @@ Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message matches only a CNAME in the zone, and nothing else. 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 accept these requests and send Push Notifications if and when matches are found in the future. Since all SUBSCRIBE operations are implicitly long-lived operations, 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 request, since it is automatic, and implied by the semantics of SUBSCRIBE. If a server receives a SUBSCRIBE request this is an error and the server MUST immediately close the TCP connection. In a SUBSCRIBE response the server MUST include an EDNS0 TCP Keepalive option specifying the idle timeout so that the client knows the frequency of keepalives it must generate to keep the connection alive. If the client receives a SUBSCRIBE response that does not contain an EDNS0 TCP Keepalive option this is an error and the client MUST immediately close the TCP connection. @@ -579,24 +579,24 @@ manner possible. For example, when three AAAA records are deleted 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 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 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 "delete an RRset from a name" updates. All Push Notification Update Messages MUST contain an EDNS0 TCP - Keepalive option [I-D.wouters-edns-tcp-keepalive] specifying the idle - timeout so that the client knows the frequency of keepalives it must - generate to keep the connection alive. If the client receives a Push - Notification Update Message that does not contain an EDNS0 TCP + Keepalive option [I-D.ietf-dnsop-edns-tcp-keepalive] specifying the + idle timeout so that the client knows the frequency of keepalives it + must generate to keep the connection alive. If the client receives a + Push Notification Update Message that does not contain an EDNS0 TCP Keepalive option this is an error and the client MUST immediately close the TCP connection. Reception of a Push Notification Update Message results in no response back to the server. 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 subscription is active, the TTL does not decrement below 1 second. For as long as a relevant subscription remains active, the client @@ -712,22 +712,22 @@ Any records in the Prerequisite Section MUST be silently ignored. UPCOUNT MUST be zero, and the Update Section MUST be empty. Any records in the Update Section MUST be silently ignored. ADCOUNT MUST be zero, and the Additional Data Section MUST be empty. Any records in the Additional Data Section MUST be silently ignored. The RCODE MUST contain a code giving the reason for termination. [Codes to be determined.] The Termination Message MUST contain an - EDNS0 TCP Keepalive option [I-D.wouters-edns-tcp-keepalive] where the - idle timeout indicates the time the client SHOULD wait before + EDNS0 TCP Keepalive option [I-D.ietf-dnsop-edns-tcp-keepalive] where + the idle timeout indicates the time the client SHOULD wait before attempting to reconnect. 7. Acknowledgements The authors would like to thank Kiren Sekar and Marc Krochmal for previous work completed in this field. This draft has been improved due to comments from Ran Atkinson. 8. IANA Considerations @@ -799,33 +799,33 @@ resumed, the DNS Push Notification server will not have any subscription state and will proceed as with any other new connection. 10. References 10.1. Normative References [I-D.ietf-dnsop-5966bis] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation - Requirements", draft-ietf-dnsop-5966bis-03 (work in - progress), September 2015. + Requirements", draft-ietf-dnsop-5966bis-04 (work in + 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] 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. - [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 10.17487/RFC0768, August 1980, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, @@ -879,22 +879,22 @@ [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, . 10.2. Informative References [I-D.ietf-dnssd-hybrid] Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service - Discovery", draft-ietf-dnssd-hybrid-01 (work in progress), - October 2015. + Discovery", draft-ietf-dnssd-hybrid-02 (work in progress), + November 2015. [I-D.sekar-dns-llq] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- llq-01 (work in progress), August 2006. [IPJ.9-4-TCPSYN] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The Internet Protocol Journal, Cisco Systems, Volume 9, Number 4, December 2006.