--- 1/draft-ietf-dnssd-push-17.txt 2019-03-11 17:22:06.809590908 -0700 +++ 2/draft-ietf-dnssd-push-18.txt 2019-03-11 17:22:07.013595912 -0700 @@ -1,19 +1,19 @@ Internet Engineering Task Force T. Pusateri Internet-Draft Unaffiliated Intended status: Standards Track S. Cheshire -Expires: September 10, 2019 Apple Inc. - March 9, 2019 +Expires: September 12, 2019 Apple Inc. + March 11, 2019 DNS Push Notifications - draft-ietf-dnssd-push-17 + draft-ietf-dnssd-push-18 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 September 10, 2019. + This Internet-Draft will expire on September 12, 2019. 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 @@ -59,25 +59,24 @@ 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 6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 20 6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20 - 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 23 - 6.4.1. UNSUBSCRIBE Request . . . . . . . . . . . . . . . . . 23 - 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 25 - 6.5.1. RECONFIRM Request . . . . . . . . . . . . . . . . . . 25 - 6.5.2. RECONFIRM Response . . . . . . . . . . . . . . . . . 28 + 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.1. Security Services . . . . . . . . . . . . . . . . . . . . 32 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 32 7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 @@ -141,44 +140,34 @@ handshake, flow control, and reliability. This document builds on experience gained with the LLQ protocol, with an improved design. Instead of using UDP, this specification uses DNS Stateful Operations (DSO) [DSO] running over TLS over TCP, and therefore doesn't need to reinvent existing TCP functionality. Using TCP also gives long-lived low-traffic connections better longevity through NAT gateways without depending on the gateway to support NAT Port Mapping Protocol (NAT-PMP) [RFC6886] or Port Control Protocol (PCP) [RFC6887], or resorting to excessive keepalive traffic. - Instead of inventing a new vocabulary of messages to communicate DNS - zone changes as LLQ did, this specification borrows the established - syntax and semantics of DNS Update messages [RFC2136]. 3. Overview - The existing DNS Update protocol [RFC2136] provides a mechanism for - clients to add or delete individual resource records (RRs) or entire - resource record sets (RRSets) on the zone's server. - - This specification adopts a simplified subset of these existing - syntax and semantics, and uses them for DNS Push Notification - messages going in the opposite direction, from server to client, to - communicate changes to a name's records. The client subscribes for - Push Notifications by connecting to the server and sending DNS - message(s) indicating the RRSet(s) of interest. When the client - loses interest in receiving further updates to these records, it - unsubscribes. + 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 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 + 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 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 support DNS Update. DNS Updates and DNS Push Notifications may be handled on different @@ -189,27 +178,20 @@ 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) 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 Notification clients are NOT required to implement DNS - Update Prerequisite processing. Prerequisites are used to perform - tentative atomic test-and-set type operations when a client updates - records on a server, and that concept has no applicability when it - comes to an authoritative server unilaterally informing a client of - changes to DNS records. - 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 @@ -775,42 +757,131 @@ The other header fields MUST be set as described in the DSO specification [DSO]. 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 Update records. A PUSH Message - MUST contain at least one Update record. If a PUSH Message is - received that contains zero Update records, this is a fatal error, - and the receiver MUST immediately terminate the connection with a TCP - RST (or equivalent for other protocols). The Update records are - formatted in the customary way for Resource Records in DNS messages. - Update records in a PUSH Message are interpreted according to the - same rules as for DNS Update [RFC2136] messages, namely: + 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). The + change notifications are formatted similarly to how DNS Resource + Records are conventionally expressed in DNS messages, and are + interpreted as described below. - Delete all RRsets from a name: - TTL=0, CLASS=ANY, RDLENGTH=0, TYPE=ANY. + If the signed 32-bit TTL is in the range 0 to 604,800 seconds (one + week), then a new DNS Resource Record with the given name, type, + class and RDATA is added. The maximum record lifetime supported in a + PUSH Message is one week. In the event that the DNS record in + question has an actual TTL greater than one week, the TTL is reported + in the PUSH Message as being one week. 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. - Delete an RRset from a name: - TTL=0, CLASS=ANY, RDLENGTH=0; - TYPE specifies the RRset being deleted. + If the signed 32-bit TTL has the value -1, then the DNS Resource + Record with the given name, type, class and RDATA is removed. + + If the signed 32-bit TTL has the value -2, 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 = -2 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: + + For collective remove notifications, if CLASS is ANY, then for the + given name this deletes all records of all types in all classes. In + this case TYPE MUST be set to ANY on tranmission, and MUST be + silently ignored on reception. + + For collective remove notifications, if CLASS is not ANY and TYPE is + is ANY then for the given name this deletes all records of all types + in the specified class. + + For collective remove notifications, if CLASS is not ANY and TYPE is + is not ANY then for the given name this deletes all records of the + specified type in the specified class. + + Summary of change notification types: + + Delete all RRsets from a name, in all classes + TTL=-2, RDLENGTH=0, TYPE=ANY, CLASS=ANY + + Delete all RRsets from a name, in given class: + TTL=-2, RDLENGTH=0, TYPE=ANY + CLASS specifies class (usually class "IN") + + Delete specified RRset from a name, in given class: + TTL=-2, RDLENGTH=0 + CLASS and TYPE specify the RRset being deleted Delete an individual RR from a name: - TTL=0, CLASS=NONE; - TYPE, RDLENGTH and RDATA specifies the RR being deleted. + TTL=-1 + CLASS, TYPE, RDLENGTH and RDATA specify the RR being deleted. - Add to an RRset: - TTL, CLASS, TYPE, RDLENGTH and RDATA specifies the RR being added. + Add individual RR to a name + TTL>=0 + CLASS, TYPE, RDLENGTH, 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 >= 0, this change + notification signals the addition of a record with the given name, + type, class, and empty RDATA. If RDLEN=0 and TTL = -1, this change + notification signals the removal specifically of that single record + with the given name, type, class, and empty RDATA. + + 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 + DSO message. Once it has exhausted the list of change notifications + immediately available to send, a server SHOULD then send the PUSH + message immediately, rather than waiting to see if additional change + notifications become available. + + For efficiency, when generating a PUSH message, a server SHOULD use + standard DNS name compression, with offsets relative to the beginning + of the DNS message [RFC1035]. When multiple change notifications in + a single PUSH message have the same owner name, this name compression + can yield significant savings. Name compression should be performed + as specified in Section 18.14 of the Multicast DNS specification + [RFC6762], namely, owner names should always be compressed, and names + appearing within only the RDATA of the following DNS types should be + compressed: + + NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC + + Servers MAY generate PUSH messages up to a DNS message length of + 16,382 bytes, counting from the start of the DSO 12-byte header. + Including the two-byte length prefix that is used to frame DNS over a + byte stream like TLS, this makes a total of 16,384 bytes. Servers + SHOULD 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 SHOULD + 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). 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 @@ -824,25 +895,25 @@ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | DSO-LENGTH (number of octets in DSO-DATA) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ \ NAME \ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | TYPE | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | CLASS | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | TTL | | - | (32 bits) | > DSO-DATA + | (32-bit signed big-endian integer) | > DSO-DATA +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | RDLEN | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | - \ RDATA \ | + \ RDATA (sized as necessary) \ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | : NAME, TYPE, CLASS, TTL, RDLEN, RDATA : | : Repeated As Necessary : / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / Figure 2: 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 @@ -894,65 +965,65 @@ aging for records covered by the subscription resumes and records are removed from the local cache when their TTL reaches zero. 6.4. DNS Push Notification UNSUBSCRIBE 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 [DSO]. This specification defines a primary unidirectional DSO TLV for DNS Push Notification UNSUBSCRIBE - Requests (tentatively DSO Type Code 0x42). + Messages (tentatively DSO Type Code 0x42). - A server MUST NOT initiate an UNSUBSCRIBE request. If a server does - send an UNSUBSCRIBE request over a DSO session initiated by a client, + 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). -6.4.1. UNSUBSCRIBE Request +6.4.1. UNSUBSCRIBE Message - An UNSUBSCRIBE request begins with the standard DSO 12-byte header - [DSO], followed by the UNSUBSCRIBE primary TLV. An UNSUBSCRIBE - request message is illustrated in Figure 3. + An UNSUBSCRIBE unidirectional message begins with the standard DSO + 12-byte header [DSO], followed by the UNSUBSCRIBE primary TLV. An + UNSUBSCRIBE message is illustrated in Figure 3. In accordance with the definition of DSO unidirectional messages, the - MESSAGE ID field MUST be zero. There is no server response to a + 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 specification [DSO]. 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 UNSUBSCRIBE (tentatively 0x42). The DSO-LENGTH field contains the value 2, the length of the 2-octet MESSAGE ID contained in the DSO-DATA. The DSO-DATA contains the value given in the MESSAGE ID field of an active SUBSCRIBE request. This is how the server knows which SUBSCRIBE request is being cancelled. After receipt of the - UNSUBSCRIBE request, the SUBSCRIBE request is no longer active. + UNSUBSCRIBE message, the SUBSCRIBE request is no longer active. - It is allowable for the client to issue an UNSUBSCRIBE request for a + It is allowable for the client to issue an UNSUBSCRIBE message for a previous SUBSCRIBE request for which the client has not yet received a SUBSCRIBE response. This is to allow for the case where a client starts and stops a subscription in less than the round-trip time to the server. The client is NOT required to wait for the SUBSCRIBE - response before issuing the UNSUBSCRIBE request. + response before issuing the UNSUBSCRIBE message. Consequently, it is possible for a server to receive an UNSUBSCRIBE - request that does not match any currently active subscription. This + message that does not match any currently active subscription. This can occur when a client sends a SUBSCRIBE request, which subsequently fails and returns an error code, but the client sent an UNSUBSCRIBE - request before it became aware that the SUBSCRIBE request had failed. - Because of this, servers MUST silently ignore UNSUBSCRIBE requests + message before it became aware that the SUBSCRIBE request had failed. + Because of this, servers MUST silently ignore UNSUBSCRIBE messages that do not match any currently active subscription. 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) | | @@ -963,69 +1034,65 @@ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | ARCOUNT (MUST BE ZERO) | / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / | DSO-TYPE = UNSUBSCRIBE (tentatively 0x42) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | DSO-LENGTH (2) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ | SUBSCRIBE MESSAGE ID | > DSO-DATA +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / - Figure 3: UNSUBSCRIBE Request + Figure 3: 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 request to ask the server to re-verify that the + 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 requests to ascertain whether the target device is + new Multicast DNS queries to ascertain whether the target device is still present. How the Discovery Proxy causes these new Multicast - DNS requests to be issued depends on the details of the underlying - Multicast DNS being used. For example, a Discovery Proxy built on - Apple's dns_sd.h API responds to a DNS Push Notification RECONFIRM - message by calling the underlying API's DNSServiceReconfirmRecord() - routine. + DNS queries to be issued depends on the details of the underlying + Multicast DNS implementation being used. For example, a Discovery + Proxy built on Apple's dns_sd.h API responds to a DNS Push + Notification RECONFIRM message by calling the underlying API's + DNSServiceReconfirmRecord() routine. For other types of DNS server, the RECONFIRM operation is currently undefined, and SHOULD result in a NOERROR response, but otherwise need not cause any action to occur. Frequent use of RECONFIRM operations may be a sign of network unreliability, or some kind of misconfiguration, so RECONFIRM operations MAY be logged or otherwise communicated to a human administrator to assist in detecting, and remedying, such network problems. - If, after receiving a valid RECONFIRM request, the server determines + If, after receiving a valid RECONFIRM message, the server determines that the disputed records are in fact no longer valid, then 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 Request +6.5.1. RECONFIRM Message - A RECONFIRM request begins with the standard DSO 12-byte header - [DSO], followed by the RECONFIRM primary TLV. A RECONFIRM request - message is illustrated in Figure 4. + A RECONFIRM unidirectional message begins with the standard DSO + 12-byte header [DSO], followed by the RECONFIRM primary TLV. A + RECONFIRM message is illustrated in Figure 4. - 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 - client has used it in a request for which it has not yet received a - response, or if the client has used it for a subscription which it - has not yet cancelled using UNSUBSCRIBE. In the RECONFIRM response - the server MUST echo back the MESSAGE ID value unchanged. + 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 specification [DSO]. 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 RECONFIRM (tentatively 0x43). The DSO-LENGTH is the length of the data that follows, which specifies the name, type, class, and content of the record being @@ -1052,119 +1119,38 @@ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ \ NAME \ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | TYPE | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA | CLASS | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | \ RDATA \ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / - Figure 4: RECONFIRM Request + Figure 4: RECONFIRM Message - The DSO-DATA for a RECONFIRM request MUST contain exactly one record. - The DSO-DATA for a RECONFIRM request has no count field to specify - more than one record. Since RECONFIRM requests are sent over TCP, - multiple RECONFIRM request messages can be concatenated in a single - TCP stream and packed efficiently into TCP segments. + 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). DNS wildcarding is not supported. That is, a wildcard ("*") in a RECONFIRM message matches only a literal wildcard character ("*") in the zone, and nothing else. Aliasing is not supported. That is, a CNAME in a RECONFIRM message matches only a literal CNAME record in the zone, and nothing else. -6.5.2. RECONFIRM Response - - Each RECONFIRM request generates exactly one RECONFIRM response from - the server. - - A RECONFIRM response begins with the standard DSO 12-byte header - [DSO], possibly followed by one or more optional TLVs, such as a - Retry Delay TLV. For suggested values for the Retry Delay TLV, see - Section 6.2.2. - - The MESSAGE ID field MUST echo the value given in the ID field of the - RECONFIRM request. This is how the client knows which request is - being responded to. - - A RECONFIRM response message MUST NOT include a DSO RECONFIRM TLV. - If a client receives a RECONFIRM response message containing a - RECONFIRM TLV then the response message is processed but the - RECONFIRM TLV MUST be silently ignored. - - In the RECONFIRM response the RCODE confirms receipt of the - reconfirmation request. Supported RCODEs are as follows: - - +-----------+-------+-----------------------------------------------+ - | Mnemonic | Value | Description | - +-----------+-------+-----------------------------------------------+ - | NOERROR | 0 | RECONFIRM accepted. | - | FORMERR | 1 | Server failed to process request due to a | - | | | malformed request. | - | SERVFAIL | 2 | Server failed to process request due to a | - | | | problem with the server. | - | NOTIMP | 4 | Server does not implement DSO. | - | REFUSED | 5 | Server refuses to process request for policy | - | | | or security reasons. | - | NOTAUTH | 9 | Server is not authoritative for the requested | - | | | name. | - | DSOTYPENI | 11 | RECONFIRM operation not supported. | - +-----------+-------+-----------------------------------------------+ - - Table 2: RECONFIRM Response codes - - This document specifies only these RCODE values for RECONFIRM - Responses. Servers sending RECONFIRM Responses SHOULD use one of - these values. Note that NXDOMAIN is not a valid RCODE in response to - a RECONFIRM Request. However, future circumstances may create - situations where other RCODE values are appropriate in RECONFIRM - Responses, so clients MUST be prepared to accept RECONFIRM Responses - with any other RCODE value. - - Nonzero RCODE values signal some kind of error. - - RCODE value FORMERR indicates a message format error, for example - TYPE or CLASS being ANY (255). - - RCODE value SERVFAIL indicates that the server has exhausted its - resources or other serious problem occurred. - - RCODE values NOTIMP indicates that the server does not support DSO, - and DSO is required for RECONFIRM requests. - - RCODE value REFUSED indicates that the server supports RECONFIRM - requests but is currently not configured to accept them from this - client. - - RCODE value NOTAUTH indicates that the server is not authoritative - for the requested name, and can do nothing to remedy the apparent - error. Note that there may be future cases in which a server is able - to pass on the RECONFIRM request to the ultimate source of the - information, and in these cases the server should return NOERROR. - - RCODE value DSOTYPENI indicates that the server does not support - RECONFIRM requests. - - Nonzero RCODE values SERVFAIL, REFUSED and DSOTYPENI are benign from - the client's point of view. The client may log them to aid in - debugging, but otherwise they require no special action. - - Nonzero RCODE values other than these three indicate a serious - problem with the client. After sending an error response other than - one of these three, the server SHOULD send a DSO Retry Delay TLV to - end the DSO session, as described in the DSO specification [DSO]. - 6.6. DNS Stateful Operations TLV Context Summary This document defines four new DSO TLVs. As suggested in Section 8.2 of the DNS Stateful Operations specification [DSO], the valid contexts of these new TLV types are summarized below. The client TLV contexts are: C-P: Client request message, primary TLV C-U: Client unidirectional message, primary TLV @@ -1174,40 +1160,40 @@ +-------------+-----+-----+-----+-----+-----+ | TLV Type | C-P | C-U | C-A | CRP | CRA | +-------------+-----+-----+-----+-----+-----+ | SUBSCRIBE | X | | | | | | PUSH | | | | | | | UNSUBSCRIBE | | X | | | | | RECONFIRM | X | | | | | +-------------+-----+-----+-----+-----+-----+ - Table 3: DSO TLV Client Context Summary + Table 2: DSO TLV Client Context Summary The server TLV contexts are: S-P: Server request message, primary TLV S-U: Server unidirectional message, primary TLV S-A: Server request or unidirectional message, additional TLV SRP: Response back to server, primary TLV SRA: Response back to server, additional TLV +-------------+-----+-----+-----+-----+-----+ | TLV Type | S-P | S-U | S-A | SRP | SRA | +-------------+-----+-----+-----+-----+-----+ | SUBSCRIBE | | | | | | | PUSH | | X | | | | | UNSUBSCRIBE | | | | | | | RECONFIRM | | | | | | +-------------+-----+-----+-----+-----+-----+ - Table 4: DSO TLV Server Context Summary + Table 3: DSO TLV Server Context Summary 6.7. Client-Initiated Termination An individual subscription is terminated by sending an UNSUBSCRIBE TLV for that specific subscription, or all subscriptions can be cancelled at once by the client closing the DSO session. When a client terminates an individual subscription (via UNSUBSCRIBE) or all subscriptions on that DSO session (by ending the session) it is signaling to the server that it is longer interested in receiving those particular updates. It is informing the server that the server @@ -1322,35 +1308,35 @@ 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 | | Service Type | | | | +-----------------------+------+----------------------+-------------+ - Table 5: IANA Service Type Assignments + 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 | +-------------+------------------------+-------------+ - Table 6: IANA DSO TLV Type Code Assignments + 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 Shankar Rao, Markus Stenberg, Dave Thaler, Soraia Zlatkovic, Sara Dickinson, and Andrew Sullivan. Ted Lemon provided clarifying text @@ -1454,20 +1440,24 @@ [LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- llq-01 (work in progress), August 2006. [obs] "Observer Pattern", . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . + [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes + (APL RR)", RFC 3123, DOI 10.17487/RFC3123, June 2001, + . + [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, DOI 10.17487/RFC4287, December 2005, . [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, . [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without