< draft-ietf-dnssd-push-20.txt   draft-ietf-dnssd-push-21.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: December 20, 2019 Apple Inc. Expires: January 6, 2020 Apple Inc.
June 18, 2019 July 5, 2019
DNS Push Notifications DNS Push Notifications
draft-ietf-dnssd-push-20 draft-ietf-dnssd-push-21
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 December 20, 2019. This Internet-Draft will expire on January 6, 2020.
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 15 skipping to change at page 2, line 15
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. State Considerations . . . . . . . . . . . . . . . . . . . . 8 5. State Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 9 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8
6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 14 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 13
6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 14 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 13
6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 17 6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . 25 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 25
6.4.1. UNSUBSCRIBE Message . . . . . . . . . . . . . . . . . 25 6.4.1. UNSUBSCRIBE Message . . . . . . . . . . . . . . . . . 25
6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 27 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 27
6.5.1. RECONFIRM Message . . . . . . . . . . . . . . . . . . 28 6.5.1. RECONFIRM Message . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 31
7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32
7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 33 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 33
7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33 7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 36 10.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
skipping to change at page 5, line 16 skipping to change at page 5, line 16
A DNS Push Notification client subscribes for Push Notifications for A DNS Push Notification client subscribes for Push Notifications for
a particular RRSet by connecting to the appropriate Push Notification a particular RRSet by connecting to the appropriate Push Notification
server for that RRSet, and sending DSO message(s) indicating the server for that RRSet, and sending DSO message(s) indicating the
RRSet(s) of interest. When the client loses interest in receiving RRSet(s) of interest. When the client loses interest in receiving
further updates to these records, it unsubscribes. further updates to these records, it unsubscribes.
The DNS Push Notification server for a DNS zone is any server capable 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 of generating the correct change notifications for a name. It may be
a primary, secondary, or stealth name server [RFC7719]. a primary, secondary, or stealth name server [RFC7719].
Consequently, the "_dns-push-tls._tcp.<zone>" SRV record for a zone Consequently, the "_dns-push._tcp.<zone>" SRV record for a zone MAY
MAY reference the same target host and port as that zone's 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._tcp.<zone>" SRV record. When the same target host and
and port is offered for both DNS Updates and DNS Push Notifications, port is offered for both DNS Updates and DNS Push Notifications, a
a client MAY use a single TCP connection to that server for both DNS 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 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
ports on the same target host, in which case they are not considered 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 to be the "same server" for the purposes of this specification, and
communications with these two ports are handled independently. communications with these two ports are handled independently.
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._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.
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 DNS Push Notifications impose less load on the responding server than
rapid polling would, but Push Notifications do still have a cost, so rapid polling would, but Push Notifications do still have a cost, so
DNS Push Notification clients MUST NOT recklessly create an excessive DNS Push Notification clients MUST NOT recklessly create an excessive
number of Push Notification subscriptions. Specifically: number of Push Notification subscriptions. Specifically:
(a) A subscription should only be active when there is a valid reason (a) A subscription should only be active when there is a valid reason
to need live data (for example, an on-screen display is currently to need live data (for example, an on-screen display is currently
showing the results to the user) and the subscription SHOULD be showing the results to the user) and the subscription SHOULD be
cancelled as soon as the need for that data ends (for example, when cancelled as soon as the need for that data ends (for example, when
the user dismisses that display). In the case of a device like a the user dismisses that display). In the case of a device like a
skipping to change at page 7, line 19 skipping to change at page 6, line 41
(TCP) [RFC0793] as the transport protocol, in keeping with the (TCP) [RFC0793] as the transport protocol, in keeping with the
historical precedent that DNS queries must first be sent over UDP historical precedent that DNS queries must first be sent over UDP
[RFC1123]. This requirement to use UDP has subsequently been relaxed [RFC1123]. This requirement to use UDP has subsequently been relaxed
[RFC7766]. [RFC7766].
In keeping with the more recent precedent, DNS Push Notification is In keeping with the more recent precedent, DNS Push Notification is
defined only for TCP. DNS Push Notification clients MUST use DNS defined only for TCP. DNS Push Notification clients MUST use DNS
Stateful Operations [RFC8490] running over TLS over TCP [RFC7858]. Stateful Operations [RFC8490] running over TLS over TCP [RFC7858].
Connection setup over TCP ensures return reachability and alleviates Connection setup over TCP ensures return reachability and alleviates
concerns of state overload at the server through anonymous concerns of state overload at the server which is a potential problem
subscriptions. All subscribers are guaranteed to be reachable by the with connection-less protocols using spoofed source addresses. All
server by virtue of the TCP three-way handshake. Flooding attacks subscribers are guaranteed to be reachable by the server by virtue of
are possible with any protocol, and a benefit of TCP is that there the TCP three-way handshake. Flooding attacks are possible with any
are already established industry best practices to guard against SYN protocol, and a benefit of TCP is that there are already established
flooding and similar attacks [SYN] [RFC4953]. 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 Use of TCP also allows DNS Push Notifications to take advantage of
current and future developments in TCP, such as Multipath TCP (MPTCP) current and future developments in TCP, such as Multipath TCP (MPTCP)
[RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP) [RFC6824], TCP Fast Open (TFO) [RFC7413], Tail Loss Probe (TLP)
[I-D.dukkipati-tcpm-tcp-loss-probe], and so on. [I-D.dukkipati-tcpm-tcp-loss-probe], and so on.
Transport Layer Security (TLS) [RFC8446] is well understood and Transport Layer Security (TLS) [RFC8446] is well understood and
deployed across many protocols running over TCP. It is designed to deployed across many protocols running over TCP. It is designed to
prevent eavesdropping, tampering, and message forgery. TLS is prevent eavesdropping, tampering, and message forgery. TLS is
REQUIRED for every connection between a client subscriber and server REQUIRED for every connection between a client subscriber and server
in this protocol specification. Additional security measures such as in this protocol specification. Additional security measures such as
client authentication during TLS negotiation MAY also be employed to client authentication during TLS negotiation MAY also be employed to
increase the trust relationship between client and server. increase the trust relationship between client and server.
skipping to change at page 10, line 7 skipping to change at page 9, line 7
server sends relevant asynchronous Push Notifications to the client. server sends relevant asynchronous Push Notifications to the client.
Note that a client MUST be prepared to receive (and silently ignore) Note that a client MUST be prepared to receive (and silently ignore)
Push Notifications for subscriptions it has previously removed, since Push Notifications for subscriptions it has previously removed, since
there is no way to prevent the situation where a Push Notification is there is no way to prevent the situation where a Push Notification is
in flight from server to client while the client's UNSUBSCRIBE in flight from server to client while the client's UNSUBSCRIBE
message cancelling that subscription is simultaneously in flight from message cancelling that subscription is simultaneously in flight from
client to server. client to server.
6.1. Discovery 6.1. Discovery
The first step in DNS Push Notification subscription is to discover The first step in a DNS Push Notification subscription is to discover
an appropriate DNS server that supports DNS Push Notifications for an appropriate DNS server that supports DNS Push Notifications for
the desired zone. the desired zone.
The client begins by opening a DSO Session to its normal configured The client begins by opening a DSO Session to its normal configured
DNS recursive resolver and requesting a Push Notification DNS recursive resolver and requesting a Push Notification
subscription. This connection is made to TCP port 853, the default subscription. This connection is made to TCP port 853, the default
port for DNS-over-TLS [RFC7858]. If the request for a Push port for DNS-over-TLS [RFC7858]. If the request for a Push
Notification subscription is successful, then the recursive resolver Notification subscription is successful, then the recursive resolver
will make a corresponding Push Notification subscription on the will make a corresponding Push Notification subscription on the
client's behalf (if the recursive resolver doesn't already have an client's behalf (if the recursive resolver doesn't already have an
active subscription for that name, type, and class), and pass on any active subscription for that name, type, and class). This is closely
results it receives back to the client. This is closely analogous to analogous to how a client sends normal DNS queries to its configured
how a client sends normal DNS queries to its configured DNS recursive DNS recursive resolver, which issues queries on the client's behalf
resolver, which issues queries on the client's behalf (if the (if the recursive resolver doesn't already have appropriate answer(s)
recursive resolver doesn't already have appropriate answer(s) in its in its cache).
cache), and passes on any results it receives back to the client.
In many contexts, the recursive resolver will be able to handle Push In many contexts, the recursive resolver will be able to handle Push
Notifications for all names that the client may need to follow. Use Notifications for all names that the client may need to follow. Use
of VPN tunnels and split-view DNS can create some additional of VPN tunnels and split-view DNS can create some additional
complexity in the client software here; the techniques to handle VPN complexity in the client software here; the techniques to handle VPN
tunnels and split-view DNS for DNS Push Notifications are the same as tunnels and split-view DNS for DNS Push Notifications are the same as
those already used to handle this for normal DNS queries. those already used to handle this for normal DNS queries.
If the recursive resolver does not support DNS over TLS, or does If the recursive resolver does not support DNS over TLS, or does
support DNS over TLS but is not listening on TCP port 853, or does support DNS over TLS but is not listening on TCP port 853, or does
support DNS over TLS on TCP port 853 but does not support DSO on that support DNS over TLS on TCP port 853 but does not support DSO on that
port, then the DSO Session session establishment will fail [RFC8490]. port, then the DSO Session session establishment will fail [RFC8490].
If the recursive resolver does support DSO but not Push Notification If the recursive resolver does support DSO but not Push Notification
subscriptions, then it will return the DSO error code, DSOTYPENI subscriptions, then it will return the DSO error code, DSOTYPENI
(11). (11).
In some cases, the recursive resolver may support DSO and Push In some cases, the recursive resolver may support DSO and Push
Notification subscriptions, but may not be able to subscribe for Push Notification subscriptions, but may not be able to subscribe for Push
Notifications for a particular name. In this case, the recursive Notifications for a particular name. In this case, the recursive
resolver should return an informative error code to the client so resolver should return SERVFAIL to the client. This includes being
that the client can make an informed decision how to handle the unable to establish a connection to the zone's DNS Push Notification
error. If the recursive resolver is unable to establish a connection server or establishing a connection but receiving a non success
to the zone's DNS Push Notification server (perhaps because the response code. In some cases, where the client has a pre-established
required SRV record does not exist) the recursive resolver should trust relationship with the owner of the zone (that is not handled
return SERVFAIL. If the recursive resolver is able to establish a via the usual mechanisms for VPN software) the client may handle
connection to the zone's DNS Push Notification server and some other these failures by contacting the zone's DNS Push server directly.
error code is then received, the recursive resolver should pass on
this received error code back to the client. In some cases, where
the client has a pre-established trust relationship with the owner of
the zone (that is not handled via the usual mechanisms for VPN
software) the client may handle these failures by contacting the
zone's DNS Push server directly.
In any of the cases described above where the client fails to In any of the cases described above where the client fails to
establish a DNS Push Notification subscription via its configured establish a DNS Push Notification subscription via its configured
recursive resolver, the client should proceed to discover the recursive resolver, the client should proceed to discover the
appropriate server for direct communication. The client MUST also appropriate server for direct communication. The client MUST also
determine which TCP port on the server is listening for connections, determine which TCP port on the server is listening for connections,
which need not be (and often is not) the typical TCP port 53 used for which need not be (and often is not) the typical TCP port 53 used for
conventional DNS, or TCP port 853 used for DNS over TLS. conventional DNS, or TCP port 853 used for DNS over TLS.
The discovery algorithm described here is an iterative algorithm, The discovery algorithm described here is an iterative algorithm,
skipping to change at page 12, line 29 skipping to change at page 11, line 23
or the query name consists of a single label, i.e., a Top Level 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 Domain (TLD). In the case of a single-label TLD, this is a
network configuration error which should not happen and the network configuration error which should not happen and the
client gives up. The client may retry the operation at a later client gives up. The client may retry the operation at a later
time, of the client's choosing, such after a change in network time, of the client's choosing, such after a change in network
attachment. attachment.
5. Once the SOA is known (either by virtue of being seen in the 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 Answer Section, or in the Authority Section), the client sends a
DNS query with type SRV [RFC2782] for the record name DNS query with type SRV [RFC2782] for the record name
"_dns-push-tls._tcp.<zone>", where <zone> is the owner name of "_dns-push._tcp.<zone>", where <zone> is the owner name of the
the discovered SOA record. discovered SOA record.
6. If the zone in question is set up to offer DNS Push Notifications 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 then this SRV record MUST exist. (If this SRV record does not
exist then the zone is not correctly configured for DNS Push exist then the zone is not correctly configured for DNS Push
Notifications as specified in this document.) The SRV "target" Notifications as specified in this document.) The SRV "target"
contains the name of the server providing DNS Push Notifications contains the name of the server providing DNS Push Notifications
for the zone. The port number on which to contact the server is 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 in the SRV record "port" field. The address(es) of the target
host MAY be included in the Additional Section, however, the host MAY be included in the Additional Section, however, the
address records SHOULD be authenticated before use as described address records SHOULD be authenticated before use as described
skipping to change at page 14, line 15 skipping to change at page 13, line 15
6.2. DNS Push Notification SUBSCRIBE 6.2. DNS Push Notification SUBSCRIBE
After connecting, and requesting a longer idle timeout and/or After connecting, and requesting a longer idle timeout and/or
keepalive interval if necessary, a DNS Push Notification client keepalive interval if necessary, a DNS Push Notification client
then indicates its desire to receive DNS Push Notifications for then indicates its desire to receive DNS Push Notifications for
a given domain name by sending a SUBSCRIBE request to the server. a given domain name by sending a SUBSCRIBE request to the server.
A SUBSCRIBE request is encoded in a DSO message [RFC8490]. A SUBSCRIBE request is encoded in a DSO message [RFC8490].
This specification defines a primary DSO TLV for DNS Push This specification defines a primary DSO TLV for DNS Push
Notification SUBSCRIBE Requests (tentatively DSO Type Code 0x40). Notification SUBSCRIBE Requests (tentatively DSO Type Code 0x40).
DSO messages with the SUBSCRIBE TLV as the Primary TLV are not
permitted in early data.
The entity that initiates a SUBSCRIBE request is by definition the The entity that initiates a SUBSCRIBE request is by definition the
client. A server MUST NOT send a SUBSCRIBE request over an existing client. A server MUST NOT send a SUBSCRIBE request over an existing
session from a client. If a server does send a SUBSCRIBE request 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 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 the client should immediately abort the connection with a TLS
equivalent for other protocols). close_notify alert. See Section 6.1 of [RFC8446].
6.2.1. SUBSCRIBE Request 6.2.1. SUBSCRIBE Request
A SUBSCRIBE request begins with the standard DSO 12-byte header A SUBSCRIBE request begins with the standard DSO 12-byte header
[RFC8490], followed by the SUBSCRIBE primary TLV. A SUBSCRIBE [RFC8490], followed by the SUBSCRIBE primary TLV. A SUBSCRIBE
request message is illustrated in Figure 1. request message is illustrated in Figure 1.
The MESSAGE ID field MUST be set to a unique value, that the client 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 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 the purposes here, a MESSAGE ID is in use on this session if the
skipping to change at page 15, line 51 skipping to change at page 14, line 51
cancels the subscription using UNSUBSCRIBE or until the DSO session cancels the subscription using UNSUBSCRIBE or until the DSO session
between the client and the server is closed. between the client and the server is closed.
SUBSCRIBE requests on a given session MUST be unique. A client MUST SUBSCRIBE requests on a given session MUST be unique. A client MUST
NOT send a SUBSCRIBE message that duplicates the NAME, TYPE and CLASS NOT send a SUBSCRIBE message that duplicates the NAME, TYPE and CLASS
of an existing active subscription on that DSO session. For the of an existing active subscription on that DSO session. For the
purpose of this matching, the established DNS case-insensitivity for purpose of this matching, the established DNS case-insensitivity for
US-ASCII letters applies (e.g., "example.com" and "Example.com" are US-ASCII letters applies (e.g., "example.com" and "Example.com" are
the same). If a server receives such a duplicate SUBSCRIBE message the same). If a server receives such a duplicate SUBSCRIBE message
this is an error and the server MUST immediately terminate the this is an error and the server MUST immediately terminate the
connection with a TCP RST (or equivalent for other protocols). connection with a TLS close_notify alert.
DNS wildcarding is not supported. That is, a wildcard ("*") in a DNS wildcarding is not supported. That is, a wildcard ("*") in a
SUBSCRIBE message matches only a literal wildcard character ("*") in SUBSCRIBE 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 SUBSCRIBE message Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message
matches only a literal CNAME record in the zone, and nothing else. matches only a literal CNAME record in the zone, and not to any
records referenced by the owner name.
A client may SUBSCRIBE to records that are unknown to the server at A client may SUBSCRIBE to records that are unknown to the server at
the time of the request (providing that the name falls within one of the time of the request (providing that the name falls within one of
the zone(s) the server is responsible for) and this is not an error. the zone(s) the server is responsible for) and this is not an error.
The server MUST NOT return NXDOMAIN in this case. The server MUST The server MUST NOT return NXDOMAIN in this case. The server MUST
accept these requests and send Push Notifications if and when accept these requests and send Push Notifications if and when
matching records are found in the future. matching records are found in the future.
If neither TYPE nor CLASS are ANY (255) then this is a specific If neither TYPE nor CLASS are ANY (255) then this is a specific
subscription to changes for the given NAME, TYPE and CLASS. If one subscription to changes for the given NAME, TYPE and CLASS. If one
skipping to change at page 17, line 11 skipping to change at page 16, line 11
where one or both of TYPE or CLASS are 255, the server MUST send Push where one or both of TYPE or CLASS are 255, the server MUST send Push
Notification Updates for ALL record changes that match the Notification Updates for ALL record changes that match the
subscription, not just some of them. subscription, not just some of them.
6.2.2. SUBSCRIBE Response 6.2.2. SUBSCRIBE Response
Each SUBSCRIBE request generates exactly one SUBSCRIBE response from Each SUBSCRIBE request generates exactly one SUBSCRIBE response from
the server. the server.
A SUBSCRIBE response begins with the standard DSO 12-byte header A SUBSCRIBE response begins with the standard DSO 12-byte header
[RFC8490], possibly followed by one or more optional TLVs, such as a [RFC8490]. The QR bit in the header is set indicating it is a
Retry Delay TLV. response. The header MAY be followed by one or more optional TLVs,
such as a Retry Delay TLV.
The MESSAGE ID field MUST echo the value given in the ID field of the The MESSAGE ID field MUST echo the value given in the Message ID
SUBSCRIBE request. This is how the client knows which request is field of the SUBSCRIBE request. This is how the client knows which
being responded to. request is being responded to.
A SUBSCRIBE response message MUST NOT include a SUBSCRIBE TLV. If a A SUBSCRIBE response message MUST NOT include a SUBSCRIBE TLV. If a
client receives a SUBSCRIBE response message containing a SUBSCRIBE client receives a SUBSCRIBE response message containing a SUBSCRIBE
TLV then the response message is processed but the SUBSCRIBE TLV MUST TLV then the response message is processed but the SUBSCRIBE TLV MUST
be silently ignored. be silently ignored.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| MESSAGE ID | \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|QR| OPCODE(6) | Z | RCODE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| QDCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER
| ANCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| NSCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ARCOUNT (MUST BE ZERO) | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
Figure 2: SUBSCRIBE Response Message
In the SUBSCRIBE response the RCODE indicates whether or not the In the SUBSCRIBE response the RCODE indicates whether or not the
subscription was accepted. Supported RCODEs are as follows: subscription was accepted. Supported RCODEs are as follows:
+-----------+-------+-----------------------------------------------+ +-----------+-------+-----------------------------------------------+
| Mnemonic | Value | Description | | Mnemonic | Value | Description |
+-----------+-------+-----------------------------------------------+ +-----------+-------+-----------------------------------------------+
| NOERROR | 0 | SUBSCRIBE successful. | | NOERROR | 0 | SUBSCRIBE successful. |
| FORMERR | 1 | Server failed to process request due to a | | FORMERR | 1 | Server failed to process request due to a |
| | | malformed request. | | | | malformed request. |
| SERVFAIL | 2 | Server failed to process request due to a | | SERVFAIL | 2 | Server failed to process request due to a |
skipping to change at page 19, line 5 skipping to change at page 18, line 33
the retry delay SHOULD be one hour. Note that in such a case, a 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 server that doesn't implement DSO is unlikely to place a Retry
Delay TLV in its response, so this recommended value in particular Delay TLV in its response, so this recommended value in particular
applies to what a client should assume by default. applies to what a client should assume by default.
For RCODE = 5 (REFUSED), which occurs on a server that implements For RCODE = 5 (REFUSED), which occurs on a server that implements
DNS Push Notifications, but is currently configured to disallow DNS Push Notifications, but is currently configured to disallow
DNS Push Notifications, the retry delay may be any value selected DNS Push Notifications, the retry delay may be any value selected
by the implementer and/or configured by the operator. by the implementer and/or configured by the operator.
If the server being queried is listed in a If the server being queried is listed in a "_dns-push._tcp.<zone>"
"_dns-push-tls._tcp.<zone>" SRV record for the zone, then this is SRV record for the zone, then this is a misconfiguration, since
a misconfiguration, since this server is being advertised as this server is being advertised as supporting DNS Push
supporting DNS Push Notifications for this zone, but the server Notifications for this zone, but the server itself is not
itself is not currently configured to perform that task. Since it currently configured to perform that task. Since it is possible
is possible that the misconfiguration may be repaired at any time, that the misconfiguration may be repaired at any time, the retry
the retry delay should not be set too high. By default, a value delay should not be set too high. By default, a value of 5
of 5 minutes is RECOMMENDED. minutes is RECOMMENDED.
For RCODE = 9 (NOTAUTH), which occurs on a server that implements For RCODE = 9 (NOTAUTH), which occurs on a server that implements
DNS Push Notifications, but is not configured to be authoritative DNS Push Notifications, but is not configured to be authoritative
for the requested name, the retry delay may be any value selected for the requested name, the retry delay may be any value selected
by the implementer and/or configured by the operator. by the implementer and/or configured by the operator.
If the server being queried is listed in a If the server being queried is listed in a "_dns-push._tcp.<zone>"
"_dns-push-tls._tcp.<zone>" SRV record for the zone, then this is SRV record for the zone, then this is a misconfiguration, since
a misconfiguration, since this server is being advertised as this server is being advertised as supporting DNS Push
supporting DNS Push Notifications for this zone, but the server Notifications for this zone, but the server itself is not
itself is not currently configured to perform that task. Since it currently configured to perform that task. Since it is possible
is possible that the misconfiguration may be repaired at any time, that the misconfiguration may be repaired at any time, the retry
the retry delay should not be set too high. By default, a value delay should not be set too high. By default, a value of 5
of 5 minutes is RECOMMENDED. minutes is RECOMMENDED.
For RCODE = 11 (DSOTYPENI), which occurs on a server that For RCODE = 11 (DSOTYPENI), which occurs on a server that
implements DSO but doesn't implement DNS Push Notifications, it is implements DSO but doesn't implement DNS Push Notifications, it is
unlikely that the server will begin supporting DNS Push unlikely that the server will begin supporting DNS Push
Notifications in the next few minutes, so the retry delay SHOULD Notifications in the next few minutes, so the retry delay SHOULD
be one hour. be one hour.
For other RCODE values, the retry delay should be set by the For other RCODE values, the retry delay should be set by the
server as appropriate for that error condition. By default, a server as appropriate for that error condition. By default, a
value of 5 minutes is RECOMMENDED. value of 5 minutes is RECOMMENDED.
skipping to change at page 20, line 19 skipping to change at page 20, line 19
case that the answer set was already non-empty at the moment the case that the answer set was already non-empty at the moment the
subscription was established, an initial PUSH message will be sent subscription was established, an initial PUSH message will be sent
immediately following the SUBSCRIBE Response. Subsequent changes to immediately following the SUBSCRIBE Response. Subsequent changes to
the answer set are then communicated to the client in subsequent PUSH the answer set are then communicated to the client in subsequent PUSH
messages. messages.
6.3.1. PUSH Message 6.3.1. PUSH Message
A PUSH unidirectional message begins with the standard DSO 12-byte A PUSH unidirectional message begins with the standard DSO 12-byte
header [RFC8490], followed by the PUSH primary TLV. A PUSH message header [RFC8490], followed by the PUSH primary TLV. A PUSH message
is illustrated in Figure 2. is illustrated in Figure 3.
In accordance with the definition of DSO unidirectional messages, the In accordance with the definition of DSO unidirectional messages, the
MESSAGE ID field MUST be zero. There is no client response to a PUSH MESSAGE ID field MUST be zero. There is no client response to a PUSH
message. message.
The other header fields MUST be set as described in the DSO spec- The other header fields MUST be set as described in the DSO spec-
ification [RFC8490]. The DNS OPCODE field contains the OPCODE value ification [RFC8490]. 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 change notifications. A PUSH The DSO-DATA contains one or more change notifications. A PUSH
Message MUST contain at least one change notification. If a PUSH Message MUST contain at least one change notification. If a PUSH
Message is received that contains no change notifications, this is a Message is received that contains no change notifications, this is a
fatal error, and the receiver MUST immediately terminate the fatal error, and the receiver MUST immediately terminate the
connection with a TCP RST (or equivalent for other protocols). connection with a TLS close_notify alert.
The change notification records are formatted similarly to how DNS The change notification records are formatted similarly to how DNS
Resource Records are conventionally expressed in DNS messages, as Resource Records are conventionally expressed in DNS messages, as
illustrated in Figure 2, and are interpreted as described below. illustrated in Figure 3, and are interpreted as described below.
The TTL field holds an unsigned 32-bit integer [RFC2181]. If the TTL 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), 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 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 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 for as long as the subscription is active, and should be discarded
immediately the moment the subscription is cancelled. immediately the moment the subscription is cancelled.
If the TTL has the value 0xFFFFFFFF, then the DNS Resource Record If the TTL has the value 0xFFFFFFFF, then the DNS Resource Record
with the given name, type, class and RDATA is removed. with the given name, type, class and RDATA is removed.
If the TTL has the value 0xFFFFFFFE, then this is a 'collective' If the TTL has the value 0xFFFFFFFE, then this is a 'collective'
remove notification. For collective remove notifications RDLEN MUST remove notification. For collective remove notifications RDLEN MUST
be zero and consequently the RDATA MUST be empty. If a change be zero and consequently the RDATA MUST be empty. If a change
notification is received where TTL = 0xFFFFFFFE and RDLEN is not notification is received where TTL = 0xFFFFFFFE and RDLEN is not
zero, this is a fatal error, and the receiver MUST immediately zero, this is a fatal error, and the receiver MUST immediately
terminate the connection with a TCP RST (or equivalent for other terminate the connection with a TLS close_notify alert. There are
protocols). There are three types of collective remove notification: three types of collective remove notification:
For collective remove notifications, if CLASS is 255 (ANY), then for For collective remove notifications, if CLASS is 255 (ANY), then for
the given name this deletes all records of all types in all classes. 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 In this case TYPE MUST be set to zero on transmission, and MUST be
silently ignored on reception. silently ignored on reception.
For collective remove notifications, if CLASS is not 255 (ANY) and 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 TYPE is 255 (ANY) then for the given name this deletes all records of
all types in the specified class. all types in the specified class.
skipping to change at page 23, line 4 skipping to change at page 22, line 51
MUST NOT generate PUSH messages larger than this. Where the MUST NOT generate PUSH messages larger than this. Where the
immediately available change notifications are sufficient to exceed a immediately available change notifications are sufficient to exceed a
DNS message length of 16,382 bytes, the change notifications MUST be DNS message length of 16,382 bytes, the change notifications MUST be
communicated in separate PUSH messages of up to 16,382 bytes each. communicated in separate PUSH messages of up to 16,382 bytes each.
DNS name compression becomes less effective for messages larger than DNS name compression becomes less effective for messages larger than
16,384 bytes, so little efficiency benefit is gained by sending 16,384 bytes, so little efficiency benefit is gained by sending
messages larger than this. messages larger than this.
If a client receives a PUSH message with a DNS message length larger 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 than 16,382 bytes, the this is a fatal error, and the receiver MUST
immediately terminate the connection with a TCP RST (or equivalent immediately terminate the connection with a TLS close_notify alert.
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 23, line 43 skipping to change at page 23, line 41
| (32-bit unsigned big-endian integer) | > DSO-DATA | (32-bit unsigned big-endian integer) | > DSO-DATA
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| RDLEN | | | RDLEN | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
\ RDATA (sized as necessary) \ | \ 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 3: 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
session. Specifically, the record name MUST match the name given in session. Specifically, the record name MUST match the name given in
a SUBSCRIBE request, subject to the usual established DNS case- a SUBSCRIBE request, subject to the usual established DNS case-
insensitivity for US-ASCII letters. If the TYPE in the SUBSCRIBE insensitivity for US-ASCII letters. If the TYPE in the SUBSCRIBE
request was not ANY (255) then the TYPE of the record must match the request was not ANY (255) then the TYPE of the record must match the
TYPE given in the SUBSCRIBE request. If the CLASS in the SUBSCRIBE TYPE given in the SUBSCRIBE request. If the CLASS in the SUBSCRIBE
request was not ANY (255) then the CLASS of the record must match the request was not ANY (255) then the CLASS of the record must match the
skipping to change at page 25, line 17 skipping to change at page 25, line 17
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 [RFC8490]. This specification defines a DSO unidirectional message [RFC8490]. This specification defines a
primary unidirectional DSO TLV for DNS Push Notification UNSUBSCRIBE primary unidirectional DSO TLV for DNS Push Notification UNSUBSCRIBE
Messages (tentatively DSO Type Code 0x42). Messages (tentatively DSO Type Code 0x42).
A server MUST NOT initiate an UNSUBSCRIBE message. If a server does A server MUST NOT initiate an UNSUBSCRIBE message. If a server does
send an UNSUBSCRIBE message 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 TLS close_notify alert.
6.4.1. UNSUBSCRIBE Message 6.4.1. UNSUBSCRIBE Message
An UNSUBSCRIBE unidirectional message begins with the standard DSO An UNSUBSCRIBE unidirectional message begins with the standard DSO
12-byte header [RFC8490], followed by the UNSUBSCRIBE primary TLV. 12-byte header [RFC8490], followed by the UNSUBSCRIBE primary TLV.
An UNSUBSCRIBE message is illustrated in Figure 3. An UNSUBSCRIBE message is illustrated in Figure 4.
In accordance with the definition of DSO unidirectional messages, the In accordance with the definition of DSO unidirectional messages, the
MESSAGE ID field MUST be zero. There is no server response to an 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 spec- The other header fields MUST be set as described in the DSO spec-
ification [RFC8490]. The DNS OPCODE field contains the OPCODE value ification [RFC8490]. 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).
skipping to change at page 26, 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 Message Figure 4: 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 message 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 queries to ascertain whether the target device is new Multicast DNS queries to ascertain whether the target device is
skipping to change at page 28, line 9 skipping to change at page 28, line 9
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 Message 6.5.1. RECONFIRM Message
A RECONFIRM unidirectional message begins with the standard DSO A RECONFIRM unidirectional message begins with the standard DSO
12-byte header [RFC8490], followed by the RECONFIRM primary TLV. 12-byte header [RFC8490], followed by the RECONFIRM primary TLV.
A RECONFIRM message is illustrated in Figure 4. A RECONFIRM message is illustrated in Figure 5.
In accordance with the definition of DSO unidirectional messages, the 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 a
RECONFIRM message. RECONFIRM message.
The other header fields MUST be set as described in the DSO spec- The other header fields MUST be set as described in the DSO spec-
ification [RFC8490]. The DNS OPCODE field contains the OPCODE value ification [RFC8490]. 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).
skipping to change at page 29, line 33 skipping to change at page 29, line 33
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
\ NAME \ \ \ NAME \ \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TYPE | | | TYPE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA
| CLASS | | | CLASS | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
\ RDATA \ / \ RDATA \ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
Figure 4: RECONFIRM Message Figure 5: RECONFIRM Message
The DSO-DATA for a RECONFIRM message MUST contain exactly one record. The DSO-DATA for a RECONFIRM message MUST contain exactly one record.
The DSO-DATA for a RECONFIRM message 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 messages are sent over TCP, more than one record. Since RECONFIRM messages are sent over TCP,
multiple RECONFIRM messages can be concatenated in a single TCP multiple RECONFIRM messages can be concatenated in a single 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).
skipping to change at page 31, line 32 skipping to change at page 31, line 32
If a client plans to terminate one or more subscriptions on a session If a client plans to terminate one or more subscriptions on a session
and doesn't intend to keep that session open, then as an efficiency and doesn't intend to keep that session open, then as an efficiency
optimization it MAY instead choose to simply close the session, which optimization it MAY instead choose to simply close the session, which
implicitly terminates all subscriptions on that session. This may implicitly terminates all subscriptions on that session. This may
occur because the client computer is being shut down, is going to occur because the client computer is being shut down, is going to
sleep, the application requiring the subscriptions has terminated, or sleep, the application requiring the subscriptions has terminated, or
simply because the last active subscription on that session has been simply because the last active subscription on that session has been
cancelled. cancelled.
When closing a session, a client will generally do an abortive When closing a session, a client should perform an orderly close of
disconnect, sending a TCP RST. This immediately discards all the TLS session in order to allow for future TLS session resumption
remaining inbound and outbound data, which is appropriate if the with the server (if available). See Section 7.3 below. Typical APIs
client no longer has any interest in this data. In the BSD Sockets will provide a session close method that will send a TLS close_notify
API, sending a TCP RST is achieved by setting the SO_LINGER option alert. This instructs the recipient that the sender will not send
with a time of 0 seconds and then closing the socket. any more data over the session. Any pending writes on the server
will be discarded when a close_notify is received.
If a client has performed operations on this session that it would If the session is forcibly closed at the TCP level by sending a RST
not want lost (like DNS updates) then the client SHOULD do an orderly from either end of the connection, data may be lost and TLS session
disconnect, sending a TLS close_notify followed by a TCP FIN. (In resumption of this session will not be possible.
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.)
7. Security Considerations 7. Security Considerations
The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS
Push Notifications [RFC8310]. Cleartext connections for DNS Push Push Notifications [RFC8310]. Cleartext connections for DNS Push
Notifications are not permissible. Since this is a new protocol, Notifications are not permissible. Since this is a new protocol,
transition mechanisms from the Opportunistic Privacy profile are transition mechanisms from the Opportunistic Privacy profile are
unnecessary. unnecessary.
Also, see Section 9 of the DNS over (D)TLS Usage Profiles document Also, see Section 9 of the DNS over (D)TLS Usage Profiles document
skipping to change at page 33, line 16 skipping to change at page 33, line 9
suites are beyond the scope of this document. Please refer to TLS suites are beyond the scope of this document. Please refer to TLS
Recommendations [RFC7525] for the best current practices. Keep in Recommendations [RFC7525] for the best current practices. Keep in
mind that best practices only exist for a snapshot in time and mind that best practices only exist for a snapshot in time and
recommendations will continue to change. Updated versions or errata recommendations will continue to change. Updated versions or errata
may exist for these recommendations. may exist for these recommendations.
7.2. TLS Name Authentication 7.2. TLS Name Authentication
As described in Section 6.1, the client discovers the DNS Push As described in Section 6.1, the client discovers the DNS Push
Notification server using an SRV lookup for the record name Notification server using an SRV lookup for the record name
"_dns-push-tls._tcp.<zone>". The server connection endpoint SHOULD "_dns-push._tcp.<zone>". The server connection endpoint SHOULD then
then be authenticated using DANE TLSA records for the associated SRV be authenticated using DANE TLSA records for the associated SRV
record. This associates the target's name and port number with a record. This associates the target's name and port number with a
trusted TLS certificate [RFC7673]. This procedure uses the TLS trusted TLS certificate [RFC7673]. This procedure uses the TLS
Server Name Indication (SNI) extension [RFC6066] to inform the server Server Name Indication (SNI) extension [RFC6066] to inform the server
of the name the client has authenticated through the use of TLSA of the name the client has authenticated through the use of TLSA
records. Therefore, if the SRV record passes DNSSEC validation and a records. Therefore, if the SRV record passes DNSSEC validation and a
TLSA record matching the target name is useable, an SNI extension TLSA record matching the target name is useable, an SNI extension
must be used for the target name to ensure the client is connecting 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 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. 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 See Usage Profiles for DNS over TLS and DNS over DTLS [RFC8310] for
skipping to change at page 34, line 11 skipping to change at page 34, line 11
will proceed as with any other new DSO session. Use of TLS Session 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 Resumption may allow a TLS connection to be set up more quickly, but
the client will still have to recreate any desired subscriptions. the client will still have to recreate any desired subscriptions.
8. IANA Considerations 8. IANA Considerations
This document defines a new service name to be published in the IANA This document defines a new service name to be published in the IANA
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._tcp" | Section 6.1 |
| Service Type | | | | | Service Type | | | |
+-----------------------+------+----------------------+-------------+ +---------------------------+------+------------------+-------------+
Table 4: 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 | Early | Status | Definition |
+-------------+------------------------+-------------+ | | | Data | | |
| SUBSCRIBE | TBA (tentatively 0x40) | Section 6.2 | +-------------+------------+---------+-----------------+------------+
| PUSH | TBA (tentatively 0x41) | Section 6.3 | | SUBSCRIBE | TBA (0x40) | NO | Standards Track | Section |
| UNSUBSCRIBE | TBA (tentatively 0x42) | Section 6.4 | | | | | | 6.2 |
| RECONFIRM | TBA (tentatively 0x43) | Section 6.5 | | PUSH | TBA (0x41) | NA | Standards Track | Section |
+-------------+------------------------+-------------+ | | | | | 6.3 |
| UNSUBSCRIBE | TBA (0x42) | NA | Standards Track | Section |
| | | | | 6.4 |
| RECONFIRM | TBA (0x43) | NA | Standards Track | Section |
| | | | | 6.5 |
+-------------+------------+---------+-----------------+------------+
Table 5: IANA DSO TLV Type Code Assignments 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
 End of changes. 40 change blocks. 
122 lines changed or deleted 133 lines changed or added

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