--- 1/draft-ietf-dnssd-push-21.txt 2019-07-08 17:20:28.007118038 -0700 +++ 2/draft-ietf-dnssd-push-22.txt 2019-07-08 17:20:28.083119961 -0700 @@ -1,19 +1,19 @@ Internet Engineering Task Force T. Pusateri Internet-Draft Unaffiliated Intended status: Standards Track S. Cheshire -Expires: January 6, 2020 Apple Inc. - July 5, 2019 +Expires: January 9, 2020 Apple Inc. + July 8, 2019 DNS Push Notifications - draft-ietf-dnssd-push-21 + draft-ietf-dnssd-push-22 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 6, 2020. + This Internet-Draft will expire on January 9, 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 @@ -65,29 +65,30 @@ 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 . . . . . . . . . . . . . . . . . . . 31 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 33 - 7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33 + 7.3. TLS Early Data . . . . . . . . . . . . . . . . . . . . . 33 + 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 - 10.2. Informative References . . . . . . . . . . . . . . . . . 36 + 10.2. Informative References . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction Domain Name System (DNS) records may be updated using DNS Update [RFC2136]. Other mechanisms such as a Discovery Proxy [DisProx] can also generate changes to a DNS zone. This document specifies a protocol for DNS clients to subscribe to receive asynchronous notifications of changes to RRSets of interest. It is immediately relevant in the case of DNS Service Discovery [RFC6763] but is not @@ -153,40 +154,40 @@ 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._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 + 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 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 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._tcp." SRV record) + zone (e.g., the in the "_dns-push-tls._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. 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: @@ -228,21 +229,21 @@ 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 which is a potential problem - with connection-less protocols using spoofed source addresses. All + 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) @@ -301,36 +302,36 @@ 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 a DNS Push Notification subscription is to discover - an appropriate DNS server that supports DNS Push Notifications for - the desired zone. + The first step in establishing 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). 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). + Notification subscription is successful, and the recursive resolver + doesn't already have an active subscription for that name, type, and + class, then the recursive resolver will make a corresponding Push + Notification subscription on the client's behalf. Results received + are relayed to the client. This is closely analogous to how a client + sends a normal DNS query to its configured DNS recursive resolver + which, if it doesn't already have appropriate answer(s) in its cache, + issues an upstream query to satisfy the request. 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 @@ -413,22 +414,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._tcp.", where is the owner name of the - discovered SOA record. + "_dns-push-tls._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 @@ -461,29 +462,37 @@ 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. + DSO messages with the SUBSCRIBE TLV as the Primary TLV are permitted + in early data, provided that the precautions described in Section 7.3 + are followed. 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 TLS - close_notify alert. See Section 6.1 of [RFC8446]. + close_notify alert (see Section 6.1 of the TLS 1.3 specification + [RFC8446]). 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. 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 @@ -540,22 +549,22 @@ If accepted, the subscription will stay in effect until the client 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 TLS close_notify alert. + this is a fatal error and the server MUST immediately terminate the + connection with a TLS close_notify alert followed by a TCP FIN. 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 not to any records referenced by the owner name. A client may SUBSCRIBE to records that are unknown to the server at @@ -587,21 +596,21 @@ 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]. 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 Message ID + 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 @@ -691,42 +700,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._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-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. 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._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-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. 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. @@ -770,43 +779,43 @@ 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 TLS close_notify alert. + connection with a TLS close_notify alert followed by a TCP FIN. The change notification records are formatted similarly to how DNS Resource Records are conventionally expressed in DNS messages, as 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 TLS close_notify alert. There are - three types of collective remove notification: + terminate the connection with a TLS close_notify alert followed by a + TCP FIN. 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. @@ -878,21 +887,22 @@ 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 TLS close_notify alert. + immediately terminate the connection with a TLS close_notify alert + followed by a TCP FIN. 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 @@ -981,21 +991,21 @@ 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 TLS close_notify alert. + connection with a TLS close_notify alert followed by a TCP FIN. 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 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. @@ -1221,25 +1231,24 @@ 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.3 below. Typical APIs + 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. 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. + any more data over the session. 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, @@ -1289,77 +1298,97 @@ 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._tcp.". The server connection endpoint SHOULD then - be authenticated using DANE TLSA records for the associated SRV + "_dns-push-tls._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 more information on authenticating domain names. -7.3. TLS Session Resumption +7.3. TLS Early Data + + DSO messages with the SUBSCRIBE TLV as the Primary TLV are permitted + in TLS early data. Using TLS early data can save one network round + trip, and can result in obtaining results faster. However, there are + some factors to consider before using TLS early data. + + TLS Early Data is not forward secret. In cases where forward secrecy + of DNS Push Notification subscriptions is required, the client should + not use TLS Early Data. + + With TLS early data there are no guarantees of non-replay between + connections. If packets are duplicated and delayed in the network, + the later arrivals could be mistaken for new subscription requests. + Generally this is not a major concern, since the amount of state + generated on the server for these spurious subscriptions is small and + short-lived, since the TCP connection will not complete the three-way + handshake. Servers MAY choose to implement rate-limiting measures + that are imposed when the server detects excessive numbers of + spurious subscription requests. + + For further guidance please see Section 2.3, Section 8, and + Appendix E.5 of the TLS 1.3 specification [RFC8446]. + +7.4. TLS Session Resumption TLS Session Resumption is permissible on DNS Push Notification servers. The server may keep TLS state with Session IDs [RFC8446] or operate in stateless mode by sending a Session Ticket [RFC5077] to the client for it to store. However, closing the TLS connection terminates the DSO session. When the TLS session is resumed, the DNS Push Notification server will not have any subscription state and 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._tcp" | Section 6.1 | + +-----------------------+------+----------------------+-------------+ + | 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) | 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 | - +-------------+------------+---------+-----------------+------------+ + +-------------+------------+--------+-----------------+-------------+ + | 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 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