draft-ietf-dnssd-push-22.txt   draft-ietf-dnssd-push-23.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 9, 2020 Apple Inc. Expires: January 22, 2020 Apple Inc.
July 8, 2019 July 21, 2019
DNS Push Notifications DNS Push Notifications
draft-ietf-dnssd-push-22 draft-ietf-dnssd-push-23
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 9, 2020. This Internet-Draft will expire on January 22, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
1.2. Fatal Errors . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. State Considerations . . . . . . . . . . . . . . . . . . . . 6
5. State Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8
6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 13 6.2. DNS Push Notification SUBSCRIBE . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . 32 6.8. Client Fallback to Polling . . . . . . . . . . . . . . . 32
7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 33 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 33
7.3. TLS Early Data . . . . . . . . . . . . . . . . . . . . . 33 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 34
7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 34 7.3. TLS Early Data . . . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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
limited to that use case, and provides a general DNS mechanism for limited to that use case, and provides a general DNS mechanism for
DNS record change notifications. Familiarity with the DNS protocol DNS record change notifications. Familiarity with the DNS protocol
and DNS packet formats is assumed [RFC1034] [RFC1035] [RFC6895]. and DNS packet formats is assumed [RFC1034] [RFC1035] [RFC6895].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. These words may also appear in this capitals, as shown here. These words may also appear in this
document in lower case as plain English words, absent their normative document in lower case as plain English words, absent their normative
meanings. meanings.
1.2. Fatal Errors
Certain invalid situations are described in this specification, like
a server sending a Push Notification subscription request to a
client, or a client sending a Push Notification response to a server.
These should never occur with a correctly implemented client and
server, and if they do occur then they indicate a serious
implementation error. In these extreme cases there is no reasonable
expectation of a graceful recovery, and the recipient detecting the
error should respond by unilaterally aborting the session without
regard for data loss. Such cases are addressed by having an engineer
investigate the cause of the failure and fixing the problem in the
software.
Where this specification says "forcibly abort", it means sending a
TCP RST to terminate the TCP connection, and the TLS session running
over that TCP connection. In the BSD Sockets API, this is achieved
by setting the SO_LINGER option to zero before closing the socket.
2. Motivation 2. Motivation
As the domain name system continues to adapt to new uses and changes As the domain name system continues to adapt to new uses and changes
in deployment, polling has the potential to burden DNS servers at in deployment, polling has the potential to burden DNS servers at
many levels throughout the network. Other network protocols have many levels throughout the network. Other network protocols have
successfully deployed a publish/subscribe model following the successfully deployed a publish/subscribe model following the
Observer design pattern [obs]. XMPP Publish-Subscribe [XEP0060] and Observer design pattern [obs]. XMPP Publish-Subscribe [XEP0060] and
Atom [RFC4287] are examples. While DNS servers are generally highly Atom [RFC4287] are examples. While DNS servers are generally highly
tuned and capable of a high rate of query/response traffic, adding a tuned and capable of a high rate of query/response traffic, adding a
publish/subscribe model for tracking changes to DNS records can publish/subscribe model for tracking changes to DNS records can
deliver more timely notification of changes with reduced CPU usage deliver more timely notification of changes with reduced CPU usage
and lower network traffic. and lower network traffic.
Multicast DNS [RFC6762] implementations always listen on a well known Multicast DNS [RFC6762] implementations always listen on a well known
link-local IP multicast group, and record changes are sent to that link-local IP multicast group address, and record changes are sent to
multicast group address for all group members to receive. Therefore, that multicast group address for all group members to receive.
Multicast DNS already has asynchronous change notification Therefore, Multicast DNS already has asynchronous change notification
capability. However, when DNS Service Discovery [RFC6763] is used capability. However, when DNS Service Discovery [RFC6763] is used
across a wide area network using Unicast DNS (possibly facilitated across a wide area network using Unicast DNS (possibly facilitated
via a Discovery Proxy [DisProx]) it would be beneficial to have an via a Discovery Proxy [DisProx]) it would be beneficial to have an
equivalent capability for Unicast DNS, to allow clients to learn equivalent capability for Unicast DNS, to allow clients to learn
about DNS record changes in a timely manner without polling. about DNS record changes in a timely manner without polling.
The DNS Long-Lived Queries (LLQ) mechanism [LLQ] is an existing The DNS Long-Lived Queries (LLQ) mechanism [LLQ] is an existing
deployed solution to provide asynchronous change notifications, used deployed solution to provide asynchronous change notifications, used
by Apple's Back to My Mac [RFC6281] service introduced in Mac OS X by Apple's Back to My Mac [RFC6281] service introduced in Mac OS X
10.5 Leopard in 2007. Back to My Mac was designed in an era when the 10.5 Leopard in 2007. Back to My Mac was designed in an era when the
skipping to change at page 5, line 8 skipping to change at page 5, line 8
and therefore doesn't need to reinvent existing TCP functionality. and therefore doesn't need to reinvent existing TCP functionality.
Using TCP also gives long-lived low-traffic connections better Using TCP also gives long-lived low-traffic connections better
longevity through NAT gateways without depending on the gateway to longevity through NAT gateways without depending on the gateway to
support NAT Port Mapping Protocol (NAT-PMP) [RFC6886] or Port Control support NAT Port Mapping Protocol (NAT-PMP) [RFC6886] or Port Control
Protocol (PCP) [RFC6887], or resorting to excessive keepalive Protocol (PCP) [RFC6887], or resorting to excessive keepalive
traffic. traffic.
3. Overview 3. Overview
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
MAY reference the same target host and port as that zone's The "_dns-push-tls._tcp.<zone>" SRV record for a zone MAY reference
the same target host and port as that zone's
"_dns-update-tls._tcp.<zone>" SRV record. When the same target host "_dns-update-tls._tcp.<zone>" SRV record. When the same target host
and port is offered for both DNS Updates and DNS Push Notifications, and port is offered for both DNS Updates and DNS Push Notifications,
a client MAY use a single TCP connection to that server for both DNS a client MAY use a single DSO session to that server for both DNS
Updates and DNS Push Notification Subscriptions. Updates and DNS Push Notification Subscriptions. DNS Updates and DNS
Push Notifications may be handled on different ports on the same
Supporting DNS Updates and DNS Push Notifications on the same server target host, in which case they are not considered to be the "same
is OPTIONAL. A DNS Push Notification server is not required to server" for the purposes of this specification, and communications
support DNS Update. with these two ports are handled independently. Supporting DNS
Updates and DNS Push Notifications on the same server is OPTIONAL. A
DNS Updates and DNS Push Notifications may be handled on different DNS Push Notification server is not required to support DNS Update.
ports on the same target host, in which case they are not considered
to be the "same server" for the purposes of this specification, and
communications with these two ports are handled independently.
Standard DNS Queries MAY be sent over a DNS Push Notification (i.e., 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 for names falling within
zone (e.g., the <zone> in the "_dns-push-tls._tcp.<zone>" SRV record) that zone (e.g., the "_dns-push-tls._tcp.<zone>" SRV record) both for
both for normal DNS queries and for DNS Push Notification normal DNS queries and for DNS Push Notification subscriptions. For
subscriptions. For names for which the server is acting as a names for which the server is acting as a recursive resolver, e.g.,
recursive resolver, e.g. when the server is the local recursive when the server is the local recursive resolver, for any query for
resolver, for any query for which it supports DNS Push Notification which it supports DNS Push Notification subscriptions, it MUST also
subscriptions, it MUST also support standard queries. 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:
(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
smartphone which, after some period of inactivity, goes to sleep or smartphone which, after some period of inactivity, goes to sleep or
otherwise darkens its screen, it should cancel its subscriptions when otherwise darkens its screen, it should cancel its subscriptions when
darkening the screen (since the user cannot see any changes in the darkening the screen (since the user cannot see any changes on the
display anyway) and reinstate its subscriptions when re-awakening display anyway) and reinstate its subscriptions when re-awakening
from display sleep. from display sleep.
(b) A DNS Push Notification client SHOULD NOT routinely keep a DNS (b) A DNS Push Notification client SHOULD NOT routinely keep a DNS
Push Notification subscription active 24 hours a day, 7 days a week, Push Notification subscription active 24 hours a day, 7 days a week,
just to keep a list in memory up to date so that if the user does just to keep a list in memory up to date so that if the user does
choose to bring up an on-screen display of that data, it can be choose to bring up an on-screen display of that data, it can be
displayed really fast. DNS Push Notifications are designed to be displayed really fast. DNS Push Notifications are designed to be
fast enough that there is no need to pre-load a "warm" list in memory fast enough that there is no need to pre-load a "warm" list in memory
just in case it might be needed later. just in case it might be needed later.
skipping to change at page 6, line 27 skipping to change at page 6, line 25
Generally, as described in the DNS Stateful Operations specification Generally, as described in the DNS Stateful Operations specification
[RFC8490], a client must not keep a session to a server open [RFC8490], a client must not keep a session to a server open
indefinitely if it has no subscriptions (or other operations) active indefinitely if it has no subscriptions (or other operations) active
on that session. A client MAY close a session as soon as it becomes on that session. A client MAY close a session as soon as it becomes
idle, and then if needed in the future, open a new session when idle, and then if needed in the future, open a new session when
required. Alternatively, a client MAY speculatively keep an idle required. Alternatively, a client MAY speculatively keep an idle
session open for some time, subject to the constraint that it MUST session open for some time, subject to the constraint that it MUST
NOT keep a session open that has been idle for more than the NOT keep a session open that has been idle for more than the
session's idle timeout (15 seconds by default) [RFC8490]. session's idle timeout (15 seconds by default) [RFC8490].
4. Transport 4. State Considerations
Each DNS Push Notification server is capable of handling some finite
number of Push Notification subscriptions. This number will vary
from server to server and is based on physical machine
characteristics, network bandwidth, and operating system resource
allocation. After a client establishes a session to a DNS server,
each subscription is individually accepted or rejected. Servers may
employ various techniques to limit subscriptions to a manageable
level. Correspondingly, the client is free to establish simultaneous
sessions to alternate DNS servers that support DNS Push Notifications
for the zone and distribute subscriptions at the client's discretion.
In this way, both clients and servers can react to resource
constraints.
5. Transport
Other DNS operations like DNS Update [RFC2136] MAY use either User Other DNS operations like DNS Update [RFC2136] MAY use either User
Datagram Protocol (UDP) [RFC0768] or Transmission Control Protocol Datagram Protocol (UDP) [RFC0768] or Transmission Control Protocol
(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
skipping to change at page 7, line 4 skipping to change at page 7, line 29
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 connectionless 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)
[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 used
deployed across many protocols running over TCP. It is designed to by many application-layer protocols running over TCP. TLS is
prevent eavesdropping, tampering, and message forgery. TLS is designed to prevent eavesdropping, tampering, and message forgery.
REQUIRED for every connection between a client subscriber and server TLS is REQUIRED for every connection between a client subscriber and
in this protocol specification. Additional security measures such as server in this protocol specification. Additional security measures
client authentication during TLS negotiation MAY also be employed to such as client authentication during TLS negotiation MAY also be
increase the trust relationship between client and server. employed to increase the trust relationship between client and
server.
5. State Considerations
Each DNS Push Notification server is capable of handling some finite
number of Push Notification subscriptions. This number will vary
from server to server and is based on physical machine
characteristics, network bandwidth, and operating system resource
allocation. After a client establishes a session to a DNS server,
each subscription is individually accepted or rejected. Servers may
employ various techniques to limit subscriptions to a manageable
level. Correspondingly, the client is free to establish simultaneous
sessions to alternate DNS servers that support DNS Push Notifications
for the zone and distribute subscriptions at the client's discretion.
In this way, both clients and servers can react to resource
constraints.
6. Protocol Operation 6. Protocol Operation
The DNS Push Notification protocol is a session-oriented protocol, The DNS Push Notification protocol is a session-oriented protocol,
and makes use of DNS Stateful Operations (DSO) [RFC8490]. and makes use of DNS Stateful Operations (DSO) [RFC8490].
For details of the DSO message format refer to the DNS Stateful Oper- For details of the DSO message format refer to the DNS Stateful Oper-
ations specification [RFC8490]. Those details are not repeated here. ations specification [RFC8490]. Those details are not repeated here.
DNS Push Notification clients and servers MUST support DSO. A single DNS Push Notification clients and servers MUST support DSO. A single
skipping to change at page 8, line 28 skipping to change at page 8, line 28
the appropriate server, using the procedure described in Section 6.1, the appropriate server, using the procedure described in Section 6.1,
and then making a TLS/TCP connection to it. and then making a TLS/TCP connection to it.
A typical DNS Push Notification client will immediately issue a DSO A typical DNS Push Notification client will immediately issue a DSO
Keepalive operation to request a session timeout and/or keepalive Keepalive operation to request a session timeout and/or keepalive
interval longer than the the 15-second default values, but this is interval longer than the the 15-second default values, but this is
not required. A DNS Push Notification client MAY issue other not required. A DNS Push Notification client MAY issue other
requests on the session first, and only issue a DSO Keepalive requests on the session first, and only issue a DSO Keepalive
operation later if it determines that to be necessary. Sending operation later if it determines that to be necessary. Sending
either a DSO Keepalive operation or a Push Notification subscription either a DSO Keepalive operation or a Push Notification subscription
over the TLS/TCP connection to the server signals the client's request over the TLS/TCP connection to the server signals the
support of DSO and serves to establish a DSO session. client's support of DSO and serves to establish a DSO session.
In accordance with the current set of active subscriptions, the In accordance with the current set of active subscriptions, the
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.
skipping to change at page 9, line 31 skipping to change at page 9, line 31
which, if it doesn't already have appropriate answer(s) in its cache, which, if it doesn't already have appropriate answer(s) in its cache,
issues an upstream query to satisfy the request. 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 supports
support DNS over TLS but is not listening on TCP port 853, or does DNS over TLS but is not listening on TCP port 853, or supports DNS
support DNS over TLS on TCP port 853 but does not support DSO on that over TLS on TCP port 853 but does not support DSO on that port, then
port, then the DSO Session session establishment will fail [RFC8490]. 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 SERVFAIL to the client. This includes being resolver should return SERVFAIL to the client. This includes being
unable to establish a connection to the zone's DNS Push Notification unable to establish a connection to the zone's DNS Push Notification
skipping to change at page 10, line 22 skipping to change at page 10, line 22
wishes to subscribe. Successive SOA queries are then issued, wishes to subscribe. Successive SOA queries are then issued,
trimming one label each time, until the closest enclosing trimming one label each time, until the closest enclosing
authoritative server is discovered. There is also an optimization to authoritative server is discovered. There is also an optimization to
enable the client to take a "short cut" directly to the SOA record of enable the client to take a "short cut" directly to the SOA record of
the closest enclosing authoritative server in many cases. the closest enclosing authoritative server in many cases.
1. The client begins the discovery by sending a DNS query to its 1. The client begins the discovery by sending a DNS query to its
local resolver, with record type SOA [RFC1035] for the record local resolver, with record type SOA [RFC1035] for the record
name to which it wishes to subscribe. As an example, suppose the name to which it wishes to subscribe. As an example, suppose the
client wishes to subscribe to PTR records with the name client wishes to subscribe to PTR records with the name
_ipp._tcp.foo.example.com (to discover Internet Printing Protocol _ipp._tcp.headoffice.example.com (to discover Internet Printing
(IPP) printers [RFC8010] [RFC8011] being advertised at Protocol (IPP) printers [RFC8010] [RFC8011] being advertised in
"foo.example.com"). The client begins by sending an SOA query the head office of Example Company.). The client begins by
for _ipp._tcp.foo.example.com to the local recursive resolver. sending an SOA query for _ipp._tcp.headoffice.example.com to the
The goal is to determine the server authoritative for the name local recursive resolver. The goal is to determine the server
_ipp._tcp.foo.example.com. The closest enclosing DNS zone authoritative for the name _ipp._tcp.headoffice.example.com. The
containing the name _ipp._tcp.foo.example.com could be closest enclosing DNS zone containing the name
example.com, or foo.example.com, or _tcp.foo.example.com, or even _ipp._tcp.headoffice.example.com could be example.com, or
_ipp._tcp.foo.example.com. The client does not know in advance headoffice.example.com, or _tcp.headoffice.example.com, or even
where the closest enclosing zone cut occurs, which is why it uses _ipp._tcp.headoffice.example.com. The client does not know in
the iterative procedure described here to discover this advance where the closest enclosing zone cut occurs, which is why
it uses the iterative procedure described here to discover this
information. information.
2. If the requested SOA record exists, it will be returned in the 2. If the requested SOA record exists, it will be returned in the
Answer section with a NOERROR response code, and the client has Answer section with a NOERROR response code, and the client has
succeeded in discovering the information it needs. succeeded in discovering the information it needs.
(This language is not placing any new requirements on DNS (This language is not placing any new requirements on DNS
recursive resolvers. This text merely describes the existing recursive resolvers. This text merely describes the existing
operation of the DNS protocol [RFC1034] [RFC1035].) operation of the DNS protocol [RFC1034] [RFC1035].)
3. If the requested SOA record does not exist, the client will get 3. If the requested SOA record does not exist, the client will get
skipping to change at page 11, line 9 skipping to change at page 11, line 9
requested name in the Authority Section. If the SOA record is requested name in the Authority Section. If the SOA record is
received in the Authority Section, then the client has succeeded received in the Authority Section, then the client has succeeded
in discovering the information it needs. in discovering the information it needs.
(This language is not placing any new requirements on DNS (This language is not placing any new requirements on DNS
recursive resolvers. This text merely describes the existing recursive resolvers. This text merely describes the existing
operation of the DNS protocol regarding negative responses operation of the DNS protocol regarding negative responses
[RFC2308].) [RFC2308].)
4. If the client receives a response containing no SOA record, then 4. If the client receives a response containing no SOA record, then
it proceeds with the iterative approach. The client strips the it proceeds with the iterative approach. The client strips the
leading label from the current query name and if the resulting leading label from the current query name, and if the resulting
name has at least one label in it, the client sends an SOA query name has at least two labels in it, the client sends an SOA query
for that new name, and processing continues at step 2 above, for that new name, and processing continues at step 2 above,
repeating the iterative search until either an SOA is received, repeating the iterative search until either an SOA is received,
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-tls._tcp.<zone>", where <zone> is the owner name of
the discovered SOA record. the discovered SOA record.
skipping to change at page 12, line 11 skipping to change at page 12, line 11
accept a subscription request, or is not reachable within a accept a subscription request, or is not reachable within a
reasonable time, as determined by the client, then a subsequent reasonable time, as determined by the client, then a subsequent
server is to be contacted. server is to be contacted.
Each time a client makes a new DNS Push Notification subscription Each time a client makes a new DNS Push Notification subscription
session, it SHOULD repeat the discovery process in order to determine session, it SHOULD repeat the discovery process in order to determine
the preferred DNS server for subscriptions at that time. However, the preferred DNS server for subscriptions at that time. However,
the client device MUST respect the DNS TTL values on records it the client device MUST respect the DNS TTL values on records it
receives, and store them in its local cache with this lifetime. This receives, and store them in its local cache with this lifetime. This
means that, as long as the DNS TTL values on the authoritative means that, as long as the DNS TTL values on the authoritative
records were set to reasonable values, repeated application of this records are set to reasonable values, repeated application of this
discovery process can be completed nearly instantaneously by the discovery process can be completed nearly instantaneously by the
client, using only locally-stored cached data. client, using only locally-stored cached data.
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 permitted DSO messages with the SUBSCRIBE TLV as the Primary TLV are permitted
in early data, provided that the precautions described in Section 7.3 in TLS early data, provided that the precautions described in
are followed. 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 MUST forcibly abort the connection immediately.
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 52 skipping to change at page 14, line 49
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 a fatal error and the server MUST immediately terminate the this is a fatal error and the server MUST forcibly abort the
connection with a TLS close_notify alert followed by a TCP FIN. connection immediately.
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 no other records
records referenced by the owner name. with the same 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 16, line 24 skipping to change at page 16, line 24
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.
A client MUST NOT send a SUBSCRIBE response. If a client does send a
SUBSCRIBE message, with the QR bit set indicating that it is a
response, this is a fatal error and the server MUST forcibly abort
the connection immediately.
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 | \ | MESSAGE ID | \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|QR| OPCODE(6) | Z | RCODE | | |QR| OPCODE(6) | Z | RCODE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER
| ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | |
skipping to change at page 20, line 30 skipping to change at page 20, line 30
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).
A client MUST NOT send a PUSH message. If a client does send a PUSH
message, or a PUSH message is sent with the QR bit set indicating
that it is a response, this is a fatal error and the receiver MUST
forcibly abort the connection immediately.
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 client MUST forcibly abort the connection
connection with a TLS close_notify alert followed by a TCP FIN. immediately.
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 client MUST forcibly abort the
terminate the connection with a TLS close_notify alert followed by a connection immediately.
TCP FIN. There are three types of collective remove notification:
For collective remove notifications, if CLASS is 255 (ANY), then for There are three types of collective remove notification:
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 For collective remove notifications, if CLASS is not 255 (ANY) and
silently ignored on reception. TYPE is not 255 (ANY) then for the given name this deletes all
records of the specified type in the specified class.
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.
For collective remove notifications, if CLASS is not 255 (ANY) and For collective remove notifications, if CLASS is 255 (ANY), then for
TYPE is not 255 (ANY) then for the given name this deletes all the given name this deletes all records of all types in all classes.
records of the specified type in the specified class. In this case TYPE MUST be set to zero on transmission, and MUST be
silently ignored on reception.
Summary of change notification types: Summary of change notification types:
Delete all RRsets from a name, in all classes Delete all RRsets from a name, in all classes
TTL=0xFFFFFFFE, RDLENGTH=0, CLASS=255 (ANY) TTL=0xFFFFFFFE, RDLENGTH=0, CLASS=255 (ANY)
Delete all RRsets from a name, in given class: Delete all RRsets from a name, in given class:
TTL=0xFFFFFFFE, RDLENGTH=0, CLASS specifies class, TYPE=255 (ANY) TTL=0xFFFFFFFE, RDLENGTH=0, CLASS specifies class, TYPE=255 (ANY)
Delete specified RRset from a name, in given class: Delete specified RRset from a name, in given class:
TTL=0xFFFFFFFE, RDLENGTH=0 TTL=0xFFFFFFFE, RDLENGTH=0
CLASS and TYPE specify the RRset being deleted CLASS and TYPE specify the RRset being deleted
Delete an individual RR from a name: Delete an individual RR from a name:
TTL=0xFFFFFFFF TTL=0xFFFFFFFF
CLASS, TYPE, RDLENGTH and RDATA specify the RR being deleted. CLASS, TYPE, RDLENGTH and RDATA specify the RR being deleted.
Add individual RR to a name Add individual RR to a name
TTL>=0 TTL⩾0
CLASS, TYPE, RDLENGTH, RDATA and TTL specify the RR being added. CLASS, TYPE, RDLENGTH, RDATA and TTL specify the RR being added.
Note that it is valid for the RDATA of an added or removed DNS Note that it is valid for the RDATA of an added or removed DNS
Resource Record to be empty (zero length). For example, an Address Resource Record to be empty (zero length). For example, an Address
Prefix List Resource Record [RFC3123] may have empty RDATA. Prefix List Resource Record [RFC3123] may have empty RDATA.
Therefore, a change notification with RDLEN=0 does not automatically Therefore, a change notification with RDLEN=0 does not automatically
indicate a remove notification. If RDLEN=0 and TTL is the in the indicate a remove notification. If RDLEN=0 and TTL is the in the
range 0 - 0x7FFFFFFF, this change notification signals the addition range 0 - 0x7FFFFFFF, this change notification signals the addition
of a record with the given name, type, class, and empty RDATA. If of a record with the given name, type, class, and empty RDATA. If
RDLEN=0 and TTL = 0xFFFFFFFF, this change notification signals the RDLEN=0 and TTL = 0xFFFFFFFF, this change notification signals the
skipping to change at page 22, line 50 skipping to change at page 23, line 6
byte stream like TLS, this makes a total of 16,384 bytes. Servers byte stream like TLS, this makes a total of 16,384 bytes. Servers
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, this is a fatal error, and the client MUST
immediately terminate the connection with a TLS close_notify alert forcibly abort the connection immediately.
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 23, line 35 skipping to change at page 23, line 37
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
\ NAME \ \ \ NAME \ \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TYPE | | | TYPE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| CLASS | | | CLASS | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TTL | | | TTL | |
| (32-bit unsigned big-endian integer) | > DSO-DATA | (32-bit unsigned big-endian integer) | > DSO-DATA
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| RDLEN | | | RDLEN (16-bit unsigned big-endian integer) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
\ 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 3: 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
skipping to change at page 25, line 14 skipping to change at page 25, line 14
6.4. DNS Push Notification UNSUBSCRIBE 6.4. DNS Push Notification UNSUBSCRIBE
To cancel an individual subscription without closing the entire DSO To cancel an individual subscription without closing the entire DSO
session, the client sends an UNSUBSCRIBE message over the established session, the client sends an UNSUBSCRIBE message over the established
DSO session to the server. The UNSUBSCRIBE message is encoded as a DSO session to the server. The UNSUBSCRIBE message is encoded as a
DSO unidirectional message [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 send an UNSUBSCRIBE message. If a server does send
send an UNSUBSCRIBE message over a DSO session initiated by a client, an UNSUBSCRIBE message over a DSO session initiated by a client, or
this is a fatal error and the client should immediately abort the an UNSUBSCRIBE message is sent with the QR bit set indicating that it
connection with a TLS close_notify alert followed by a TCP FIN. is a response, this is a fatal error and the receiver MUST forcibly
abort the connection immediately.
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 27, line 28 skipping to change at page 27, line 28
Notification RECONFIRM message by calling the underlying API's Notification RECONFIRM message by calling the underlying API's
DNSServiceReconfirmRecord() routine. DNSServiceReconfirmRecord() routine.
For other types of DNS server, the RECONFIRM operation is currently For other types of DNS server, the RECONFIRM operation is currently
undefined, and SHOULD result in a NOERROR response, but otherwise undefined, and SHOULD result in a NOERROR response, but otherwise
need not cause any action to occur. need not cause any action to occur.
Frequent use of RECONFIRM operations may be a sign of network Frequent use of RECONFIRM operations may be a sign of network
unreliability, or some kind of misconfiguration, so RECONFIRM unreliability, or some kind of misconfiguration, so RECONFIRM
operations MAY be logged or otherwise communicated to a human operations MAY be logged or otherwise communicated to a human
administrator to assist in detecting, and remedying, such network administrator to assist in detecting and remedying such network
problems. problems.
If, after receiving a valid RECONFIRM message, the server determines If, after receiving a valid RECONFIRM message, the server determines
that the disputed records are in fact no longer valid, then that the disputed records are in fact no longer valid, then
subsequent DNS PUSH Messages will be generated to inform interested subsequent DNS PUSH Messages will be generated to inform interested
clients. Thus, one client discovering that a previously-advertised clients. Thus, one client discovering that a previously-advertised
device (like a network printer) is no longer present has the side device (like a network printer) is no longer present has the side
effect of informing all other interested clients that the device in effect of informing all other interested clients that the device in
question is now gone. question is now gone.
A server MUST NOT send a RECONFIRM message. If a server does send a
RECONFIRM message over a DSO session initiated by a client, or a
RECONFIRM message is sent with the QR bit set indicating that it is a
response, this is a fatal error and the receiver MUST forcibly abort
the connection immediately.
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 5. 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.
skipping to change at page 29, line 5 skipping to change at page 28, line 26
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 RECONFIRM (tentatively 0x43). The DSO-TYPE is RECONFIRM (tentatively 0x43).
The DSO-LENGTH is the length of the data that follows, which The DSO-LENGTH is the length of the data that follows, which
specifies the name, type, class, and content of the record being specifies the name, type, class, and content of the record being
disputed. disputed.
The DSO-DATA for a RECONFIRM message MUST contain exactly one record.
The DSO-DATA for a RECONFIRM message has no count field to specify
more than one record. Since RECONFIRM messages are sent over TCP,
multiple RECONFIRM messages can be concatenated in a single TCP
stream and packed efficiently into TCP segments.
TYPE MUST NOT be the value ANY (255) and CLASS MUST NOT be the value
ANY (255).
DNS wildcarding is not supported. That is, a wildcard ("*") in a
RECONFIRM message matches only a literal wildcard character ("*") in
the zone, and nothing else.
Aliasing is not supported. That is, a CNAME in a RECONFIRM message
matches only a literal CNAME record in the zone, and no other records
with the same owner name.
Note that there is no RDLEN field, since the length of the RDATA can
be inferred from DSO-LENGTH, so an additional RDLEN field would be
redundant.
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 | \ | MESSAGE ID | \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
|QR| OPCODE(6) | Z | RCODE | | |QR| OPCODE(6) | Z | RCODE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| QDCOUNT (MUST BE ZERO) | | | QDCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > HEADER
| ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | |
skipping to change at page 29, line 35 skipping to change at page 30, line 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TYPE | | | TYPE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA
| CLASS | | | CLASS | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
\ RDATA \ / \ RDATA \ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
Figure 5: 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 has no count field to specify
more than one record. Since RECONFIRM messages are sent over TCP,
multiple RECONFIRM messages can be concatenated in a single TCP
stream and packed efficiently into TCP segments.
TYPE MUST NOT be the value ANY (255) and CLASS MUST NOT be the value
ANY (255).
DNS wildcarding is not supported. That is, a wildcard ("*") in a
RECONFIRM message matches only a literal wildcard character ("*") in
the zone, and nothing else.
Aliasing is not supported. That is, a CNAME in a RECONFIRM message
matches only a literal CNAME record in the zone, and nothing else.
6.6. DNS Stateful Operations TLV Context Summary 6.6. DNS Stateful Operations TLV Context Summary
This document defines four new DSO TLVs. As suggested in Section 8.2 This document defines four new DSO TLVs. As suggested in Section 8.2
of the DNS Stateful Operations specification [RFC8490], the valid of the DNS Stateful Operations specification [RFC8490], the valid
contexts of these new TLV types are summarized below. contexts of these new TLV types are summarized below.
The client TLV contexts are: The client TLV contexts are:
C-P: Client request message, primary TLV C-P: Client request message, primary TLV
C-U: Client unidirectional message, primary TLV C-U: Client unidirectional message, primary TLV
skipping to change at page 31, line 36 skipping to change at page 31, line 36
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.4 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 (see Section 6.1 of the TLS 1.3 specification [RFC8446]). This
any more data over the session. instructs the recipient that the sender will not send any more data
over the session. 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.
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.
6.8. Client Fallback to Polling
There are cases where a client may exhaust all avenues for
establishing a DNS Push Notification subscription without success.
This can happen if the client's configured recursive resolver does
not support DNS over TLS, or supports DNS over TLS but is not
listening on TCP port 853, or supports DNS over TLS on TCP port 853
but does not support DSO on that port, or for some other reason is
unable to provide a DNS Push Notification subscription. In this case
the client will attempt to communicate directly with an appropriate
server, and it may be that the zone apex discovery fails, or there is
no "_dns-push-tls._tcp.<zone>" SRV record, or server indicated in the
SRV record is misconfigured, or is unresponsive for some other
reason.
Regardless of the reason for the failure, after being unable to
establish the desired DNS Push Notification subscription, it is
likely that the client will still wish to know the answer it seeks,
even if that answer cannot be obtained with the timely change
notifications provided by DNS Push Notifications. In such cases it
is likely that the client will obtain the answer it seeks via a
conventional DNS query instead, repeated at some interval to detect
when the answer RRset changes.
In the case where a client responds to its failure to establish a DNS
Push Notification subscription by falling back to polling with
conventional DNS queries instead, the polling rate should be
controlled to avoid placing excessive burden on the server. The
interval between successive DNS queries for the same name, type and
class SHOULD be at least the minimum of: 900 seconds (15 minutes), or
two seconds more than the TTL of the answer RRset.
The reason that for TTLs shorter than 898 seconds the query should
not be reissued until two seconds *after* the answer RRset has
expired is to ensure that the answer RRset has also expired from the
cache on the client's configured recursive resolver. Otherwise
(particularly if the clocks on the client and the recursive resolver
do not run at precisely the same rate) there's a risk of a race
condition where the client queries its configured recursive resolver
just as the answer RRset has one second remaining in the recursive
resolver's cache. The client would then receive a reply telling it
that the answer RRset has one second remaining, and then the client
would then re-query the recursive resolver again one second later
when the answer RRset actually expires, and only then would the
recursive resolver issue a new query to fetch new fresh data from the
authoritative server. Waiting until the answer RRset has definitely
expired from the the cache on the client's configured recursive
resolver avoids this race condition and unnecessary additional
queries it causes.
Each time a client is about to reissue its query to discover changes
to the answer RRset, it should first make a new attempt to establish
a DNS Push Notification subscription, using previously cached DNS
answers as appropriate. After a temporary misconfiguration has been
remedied, this allows a client that is polling to return to using DNS
Push Notifications for asynchronous notification of changes.
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
[RFC8310] for additional recommendations for various versions of TLS [RFC8310] for additional recommendations for various versions of TLS
skipping to change at page 33, line 34 skipping to change at page 34, line 42
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 Early Data 7.3. TLS Early Data
DSO messages with the SUBSCRIBE TLV as the Primary TLV are permitted 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 in TLS early data. Using TLS early data can save one network round
trip, and can result in obtaining results faster. However, there are trip, and can result in the client obtaining results faster.
some factors to consider before using TLS early data.
However, there are some factors to consider before using TLS early
data.
TLS Early Data is not forward secret. In cases where forward secrecy TLS Early Data is not forward secret. In cases where forward secrecy
of DNS Push Notification subscriptions is required, the client should of DNS Push Notification subscriptions is required, the client should
not use TLS Early Data. not use TLS Early Data.
With TLS early data there are no guarantees of non-replay between With TLS early data there are no guarantees of non-replay between
connections. If packets are duplicated and delayed in the network, connections. If packets are duplicated and delayed in the network,
the later arrivals could be mistaken for new subscription requests. the later arrivals could be mistaken for new subscription requests.
Generally this is not a major concern, since the amount of state Generally this is not a major concern, since the amount of state
generated on the server for these spurious subscriptions is small and generated on the server for these spurious subscriptions is small and
short-lived, since the TCP connection will not complete the three-way short-lived, since the TCP connection will not complete the three-way
handshake. Servers MAY choose to implement rate-limiting measures handshake. Servers MAY choose to implement rate-limiting measures
that are imposed when the server detects excessive numbers of that are activated when the server detects an excessive number of
spurious subscription requests. spurious subscription requests.
For further guidance please see Section 2.3, Section 8, and For further guidance please see Section 2.3, Section 8, and
Appendix E.5 of the TLS 1.3 specification [RFC8446]. Appendix E.5 of the TLS 1.3 specification [RFC8446].
7.4. TLS Session Resumption 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
skipping to change at page 35, line 5 skipping to change at page 36, line 35
| | | Data | | | | | | Data | | |
+-------------+------------+--------+-----------------+-------------+ +-------------+------------+--------+-----------------+-------------+
| SUBSCRIBE | TBA (0x40) | OK | Standards Track | Section 6.2 | | SUBSCRIBE | TBA (0x40) | OK | Standards Track | Section 6.2 |
| PUSH | TBA (0x41) | NO | Standards Track | Section 6.3 | | PUSH | TBA (0x41) | NO | Standards Track | Section 6.3 |
| UNSUBSCRIBE | TBA (0x42) | NO | Standards Track | Section 6.4 | | UNSUBSCRIBE | TBA (0x42) | NO | Standards Track | Section 6.4 |
| RECONFIRM | TBA (0x43) | NO | Standards Track | Section 6.5 | | RECONFIRM | TBA (0x43) | NO | Standards Track | Section 6.5 |
+-------------+------------+--------+-----------------+-------------+ +-------------+------------+--------+-----------------+-------------+
Table 5: IANA DSO TLV Type Code Assignments Table 5: IANA DSO TLV Type Code Assignments
This document defines no new DNS OPCODEs or RCODEs.
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, Sara Dickinson, Mark Delany, Ralph Droms, Jan Komissar, Eric
Shankar Rao, Markus Stenberg, Dave Thaler, Soraia Zlatkovic, Sara Rescorla, Michael Richardson, David Schinazi, Manju Shankar Rao,
Dickinson, and Andrew Sullivan. Ted Lemon provided clarifying text Robert Sparks, Markus Stenberg, Andrew Sullivan, Michael Sweet, Dave
Thaler, Brian Trammell, Bernie Volz, Eric Vyncke, Christopher Wood,
Liang Xia, and Soraia Zlatkovic. Ted Lemon provided clarifying text
that was greatly appreciated. that was greatly appreciated.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
 End of changes. 47 change blocks. 
153 lines changed or deleted 258 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/