< draft-ietf-dnssd-push-21.txt   draft-ietf-dnssd-push-22.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: January 6, 2020 Apple Inc. Expires: January 9, 2020 Apple Inc.
July 5, 2019 July 8, 2019
DNS Push Notifications DNS Push Notifications
draft-ietf-dnssd-push-21 draft-ietf-dnssd-push-22
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 January 6, 2020. This Internet-Draft will expire on January 9, 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 30 skipping to change at page 2, line 30
6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 13 6.2.1. SUBSCRIBE Request . . . . . . . . . . . . . . . . . . 13
6.2.2. SUBSCRIBE Response . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
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 Early Data . . . . . . . . . . . . . . . . . . . . . 33
7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
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 . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Domain Name System (DNS) records may be updated using DNS Update Domain Name System (DNS) records may be updated using DNS Update
[RFC2136]. Other mechanisms such as a Discovery Proxy [DisProx] can [RFC2136]. Other mechanisms such as a Discovery Proxy [DisProx] can
also generate changes to a DNS zone. This document specifies a also generate changes to a DNS zone. This document specifies a
protocol for DNS clients to subscribe to receive asynchronous protocol for DNS clients to subscribe to receive asynchronous
notifications of changes to RRSets of interest. It is immediately notifications of changes to RRSets of interest. It is immediately
relevant in the case of DNS Service Discovery [RFC6763] but is not relevant in the case of DNS Service Discovery [RFC6763] but is not
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._tcp.<zone>" SRV record for a zone MAY Consequently, the "_dns-push-tls._tcp.<zone>" SRV record for a zone
reference the same target host and port as that zone's MAY reference the same target host and port as that zone's
"_dns-update._tcp.<zone>" SRV record. When the same target host and "_dns-update-tls._tcp.<zone>" SRV record. When the same target host
port is offered for both DNS Updates and DNS Push Notifications, a and port is offered for both DNS Updates and DNS Push Notifications,
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 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._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 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:
skipping to change at page 6, line 42 skipping to change at page 6, line 42
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 which is a potential problem concerns of state overload at the server which is a potential problem
with connection-less protocols using spoofed source addresses. All with connectionless protocols using spoofed source addresses. All
subscribers are guaranteed to be reachable by the server by virtue of subscribers are guaranteed to be reachable by the server by virtue of
the TCP three-way handshake. Flooding attacks are possible with any the TCP three-way handshake. Flooding attacks are possible with any
protocol, and a benefit of TCP is that there are already established protocol, and a benefit of TCP is that there are already established
industry best practices to guard against SYN flooding and similar industry best practices to guard against SYN flooding and similar
attacks [SYN] [RFC4953]. 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)
skipping to change at page 9, 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 a DNS Push Notification subscription is to discover The first step in establishing a DNS Push Notification subscription
an appropriate DNS server that supports DNS Push Notifications for is to discover an appropriate DNS server that supports DNS Push
the desired zone. Notifications for 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, and the recursive resolver
will make a corresponding Push Notification subscription on the doesn't already have an active subscription for that name, type, and
client's behalf (if the recursive resolver doesn't already have an class, then the recursive resolver will make a corresponding Push
active subscription for that name, type, and class). This is closely Notification subscription on the client's behalf. Results received
analogous to how a client sends normal DNS queries to its configured are relayed to the client. This is closely analogous to how a client
DNS recursive resolver, which issues queries on the client's behalf sends a normal DNS query to its configured DNS recursive resolver
(if the recursive resolver doesn't already have appropriate answer(s) which, if it doesn't already have appropriate answer(s) in its cache,
in its cache). issues an upstream query to satisfy the request.
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
skipping to change at page 11, line 23 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._tcp.<zone>", where <zone> is the owner name of the "_dns-push-tls._tcp.<zone>", where <zone> is the owner name of
discovered SOA record. the 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 13, 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 DSO messages with the SUBSCRIBE TLV as the Primary TLV are permitted
permitted in early data. in early data, provided that the precautions described in Section 7.3
are followed.
The entity that initiates a SUBSCRIBE request is by definition the 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 TLS the client should immediately abort the connection with a TLS
close_notify alert. See Section 6.1 of [RFC8446]. close_notify alert (see Section 6.1 of the TLS 1.3 specification
[RFC8446]). After sending the TLS close_notify alert the client MUST
gracefully close the underlying connection using a TCP FIN, so that
the TLS close_notify is reliably delivered. The mechanisms for
gracefully closing a TCP connection with a TCP FIN vary depending on
the networking API. For example, in the BSD Sockets API, sending a
TCP FIN is achieved by calling "shutdown(s,SHUT_WR)" and keeping the
socket open until all remaining data has been read from it.
6.2.1. SUBSCRIBE Request 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 14, line 50 skipping to change at page 15, line 4
If accepted, the subscription will stay in effect until the client If accepted, the subscription will stay in effect until the client
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 a fatal error and the server MUST immediately terminate the
connection with a TLS close_notify alert. connection with a TLS close_notify alert followed by a TCP FIN.
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 not to any matches only a literal CNAME record in the zone, and not to any
records referenced by the owner name. 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
skipping to change at page 16, line 15 skipping to change at page 16, line 15
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]. The QR bit in the header is set indicating it is a [RFC8490]. The QR bit in the header is set indicating it is a
response. The header MAY be followed by one or more optional TLVs, response. The header MAY be followed by one or more optional TLVs,
such as a Retry Delay TLV. such as a Retry Delay TLV.
The MESSAGE ID field MUST echo the value given in the Message ID The MESSAGE ID field MUST echo the value given in the MESSAGE ID
field of the SUBSCRIBE request. This is how the client knows which field of the SUBSCRIBE request. This is how the client knows which
request is 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 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
skipping to change at page 18, line 33 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 "_dns-push._tcp.<zone>" If the server being queried is listed in a
SRV record for the zone, then this is a misconfiguration, since "_dns-push-tls._tcp.<zone>" SRV record for the zone, then this is
this server is being advertised as supporting DNS Push a misconfiguration, since this server is being advertised as
Notifications for this zone, but the server itself is not supporting DNS Push Notifications for this zone, but the server
currently configured to perform that task. Since it is possible itself is not currently configured to perform that task. Since it
that the misconfiguration may be repaired at any time, the retry is possible that the misconfiguration may be repaired at any time,
delay should not be set too high. By default, a value of 5 the retry delay should not be set too high. By default, a value
minutes is RECOMMENDED. of 5 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 "_dns-push._tcp.<zone>" If the server being queried is listed in a
SRV record for the zone, then this is a misconfiguration, since "_dns-push-tls._tcp.<zone>" SRV record for the zone, then this is
this server is being advertised as supporting DNS Push a misconfiguration, since this server is being advertised as
Notifications for this zone, but the server itself is not supporting DNS Push Notifications for this zone, but the server
currently configured to perform that task. Since it is possible itself is not currently configured to perform that task. Since it
that the misconfiguration may be repaired at any time, the retry is possible that the misconfiguration may be repaired at any time,
delay should not be set too high. By default, a value of 5 the retry delay should not be set too high. By default, a value
minutes is RECOMMENDED. of 5 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 39 skipping to change at page 20, line 39
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 TLS close_notify alert. connection with a TLS close_notify alert followed by a TCP FIN.
The change notification records are formatted similarly to how DNS 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 3, 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 TLS close_notify alert. There are terminate the connection with a TLS close_notify alert followed by a
three types of collective remove notification: TCP FIN. There are 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 22, line 51 skipping to change at page 23, line 4
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 TLS close_notify alert. immediately terminate the connection with a TLS close_notify alert
followed by a TCP FIN.
1 1 1 1 1 1 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 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 TLS close_notify alert. connection with a TLS close_notify alert followed by a TCP FIN.
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 4. 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.
skipping to change at page 31, line 34 skipping to change at page 31, line 34
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 should perform an orderly close of When closing a session, a client should perform an orderly close of
the TLS session in order to allow for future TLS session resumption the TLS session in order to allow for future TLS session resumption
with the server (if available). See Section 7.3 below. Typical APIs with the server (if available). See Section 7.4 below. Typical APIs
will provide a session close method that will send a TLS close_notify will provide a session close method that will send a TLS close_notify
alert. This instructs the recipient that the sender will not send alert. This instructs the recipient that the sender will not send
any more data over the session. Any pending writes on the server any more data over the session.
will be discarded when a close_notify is received.
If the session is forcibly closed at the TCP level by sending a RST If the session is forcibly closed at the TCP level by sending a RST
from either end of the connection, data may be lost and TLS session from either end of the connection, data may be lost and TLS session
resumption of this session will not be possible. resumption of this session will not be possible.
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,
skipping to change at page 33, line 9 skipping to change at page 33, line 16
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._tcp.<zone>". The server connection endpoint SHOULD then "_dns-push-tls._tcp.<zone>". The server connection endpoint SHOULD
be authenticated using DANE TLSA records for the associated SRV then 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
more information on authenticating domain names. more information on authenticating domain names.
7.3. TLS Session Resumption 7.3. TLS Early Data
DSO messages with the SUBSCRIBE TLV as the Primary TLV are permitted
in TLS early data. Using TLS early data can save one network round
trip, and can result in obtaining results faster. However, there are
some factors to consider before using TLS early data.
TLS Early Data is not forward secret. In cases where forward secrecy
of DNS Push Notification subscriptions is required, the client should
not use TLS Early Data.
With TLS early data there are no guarantees of non-replay between
connections. If packets are duplicated and delayed in the network,
the later arrivals could be mistaken for new subscription requests.
Generally this is not a major concern, since the amount of state
generated on the server for these spurious subscriptions is small and
short-lived, since the TCP connection will not complete the three-way
handshake. Servers MAY choose to implement rate-limiting measures
that are imposed when the server detects excessive numbers of
spurious subscription requests.
For further guidance please see Section 2.3, Section 8, and
Appendix E.5 of the TLS 1.3 specification [RFC8446].
7.4. TLS Session Resumption
TLS Session Resumption is permissible on DNS Push Notification TLS Session Resumption is permissible on DNS Push Notification
servers. The server may keep TLS state with Session IDs [RFC8446] or servers. The server may keep TLS state with Session IDs [RFC8446] or
operate in stateless mode by sending a Session Ticket [RFC5077] to operate in stateless mode by sending a Session Ticket [RFC5077] to
the client for it to store. However, closing the TLS connection the client for it to store. However, closing the TLS connection
terminates the DSO session. When the TLS session is resumed, the DNS terminates the DSO session. When the TLS session is resumed, the DNS
Push Notification server will not have any subscription state and Push Notification server will not have any subscription state and
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._tcp" | Section 6.1 | | DNS Push Notification | None | "_dns-push-tls._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 | Early | Status | Definition | | Name | Value | Early | Status | Definition |
| | | Data | | | | | | Data | | |
+-------------+------------+---------+-----------------+------------+ +-------------+------------+--------+-----------------+-------------+
| SUBSCRIBE | TBA (0x40) | NO | Standards Track | Section | | SUBSCRIBE | TBA (0x40) | OK | Standards Track | Section 6.2 |
| | | | | 6.2 | | PUSH | TBA (0x41) | NO | Standards Track | Section 6.3 |
| PUSH | TBA (0x41) | NA | Standards Track | Section | | UNSUBSCRIBE | TBA (0x42) | NO | Standards Track | Section 6.4 |
| | | | | 6.3 | | RECONFIRM | TBA (0x43) | NO | Standards Track | Section 6.5 |
| 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. 29 change blocks. 
80 lines changed or deleted 109 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/