--- 1/draft-ietf-dnssd-push-23.txt 2019-08-07 19:13:06.053879633 -0700 +++ 2/draft-ietf-dnssd-push-24.txt 2019-08-07 19:13:06.133881659 -0700 @@ -1,19 +1,19 @@ Internet Engineering Task Force T. Pusateri Internet-Draft Unaffiliated Intended status: Standards Track S. Cheshire -Expires: January 22, 2020 Apple Inc. - July 21, 2019 +Expires: February 8, 2020 Apple Inc. + August 7, 2019 DNS Push Notifications - draft-ietf-dnssd-push-23 + draft-ietf-dnssd-push-24 Abstract The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. 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 @@ -27,21 +27,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 https://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 January 22, 2020. + This Internet-Draft will expire on February 8, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -224,29 +224,39 @@ (b) A DNS Push Notification client SHOULD NOT routinely keep a DNS Push Notification subscription active 24 hours a day, 7 days a week, just to keep a list in memory up to date so that if the user does choose to bring up an on-screen display of that data, it can be displayed really fast. DNS Push Notifications are designed to be fast enough that there is no need to pre-load a "warm" list in memory just in case it might be needed later. Generally, as described in the DNS Stateful Operations specification - [RFC8490], a client must not keep a session to a server open + [RFC8490], a client must not keep a DSO session to a server open indefinitely if it has no subscriptions (or other operations) active - on that session. A client MAY close a session as soon as it becomes - idle, and then if needed in the future, open a new session when - required. Alternatively, a client MAY speculatively keep an idle - session open for some time, subject to the constraint that it MUST - NOT keep a session open that has been idle for more than the + on that session. A client MAY close a DSO session immediately it + becomes idle, and then if needed in the future, open a new session + when required. Alternatively, a client MAY speculatively keep an + idle DSO session open for some time, subject to the constraint that + it must not keep a session open that has been idle for more than the session's idle timeout (15 seconds by default) [RFC8490]. + Note that a DSO session which has an active DNS Push Notification + subscription is not considered idle, even if there is no traffic + flowing for an extended period of time. In this case the DSO + inactivity timeout does not apply, because the session is not + inactive, but the keepalive interval does still apply, to ensure + generation of sufficient messages to maintain state in middleboxes + (such at NAT gateways or firewalls) and for the client and server to + periodically verify that they still have connectivity to each other. + This is described in Section 6.2 of the DSO specification [RFC8490]. + 4. State Considerations Each DNS Push Notification server is capable of handling some finite number of Push Notification subscriptions. This number will vary from server to server and is based on physical machine characteristics, network bandwidth, and operating system resource allocation. After a client establishes a session to a DNS server, each subscription is individually accepted or rejected. Servers may employ various techniques to limit subscriptions to a manageable level. Correspondingly, the client is free to establish simultaneous @@ -272,22 +282,22 @@ concerns of state overload at the server which is a potential problem with connectionless protocols using spoofed source addresses. All subscribers are guaranteed to be reachable by the server by virtue of the TCP three-way handshake. Flooding attacks are possible with any protocol, and a benefit of TCP is that there are already established industry best practices to guard against SYN flooding and similar attacks [SYN] [RFC4953]. Use of TCP also allows DNS Push Notifications to take advantage of current and future developments in TCP, such as Multipath TCP (MPTCP) - [RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP) - [I-D.dukkipati-tcpm-tcp-loss-probe], and so on. + [RFC6824], TCP Fast Open (TFO) [RFC7413], RACK: a time-based fast + loss detection algorithm for TCP [I-D.ietf-tcpm-rack], and so on. Transport Layer Security (TLS) [RFC8446] is well understood, and used by many application-layer protocols running over TCP. TLS is designed to prevent eavesdropping, tampering, and message forgery. TLS is REQUIRED for every connection between a client subscriber and server in this protocol specification. Additional security measures such as client authentication during TLS negotiation MAY also be employed to increase the trust relationship between client and server. @@ -589,22 +599,22 @@ If neither TYPE nor CLASS are ANY (255) then this is a specific subscription to changes for the given NAME, TYPE and CLASS. If one or both of TYPE or CLASS are ANY (255) then this subscription matches any type and/or any class, as appropriate. NOTE: A little-known quirk of DNS is that in DNS QUERY requests, QTYPE and QCLASS 255 mean "ANY" not "ALL". They indicate that the server should respond with ANY matching records of its choosing, not necessarily ALL matching records. This can lead to some surprising and unexpected results, where a query returns some valid answers but - not all of them, and makes QTYPE=ANY queries less useful than people - sometimes imagine. + not all of them, and makes QTYPE = 255 (ANY) queries less useful than + people sometimes imagine. When used in conjunction with SUBSCRIBE, TYPE and CLASS 255 should be interpreted to mean "ALL", not "ANY". After accepting a subscription where one or both of TYPE or CLASS are 255, the server MUST send Push Notification Updates for ALL record changes that match the subscription, not just some of them. 6.2.2. SUBSCRIBE Response Each SUBSCRIBE request generates exactly one SUBSCRIBE response from @@ -842,47 +852,47 @@ all types in the specified class. For collective remove notifications, if CLASS is 255 (ANY), then for the given name this deletes all records of all types in all classes. In this case TYPE MUST be set to zero on transmission, and MUST be silently ignored on reception. Summary of change notification types: Delete all RRsets from a name, in all classes - TTL=0xFFFFFFFE, RDLENGTH=0, CLASS=255 (ANY) + TTL = 0xFFFFFFFE, RDLEN = 0, CLASS = 255 (ANY) Delete all RRsets from a name, in given class: - TTL=0xFFFFFFFE, RDLENGTH=0, CLASS specifies class, TYPE=255 (ANY) + TTL = 0xFFFFFFFE, RDLEN = 0, CLASS gives class, TYPE = 255 (ANY) Delete specified RRset from a name, in given class: - TTL=0xFFFFFFFE, RDLENGTH=0 + TTL = 0xFFFFFFFE, RDLEN = 0 CLASS and TYPE specify the RRset being deleted Delete an individual RR from a name: TTL=0xFFFFFFFF - CLASS, TYPE, RDLENGTH and RDATA specify the RR being deleted. + CLASS, TYPE, RDLEN and RDATA specify the RR being deleted. Add individual RR to a name - TTLā©¾0 - CLASS, TYPE, RDLENGTH, RDATA and TTL specify the RR being added. + TTL >= 0 and TTL <= 0x7FFFFFFF + CLASS, TYPE, RDLEN, RDATA and TTL specify the RR being added. Note that it is valid for the RDATA of an added or removed DNS Resource Record to be empty (zero length). For example, an Address Prefix List Resource Record [RFC3123] may have empty RDATA. - Therefore, a change notification with RDLEN=0 does not automatically - indicate a remove notification. If RDLEN=0 and TTL is the in the - range 0 - 0x7FFFFFFF, this change notification signals the addition - of a record with the given name, type, class, and empty RDATA. If - RDLEN=0 and TTL = 0xFFFFFFFF, this change notification signals the - removal specifically of that single record with the given name, type, - class, and empty RDATA. + Therefore, a change notification with RDLEN = 0 does not + automatically indicate a remove notification. If RDLEN = 0 and TTL + is the in the range 0 - 0x7FFFFFFF, this change notification signals + the addition of a record with the given name, type, class, and empty + RDATA. If RDLEN = 0 and TTL = 0xFFFFFFFF, this change notification + signals the removal specifically of that single record with the given + name, type, class, and empty RDATA. If the TTL is any value other than 0xFFFFFFFF, 0xFFFFFFFE, or a value in the range 0 - 0x7FFFFFFF, then the receiver SHOULD silently ignore this particular change notification record. The connection is not terminated and other valid change notification records within this PUSH message are processed as usual. For efficiency, when generating a PUSH message, a server SHOULD include as many change notifications as it has immediately available to send, rather than sending each change notification as a separate @@ -971,23 +981,23 @@ record addition/deletion is silently ignored. Processing of other additions and deletions in this message is not affected. The DSO session is not closed. This is to allow for the unavoidable race condition where a client sends an outbound UNSUBSCRIBE while inbound PUSH messages for that subscription from the server are still in flight. In the case where a single change affects more than one active subscription, only one PUSH message is sent. For example, a PUSH message adding a given record may match both a SUBSCRIBE request with - the same TYPE and a different SUBSCRIBE request with TYPE=ANY (255). - It is not the case that two PUSH messages are sent because the new - record matches two active subscriptions. + the same TYPE and a different SUBSCRIBE request with TYPE = 255 + (ANY). It is not the case that two PUSH messages are sent because + the new record matches two active subscriptions. The server SHOULD encode change notifications in the most efficient 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" PUSH message, not three separate "delete an individual RR from a name" PUSH messages. 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" PUSH message, not two separate "delete an RRset from a name" PUSH messages. @@ -1264,37 +1274,34 @@ If a client plans to terminate one or more subscriptions on a session and doesn't intend to keep that session open, then as an efficiency optimization it MAY instead choose to simply close the session, which implicitly terminates all subscriptions on that session. This may occur because the client computer is being shut down, is going to sleep, the application requiring the subscriptions has terminated, or simply because the last active subscription on that session has been cancelled. When closing a session, a client should perform an orderly close of - the TLS session in order to allow for future TLS session resumption - with the server (if available). See Section 7.4 below. Typical APIs - will provide a session close method that will send a TLS close_notify - alert (see Section 6.1 of the TLS 1.3 specification [RFC8446]). This - instructs the recipient that the sender will not send any more data - over the session. After sending the TLS close_notify alert the - client MUST gracefully close the underlying connection using a TCP - FIN, so that the TLS close_notify is reliably delivered. The - mechanisms for gracefully closing a TCP connection with a TCP FIN - vary depending on the networking API. For example, in the BSD - Sockets API, sending a TCP FIN is achieved by calling - "shutdown(s,SHUT_WR)" and keeping the socket open until all remaining - data has been read from it. + the TLS session. Typical APIs will provide a session close method + that will send a TLS close_notify alert (see Section 6.1 of the TLS + 1.3 specification [RFC8446]). This instructs the recipient that the + sender will not send any more data over the session. After sending + the TLS close_notify alert the client MUST gracefully close the + underlying connection using a TCP FIN, so that the TLS close_notify + is reliably delivered. The mechanisms for gracefully closing a TCP + connection with a TCP FIN vary depending on the networking API. For + example, in the BSD Sockets API, sending a TCP FIN is achieved by + calling "shutdown(s,SHUT_WR)" and keeping the socket open until all + remaining data has been read from it. If the session is forcibly closed at the TCP level by sending a RST - from either end of the connection, data may be lost and TLS session - resumption of this session will not be possible. + from either end of the connection, data may be lost. 6.8. Client Fallback to Polling There are cases where a client may exhaust all avenues for establishing a DNS Push Notification subscription without success. This can happen if the client's configured recursive resolver does not support DNS over TLS, or supports DNS over TLS but is not listening on TCP port 853, or supports DNS over TLS on TCP port 853 but does not support DSO on that port, or for some other reason is unable to provide a DNS Push Notification subscription. In this case @@ -1467,29 +1474,33 @@ +-----------------------+------+----------------------+-------------+ | DNS Push Notification | None | "_dns-push-tls._tcp" | Section 6.1 | | Service Type | | | | +-----------------------+------+----------------------+-------------+ Table 4: IANA Service Type Assignments This document also defines four new DNS Stateful Operation TLV types to be recorded in the IANA DSO Type Code Registry. - +-------------+------------+--------+-----------------+-------------+ + +-------------+------------+---------+-----------------+------------+ | Name | Value | Early | Status | Definition | | | | Data | | | - +-------------+------------+--------+-----------------+-------------+ - | SUBSCRIBE | TBA (0x40) | OK | Standards Track | Section 6.2 | - | PUSH | TBA (0x41) | NO | Standards Track | Section 6.3 | - | UNSUBSCRIBE | TBA (0x42) | NO | Standards Track | Section 6.4 | - | RECONFIRM | TBA (0x43) | NO | Standards Track | Section 6.5 | - +-------------+------------+--------+-----------------+-------------+ + +-------------+------------+---------+-----------------+------------+ + | SUBSCRIBE | TBA (0x40) | OK | Standards Track | Section | + | | | | | 6.2 | + | PUSH | TBA (0x41) | NO | Standards Track | Section | + | | | | | 6.3 | + | UNSUBSCRIBE | TBA (0x42) | NO | Standards Track | Section | + | | | | | 6.4 | + | RECONFIRM | TBA (0x43) | NO | Standards Track | Section | + | | | | | 6.5 | + +-------------+------------+---------+-----------------+------------+ Table 5: IANA DSO TLV Type Code Assignments This document defines no new DNS OPCODEs or RCODEs. 9. Acknowledgements The authors would like to thank Kiren Sekar and Marc Krochmal for previous work completed in this field. @@ -1587,25 +1598,24 @@ [ST] "Service Name and Transport Protocol Port Number Registry", . 10.2. Informative References [DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based Service Discovery", draft-ietf-dnssd-hybrid-10 (work in progress), March 2019. - [I-D.dukkipati-tcpm-tcp-loss-probe] - Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, - "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of - Tail Losses", draft-dukkipati-tcpm-tcp-loss-probe-01 (work - in progress), February 2013. + [I-D.ietf-tcpm-rack] + Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "RACK: + a time-based fast loss detection algorithm for TCP", + draft-ietf-tcpm-rack-05 (work in progress), April 2019. [LLQ] Cheshire, S. and M. Krochmal, "DNS Long-Lived Queries", draft-sekar-dns-llq-03 (work in progress), March 2019. [obs] "Observer Pattern", . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, .