--- 1/draft-ietf-dnssd-push-20.txt 2019-07-05 20:13:04.392843454 -0700 +++ 2/draft-ietf-dnssd-push-21.txt 2019-07-05 20:13:04.464845920 -0700 @@ -1,19 +1,19 @@ Internet Engineering Task Force T. Pusateri Internet-Draft Unaffiliated Intended status: Standards Track S. Cheshire -Expires: December 20, 2019 Apple Inc. - June 18, 2019 +Expires: January 6, 2020 Apple Inc. + July 5, 2019 DNS Push Notifications - draft-ietf-dnssd-push-20 + draft-ietf-dnssd-push-21 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 December 20, 2019. + This Internet-Draft will expire on January 6, 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 @@ -50,36 +50,36 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 5. State Considerations . . . . . . . . . . . . . . . . . . . . 8 - 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 9 - 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 14 - 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 14 - 6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 17 + 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. State Considerations . . . . . . . . . . . . . . . . . . . . 7 + 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 + 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 + 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 13 + 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 13 + 6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 16 6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 20 6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 25 6.4.1. UNSUBSCRIBE Message . . . . . . . . . . . . . . . . . 25 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 27 6.5.1. RECONFIRM Message . . . . . . . . . . . . . . . . . . 28 6.6. DNS Stateful Operations TLV Context Summary . . . . . . . 30 6.7. Client-Initiated Termination . . . . . . . . . . . . . . 31 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 33 7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 @@ -153,55 +153,46 @@ A DNS Push Notification client subscribes for Push Notifications for a particular RRSet by connecting to the appropriate Push Notification server for that RRSet, and sending DSO message(s) indicating the RRSet(s) of interest. When the client loses interest in receiving further updates to these records, it unsubscribes. The DNS Push Notification server for a DNS zone is any server capable of generating the correct change notifications for a name. It may be a primary, secondary, or stealth name server [RFC7719]. - Consequently, the "_dns-push-tls._tcp." SRV record for a zone - MAY reference the same target host and port as that zone's - "_dns-update-tls._tcp." SRV record. When the same target host - and port is offered for both DNS Updates and DNS Push Notifications, - a client MAY use a single TCP connection to that server for both DNS + Consequently, the "_dns-push._tcp." SRV record for a zone MAY + reference the same target host and port as that zone's + "_dns-update._tcp." SRV record. When the same target host and + port is offered for both DNS Updates and DNS Push Notifications, a + client MAY use a single TCP connection to that server for both DNS Updates and DNS Push Notification Subscriptions. Supporting DNS Updates and DNS Push Notifications on the same server - is OPTIONAL. A DNS Push Notification server is NOT REQUIRED also to + is OPTIONAL. A DNS Push Notification server is not required to support DNS Update. DNS Updates and DNS Push Notifications may be handled on different ports on the same target host, in which case they are not considered to be the "same server" for the purposes of this specification, and communications with these two ports are handled independently. Standard DNS Queries MAY be sent over a DNS Push Notification (i.e., DSO) session. For any zone for which the server is authoritative, it MUST respond authoritatively for queries on names falling within that - zone (e.g., the in the "_dns-push-tls._tcp." SRV record) + zone (e.g., the in the "_dns-push._tcp." SRV record) both for normal DNS queries and for DNS Push Notification subscriptions. For names for which the server is acting as a recursive resolver, e.g. when the server is the local recursive resolver, for any query for which it supports DNS Push Notification subscriptions, it MUST also support standard queries. - This DNS Push Notification specification includes support for DNS - classes, for completeness. However, in practice, it is anticipated - that for the foreseeable future the only DNS class in use will be DNS - class "IN", as is the reality today with existing DNS servers and - clients. A DNS Push Notification server MAY choose to implement only - DNS class "IN". If messages are received for a class other than - "IN", and that class is not supported, an error with RCODE NOTIMPL - (Not Implemented) should be returned. - DNS Push Notifications impose less load on the responding server than rapid polling would, but Push Notifications do still have a cost, so DNS Push Notification clients MUST NOT recklessly create an excessive number of Push Notification subscriptions. Specifically: (a) A subscription should only be active when there is a valid reason to need live data (for example, an on-screen display is currently showing the results to the user) and the subscription SHOULD be cancelled as soon as the need for that data ends (for example, when the user dismisses that display). In the case of a device like a @@ -236,29 +227,31 @@ (TCP) [RFC0793] as the transport protocol, in keeping with the historical precedent that DNS queries must first be sent over UDP [RFC1123]. This requirement to use UDP has subsequently been relaxed [RFC7766]. In keeping with the more recent precedent, DNS Push Notification is defined only for TCP. DNS Push Notification clients MUST use DNS Stateful Operations [RFC8490] running over TLS over TCP [RFC7858]. Connection setup over TCP ensures return reachability and alleviates - concerns of state overload at the server through anonymous - subscriptions. 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]. + concerns of state overload at the server which is a potential problem + with connection-less 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. Transport Layer Security (TLS) [RFC8446] is well understood and deployed across many protocols running over TCP. It 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. @@ -308,70 +301,63 @@ server sends relevant asynchronous Push Notifications to the client. Note that a client MUST be prepared to receive (and silently ignore) Push Notifications for subscriptions it has previously removed, since there is no way to prevent the situation where a Push Notification is in flight from server to client while the client's UNSUBSCRIBE message cancelling that subscription is simultaneously in flight from client to server. 6.1. Discovery - The first step in DNS Push Notification subscription is to discover + The first step in a DNS Push Notification subscription is to discover an appropriate DNS server that supports DNS Push Notifications for the desired zone. The client begins by opening a DSO Session to its normal configured DNS recursive resolver and requesting a Push Notification subscription. This connection is made to TCP port 853, the default port for DNS-over-TLS [RFC7858]. If the request for a Push Notification subscription is successful, then the recursive resolver will make a corresponding Push Notification subscription on the client's behalf (if the recursive resolver doesn't already have an - active subscription for that name, type, and class), and pass on any - results it receives back to the client. This is closely analogous to - how a client sends normal DNS queries to its configured DNS recursive - resolver, which issues queries on the client's behalf (if the - recursive resolver doesn't already have appropriate answer(s) in its - cache), and passes on any results it receives back to the client. + active subscription for that name, type, and class). This is closely + analogous to how a client sends normal DNS queries to its configured + DNS recursive resolver, which issues queries on the client's behalf + (if the recursive resolver doesn't already have appropriate answer(s) + in its cache). In many contexts, the recursive resolver will be able to handle Push Notifications for all names that the client may need to follow. Use of VPN tunnels and split-view DNS can create some additional complexity in the client software here; the techniques to handle VPN tunnels and split-view DNS for DNS Push Notifications are the same as those already used to handle this for normal DNS queries. If the recursive resolver does not support DNS over TLS, or does support DNS over TLS but is not listening on TCP port 853, or does support DNS over TLS on TCP port 853 but does not support DSO on that port, then the DSO Session session establishment will fail [RFC8490]. If the recursive resolver does support DSO but not Push Notification subscriptions, then it will return the DSO error code, DSOTYPENI (11). In some cases, the recursive resolver may support DSO and Push Notification subscriptions, but may not be able to subscribe for Push Notifications for a particular name. In this case, the recursive - resolver should return an informative error code to the client so - that the client can make an informed decision how to handle the - error. If the recursive resolver is unable to establish a connection - to the zone's DNS Push Notification server (perhaps because the - required SRV record does not exist) the recursive resolver should - return SERVFAIL. If the recursive resolver is able to establish a - connection to the zone's DNS Push Notification server and some other - error code is then received, the recursive resolver should pass on - this received error code back to the client. In some cases, where - the client has a pre-established trust relationship with the owner of - the zone (that is not handled via the usual mechanisms for VPN - software) the client may handle these failures by contacting the - zone's DNS Push server directly. + resolver should return SERVFAIL to the client. This includes being + unable to establish a connection to the zone's DNS Push Notification + server or establishing a connection but receiving a non success + response code. In some cases, where the client has a pre-established + trust relationship with the owner of the zone (that is not handled + via the usual mechanisms for VPN software) the client may handle + these failures by contacting the zone's DNS Push server directly. In any of the cases described above where the client fails to establish a DNS Push Notification subscription via its configured recursive resolver, the client should proceed to discover the appropriate server for direct communication. The client MUST also determine which TCP port on the server is listening for connections, which need not be (and often is not) the typical TCP port 53 used for conventional DNS, or TCP port 853 used for DNS over TLS. The discovery algorithm described here is an iterative algorithm, @@ -427,22 +413,22 @@ or the query name consists of a single label, i.e., a Top Level Domain (TLD). In the case of a single-label TLD, this is a network configuration error which should not happen and the client gives up. The client may retry the operation at a later time, of the client's choosing, such after a change in network attachment. 5. Once the SOA is known (either by virtue of being seen in the Answer Section, or in the Authority Section), the client sends a DNS query with type SRV [RFC2782] for the record name - "_dns-push-tls._tcp.", where is the owner name of - the discovered SOA record. + "_dns-push._tcp.", where is the owner name of the + discovered SOA record. 6. If the zone in question is set up to offer DNS Push Notifications then this SRV record MUST exist. (If this SRV record does not exist then the zone is not correctly configured for DNS Push Notifications as specified in this document.) The SRV "target" contains the name of the server providing DNS Push Notifications for the zone. The port number on which to contact the server is in the SRV record "port" field. The address(es) of the target host MAY be included in the Additional Section, however, the address records SHOULD be authenticated before use as described @@ -475,26 +461,29 @@ 6.2. DNS Push Notification SUBSCRIBE After connecting, and requesting a longer idle timeout and/or keepalive interval if necessary, a DNS Push Notification client then indicates its desire to receive DNS Push Notifications for a given domain name by sending a SUBSCRIBE request to the server. A SUBSCRIBE request is encoded in a DSO message [RFC8490]. This specification defines a primary DSO TLV for DNS Push Notification SUBSCRIBE Requests (tentatively DSO Type Code 0x40). + DSO messages with the SUBSCRIBE TLV as the Primary TLV are not + permitted in early data. + The entity that initiates a SUBSCRIBE request is by definition the client. A server MUST NOT send a SUBSCRIBE request over an existing session from a client. If a server does send a SUBSCRIBE request over a DSO session initiated by a client, this is a fatal error and - the client should immediately abort the connection with a TCP RST (or - equivalent for other protocols). + the client should immediately abort the connection with a TLS + close_notify alert. See Section 6.1 of [RFC8446]. 6.2.1. SUBSCRIBE Request A SUBSCRIBE request begins with the standard DSO 12-byte header [RFC8490], followed by the SUBSCRIBE primary TLV. A SUBSCRIBE request message is illustrated in Figure 1. The MESSAGE ID field MUST be set to a unique value, that the client is not using for any other active operation on this DSO session. For the purposes here, a MESSAGE ID is in use on this session if the @@ -552,28 +541,29 @@ cancels the subscription using UNSUBSCRIBE or until the DSO session between the client and the server is closed. SUBSCRIBE requests on a given session MUST be unique. A client MUST NOT send a SUBSCRIBE message that duplicates the NAME, TYPE and CLASS of an existing active subscription on that DSO session. For the purpose of this matching, the established DNS case-insensitivity for US-ASCII letters applies (e.g., "example.com" and "Example.com" are the same). If a server receives such a duplicate SUBSCRIBE message this is an error and the server MUST immediately terminate the - connection with a TCP RST (or equivalent for other protocols). + connection with a TLS close_notify alert. DNS wildcarding is not supported. That is, a wildcard ("*") in a SUBSCRIBE message matches only a literal wildcard character ("*") in the zone, and nothing else. Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message - matches only a literal CNAME record in the zone, and nothing else. + matches only a literal CNAME record in the zone, and not to any + records referenced by the owner name. 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 zone(s) the server is responsible for) and this is not an error. The server MUST NOT return NXDOMAIN in this case. The server MUST accept these requests and send Push Notifications if and when matching records are found in the future. 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 @@ -593,32 +583,51 @@ 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 the server. A SUBSCRIBE response begins with the standard DSO 12-byte header - [RFC8490], possibly followed by one or more optional TLVs, such as a - Retry Delay TLV. + [RFC8490]. The QR bit in the header is set indicating it is a + response. The header MAY be followed by one or more optional TLVs, + such as a Retry Delay TLV. - The MESSAGE ID field MUST echo the value given in the ID field of the - SUBSCRIBE request. This is how the client knows which request is - being responded to. + The MESSAGE ID field MUST echo the value given in the Message ID + field of the SUBSCRIBE request. This is how the client knows which + request is being responded to. A SUBSCRIBE response message MUST NOT include a SUBSCRIBE TLV. If a client receives a SUBSCRIBE response message containing a SUBSCRIBE TLV then the response message is processed but the SUBSCRIBE TLV MUST be silently ignored. + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ + | MESSAGE ID | \ + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | + |QR| OPCODE(6) | Z | RCODE | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | + | QDCOUNT (MUST BE ZERO) | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER + | ANCOUNT (MUST BE ZERO) | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | + | NSCOUNT (MUST BE ZERO) | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | + | ARCOUNT (MUST BE ZERO) | / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / + + Figure 2: SUBSCRIBE Response Message + In the SUBSCRIBE response the RCODE indicates whether or not the subscription was accepted. Supported RCODEs are as follows: +-----------+-------+-----------------------------------------------+ | Mnemonic | Value | Description | +-----------+-------+-----------------------------------------------+ | NOERROR | 0 | SUBSCRIBE successful. | | FORMERR | 1 | Server failed to process request due to a | | | | malformed request. | | SERVFAIL | 2 | Server failed to process request due to a | @@ -682,42 +691,42 @@ the retry delay SHOULD be one hour. Note that in such a case, a server that doesn't implement DSO is unlikely to place a Retry Delay TLV in its response, so this recommended value in particular applies to what a client should assume by default. For RCODE = 5 (REFUSED), which occurs on a server that implements DNS Push Notifications, but is currently configured to disallow DNS Push Notifications, the retry delay may be any value selected by the implementer and/or configured by the operator. - If the server being queried is listed in a - "_dns-push-tls._tcp." SRV record for the zone, then this is - a misconfiguration, since this server is being advertised as - supporting DNS Push Notifications for this zone, but the server - itself is not currently configured to perform that task. Since it - is possible that the misconfiguration may be repaired at any time, - the retry delay should not be set too high. By default, a value - of 5 minutes is RECOMMENDED. + If the server being queried is listed in a "_dns-push._tcp." + SRV record for the zone, then this is a misconfiguration, since + this server is being advertised as supporting DNS Push + Notifications for this zone, but the server itself is not + currently configured to perform that task. Since it is possible + that the misconfiguration may be repaired at any time, the retry + delay should not be set too high. By default, a value of 5 + minutes is RECOMMENDED. For RCODE = 9 (NOTAUTH), which occurs on a server that implements DNS Push Notifications, but is not configured to be authoritative for the requested name, the retry delay may be any value selected by the implementer and/or configured by the operator. - If the server being queried is listed in a - "_dns-push-tls._tcp." SRV record for the zone, then this is - a misconfiguration, since this server is being advertised as - supporting DNS Push Notifications for this zone, but the server - itself is not currently configured to perform that task. Since it - is possible that the misconfiguration may be repaired at any time, - the retry delay should not be set too high. By default, a value - of 5 minutes is RECOMMENDED. + If the server being queried is listed in a "_dns-push._tcp." + SRV record for the zone, then this is a misconfiguration, since + this server is being advertised as supporting DNS Push + Notifications for this zone, but the server itself is not + currently configured to perform that task. Since it is possible + that the misconfiguration may be repaired at any time, the retry + delay should not be set too high. By default, a value of 5 + minutes is RECOMMENDED. For RCODE = 11 (DSOTYPENI), which occurs on a server that implements DSO but doesn't implement DNS Push Notifications, it is unlikely that the server will begin supporting DNS Push Notifications in the next few minutes, so the retry delay SHOULD be one hour. For other RCODE values, the retry delay should be set by the server as appropriate for that error condition. By default, a value of 5 minutes is RECOMMENDED. @@ -741,63 +750,63 @@ case that the answer set was already non-empty at the moment the subscription was established, an initial PUSH message will be sent immediately following the SUBSCRIBE Response. Subsequent changes to the answer set are then communicated to the client in subsequent PUSH messages. 6.3.1. PUSH Message A PUSH unidirectional message begins with the standard DSO 12-byte header [RFC8490], followed by the PUSH primary TLV. A PUSH message - is illustrated in Figure 2. + is illustrated in Figure 3. In accordance with the definition of DSO unidirectional messages, the MESSAGE ID field MUST be zero. There is no client response to a PUSH message. The other header fields MUST be set as described in the DSO spec- ification [RFC8490]. The DNS OPCODE field contains the OPCODE value for DNS Stateful Operations (6). The four count fields MUST be zero, and the corresponding four sections MUST be empty (i.e., absent). The DSO-TYPE is PUSH (tentatively 0x41). The DSO-LENGTH is the length of the DSO-DATA that follows, which specifies the changes being communicated. The DSO-DATA contains one or more change notifications. A PUSH Message MUST contain at least one change notification. If a PUSH Message is received that contains no change notifications, this is a fatal error, and the receiver MUST immediately terminate the - connection with a TCP RST (or equivalent for other protocols). + connection with a TLS close_notify alert. The change notification records are formatted similarly to how DNS Resource Records are conventionally expressed in DNS messages, as - illustrated in Figure 2, and are interpreted as described below. + illustrated in Figure 3, and are interpreted as described below. The TTL field holds an unsigned 32-bit integer [RFC2181]. If the TTL is in the range 0 to 2,147,483,647 seconds (2^31 - 1, or 0x7FFFFFFF), then a new DNS Resource Record with the given name, type, class and RDATA is added. A TTL of 0 means that this record should be retained for as long as the subscription is active, and should be discarded immediately the moment the subscription is cancelled. If the TTL has the value 0xFFFFFFFF, then the DNS Resource Record with the given name, type, class and RDATA is removed. If the TTL has the value 0xFFFFFFFE, then this is a 'collective' remove notification. For collective remove notifications RDLEN MUST be zero and consequently the RDATA MUST be empty. If a change notification is received where TTL = 0xFFFFFFFE and RDLEN is not zero, this is a fatal error, and the receiver MUST immediately - terminate the connection with a TCP RST (or equivalent for other - protocols). There are three types of collective remove notification: + terminate the connection with a TLS close_notify alert. There are + three types of collective remove notification: 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. For collective remove notifications, if CLASS is not 255 (ANY) and TYPE is 255 (ANY) then for the given name this deletes all records of all types in the specified class. @@ -869,22 +878,21 @@ MUST NOT generate PUSH messages larger than this. Where the immediately available change notifications are sufficient to exceed a DNS message length of 16,382 bytes, the change notifications MUST be communicated in separate PUSH messages of up to 16,382 bytes each. DNS name compression becomes less effective for messages larger than 16,384 bytes, so little efficiency benefit is gained by sending messages larger than this. If a client receives a PUSH message with a DNS message length larger than 16,382 bytes, the this is a fatal error, and the receiver MUST - immediately terminate the connection with a TCP RST (or equivalent - for other protocols). + immediately terminate the connection with a TLS close_notify alert. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ | MESSAGE ID (MUST BE ZERO) | \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |QR| OPCODE(6) | Z | RCODE | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | QDCOUNT (MUST BE ZERO) | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER @@ -908,21 +916,21 @@ | (32-bit unsigned big-endian integer) | > DSO-DATA +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | RDLEN | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | \ RDATA (sized as necessary) \ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | : NAME, TYPE, CLASS, TTL, RDLEN, RDATA : | : Repeated As Necessary : / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / - Figure 2: PUSH Message + Figure 3: PUSH Message When processing the records received in a PUSH Message, the receiving client MUST validate that the records being added or deleted correspond with at least one currently active subscription on that session. Specifically, the record name MUST match the name given in a SUBSCRIBE request, subject to the usual established DNS case- insensitivity for US-ASCII letters. If the TYPE in the SUBSCRIBE request was not ANY (255) then the TYPE of the record must match the TYPE given in the SUBSCRIBE request. If the CLASS in the SUBSCRIBE request was not ANY (255) then the CLASS of the record must match the @@ -973,27 +981,27 @@ To cancel an individual subscription without closing the entire DSO session, the client sends an UNSUBSCRIBE message over the established DSO session to the server. The UNSUBSCRIBE message is encoded as a DSO unidirectional message [RFC8490]. This specification defines a primary unidirectional DSO TLV for DNS Push Notification UNSUBSCRIBE Messages (tentatively DSO Type Code 0x42). A server MUST NOT initiate an UNSUBSCRIBE message. If a server does send an UNSUBSCRIBE message over a DSO session initiated by a client, this is a fatal error and the client should immediately abort the - connection with a TCP RST (or equivalent for other protocols). + connection with a TLS close_notify alert. 6.4.1. UNSUBSCRIBE Message An UNSUBSCRIBE unidirectional message begins with the standard DSO 12-byte header [RFC8490], followed by the UNSUBSCRIBE primary TLV. - An UNSUBSCRIBE message is illustrated in Figure 3. + An UNSUBSCRIBE message is illustrated in Figure 4. In accordance with the definition of DSO unidirectional messages, the MESSAGE ID field MUST be zero. There is no server response to an UNSUBSCRIBE message. The other header fields MUST be set as described in the DSO spec- ification [RFC8490]. The DNS OPCODE field contains the OPCODE value for DNS Stateful Operations (6). The four count fields MUST be zero, and the corresponding four sections MUST be empty (i.e., absent). @@ -1037,21 +1045,21 @@ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | ARCOUNT (MUST BE ZERO) | / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / | DSO-TYPE = UNSUBSCRIBE (tentatively 0x42) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | DSO-LENGTH (2) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ | SUBSCRIBE MESSAGE ID | > DSO-DATA +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / - Figure 3: UNSUBSCRIBE Message + Figure 4: UNSUBSCRIBE Message 6.5. DNS Push Notification RECONFIRM Sometimes, particularly when used with a Discovery Proxy [DisProx], a DNS Zone may contain stale data. When a client encounters data that it believes may be stale (e.g., an SRV record referencing a target host+port that is not responding to connection requests) the client can send a RECONFIRM message to ask the server to re-verify that the data is still valid. For a Discovery Proxy, this causes it to issue new Multicast DNS queries to ascertain whether the target device is @@ -1077,21 +1085,21 @@ subsequent DNS PUSH Messages will be generated to inform interested clients. Thus, one client discovering that a previously-advertised device (like a network printer) is no longer present has the side effect of informing all other interested clients that the device in question is now gone. 6.5.1. RECONFIRM Message A RECONFIRM unidirectional message begins with the standard DSO 12-byte header [RFC8490], followed by the RECONFIRM primary TLV. - A RECONFIRM message is illustrated in Figure 4. + A RECONFIRM message is illustrated in Figure 5. In accordance with the definition of DSO unidirectional messages, the MESSAGE ID field MUST be zero. There is no server response to a RECONFIRM message. The other header fields MUST be set as described in the DSO spec- ification [RFC8490]. The DNS OPCODE field contains the OPCODE value for DNS Stateful Operations (6). The four count fields MUST be zero, and the corresponding four sections MUST be empty (i.e., absent). @@ -1122,21 +1130,21 @@ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ \ NAME \ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | TYPE | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA | CLASS | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | \ RDATA \ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / - Figure 4: RECONFIRM Message + Figure 5: RECONFIRM Message The DSO-DATA for a RECONFIRM message MUST contain exactly one record. The DSO-DATA for a RECONFIRM message has no count field to specify more than one record. Since RECONFIRM messages are sent over TCP, multiple RECONFIRM messages can be concatenated in a single TCP stream and packed efficiently into TCP segments. TYPE MUST NOT be the value ANY (255) and CLASS MUST NOT be the value ANY (255). @@ -1211,33 +1219,31 @@ 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 will generally do an abortive - disconnect, sending a TCP RST. This immediately discards all - remaining inbound and outbound data, which is appropriate if the - client no longer has any interest in this data. In the BSD Sockets - API, sending a TCP RST is achieved by setting the SO_LINGER option - with a time of 0 seconds and then closing the socket. + 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.3 below. Typical APIs + will provide a session close method that will send a TLS close_notify + alert. This instructs the recipient that the sender will not send + any more data over the session. Any pending writes on the server + will be discarded when a close_notify is received. - If a client has performed operations on this session that it would - not want lost (like DNS updates) then the client SHOULD do an orderly - disconnect, sending a TLS close_notify followed by a TCP FIN. (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. 7. Security Considerations The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS Push Notifications [RFC8310]. Cleartext connections for DNS Push Notifications are not permissible. Since this is a new protocol, transition mechanisms from the Opportunistic Privacy profile are unnecessary. Also, see Section 9 of the DNS over (D)TLS Usage Profiles document @@ -1283,22 +1289,22 @@ suites are beyond the scope of this document. Please refer to TLS Recommendations [RFC7525] for the best current practices. Keep in mind that best practices only exist for a snapshot in time and recommendations will continue to change. Updated versions or errata may exist for these recommendations. 7.2. TLS Name Authentication As described in Section 6.1, the client discovers the DNS Push Notification server using an SRV lookup for the record name - "_dns-push-tls._tcp.". The server connection endpoint SHOULD - then be authenticated using DANE TLSA records for the associated SRV + "_dns-push._tcp.". The server connection endpoint SHOULD then + be authenticated using DANE TLSA records for the associated SRV record. This associates the target's name and port number with a trusted TLS certificate [RFC7673]. This procedure uses the TLS Server Name Indication (SNI) extension [RFC6066] to inform the server of the name the client has authenticated through the use of TLSA records. Therefore, if the SRV record passes DNSSEC validation and a TLSA record matching the target name is useable, an SNI extension must be used for the target name to ensure the client is connecting to the server it has authenticated. If the target name does not have a usable TLSA record, then the use of the SNI extension is optional. See Usage Profiles for DNS over TLS and DNS over DTLS [RFC8310] for @@ -1315,40 +1321,45 @@ will proceed as with any other new DSO session. Use of TLS Session Resumption may allow a TLS connection to be set up more quickly, but the client will still have to recreate any desired subscriptions. 8. IANA Considerations This document defines a new service name to be published in the IANA Registry Service Types [RFC6335][ST] that is only applicable for the TCP protocol. - +-----------------------+------+----------------------+-------------+ + +---------------------------+------+------------------+-------------+ | Name | Port | Value | Definition | - +-----------------------+------+----------------------+-------------+ - | DNS Push Notification | None | "_dns-push-tls._tcp" | Section 6.1 | + +---------------------------+------+------------------+-------------+ + | DNS Push Notification | None | "_dns-push._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 | Definition | - +-------------+------------------------+-------------+ - | SUBSCRIBE | TBA (tentatively 0x40) | Section 6.2 | - | PUSH | TBA (tentatively 0x41) | Section 6.3 | - | UNSUBSCRIBE | TBA (tentatively 0x42) | Section 6.4 | - | RECONFIRM | TBA (tentatively 0x43) | Section 6.5 | - +-------------+------------------------+-------------+ + +-------------+------------+---------+-----------------+------------+ + | Name | Value | Early | Status | Definition | + | | | Data | | | + +-------------+------------+---------+-----------------+------------+ + | SUBSCRIBE | TBA (0x40) | NO | Standards Track | Section | + | | | | | 6.2 | + | PUSH | TBA (0x41) | NA | Standards Track | Section | + | | | | | 6.3 | + | UNSUBSCRIBE | TBA (0x42) | NA | Standards Track | Section | + | | | | | 6.4 | + | RECONFIRM | TBA (0x43) | NA | Standards Track | Section | + | | | | | 6.5 | + +-------------+------------+---------+-----------------+------------+ Table 5: IANA DSO TLV Type Code Assignments 9. 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, Tim Chown, Mark Delany, Ralph Droms, Bernie Volz, Jan Komissar, Manju