draft-ietf-dnssd-push-17.txt   draft-ietf-dnssd-push-18.txt 
Internet Engineering Task Force T. Pusateri Internet Engineering Task Force T. Pusateri
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track S. Cheshire Intended status: Standards Track S. Cheshire
Expires: September 10, 2019 Apple Inc. Expires: September 12, 2019 Apple Inc.
March 9, 2019 March 11, 2019
DNS Push Notifications DNS Push Notifications
draft-ietf-dnssd-push-17 draft-ietf-dnssd-push-18
Abstract Abstract
The Domain Name System (DNS) was designed to return matching records The Domain Name System (DNS) was designed to return matching records
efficiently for queries for data that are relatively static. When efficiently for queries for data that are relatively static. When
those records change frequently, DNS is still efficient at returning those records change frequently, DNS is still efficient at returning
the updated results when polled, as long as the polling rate is not 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 too high. But there exists no mechanism for a client to be
asynchronously notified when these changes occur. This document asynchronously notified when these changes occur. This document
defines a mechanism for a client to be notified of such changes to defines a mechanism for a client to be notified of such changes to
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. State Considerations . . . . . . . . . . . . . . . . . . . . 8 5. State Considerations . . . . . . . . . . . . . . . . . . . . 8
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 9 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 9
6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 14 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 14
6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 14 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 14
6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 17 6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 17
6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 20 6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 20
6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20 6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20
6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 23 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 25
6.4.1. UNSUBSCRIBE Request . . . . . . . . . . . . . . . . . 23 6.4.1. UNSUBSCRIBE Message . . . . . . . . . . . . . . . . . 25
6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 25 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 27
6.5.1. RECONFIRM Request . . . . . . . . . . . . . . . . . . 25 6.5.1. RECONFIRM Message . . . . . . . . . . . . . . . . . . 28
6.5.2. RECONFIRM Response . . . . . . . . . . . . . . . . . 28
6.6. DNS Stateful Operations TLV Context Summary . . . . . . . 30 6.6. DNS Stateful Operations TLV Context Summary . . . . . . . 30
6.7. Client-Initiated Termination . . . . . . . . . . . . . . 31 6.7. Client-Initiated Termination . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32
7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 32 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 32
7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33 7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 34
skipping to change at page 4, line 47 skipping to change at page 5, line 4
handshake, flow control, and reliability. handshake, flow control, and reliability.
This document builds on experience gained with the LLQ protocol, with This document builds on experience gained with the LLQ protocol, with
an improved design. Instead of using UDP, this specification uses an improved design. Instead of using UDP, this specification uses
DNS Stateful Operations (DSO) [DSO] running over TLS over TCP, and DNS Stateful Operations (DSO) [DSO] running over TLS over TCP, and
therefore doesn't need to reinvent existing TCP functionality. Using therefore doesn't need to reinvent existing TCP functionality. Using
TCP also gives long-lived low-traffic connections better longevity TCP also gives long-lived low-traffic connections better longevity
through NAT gateways without depending on the gateway to support NAT through NAT gateways without depending on the gateway to support NAT
Port Mapping Protocol (NAT-PMP) [RFC6886] or Port Control Protocol Port Mapping Protocol (NAT-PMP) [RFC6886] or Port Control Protocol
(PCP) [RFC6887], or resorting to excessive keepalive traffic. (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 3. Overview
The existing DNS Update protocol [RFC2136] provides a mechanism for A DNS Push Notification client subscribes for Push Notifications for
clients to add or delete individual resource records (RRs) or entire a particular RRSet by connecting to the appropriate Push Notification
resource record sets (RRSets) on the zone's server. server for that RRSet, and sending DSO message(s) indicating the
RRSet(s) of interest. When the client loses interest in receiving
This specification adopts a simplified subset of these existing further updates to these records, it unsubscribes.
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.
The DNS Push Notification server for a zone is any server capable of The DNS Push Notification server for a DNS zone is any server capable
generating the correct change notifications for a name. It may be a of generating the correct change notifications for a name. It may be
primary, secondary, or stealth name server [RFC7719]. Consequently, a primary, secondary, or stealth name server [RFC7719].
the "_dns-push-tls._tcp.<zone>" SRV record for a zone MAY reference Consequently, the "_dns-push-tls._tcp.<zone>" SRV record for a zone
the same target host and port as that zone's MAY reference the same target host and port as that zone's
"_dns-update-tls._tcp.<zone>" SRV record. When the same target host "_dns-update-tls._tcp.<zone>" SRV record. When the same target host
and port is offered for both DNS Updates and DNS Push Notifications, 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 a client MAY use a single TCP connection to that server for both DNS
Updates and DNS Push Notification Subscriptions. Updates and DNS Push Notification Subscriptions.
Supporting DNS Updates and DNS Push Notifications on the same server 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 also to
support DNS Update. support DNS Update.
DNS Updates and DNS Push Notifications may be handled on different DNS Updates and DNS Push Notifications may be handled on different
skipping to change at page 5, line 49 skipping to change at page 5, line 42
Standard DNS Queries MAY be sent over a DNS Push Notification (i.e., 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 DSO) session. For any zone for which the server is authoritative, it
MUST respond authoritatively for queries on names falling within that MUST respond authoritatively for queries on names falling within that
zone (e.g., the <zone> in the "_dns-push-tls._tcp.<zone>" SRV record) zone (e.g., the <zone> in the "_dns-push-tls._tcp.<zone>" SRV record)
both for normal DNS queries and for DNS Push Notification both for normal DNS queries and for DNS Push Notification
subscriptions. For names for which the server is acting as a subscriptions. For names for which the server is acting as a
recursive resolver, e.g. when the server is the local recursive recursive resolver, e.g. when the server is the local recursive
resolver, for any query for which it supports DNS Push Notification resolver, for any query for which it supports DNS Push Notification
subscriptions, it MUST also support standard queries. 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 This DNS Push Notification specification includes support for DNS
classes, for completeness. However, in practice, it is anticipated classes, for completeness. However, in practice, it is anticipated
that for the foreseeable future the only DNS class in use will be DNS 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 class "IN", as is the reality today with existing DNS servers and
clients. A DNS Push Notification server MAY choose to implement only clients. A DNS Push Notification server MAY choose to implement only
DNS class "IN". If messages are received for a class other than DNS class "IN". If messages are received for a class other than
"IN", and that class is not supported, an error with RCODE NOTIMPL "IN", and that class is not supported, an error with RCODE NOTIMPL
(Not Implemented) should be returned. (Not Implemented) should be returned.
DNS Push Notifications impose less load on the responding server than DNS Push Notifications impose less load on the responding server than
skipping to change at page 20, line 35 skipping to change at page 20, line 35
The other header fields MUST be set as described in the DSO The other header fields MUST be set as described in the DSO
specification [DSO]. The DNS OPCODE field contains the OPCODE value specification [DSO]. The DNS OPCODE field contains the OPCODE value
for DNS Stateful Operations (6). The four count fields MUST be zero, for DNS Stateful Operations (6). The four count fields MUST be zero,
and the corresponding four sections MUST be empty (i.e., absent). and the corresponding four sections MUST be empty (i.e., absent).
The DSO-TYPE is PUSH (tentatively 0x41). The DSO-TYPE is PUSH (tentatively 0x41).
The DSO-LENGTH is the length of the DSO-DATA that follows, which The DSO-LENGTH is the length of the DSO-DATA that follows, which
specifies the changes being communicated. specifies the changes being communicated.
The DSO-DATA contains one or more Update records. A PUSH Message The DSO-DATA contains one or more change notifications. A PUSH
MUST contain at least one Update record. If a PUSH Message is Message MUST contain at least one change notification. If a PUSH
received that contains zero Update records, this is a fatal error, Message is received that contains no change notifications, this is a
and the receiver MUST immediately terminate the connection with a TCP fatal error, and the receiver MUST immediately terminate the
RST (or equivalent for other protocols). The Update records are connection with a TCP RST (or equivalent for other protocols). The
formatted in the customary way for Resource Records in DNS messages. change notifications are formatted similarly to how DNS Resource
Update records in a PUSH Message are interpreted according to the Records are conventionally expressed in DNS messages, and are
same rules as for DNS Update [RFC2136] messages, namely: interpreted as described below.
Delete all RRsets from a name: If the signed 32-bit TTL is in the range 0 to 604,800 seconds (one
TTL=0, CLASS=ANY, RDLENGTH=0, TYPE=ANY. 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: If the signed 32-bit TTL has the value -1, then the DNS Resource
TTL=0, CLASS=ANY, RDLENGTH=0; Record with the given name, type, class and RDATA is removed.
TYPE specifies the RRset being deleted.
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: Delete an individual RR from a name:
TTL=0, CLASS=NONE; TTL=-1
TYPE, RDLENGTH and RDATA specifies the RR being deleted. CLASS, TYPE, RDLENGTH and RDATA specify the RR being deleted.
Add to an RRset: Add individual RR to a name
TTL, CLASS, TYPE, RDLENGTH and RDATA specifies the RR being added. 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 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| MESSAGE ID (MUST BE ZERO) | \ | MESSAGE ID (MUST BE ZERO) | \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|QR| OPCODE(6) | Z | RCODE | | |QR| OPCODE(6) | Z | RCODE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER
skipping to change at page 21, line 35 skipping to change at page 23, line 31
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSO-LENGTH (number of octets in DSO-DATA) | | DSO-LENGTH (number of octets in DSO-DATA) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
\ NAME \ \ \ NAME \ \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TYPE | | | TYPE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| CLASS | | | CLASS | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TTL | | | TTL | |
| (32 bits) | > DSO-DATA | (32-bit signed big-endian integer) | > DSO-DATA
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| RDLEN | | | RDLEN | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
\ RDATA \ | \ RDATA (sized as necessary) \ |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
: NAME, TYPE, CLASS, TTL, RDLEN, RDATA : | : NAME, TYPE, CLASS, TTL, RDLEN, RDATA : |
: Repeated As Necessary : / : Repeated As Necessary : /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
Figure 2: PUSH Message Figure 2: PUSH Message
When processing the records received in a PUSH Message, the receiving When processing the records received in a PUSH Message, the receiving
client MUST validate that the records being added or deleted client MUST validate that the records being added or deleted
correspond with at least one currently active subscription on that correspond with at least one currently active subscription on that
skipping to change at page 23, line 12 skipping to change at page 25, line 12
aging for records covered by the subscription resumes and records are aging for records covered by the subscription resumes and records are
removed from the local cache when their TTL reaches zero. removed from the local cache when their TTL reaches zero.
6.4. DNS Push Notification UNSUBSCRIBE 6.4. DNS Push Notification UNSUBSCRIBE
To cancel an individual subscription without closing the entire DSO To cancel an individual subscription without closing the entire DSO
session, the client sends an UNSUBSCRIBE message over the established session, the client sends an UNSUBSCRIBE message over the established
DSO session to the server. The UNSUBSCRIBE message is encoded as a DSO session to the server. The UNSUBSCRIBE message is encoded as a
DSO unidirectional message [DSO]. This specification defines a DSO unidirectional message [DSO]. This specification defines a
primary unidirectional DSO TLV for DNS Push Notification UNSUBSCRIBE 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 A server MUST NOT initiate an UNSUBSCRIBE message. If a server does
send an UNSUBSCRIBE request over a DSO session initiated by a client, send an UNSUBSCRIBE message over a DSO session initiated by a client,
this is a fatal error and the client should immediately abort the 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 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 An UNSUBSCRIBE unidirectional message begins with the standard DSO
[DSO], followed by the UNSUBSCRIBE primary TLV. An UNSUBSCRIBE 12-byte header [DSO], followed by the UNSUBSCRIBE primary TLV. An
request message is illustrated in Figure 3. UNSUBSCRIBE message is illustrated in Figure 3.
In accordance with the definition of DSO unidirectional messages, the 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. UNSUBSCRIBE message.
The other header fields MUST be set as described in the DSO The other header fields MUST be set as described in the DSO
specification [DSO]. The DNS OPCODE field contains the OPCODE value specification [DSO]. The DNS OPCODE field contains the OPCODE value
for DNS Stateful Operations (6). The four count fields MUST be zero, for DNS Stateful Operations (6). The four count fields MUST be zero,
and the corresponding four sections MUST be empty (i.e., absent). and the corresponding four sections MUST be empty (i.e., absent).
The DSO-TYPE is UNSUBSCRIBE (tentatively 0x42). The DSO-TYPE is UNSUBSCRIBE (tentatively 0x42).
The DSO-LENGTH field contains the value 2, the length of the 2-octet The DSO-LENGTH field contains the value 2, the length of the 2-octet
MESSAGE ID contained in the DSO-DATA. MESSAGE ID contained in the DSO-DATA.
The DSO-DATA contains the value given in the MESSAGE ID field of an The DSO-DATA contains the value given in the MESSAGE ID field of an
active SUBSCRIBE request. This is how the server knows which active SUBSCRIBE request. This is how the server knows which
SUBSCRIBE request is being cancelled. After receipt of the 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 previous SUBSCRIBE request for which the client has not yet received
a SUBSCRIBE response. This is to allow for the case where a client 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 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 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 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 can occur when a client sends a SUBSCRIBE request, which subsequently
fails and returns an error code, but the client sent an UNSUBSCRIBE fails and returns an error code, but the client sent an UNSUBSCRIBE
request before it became aware that the SUBSCRIBE request had failed. message before it became aware that the SUBSCRIBE request had failed.
Because of this, servers MUST silently ignore UNSUBSCRIBE requests Because of this, servers MUST silently ignore UNSUBSCRIBE messages
that do not match any currently active subscription. that do not match any currently active subscription.
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| MESSAGE ID (MUST BE ZERO) | \ | MESSAGE ID (MUST BE ZERO) | \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|QR| OPCODE(6) | Z | RCODE | | |QR| OPCODE(6) | Z | RCODE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | |
skipping to change at page 24, line 32 skipping to change at page 26, line 32
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
| DSO-TYPE = UNSUBSCRIBE (tentatively 0x42) | | DSO-TYPE = UNSUBSCRIBE (tentatively 0x42) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSO-LENGTH (2) | | DSO-LENGTH (2) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| SUBSCRIBE MESSAGE ID | > DSO-DATA | SUBSCRIBE MESSAGE ID | > DSO-DATA
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
Figure 3: UNSUBSCRIBE Request Figure 3: UNSUBSCRIBE Message
6.5. DNS Push Notification RECONFIRM 6.5. DNS Push Notification RECONFIRM
Sometimes, particularly when used with a Discovery Proxy [DisProx], a Sometimes, particularly when used with a Discovery Proxy [DisProx], a
DNS Zone may contain stale data. When a client encounters data that 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 it believes may be stale (e.g., an SRV record referencing a target
host+port that is not responding to connection requests) the client 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 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 still present. How the Discovery Proxy causes these new Multicast
DNS requests to be issued depends on the details of the underlying DNS queries to be issued depends on the details of the underlying
Multicast DNS being used. For example, a Discovery Proxy built on Multicast DNS implementation being used. For example, a Discovery
Apple's dns_sd.h API responds to a DNS Push Notification RECONFIRM Proxy built on Apple's dns_sd.h API responds to a DNS Push
message by calling the underlying API's DNSServiceReconfirmRecord() Notification RECONFIRM message by calling the underlying API's
routine. DNSServiceReconfirmRecord() routine.
For other types of DNS server, the RECONFIRM operation is currently For other types of DNS server, the RECONFIRM operation is currently
undefined, and SHOULD result in a NOERROR response, but otherwise undefined, and SHOULD result in a NOERROR response, but otherwise
need not cause any action to occur. need not cause any action to occur.
Frequent use of RECONFIRM operations may be a sign of network Frequent use of RECONFIRM operations may be a sign of network
unreliability, or some kind of misconfiguration, so RECONFIRM unreliability, or some kind of misconfiguration, so RECONFIRM
operations MAY be logged or otherwise communicated to a human operations MAY be logged or otherwise communicated to a human
administrator to assist in detecting, and remedying, such network administrator to assist in detecting, and remedying, such network
problems. 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 that the disputed records are in fact no longer valid, then
subsequent DNS PUSH Messages will be generated to inform interested subsequent DNS PUSH Messages will be generated to inform interested
clients. Thus, one client discovering that a previously-advertised clients. Thus, one client discovering that a previously-advertised
device (like a network printer) is no longer present has the side device (like a network printer) is no longer present has the side
effect of informing all other interested clients that the device in effect of informing all other interested clients that the device in
question is now gone. 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 A RECONFIRM unidirectional message begins with the standard DSO
[DSO], followed by the RECONFIRM primary TLV. A RECONFIRM request 12-byte header [DSO], followed by the RECONFIRM primary TLV. A
message is illustrated in Figure 4. RECONFIRM message is illustrated in Figure 4.
The MESSAGE ID field MUST be set to a unique value, that the client In accordance with the definition of DSO unidirectional messages, the
is not using for any other active operation on this DSO session. For MESSAGE ID field MUST be zero. There is no server response to a
the purposes here, a MESSAGE ID is in use on this session if the RECONFIRM message.
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.
The other header fields MUST be set as described in the DSO The other header fields MUST be set as described in the DSO
specification [DSO]. The DNS OPCODE field contains the OPCODE value specification [DSO]. The DNS OPCODE field contains the OPCODE value
for DNS Stateful Operations (6). The four count fields MUST be zero, for DNS Stateful Operations (6). The four count fields MUST be zero,
and the corresponding four sections MUST be empty (i.e., absent). and the corresponding four sections MUST be empty (i.e., absent).
The DSO-TYPE is RECONFIRM (tentatively 0x43). The DSO-TYPE is RECONFIRM (tentatively 0x43).
The DSO-LENGTH is the length of the data that follows, which The DSO-LENGTH is the length of the data that follows, which
specifies the name, type, class, and content of the record being specifies the name, type, class, and content of the record being
skipping to change at page 26, line 44 skipping to change at page 29, line 33
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
\ NAME \ \ \ NAME \ \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TYPE | | | TYPE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA
| CLASS | | | CLASS | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
\ RDATA \ / \ 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 message MUST contain exactly one record.
The DSO-DATA for a RECONFIRM request has no count field to specify The DSO-DATA for a RECONFIRM message has no count field to specify
more than one record. Since RECONFIRM requests are sent over TCP, more than one record. Since RECONFIRM messages are sent over TCP,
multiple RECONFIRM request messages can be concatenated in a single multiple RECONFIRM messages can be concatenated in a single TCP
TCP stream and packed efficiently into TCP segments. stream and packed efficiently into TCP segments.
TYPE MUST NOT be the value ANY (255) and CLASS MUST NOT be the value TYPE MUST NOT be the value ANY (255) and CLASS MUST NOT be the value
ANY (255). ANY (255).
DNS wildcarding is not supported. That is, a wildcard ("*") in a DNS wildcarding is not supported. That is, a wildcard ("*") in a
RECONFIRM message matches only a literal wildcard character ("*") in RECONFIRM message matches only a literal wildcard character ("*") in
the zone, and nothing else. the zone, and nothing else.
Aliasing is not supported. That is, a CNAME in a RECONFIRM message Aliasing is not supported. That is, a CNAME in a RECONFIRM message
matches only a literal CNAME record in the zone, and nothing else. 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 6.6. DNS Stateful Operations TLV Context Summary
This document defines four new DSO TLVs. As suggested in Section 8.2 This document defines four new DSO TLVs. As suggested in Section 8.2
of the DNS Stateful Operations specification [DSO], the valid of the DNS Stateful Operations specification [DSO], the valid
contexts of these new TLV types are summarized below. contexts of these new TLV types are summarized below.
The client TLV contexts are: The client TLV contexts are:
C-P: Client request message, primary TLV C-P: Client request message, primary TLV
C-U: Client unidirectional message, primary TLV C-U: Client unidirectional message, primary TLV
skipping to change at page 30, line 28 skipping to change at page 30, line 28
+-------------+-----+-----+-----+-----+-----+ +-------------+-----+-----+-----+-----+-----+
| TLV Type | C-P | C-U | C-A | CRP | CRA | | TLV Type | C-P | C-U | C-A | CRP | CRA |
+-------------+-----+-----+-----+-----+-----+ +-------------+-----+-----+-----+-----+-----+
| SUBSCRIBE | X | | | | | | SUBSCRIBE | X | | | | |
| PUSH | | | | | | | PUSH | | | | | |
| UNSUBSCRIBE | | X | | | | | UNSUBSCRIBE | | X | | | |
| RECONFIRM | X | | | | | | RECONFIRM | X | | | | |
+-------------+-----+-----+-----+-----+-----+ +-------------+-----+-----+-----+-----+-----+
Table 3: DSO TLV Client Context Summary Table 2: DSO TLV Client Context Summary
The server TLV contexts are: The server TLV contexts are:
S-P: Server request message, primary TLV S-P: Server request message, primary TLV
S-U: Server unidirectional message, primary TLV S-U: Server unidirectional message, primary TLV
S-A: Server request or unidirectional message, additional TLV S-A: Server request or unidirectional message, additional TLV
SRP: Response back to server, primary TLV SRP: Response back to server, primary TLV
SRA: Response back to server, additional TLV SRA: Response back to server, additional TLV
+-------------+-----+-----+-----+-----+-----+ +-------------+-----+-----+-----+-----+-----+
| TLV Type | S-P | S-U | S-A | SRP | SRA | | TLV Type | S-P | S-U | S-A | SRP | SRA |
+-------------+-----+-----+-----+-----+-----+ +-------------+-----+-----+-----+-----+-----+
| SUBSCRIBE | | | | | | | SUBSCRIBE | | | | | |
| PUSH | | X | | | | | PUSH | | X | | | |
| UNSUBSCRIBE | | | | | | | UNSUBSCRIBE | | | | | |
| RECONFIRM | | | | | | | RECONFIRM | | | | | |
+-------------+-----+-----+-----+-----+-----+ +-------------+-----+-----+-----+-----+-----+
Table 4: DSO TLV Server Context Summary Table 3: DSO TLV Server Context Summary
6.7. Client-Initiated Termination 6.7. Client-Initiated Termination
An individual subscription is terminated by sending an UNSUBSCRIBE An individual subscription is terminated by sending an UNSUBSCRIBE
TLV for that specific subscription, or all subscriptions can be TLV for that specific subscription, or all subscriptions can be
cancelled at once by the client closing the DSO session. When a cancelled at once by the client closing the DSO session. When a
client terminates an individual subscription (via UNSUBSCRIBE) or all client terminates an individual subscription (via UNSUBSCRIBE) or all
subscriptions on that DSO session (by ending the session) it is subscriptions on that DSO session (by ending the session) it is
signaling to the server that it is longer interested in receiving signaling to the server that it is longer interested in receiving
those particular updates. It is informing the server that the server those particular updates. It is informing the server that the server
skipping to change at page 33, line 42 skipping to change at page 33, line 42
Registry Service Types [RFC6335][ST] that is only applicable for the Registry Service Types [RFC6335][ST] that is only applicable for the
TCP protocol. TCP protocol.
+-----------------------+------+----------------------+-------------+ +-----------------------+------+----------------------+-------------+
| Name | Port | Value | Definition | | Name | Port | Value | Definition |
+-----------------------+------+----------------------+-------------+ +-----------------------+------+----------------------+-------------+
| DNS Push Notification | None | "_dns-push-tls._tcp" | Section 6.1 | | DNS Push Notification | None | "_dns-push-tls._tcp" | Section 6.1 |
| Service Type | | | | | 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 This document also defines four new DNS Stateful Operation TLV types
to be recorded in the IANA DSO Type Code Registry. to be recorded in the IANA DSO Type Code Registry.
+-------------+------------------------+-------------+ +-------------+------------------------+-------------+
| Name | Value | Definition | | Name | Value | Definition |
+-------------+------------------------+-------------+ +-------------+------------------------+-------------+
| SUBSCRIBE | TBA (tentatively 0x40) | Section 6.2 | | SUBSCRIBE | TBA (tentatively 0x40) | Section 6.2 |
| PUSH | TBA (tentatively 0x41) | Section 6.3 | | PUSH | TBA (tentatively 0x41) | Section 6.3 |
| UNSUBSCRIBE | TBA (tentatively 0x42) | Section 6.4 | | UNSUBSCRIBE | TBA (tentatively 0x42) | Section 6.4 |
| RECONFIRM | TBA (tentatively 0x43) | Section 6.5 | | 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 9. Acknowledgements
The authors would like to thank Kiren Sekar and Marc Krochmal for The authors would like to thank Kiren Sekar and Marc Krochmal for
previous work completed in this field. previous work completed in this field.
This draft has been improved due to comments from Ran Atkinson, Tim This draft has been improved due to comments from Ran Atkinson, Tim
Chown, Mark Delany, Ralph Droms, Bernie Volz, Jan Komissar, Manju Chown, Mark Delany, Ralph Droms, Bernie Volz, Jan Komissar, Manju
Shankar Rao, Markus Stenberg, Dave Thaler, Soraia Zlatkovic, Sara Shankar Rao, Markus Stenberg, Dave Thaler, Soraia Zlatkovic, Sara
Dickinson, and Andrew Sullivan. Ted Lemon provided clarifying text Dickinson, and Andrew Sullivan. Ted Lemon provided clarifying text
skipping to change at page 36, line 39 skipping to change at page 36, line 39
[LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- [LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns-
llq-01 (work in progress), August 2006. llq-01 (work in progress), August 2006.
[obs] "Observer Pattern", [obs] "Observer Pattern",
<https://en.wikipedia.org/wiki/Observer_pattern>. <https://en.wikipedia.org/wiki/Observer_pattern>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>. <https://www.rfc-editor.org/info/rfc2308>.
[RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes
(APL RR)", RFC 3123, DOI 10.17487/RFC3123, June 2001,
<https://www.rfc-editor.org/info/rfc3123>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, DOI 10.17487/RFC4287, Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <https://www.rfc-editor.org/info/rfc4287>. December 2005, <https://www.rfc-editor.org/info/rfc4287>.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, DOI 10.17487/RFC4953, July 2007, RFC 4953, DOI 10.17487/RFC4953, July 2007,
<https://www.rfc-editor.org/info/rfc4953>. <https://www.rfc-editor.org/info/rfc4953>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
 End of changes. 41 change blocks. 
180 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/