rfc8765xml2.original.xml   rfc8765.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0020 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.0020.xml">
<!ENTITY RFC0768 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.0768.xml">
<!ENTITY RFC0793 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.0793.xml">
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.1034.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.1035.xml">
<!ENTITY RFC1123 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.1123.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml">
<!ENTITY RFC2136 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2136.xml">
<!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2181.xml">
<!ENTITY RFC2308 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2308.xml">
<!ENTITY RFC3123 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3123.xml">
<!ENTITY RFC2782 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2782.xml">
<!ENTITY RFC4287 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4287.xml">
<!ENTITY RFC4953 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4953.xml">
<!ENTITY RFC6066 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6066.xml">
<!ENTITY RFC6281 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6281.xml">
<!ENTITY RFC6762 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6762.xml">
<!ENTITY RFC6763 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6763.xml">
<!ENTITY RFC6824 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6824.xml">
<!ENTITY RFC6886 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6886.xml">
<!ENTITY RFC6887 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6887.xml">
<!ENTITY RFC6895 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6895.xml">
<!ENTITY RFC7413 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7413.xml">
<!ENTITY RFC7673 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7673.xml">
<!ENTITY RFC7719 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7719.xml">
<!ENTITY RFC7766 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7766.xml">
<!ENTITY RFC7858 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7858.xml">
<!ENTITY RFC8010 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8010.xml">
<!ENTITY RFC8011 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8011.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml">
<!ENTITY RFC8310 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8310.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8446.xml">
<!ENTITY RFC8490 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8490.xml">
<!ENTITY RFC8499 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8499.xml">
<!ENTITY I-D.ietf-tcpm-rack SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/b
ibxml3/reference.I-D.ietf-tcpm-rack.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-dnssd-push-25" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="DNS Push Notifications">DNS Push Notifications</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Tom Pusateri" initials="T.J." surname="Pusateri">
<organization>Unaffiliated</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Raleigh</city>
<region>NC</region>
<code>27608</code>
<country>USA</country>
</postal>
<phone>+1 919 867 1330</phone>
<email>pusateri@bangj.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
<organization>Apple Inc.</organization>
<address>
<postal>
<street>One Apple Park Way</street>
<!-- Reorder these if your country does things differently -->
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>USA</country>
</postal>
<phone>+1 (408) 996-1010</phone>
<email>cheshire@apple.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year='2019' month='October' day='13'/>
<!-- If the month and year are both specified and are the current ones, xml2r <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
fc will fill consensus="true" docName="draft-ietf-dnssd-push-25" number="8765"
in the current day for you. If only the current year is specified, xml2r ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
fc will fill xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true"
in the current day and month for you. If the year is not the current one sortRefs="true" version="3">
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations --> <front>
<area>DNSSD</area> <title abbrev="DNS Push Notifications">DNS Push Notifications</title>
<seriesInfo name="RFC" value="8765"/>
<workgroup>Internet Engineering Task Force</workgroup> <author fullname="Tom Pusateri" initials="T." surname="Pusateri">
<organization>Unaffiliated</organization>
<address>
<postal>
<street/>
<!-- WG name at the upper left corner of the doc, <city>Raleigh</city>
IETF is fine for individual submissions. <region>NC</region>
If this element is not present, the default is "Network Working Group", <code>27608</code>
which is used by the RFC Editor as a nod to the history of the IETF. --> <country>United States of America</country>
</postal>
<phone>+1 919 867 1330</phone>
<email>pusateri@bangj.com</email>
<keyword>dns update push notification</keyword> </address>
</author>
<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
<organization>Apple Inc.</organization>
<address>
<postal>
<street>One Apple Park Way</street>
<!-- Keywords will be incorporated into HTML output <city>Cupertino</city>
files in a meta tag but they have no effect on text or nroff <region>CA</region>
output. If you submit your draft to the RFC Editor, the <code>95014</code>
keywords will be used for the search engine. --> <country>United States of America</country>
</postal>
<phone>+1 (408) 996-1010</phone>
<email>cheshire@apple.com</email>
<abstract> </address>
<t>The Domain Name System (DNS) was designed to return matching records </author>
efficiently for queries for data that are relatively static. <date year="2020" month="June"/>
When those records change frequently, DNS is still efficient at returning
the updated results when polled, as long as the polling rate is not too hig
h.
But there exists no mechanism
for a client to be asynchronously notified when these changes occur.
This document defines a mechanism for a client to be notified
of such changes to DNS records, called DNS Push Notifications.</t>
</abstract>
</front>
<middle> <area>INT</area>
<?rfc needLines="14" ?> <workgroup>DNSSD</workgroup>
<section title="Introduction">
<t>Domain Name System (DNS) records may be updated using <xref target="RFC2 <keyword>Push notification</keyword>
136">DNS Update</xref>. <keyword>Asynchronous notification</keyword>
Other mechanisms such as a <xref target="DisProx">Discovery Proxy</xref> ca
n also generate changes to a DNS zone.
This document specifies a protocol for DNS clients to subscribe to receive
asynchronous notifications of changes to RRsets of interest. It is immediately r
elevant in the case of <xref target="RFC6763">DNS Service Discovery</xref> but i
s not limited to that use case, and provides a general DNS mechanism for DNS rec
ord change notifications. Familiarity with the DNS protocol and DNS packet forma
ts is assumed <xref target="RFC1034"/> <xref target="RFC1035"/> <xref target="RF
C6895"/>.</t>
<?rfc needLines="7" ?> <abstract>
<section title="Requirements Language"> <t>The Domain Name System (DNS) was designed to return matching records
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", efficiently for queries for data that are relatively static. When those
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", records change frequently, DNS is still efficient at returning the
and "OPTIONAL" in this document are to be interpreted as described updated results when polled, as long as the polling rate is not too
in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> high.
when, and only when, they appear in all capitals, as shown here. But, there exists no mechanism for a client to be asynchronously
These words may also appear in this document in lower case as notified
plain English words, absent their normative meanings.</t> when these changes occur. This document defines a mechanism for a
</section> client to be notified of such changes to DNS records, called DNS Push
Notifications.</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>Domain Name System (DNS) records may be updated using DNS Update
<xref target="RFC2136" format="default"></xref>. Other mechanisms such
as a Discovery Proxy <xref target="RFC8766" format="default"></xref> can
also generate changes to a DNS zone. This document specifies a protocol
for DNS clients to subscribe to receive asynchronous notifications of
changes to RRsets of interest. It is immediately relevant in the case of
DNS-based Service Discovery <xref target="RFC6763" format="default"></xref
>
but is not limited to that use case; it provides a general DNS
mechanism for DNS record change notifications. Familiarity with the DNS
protocol and DNS packet formats is assumed <xref target="RFC1034"
format="default"/> <xref target="RFC1035" format="default"/> <xref
target="RFC6895" format="default"/>.</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Fatal Errors"> <t>
<t>Certain invalid situations are described in this specification, The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
like a server sending a Push Notification subscription request to a clien "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
t, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
or a client sending a Push Notification response to a server. "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
These should never occur with a correctly implemented client and server, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
and if they do occur then they indicate a serious implementation error. to be interpreted as
In these extreme cases there is no reasonable expectation of a graceful r described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
ecovery, when, and only when, they appear in all capitals, as shown here.
and the recipient detecting the error should respond by unilaterally </t>
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.</t>
<t>Where this specification says "forcibly abort", it means </section>
sending a TCP RST to terminate the TCP connection, <section numbered="true" toc="default">
<name>Fatal Errors</name>
<t>Certain invalid situations are described in this specification,
such
as 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.</t>
<t>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. and the TLS session running over that TCP connection.
In the BSD Sockets API, this is achieved by setting the In the BSD Sockets API, this is achieved by setting the
SO_LINGER option to zero before closing the socket.</t> SO_LINGER option to zero before closing the socket.</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Motivation</name>
<t>As the domain name system continues to adapt to new uses and changes
in deployment, polling has the potential to burden DNS servers at many
levels throughout the network. Other network protocols have successfully
deployed a publish/subscribe model following the Observer design pattern
<xref target="OBS" format="default"></xref>. Extensible Messaging and
Presence Protocol (XMPP) Publish-Subscribe
<xref target="XEP0060" format="default"></xref> and Atom <xref
target="RFC4287" format="default"></xref> are examples. While DNS
servers are generally highly tuned and capable of a high rate of
query/response traffic, adding a publish/subscribe model for tracking
changes to DNS records can deliver more timely notifications of changes
with reduced CPU usage and lower network traffic.</t>
<t>The guiding design principle of DNS Push Notifications
is that clients that choose to use DNS Push Notifications,
instead of repeated polling with DNS queries,
will receive the same results as they could
via sufficiently rapid polling, except more efficiently.
This means that the rules for
which records match a given DNS Push Notification subscription are the
same as the already established rules used to determine
which records match a given DNS query <xref target="RFC1034"
format="default"/>.
For example, name comparisons are done in a case-insensitive manner,
and a record of type CNAME in a zone matches any DNS TYPE in a query or
subscription.</t>
<t>Multicast DNS <xref target="RFC6762" format="default"></xref>
implementations always listen on a well-known link-local IP multicast
group address, and changes are sent to that multicast group address for
all group members to receive. Therefore, Multicast DNS already has
asynchronous change notification capability. When DNS-based Service Disco
very
<xref target="RFC6763" format="default"></xref> is used across a wide
area network using Unicast DNS (possibly facilitated via a Discovery
Proxy <xref target="RFC8766" format="default"></xref>), it would be
beneficial to have an equivalent capability for Unicast DNS in order to
allow clients to learn about DNS record changes in a timely manner
without polling.</t>
<t>The DNS Long-Lived Queries (LLQ) mechanism <xref target="RFC8764"
format="default"></xref> is an existing deployed solution to provide
asynchronous change notifications; it was used by Apple's Back to
My Mac <xref target="RFC6281" format="default"></xref> service
introduced in Mac OS X 10.5 Leopard in 2007. Back to My Mac was
designed in an era when the data center operations staff asserted that
it was impossible for a server to handle large numbers of
TCP connections, even if those connections carried
very little traffic and spent most of their time idle.
Consequently, LLQ was defined as a UDP-based protocol, effectively
replicating much of TCP's connection state management logic in user
space and creating its own imitation of existing TCP features like flow
control, reliability, and the three-way handshake.</t>
<?rfc needLines="40" ?> <t>This document builds on experience gained with the LLQ protocol, with
</section> an improved design. Instead of using UDP, this specification uses DNS
</section> Stateful Operations (DSO) <xref target="RFC8490"
format="default"></xref> running over TLS over TCP, and therefore
<section title="Motivation"> doesn't need to reinvent existing TCP functionality. Using TCP also
<t>As the domain name system continues to adapt to new uses and changes in gives long-lived low-traffic connections better longevity through NAT
deployment, polling has the potential to burden DNS servers at many levels throu gateways without depending on the gateway to support NAT Port Mapping
ghout the network. Other network protocols have successfully deployed a publish/ Protocol (NAT-PMP) <xref target="RFC6886" format="default"></xref> or
subscribe model following the <xref target="obs">Observer design pattern</xref>. Port Control Protocol (PCP) <xref target="RFC6887"
<xref target="XEP0060">XMPP Publish-Subscribe</xref> and <xref target="RFC4 format="default"></xref>, or resorting to excessive keepalive
287">Atom</xref> are examples. While DNS servers are generally highly tuned and traffic.</t>
capable of a high rate of query/response traffic, adding a publish/subscribe mod </section>
el for tracking changes to DNS records can deliver more timely notification of c
hanges with reduced CPU usage and lower network traffic.</t>
<t><xref target="RFC6762">Multicast DNS</xref> implementations always liste
n on a well known link-local
IP multicast group address, and changes are sent to that multicast group ad
dress for all group members to receive.
Therefore, Multicast DNS already has asynchronous change notification capab
ility.
When <xref target="RFC6763">DNS Service Discovery</xref> is used across a w
ide area network using Unicast DNS
(possibly facilitated via a <xref target="DisProx">Discovery Proxy</xref>)
it would be beneficial to have an equivalent
capability for Unicast DNS, to allow clients to learn about DNS record chan
ges in a timely manner without polling.</t>
<t>The <xref target="LLQ">DNS Long-Lived Queries (LLQ) mechanism</xref> is
an existing deployed solution to provide asynchronous change notifications, used
by Apple's <xref target="RFC6281">Back to My Mac</xref> service
introduced in Mac OS X 10.5 Leopard in 2007.
Back to My Mac was designed in an era when the data center operations staff
asserted that it was impossible for a server to handle large numbers of mostly-
idle TCP connections, so LLQ was defined as a UDP-based protocol, effectively re
plicating much of TCP's connection state management logic in user space, and cre
ating its own imitation of existing TCP features like the three-way handshake, f
low control, and reliability.</t>
<t>This document builds on experience gained with the LLQ protocol, with an
improved design.
Instead of using UDP, this specification uses
<xref target="RFC8490">DNS Stateful Operations (DSO)</xref>
running over TLS over TCP,
and therefore doesn't need to reinvent existing TCP functionality.
Using TCP also gives long-lived low-traffic connections better longevity th
rough NAT gateways
without depending on the gateway to support
<xref target="RFC6886">NAT Port Mapping Protocol (NAT-PMP)</xref> or
<xref target="RFC6887">Port Control Protocol (PCP)</xref>, or
resorting to excessive keepalive traffic.</t>
<?rfc needLines="9" ?>
</section>
<section title="Overview">
<t>A DNS Push Notification client subscribes for Push Notifications for a p
articular RRset by connecting to the appropriate Push Notification server for th
at RRset, and sending DSO message(s) indicating the RRset(s) of interest. When t
he client loses interest in receiving further updates to these records, it unsub
scribes.</t>
<t>The DNS Push Notification server for a DNS zone is any server capable <section numbered="true" toc="default">
<name>Overview</name>
<t>A DNS Push Notification client subscribes for Push Notifications for
a particular RRset by connecting to the appropriate Push Notification
server for that RRset and sending DSO message(s) indicating the
RRset(s) of interest. When the client loses interest in receiving
further updates to these records, it unsubscribes.</t>
<t>The DNS Push Notification server for a DNS zone is any server capable
of generating the correct change notifications for a name. of generating the correct change notifications for a name.
It may be a primary, secondary, or stealth name server <xref target="RFC771 It may be a primary, secondary, or stealth name server <xref
9"/>.</t> target="RFC8499" format="default"/>.</t>
<t>The <tt>_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</tt> SRV record for
<t>The <spanx style="verb">_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</spanx a zone <bcp14>MAY</bcp14> reference the same target host and port as
> SRV record for a that zone's <tt>_dns&nbhy;update&nbhy;tls._tcp.&lt;zone&gt;</tt> SRV
zone MAY reference the same target host and port as that zone's record. When the same target host and port is offered for both DNS
<spanx style="verb">_dns&nbhy;update&nbhy;tls._tcp.&lt;zone&gt;</spanx> SRV Updates and DNS Push Notifications, a client <bcp14>MAY</bcp14> use a
record. When the same target host and port is offered for both DNS Updates and single DSO session to that server for both DNS Updates and DNS Push
DNS Push Notifications, a client MAY use a single DSO session to that server for Notification subscriptions. DNS Updates and DNS Push Notifications may
both DNS Updates and DNS Push Notification Subscriptions. be handled on different ports on the same target host, in which case
DNS Updates and DNS Push Notifications may be handled on different ports on they are not considered to be the "same server" for the purposes of this
the same target host, in which case they are not considered to be the "same ser specification, and communications with these two ports are handled
ver" for the purposes of this specification, and communications with these two p independently. Supporting DNS Updates and DNS Push Notifications on the
orts are handled independently. same server is <bcp14>OPTIONAL</bcp14>. A DNS Push Notification server
Supporting DNS Updates and DNS Push Notifications on the same server is OPT is not required to support DNS Update.</t>
IONAL. A DNS Push Notification server is not required to support DNS Update.</t> <t>Standard DNS Queries <bcp14>MAY</bcp14> be sent over a DNS Push
Notification (i.e., DSO) session. For any zone for which the server is
<t>Standard DNS Queries MAY be sent over a DNS Push Notification (i.e., DSO authoritative, it <bcp14>MUST</bcp14> respond authoritatively for
) queries for names falling within that zone (e.g., the
session. For any zone for which the server is authoritative, it <tt>_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</tt> SRV record) both for
MUST respond authoritatively for queries for names falling within normal DNS queries and for DNS Push Notification subscriptions. For
that zone (e.g., the <spanx style="verb">_dns&nbhy;push&nbhy;tls._tcp.&lt;zon names for which the server is acting as a recursive resolver (e.g., when
e&gt;</spanx> SRV the server is the local recursive resolver) for any query for which it
record) both for normal DNS queries and for DNS Push Notification subscriptio supports DNS Push Notification subscriptions, it <bcp14>MUST</bcp14>
ns. also support standard queries.</t>
For names for which the server is acting as a recursive <t>DNS Push Notifications impose less load on the responding server than
resolver (e.g., when the server is the local recursive resolver) for any quer rapid polling would, but Push Notifications do still have a
y cost. Therefore, DNS Push Notification clients <bcp14>MUST NOT</bcp14>
for which it supports DNS Push Notification subscriptions, it MUST also suppo recklessly create an excessive number of Push Notification
rt subscriptions. Specifically:</t>
standard queries.</t> <ol type="(%c)" >
<li>A subscription should only be active when there is a valid reason to need
<t>DNS Push Notifications impose less load on the responding server than ra live data (for example, an on-screen display is currently showing the results
pid polling would, but Push Notifications do still have a cost, so DNS Push Noti to the user), and the subscription <bcp14>SHOULD</bcp14> be canceled as soon
fication clients MUST NOT recklessly create an excessive number of Push Notifica as the need for that data ends (for example, when the user dismisses that
tion subscriptions. Specifically:</t> display). In the case of a device like a smartphone that, after some period
of inactivity, goes to sleep or otherwise darkens its screen, it should cancel
<t>(a) A subscription should only be active when there is a valid reason to its subscriptions when darkening the screen (since the user cannot see any
need live data (for example, an on-screen display is currently showing the resu changes on the display anyway) and reinstate its subscriptions when
lts to the user) and the subscription SHOULD be cancelled as soon as the need fo reawakening from display sleep.
r that data ends (for example, when the user dismisses that display). In the cas </li>
e of a device like a smartphone which, after some period of inactivity, goes to <li>A DNS Push Notification client <bcp14>SHOULD NOT</bcp14> routinely keep a
sleep or otherwise darkens its screen, it should cancel its subscriptions when d DNS Push Notification subscription active 24 hours a day, 7 days a week, just
arkening the screen (since the user cannot see any changes on the display anyway to keep a list in memory up to date so that if the user does choose to bring
) and reinstate its subscriptions when re-awakening from display sleep.</t> up an on-screen display of that data, it can be displayed really fast. DNS
Push Notifications are designed to be fast enough that there is no need to
<t>(b) A DNS Push Notification client SHOULD NOT routinely keep a DNS Push pre-load a "warm" list in memory just in case it might be needed later.
Notification subscription active 24 hours a day, 7 days a week, just to keep a l </li>
ist in memory up to date so that if the user does choose to bring up an on-scree </ol>
n display of that data, it can be displayed really fast. DNS Push Notifications
are designed to be fast enough that there is no need to pre-load a "warm" list i
n memory just in case it might be needed later.</t>
<t>Generally, as described in the <xref target="RFC8490">DNS Stateful Opera
tions specification</xref>, a client must not keep a DSO session to a server ope
n indefinitely if it has no subscriptions (or other operations) active on that s
ession. A client may close a DSO session immediately it becomes idle, and then i
f needed in the future, open a new session when required. Alternatively, a clien
t may speculatively keep an idle DSO 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 session's idle timeout (15 seconds by default) <xref target="RFC8490"/>.</t
>
<t>Note that a DSO session that has an active DNS Push Notification subscri
ption is not considered idle,
even if there is no traffic flowing for an extended period of time.
In this case the DSO inactivity timeout does not apply, because the session
is not inactive,
but the keepalive interval does still apply, to ensure generation of
sufficient messages to maintain state in middleboxes (such at NAT gateways
or firewalls)
and for the client and server to periodically verify that they still have c
onnectivity to each other.
This is described in Section 6.2 of the <xref target="RFC8490">DSO specific
ation</xref>.</t>
<?rfc needLines="14" ?>
</section>
<section title="State Considerations"> <t>Generally, as described in the DNS Stateful Operations specification
<t>Each DNS Push Notification server is capable of handling some finite <xref target="RFC8490"
format="default"></xref>, a client
must not keep a DSO session to a server open indefinitely if it has no
subscriptions (or other operations) active on that session. A client
should begin closing a DSO session immediately after it becomes idle,
and then, if needed in
the future, open a new session when required. Alternatively, a client
may speculatively keep an idle DSO 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 session's idle timeout (15 seconds by default)
<xref target="RFC8490" format="default"/>.</t>
<t>Note that a DSO session that has an active DNS Push Notification
subscription is not considered idle, even if there is no traffic flowing
for an extended period of time. In this case, the DSO inactivity
timeout does not apply, because the session is not inactive, but the
keepalive interval does still apply, to ensure the generation of
sufficient messages to maintain state in middleboxes (such at NAT
gateways or firewalls) and for the client and server to periodically
verify that they still have connectivity to each other. This is
described in <xref target="RFC8490" sectionFormat="of"
section="6.2">the DSO specification</xref>.</t>
</section>
<section numbered="true" toc="default">
<name>State Considerations</name>
<t>Each DNS Push Notification server is capable of handling some finite
number of Push Notification subscriptions. This number will vary from number of Push Notification subscriptions. This number will vary from
server to server and is based on physical machine characteristics, server to server and is based on physical machine characteristics,
network bandwidth, and operating system resource allocation. After a network capacity, and operating system resource allocation. After a
client establishes a session to a DNS server, each subscription is client establishes a session to a DNS server, each subscription is
individually accepted or rejected. Servers may employ various techniques individually accepted or rejected. Servers may employ various techniques
to limit subscriptions to a manageable level. Correspondingly, the client to limit subscriptions to a manageable level. Correspondingly, the client
is free to establish simultaneous sessions to alternate DNS servers that is free to establish simultaneous sessions to alternate DNS servers that
support DNS Push Notifications for the zone and distribute subscriptions support DNS Push Notifications for the zone and distribute subscriptions
at the client's discretion. In this way, both clients and servers can at the client's discretion. In this way, both clients and servers can
react to resource constraints.</t> react to resource constraints.</t>
<?rfc needLines="35" ?> </section>
</section> <section numbered="true" toc="default">
<name>Transport</name>
<section title="Transport"> <t>Other DNS operations like DNS Update <xref target="RFC2136"
<t>Other DNS operations like <xref target="RFC2136">DNS Update</xref> MAY u format="default"></xref> <bcp14>MAY</bcp14> use either DNS over User
se either User Datagram Protocol <xref target="RFC0768">(UDP)</xref> or Transmis Datagram
sion Control Protocol <xref target="RFC0793">(TCP)</xref> as the transport proto Protocol (UDP) <xref target="RFC0768" format="default"></xref> or
col, in keeping with the historical precedent that DNS queries must first be sen DNS over Transmission Control Protocol (TCP) <xref target="RFC0793"
t over UDP <xref target="RFC1123"/>. This requirement to use UDP has subsequentl format="default"></xref> as the transport protocol, provided they follow
y been relaxed <xref target="RFC7766"/>.</t> the historical precedent that DNS queries must first be sent using DNS
over UDP
<t>In keeping with the more recent precedent, DNS Push Notification is defi and only switch to DNS over TCP if needed <xref target="RFC1123"
ned only for TCP. format="default"/>.
DNS Push Notification clients MUST use This requirement to prefer UDP
<xref target="RFC8490">DNS Stateful Operations</xref> has subsequently been relaxed <xref target="RFC7766"
running over TLS over TCP <xref target="RFC7858"/>.</t> format="default"/>.</t>
<t>In keeping with the more recent precedent, DNS Push Notification is
<t>Connection setup over TCP ensures return reachability defined only for TCP.
and alleviates concerns of state overload at the server, DNS Push Notification clients <bcp14>MUST</bcp14> use
which is a potential problem with connectionless protocols, DNS Stateful Operations <xref target="RFC8490" format="default"></xref>
which can be more vulnerable to being exploited by attackers using spoofed running over TLS over TCP <xref target="RFC7858" format="default"/>.</t>
source addresses.
All subscribers are guaranteed to be reachable by the server by virtue of t
he TCP three-way handshake.
Flooding attacks are possible with any protocol, and a benefit of TCP is th
at there are already established industry best practices to guard against SYN fl
ooding and similar attacks <xref target="SYN"/> <xref target="RFC4953"/>.</t>
<t>Use of TCP also allows DNS Push Notifications to take advantage of curre
nt and future developments in TCP, such as
<xref target="RFC6824">Multipath TCP (MPTCP)</xref>,
<xref target="RFC7413">TCP Fast Open (TFO)</xref>,
<xref target="I-D.ietf-tcpm-rack">the TCP RACK fast loss detection algorith
m</xref>,
and so on.</t>
<t>Transport Layer Security <xref target="RFC8446">(TLS)</xref> is well und
erstood, and used by many application-layer protocols running over TCP. TLS is d
esigned to prevent eavesdropping, tampering, and message forgery. TLS is REQUIRE
D for every connection between a client subscriber and server in this protocol s
pecification. Additional security measures such as client authentication during
TLS negotiation may also be employed to increase the trust relationship between
client and server.</t>
<?rfc needLines="25" ?>
</section>
<section title="Protocol Operation"> <t>
<t>The DNS Push Notification protocol is a session-oriented protocol, and m Connection setup over TCP ensures return reachability and alleviates concerns
akes use of of state overload at the server, a potential problem with connectionless
<xref target="RFC8490">DNS Stateful Operations (DSO)</xref>.</t> protocols, which can be more vulnerable to being exploited by attackers using
spoofed source addresses.
<t>For details of the DSO message format refer to the All subscribers are guaranteed to be reachable by the server by virtue of
<xref target="RFC8490">DNS Stateful Oper-ations specification</xref>. the TCP three-way handshake. Flooding attacks are possible with any
protocol, and a benefit of TCP is that there are already established
industry best practices to guard against SYN flooding and similar attacks
<xref target="SYN" format="default"/> <xref target="RFC4953"
format="default"/>.</t>
<t>Use of TCP also allows DNS Push Notifications to take advantage of
current and future developments in TCP such as Multipath TCP (MPTCP)
<xref target="RFC8684" format="default"></xref>, TCP Fast Open (TFO)
<xref target="RFC7413" format="default"></xref>, the TCP RACK fast loss
detection algorithm <xref target="I-D.ietf-tcpm-rack"
format="default"></xref>, and so on.</t>
<t>Transport Layer Security (TLS) <xref target="RFC8446"
format="default"></xref> is well understood and is used by many
application-layer protocols running over TCP. TLS is designed to prevent
eavesdropping, tampering, and message forgery. TLS is
<bcp14>REQUIRED</bcp14> for every connection between a client subscriber
and server in this protocol specification. Additional security measures
such as client authentication during TLS negotiation may also be
employed to increase the trust relationship between client and
server.</t>
</section>
<section numbered="true" toc="default">
<name>Protocol Operation</name>
<t>The DNS Push Notification protocol is a session-oriented protocol and
makes use of
DNS Stateful Operations (DSO) <xref target="RFC8490"
format="default"></xref>.</t>
<t>For details of the DSO message format, refer to the
DNS Stateful Operations specification <xref target="RFC8490"
format="default"></xref>.
Those details are not repeated here.</t> Those details are not repeated here.</t>
<t>DNS Push Notification clients and servers <bcp14>MUST</bcp14> support
<t>DNS Push Notification clients and servers MUST support DSO. DSO.
A single server can support DNS Queries, DNS Updates, and DNS Push A single server can support DNS Queries, DNS Updates, and DNS Push
Notifications (using DSO) on the same TCP port.</t> Notifications (using DSO) on the same TCP port.</t>
<t>A DNS Push Notification exchange begins with the client discovering
<t>A DNS Push Notification exchange begins with the client discovering the the appropriate server, using the procedure described in <xref
appropriate server, target="discovery" format="default"/>, and then making a TLS/TCP
using the procedure described in <xref target="discovery"/>, and then makin connection to it.</t>
g a TLS/TCP connection to it.</t> <t>After making the TLS/TCP connection to the server,
a typical DNS Push Notification client will then immediately issue a DSO
<t>A typical DNS Push Notification client will immediately issue a DSO Keepalive operation to establish the DSO session
Keepalive operation to request a session timeout and/or keepalive interval and request a session timeout and/or keepalive interval
longer than the 15-second default values, but this is not required. longer than the 15-second default values, but this is not required.
A DNS Push Notification client MAY issue other requests on the A DNS Push Notification client <bcp14>MAY</bcp14> issue other requests on
the
session first, and only issue a DSO Keepalive session first, and only issue a DSO Keepalive
operation later if it determines that to be necessary. operation later if it determines that to be necessary.
Sending either a DSO Keepalive operation or a Push Notification Sending either a DSO Keepalive operation or a Push Notification
subscription request over the TLS/TCP connection to the server signals the subscription request over the TLS/TCP connection to the server signals
the
client's support of DSO and serves to establish a DSO session.</t> client's support of DSO and serves to establish a DSO session.</t>
<t>In accordance with the current set of active subscriptions,
<t>In accordance with the current set of active subscriptions,
the server sends relevant asynchronous Push Notifications to the server sends relevant asynchronous Push Notifications to
the client. Note that a client MUST be prepared to receive the client. Note that a client <bcp14>MUST</bcp14> be prepared to receive
(and silently ignore) Push Notifications for subscriptions it (and silently ignore) Push Notifications for subscriptions it
has previously removed, since there is no way to prevent the has previously removed, since there is no way to prevent the
situation where a Push Notification is in flight from server situation where a Push Notification is in flight from server
to client while the client's UNSUBSCRIBE message cancelling to client while the client's UNSUBSCRIBE message canceling
that subscription is simultaneously in flight from client to that subscription is simultaneously in flight from client to
server.</t> server.</t>
<section anchor="discovery" numbered="true" toc="default">
<?rfc needLines="30" ?> <name>Discovery</name>
<section title="Discovery" anchor="discovery"> <t>The first step in establishing a DNS Push Notification
<t>The first step in establishing a DNS Push Notification subscription i subscription is to discover an appropriate DNS server that
s to discover an appropriate DNS server that supports DNS Push Notifications for supports DNS Push Notifications for the desired zone.</t>
the desired zone.</t> <t>The client begins by opening a DSO session to its normal configured
DNS recursive resolver and requesting a Push Notification
<t>The client begins by opening a DSO Session to its normal configured subscription.
DNS recursive resolver and requesting a Push Notification subscription.
This connection is made to TCP port 853, the default port for This connection is made to TCP port 853, the default port for
<xref target="RFC7858">DNS-over-TLS</xref>. DNS over TLS <xref target="RFC7858" format="default"></xref>.
If the request for a Push Notification subscription is successful, If the request for a Push Notification subscription is successful,
and the recursive resolver doesn't already have an active subscription f and the recursive resolver doesn't already have an active subscription
or that name, type, and class, for that name, type, and class,
then the recursive resolver will make a corresponding then the recursive resolver will make a corresponding
Push Notification subscription on the client's behalf. Push Notification subscription on the client's behalf.
Results received are relayed to the client. Results received are relayed to the client.
This is closely analogous to how a client sends a normal DNS This is closely analogous to how a client sends a normal DNS
query to its configured DNS recursive resolver which, query to its configured DNS recursive resolver, which,
if it doesn't already have appropriate answer(s) in its cache, if it doesn't already have appropriate answer(s) in its cache,
issues an upstream query to satisfy the request.</t> issues an upstream query to satisfy the request.</t>
<t>In many contexts, the recursive resolver will be able to handle <t>In many contexts, the recursive resolver will be able to handle
Push Notifications for all names that the client may need to follow. Push Notifications for all names that the client may need to follow.
Use of VPN tunnels and Private DNS <xref target="RFC8499"/> Use of VPN tunnels and Private DNS <xref target="RFC8499"
format="default"/>
can create some additional complexity in the client software here; can create some additional complexity in the client software here;
the techniques to handle VPN tunnels and Private DNS for DNS Push the techniques to handle VPN tunnels and Private DNS for DNS Push
Notifications are the same as those already used to handle this for Notifications are the same as those already used to handle this for
normal DNS queries.</t> normal DNS queries.</t>
<t>If the recursive resolver <t>If the recursive resolver does not support DNS over TLS, or
does not support DNS over TLS, or
supports DNS over TLS but is not listening on TCP port 853, 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 p supports DNS over TLS on TCP port 853 but does not support DSO on that
ort, port, then the DSO session establishment will fail <xref
then the DSO Session session establishment will fail <xref target="RFC84 target="RFC8490" format="default"/>.</t>
90"/>.</t> <t>If the recursive resolver does support DSO on TCP port 853
but does not support Push Notification subscriptions,
<t>If the recursive resolver does support DSO but not Push Notification then when the client attempts to create a subscription,
subscriptions, then it will return the DSO error code DSOTYPENI (11).</t the server will return the DSO error code DSOTYPENI (11).</t>
>
<t>In some cases, the recursive resolver may support DSO and Push <t>In some cases, the recursive resolver may support DSO and Push
Notification subscriptions, but may not be able Notification subscriptions but may not be able
to subscribe for Push Notifications for a particular name. to subscribe for Push Notifications for a particular name.
In this case, the recursive resolver should return In this case, the recursive resolver should return
SERVFAIL to the client. This includes being unable SERVFAIL to the client. This includes being unable
to establish a connection to establish a connection
to the zone's DNS Push Notification server or establishing to the zone's DNS Push Notification server or establishing
a connection but receiving a non success response code. a connection but receiving a non-success response code.
In some cases, where the client has a pre-established trust In some cases, where the client has a pre-established trust
relationship with the owner of the zone (that is not handled relationship with the owner of the zone (that is not handled
via the usual mechanisms for VPN software) the client may via the usual mechanisms for VPN software), the client may
handle these failures by contacting the zone's DNS Push server handle these failures by contacting the zone's DNS Push Notification
server
directly.</t> directly.</t>
<t>In any of the cases described above where the client <t>In any of the cases described above where the client
fails to establish a DNS Push Notification subscription via its fails to establish a DNS Push Notification subscription via its
configured recursive resolver, the client should proceed to discover configured recursive resolver, the client should proceed to discover
the appropriate server for direct communication. The client MUST the appropriate server for direct communication. The client
also determine which TCP port on the server is listening for <bcp14>MUST</bcp14>
connections, which need not be (and often is not) the typical TCP also determine on which TCP port the server is listening for
port 53 used for conventional DNS, or TCP port 853 used for DNS connections, which need not be, and often is not,
over TLS.</t> TCP port 53 (traditionally used for conventional DNS) or
TCP port 853 (traditionally used for DNS over TLS).</t>
<t>The discovery algorithm described here is an iterative algorithm, <t>The discovery algorithm described here is an iterative algorithm,
which starts with the full name of the record to which the which starts with the full name of the record to which the
client wishes to subscribe. Successive SOA queries are then client wishes to subscribe. Successive SOA queries are then
issued, trimming one label each time, until issued, trimming one label each time, until
the closest enclosing authoritative server is discovered. the closest enclosing authoritative server is discovered.
There is also an optimization to enable the client to There is also an optimization to enable the client to
take a "short cut" directly to the SOA record of take a "short cut" directly to the SOA record of
the closest enclosing authoritative server in many cases.</t> the closest enclosing authoritative server in many cases.</t>
<ol spacing="normal" type="1">
<li>The client begins the discovery by sending a DNS query to its
local resolver, with record type SOA <xref target="RFC1035"
format="default"></xref> for the record name to which it wishes to
subscribe. As an example, suppose the client wishes to subscribe to
PTR records with the name <tt>_ipp._tcp.headoffice.example.com</tt>
(to
discover Internet Printing Protocol (IPP) printers <xref
target="RFC8010" format="default"/> <xref target="RFC8011"
format="default"/> being advertised in the head office of Example
Company). The client begins by sending an SOA query for
<tt>_ipp._tcp.headoffice.example.com</tt> to the local recursive
resolver.
The goal is to determine the server that is authoritative for the
name
<tt>_ipp._tcp.headoffice.example.com</tt>. The closest enclosing
DNS zone
containing the name <tt>_ipp._tcp.headoffice.example.com</tt> could
be
<tt>example.com</tt>, or <tt>headoffice.example.com</tt>, or
<tt>_tcp.headoffice.example.com</tt>, or even
<tt>_ipp._tcp.headoffice.example.com</tt>. The client does not know
in
advance where the closest enclosing zone cut occurs, which is why it
uses the iterative procedure described here to discover this
information.</li>
<li>
<t>If the requested SOA record exists, it will be returned in the
Answer Section with a NOERROR response code, and the client has
succeeded in discovering the information it needs.
</t>
<t>
(This language is not placing any new requirements on DNS
recursive resolvers.
This text merely describes the existing operation of the DNS
protocol
<xref target="RFC1034" format="default"/> <xref target="RFC1035"
format="default"/>.)</t>
</li>
<t> <li>
<list style="numbers"> <t>If the requested SOA record does not exist, the client will get
<t>The client begins the discovery by sending a DNS query to its loc back a NOERROR/NODATA response or an NXDOMAIN/Name Error response.
al resolver, with record type In either case, the local resolver would normally include the SOA
<xref target="RFC1035">SOA</xref> for the record name to which it wi record for the closest enclosing zone of the requested name in the
shes to subscribe. Authority Section. If the SOA record is received in the Authority
As an example, suppose the client wishes to subscribe to PTR records Section, then the client has succeeded in discovering the
with the name _ipp._tcp.headoffice.example.com information it needs.
(to discover Internet Printing Protocol (IPP) printers <xref target= </t>
"RFC8010"/> <xref target="RFC8011"/>
being advertised in the head office of Example Company.).
The client begins by sending an SOA query for _ipp._tcp.headoffice.e
xample.com to the local recursive resolver.
The goal is to determine the server authoritative for the name _ipp.
_tcp.headoffice.example.com.
The closest enclosing DNS zone containing the name _ipp._tcp.headoff
ice.example.com could be example.com,
or headoffice.example.com, or _tcp.headoffice.example.com, or even _
ipp._tcp.headoffice.example.com.
The client does not know in advance where the closest enclosing zone
cut occurs,
which is why it uses the iterative procedure described here to disco
ver this information.</t>
<t>If the requested SOA record exists, it will be returned in the An
swer section with a NOERROR response code, and
the client has succeeded in discovering the information it needs.
<vspace />
(This language is not placing any new requirements on DNS recursive
resolvers.
This text merely describes the existing operation of the DNS protoco
l
<xref target="RFC1034"/> <xref target="RFC1035"/>.)</t>
<t>If the requested SOA record does not exist, the client will get b
ack a NOERROR/NODATA response or an NXDOMAIN/Name Error response.
In either case, the local resolver would normally include the SOA re
cord for the closest enclosing zone of the requested name in the Authority Secti
on.
If the SOA record is received in the Authority Section, then
the client has succeeded in discovering the information it needs.
<vspace />
(This language is not placing any new requirements on DNS recursive
resolvers.
This text merely describes the existing operation of the DNS protoco
l
regarding negative responses <xref target="RFC2308"/>.)</t>
<t>If the client receives a response containing no SOA record,
then it proceeds with the iterative approach.
The client strips the leading label from the current query name,
and if the resulting 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,
repeating the iterative search until either an SOA is received,
or the query name consists of a single label, i.e., a Top Level Doma
in (TLD).
In the case of a single-label name (TLD), this is a network configur
ation error,
which should not happen, and the client gives up.
The client may retry the operation at a later time, of the client's
choosing,
such after a change in network attachment.</t>
<t>Once the SOA is known (either by virtue of being seen in the Answ
er Section, or in the Authority Section), the client sends a DNS query with type
<xref target="RFC2782">SRV</xref> for the record name
<spanx style="verb">_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</spanx
>, where &lt;zone&gt; is the owner name of the discovered SOA record.</t>
<t>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 exist then the zone is not correctly
configured for DNS Push Notifications as specified in this document.
)
The SRV <spanx style="verb">target</spanx> contains the name of the
server providing DNS Push Notifications for the zone. The port number on which t
o contact the server is in the SRV record <spanx style="verb">port</spanx> field
. The address(es) of the target host MAY be included in the Additional Section,
however, the address records SHOULD be authenticated before use as described bel
ow in <xref target="tls_name_auth"/> and in
<xref target="RFC7673">the specification for using DANE TLSA Records
with SRV Records</xref>, if applicable.</t>
<t anchor="SRV">More than one SRV record may be returned. In this ca
se, the <spanx style="verb">priority</spanx> and <spanx style="verb">weight</spa
nx> values in the returned SRV records are used to determine the order in which
to contact the servers for subscription requests. As described in <xref target="
RFC2782">the SRV specification</xref>, the server with the lowest <spanx style="
verb">priority</spanx> is first contacted. If more than one server has the same
<spanx style="verb">priority</spanx>, the <spanx style="verb">weight</spanx> ind
icates the weighted probability that the client should contact that server. High
er weights have higher probabilities of being selected.
If a server is not willing to accept a subscription request,
or is not reachable within a reasonable time, as determined by the c
lient,
then a subsequent server is to be contacted.</t>
</list>
</t>
<t>
(This language is not placing any new requirements on DNS
recursive resolvers.
This text merely describes the existing operation of the DNS
protocol
regarding negative responses <xref target="RFC2308"
format="default"/>.)</t>
</li>
<li>If the client receives a response containing no SOA record, then
it proceeds with the iterative approach. The client strips the
leading label from the current query name, and if the resulting name
has at least two labels in it, then the client sends an SOA query
for
that new name and processing continues at step 2 above, repeating
the iterative search until either an SOA is received or the query
name consists of a single label, i.e., a Top-Level Domain (TLD). In
the case of a single-label name (TLD), this is a network
configuration error, which should not happen, and the client gives
up. The client may retry the operation at a later time of the
client's choosing, such as after a change in network
attachment.</li>
<li>Once the SOA is known (by virtue of being seen either in the
Answer Section or in the Authority Section), the client sends a DNS
query with type SRV <xref target="RFC2782" format="default"></xref>
for the record name
<tt>_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</tt>, where
&lt;zone&gt; is the owner name of the discovered SOA record.</li>
<li>If the zone in question is set up to offer DNS Push
Notifications, then this SRV record <bcp14>MUST</bcp14> exist. (If
this SRV record does not exist, then the zone is not correctly
configured for DNS Push Notifications as specified in this
document.) The SRV <tt>target</tt> contains the name of the server
providing DNS Push Notifications for the zone. The port number on
which to contact the server is in the SRV record <tt>port</tt>
field. The address(es) of the target host <bcp14>MAY</bcp14> be
included in the Additional Section, however, the address records
<bcp14>SHOULD</bcp14> be authenticated before use as described in
<xref target="tls_name_auth" format="default"/> and in the
specification for using DNS-Based Authentication of Named Entities
(DANE) TLSA Records with SRV Records <xref
target="RFC7673" format="default"></xref>, if applicable.</li>
<li anchor="SRV">More than one SRV record may be returned. In this
case, the <tt>priority</tt> and <tt>weight</tt> values in the
returned SRV records are used to determine the order in which to
contact the servers for subscription requests. As described in the
SRV specification <xref target="RFC2782" format="default"></xref>,
the server with the lowest <tt>priority</tt> is first contacted. If
more than one server has the same <tt>priority</tt>, the
<tt>weight</tt> indicates the weighted probability that the client
should contact that server. Higher weights have higher probabilities
of being selected. If a server is not willing to accept a
subscription request, or is not reachable within a reasonable time,
as determined by the client, then a subsequent server is to be
contacted.</li>
</ol>
<t>Each time a client makes a new DNS Push Notification subscription, <t>Each time a client makes a new DNS Push Notification subscription,
it SHOULD repeat the discovery process in order to determine it <bcp14>SHOULD</bcp14> repeat the discovery process in order to
the preferred DNS server for that subscription at that time. determine the preferred DNS server for that subscription at that time.
If a client already has a DSO session with that DNS server If a client already has a DSO session with that DNS server, the client
the client SHOULD reuse that existing DSO session for the new subscripti <bcp14>SHOULD</bcp14> reuse that existing DSO session for the new
on, subscription; otherwise, a new DSO session is established. The client
otherwise, a new DSO session is established. <bcp14>MUST</bcp14> respect the DNS TTL values on records it receives
The client MUST respect the DNS TTL values on records it receives while while performing the discovery process and store them in its local
performing cache with this lifetime (as it will generally do anyway for all
the discovery process and store them in its local cache with this lifeti DNS queries it performs). This means that, as long as the DNS TTL
me values on the authoritative records are set to reasonable values,
(as it will generally be do anyway for all DNS queries it performs). repeated application of the discovery process can be completed
This means that, as long as the DNS TTL values on the authoritative reco practically
rds are set instantaneously by the client, using only locally stored cached
to reasonable values, repeated application of the discovery process can data.</t>
be completed </section>
nearly instantaneously by the client, using only locally-stored cached d
ata.</t>
<?rfc needLines="48" ?>
</section>
<section title="DNS Push Notification SUBSCRIBE" anchor="subscribe">
<t>After connecting, and requesting a longer idle timeout and/or
keepalive interval if necessary, a DNS Push Notification client<vspace />
then indicates its desire to receive DNS Push Notifications for<vspace />
a given domain name by sending a SUBSCRIBE request to the server.<vspace
/>
A SUBSCRIBE request is encoded in a DSO message <xref target="RFC8490"/>.
<vspace />
This specification defines a primary DSO TLV for DNS Push Notification SU
BSCRIBE Requests (tentatively DSO Type Code 0x40).</t>
<t>DSO messages with the SUBSCRIBE TLV as the Primary TLV are permitted i
n TLS early data,
provided that the precautions described in <xref target="early_data"/> ar
e followed.</t>
<t>The entity that initiates a SUBSCRIBE request is by definition the cli
ent.
A server MUST NOT send a SUBSCRIBE request over an existing 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 the client MUST forcibly abort the connection i
mmediately.</t>
<t>Each SUBSCRIBE request generates exactly one SUBSCRIBE response from t
he server.
The entity that initiates a SUBSCRIBE response is by definition the serve
r.
A client MUST NOT send a SUBSCRIBE response.
If a client does send a SUBSCRIBE response,
this is a fatal error and the server MUST forcibly abort the connection i
mmediately.</t>
<section title="SUBSCRIBE Request">
<t>A SUBSCRIBE request begins with the standard
<xref target="RFC8490">DSO 12-byte header</xref>, followed by the SUBSC
RIBE primary TLV.
A SUBSCRIBE request is illustrated in <xref target="subscribe_req"/>.</
t>
<t>The MESSAGE ID field MUST be set to a unique value, that the client
is not using for any other active operation on this DSO session. For the purpose
s here, a MESSAGE ID is in use on this session if the client has used it in a re
quest for which it has not yet received a response, or if the client has used it
for a subscription which it has not yet cancelled using UNSUBSCRIBE. In the SUB
SCRIBE response the server MUST echo back the MESSAGE ID value unchanged.</t>
<t>The other header fields MUST be set as described in the
<xref target="RFC8490">DSO spec-ification</xref>.
The DNS OPCODE field contains the OPCODE value for DNS Stateful Operati
ons (6).
The four count fields must be zero, and the corresponding four sections
must be empty (i.e., absent).</t>
<t>The DSO-TYPE is SUBSCRIBE (tentatively 0x40).</t>
<t>The DSO-LENGTH is the length of the DSO-DATA that follows, which spe <section anchor="subscribe" numbered="true" toc="default">
cifies <name>DNS Push Notification SUBSCRIBE</name>
<t>After connecting, and requesting a longer idle timeout and/or
keepalive interval if necessary, a DNS Push Notification client then
indicates its desire to receive DNS Push Notifications for a given
domain name by sending a SUBSCRIBE request to the server. A SUBSCRIBE
request is encoded in a DSO message <xref target="RFC8490"
format="default"/>. This specification defines a
DSO Primary TLV for DNS Push Notification SUBSCRIBE Requests
(DSO Type Code 0x0040).</t>
<t>DSO messages with the SUBSCRIBE TLV as the Primary TLV are
permitted in TLS early data, provided that the precautions described
in
<xref target="early_data" format="default"/> are followed.</t>
<t>The entity that initiates a SUBSCRIBE request is by definition the
client. A server <bcp14>MUST NOT</bcp14> send a SUBSCRIBE request
over an existing 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 the client <bcp14>MUST</bcp14> forcibly abort the
connection immediately.</t>
<t>Each SUBSCRIBE request generates exactly one SUBSCRIBE response
from the server. The entity that initiates a SUBSCRIBE response is by
definition the server. A client <bcp14>MUST NOT</bcp14> send a
SUBSCRIBE response. If a client does send a SUBSCRIBE response, this
is a fatal error and the server <bcp14>MUST</bcp14> forcibly abort the
connection immediately.</t>
<section numbered="true" toc="default">
<name>SUBSCRIBE Request</name>
<t>A SUBSCRIBE request begins with the standard DSO 12-byte header
<xref target="RFC8490" format="default"></xref>, followed by the
SUBSCRIBE Primary TLV. A SUBSCRIBE request is illustrated in <xref
target="subscribe_req" format="default"/>.</t>
<t>The MESSAGE ID field <bcp14>MUST</bcp14> be set to a unique
value that the client is not using for any other active operation
on this DSO session. For the purposes here, a MESSAGE ID is in use
on this session if either the client has used it in a request for
which it
has not yet received a response, or if the client has used it for a
subscription that it has not yet canceled using UNSUBSCRIBE. In
the SUBSCRIBE response, the server <bcp14>MUST</bcp14> echo back the
MESSAGE ID value unchanged.</t>
<t>The other header fields <bcp14>MUST</bcp14> be set as described
in the
<xref target="RFC8490" format="default">DSO specification</xref>.
The DNS OPCODE field contains the OPCODE value for DNS Stateful
Operations (6).
The four count fields must be zero, and the corresponding four
sections must be empty (i.e., absent).</t>
<t>The DSO-TYPE is SUBSCRIBE (0x0040).</t>
<t>The DSO-LENGTH is the length of the DSO-DATA that follows, which
specifies
the name, type, and class of the record(s) being sought.</t> the name, type, and class of the record(s) being sought.</t>
<figure anchor="subscribe_req">
<figure align="left" anchor="subscribe_req" title="SUBSCRIBE Request">< <name>SUBSCRIBE Request</name>
artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
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) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
| DSO-TYPE = SUBSCRIBE (tentatively 0x40) | | DSO-TYPE = SUBSCRIBE (0x0040) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSO-LENGTH (number of octets in DSO-DATA) | | DSO-LENGTH (number of octets in DSO-DATA) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
\ NAME \ \ \ NAME \ \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TYPE | > DSO-DATA | TYPE | > DSO-DATA
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| CLASS | / | CLASS | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /]]></artwork></figure> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /]]></artwork>
</figure>
<t>The DSO-DATA for a SUBSCRIBE request MUST contain exactly one NAME, <t>The DSO-DATA for a SUBSCRIBE request <bcp14>MUST</bcp14> contain
TYPE, and CLASS. exactly one NAME, TYPE, and CLASS.
Since SUBSCRIBE requests are sent over TCP, multiple SUBSCRIBE DSO requ Since SUBSCRIBE requests are sent over TCP, multiple SUBSCRIBE DSO
est messages request messages
can be concatenated in a single TCP stream and packed efficiently into can be concatenated in a single TCP stream and packed efficiently
TCP segments.</t> into TCP segments.</t>
<t>If accepted, the subscription will stay in effect until the
<t>If accepted, the subscription will stay in effect until the client c client cancels the subscription using UNSUBSCRIBE or until the DSO
ancels the subscription using UNSUBSCRIBE or until the DSO session between the c session between the client and the server is closed.</t>
lient and the server is closed.</t> <t>SUBSCRIBE requests on a given session <bcp14>MUST</bcp14> be
unique. A client <bcp14>MUST NOT</bcp14> send a SUBSCRIBE message
<t>SUBSCRIBE requests on a given session MUST be unique. that duplicates the name, type and class of an existing active
A client MUST NOT send a SUBSCRIBE message that duplicates the subscription on that DSO session. For the purpose of this matching,
NAME, TYPE and CLASS of an existing active subscription on that DSO ses the established DNS case insensitivity for US-ASCII letters <xref
sion. target="RFC0020" format="default"/> applies (e.g., "example.com" and
For the purpose of this matching, the established DNS case-insensitivit "Example.com" are the same). If a server receives such a duplicate
y SUBSCRIBE message, this is a fatal error and the server
for US-ASCII letters <xref target="RFC0020" /> applies (e.g., "example. <bcp14>MUST</bcp14> forcibly abort the connection immediately.</t>
com" and "Example.com" are the same). <t>DNS wildcarding is not supported.
If a server receives such a duplicate SUBSCRIBE message, That is, an asterisk character ("*") in a SUBSCRIBE message matches
this is a fatal error and the server MUST forcibly abort the connection only a literal asterisk character ("*") in a name and nothing else.
immediately.</t> Similarly, a CNAME in a SUBSCRIBE message matches only a CNAME
record
<t>DNS wildcarding is not supported. That is, a wildcard ("*") in a SUB with that name in the zone and no other records with that name.</t>
SCRIBE message matches only a literal wildcard character ("*") in the zone, and <t>A client may SUBSCRIBE to records that are unknown to the server
nothing else.</t> at 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
<t>Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message m error. The server <bcp14>MUST NOT</bcp14> return NXDOMAIN in this
atches only a literal CNAME record in the zone, and no other records with the sa case. The server <bcp14>MUST</bcp14> accept these requests and send
me owner name.</t> Push Notifications if and when matching records are found in the
future.</t>
<t>A client may SUBSCRIBE to records that are unknown to the server at <t>If neither TYPE nor CLASS are ANY (255), then this is a specific
the time of the request (providing that the name falls within one of the zone(s) subscription to changes for the given name, type, and class. If one
the server is responsible for) and this is not an error. The server MUST NOT re or both of TYPE or CLASS are ANY (255), then this subscription
turn NXDOMAIN in this case. The server MUST accept these requests and send Push matches all types and/or all classes as appropriate.</t>
Notifications if and when matching records are found in the future.</t> <t>NOTE: A little-known quirk of DNS is that in DNS QUERY requests,
QTYPE and QCLASS 255 mean "ANY", not "ALL". They indicate that the
<t>If neither TYPE nor CLASS are ANY (255) then this is a specific subs server should respond with ANY matching records of its choosing, not
cription to changes for the given NAME, TYPE and CLASS. If one or both of TYPE o necessarily ALL matching records. This can lead to some surprising
r CLASS are ANY (255) then this subscription matches any type and/or any class, and unexpected results, where a query returns some valid answers,
as appropriate.</t> but
not all of them, and makes QTYPE = 255 (ANY) queries less useful
<?rfc needLines="14" ?> than people sometimes imagine.</t>
<t>NOTE: A little-known quirk of DNS is that in DNS QUERY requests, QTY <t>When used in conjunction with SUBSCRIBE, TYPE 255 and CLASS 255
PE and QCLASS 255 mean "ANY" not "ALL". They indicate that the server should res should be interpreted to mean "ALL", not "ANY". After accepting a
pond with ANY matching records of its choosing, not necessarily ALL matching rec subscription where one or both of TYPE or CLASS are 255, the server
ords. This can lead to some surprising and unexpected results, where a query ret <bcp14>MUST</bcp14> send Push Notification Updates for ALL record
urns some valid answers but not all of them, and makes QTYPE = 255 (ANY) queries changes that match the subscription, not just some of them.</t>
less useful than people sometimes imagine.</t> </section>
<t>When used in conjunction with SUBSCRIBE, TYPE and CLASS 255 should b
e interpreted to mean "ALL", not "ANY". After accepting a subscription where one
or both of TYPE or CLASS are 255, the server MUST send Push Notification Update
s for ALL record changes that match the subscription, not just some of them.</t>
<?rfc needLines="48" ?>
</section>
<section title="SUBSCRIBE Response" anchor="subresp">
<t>A SUBSCRIBE response begins with the standard <section anchor="subresp" numbered="true" toc="default">
<xref target="RFC8490">DSO 12-byte header</xref>. <name>SUBSCRIBE Response</name>
<t>A SUBSCRIBE response begins with the standard
DSO 12-byte header <xref target="RFC8490" format="default"></xref>.
The QR bit in the header is set indicating it is a response. The QR bit in the header is set indicating it is a response.
The header MAY be followed by one or more optional TLVs, such as a Retr The header <bcp14>MAY</bcp14> be followed by one or more
y Delay TLV. optional Additional TLVs such as a Retry Delay Additional TLV.
A SUBSCRIBE response is illustrated in <xref target="subscribe_resp"/>. A SUBSCRIBE response is illustrated in <xref target="subscribe_resp"
</t> format="default"/>.</t>
<t>The MESSAGE ID field <bcp14>MUST</bcp14> echo the value given in
<t>The MESSAGE ID field MUST echo the value given in the MESSAGE ID fie the MESSAGE ID field of the SUBSCRIBE request. This is how the
ld of the SUBSCRIBE request. client knows which request is being responded to.</t>
This is how the client knows which request is being responded to.</t> <t>The other header fields <bcp14>MUST</bcp14> be set as described
in the <xref target="RFC8490"
<t>The other header fields MUST be set as described in the format="default">DSO specification</xref>. The DNS OPCODE field
<xref target="RFC8490">DSO spec-ification</xref>. contains the OPCODE
The DNS OPCODE field contains the OPCODE value for DNS Stateful Operati value for DNS Stateful Operations (6). The four count fields must
ons (6). be zero, and the corresponding four sections must be empty (i.e.,
The four count fields must be zero, and the corresponding four sections absent).</t>
must be empty (i.e., absent).</t> <t>A SUBSCRIBE response message <bcp14>MUST NOT</bcp14> include a
SUBSCRIBE TLV.
<t>A SUBSCRIBE response message MUST NOT include a SUBSCRIBE TLV. If a client receives a SUBSCRIBE response message containing a
If a client receives a SUBSCRIBE response message containing a SUBSCRIB SUBSCRIBE TLV,
E TLV then the response message is processed but the SUBSCRIBE TLV
then the response message is processed but the SUBSCRIBE TLV MUST be si <bcp14>MUST</bcp14> be silently ignored.</t>
lently ignored.</t> <figure anchor="subscribe_resp">
<name>SUBSCRIBE Response</name>
<figure align="left" anchor="subscribe_resp" title="SUBSCRIBE Response" <artwork align="left" name="" type="" alt=""><![CDATA[
><artwork align="left"><![CDATA[
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) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
]]>
</artwork></figure>
<?rfc needLines="20" ?>
<t>In the SUBSCRIBE response the RCODE indicates whether or not the sub
scription was accepted. Supported RCODEs are as follows:</t>
<texttable title="SUBSCRIBE Response codes" anchor="subscribe_rcodes">
<ttcol align="left">Mnemonic</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="left">Description</ttcol>
<c>NOERROR</c><c>0</c><c>SUBSCRIBE successful.</c>
<c>FORMERR</c><c>1</c><c>Server failed to process request due to a malf
ormed request.</c>
<c>SERVFAIL</c><c>2</c><c>Server failed to process request due to a pro
blem with the server.</c>
<c>NOTIMP</c><c>4</c><c>Server does not implement DSO.</c>
<c>REFUSED</c><c>5</c><c>Server refuses to process request for policy o
r security reasons.</c>
<c>NOTAUTH</c><c>9</c><c>Server is not authoritative for the requested
name.</c>
<c>DSOTYPENI</c><c>11</c><c>SUBSCRIBE operation not supported.</c>
</texttable>
<t>This document specifies only these RCODE values for SUBSCRIBE Respon ]]></artwork>
ses. Servers sending SUBSCRIBE Responses SHOULD use one of these values. Note th </figure>
at NXDOMAIN is not a valid RCODE in response to a SUBSCRIBE Request. However, fu <t>In the SUBSCRIBE response, the RCODE indicates whether or not the
ture circumstances may create situations where other RCODE values are appropriat subscription was accepted. Supported RCODEs are as follows:</t>
e in SUBSCRIBE Responses, so clients MUST be prepared to accept SUBSCRIBE Respon <table anchor="subscribe_rcodes" align="center">
ses with any other RCODE value.</t> <name>SUBSCRIBE Response Codes</name>
<thead>
<t>If the server sends a nonzero RCODE in the SUBSCRIBE response, that <tr>
means: <th align="left">Mnemonic</th>
<?rfc subcompact="yes" ?> <th align="center">Value</th>
<list style="letters"> <th align="left">Description</th>
<t>the client is (at least partially) misconfigured, or</t> </tr>
<t>the server resources are exhausted, or</t> </thead>
<t>there is some other unknown failure on the server.</t> <tbody>
</list> <tr>
<?rfc subcompact="no" ?> <td align="left">NOERROR</td>
In any case, the client shouldn't retry the subscription to this server <td align="center">0</td>
right away. If multiple SRV records were returned as described in <xref target= <td align="left">SUBSCRIBE successful.</td>
"discovery"/>, <xref target="SRV"/>, a subsequent server MAY be tried immediatel </tr>
y.</t> <tr>
<t>If the client has other successful subscriptions to this server, the <td align="left">FORMERR</td>
se subscriptions remain even though additional subscriptions may be refused. Nei <td align="center">1</td>
ther the client nor the server are required to close the connection, although, e <td align="left">Server failed to process request due to a
ither end may choose to do so.</t> malformed request.</td>
<t>If the server sends a nonzero RCODE then it SHOULD append a Retry De </tr>
lay TLV <xref target="RFC8490"/> to the response specifying a delay before the c <tr>
lient attempts this operation again. Recommended values for the delay for differ <td align="left">SERVFAIL</td>
ent RCODE values are given below. These recommended values apply both to the def <td align="center">2</td>
ault values a server should place in the Retry Delay TLV, and the default values <td align="left">Server failed to process request due to a
a client should assume if the server provides no Retry Delay TLV. problem with the server.</td>
<list style="bullets"> </tr>
<t>For RCODE = 1 (FORMERR) the delay may be any value selected by t <tr>
he implementer. A value of five minutes is RECOMMENDED, to reduce the risk of hi <td align="left">NOTIMP</td>
gh load from defective clients.</t> <td align="center">4</td>
<td align="left">Server does not implement DSO.</td>
<t>For RCODE = 2 (SERVFAIL) the delay should be chosen according to </tr>
the level of server overload and the anticipated duration of that overload. By <tr>
default, a value of one minute is RECOMMENDED. If a more serious server failure <td align="left">REFUSED</td>
occurs, the delay may be longer in accordance with the specific problem encounte <td align="center">5</td>
red.</t> <td align="left">Server refuses to process request for policy
or security reasons.</td>
<t>For RCODE = 4 (NOTIMP), which occurs on a server that doesn't im </tr>
plement <tr>
<xref target="RFC8490">DNS Stateful Operations</xref>, <td align="left">NOTAUTH</td>
<td align="center">9</td>
<td align="left">Server is not authoritative for the requested
name.</td>
</tr>
<tr>
<td align="left">DSOTYPENI</td>
<td align="center">11</td>
<td align="left">SUBSCRIBE operation not supported.</td>
</tr>
</tbody>
</table>
<t>This document specifies only these RCODE values for SUBSCRIBE
Responses. Servers sending SUBSCRIBE Responses <bcp14>SHOULD</bcp14>
use one of these values. Note that NXDOMAIN is not a valid RCODE in
response to a SUBSCRIBE Request. However, future circumstances may
create situations where other RCODE values are appropriate in
SUBSCRIBE Responses, so clients <bcp14>MUST</bcp14> be prepared to
accept and handle SUBSCRIBE Responses with any other nonzero RCODE
error values.</t>
<t>If the server sends a nonzero RCODE in the SUBSCRIBE response,
that means:
</t>
<ol spacing="compact" type="a">
<li>the client is (at least partially) misconfigured, or</li>
<li>the server resources are exhausted, or</li>
<li>there is some other unknown failure on the server.</li>
</ol>
<t>
In any case, the client shouldn't retry the subscription to this
server right away. If multiple SRV records were returned as
described in <xref
target="SRV" format="default"/>, a subsequent server
<bcp14>MAY</bcp14> be tried immediately.</t>
<t>If the client has other successful subscriptions to this server,
these subscriptions remain even though additional subscriptions may
be refused. Neither the client nor the server is required to close
the connection, although either end may choose to do so.</t>
<t>If the server sends a nonzero RCODE, then it
<bcp14>SHOULD</bcp14>
append a Retry Delay Additional TLV <xref target="RFC8490"
format="default"/>
to the response specifying a delay before the client attempts this
operation again. Recommended values for the delay for different
RCODE values are given below. These recommended values apply both to
the default values a server should place in the Retry Delay
Additional TLV and
the default values a client should assume if the server provides no
Retry Delay Additional TLV.
</t>
<ul spacing="normal" empty="true">
<li>For RCODE = 1 (FORMERR), the delay may be any value selected
by
the implementer. A value of five minutes is
<bcp14>RECOMMENDED</bcp14> to reduce the risk of high load from
defective clients.</li>
<li>For RCODE = 2 (SERVFAIL), the delay should be chosen according
to the level of server overload and the anticipated duration of
that overload. By default, a value of one minute is
<bcp14>RECOMMENDED</bcp14>. If a more serious server failure
occurs, the delay may be longer in accordance with the specific
problem encountered.</li>
<li>For RCODE = 4 (NOTIMP), which occurs on a server that doesn't
implement
DNS Stateful Operations <xref target="RFC8490"
format="default"></xref>,
it is unlikely that the server will begin supporting DSO it is unlikely that the server will begin supporting DSO
in the next few minutes, so the retry delay SHOULD be one hour. in the next few minutes, so the retry delay <bcp14>SHOULD</bcp14>
be one hour.
Note that in such a case, a server that doesn't implement DSO Note that in such a case, a server that doesn't implement DSO
is unlikely to place a Retry Delay TLV in its response, so this is unlikely to place a Retry Delay Additional TLV in its
recommended value in particular applies to what a client should ass response, so this
ume by default.</t> recommended value in particular applies to what a client should
assume by default.</li>
<t>For RCODE = 5 (REFUSED), which occurs on a server that implement <li>For RCODE = 5 (REFUSED), which occurs on a server that
s DNS Push Notifications, but is currently configured to disallow DNS Push Notif implements DNS Push Notifications but is currently configured to
ications, the retry delay may be any value selected by the implementer and/or co disallow DNS Push Notifications, the retry delay may be any value
nfigured by the operator.</t> selected by the implementer and/or configured by the
<t>If the server being queried is listed in a operator.</li>
<spanx style="verb">_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</span <li>If the server being queried is listed in a
x> <tt>_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</tt>
SRV record for the zone, then this is a misconfiguration, SRV record for the zone, then this is a misconfiguration,
since this server is being advertised as supporting DNS Push Notifi since this server is being advertised as supporting DNS Push
cations for this zone, Notifications for this zone,
but the server itself is not currently configured to perform that t but the server itself is not currently configured to perform that
ask. task.
Since it is possible that the misconfiguration may be repaired Since it is possible that the misconfiguration may be repaired
at any time, the retry delay should not be set too high. By defaul at any time, the retry delay should not be set too high. By
t, default,
a value of 5 minutes is RECOMMENDED.</t> a value of 5 minutes is <bcp14>RECOMMENDED</bcp14>.</li>
<li>For RCODE = 9 (NOTAUTH), which occurs on a server that
<t>For RCODE = 9 (NOTAUTH), which occurs on a server that implement implements DNS Push Notifications but is not configured to be
s DNS Push Notifications, but is not configured to be authoritative for the requ authoritative for the requested name, the retry delay may be any
ested name, the retry delay may be any value selected by the implementer and/or value selected by the implementer and/or configured by the
configured by the operator.</t> operator.</li>
<t>If the server being queried is listed in a <li>If the server being queried is listed in a
<spanx style="verb">_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</span <tt>_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</tt>
x>
SRV record for the zone, then this is a misconfiguration, SRV record for the zone, then this is a misconfiguration,
since this server is being advertised as supporting DNS Push Notifi since this server is being advertised as supporting DNS Push
cations for this zone, Notifications for this zone,
but the server itself is not currently configured to perform that t but the server itself is not currently configured to perform that
ask. task.
Since it is possible that the misconfiguration may be repaired Since it is possible that the misconfiguration may be repaired
at any time, the retry delay should not be set too high. By defaul at any time, the retry delay should not be set too high. By
t, default,
a value of 5 minutes is RECOMMENDED.</t> a value of 5 minutes is <bcp14>RECOMMENDED</bcp14>.</li>
<li>For RCODE = 11 (DSOTYPENI),
<t>For RCODE = 11 (DSOTYPENI), which occurs on a server that implements DSO but doesn't
which occurs on a server that implements DSO but doesn't implement implement DNS Push Notifications,
DNS Push Notifications, it is unlikely that the server will begin supporting DNS Push
it is unlikely that the server will begin supporting DNS Push Notif Notifications
ications in the next few minutes, so the retry delay <bcp14>SHOULD</bcp14>
in the next few minutes, so the retry delay SHOULD be one hour.</t> be one hour.</li>
<li>For other RCODE values, the retry delay should be
<t>For other RCODE values, the retry delay should be set by the ser set by the server as appropriate for that error condition.
ver as appropriate for that error condition. By default, a value of 5 minutes is By default, a value of 5 minutes is
RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</li>
</list> </ul>
</t> <t>For RCODE = 9 (NOTAUTH), the time delay applies to requests for
<t>For RCODE = 9 (NOTAUTH), the time delay applies to requests for othe other names falling within the same zone. Requests for names falling
r names falling within the same zone. Requests for names falling within other zo within other zones are not subject to the delay. For all other
nes are not subject to the delay. For all other RCODEs the time delay applies to RCODEs, the time delay applies to all subsequent requests to this
all subsequent requests to this server.</t> server.</t>
<t>After sending an error response, the server <bcp14>MAY</bcp14>
<t>After sending an error response the server MAY allow the session to allow the session to remain open, or <bcp14>MAY</bcp14> follow it
remain open, with
or MAY send a DNS Push Notification Retry Delay Operation TLV instructi a DSO Retry Delay operation (using the Retry Delay Primary TLV)
ng the client to close the session, instructing the client to close the session as described in the
as described in the <xref target="RFC8490">DSO specification</xref>. <xref target="RFC8490" format="default">DSO specification</xref>.
Clients MUST correctly handle both cases.</t> Clients <bcp14>MUST</bcp14> correctly handle both cases.
Note that the
<?rfc needLines="48" ?> DSO Retry Delay operation (using the Retry Delay Primary TLV)
</section> is different to the Retry Delay Additional TLV mentioned above.
</section> </t>
</section>
<section title="DNS Push Notification Updates" anchor="push"> </section>
<t>Once a subscription has been successfully established, the server gene <section anchor="push" numbered="true" toc="default">
rates PUSH messages to send to the client as appropriate. In the case that the a <name>DNS Push Notification Updates</name>
nswer set was already non-empty at the moment the subscription was established, <t>Once a subscription has been successfully established,
an initial PUSH message will be sent immediately following the SUBSCRIBE Respons the server generates PUSH messages to send to the client as
e. Subsequent changes to the answer set are then communicated to the client in s appropriate.
ubsequent PUSH messages.</t> In the case that the answer set was already non-empty at the moment
the subscription was established, an initial PUSH message will be sent
<t>A client MUST NOT send a PUSH message. immediately following the SUBSCRIBE Response. Subsequent changes to
the
answer set are then communicated to the client in subsequent PUSH
messages.</t>
<t>A client <bcp14>MUST NOT</bcp14> send a PUSH message.
If a client does 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 res or a PUSH message is sent with the QR bit set indicating that it is a
ponse, response,
this is a fatal error and the receiver MUST forcibly abort the connection this is a fatal error and the receiver <bcp14>MUST</bcp14> forcibly
immediately.</t> abort the connection immediately.</t>
<section numbered="true" toc="default">
<section title="PUSH Message"> <name>PUSH Message</name>
<t>A PUSH unidirectional message begins with the standard
<t>A PUSH unidirectional message begins with the standard DSO 12-byte header <xref target="RFC8490" format="default"></xref>,
<xref target="RFC8490">DSO 12-byte header</xref>, followed by the PUSH followed by the PUSH Primary TLV.
primary TLV. A PUSH message is illustrated in <xref target="push_msg"
A PUSH message is illustrated in <xref target="push_msg"/>.</t> format="default"/>.</t>
<t>In accordance with the definition of DSO unidirectional messages,
<t>In accordance with the definition of DSO unidirectional messages, the MESSAGE ID field <bcp14>MUST</bcp14> be zero.
the MESSAGE ID field MUST be zero.
There is no client response to a PUSH message.</t> There is no client response to a PUSH message.</t>
<t>The other header fields <bcp14>MUST</bcp14> be set as described
<t>The other header fields MUST be set as described in the in the
<xref target="RFC8490">DSO spec-ification</xref>. DSO specification <xref target="RFC8490" format="default"></xref>.
The DNS OPCODE field contains the OPCODE value for DNS Stateful Operati The DNS OPCODE field contains the OPCODE value for DNS Stateful
ons (6). Operations (6).
The four count fields must be zero, and the corresponding four sections The four count fields must be zero, and the corresponding four
must be empty (i.e., absent).</t> sections must be empty (i.e., absent).</t>
<t>The DSO-TYPE is PUSH (0x0041).</t>
<t>The DSO-TYPE is PUSH (tentatively 0x41).</t> <t>The DSO-LENGTH is the length of the DSO-DATA that follows, which
specifies
<t>The DSO-LENGTH is the length of the DSO-DATA that follows, which spe
cifies
the changes being communicated.</t> the changes being communicated.</t>
<t>The DSO-DATA contains one or more change notifications.
<t>The DSO-DATA contains one or more change notifications. A PUSH Message <bcp14>MUST</bcp14> contain at least one change
A PUSH Message MUST contain at least one change notification. notification.
If a PUSH Message is received that contains no change notifications, If a PUSH Message is received that contains no change notifications,
this is a fatal error, and the client MUST forcibly abort the connectio this is a fatal error and the client <bcp14>MUST</bcp14> forcibly
n immediately.</t> abort the connection immediately.</t>
<t>The change notification records are formatted similarly to how
<t>The change notification records are formatted similarly to how
DNS Resource Records are conventionally expressed in DNS messages, DNS Resource Records are conventionally expressed in DNS messages,
as illustrated in <xref target="push_msg"/>, as illustrated in <xref target="push_msg" format="default"/>,
and are interpreted as described below.</t> and are interpreted as described below.</t>
<t>The TTL field holds an unsigned 32-bit integer <xref
target="RFC2181" format="default"/>.
If the TTL is in the range 0 to 2,147,483,647 seconds (0 to
2<sup>31</sup> - 1, or 0x7FFFFFFF),
then a new DNS Resource Record with the given name, type, class, and
RDATA is added.
Type and class <bcp14>MUST NOT</bcp14> be 255 (ANY). If either type
or class are 255 (ANY),
this is a fatal error and the client <bcp14>MUST</bcp14> forcibly
abort the connection immediately.
A TTL of 0 means that this record should be retained for as long as
the subscription is active
and should be discarded immediately the moment the subscription is
canceled.</t>
<t>If the TTL has the value 0xFFFFFFFF, then the DNS Resource Record
with the given name, type, class, and RDATA is removed. Type and
class <bcp14>MUST NOT</bcp14> be 255 (ANY). If either type or class
are 255 (ANY), this is a fatal error and the client
<bcp14>MUST</bcp14> forcibly abort the connection immediately.</t>
<t>If the TTL has the value 0xFFFFFFFE, then this is a 'collective'
remove notification. For collective remove notifications, RDLEN
<bcp14>MUST</bcp14> be zero, and consequently, the RDATA
<bcp14>MUST</bcp14> be empty. If a change notification is received
where TTL = 0xFFFFFFFE and RDLEN is not zero, this is a fatal error
and the client <bcp14>MUST</bcp14> forcibly abort the connection
immediately.</t>
<?rfc needLines="6" ?> <t>There are three types of collective remove notification.
<t>The TTL field holds an unsigned 32-bit integer <xref target="RFC2181 For collective remove notifications:</t>
"/>.
If the TTL is in the range 0 to 2,147,483,647 seconds (0 to 2^31 - 1, o
r 0x7FFFFFFF),
then a new DNS Resource Record with the given name, type, class and RDA
TA is added.
Type and class MUST NOT be 255 (ANY). If either type or class are 255 (
ANY)
this is a fatal error, and the client MUST forcibly abort the connectio
n immediately.
A TTL of 0 means that this record should be retained for as long as the
subscription is active,
and should be discarded immediately the moment the subscription is canc
elled.</t>
<t>If the TTL has the value 0xFFFFFFFF, then the
DNS Resource Record with the given name, type, class and RDATA is remov
ed.
Type and class MUST NOT be 255 (ANY). If either type or class are 255 (
ANY)
this is a fatal error, and the client MUST forcibly abort the connectio
n immediately.</t>
<t>If the TTL has the value 0xFFFFFFFE, then this is a 'collective' rem
ove notification.
For collective remove notifications RDLEN MUST be zero and consequently
the RDATA MUST be empty.
If a change notification is received where TTL = 0xFFFFFFFE and RDLEN i
s not zero,
this is a fatal error, and the client MUST forcibly abort the connectio
n immediately.</t>
<t>There are three types of collective remove notification:</t>
<t>For collective remove notifications,
if CLASS is not 255 (ANY) and TYPE is not 255 (ANY)
then for the given name this removes all records of the specified type
in the specified class.</t>
<t>For collective remove notifications,
if CLASS is not 255 (ANY) and TYPE is 255 (ANY)
then for the given name this removes all records of all types in the sp
ecified class.</t>
<t>For collective remove notifications,
if CLASS is 255 (ANY),
then for the given name this removes all records of all types in all cl
asses.
In this case TYPE MUST be set to zero on transmission, and MUST be sile
ntly ignored on reception.</t>
<?rfc needLines="19" ?>
<t>Summary of change notification types:
<list style="bullets">
<t>Remove all RRsets from a name, in all classes<vspace />
TTL = 0xFFFFFFFE, RDLEN = 0, CLASS = 255 (ANY)</t>
<t>Remove all RRsets from a name, in given class:<vspace /> <ul>
TTL = 0xFFFFFFFE, RDLEN = 0, CLASS gives class, TYPE = 255 (ANY)</t
>
<t>Remove specified RRset from a name, in given class:<vspace /> <li>If CLASS is not 255 (ANY) and TYPE is not 255 (ANY), then for the given
TTL = 0xFFFFFFFE, RDLEN = 0<vspace /> name, this removes all records of the specified type in the specified class.
CLASS and TYPE specify the RRset being removed</t> </li>
<t>Remove an individual RR from a name:<vspace /> <li>If CLASS is not 255 (ANY) and TYPE is 255 (ANY), then for the given name,
TTL = 0xFFFFFFFF<vspace /> this removes all records of all types in the specified class.
CLASS, TYPE, RDLEN and RDATA specify the RR being removed</t> </li>
<t>Add individual RR to a name<vspace /> <li>If CLASS is 255 (ANY), then for the given name, this removes all records
TTL &gt;= 0 and TTL &lt;= 0x7FFFFFFF<vspace /> of all types in all classes. In this case, TYPE <bcp14>MUST</bcp14> be set to
CLASS, TYPE, RDLEN, RDATA and TTL specify the RR being added</t> zero on
</list> transmission and <bcp14>MUST</bcp14> be silently ignored on reception.
</t> </li>
<t>Note that it is valid for the RDATA of an added or removed DNS Resou </ul>
rce Record to be empty (zero length).
For example, an <xref target="RFC3123">Address Prefix List Resource Rec
ord</xref> may have empty RDATA.
Therefore, a change notification with RDLEN = 0 does not automatically
indicate a remove notification.
If RDLEN = 0 and TTL is the in the range 0 - 0x7FFFFFFF, this change no
tification signals the addition of a
record with the given name, type, class, and empty RDATA.
If RDLEN = 0 and TTL = 0xFFFFFFFF, this change notification signals the
removal specifically of that single
record with the given name, type, class, and empty RDATA.</t>
<t>If the TTL is any value other than 0xFFFFFFFF, 0xFFFFFFFE, or a valu <t>Summary of change notification types:
e in the range 0 - 0x7FFFFFFF, </t>
then the receiver SHOULD silently ignore this particular change notific <ul spacing="normal">
ation record. <li>
The connection is not terminated and other valid change notification re <t>Remove all RRsets from a name in all classes:<br/>
cords TTL = 0xFFFFFFFE, RDLEN = 0, CLASS = 255 (ANY).</t>
</li>
<li>
<t>Remove all RRsets from a name in given class:<br/>
TTL = 0xFFFFFFFE, RDLEN = 0, CLASS gives class, TYPE = 255
(ANY).</t>
</li>
<li>
<t>Remove specified RRset from a name in given class:<br/>
TTL = 0xFFFFFFFE, RDLEN = 0,<br/>
CLASS and TYPE specify the RRset being removed.</t>
</li>
<li>
<t>Remove an individual RR from a name:<br/>
TTL = 0xFFFFFFFF,<br/>
CLASS, TYPE, RDLEN, and RDATA specify the RR being removed.</t>
</li>
<li>
<t>Add individual RR to a name:<br/>
TTL &gt;= 0 and TTL &lt;= 0x7FFFFFFF,<br/>
CLASS, TYPE, RDLEN, RDATA, and TTL specify the RR being
added.</t>
</li>
</ul>
<t>Note that it is valid for the RDATA of an added or removed DNS
Resource Record to be empty (zero length). For example, an Address
Prefix List Resource Record <xref target="RFC3123"
format="default"></xref> may have empty RDATA. Therefore, a change
notification with RDLEN = 0 does not automatically indicate a remove
notification. If RDLEN = 0 and TTL is in the range 0 to
0x7FFFFFFF, this change notification signals the addition of a
record with the given name, type, class, and empty RDATA. If RDLEN
= 0 and TTL = 0xFFFFFFFF, this change notification signals the
removal specifically of that single record with the given name,
type, class, and empty RDATA.</t>
<t>If the TTL is any value other than 0xFFFFFFFF, 0xFFFFFFFE, or a
value in the range 0 to 0x7FFFFFFF,
then the receiver <bcp14>SHOULD</bcp14> silently ignore this
particular change notification record.
The connection is not terminated and other valid change notification
records
within this PUSH message are processed as usual.</t> within this PUSH message are processed as usual.</t>
<t>For efficiency, when generating a PUSH message, a server SHOULD <t>In the case where a single change affects more than one active
include as many change notifications as it has immediately available to subscription, only one PUSH message is sent. For example, a PUSH
send, message adding a given record may match both a SUBSCRIBE request
rather than sending each change notification as a separate DSO message. with the same TYPE and a different SUBSCRIBE request with TYPE = 255
Once it has exhausted the list of change notifications immediately avai (ANY). It is not the case that two PUSH messages are sent because
lable to send, the new record matches two active subscriptions.</t>
a server SHOULD then send the PUSH message immediately,
rather than waiting to see if additional change notifications become av
ailable.</t>
<?rfc needLines="6" ?> <t>The server <bcp14>SHOULD</bcp14> encode change notifications in
<t>For efficiency, when generating a PUSH message, a server SHOULD the most efficient manner possible.
use standard DNS name compression, For example, when three AAAA records are removed from a given name,
with offsets relative to the beginning of the DNS message <xref target= and no other AAAA
"RFC1035"/>. records exist for that name, the server <bcp14>SHOULD</bcp14> send a
When multiple change notifications in a single PUSH message have the sa "Remove specified RRset from a name in given class" PUSH message,
me owner name, not three separate
this name compression can yield significant savings. "Remove an individual RR from a name" PUSH messages.
Name compression should be performed as specified in Section 18.14 of t Similarly, when both an SRV and a TXT record are removed from a
he given name, and no other
<xref target="RFC6762">Multicast DNS specification</xref>, namely, records of any kind exist for that name in that class, the server
owner names should always be compressed, <bcp14>SHOULD</bcp14> send a
and names appearing within RDATA should be compressed for only the RR t "Remove all RRsets from a name in given class" PUSH message, not two
ypes listed below: separate
<list style="hanging"> "Remove specified RRset from a name in given class" PUSH
<t>NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC</ messages.</t>
t>
</list></t>
<t>Servers may generate PUSH messages up to a maximum DNS message lengt <t>For efficiency, when generating a PUSH message, rather than
h of 16,382 bytes, sending
each change notification as a separate DSO message, a server
<bcp14>SHOULD</bcp14> include as many change notifications as it has
immediately available to send to that client, even if those change
notifications apply to different subscriptions from that
client. Conceptually, a PUSH
message is a session-level mechanism, not a subscription-level
mechanism.
Once it has exhausted the list of change notifications immediately
available to send to that client,
a server <bcp14>SHOULD</bcp14> then send the PUSH message
immediately
rather than waiting speculatively to see if additional change
notifications become available.</t>
<t>For efficiency, when generating a PUSH message a server
<bcp14>SHOULD</bcp14> use standard DNS name compression, with
offsets
relative to the beginning of the DNS message <xref target="RFC1035"
format="default"/>. When multiple change notifications in a single
PUSH message have the same owner name, this name compression can
yield significant savings. Name compression should be performed as
specified in <xref target="RFC6762" sectionFormat="of"
section="18.14">the Multicast DNS specification</xref>; namely,
owner names
should always be compressed, and names appearing within RDATA should
be compressed for only the RR types listed below:
</t>
<dl newline="false" spacing="normal">
<dt/>
<dd>NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV,
NSEC</dd>
</dl>
<t>Servers may generate PUSH messages up to a maximum DNS message
length of 16,382 bytes,
counting from the start of the DSO 12-byte header. counting from the start of the DSO 12-byte header.
Including the two-byte length prefix that is used to frame DNS over a b Including the two-byte length prefix that is used to frame DNS over a
yte stream byte stream
like TLS, this makes a total of 16,384 bytes. like TLS, this makes a total of 16,384 bytes.
Servers MUST NOT generate PUSH messages larger than this. Servers <bcp14>MUST NOT</bcp14> generate PUSH messages larger than
this.
Where the immediately available change notifications Where the immediately available change notifications
are sufficient to exceed a DNS message length of 16,382 bytes, are sufficient to exceed a DNS message length of 16,382 bytes,
the change notifications MUST be communicated in separate PUSH messages the change notifications <bcp14>MUST</bcp14> be communicated in
separate PUSH messages
of up to 16,382 bytes each. of up to 16,382 bytes each.
DNS name compression becomes less effective for messages larger than 16 DNS name compression becomes less effective for messages larger than
,384 bytes, 16,384 bytes,
so little efficiency benefit is gained by sending messages larger than so little efficiency benefit is gained by sending messages larger
this.</t> than this.</t>
<t>If a client receives a PUSH message with a DNS message length
<t>If a client receives a PUSH message with a DNS message length larger larger than 16,382 bytes,
than 16,382 bytes, this is a fatal error and the client <bcp14>MUST</bcp14> forcibly
this is a fatal error, and the client MUST forcibly abort the connectio abort the connection immediately.</t>
n immediately.</t> <figure anchor="push_msg">
<name>PUSH Message</name>
<figure align="left" anchor="push_msg" title="PUSH Message"><artwork al <artwork align="left" name="" type="" alt=""><![CDATA[
ign="left"><![CDATA[
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
| ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
| DSO-TYPE = PUSH (tentatively 0x41) | | DSO-TYPE = PUSH (0x0041) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSO-LENGTH (number of octets in DSO-DATA) | | DSO-LENGTH (number of octets in DSO-DATA) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
\ NAME \ \ \ NAME \ \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TYPE | | | TYPE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| CLASS | | | CLASS | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TTL | | | TTL | |
| (32-bit unsigned big-endian integer) | > DSO-DATA | (32-bit unsigned big-endian integer) | > DSO-DATA
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| RDLEN (16-bit unsigned big-endian integer) | | | 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 : /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /]]></artwork></figure> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /]]></artwork>
</figure>
<t>When processing the records received in a PUSH Message, the receivin <t>When processing the records received in a PUSH Message, the
g client MUST validate receiving client <bcp14>MUST</bcp14> validate
that the records being added or removed correspond with at least one cu that the records being added or removed correspond with at least one
rrently active currently active
subscription on that session. Specifically, the record name MUST match subscription on that session. Specifically, the record name
the name given in the <bcp14>MUST</bcp14> match the name given in the
SUBSCRIBE request, subject to the usual established DNS case-insensitiv SUBSCRIBE request, subject to the usual established DNS
ity for US-ASCII letters. case-insensitivity for US-ASCII letters.
For individual additions and removals, For individual additions and removals,
if the TYPE in the SUBSCRIBE request was not ANY (255) if the TYPE in the SUBSCRIBE request was not ANY (255),
then the TYPE of the record must match the TYPE given in the SUBSCRIBE then the TYPE of the record must either be CNAME or match the TYPE
request, and given in the SUBSCRIBE request, and
if the CLASS in the SUBSCRIBE request was not ANY (255) if the CLASS in the SUBSCRIBE request was not ANY (255),
then the CLASS of the record must match the CLASS given in the SUBSCRIB then the CLASS of the record must match the CLASS given in the
E request. SUBSCRIBE request.
For collective removals, at least one of the records being removed must For collective removals, at least one of the records being removed
match an active subscription. must match an active subscription.
If a matching active subscription on that session is not found, then th If a matching active subscription on that session is not found, then
at particular that particular
addition/removal record is silently ignored. Processing of other additi addition/removal record is silently ignored. The processing of other
ons and removal records additions and removal records
in this message is not affected. The DSO session is not closed. This is in this message is not affected. The DSO session is not closed. This
to allow for is to allow for
the unavoidable race condition where a client sends an outbound UNSUBSC the unavoidable race condition where a client sends an outbound
RIBE while UNSUBSCRIBE while
inbound PUSH messages for that subscription from the server are still i inbound PUSH messages for that subscription from the server are still
n flight.</t> in flight.</t>
<t>The TTL of an added record is stored by the client. While the
<t>In the case where a single change affects more than one active subsc subscription
ription, only one PUSH message is sent. For example, a PUSH message adding a giv is active the TTL is not decremented, because a change to the TTL
en record may match both a SUBSCRIBE request with the same TYPE and a different would
SUBSCRIBE request with TYPE = 255 (ANY). It is not the case that two PUSH messag
es are sent because the new record matches two active subscriptions.</t>
<t>The server SHOULD encode change notifications in the most efficient
manner possible.
For example, when three AAAA records are removed from a given name, and
no other AAAA
records exist for that name, the server SHOULD send a "remove an RRset
from a name"
PUSH message, not three separate "remove an individual RR from a name"
PUSH messages.
Similarly, when both an SRV and a TXT record are removed from a given n
ame, and no other
records of any kind exist for that name, the server SHOULD send a "remo
ve all RRsets
from a name" PUSH message, not two separate "remove an RRset from a nam
e" PUSH messages.</t>
<t>A server SHOULD combine multiple change notifications in a single PU
SH message when possible, even if those change notifications apply to different
subscriptions. Conceptually, a PUSH message is a session-level mechanism, not a
subscription-level mechanism.</t>
<t>The TTL of an added record is stored by the client. While the subsc
ription
is active, the TTL is not decremented, because a change to the TTL wo
uld
produce a new update. produce a new update.
For as long as a relevant subscription remains active, the client For as long as a relevant subscription remains active, the client
SHOULD assume that when a record goes away the server will notify it <bcp14>SHOULD</bcp14> assume that when a record goes away, the
of that fact. Consequently, a client does not have to poll to verify server will notify it
that the record is still there. Once a subscription is cancelled of that fact. Consequently, a client does not have to poll to
(individually, or as a result of the DSO session being closed) record verify
aging for records covered by the subscription resumes and records are that the record is still there. Once a subscription is canceled
(individually, or as a result of the DSO session being closed),
record
aging for records covered by the subscription resumes and records
are
removed from the local cache when their TTL reaches zero.</t> removed from the local cache when their TTL reaches zero.</t>
<?rfc needLines="48" ?> </section>
</section> </section>
</section>
<section title="DNS Push Notification UNSUBSCRIBE" anchor="unsubscribe">
<t>To cancel an individual subscription without closing the entire DSO se
ssion, the client sends an UNSUBSCRIBE message over the established DSO session
to the server.</t>
<t>The entity that initiates an UNSUBSCRIBE message is by definition the <section anchor="unsubscribe" numbered="true" toc="default">
client. <name>DNS Push Notification UNSUBSCRIBE</name>
A server MUST NOT send an UNSUBSCRIBE message over an existing session fr <t>To cancel an individual subscription without closing the entire DSO
om a client. session, the client sends an UNSUBSCRIBE message over the established
If a server does send an UNSUBSCRIBE message over a DSO session initiated DSO session to the server.</t>
by a client, <t>The entity that initiates an UNSUBSCRIBE message is by definition
or an UNSUBSCRIBE message is sent with the QR bit set indicating that it the client.
is a response, A server <bcp14>MUST NOT</bcp14> send an UNSUBSCRIBE message over an
this is a fatal error and the receiver MUST forcibly abort the connection existing session from a client.
immediately.</t> If a server does send an UNSUBSCRIBE message over a DSO session
initiated by a client,
<section title="UNSUBSCRIBE Message"> or an UNSUBSCRIBE message is sent with the QR bit set indicating that
it is a response,
<t>An UNSUBSCRIBE unidirectional message begins with the standard this is a fatal error and the receiver <bcp14>MUST</bcp14> forcibly
<xref target="RFC8490">DSO 12-byte header</xref>, followed by the UNSUB abort the connection immediately.</t>
SCRIBE primary TLV. <section numbered="true" toc="default">
An UNSUBSCRIBE message is illustrated in <xref target="unsubscribe_msg" <name>UNSUBSCRIBE Message</name>
/>.</t> <t>An UNSUBSCRIBE unidirectional message begins with the standard
DSO 12-byte header <xref target="RFC8490" format="default"></xref>,
<t>In accordance with the definition of DSO unidirectional messages, followed by the UNSUBSCRIBE Primary TLV.
the MESSAGE ID field MUST be zero. An UNSUBSCRIBE message is illustrated in <xref
target="unsubscribe_msg" format="default"/>.</t>
<t>In accordance with the definition of DSO unidirectional messages,
the MESSAGE ID field <bcp14>MUST</bcp14> be zero.
There is no server response to an UNSUBSCRIBE message.</t> There is no server response to an UNSUBSCRIBE message.</t>
<t>The other header fields <bcp14>MUST</bcp14> be set as described
<t>The other header fields MUST be set as described in the in the
<xref target="RFC8490">DSO spec-ification</xref>. <xref target="RFC8490" format="default">DSO specification</xref>.
The DNS OPCODE field contains the OPCODE value for DNS Stateful Operati The DNS OPCODE field contains the OPCODE value for DNS Stateful
ons (6). Operations (6).
The four count fields must be zero, and the corresponding four sections The four count fields must be zero, and the corresponding four
must be empty (i.e., absent).</t> sections must be empty (i.e., absent).</t>
<t>The DSO-TYPE is UNSUBSCRIBE (0x0042).</t>
<t>The DSO-TYPE is UNSUBSCRIBE (tentatively 0x42).</t> <t>The DSO-LENGTH field contains the value 2, the length of the
2-octet MESSAGE ID contained in the DSO-DATA.</t>
<t>The DSO-LENGTH field contains the value 2, the length of the 2-octet <t>The DSO-DATA contains the value previously given in the MESSAGE
MESSAGE ID contained in the DSO-DATA.</t> ID field of an active SUBSCRIBE request.
This is how the server knows which SUBSCRIBE request is being
<t>The DSO-DATA contains the value previously given in the MESSAGE ID f canceled.
ield of an active SUBSCRIBE request. After receipt of the UNSUBSCRIBE message, the SUBSCRIBE request is no
This is how the server knows which SUBSCRIBE request is being cancelled longer active.</t>
. <t>It is allowable for the client to issue an UNSUBSCRIBE message
After receipt of the UNSUBSCRIBE message, the SUBSCRIBE request is no l for a previous SUBSCRIBE request
onger active.</t>
<t>It is allowable for the client to issue an UNSUBSCRIBE message for a
previous SUBSCRIBE request
for which the client has not yet received a SUBSCRIBE response. for which the client has not yet received a SUBSCRIBE response.
This is to allow for the case where a client starts and stops a subscri This is to allow for the case where a client starts and stops a
ption in less than the subscription in less than the
round-trip time to the server. round-trip time to the server.
The client is NOT required to wait for the SUBSCRIBE response before is The client is NOT required to wait for the SUBSCRIBE response before
suing the UNSUBSCRIBE message.</t> issuing the UNSUBSCRIBE message.</t>
<t>Consequently, it is possible for a server to receive an
<?rfc needLines="6" ?> UNSUBSCRIBE message
<t>Consequently, it is possible for a server to receive an UNSUBSCRIBE
message
that does not match any currently active subscription. that does not match any currently active subscription.
This can occur when a client sends a SUBSCRIBE request, This can occur when a client sends a SUBSCRIBE request,
which subsequently fails and returns an error code, which subsequently fails and returns an error code,
but the client sent an UNSUBSCRIBE message before it but the client sent an UNSUBSCRIBE message before it
became aware that the SUBSCRIBE request had failed. became aware that the SUBSCRIBE request had failed.
Because of this, servers MUST silently ignore Because of this, servers <bcp14>MUST</bcp14> silently ignore
UNSUBSCRIBE messages that do not match any currently active subscriptio UNSUBSCRIBE messages that do not match any currently active
n.</t> subscription.</t>
<figure anchor="unsubscribe_msg">
<figure align="left" anchor="unsubscribe_msg" title="UNSUBSCRIBE Messag <name>UNSUBSCRIBE Message</name>
e"><artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
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
| ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
| DSO-TYPE = UNSUBSCRIBE (tentatively 0x42) | | DSO-TYPE = UNSUBSCRIBE (0x0042) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSO-LENGTH (2) | | DSO-LENGTH (2) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
| SUBSCRIBE MESSAGE ID | > DSO-DATA | SUBSCRIBE MESSAGE ID | > DSO-DATA
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /]]></artwork></figure> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /]]></artwork>
</figure>
<?rfc needLines="48" ?> </section>
</section> </section>
</section> <section anchor="reconfirm" numbered="true" toc="default">
<name>DNS Push Notification RECONFIRM</name>
<section title="DNS Push Notification RECONFIRM" anchor="reconfirm"> <t>Sometimes, particularly when used with a Discovery Proxy <xref
<t>Sometimes, particularly when used with a <xref target="DisProx">Discov target="RFC8766" format="default"></xref>, a DNS Zone may contain
ery Proxy</xref>, a DNS Zone may contain stale data. When a client encounters da stale data. When a client encounters data that it believes may be
ta that it believes may be stale (e.g., an SRV record referencing a target host+ stale (e.g., an SRV record referencing a target host+port that is not
port that is not responding to connection requests) the client can send a RECONF responding to connection requests), the client can send a RECONFIRM
IRM message to ask the server to re-verify that the data is still valid. For a D message to ask the server to re-verify that the data is still
iscovery Proxy, this causes it to issue new Multicast DNS queries to ascertain w valid. For a Discovery Proxy, this causes it to issue new Multicast
hether the target device is still present. How the Discovery Proxy causes these DNS queries to ascertain whether the target device is still
new Multicast DNS queries to be issued depends on the details of the underlying present. How the Discovery Proxy causes these new Multicast DNS
Multicast DNS implementation being used. queries to be issued depends on the details of the underlying
For example, a Discovery Proxy built on Apple's dns_sd.h API <xref target Multicast DNS implementation being used. For example, a Discovery
="SD-API"/> Proxy built on Apple's dns_sd.h API <xref target="SD-API"
responds to a DNS Push Notification RECONFIRM message by calling format="default"/> responds to a DNS Push Notification RECONFIRM
the underlying API's DNSServiceReconfirmRecord() routine.</t> message by calling the underlying API's DNSServiceReconfirmRecord()
routine.</t>
<t>For other types of DNS server, the RECONFIRM operation is currently un <t>For other types of DNS server, the RECONFIRM operation is currently
defined, and SHOULD result in a NOERROR response, but otherwise need not cause a undefined and <bcp14>SHOULD</bcp14> result in a NOERROR response, but
ny action to occur.</t> it need not cause any other action to occur.</t>
<t>Frequent use of RECONFIRM operations may be a sign of network
<t>Frequent use of RECONFIRM operations may be a sign of network unreliab unreliability, or some kind of misconfiguration, so RECONFIRM
ility, or some kind of misconfiguration, so RECONFIRM operations MAY be logged o operations <bcp14>MAY</bcp14> be logged or otherwise communicated to a
r otherwise communicated to a human administrator to assist in detecting and rem human administrator to assist in detecting and remedying such network
edying such network problems.</t> problems.</t>
<t>If, after receiving a valid RECONFIRM message, the server
<t>If, after receiving a valid RECONFIRM message, the server determines t determines that the disputed records are in fact no longer valid, then
hat the disputed records are in fact no longer valid, then subsequent DNS PUSH M subsequent DNS PUSH Messages will be generated to inform interested
essages will be generated to inform interested clients. Thus, one client discove clients. Thus, one client discovering that a previously advertised
ring that a previously-advertised device (like a network printer) is no longer p device (like a network printer) is no longer present has the side
resent has the side effect of informing all other interested clients that the de effect of informing all other interested clients that the device in
vice in question is now gone.</t> question is now gone.</t>
<t>The entity that initiates a RECONFIRM message is by definition the
<t>The entity that initiates a RECONFIRM message is by definition the cli client.
ent. A server <bcp14>MUST NOT</bcp14> send a RECONFIRM message over an
A server MUST NOT send a RECONFIRM message over an existing session from existing session from a client.
a client. If a server does send a RECONFIRM message over a DSO session initiated
If a server does send a RECONFIRM message over a DSO session initiated by by a client,
a client, or a RECONFIRM message is sent with the QR bit set indicating that it
or a RECONFIRM message is sent with the QR bit set indicating that it is is a response,
a response, this is a fatal error and the receiver <bcp14>MUST</bcp14> forcibly
this is a fatal error and the receiver MUST forcibly abort the connection abort the connection immediately.</t>
immediately.</t> <section numbered="true" toc="default">
<name>RECONFIRM Message</name>
<?rfc needLines="20" ?> <t>A RECONFIRM unidirectional message begins with the standard DSO
<section title="RECONFIRM Message"> 12-byte header <xref target="RFC8490" format="default"></xref>,
followed by the RECONFIRM Primary TLV.
<t>A RECONFIRM unidirectional message begins with the standard A RECONFIRM message is illustrated in <xref target="reconfirm_msg"
<xref target="RFC8490">DSO 12-byte header</xref>, followed by the RECON format="default"/>.</t>
FIRM primary TLV.<vspace /> <t>In accordance with the definition of DSO unidirectional messages,
A RECONFIRM message is illustrated in <xref target="reconfirm_msg"/>.</ the MESSAGE ID field <bcp14>MUST</bcp14> be zero.
t>
<t>In accordance with the definition of DSO unidirectional messages,
the MESSAGE ID field MUST be zero.
There is no server response to a RECONFIRM message.</t> There is no server response to a RECONFIRM message.</t>
<t>The other header fields <bcp14>MUST</bcp14> be set as described
<t>The other header fields MUST be set as described in the in the
<xref target="RFC8490">DSO spec-ification</xref>. <xref target="RFC8490" format="default">DSO specification</xref>.
The DNS OPCODE field contains the OPCODE value for DNS Stateful Operati The DNS OPCODE field contains the OPCODE value for DNS Stateful
ons (6). Operations (6).
The four count fields must be zero, and the corresponding four sections The four count fields must be zero, and the corresponding four
must be empty (i.e., absent).</t> sections must be empty (i.e., absent).</t>
<t>The DSO-TYPE is RECONFIRM (0x0043).</t>
<t>The DSO-TYPE is RECONFIRM (tentatively 0x43).</t> <t>The DSO-LENGTH is the length of the data that follows, which
specifies
<t>The DSO-LENGTH is the length of the data that follows, which specifi
es
the name, type, class, and content of the record being disputed.</t> the name, type, class, and content of the record being disputed.</t>
<t>A DNS Push Notifications RECONFIRM message contains exactly one
<t>The DSO-DATA for a RECONFIRM message MUST contain exactly one record RECONFIRM Primary TLV.
. The DSO-DATA in a RECONFIRM Primary TLV <bcp14>MUST</bcp14> contain
The DSO-DATA for a RECONFIRM message has no count field to specify more exactly one record.
than one record. The DSO-DATA in a RECONFIRM Primary TLV has no count field to
Since RECONFIRM messages are sent over TCP, multiple RECONFIRM messages specify more than one record.
can be concatenated in a single TCP stream and packed efficiently into Since RECONFIRM messages are sent over TCP, multiple RECONFIRM
TCP segments.</t> messages
can be concatenated in a single TCP stream and packed efficiently
<t>TYPE MUST NOT be the value ANY (255) and CLASS MUST NOT be the value into TCP segments.
ANY (255).</t> Note that this means that DNS name compression cannot be used
between different RECONFIRM messages.
<t>DNS wildcarding is not supported. That is, a wildcard ("*") in a REC However, when a client is sending multiple RECONFIRM messages this
ONFIRM message matches only a literal wildcard character ("*") in the zone, and indicates
nothing else.</t> a situation with serious network problems, and this is not expected
to occur
<t>Aliasing is not supported. That is, a CNAME in a RECONFIRM message m frequently enough that optimizing efficiency in this case is
atches only a literal CNAME record in the zone, and no other records with the sa important.
me owner name.</t> </t>
<t>TYPE <bcp14>MUST NOT</bcp14> be the value ANY (255) and CLASS
<t>Note that there is no RDLEN field, since the length of the RDATA can <bcp14>MUST NOT</bcp14> be the value ANY (255).</t>
be inferred from DSO-LENGTH, so an additional RDLEN field would be redundant.</ <t>DNS wildcarding is not supported.
t> That is, an asterisk character ("*") in a RECONFIRM message matches
only a literal asterisk character ("*") in a name and nothing else.
<figure align="left" anchor="reconfirm_msg" title="RECONFIRM Message">< Similarly, a CNAME in a RECONFIRM message matches only a CNAME
artwork align="left"><![CDATA[ record
with that name in the zone and no other records with that name.</t>
<t>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.</t>
<t>Following the same rules as for PUSH messages, DNS name
compression SHOULD
be used within the RDATA of the RECONFIRM message, with offsets
relative to the
beginning of the DNS message <xref target="RFC1035"
format="default"/>.</t>
<figure anchor="reconfirm_msg">
<name>RECONFIRM Message</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
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
| ANCOUNT (MUST BE ZERO) | | | ANCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| NSCOUNT (MUST BE ZERO) | | | NSCOUNT (MUST BE ZERO) | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| ARCOUNT (MUST BE ZERO) | / | ARCOUNT (MUST BE ZERO) | /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /
| DSO-TYPE = RECONFIRM (tentatively 0x43) | | DSO-TYPE = RECONFIRM (0x0043) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| DSO-LENGTH (number of octets in DSO-DATA) | | DSO-LENGTH (number of octets in DSO-DATA) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ \
\ NAME \ \ \ NAME \ \
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
| TYPE | | | TYPE | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > DSO-DATA
| CLASS | | | CLASS | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |
\ RDATA \ / \ RDATA \ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /]]></artwork></figure> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ /]]></artwork>
</figure>
<?rfc needLines="48" ?> </section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>DNS Stateful Operations TLV Context Summary</name>
<section title="DNS Stateful Operations TLV Context Summary"> <t>This document defines four new DSO TLVs. As recommended in <xref
<t>This document defines four new DSO TLVs. As recommended in Section 8.2 target="RFC8490" sectionFormat="of" section="8.2">the DNS Stateful
of the <xref target="RFC8490">DNS Stateful Operations specification</xref>, the Operations specification</xref>, the valid contexts of these
valid contexts of these new TLV types are summarized below.</t> new TLV types are summarized below.</t>
<t>The client TLV contexts are: <t>The client TLV contexts are:
<?rfc subcompact="yes" ?>
<list style="hanging">
<t hangText="C-P:">Client request message, primary TLV</t>
<t hangText="C-U:">Client unidirectional message, primary TLV</t>
<t hangText="C-A:">Client request or unidirectional message, addition
al TLV</t>
<t hangText="CRP:">Response back to client, primary TLV</t>
<t hangText="CRA:">Response back to client, additional TLV</t>
</list>
<?rfc subcompact="no" ?>
</t>
<texttable title="DSO TLV Client Context Summary" anchor="tlv_client_cont
exts">
<ttcol align="right">TLV Type</ttcol>
<ttcol align="center">C-P</ttcol>
<ttcol align="center">C-U</ttcol>
<ttcol align="center">C-A</ttcol>
<ttcol align="center">CRP</ttcol>
<ttcol align="center">CRA</ttcol>
<c>SUBSCRIBE</c><c>X</c><c></c><c></c><c></c><c></c>
<c>PUSH</c><c></c><c></c><c></c><c></c><c></c>
<c>UNSUBSCRIBE</c><c></c><c>X</c><c></c><c></c><c></c>
<c>RECONFIRM</c><c></c><c>X</c><c></c><c></c><c></c>
</texttable>
<t>The server TLV contexts are:
<?rfc subcompact="yes" ?>
<list style="hanging">
<t hangText="S-P:">Server request message, primary TLV</t>
<t hangText="S-U:">Server unidirectional message, primary TLV</t>
<t hangText="S-A:">Server request or unidirectional message, additional
TLV</t>
<t hangText="SRP:">Response back to server, primary TLV</t>
<t hangText="SRA:">Response back to server, additional TLV</t>
</list>
<?rfc subcompact="no" ?>
</t>
<texttable title="DSO TLV Server Context Summary" anchor="tlv_server_contex
ts">
<ttcol align="right">TLV Type</ttcol>
<ttcol align="center">S-P</ttcol>
<ttcol align="center">S-U</ttcol>
<ttcol align="center">S-A</ttcol>
<ttcol align="center">SRP</ttcol>
<ttcol align="center">SRA</ttcol>
<c>SUBSCRIBE</c><c></c><c></c><c></c><c></c><c></c>
<c>PUSH</c><c></c><c>X</c><c></c><c></c><c></c>
<c>UNSUBSCRIBE</c><c></c><c></c><c></c><c></c><c></c>
<c>RECONFIRM</c><c></c><c></c><c></c><c></c><c></c>
</texttable>
</section>
<section title="Client-Initiated Termination">
<t>An individual subscription is terminated by sending an UNSUBSCRIBE TLV
for that specific subscription, or all subscriptions can be cancelled at once b
y the client closing the DSO session. When a client terminates an individual sub
scription (via UNSUBSCRIBE) or all subscriptions on that DSO session (by ending
the session) it is signaling to the server that it is no longer interested in re
ceiving those particular updates. It is informing the server that the server may
release any state information it has been keeping with regards to these particu
lar subscriptions.</t>
<t>After terminating its last subscription on a session via UNSUBSCRIBE,
a client MAY close the session immediately, or it may keep it open if it anticip
ates performing further operations on that session in the future. If a client wi
shes to keep an idle session open, it MUST respect the maximum idle time require
d by the server <xref target="RFC8490"/>.</t>
<t>If a client plans to terminate one or more subscriptions on a session
and doesn't intend to keep that session open, then as an efficiency optimization
it MAY instead choose to simply close the session, which implicitly terminates
all subscriptions on that session. This may occur because the client computer is
being shut down, is going to sleep, the application requiring the subscriptions
has terminated, or simply because the last active subscription on that session
has been cancelled.</t>
<t>When closing a session, a client should perform an orderly close of </t>
the TLS session. <dl newline="false" spacing="compact">
Typical APIs will provide a session <dt>C-P:</dt>
close method that will send a TLS close_notify alert <dd>Client request message, Primary TLV</dd>
(see Section 6.1 of the TLS 1.3 specification <xref target="RFC8446"/>). <dt>C-U:</dt>
This instructs the recipient that the sender will not send any more data <dd>Client Unidirectional message, primary TLV</dd>
over the session. <dt>C-A:</dt>
After sending the TLS close_notify alert <dd>Client request or unidirectional message, Additional TLV</dd>
the client MUST gracefully close the underlying connection using a TCP FI <dt>CRP:</dt>
N, <dd>Response back to client, Primary TLV</dd>
so that the TLS close_notify is reliably delivered. <dt>CRA:</dt>
The mechanisms for gracefully closing a TCP connection with a TCP FIN var <dd>Response back to client, Additional TLV</dd>
y depending on the networking API. </dl>
For example, in the BSD Sockets API, sending a TCP FIN is achieved by cal <table anchor="tlv_client_contexts" align="center">
ling "shutdown(s,SHUT_WR)" <name>DSO TLV Client Context Summary</name>
and keeping the socket open until all remaining data has been read from i <thead>
t.</t> <tr>
<th align="right">TLV Type</th>
<th align="center">C-P</th>
<th align="center">C-U</th>
<th align="center">C-A</th>
<th align="center">CRP</th>
<th align="center">CRA</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">SUBSCRIBE</td>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="right">PUSH</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="right">UNSUBSCRIBE</td>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="right">RECONFIRM</td>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
</tbody>
</table>
<t>The server TLV contexts are:
<t>If the session is forcibly closed at the TCP level by sending a </t>
<dl newline="false" spacing="compact">
<dt>S-P:</dt>
<dd>Server request message, Primary TLV</dd>
<dt>S-U:</dt>
<dd>Server Unidirectional message, primary TLV</dd>
<dt>S-A:</dt>
<dd>Server request or unidirectional message, Additional TLV</dd>
<dt>SRP:</dt>
<dd>Response back to server, Primary TLV</dd>
<dt>SRA:</dt>
<dd>Response back to server, Additional TLV</dd>
</dl>
<table anchor="tlv_server_contexts" align="center">
<name>DSO TLV Server Context Summary</name>
<thead>
<tr>
<th align="right">TLV Type</th>
<th align="center">S-P</th>
<th align="center">S-U</th>
<th align="center">S-A</th>
<th align="center">SRP</th>
<th align="center">SRA</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">SUBSCRIBE</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="right">PUSH</td>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="right">UNSUBSCRIBE</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="right">RECONFIRM</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Client-Initiated Termination</name>
<t>An individual subscription is terminated by sending an UNSUBSCRIBE
TLV for that specific subscription, or all subscriptions can be
canceled at once by the client closing the DSO session. When a client
terminates an individual subscription (via UNSUBSCRIBE) or all
subscriptions on that DSO session (by ending the session), it is
signaling to the server that it is no longer interested in receiving
those particular updates. It is informing the server that the server
may release any state information it has been keeping with regards to
these particular subscriptions.</t>
<t>After terminating its last subscription on a session via
UNSUBSCRIBE, a client <bcp14>MAY</bcp14> close the session immediately
or it may keep it open if it anticipates performing further operations
on that session in the future. If a client wishes to keep an idle
session open, it <bcp14>MUST</bcp14> respect the maximum idle time
required by the server <xref target="RFC8490" format="default"/>.</t>
<t>If a client plans to terminate one or more subscriptions on a
session and doesn't intend to keep that session open, then as an
efficiency optimization, it <bcp14>MAY</bcp14> instead choose to
simply
close the session, which implicitly terminates all subscriptions on
that session. This may occur because the client computer is being shut
down, is going to sleep, the application requiring the subscriptions
has terminated, or simply because the last active subscription on that
session has been canceled.</t>
<t>When closing a session, a client should perform an orderly close of
the TLS session. Typical APIs will provide a session close method
that will send a TLS close_notify alert as described in <xref
target="RFC8446"
sectionFormat="of" section="6.1">the TLS 1.3 specification</xref>.
This instructs the
recipient that the sender will not send any more data over the
session. After sending the TLS close_notify alert, the client
<bcp14>MUST</bcp14> 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.</t>
<t>If the session is forcibly closed at the TCP level by sending a
RST from either end of the connection, data may be lost.</t> RST from either end of the connection, data may be lost.</t>
<?rfc needLines="10" ?> </section>
</section>
<section title="Client Fallback to Polling" anchor="polling"> <section anchor="polling" numbered="true" toc="default">
<name>Client Fallback to Polling</name>
<t>There are cases where a client may exhaust all avenues for <t>There are cases where a client may exhaust all avenues for
establishing a DNS Push Notification subscription without success. establishing a DNS Push Notification subscription without success.
This can happen if the client's configured recursive resolver This can happen if the client's configured recursive resolver does not
does not support DNS over TLS, or support DNS over TLS, or supports DNS over TLS but is not listening on
supports DNS over TLS but is not listening on TCP port 853, or TCP port 853, or supports DNS over TLS on TCP port 853 but does not
supports DNS over TLS on TCP port 853 but does not support DSO on that p support DSO on that port, or for some other reason is unable to
ort, provide a DNS Push Notification subscription. In this case, the
or for some other reason is unable to provide a DNS Push Notification su client
bscription. will attempt to communicate directly with an appropriate server, and
In this case the client will attempt to communicate directly with an app it may be that the zone apex discovery fails, or there is no
ropriate server, <tt>_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</tt> SRV record, or
and it may be that the zone apex discovery fails, or there is no the server indicated in the SRV record is misconfigured, overloaded,
<spanx style="verb">_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</spanx> SR or is
V record, unresponsive for some other reason.</t>
or server indicated in the SRV record is misconfigured, <t>Regardless of the reason for the failure, after being unable to
or is unresponsive for some other reason.</t> establish the desired DNS Push Notification subscription, it is likely
that the client will still wish to know the answer it seeks, even if
<t>Regardless of the reason for the failure, that answer cannot be obtained with the timely change notifications
after being unable to establish the desired DNS Push Notification subscr provided by DNS Push Notifications. In such cases, it is likely that
iption, the client will obtain the answer it seeks via a conventional DNS
it is likely that the client will still wish to know the answer it seeks query instead, repeated at some interval to detect when the answer
, RRset changes.</t>
even if that answer cannot be obtained with the timely <t>In the case where a client responds to its failure to establish a
change notifications provided by DNS Push Notifications. DNS Push Notification subscription by falling back to polling with
In such cases it is likely that the client will obtain conventional DNS queries instead, the polling rate should be
the answer it seeks via a conventional DNS query instead, controlled to avoid placing excessive burden on the server. The
repeated at some interval to detect when the answer RRset changes.</t> interval between successive DNS queries for the same name, type, and
class <bcp14>SHOULD</bcp14> be at least the minimum of 900 seconds (15
<t>In the case where a client responds to its minutes) or two seconds more than the TTL of the answer RRset.</t>
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.</t>
<t>The reason that for TTLs shorter than 898 seconds the query should
not be reissued until two seconds *after* the answer RRset has expired i
s
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.
</t>
<t>The reason that for TTLs up to 898 seconds the query should
not be reissued until two seconds <em>after</em> 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 receive a reply telling it
that the answer RRset has one second remaining; the client
would then requery the recursive resolver again one second later.
If by this time the answer RRset has actually expired from the
recursive resolver's cache, the recursive resolver would then
issue a new query to fetch fresh data from the
authoritative server. Waiting until the answer RRset has definitely
expired from the cache on the client's configured recursive resolver
avoids this race condition and any unnecessary additional queries it
causes.</t>
<t>Each time a client is about to reissue its query to discover <t>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 changes to the answer RRset, it should first make a new attempt to
establish a DNS Push Notification subscription, using previously establish a DNS Push Notification subscription using previously
cached DNS answers as appropriate. cached DNS answers as appropriate. After a temporary misconfiguration
After a temporary misconfiguration has been remedied, has been remedied, this allows a client that is polling to return to
this allows a client that is polling to return to using using DNS Push Notifications for asynchronous notification of
DNS Push Notifications for asynchronous notification of changes.</t> changes.</t>
</section> </section>
</section> </section>
<section title="Security Considerations" anchor="Security">
<t>The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS Pu
sh Notifications <xref target="RFC8310"/>. Cleartext connections for DNS Push No
tifications are not permissible. Since this is a new protocol, transition mechan
isms from the Opportunistic Privacy profile are unnecessary.</t>
<t>Also, see Section 9 of the DNS over (D)TLS Usage Profiles document <xref
target="RFC8310"/> for additional recommendations for various versions of TLS u
sage.</t>
<t>As a consequence of requiring TLS, client certificate authentication and
verification may also be enforced by the server for stronger client-server secu
rity or end-to-end security. However, recommendations for security in particular
deployment scenarios are outside the scope of this document.</t>
<t>DNSSEC is RECOMMENDED for the authentication of DNS Push Notification se
rvers.
TLS alone does not provide complete security.
TLS certificate verification can provide reasonable assurance that the clie
nt is really talking to the
server associated with the desired host name, but since the desired host na
me is learned via a DNS SRV query,
if the SRV query is subverted then the client may have a secure connection
to a rogue server.
DNSSEC can provide added confidence that the SRV query has not been subvert
ed.</t>
<?rfc needLines="14" ?>
<section title="Security Services">
<t>It is the goal of using TLS to provide the following security services
:
<list style="hanging">
<t hangText="Confidentiality:">All application-layer communication is
encrypted with the goal that no party should be able to decrypt it except the i
ntended receiver.</t>
<t hangText="Data integrity protection:">Any changes made to the comm
unication in transit are detectable by the receiver.</t>
<t hangText="Authentication:">An end-point of the TLS communication i
s authenticated as the intended entity to communicate with.</t>
<t hangText="Anti-replay protection:">TLS provides for the detection
of and prevention
against messages sent previously over a TLS connection (such as DNS P
ush Notifications).
If prior messages are re-sent at a later time as a form of a man-in-t
he-middle attack
then the receiver will detect this and reject the replayed messages.<
/t>
</list>
</t>
<t>Deployment recommendations on the appropriate key lengths and cypher s
uites are beyond the scope of this document. Please refer to <xref target="BCP19
5">TLS Recommendations</xref> for the best current practices. Keep in mind that
best practices only exist for a snapshot in time and recommendations will contin
ue to change. Updated versions or errata may exist for these recommendations.</t
>
</section>
<section title="TLS Name Authentication" anchor="tls_name_auth">
<t>As described in <xref target="discovery"/>, the client discovers the D
NS Push Notification server using an SRV lookup for the record name <spanx style
="verb">_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</spanx>. The server connection
endpoint SHOULD then be authenticated using DANE TLSA records for the associate
d SRV record. This associates the target's name and port number with a trusted T
LS certificate <xref target="RFC7673"/>. This procedure uses the TLS Server Name
Indication (SNI) extension <xref target="RFC6066"/> to inform the server of the
name the client has authenticated through the use of TLSA records. Therefore, i
f the SRV record passes DNSSEC validation and a TLSA record matching the target
name is useable, an SNI extension must be used for the target name to ensure the
client is connecting to the server it has authenticated. If the target name doe
s not have a usable TLSA record, then the use of the SNI extension is optional.
See <xref target="RFC8310">Usage Profiles for DNS over TLS and DNS over DTLS</xr
ef> for more information on authenticating domain names.</t>
</section>
<section title="TLS Early Data" anchor="early_data">
<t>DSO messages with the SUBSCRIBE TLV as the Primary TLV are permitted i
n TLS early data.
Using TLS early data can save one network round trip, and can result in t
he client obtaining results faster.</t>
<t>However, there are some factors to consider before using TLS early dat <section anchor="Security" numbered="true" toc="default">
a.</t> <name>Security Considerations</name>
<t>The Strict Privacy profile for DNS over TLS is
<bcp14>REQUIRED</bcp14> for DNS Push Notifications <xref
target="RFC8310" format="default"/>. Cleartext connections for DNS Push
Notifications are not permissible. Since this is a new protocol,
transition mechanisms from the Opportunistic Privacy profile are
unnecessary.</t>
<t>TLS Early Data is not forward secret. <t>Also, see
In cases where forward secrecy of DNS Push Notification subscriptions is <xref target="RFC8310" sectionFormat="of" section="9">the document Usage
required, Profiles for DNS over (D)TLS</xref>
the client should not use TLS Early Data.</t> for additional
recommendations for various versions of TLS usage.</t>
<t>As a consequence of requiring TLS, client certificate authentication
and verification may also be enforced by the server for stronger
client-server security or end-to-end security. However, recommendations
for security in particular deployment scenarios are outside the scope of
this document.</t>
<t>DNSSEC is <bcp14>RECOMMENDED</bcp14> for the authentication of DNS
Push Notification servers. TLS alone does not provide complete
security. TLS certificate verification can provide reasonable assurance
that the client is really talking to the server associated with the
desired host name, but since the desired host name is learned via a DNS
SRV query, if the SRV query is subverted, then the client may have a
secure connection to a rogue server. DNSSEC can provide added
confidence that the SRV query has not been subverted.</t>
<section numbered="true" toc="default">
<name>Security Services</name>
<t>It is the goal of using TLS to provide the following security
services:
</t>
<dl newline="false" spacing="normal">
<dt>Confidentiality:</dt>
<dd>All application-layer communication is encrypted with the goal
that no party should be able to decrypt it except the intended
receiver.</dd>
<dt>Data integrity protection:</dt>
<dd>Any changes made to the communication in transit are detectable
by the receiver.</dd>
<dt>Authentication:</dt>
<dd>An endpoint of the TLS communication is authenticated as the
intended entity to communicate with.</dd>
<dt>Anti-replay protection:</dt>
<dd>TLS provides for the detection of and prevention
against messages sent previously over a TLS connection (such as DNS
Push Notifications).
If prior messages are re-sent at a later time as a form of a
man-in-the-middle attack,
then the receiver will detect this and reject the replayed
messages.</dd>
</dl>
<t>With TLS early data there are no guarantees of non-replay between conn <t>Deployment recommendations on the appropriate key lengths and
ections. cipher suites are beyond the scope of this document. Please refer to
the current
TLS Recommendations <xref target="BCP195" format="default"></xref>
for the best current practices.
Keep in mind that best practices only exist for a snapshot in time,
and recommendations will continue to change.
Updated versions or errata may exist for these recommendations.</t>
</section>
<section anchor="tls_name_auth" numbered="true" toc="default">
<name>TLS Name Authentication</name>
<t>As described in <xref target="discovery" format="default"/>, the
client discovers the DNS Push Notification server using an SRV lookup
for the record name
<tt>_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</tt>. The server
connection endpoint <bcp14>SHOULD</bcp14> then be authenticated using
DANE TLSA records for the associated SRV record. This associates the
target's name and port number with a trusted TLS certificate <xref
target="RFC7673" format="default"/>. This procedure uses the TLS
Server Name Indication (SNI) extension <xref target="RFC6066"
format="default"/> to inform the server of the name the client has
authenticated through the use of TLSA records. Therefore, if the SRV
record passes DNSSEC validation and a TLSA record matching the target
name is usable, an SNI extension 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 a usable TLSA record, then the use of
the SNI extension is optional. See Usage Profiles for DNS over TLS and
DNS over DTLS <xref target="RFC8310" format="default"></xref> for more
information on authenticating domain names.</t>
</section>
<section anchor="early_data" numbered="true" toc="default">
<name>TLS Early Data</name>
<t>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
the client obtaining results faster.</t>
<t>However, there are some factors to consider before using TLS early
data.</t>
<t>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.</t>
<t>With TLS early data, there are no guarantees of non-replay between
connections.
If packets are duplicated and delayed in the network, 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, Generally, this is not a major concern
since the amount of state generated on the server for since the amount of state generated on the server for
these spurious subscriptions is small and short-lived, these spurious subscriptions is small and short lived
since the TCP connection will not complete the three-way handshake. since the TCP connection will not complete the three-way handshake.
Servers MAY choose to implement rate-limiting measures that are activated Servers <bcp14>MAY</bcp14> choose to implement rate-limiting measures
when that are activated when
the server detects an excessive number of spurious subscription requests. the server detects an excessive number of spurious subscription
</t> requests.</t>
<t>For further guidance on use of TLS early data, please see
<t>For further guidance please see discussion of zero round-trip data discussion of zero round-trip data
(Section 2.3, Section 8, and Appendix E.5) in Sections <xref target="RFC8446" sectionFormat="bare" section="2.3"/>
in the TLS 1.3 specification, <xref target="RFC8446"/>.</t> and
</section> <xref target="RFC8446" sectionFormat="bare" section="8"/>, and Appendix
<xref
<section title="TLS Session Resumption" anchor="resumption"> target="RFC8446" sectionFormat="bare" section="E.5"/>, of <xref
<t>TLS Session Resumption <xref target="RFC8446"/> target="RFC8446">the TLS 1.3 specification</xref>.</t>
</section>
<section anchor="resumption" numbered="true" toc="default">
<name>TLS Session Resumption</name>
<t>TLS session resumption <xref target="RFC8446" format="default"/>
is permissible on DNS Push Notification servers. is permissible on DNS Push Notification servers.
However, closing the TLS connection terminates the DSO session. However, closing the TLS connection terminates the DSO session.
When the TLS session is resumed, the DNS Push Notification server will no When the TLS session is resumed, the DNS Push Notification server will
t not
have any subscription state and will proceed as with any other new DSO se have any subscription state and will proceed as with any other new DSO
ssion. session.
Use of TLS Session Resumption may allow a TLS connection to be set up mor Use of TLS session resumption may allow a TLS connection to be set up
e quickly, more quickly,
but the client will still have to recreate any desired subscriptions.</t> but the client will still have to recreate any desired
<?rfc needLines="30" ?> subscriptions.</t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section title="IANA Considerations" anchor="IANA"> <name>IANA Considerations</name>
<t>This document defines a new service name, only applicable for the TCP
<t>This document defines a new service name, only applicable for the TCP pr protocol,
otocol, which has been recorded in the IANA "Service Name and Transport Protocol
to be recorded in the IANA Service Type Registry <xref target="RFC6335"/><x Port Number Registry" <xref target="RFC6335" format="default"/> <xref
ref target="SRVTYPE"/>.</t> target="SRVTYPE" format="default"/>.</t>
<texttable title="IANA Service Type Assignments" anchor="iana_service_table <table anchor="iana_service_table" align="center">
"> <name>IANA Service Type Assignments</name>
<ttcol width="25%" align="left">Name</ttcol> <thead>
<ttcol align="center">Port</ttcol> <tr>
<ttcol align="center">Value</ttcol> <th align="left">Name</th>
<ttcol align="left">Definition</ttcol> <th align="center">Port</th>
<c>DNS Push Notification Service Type</c> <th align="center">Value</th>
<c>None</c> <th align="center">Section</th>
<c><spanx style="verb">_dns&nbhy;push&nbhy;tls._tcp</spanx></c> </tr>
<c><xref target="discovery"/></c> </thead>
</texttable> <tbody>
<tr>
<t>This document defines four new DNS Stateful Operation TLV types <td align="left">DNS Push Notification Service Type</td>
to be recorded in the IANA DSO Type Code Registry <xref target="RFC8490"/>< <td align="center">None</td>
xref target="DSOTYPE"/>.</t> <td align="center">
<texttable title="IANA DSO TLV Type Code Assignments" anchor="iana_tlv_tabl <tt>_dns&nbhy;push&nbhy;tls._tcp</tt></td>
e"> <td align="center">
<ttcol align="left" >Name</ttcol> <xref target="discovery" format="counter"/></td>
<ttcol align="center" width="18%">Value</ttcol> </tr>
<ttcol align="center" >Early Data</ttcol> </tbody>
<ttcol align="center" width="28%">Status</ttcol> </table>
<ttcol align="left" width="20%">Definition</ttcol> <t>This document defines four new DNS Stateful Operation TLV types,
<c>SUBSCRIBE</c> which have been recorded in the IANA "DSO Type Codes" registry <xref
<c>TBA (0x40)</c> target="RFC8490" format="default"/> <xref target="DSOTYPE"
<c>OK</c> format="default"/>.</t>
<c>Standards Track</c> <table anchor="iana_tlv_table" align="center">
<c><xref target="subscribe"/></c> <name>IANA DSO TLV Type Code Assignments</name>
<c>PUSH</c> <thead>
<c>TBA (0x41)</c> <tr>
<c>NO</c> <th align="left">Name</th>
<c>Standards Track</c> <th align="center">Value</th>
<c><xref target="push"/></c> <th align="center">Early Data</th>
<c>UNSUBSCRIBE</c> <th align="center">Status</th>
<c>TBA (0x42)</c> <th align="center">Section</th>
<c>NO</c> </tr>
<c>Standards Track</c> </thead>
<c><xref target="unsubscribe"/></c> <tbody>
<c>RECONFIRM</c> <tr>
<c>TBA (0x43)</c> <td align="left">SUBSCRIBE</td>
<c>NO</c> <td align="center">0x0040</td>
<c>Standards Track</c> <td align="center">OK</td>
<c><xref target="reconfirm"/></c> <td align="center">Standards Track</td>
</texttable> <td align="center">
<xref target="subscribe" format="counter"/></td>
<t>This document defines no new DNS OPCODEs or RCODEs.</t> </tr>
<tr>
<?rfc needLines="12" ?> <td align="left">PUSH</td>
</section> <td align="center">0x0041</td>
<td align="center">NO</td>
<section title="Acknowledgements" anchor="Acknowledgements"> <td align="center">Standards Track</td>
<t>The authors would like to thank Kiren Sekar and Marc Krochmal for previo <td align="center">
us work completed in this field.</t> <xref target="push" format="counter"/></td>
</tr>
<t>This draft has been improved due to comments from <tr>
Ran Atkinson, <td align="left">UNSUBSCRIBE</td>
Tim Chown, <td align="center">0x0042</td>
Sara Dickinson, <td align="center">NO</td>
Mark Delany, <td align="center">Standards Track</td>
Ralph Droms, <td align="center">
Jan Komissar, <xref target="unsubscribe" format="counter"/></td>
Eric Rescorla, </tr>
Michael Richardson, <tr>
David Schinazi, <td align="left">RECONFIRM</td>
Manju Shankar Rao, <td align="center">0x0043</td>
Robert Sparks, <td align="center">NO</td>
Markus Stenberg, <td align="center">Standards Track</td>
Andrew Sullivan, <td align="center">
Michael Sweet, <xref target="reconfirm" format="counter"/></td>
Dave Thaler, </tr>
Brian Trammell, </tbody>
Bernie Volz, </table>
Eric Vyncke, <t>This document defines no new DNS OPCODEs or RCODEs.</t>
Christopher Wood, </section>
Liang Xia,
and
Soraia Zlatkovic.
Ted Lemon provided clarifying text that was greatly appreciated.</t>
<?rfc needLines="15" ?>
</section>
</middle>
<!-- *****BACK MATTER ***** --> </middle>
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries <displayreference target="I-D.ietf-tcpm-rack" to="TCPRACK"/>
:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (
as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml
"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
ml")
Both are cited textually in the same manner: by using xref elements. <references>
If you use the PI option, xml2rfc will, by default, try to find included fil <name>References</name>
es in the same <references>
directory as the including file. You can also define the XML_LIBRARY environ <name>Normative References</name>
ment variable <xi:include
with a value containing a set of directories to search. These can be either href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.00
in the local 20.xml"/>
filing system or remote ones accessed by http (http://domain/dir/... ).--> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.07
68.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.07
93.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.10
34.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.10
35.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.11
23.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.21
36.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.21
81.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.27
82.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.60
66.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.63
35.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.68
95.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.76
73.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.77
66.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.78
58.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.83
10.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.84
46.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.84
90.xml"/>
<references title="Normative References"> <reference anchor="SRVTYPE"
&RFC0020; target="https://www.iana.org/assignments/service-names-port
&RFC0768; -numbers/">
&RFC0793; <front>
&RFC1034; <title>Service Name and Transport Protocol Port Number
&RFC1035; Registry</title>
&RFC1123; <author><organization>IANA</organization></author>
&RFC2119; </front>
&RFC2136; </reference>
&RFC2181;
&RFC2782;
&RFC6066;
<?rfc include="reference.RFC.6335" ?>
&RFC6895;
&RFC7673;
&RFC7766;
&RFC7858;
&RFC8174;
&RFC8310;
&RFC8446;
&RFC8490;
<reference anchor="SRVTYPE" <reference anchor="DSOTYPE"
target="http://www.iana.org/assignments/service-names-port-numbers/"> target="https://www.iana.org/assignments/dns-parameters/">
<front> <front>
<title>Service Name and Transport Protocol Port Number Registry</title> <title>Domain Name System (DNS) Parameters</title>
<author/> <author><organization>IANA</organization></author>
<date/> </front>
</front> </reference>
</reference>
<reference anchor="DSOTYPE" </references>
target="https://www.iana.org/assignments/dns-parameters/">
<front>
<title>DSO Type Code Registry</title>
<author/>
<date/>
</front>
</reference>
</references> <references>
<name>Informative References</name>
<!-- Use needLines to make sure "Authors' Addresses" line doesn't appear as the <reference anchor='BCP195' target='https://www.rfc-editor.org/info/bcp195'>
last line on the page --> <front>
<?rfc needLines="9" ?> <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Data
gram Transport Layer Security (DTLS)</title>
<author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></
author>
<author initials='R.' surname='Holz' fullname='R. Holz'><organization /></author
>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'><organizat
ion /></author>
<date year='2015' month='May' />
</front>
<seriesInfo name='BCP' value='195'/>
<seriesInfo name='RFC' value='7525'/>
</reference>
<references title="Informative References"> <xi:include
<reference anchor="BCP195" target="http://www.rfc-editor.org/info/bcp195">< href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.23
front> 08.xml"/>
<title>Recommendations for Secure Use of Transport Layer Security (TL <xi:include
S) and Datagram Transport Layer Security (DTLS)</title> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.31
<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer"/> 23.xml"/>
<author initials="R." surname="Holz" fullname="Ralph Holz"/> <xi:include
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-And href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.42
re"/> 87.xml"/>
<date year="2015" month="May"/> <xi:include
</front><seriesInfo name="BCP" value="195"/><seriesInfo name="RFC" valu href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.49
e="7525"/></reference> 53.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.62
81.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.67
62.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.67
63.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.68
86.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.68
87.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.74
13.xml"/>
&RFC2308; <xi:include
&RFC3123; href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.84
&RFC4287; 99.xml"/>
&RFC4953;
&RFC6281;
&RFC6762;
&RFC6763;
&RFC6824;
&RFC6886;
&RFC6887;
&RFC7413;
&RFC7719;
&RFC8010;
&RFC8011;
&RFC8499;
&I-D.ietf-tcpm-rack; <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.86
84.xml"/>
<reference anchor='LLQ'> <xi:include
<front> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.80
<title>DNS Long-Lived Queries</title> 10.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.80
11.xml"/>
<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'> <xi:include
<organization /> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference
</author> .I-D.ietf-tcpm-rack.xml"/>
<author initials='M' surname='Krochmal' fullname='Marc Krochmal'> <reference anchor='RFC8764' target="https://www.rfc-editor.org/info/rfc8764">
<organization /> <front>
</author> <title>Apple's DNS Long-Lived Queries Protocol</title>
<date month='March' day='4' year='2019' /> <author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
<organization />
</author>
<abstract><t>DNS Long-Lived Queries (LLQ) is a protocol for extending the DNS pr <author initials='M' surname='Krochmal' fullname='Marc Krochmal'>
otocol to support change notification, thus allowing clients to learn about chan <organization />
ges to DNS data without polling the server. From 2007 onwards, LLQ was implemen </author>
ted in Apple products including Mac OS X, Bonjour for Windows, and AirPort wirel
ess base stations. In 2019, the LLQ protocol was superseded by the IETF Standar
ds Track RFC "DNS Push Notifications", which builds on experience gained with th
e LLQ protocol to create a superior replacement.</t></abstract>
</front> <date month='June' year='2020' />
</front>
<seriesInfo name='Internet-Draft' value='draft-sekar-dns-llq-03' /> <seriesInfo name='RFC' value='8764' />
<format type='TXT' <seriesInfo name="DOI" value="10.17487/RFC8764"/>
target='http://www.ietf.org/internet-drafts/draft-sekar-dns-llq-03.txt'
/>
</reference> </reference>
<reference anchor='DisProx'> <reference anchor='RFC8766' target="https://www.rfc-editor.org/info/rfc8766">
<front> <front>
<title>Discovery Proxy for Multicast DNS-Based Service Discovery</title> <title>Discovery Proxy for Multicast DNS-Based Service Discovery</title>
<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'> <author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
<organization /> <organization />
</author> </author>
<date month='March' day='24' year='2019' /> <date month='June' year='2020' />
<abstract><t>This document specifies a network proxy that uses Multicast DNS to
automatically populate the wide-area unicast Domain Name System namespace with r
ecords describing devices and services found on the local link.</t></abstract>
</front> </front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnssd-hybrid-10' /> <seriesInfo name="RFC" value="8766"/>
<format type='TXT' <seriesInfo name="DOI" value="10.17487/RFC8766"/>
target='http://www.ietf.org/internet-drafts/draft-ietf-dnssd-hybrid-10.t
xt' />
</reference> </reference>
<reference anchor='SYN'> <reference anchor="SYN"
<front> target="https://www.cisco.com/web/about/ac123/ac147/archive
<title>Defenses Against TCP SYN Flooding Attacks</title> d_issues/ipj_9-4/ipj_9-4.pdf">
<author initials='W.' surname='Eddy' fullname='Wesley Eddy'> <front>
<organization>Verizon Federal Network Systems</organization> <title>Defenses Against TCP SYN Flooding Attacks</title>
<address>
<email>weddy@grc.nasa.gov</email>
</address>
</author>
<date year='2006' month='December' />
<keyword>TCP</keyword>
</front>
<seriesInfo name="The Internet Protocol Journal," value='Cisco Systems' /
>
<seriesInfo name='Volume' value='9' />
<seriesInfo name='Number' value='4' />
<format type='PDF' octets='882020' target="http://www.cisco.com/web/about
/ac123/ac147/archived_issues/ipj_9-4/ipj_9-4.pdf" />
<format type='HTML' octets='65566' target="http://www.cisco.com/web/about
/ac123/ac147/archived_issues/ipj_9-4/syn_flooding_attacks.html" />
</reference>
<reference anchor='obs' target="https://en.wikipedia.org/wiki/Observer_patt <author initials="W." surname="Eddy" fullname="Wesley Eddy">
ern"> <organization>Verizon Federal Network Systems</organization>
<front> <address>
<title>Observer Pattern</title> <email>weddy@grc.nasa.gov</email>
<author/> </address>
<date/> </author>
</front> <date year="2006" month="December"/>
</reference> <keyword>TCP</keyword>
</front>
<refcontent>The Internet Protocol Journal</refcontent>
<refcontent>Cisco Systems</refcontent>
<refcontent>Volume 9</refcontent>
<refcontent>Number 4</refcontent>
</reference>
<reference anchor='SD-API' target="https://opensource.apple.com/source/mDNS <reference anchor="OBS"
Responder/mDNSResponder-878.70.2/mDNSShared/dns_sd.h.auto.html"> target="https://en.wikipedia.org/w/index.php?title=Obser
<front> ver_pattern&amp;oldid=939702131">
<title>dns_sd.h API</title> <front>
<author/> <title>Observer pattern</title>
<date/> <author>
</front> <organization>Wikipedia
</reference> </organization>
</author>
<date month="February" year="2020"/>
</front>
</reference>
<reference anchor="XEP0060"> <reference anchor="SD-API"
<front> target="https://opensource.apple.com/source/mDNSResponder/m
<title>Publish-Subscribe</title> DNSResponder-878.70.2/mDNSShared/dns_sd.h.auto.html">
<author initials="P." surname="Millard" fullname="Peter Millard"> <front>
<organization/> <title>dns_sd.h</title>
<address> <author>
<email/> <organization>Apple Inc.
</address> </organization>
</author> </author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre
">
<organization/>
<address>
<email>peter@andyet.net</email>
</address>
</author>
<author initials="R." surname="Meijer" fullname="Ralph Meijer">
<organization/>
<address>
<email>ralphm@ik.nu</email>
</address>
</author>
<date day="01" month="July" year="2010"/>
</front>
<seriesInfo name="XSF XEP" value="0060"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0060.html"/>
</reference>
</references> </front>
</back> </reference>
<reference anchor="XEP0060"
target="https://xmpp.org/extensions/xep-0060.html">
<front>
<title>Publish-Subscribe</title>
<author initials="P." surname="Millard" fullname="Peter Millard">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter
Saint-Andre">
<organization/>
<address>
<email>peter@andyet.net</email>
</address>
</author>
<author initials="R." surname="Meijer" fullname="Ralph Meijer">
<organization/>
<address>
<email>ralphm@ik.nu</email>
</address>
</author>
<date month="October" year="2019"/>
</front>
<refcontent>XSF XEP 0060
</refcontent>
</reference>
</references>
</references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Kiren Sekar"/> and
<contact fullname="Marc Krochmal"/> for previous work completed in this
field.</t>
<t>This document has been improved due to comments from
<contact fullname="Ran Atkinson"/>,
<contact fullname="Tim Chown"/>,
<contact fullname="Sara Dickinson"/>,
<contact fullname="Mark Delany"/>,
<contact fullname="Ralph Droms"/>,
<contact fullname="Jan Komissar"/>,
<contact fullname="Eric Rescorla"/>,
<contact fullname="Michael Richardson"/>,
<contact fullname="David Schinazi"/>,
<contact fullname="Manju Shankar Rao"/>,
<contact fullname="Robert Sparks"/>,
<contact fullname="Markus Stenberg"/>,
<contact fullname="Andrew Sullivan"/>,
<contact fullname="Michael Sweet"/>,
<contact fullname="Dave Thaler"/>,
<contact fullname="Brian Trammell"/>,
<contact fullname="Bernie Volz"/>,
<contact fullname="Éric Vyncke"/>,
<contact fullname="Christopher Wood"/>,
<contact fullname="Liang Xia"/>,
and
<contact fullname="Soraia Zlatkovic"/>.
<contact fullname="Ted Lemon"/> provided clarifying text that was greatly
appreciated.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 140 change blocks. 
1842 lines changed or deleted 1889 lines changed or added

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