rfc8764xml2.original.xml   rfc8764.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2119.xml">
<!ENTITY RFC2782 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2782.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8174.xml">
<!ENTITY RFC2136 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2136.xml">
<!ENTITY RFC4787 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4787.xml">
<!ENTITY RFC4953 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4953.xml">
<!ENTITY RFC5382 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5382.xml">
<!ENTITY RFC6281 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6281.xml">
<!ENTITY RFC6762 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6762.xml">
<!ENTITY RFC6763 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6763.xml">
<!ENTITY RFC6886 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6886.xml">
<!ENTITY RFC6887 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6887.xml">
<!ENTITY RFC6891 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6891.xml">
<!ENTITY RFC7857 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7857.xml">
]>
<?rfc compact="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc docName="draft-sekar-dns-llq-06" category="info" submissionType="independen <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8764"
t" ipr="trust200902"> docName="draft-sekar-dns-llq-06" category="info"
submissionType="independent" ipr="trust200902" obsoletes="" updates=""
xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
version="3">
<front> <front>
<title abbrev="Apple's DNS LLQ">Apple's DNS Long-Lived Queries
Protocol</title>
<seriesInfo name="RFC" value="8764"/>
<author initials="S." surname="Cheshire" fullname="Stuart Cheshire">
<organization>Apple Inc.</organization>
<address>
<postal>
<street>One Apple Park Way</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>United States of America</country>
</postal>
<phone>+1 (408) 996-1010</phone>
<email>cheshire@apple.com</email>
</address>
</author>
<author initials="M." surname="Krochmal" fullname="Marc Krochmal">
<organization>Apple Inc.</organization>
<address>
<postal>
<street>One Apple Park Way</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>United States of America</country>
</postal>
<phone>+1 (408) 996-1010</phone>
<email>marc@apple.com</email>
</address>
</author>
<date year="2020" month="June"/>
<title>Apple's DNS Long-Lived Queries protocol</title> <keyword>Async, Asynchronous, Change Notification, Push Notification</keyword>
<author initials="S." surname="Cheshire" fullname="Stuart Cheshire"> <abstract>
<organization>Apple Inc.</organization> <t>
<address> Apple's DNS Long-Lived Queries (LLQ) is a mechanism
<postal> for extending the DNS protocol to support change notification,
<street>One Apple Park Way</street> thus allowing clients to learn about changes to DNS data
<city>Cupertino</city> without polling the server. From 2005 onwards, LLQ was
<region>CA</region> implemented in Apple products including Mac OS X, Bonjour for
<code>95014</code> Windows, and AirPort wireless base stations. In 2020, the LLQ
<country>United States of America</country> protocol was superseded by the IETF Standards Track RFC 8765,
</postal> "DNS
<phone>+1 (408) 996-1010</phone> Push Notifications", which builds on experience gained with
<email>cheshire@apple.com</email> the LLQ protocol to create a superior replacement.
</address> </t>
</author> <t>
The existing LLQ protocol deployed and used from 2005 to 2020 is
documented here to give
background regarding the operational experience that informed
the development of DNS Push Notifications, and to help facilitate
a smooth transition from LLQ to DNS Push Notifications.
</t>
</abstract>
</front>
<middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>
In dynamic environments, DNS-based Service Discovery <xref target="RFC6763"
format="default"/> benefits
significantly from clients being able to learn about changes to
DNS information via a mechanism that is both more timely and more
efficient than simple polling. Such a mechanism enables "live
browses" that (a) learn when a new instance of a service appears, (b)
learn when
an existing service instance disappears from the network, and (c) allows
clients
to monitor status changes to a service instance (e.g., printer ink
levels).
Multicast DNS <xref target="RFC6762" format="default"/> supports this
natively. When a device on the network publishes or deletes Multicast DNS
records, these changes are multicast to other hosts on the network.
Those hosts deliver the change notifications to interested clients
(applications
running on that host). Hosts also send occasional queries to the
network, in case gratuitous announcements are not received due to
packet loss, and to detect records lost due to their publishers
crashing or having become disconnected from the network.
</t>
<t>
This document defines an Apple extension to unicast DNS that enables a
client to
issue long-lived queries that allow a unicast DNS server to notify clients
about changes to DNS data. This is a more scalable and practical
solution than can be achieved by polling of the name server, because
a low polling rate could leave the client with stale information,
while a high polling rate would have an adverse impact on the network
and server.
</t>
<t>
The mechanism defined in this document is now being replaced by DNS Push
Notifications <xref target="RFC8765" format="default"></xref> as explained
in <xref target="trans" format="default"/>.
</t>
<t>
</t>
<section anchor="trans" numbered="true" toc="default">
<name>Transition to DNS Push Notifications</name>
<t>
The LLQ protocol enjoyed over a decade of useful operation,
enabling timely live updates for the service discovery user interface in
Apple's Back to My Mac <xref target="RFC6281" format="default"></xref>
service.
</t>
<t>
However, some problems were discovered, as described in <xref
target="problems" format="default"/>.
This operational
experience with LLQ informed the design of its IETF Standards
Track successor, DNS Push Notifications <xref target="RFC8765"
format="default"></xref>.
Since no further work is being done on the LLQ protocol, this LLQ
specification will not be updated to remedy these problems.
</t>
<t>
All existing LLQ implementations are <bcp14>RECOMMENDED</bcp14> to migrate
to using DNS Push Notifications instead.
</t>
<t>
Existing LLQ servers are <bcp14>RECOMMENDED</bcp14> to implement and
support
DNS Push Notifications so that clients can begin migrating to the
newer protocol.
</t>
<t>
Existing LLQ clients are <bcp14>RECOMMENDED</bcp14> to query for the
<tt>_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</tt> SRV record first, and
then only if DNS Push Notifications fail, fall back to query for
<tt>_dns&nbhy;llq._udp.&lt;zone&gt;</tt> instead. Use of the
<tt>_dns&nbhy;llq._udp.&lt;zone&gt;</tt> SRV record is described in <xref
target="address-port"/>.
</t>
<t>
This will cause clients to prefer the newer protocol when possible. It is
<bcp14>RECOMMENDED</bcp14> that clients always attempt DNS Push
Notifications first for every new request, and only if that fails, then
fall back to using LLQ. Clients <bcp14>SHOULD NOT</bcp14> record that a
given server only speaks LLQ and subsequently default to LLQ for that
server, since server software gets updated and even a server that speaks
only LLQ today may be updated to support DNS Push Notifications tomorrow.
</t>
<t>
New client and server implementations are <bcp14>RECOMMENDED</bcp14> to
support only
DNS Push Notifications.
</t>
<author initials='M.' surname='Krochmal' fullname='Marc Krochmal'> </section>
<organization>Apple Inc.</organization> </section>
<address> <section numbered="true" toc="default">
<postal> <name>Conventions and Terminology Used in This Document</name>
<street>One Apple Park Way</street>
<city>Cupertino</city>
<region>California</region>
<code>95014</code>
<country>USA</country>
</postal>
<email>marc@apple.com</email>
</address>
</author>
<date year="2019" month="August" day="22"/> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.
</t>
<abstract> </section>
<t> <section numbered="true" toc="default">
Apple's DNS Long-Lived Queries protocol (LLQ) is <name>Mechanisms</name>
a protocol for extending the DNS protocol to support <t>
change notification, thus allowing clients to learn about changes DNS Long-Lived Queries (LLQ) are implemented using the standard
to DNS message format <xref target="RFC1035" format="default"/> in
DNS data without polling the server. conjunction with an EDNS(0) OPT
From 2005 onwards, LLQ was implemented in Apple products pseudo&nbhy;RR <xref target="RFC6891" format="default"/> with a new
including Mac OS X, Bonjour for Windows, and AirPort wireless base OPTION&nbhy;CODE
stations. In 2019, the LLQ protocol and OPTION&nbhy;DATA format specified here. Encoding the LLQ request in
was superseded by the IETF Standards Track RFC xxxx an OPT pseudo&nbhy;RR
[[RFC Editor note: Please replace xxxx with RFC number]] allows for implementation of LLQ with minimal modification to a name
"DNS Push Notifications", server's front end. If a DNS query containing an LLQ option is sent to a
which builds on experience gained with the LLQ protocol to create server that does not implement LLQ, a server that complies with the
a superior replacement. EDNS(0) specification <xref target="RFC6891" format="default"></xref> will
</t> silently ignore the unrecognized option and answer the request as a normal
<t> DNS query without establishing any long-lived state and without
The existing LLQ protocol deployed and used from 2005 to 2019 is documented h returning an LLQ option in its response. If a DNS query containing an LLQ
ere to give option is sent to a server that does not implement EDNS(0) at all, the
background regarding the operational experience that informed server may silently ignore the EDNS(0) OPT pseudo&nbhy;RR or it may
the development of DNS Push Notifications, and to help facilitate return a nonzero RCODE. However, in practice, this issue is mostly
a smooth transition from LLQ to DNS Push Notifications. theoretical, since having a zone's _dns&nbhy;llq._udp.&lt;zone&gt; SRV
</t> record target a host that does not implement LLQ is a configuration error.
</abstract> </t>
<t>
Note that this protocol is designed for data set sizes of a few dozen
resource records at most and change rates no more than once every 10
seconds on average. Data sets that frequently
exceed a single IP packet, or that experience a rapid change rate, may
have
undesirable performance implications.
</t>
</front> <section numbered="true" toc="default">
<name>Assigned Numbers</name>
<t>
This section describes constants used in this document.
</t>
<middle> <ul empty="true">
<?rfc needLines="40" ?>
<section anchor="introduction" title="Introduction">
<t>
In dynamic environments, DNS Service Discovery <xref target="RFC6763"/> benef
its
significantly from clients being able to learn about changes to
DNS information via a mechanism that is both more timely and more
efficient than simple polling. Such a mechanism enables "live
browses" that learn when a new instance of a service appears, or when
an existing service disappears from the network, and allows clients
to monitor changes to a service. Multicast DNS <xref target="RFC6762"/> suppo
rts this
natively. When a host on the network publishes or deletes DNS
records, these changes are multicast to other hosts on the network.
These hosts deliver the change notifications to interested clients (applicati
ons
running on the host). Hosts also send occasional queries to the
network in case gratuitous announcements are not received due to
packet loss, and to detect records lost due to their publishers
crashing or having become disconnected from the network.
</t>
<t> <li>
This document defines an Apple extension to DNS that enables a client to <t>EDNS(0) OPTION&nbhy;CODE (recorded with IANA):</t>
issue long-lived queries that allow a DNS server to notify clients
about changes to DNS data. This is a more scalable and practical
solution than can be achieved by polling of the name server because
a low polling rate could leave the client with stale information
while a high polling rate would have an adverse impact on the network
and server.
</t>
<t> <ul empty="true">
The mechanism defined in this document is now being replaced by <li>
<xref target="Push">DNS Push Notifications</xref> as explained below <dl indent="18">
in <xref target="trans"/>. <dt>LLQ
</t> </dt>
<?rfc needLines="40" ?> <dd>1
<t> </dd>
</t> </dl>
<section anchor="trans" title="Transition to DNS Push Notificatio </li>
ns"> </ul>
<t> </li>
The LLQ protocol enjoyed over a decade of useful operation,
enabling timely live updates for the service discovery user interface in
Apple's <xref target="RFC6281">Back to My Mac</xref> service.
</t>
<t> <li>
However, some problems were discovered, as described in <xref target="problem LLQ&nbhy;PORT 5352 (recorded with IANA)
s"/>. </li>
This operational
experience with LLQ informed the design of its IETF Standards
Track successor, <xref target="Push">DNS Push Notifications</xref>.
Since no further work is being done on the LLQ protocol, this LLQ
specification will not be updated to remedy these problems.
</t>
<t> <li><t>LLQ Opcodes (specific to this LLQ EDNS(0) Option):</t>
All existing LLQ
implementations are RECOMMENDED to migrate to using DNS Push Notifications in
stead.
</t>
<t> <ul empty="true">
For existing LLQ servers, they are RECOMMENDED to implement and support <li>
DNS Push Notifications, so that clients can begin migrating to the <dl indent="18" spacing="compact">
newer protocol. <dt>LLQ&nbhy;SETUP
</t> </dt>
<dd>1
</dd>
<t> <dt>LLQ&nbhy;REFRESH
For existing LLQ clients, they are RECOMMENDED to query for the </dt>
<spanx style="verb">_dns&nbhy;push&nbhy;tls._tcp.&lt;zone&gt;</spanx> <dd>2
SRV record first, and only if DNS Push fails, then fall back to query for </dd>
<spanx style="verb">_dns&nbhy;llq._udp.&lt;zone&gt;</spanx> instead.
</t>
<t> <dt>LLQ&nbhy;EVENT
This will cause clients to prefer the newer protocol when possible. </dt>
It is RECOMMENDED that clients always attempt <dd>3
DNS Push Notifications first for every new request, and </dd>
only if that fails, then back to using LLQ. </dl>
Clients SHOULD NOT record that a given server only speaks LLQ and </li>
subsequently default to LLQ for that server, since server software </ul>
gets updated, and even a server that speaks only LLQ today, </li>
may be updated to support DNS Push Notifications tomorrow.
</t>
<t> <li>
New client and server implementations are RECOMMENDED to support only <t>LLQ Error Codes (specific to this LLQ EDNS(0) Option):</t>
DNS Push Notifications.
</t>
</section> <ul empty="true">
</section> <li>
<dl indent="18" spacing="compact">
<dt>
NO-ERROR
</dt>
<dd>0
</dd>
<section title="Conventions and Terminology Used in this Document"> <dt>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL SERV-FULL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", </dt>
"MAY", and "OPTIONAL" in this document are to be interpreted as <dd>1
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="R </dd>
FC8174"/>
when, and only when, they appear in all capitals, as shown here.<
/t>
<?rfc needLines="40" ?>
</section>
<section title="Mechanisms"> <dt>
<t> STATIC
DNS Long-Lived Queries (DNS&nbhy;LLQ) is implemented using the standard </dt>
DNS message format <xref target="RFC1035"/> in conjunction with an EDNS(0) OP <dd>2
T </dd>
pseudo&nbhy;RR <xref target="RFC6891"/> with a new OPT and RDATA format speci
fied here.
Encoding the LLQ request in an OPT RR allows for implementation of
LLQ with minimal modification to a name server's front-end.
If a DNS query containing an LLQ option is sent to a
server that does not implement LLQ, a server that complies with
the <xref target="RFC6891">EDNS(0) specification</xref> will silently ignore
the unrecognized option and answer the request as a normal DNS query,
without establishing any long-lived state,
and without returning an LLQ option in its response.
If a DNS query containing an LLQ option is sent to a
server that does not implement EDNS(0) at all,
the server may silently ignore the EDNS(0) OPT pseudo&nbhy;RR,
or it may return a nonzero RCODE.
However, in practice this issue is mostly theoretical,
since having a zone's _dns&nbhy;llq._udp.&lt;zone&gt; SRV record
target a host that does not implement LLQ is a configuration error.
</t>
<t>
Note that this protocol is designed for data set sizes of a few dozen resourc
e records at most, and
change rates no more than one every ten seconds on average. Data sets in resp
onse to queries that
frequently exceed a single packet, or that experience a rapid change
rate, may have undesirable performance implications.
</t>
<?rfc needLines="20" ?>
<t>
</t>
<section title="Assigned Numbers">
<t>
This section describes constants uses in this document.
</t>
<figure><artwork>
EDNS(0) Option Code (recorded with IANA):
LLQ 1
LLQ-PORT 5352 (recorded with IANA) <dt>
FORMAT-ERR
</dt>
<dd>3
</dd>
LLQ Error Codes (specific to this LLQ EDNS(0) Option): <dt>
NO-ERROR 0 NO-SUCH-LLQ
SERV-FULL 1 </dt>
STATIC 2 <dd>4
FORMAT-ERR 3 </dd>
NO-SUCH-LLQ 4
BAD-VERS 5
UNKNOWN-ERR 6
LLQ Opcodes (specific to this LLQ EDNS(0) Option): <dt>
LLQ-SETUP 1 BAD-VERS
LLQ-REFRESH 2 </dt>
LLQ-EVENT 3 <dd>5
</artwork></figure> </dd>
<?rfc needLines="40" ?>
</section>
<section title="Opt-RR Format"> <dt>
<t> UNKNOWN-ERR
As required by the <xref target="RFC6891">EDNS(0) specification</xref>, </dt>
all OPT&nbhy;RRs used in LLQs are formatted as follows: <dd>6
</t> </dd>
</dl>
</li>
</ul>
</li>
</ul>
<figure><artwork> </section>
Field Name Field Type Description
NAME domain name empty (root domain)
TYPE u_int16_t OPT
CLASS u_int16_t 0*
TTL u_int32_t 0
RDLEN u_int16_t describes RDATA
RDATA octet stream (see below)
</artwork></figure>
<t> <section numbered="true" toc="default">
* The CLASS field indicates, as per the <xref target="RFC6891">EDNS(0) specif <name>Opt-RR Format</name>
ication</xref>, the sender's UDP <t>
payload size. However, clients and servers need not be required to As required by the EDNS(0) specification <xref target="RFC6891"
determine their reassembly buffer size, path MTU, etc. to support format="default"></xref>,
LLQ. Thus, the sender of an LLQ Request or Response MAY set the CLASS all OPT pseudo&nbhy;RRs used in LLQs are formatted as follows:
field to 0. The recipient MUST ignore the class field if it is set </t>
to 0.
</t>
<?rfc needLines="20" ?> <table anchor="OPT-RRs">
<t> <name>OPT-RRs Used in LLQs</name>
RDATA Format: <thead>
</t> <tr>
<th>Field Name</th>
<th>Field Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>NAME</td>
<td>domain name</td>
<td>MUST be 0 (root domain)</td>
</tr>
<tr>
<td>TYPE</td>
<td>u_int16_t</td>
<td>OPT (41)</td>
</tr>
<tr>
<td>CLASS</td>
<td>u_int16_t</td>
<td>0*</td>
</tr>
<tr>
<td>TTL</td>
<td>u_int32_t</td>
<td>0</td>
</tr>
<tr>
<td>RDLEN</td>
<td>u_int16_t</td>
<td>length of all RDATA</td>
</tr>
<tr>
<td>RDATA</td>
<td>octet stream</td>
<td>(see below)</td>
</tr>
</tbody>
</table>
<figure><artwork> <t>
Field Name Field Type Description * The CLASS field indicates, as per the EDNS(0) specification <xref
OPTION-CODE u_int16_t LLQ target="RFC6891" format="default"></xref>, the sender's UDP payload
OPTION-LENGTH u_int16_t Length of following fields, as size. However, clients and servers are not required to determine their
appropriate reassembly buffer size, path MTU, etc., to support LLQ. Thus, the sender
VERSION u_int16_t Version of LLQ protocol implemented of
LLQ-OPCODE u_int16_t Identifies LLQ operation an LLQ Request or Response <bcp14>MAY</bcp14> set the CLASS field to 0.
ERROR-CODE u_int16_t Identifies LLQ errors The recipient <bcp14>MUST</bcp14> ignore the class field if it is set to
LLQ-ID u_int64_t Identifier for an LLQ 0.
LEASE-LIFE u_int32_t Requested or granted life of LLQ, in </t>
seconds <t>
</artwork></figure> The RDATA of an EDNS(0) OPT pseudo&nbhy;RR consists of zero or more
options
of the form { OPTION&nbhy;CODE, OPTION&nbhy;LENGTH, OPTION&nbhy;DATA }
packed together,
with the RDLEN field set accordingly to indicate the total size.
An LLQ OPTION is illustrated below.
An EDNS(0) OPT pseudo&nbhy;RR may contain zero or more LLQ OPTIONS in
addition
to zero or more other EDNS(0) options.
</t>
<t> <table anchor="LLQ-OPT-FORMAT">
This data format, consisting of (OPTION&nbhy;CODE, OPTION&nbhy;LENGTH, <name>LLQ OPTION</name>
LLQ&nbhy;Metadata) tuples, may be repeated an arbitrary number of times in <thead>
the RDATA section, with the RDLEN field set accordingly. <tr>
</t> <th>Field Name</th>
<th>Field Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>OPTION-CODE</td>
<td>u_int16_t</td>
<td>LLQ (1)</td>
</tr>
<tr>
<td>OPTION-LENGTH</td>
<td>u_int16_t</td>
<td>Length of following fields (18)</td>
</tr>
<tr>
<td>LLQ-VERSION</td>
<td>u_int16_t</td>
<td>Version of LLQ protocol implemented</td>
</tr>
<tr>
<td>LLQ-OPCODE</td>
<td>u_int16_t</td>
<td>Identifies LLQ operation</td>
</tr>
<tr>
<td>LLQ-ERROR</td>
<td>u_int16_t</td>
<td>Identifies LLQ errors</td>
</tr>
<tr>
<td>LLQ-ID</td>
<td>u_int64_t</td>
<td>Identifier for an LLQ</td>
</tr>
<tr>
<td>LLQ-LEASE</td>
<td>u_int32_t</td>
<td>Requested or granted life of LLQ, in seconds</td>
</tr>
<t> </tbody>
The size and meaning of the </table>
OPTION&nbhy;CODE and OPTION&nbhy;LENGTH fields are as described in the
<xref target="RFC6891">EDNS(0) specification</xref>.
The remainder of the fields comprise the OPTION-DATA of the
EDNS(0) option.
Since for LLQ the OPTION-DATA is a fixed size,
in LLQ EDNS(0) options the OPTION&nbhy;LENGTH field always has the value 18.
</t>
<?rfc needLines="40" ?>
</section>
</section>
<section title="LLQ Address and Port Identification"> <t>
<t> The size and meaning of the OPTION&nbhy;CODE and OPTION&nbhy;LENGTH fields
are as described in the EDNS(0) specification <xref target="RFC6891"
format="default"></xref>. The remainder of the fields comprise the
OPTION&nbhy;DATA of the EDNS(0) LLQ OPTION. Since for LLQ the
OPTION&nbhy;DATA is a
fixed size, in EDNS(0) LLQ OPTIONS the OPTION&nbhy;LENGTH field always has
the value 18.
</t>
<t>
In keeping with Internet convention, all multi-byte numeric quantities
(u_int16_t, u_int32_t, and u_int64_t)
are represented in big endian byte order (most significant byte first).
</t>
</section>
</section>
<section numbered="true" toc="default" anchor="address-port">
<name>LLQ Address and Port Identification</name>
<t>
The client The client
requires a mechanism to determine to which server it should send LLQ operatio requires a mechanism to determine to which server it should send LLQ
ns. operations.
</t> </t>
<t> <t>
Additionally, some firewalls block direct communication with a Additionally, some firewalls block direct communication with a name server
name server on port 53 to avoid spoof responses. However, this on port 53 to avoid spoof responses. However, this direct communication is
direct communication is necessary for LLQs. Thus, servers MAY listen necessary for LLQs. Thus, servers <bcp14>MAY</bcp14> listen for LLQs on a
for LLQs on a different port (typically 5352). Clients also therefore need a different port (typically 5352). Clients, therefore, also need a
mechanism to determine to which port to send LLQ operations. mechanism to determine to which port to send LLQ operations.
</t> </t>
<?rfc needLines="20" ?>
<t> <t>
The client determines the server responsible for a given LLQ much as The client determines the server responsible for a given LLQ much as a
a client determines to which server to send a dynamic update. The client determines to which server to send a DNS dynamic update. The client
client begins by sending a standard DNS query for the name of the begins by sending a standard DNS query for the name of the LLQ, with type
LLQ, with type SOA. The server MUST answer with that SOA record in SOA. If the record exists, then the server <bcp14>MUST</bcp14> answer with
the Answer section, if the record exists. The server SHOULD include that SOA record in the Answer section. If a record of type SOA with the
an SOA record for that name's zone in the Authority section, if the LLQ name does not exist, then the server <bcp14>SHOULD</bcp14> include an
LLQ name (type SOA) does not exist. For example, a query for SOA record for that name's zone in the Authority section. For example, a
"_ftp._tcp.example.com." may return an SOA record named "example.com." in the query for "_ftp._tcp.example.com" with type SOA, when there is no SOA
Authority section if there is no SOA record named record with that name, might return an SOA record named "example.com" in
"_ftp._tcp.example.com." If, in this case, the server does not include the Authority section. If the named SOA record does not exist and the
the SOA record in the Authority section, the client strips the server fails to include the enclosing SOA record in the Authority section,
leading label from the name and tries again, repeating until an the client strips the leading label from the name and tries again,
answer is received. repeating until an answer is received.
</t> </t>
<t> <t>
This iterative zone apex discovery algorithm is described in more detail This iterative zone apex discovery algorithm is described in more detail in
in the <xref target="Push">DNS Push Notifications specification</xref>. the DNS Push Notifications specification <xref target="RFC8765"
</t> format="default"></xref>.
<t> </t>
Upon learning the zone (SOA), the client then constructs and sends an <t>
SRV query for the name _dns&nbhy;llq._udp.&lt;zone&gt;, Upon learning the zone apex (SOA), the client then constructs and sends an
e.g.,&nbsp;_dns&nbhy;llq._udp.example.com. SRV query for the name, "_dns&nbhy;llq._udp.&lt;zone&gt;",
</t> e.g.,&nbsp;"_dns&nbhy;llq._udp.example.com".
<t> </t>
A server implementing LLQ MUST answer with an SRV record <xref target="RFC278 <t>
2"/> An authoritative server for a zone implementing LLQ <bcp14>MUST</bcp14>
answer with an SRV record <xref target="RFC2782" format="default"/>
for this name. The SRV RDATA is as follows: for this name. The SRV RDATA is as follows:
</t> </t>
<figure><artwork>
PRIORITY typically 0 <table anchor="SRV-RDATA">
WEIGHT typically 0 <name>SRV RDATA</name>
PORT typically 53 or 5352 <tbody>
TARGET name of server providing LLQs for the requested zone <tr>
</artwork></figure> <td>PRIORITY</td>
<t> <td>typically 0</td>
The server SHOULD include its address record(s) in the Additional
</tr>
<tr>
<td>WEIGHT</td>
<td>typically 0</td>
</tr>
<tr>
<td>PORT</td>
<td>typically 53 or 5352</td>
</tr>
<tr>
<td>TARGET</td>
<td>name of server providing LLQs for the requested zone</td>
</tr>
</tbody>
</table>
<t>
The server <bcp14>SHOULD</bcp14> include the address record(s) for the
target host in the Additional
section of the response. section of the response.
</t> </t>
<t> <t>
If the server does not include its address record in the Additional If the server does not include the target host's address record(s) in the
section, the client SHOULD query explicitly for the address record Additional
section, the client <bcp14>SHOULD</bcp14> query explicitly for the address
record(s)
with the name of the SRV target. with the name of the SRV target.
</t> </t>
<t> <t>
The client MUST send all LLQ requests, refreshes, and acknowledgments The client <bcp14>MUST</bcp14> send all LLQ requests, refreshes, and
to the name server specified in the SRV target, at the address acknowledgments to the name server specified in the SRV target, at the
contained in the address record for that target. Note that the address contained in the address record for that target. Note that the
queries described in this section (including those for SOA and SRV queries described in this section (including those for SOA and SRV records)
records) MAY be sent to an intermediate DNS recursive resolver -- they need n <bcp14>MAY</bcp14> be sent to an intermediate DNS recursive resolver --
ot be they
sent directly to the name server. need not be sent directly to the name server.
</t> </t>
<t> <t>
If, on issuing the SRV query, the client receives an NXDOMAIN If, on issuing the SRV query, the client receives a negative
response indicating that the SRV record does not exist, the client response indicating that the SRV record does not exist, the client
SHOULD conclude that the server does not support an LLQ in the <bcp14>SHOULD</bcp14> conclude that the zone does not support LLQ.
requested zone. The client then SHOULD NOT send an LLQ request for The client then <bcp14>SHOULD NOT</bcp14> send an LLQ request for
the desired name, instead utilizing the behavior for LLQ-unaware the desired name, instead utilizing the behavior for LLQ-unaware
servers described in Section 5 "LLQ Setup". servers described in <xref target="llq-setup"/>, "<xref target="llq-setup"
</t> format="title"/>".
<?rfc needLines="20" ?> </t>
<t>
</t> <t>
<t>
Servers should send all messages to the source address and port of Servers should send all messages to the source address and port of
the LLQ setup message received from the client. the LLQ setup message received from the client.
</t> </t>
<?rfc needLines="40" ?> </section>
</section> <section numbered="true" toc="default" anchor="llq-setup">
<name>LLQ Setup</name>
<section title="LLQ Setup"> <t>
<t> An LLQ is initiated by a client and is completed via a four-way
An LLQ is initiated by a client, and is completed via a four-way
handshake. This handshake provides resilience to packet loss, handshake. This handshake provides resilience to packet loss,
demonstrates client reachability, and reduces denial of service demonstrates client reachability, and reduces denial-of-service
attack opportunities (see Section 8 "Security Considerations"). attack opportunities (see <xref target="security-considerations"/>, "<xref
</t> target="security-considerations" format="title"/>").
<section title="Setup Message Retransmission"> </t>
<t> <section numbered="true" toc="default"
LLQ Setup Requests and Responses sent by the client SHOULD be anchor="setup-message-retransmission">
retransmitted if no acknowledgments are received. The client SHOULD <name>Setup Message Retransmission</name>
re&nbhy;try up to two more times (for a total of 3 attempts) before <t>
considering the server down or unreachable. The client MUST wait at LLQ Setup Requests and Responses sent by the client <bcp14>SHOULD</bcp14>
be
retransmitted if no acknowledgments are received. The client
<bcp14>SHOULD</bcp14>
retry up to two more times (for a total of 3 attempts) before
considering the server down or unreachable. The client <bcp14>MUST</bcp14>
wait at
least 2 seconds before the first retransmission and 4 seconds between least 2 seconds before the first retransmission and 4 seconds between
the first and second retransmissions. The client SHOULD listen for a the first and second retransmissions. The client <bcp14>SHOULD</bcp14>
listen for a
response for at least 8 seconds after the 3rd attempt before response for at least 8 seconds after the 3rd attempt before
considering the server down or unreachable. Upon determining a considering the server down or unreachable. Upon determining a
server to be down, a client MAY periodically attempt to re-initiate server to be down, a client <bcp14>MAY</bcp14> periodically attempt to
an LLQ setup, at a rate of not more than once per hour. re-initiate
</t> an LLQ setup at a rate of not more than once per hour.
</t>
<t> <t>
Servers MUST NOT re-transmit acknowledgments that do not generate Servers <bcp14>MUST NOT</bcp14> retransmit acknowledgments that do not
responses from the client. Retransmission in setup is client-driven, generate
responses from the client. Retransmission in setup is client driven,
freeing servers from maintaining timers for incomplete LLQ setups. If freeing servers from maintaining timers for incomplete LLQ setups. If
servers receive duplicate messages from clients (perhaps due to the servers receive duplicate messages from clients (perhaps due to the
loss of the server's responses mid-flight), the server MUST re&nbhy;send loss of the server's responses mid-flight), the server <bcp14>MUST</bcp14>
its reply (possibly modifying the LEASE&nbhy;LIFE as described in Section resend
5.2.4 "ACK + Answers"). its reply (possibly modifying the LLQ&nbhy;LEASE as described in <xref
</t> target="ack-answers"/>, "<xref
target="ack-answers" format="title"/>").
<t> </t>
Servers MUST NOT garbage collect LLQs that fail to complete the four- <t>
way handshake until the initially granted LEASE&nbhy;LIFE has elapsed. Servers <bcp14>MUST NOT</bcp14> garbage collect LLQs that fail to complete
</t> the four-way handshake until the initially granted LLQ&nbhy;LEASE has
</section> elapsed.
<section title="LLQ Setup Four-Way Handshake"> </t>
<figure><artwork> </section>
The four phases of the handshake include:
1) Setup Request client to server, identifies LLQ(s) requested
2) Setup Challenge server to client, provides error(s) for <section numbered="true" toc="default" anchor="four-way-handshake">
requested LLQs, and unique identifiers for <name>LLQ Setup Four-Way Handshake</name>
the successful requests <t>The four phases of the handshake include:
</t>
3) Challenge Response client to server, echoes identifier(s), <ul empty="true">
demonstrating client's reachability and <li>
willingness to participate <dl indent="24">
<dt>1) Setup Request
</dt>
<dd>client to server, identifies LLQ(s) requested
</dd>
<dt>2) Setup Challenge
</dt>
<dd>server to client, provides
unique identifiers for successful requested LLQs, and
error(s) for unsuccessful requested LLQs.
</dd>
<dt>3) Challenge Response
</dt>
<dd>client to server, echoes identifier(s), demonstrating client's
reachability and willingness to participate
</dd>
<dt>4) ACK + Answers
</dt>
<dd>server to client, confirms setup and provides initial answers
</dd>
</dl>
</li>
</ul>
4) ACK + Answers server to client, confirms setup and <section numbered="true" toc="default" anchor="setup-request">
provides initial answers <name>Setup Request</name>
</artwork></figure> <t>
<section title="Setup Request"> A request for an LLQ is formatted like a standard DNS query but with
<t> an OPT pseudo&nbhy;RR containing LLQ metadata in its Additional
A request for an LLQ is formatted like a standard DNS query, but with section. LLQ
an OPT RR containing LLQ metadata in its Additional section. LLQ Setup Requests are identified by the LLQ&nbhy;SETUP opcode and a
setup requests are identified by the LLQ&nbhy;SETUP opcode and a
zero&nbhy;valued LLQ&nbhy;ID. zero&nbhy;valued LLQ&nbhy;ID.
</t> </t>
<t>
<t> The request <bcp14>MAY</bcp14> contain multiple questions to set up
The request MAY contain multiple questions to set up multiple LLQs. multiple LLQs.
A request consisting of multiple questions MUST contain multiple LLQ A Setup Request consisting of multiple questions <bcp14>MUST</bcp14>
metadata sections, one per question, with metadata sections in the contain multiple LLQ
OPTIONS, one per question, with the LLQ OPTIONS in the
same order as the questions they correspond to (i.e., the first same order as the questions they correspond to (i.e., the first
metadata section corresponds to the first question, the second LLQ OPTION corresponds to the first question, the second
metadata section corresponds to the second question, etc.) If LLQ OPTION corresponds to the second question, etc.). If
requesting multiple LLQs, clients SHOULD request the same LEASE&nbhy;LIFE requesting multiple LLQs, clients <bcp14>SHOULD</bcp14> request the same
for each LLQ. Requests over UDP MUST NOT contain multiple questions LLQ&nbhy;LEASE
if doing so would cause the message to not fit in a single packet. for each LLQ. Requests over UDP <bcp14>MUST NOT</bcp14> contain multiple
</t> questions
if doing so would cause the message to exceed a single IP packet.
<t> </t>
A client MUST NOT request multiple identical LLQs (i.e., containing <t>
A client <bcp14>MUST NOT</bcp14> request multiple identical LLQs (i.e.,
containing
the same qname/type/class) from the same source IP address and port. the same qname/type/class) from the same source IP address and port.
This requirement is to avoid unnecessary load on servers. This requirement is to avoid unnecessary load on servers.
In the case of multiple independent client implementations that In the case of multiple independent client implementations that
may run on the same device without knowledge of each other, may run on the same device without knowledge of each other,
it is allowable if they by chance send LLQ requests for the same it is allowable if they by chance send LLQ requests for the same
qname/type/class. These independent implementations on the same qname/type/class. These independent implementations on the same
client will be using different source ports. Likewise, client will be using different source ports. Likewise,
to the server, to the server,
multiple independent clients behind the same NAT gateway multiple independent clients behind the same NAT gateway
will appear as if they were will appear as if they were
multiple independent clients using different ports on the same host. multiple independent clients using different ports on the same host,
and this is also allowable.
</t>
<t> </t>
The query MUST NOT be for record type ANY (255), class ANY (255), or <t>
The query <bcp14>MUST NOT</bcp14> be for record type ANY (255), class ANY
(255), or
class NONE (0). class NONE (0).
</t> </t>
<t>
Setup Request OPT&nbhy;RR LLQ Metadata Format:
</t>
<figure><artwork>
Field Name Field Type Description
OPTION-CODE u_int16_t LLQ (1)
OPTION-LENGTH u_int16_t Length of following fields (18)
VERSION u_int16_t Version of LLQ protocol implemented
by requester (1)
LLQ-OPCODE u_int16_t LLQ-SETUP (1)
ERROR-CODE u_int16_t NOERROR (0)
LLQ-ID u_int64_t 0
LEASE-LIFE u_int32_t Desired life of LLQ request
These fields MUST be repeated once for each additional query in the <table anchor="OPT-RR-LLQ">
<name>Setup Request LLQ OPTION Format</name>
<thead>
<tr>
<th>Field Name</th>
<th>Field Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>OPTION-CODE</td>
<td>u_int16_t</td>
<td>LLQ (1)</td>
</tr>
<tr>
<td>OPTION-LENGTH</td>
<td>u_int16_t</td>
<td>Length of following fields (18)</td>
</tr>
<tr>
<td>LLQ-VERSION</td>
<td>u_int16_t</td>
<td>Version of LLQ protocol implemented by requester (1)</td>
</tr>
<tr>
<td>LLQ-OPCODE</td>
<td>u_int16_t</td>
<td>LLQ-SETUP (1)</td>
</tr>
<tr>
<td>LLQ-ERROR</td>
<td>u_int16_t</td>
<td>NO-ERROR (0)</td>
</tr>
<tr>
<td>LLQ-ID</td>
<td>u_int64_t</td>
<td>0</td>
</tr>
<tr>
<td>LLQ-LEASE</td>
<td>u_int32_t</td>
<td>Desired life of LLQ request</td>
</tr>
</tbody>
</table>
<t>The Setup Request LLQ OPTION <bcp14>MUST</bcp14> be repeated once for each
additional query in the
Question section. Question section.
</artwork></figure> </t>
<?rfc needLines="40" ?>
</section>
<section title="Setup Challenge"> </section>
<t> <section numbered="true" toc="default" anchor="setup-challenge">
<name>Setup Challenge</name>
<t>
Upon receiving an LLQ Setup Request, a server implementing LLQs will Upon receiving an LLQ Setup Request, a server implementing LLQs will
send a Setup Challenge to the requester (client). An LLQ Setup send a Setup Challenge to the requester (client). An LLQ Setup
Challenge is a DNS Response, with the DNS message ID matching that of Challenge is a DNS response, with the DNS message ID matching that of
the request, and with all questions contained in the request present the Setup Request, and with all questions contained in the Setup Request
present
in the Question section of the response. Additionally, the in the Question section of the response. Additionally, the
challenge contains a single OPT&nbhy;RR with an LLQ metadata section for challenge contains a single OPT pseudo&nbhy;RR with an LLQ OPTION for
each LLQ request, indicating the success or failure of each request. each LLQ request, indicating the success or failure of each request.
Metadata sections MUST be in the same order as the questions they The LLQ OPTIONS <bcp14>MUST</bcp14> be in the same order as the questions
correspond to. Note that in a request containing multiple they
questions some LLQs may succeed, while others may fail. correspond to. Note that in a Setup Request containing multiple
</t> questions, some LLQs may succeed while others may fail.
</t>
<t> <table anchor="CHALLENGE-OPT-RR-DATA">
Setup Challenge OPT&nbhy;RR RDATA Format: <name>Setup Challenge LLQ OPTION Format</name>
</t> <thead>
<tr>
<th>Field Name</th>
<th>Field Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>OPTION-CODE</td>
<td>u_int16_t</td>
<td>LLQ (1)</td>
</tr>
<tr>
<td>OPTION-LENGTH</td>
<td>u_int16_t</td>
<td>Length of following fields (18)</td>
</tr>
<tr>
<td>LLQ-VERSION</td>
<td>u_int16_t</td>
<td>Version of LLQ protocol implemented in server (1)</td>
</tr>
<tr>
<td>LLQ-OPCODE</td>
<td>u_int16_t</td>
<td>LLQ-SETUP (1)</td>
</tr>
<tr>
<td>LLQ-ERROR</td>
<td>u_int16_t</td>
<td>[As Appropriate]</td>
</tr>
<tr>
<td>LLQ-ID</td>
<td>u_int64_t</td>
<td>[As Appropriate]</td>
</tr>
<tr>
<td>LLQ-LEASE</td>
<td>u_int32_t</td>
<td>[As Appropriate]</td>
</tr>
</tbody>
</table>
<figure><artwork> <t>
Field Name Field Type Description The Setup Challenge LLQ OPTION <bcp14>MUST</bcp14> be repeated once for
OPTION-CODE u_int16_t LLQ (1) each query in the Questions
OPTION-LENGTH u_int16_t Length of following fields (18) section of the Setup Challenge.
VERSION u_int16_t Version of LLQ protocol implemented Further details for LLQ&nbhy;ERROR, LLQ&nbhy;ID and LLQ&nbhy;LEASE are
in server (1) given below.
LLQ-OPCODE u_int16_t LLQ-SETUP (1) </t>
ERROR-CODE u_int16_t [As Appropriate]
LLQ-ID u_int64_t [As Appropriate]
LEASE-LIFE u_int32_t [As Appropriate]
</artwork></figure>
<t> <t>
These fields MUST be repeated once for each query in the Questions LLQ&nbhy;ERROR:
section of the Setup Request. </t>
</t>
<?rfc needLines="40" ?> <ul empty="true">
<t> <li>
LLQ Metadata field descriptions: <dl indent="18">
</t> <dt>NO-ERROR:
</dt>
<dd>The LLQ Setup Request was successful.
</dd>
<dt>FORMAT-ERR:
</dt>
<dd>The LLQ was improperly formatted. Note that if the rest of the DNS
message is properly formatted, the DNS header error code <bcp14>MUST
NOT</bcp14> include a format error code, since to do so would cause ambiguity
between the case where a client sends a valid LLQ Setup Request to a server
that does not understand LLQ and the case where a client sends a malformed
LLQ Setup Request to a server that does understand LLQ.
</dd>
<figure><artwork> <dt>SERV-FULL:
ERROR-CODE: Possible values include: </dt>
<dd>The server cannot grant the LLQ request because it is overloaded or the
request exceeds the server's rate limit (see <xref
target="security-considerations"/>, <xref target="security-considerations"
format="title"/>). Upon
returning this error, the server <bcp14>MUST</bcp14> include in the LLQ-LEASE
field a time interval, in seconds, after which the client may retry the LLQ
Setup.
</dd>
NO-ERROR: The LLQ Setup Request was successful. <dt>STATIC:
</dt>
<dd>The data for this name and type is not expected to change frequently, and
the server, therefore, does not support the requested LLQ. The client
<bcp14>MUST</bcp14> honor the resource record TTLs returned and
<bcp14>MUST NOT</bcp14> poll sooner than indicated by those TTLs,
nor should it retry the LLQ Setup for this name and type.
</dd>
FORMAT-ERR: The LLQ was improperly formatted. Note that if the <dt>BAD-VERS:
rest of the DNS message is properly formatted, the </dt>
DNS header error code MUST NOT include a format error <dd>The protocol version specified in the client's Setup Request is not
code, as this would cause confusion between a server supported by
that does not understand the LLQ format, and a client the server.
that sends malformed LLQs. </dd>
SERV-FULL: The server cannot grant the LLQ request because it is <dt>UNKNOWN-ERR:
overloaded, or the request exceeds the server's rate </dt>
limit (see Section 8 "Security Considerations"). <dd>The LLQ was not granted for some other reason not covered by the preceding
Upon returning this error, the server MUST include error code values.
in the LEASE-LIFE field a time interval, in seconds, </dd>
after which the client may re-try the LLQ Setup.
STATIC: The data for this name and type is not expected to </dl>
change frequently, and the server therefore does not
support the requested LLQ. The client MUST NOT poll
for this name and type, nor should it re-try the LLQ
Setup, and should instead honor the normal resource
record TTLs returned.
BAD-VERS: The protocol version specified in the client's </li>
request is not supported by the server. </ul>
UNKNOWN-ERR: The LLQ was not granted for an unknown reason <dl indent="18">
</artwork></figure> <dt>LLQ&nbhy;ID:
</dt>
<dd>On success, a random number generated by the server that is unique on the
server for the
requested name/type/class. The LLQ&nbhy;ID <bcp14>SHOULD</bcp14> be an
unpredictable random number. A possible method of allocating LLQ&nbhy;IDs with
minimal bookkeeping would be to store the time, in seconds since the Epoch, in
the high 32 bits of the field, and a cryptographically generated 32-bit random
integer in the low 32 bits.
</dd>
<?rfc needLines="40" ?> <dt>
<t> </dt>
LLQ&nbhy;ID: On success, a random number generated by the server that is <dd>
unique for the requested name/type/class. The LLQ&nbhy;ID SHOULD be an On error, the LLQ&nbhy;ID is set to 0.
unpredictable random number. A possible method of allocating LLQ&nbhy;IDs </dd>
with minimal bookkeeping would be to store the time, in seconds since
the Epoch, in the high 32 bits of the field, and a cryptographically
generated 32-bit random integer in the low 32 bits.
</t>
<t> <dt>LLQ&nbhy;LEASE:
On error, the LLQ&nbhy;ID is set to 0. </dt>
</t>
<t> <dd>On success, the actual life of the LLQ, in seconds. Value may be greater
LEASE&nbhy;LIFE: On success, the actual life of the LLQ, in seconds. than, less than, or equal to the value requested by the client, as per the
Value may be greater than, less than, or equal to the value requested server administrator's policy. The server <bcp14>MAY</bcp14> discard the LLQ
by the client, as per the server administrator's policy. The server after this LLQ&nbhy;LEASE expires unless the LLQ has been renewed by the
MAY discard the LLQ after this LEASE&nbhy;LIFE expires unless the LLQ has client (see <xref target="LLQ-LLE"/>, "<xref target="LLQ-LLE"
been renewed by the client (see Section 7 "LLQ Lease-Life Expiration"). format="title"/>"). The server <bcp14>MUST NOT</bcp14> generate events (see
The server MUST NOT generate events (see Section 6 "Event Responses") <xref target="event-responses"/>, "<xref target="event-responses"
for expired LLQs. format="title"/>") for expired LLQs.
</t> </dd>
<t> <dt></dt>
On SERV&nbhy;FULL error, LEASE&nbhy;LIFE MUST be set to a time interval, in <dd>
seconds, after which the client may re&nbhy;try the LLQ Setup. On SERV&nbhy;FULL error, LLQ&nbhy;LEASE <bcp14>MUST</bcp14> be set to a time
</t> interval, in seconds, after which the client may retry the LLQ Setup.
</dd>
<dt>
</dt>
<dd>
On other errors, the LLQ&nbhy;LEASE <bcp14>MUST</bcp14> be set to 0.
</dd>
<t> </dl>
On other errors, the LEASE&nbhy;LIFE MUST be set to 0.
</t>
<?rfc needLines="40" ?>
</section>
<section title="Challenge Response"> </section>
<t> <section numbered="true" toc="default" anchor="challenge-response">
<name>Challenge Response</name>
<t>
Upon issuing a Setup Request, a client listens for a Setup Challenge Upon issuing a Setup Request, a client listens for a Setup Challenge
(5.2.2), re-transmitting the request as necessary (5.1). After (<xref target="setup-challenge"/>) retransmitting the Setup Request as
receiving a successful Challenge, the client SHOULD send a Challenge necessary
(<xref target="setup-message-retransmission"/>). After
receiving a successful Setup Challenge, the client <bcp14>SHOULD</bcp14>
send a Challenge
Response to the server. This Challenge Response is a DNS request Response to the server. This Challenge Response is a DNS request
with questions from the request and challenge, and a single OPT&nbhy;RR in with questions as in the Setup Request and Setup Challenge, and a single
the Additional section, with the OPT&nbhy;RR RDATA identical to the OPT pseudo&nbhy;RR in
OPT&nbhy;RR RDATA contained in the Setup Challenge (i.e., echoing, for the Additional section, with the LLQ OPTIONS corresponding to the
each set of fields, the random LLQ&nbhy;ID and the granted lease life). If LLQ OPTIONS contained in the Setup Challenge (i.e., echoing, for
the challenge response contains multiple questions, the first each LLQ OPTION, the random LLQ&nbhy;ID and the granted LLQ&nbhy;LEASE). If
question MUST correspond to the first OPT&nbhy;RR RDATA tuple, etc. the Challenge Response contains multiple questions, the first
</t> question <bcp14>MUST</bcp14> correspond to the first LLQ OPTION, etc.
</t>
<t> <t>
If the Setup Request fails with a STATIC error, the client MUST NOT If the Setup Request for a particular LLQ fails with a STATIC error, the
poll the server. The client SHOULD honor the resource record TTLs client <bcp14>MUST NOT</bcp14>
poll the server for that LLQ. The client <bcp14>SHOULD</bcp14> honor the
resource record TTLs
contained in the response. contained in the response.
</t> </t>
<t>
<t> If a Setup Request fails with a SERV&nbhy;FULL error, the client
If the Setup Request fails with a SERV&nbhy;FULL error, the client MAY <bcp14>MAY</bcp14>
re&nbhy;try the LLQ Setup Request (5.2.1) after the time indicated in the retry the LLQ Setup Request (<xref target="setup-request"/>) after the time
LEASE&nbhy;LIFE field. indicated in the
</t> LLQ&nbhy;LEASE field.
</t>
<t> <t>
If the Setup Request fails with an error other than STATIC or If the Setup Request fails with an error other than STATIC or
SERV&nbhy;FULL, or the server is determined not to support LLQ SERV&nbhy;FULL, or the server is determined not to support LLQ
(i.e., the client receives a DNS response with a nonzero RCODE, (i.e., the client receives a DNS response with a nonzero RCODE,
or a DNS response containing no LLQ option), the or a DNS response containing no LLQ option), the
client MAY poll the server periodically with standard DNS queries, client <bcp14>MAY</bcp14> poll the server periodically with standard DNS
inferring Add and Remove events (see Section 6 "Event Responses") queries,
inferring Add and Remove Events (see <xref target="event-responses"/>,
"Event Responses")
by comparing answers to these queries. The client by comparing answers to these queries. The client
SHOULD NOT poll more than once every 15 minutes for a given query. <bcp14>SHOULD NOT</bcp14> poll more than once every 15 minutes for a given
The client MUST NOT poll if it receives a STATIC error code in the query.
The client <bcp14>MUST NOT</bcp14> poll if it receives a STATIC error code
in the
acknowledgment. acknowledgment.
</t> </t>
<?rfc needLines="40" ?> </section>
</section> <section numbered="true" toc="default" anchor="ack-answers">
<name>ACK + Answers</name>
<section title="ACK + Answers"> <t>
<t>
Upon receiving a correct Challenge Response, a server MUST return an Upon receiving a correct Challenge Response, a server <bcp14>MUST</bcp14>
return an
acknowledgment, completing the LLQ setup, and provide all current acknowledgment, completing the LLQ setup, and provide all current
answers to the question(s). answers to the question(s).
</t> </t>
<t>
<t>
To acknowledge a successful Challenge Response, i.e., a Challenge To acknowledge a successful Challenge Response, i.e., a Challenge
Response in which the LLQ&nbhy;ID and LEASE&nbhy;LIFE echoed by the client Response in which the LLQ&nbhy;ID and LLQ&nbhy;LEASE echoed by the client
match the values issued by the server, the server MUST send a DNS match the values issued by the server, the server <bcp14>MUST</bcp14> send
a DNS
response containing all available answers to the question(s) response containing all available answers to the question(s)
contained in the original Setup Request, along with all additional contained in the original Setup Request, along with all additional
resource records appropriate for those answers in the Additional resource records appropriate for those answers in the Additional
section. The Additional section also contains an OPT&nbhy;RR formatted as section. The Additional section also contains LLQ OPTIONS formatted as
follows: follows:
</t> </t>
<t>
Successful ACK + Answers OPT&nbhy;RR RDATA Format:
</t>
<figure><artwork> <table anchor="SUCCESSFUL-ACK-ANSWERS-OPT-RR-RDATA">
Field Name Field Type Description <name>Successful ACK + Answers LLQ OPTION Format</name>
OPTION-CODE u_int16_t LLQ <thead>
OPTION-LENGTH u_int16_t Length of following fields, as <tr>
appropriate <th>Field Name</th>
VERSION u_int16_t Version of LLQ protocol implemented <th>Field Type</th>
in server <th>Description</th>
LLQ-OPCODE u_int16_t LLQ-SETUP (1) </tr>
ERROR-CODE u_int16_t NO-ERROR </thead>
LLQ-ID u_int64_t Originally granted ID, echoed in <tbody>
client's Response <tr>
LEASE-LIFE u_int32_t Remaining life of LLQ, in seconds <td>OPTION-CODE</td>
</artwork></figure> <td>u_int16_t</td>
<td>LLQ (1)</td>
</tr>
<tr>
<td>OPTION-LENGTH</td>
<td>u_int16_t</td>
<td>Length of following fields (18)</td>
</tr>
<tr>
<td>LLQ-VERSION</td>
<td>u_int16_t</td>
<td>Version of LLQ protocol implemented in server (1)</td>
</tr>
<tr>
<td>LLQ-OPCODE</td>
<td>u_int16_t</td>
<td>LLQ-SETUP (1)</td>
</tr>
<tr>
<td>LLQ-ERROR</td>
<td>u_int16_t</td>
<td>NO-ERROR (0)</td>
</tr>
<tr>
<td>LLQ-ID</td>
<td>u_int64_t</td>
<td>Originally granted ID, echoed in client's Response</td>
</tr>
<tr>
<td>LLQ-LEASE</td>
<td>u_int32_t</td>
<td>Remaining life of LLQ, in seconds</td>
</tr>
</tbody>
</table>
<t> <t>
If there is a significant delay in receiving a Challenge Response, or If there is a significant delay in receiving a Challenge Response, or
multiple Challenge Responses are issued (possibly because they were lost multiple Challenge Responses are issued (possibly because they were lost
en route to the client, causing the client to re&nbhy;send the Challenge en route to the client, causing the client to resend the Challenge
Response), the server MAY decrement the LEASE&nbhy;LIFE by the time Response), the server <bcp14>MAY</bcp14> decrement the LLQ&nbhy;LEASE by
the time
elapsed since the Setup Challenge was initially issued. elapsed since the Setup Challenge was initially issued.
</t> </t>
<t>
<t>
If the setup is completed over UDP and all initially available If the setup is completed over UDP and all initially available
answers to the question(s), additional records, and the OPT&nbhy;RR do not answers to the question(s), additional records, and the OPT pseudo&nbhy;RR
fit in a single packet, some or all additional records (excluding the do not
OPT&nbhy;RR) MUST be omitted. If, after omission of all additional fit in a single IP packet, some or all additional records (excluding the
OPT pseudo&nbhy;RR) <bcp14>MUST</bcp14> be omitted. If, after omission of
all additional
records, the answers still do not fit in a single message, answers records, the answers still do not fit in a single message, answers
MUST be removed until the message fits in a single packet. These <bcp14>MUST</bcp14> be removed until the message fits in a single IP
answers not delivered in the ACK + Answers MUST be delivered packet. These
without undue delay to the client via Add Events (Section 6 "Event Responses" answers not delivered in the ACK + Answers <bcp14>MUST</bcp14> be delivered
). without undue delay to the client via Add Events (<xref
</t> target="event-responses"/>, "<xref
</section> target="event-responses" format="title"/>").
</section> </t>
<section title="Resource Record TTLs"> </section>
<t> </section>
<section numbered="true" toc="default" anchor="resource-record-ttls">
<name>Resource Record TTLs</name>
<t>
The TTLs of resource records contained in answers to successful LLQs The TTLs of resource records contained in answers to successful LLQs
SHOULD be ignored by the client. The client MAY cache LLQ answers <bcp14>SHOULD</bcp14> be ignored by the client. The client
until the client receives a gratuitous announcement (see Section 6 <bcp14>MAY</bcp14> cache LLQ answers until the client receives a gratuitous
"Event Responses") indicating that the answer to the LLQ has changed. announcement (see <xref target="event-responses"/>, "<xref
The client SHOULD NOT cache answers after the LLQs LEASE&nbhy;LIFE expires target="event-responses" format="title"/>")
without being refreshed (see Section 7 "LLQ Lease-Life Expiration"). indicating that the answer to the LLQ has changed. The client
If an LLQ request fails, the client SHOULD NOT cache answers for a <bcp14>SHOULD NOT</bcp14> cache answers after the LLQs LLQ&nbhy;LEASE
period longer than the client's polling interval. expires without being refreshed (see <xref target="LLQ-LLE"/>, "LLQ
</t> Lease-Life Expiration"). If an LLQ request fails, the client <bcp14>SHOULD
NOT</bcp14> cache answers for a period longer than the client's polling
<t> interval.
</t>
<t>
Note that resource records intended specifically to be transmitted Note that resource records intended specifically to be transmitted
via LLQs (e.g., DNS Service Discovery resource records) may have via LLQs (e.g., DNS-based Service Discovery resource records) may have
unusually short TTLs. This is because it is assumed that the records unusually short TTLs. This is because it is assumed that the records
may change frequently, and that a client's cache coherence will be may change frequently, and that a client's cache coherence will be
maintained via the LLQ and gratuitous responses. Short TTLs prevent maintained via the LLQ and gratuitous responses. Short TTLs prevent
stale information from residing in intermediate DNS recursive resolvers that stale information from residing in intermediate DNS recursive resolvers
are that are
not LLQ-aware. not LLQ aware.
</t> </t>
<t>
<t>
TTLs of resource records included in the Additional section of an TTLs of resource records included in the Additional section of an
LLQ response (which do not directly answer the LLQ) SHOULD be honored LLQ response (which do not directly answer the LLQ) <bcp14>SHOULD</bcp14>
be honored
by the client. by the client.
</t> </t>
<?rfc needLines="40" ?> </section>
</section> </section>
</section> <section numbered="true" toc="default" anchor="event-responses">
<name>Event Responses</name>
<section title="Event Responses"> <t>
<t>
When a change ("event") occurs to a name server's zone, the server When a change ("event") occurs to a name server's zone, the server
MUST check if the new or deleted resource records answer any LLQs. <bcp14>MUST</bcp14> check if the new or deleted resource records answer any
If so, the changes MUST be communicated to the LLQ requesters in LLQs.
If so, the changes <bcp14>MUST</bcp14> be communicated to the LLQ
requesters in
the form of a gratuitous DNS response sent to the client, with the the form of a gratuitous DNS response sent to the client, with the
question(s) being answered in the Question section, and answers to relevant question(s) in the Question section, and the corresponding answers
these questions in the Answer section. The response also includes in the Answer section. The response also includes
an OPT RR in the Additional section. This OPT RR contains, in its an OPT pseudo&nbhy;RR in the Additional section. This OPT pseudo&nbhy;RR
RDATA, an entry for each LLQ being answered in the message. Entries contains, in its
RDATA, an LLQ OPTION for each LLQ being answered in the message. Each LLQ
OPTION
must include the LLQ&nbhy;ID. This reduces the potential for spoof events must include the LLQ&nbhy;ID. This reduces the potential for spoof events
being sent to a client. being sent to a client.
</t> </t>
<t> <table anchor="EVENT-RESPONSE-OPT-RR-RDATA">
Event Response OPT&nbhy;RR RDATA Format: <name>Event Response LLQ OPTION Format</name>
</t> <thead>
<tr>
<th>Field Name</th>
<th>Field Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>OPTION-CODE</td>
<td>u_int16_t</td>
<td>LLQ (1)</td>
</tr>
<tr>
<td>OPTION-LENGTH</td>
<td>u_int16_t</td>
<td>Length of following fields (18)</td>
</tr>
<tr>
<td>LLQ-VERSION</td>
<td>u_int16_t</td>
<td>Version of LLQ protocol implemented in server (1)</td>
</tr>
<tr>
<td>LLQ-OPCODE</td>
<td>u_int16_t</td>
<td>LLQ-EVENT (3)</td>
</tr>
<tr>
<td>LLQ-ERROR</td>
<td>u_int16_t</td>
<td>NO-ERROR (0)</td>
</tr>
<tr>
<td>LLQ-ID</td>
<td>u_int64_t</td>
<td>[As Appropriate]</td>
</tr>
<tr>
<td>LLQ-LEASE</td>
<td>u_int32_t</td>
<td>0</td>
</tr>
<figure><artwork> </tbody>
Field Name Field Type Description </table>
OPTION-CODE u_int16_t LLQ (1)
OPTION-LENGTH u_int16_t Length of following fields (18)
VERSION u_int16_t Version of LLQ protocol implemented
in server (1)
LLQ-OPCODE u_int16_t LLQ-EVENT (3)
ERROR-CODE u_int16_t 0
LLQ-ID u_int64_t [As Appropriate]
LEASE-LIFE u_int32_t 0
</artwork></figure>
<t> <t>
Gratuitous responses for a single LLQ MAY be batched, such that Gratuitous responses for a single LLQ <bcp14>MAY</bcp14> be batched such
that
multiple changes are communicated in a single message. multiple changes are communicated in a single message.
Responses MUST NOT be batched if this would cause a message that Responses <bcp14>MUST NOT</bcp14> be batched if this would cause a message
would otherwise fit in a single packet to be truncated. While that
responses MAY be deferred to provide opportunities for batching, would otherwise fit in a single IP packet to be truncated. While
responses SHOULD NOT be delayed, for purposes of batching, for more responses <bcp14>MAY</bcp14> be deferred to provide opportunities for
batching,
responses <bcp14>SHOULD NOT</bcp14> be delayed, for purposes of batching,
for more
than 30 seconds, as this would cause an unacceptable latency for the than 30 seconds, as this would cause an unacceptable latency for the
client. client.
</t> </t>
<t>
<t> After sending a gratuitous response, the server <bcp14>MUST</bcp14> listen
After sending a gratuitous response, the server MUST listen for an for an
acknowledgment from the client. If the client does not respond, the acknowledgment from the client. If the client does not respond, the
server MUST re&nbhy;send the response. The server MUST re&nbhy;send 2 times server <bcp14>MUST</bcp14> resend the response. The server
(for a total of 3 transmissions), after which the server MUST <bcp14>MUST</bcp14> resend two times
(for a total of 3 transmissions), after which the server
<bcp14>MUST</bcp14>
consider the client to be unreachable and delete its LLQ. The server consider the client to be unreachable and delete its LLQ. The server
MUST listen for 2 seconds before re&nbhy;sending the response, 4 more <bcp14>MUST</bcp14> listen for 2 seconds before resending the response, 4
seconds before re&nbhy;sending again, and must wait an additional 8 more
seconds before resending again, and must wait an additional 8
seconds after the 3rd transmission before terminating the LLQ. seconds after the 3rd transmission before terminating the LLQ.
</t> </t>
<t>
<t> The DNS message header of the response <bcp14>SHOULD</bcp14> include an
The DNS message header of the response SHOULD include an unpredictable unpredictable
random number in the DNS message ID field, which is to be echoed in random number in the DNS message ID field, which is to be echoed in
the client's acknowledgement. the client's acknowledgment.
</t> </t>
<section title="Add Events"> <section numbered="true" toc="default">
<t> <name>Add Events</name>
Add events occur when a new resource record appears, usually as the <t>
result of a dynamic update <xref target="RFC2136"/>, that answers an LLQ. Thi Add Events occur when a new resource record appears, usually as the
s result of a dynamic update <xref target="RFC2136" format="default"/>, that
answers an LLQ. This
record must be sent in the Answer section of the event to the client. record must be sent in the Answer section of the event to the client.
Records that normally accompany this record in responses MAY be Records that normally accompany this record in responses <bcp14>MAY</bcp14>
included in the Additional section, as per truncation restrictions be
included in the Additional section as per truncation restrictions
described above. described above.
</t> </t>
</section> </section>
<section title="Remove Events"> <section numbered="true" toc="default">
<t> <name>Remove Events</name>
Remove events occur when a resource record previously sent to a <t>
client, either in an initial response, or in an Add Event, becomes Remove Events occur when a resource record previously sent to a
client, either in an initial response or in an Add Event, becomes
invalid (normally as a result of being removed via a dynamic update). invalid (normally as a result of being removed via a dynamic update).
The deleted resource record is sent in the Answer section of the The deleted resource record is sent in the Answer section of the
event to the client. The resource record TTL is set to -1, event to the client. The resource record TTL is set to -1,
indicating that the record has been removed. indicating that the record has been removed.
</t> </t>
</section> </section>
<section title="Gratuitous Response Acknowledgments"> <section numbered="true" toc="default">
<t> <name>Gratuitous Response Acknowledgments</name>
Upon receiving a gratuitous response ("event"), the client MUST send <t>
Upon receiving a gratuitous response ("event"), the client
<bcp14>MUST</bcp14> send
an acknowledgment to the server. This acknowledgment is a DNS an acknowledgment to the server. This acknowledgment is a DNS
response echoing the OPT&nbhy;RR contained in the event, with the message response echoing the OPT pseudo&nbhy;RR contained in the event, with the
message
ID of the gratuitous response echoed in the message header. The ID of the gratuitous response echoed in the message header. The
acknowledgment MUST be sent to the source IP address and port from acknowledgment <bcp14>MUST</bcp14> be sent to the source IP address and
port from
which the event originated. which the event originated.
</t> </t>
<?rfc needLines="40" ?> </section>
</section> </section>
</section> <section numbered="true" toc="default" anchor="LLQ-LLE">
<name>LLQ Lease-Life Expiration</name>
<section title="LLQ Lease-Life Expiration"> <section numbered="true" toc="default">
<t> <name>Refresh Request</name>
</t> <t>
<section title="Refresh Request"> If the client desires to maintain the LLQ beyond the duration specified in
<t> the LLQ&nbhy;LEASE field of the ACK + Answers (<xref
If the client desires to maintain the LLQ beyond the duration target="ack-answers"/>), the client <bcp14>MUST</bcp14> send a
specified in the LEASE&nbhy;LIFE field of the Ack + Answers Refresh Request. A Refresh Request is identical to an LLQ Challenge
(5.2), the client MUST send a Refresh Request. A Refresh Request is Response (<xref target="challenge-response"/>) but with the LLQ&nbhy;OPCODE
identical to an LLQ Challenge Response (5.3), but with the LLQ&nbhy;OPCODE set to
set to LLQ&nbhy;REFRESH. Unlike a Challenge Response, a Refresh Request LLQ&nbhy;REFRESH. Unlike a Challenge Response, a Refresh Request returns no
returns no answers. answers.
</t> </t>
<t> <t>
The client SHOULD refresh an LLQ when 80% of its lease life has The client <bcp14>SHOULD</bcp14> refresh an LLQ when 80% of its
LLQ&nbhy;LEASE has
elapsed. elapsed.
</t> </t>
<t>
<t>
As a means of reducing network traffic, when constructing refresh As a means of reducing network traffic, when constructing refresh
messages the client SHOULD include all LLQs established with a given messages the client <bcp14>SHOULD</bcp14> include all LLQs established with
a given
server, even those not yet close to expiration. However, at least server, even those not yet close to expiration. However, at least
one LLQ MUST have elapsed at least 80% of its original LEASE&nbhy;LIFE. one LLQ <bcp14>MUST</bcp14> have elapsed at least 80% of its original
The client MUST NOT include additional LLQs if doing so would cause LLQ&nbhy;LEASE.
the message to no longer fit in a single packet. In this case, the The client <bcp14>MUST NOT</bcp14> include additional LLQs if doing so
would cause
the message to no longer fit in a single IP packet. In this case, the
LLQs furthest from expiration should be omitted such that the message LLQs furthest from expiration should be omitted such that the message
fits in a single packet. (These LLQs SHOULD be refreshed in a fits in a single IP packet. (These LLQs <bcp14>SHOULD</bcp14> be refreshed
in a
separate message when 80% of one or more of their lease lives have separate message when 80% of one or more of their lease lives have
elapsed.) When refreshing multiple LLQs simultaneously, the message elapsed.) When refreshing multiple LLQs simultaneously, the message
contains multiple questions, and a single OPT&nbhy;RR with multiple LLQ contains multiple questions and a single OPT pseudo&nbhy;RR with multiple
metadata sections, one per question, with the metadata sections in LLQ
OPTIONS, one per question, with the LLQ OPTIONS in
the same order as the questions they correspond to. the same order as the questions they correspond to.
</t> </t>
<t>
<t> The client <bcp14>SHOULD</bcp14> specify the original LLQ&nbhy;LEASE
The client SHOULD specify the original lease life granted in the LLQ granted in the LLQ
response as the desired LEASE&nbhy;LIFE in the refresh request. If response as the desired LLQ&nbhy;LEASE in the Refresh Request. If
refreshing multiple LLQs simultaneously, the client SHOULD request refreshing multiple LLQs simultaneously, the client <bcp14>SHOULD</bcp14>
the same lease life for all LLQs being refreshed (with the exception request
of termination requests, see below). the same LLQ&nbhy;LEASE for all LLQs being refreshed (with the exception
</t> of termination requests; see below).
</t>
<t> <t>
To terminate an LLQ prior To terminate an LLQ prior
to its scheduled expiration (for instance, when the client terminates to its scheduled expiration (for instance, when the client terminates
a DNS Service Discovery browse operation, or a client is about to go a DNS-based Service Discovery browse operation or when a client is about to g
to sleep or shut down) the client specifies a lease life of 0. o
</t> to sleep or shut down), the client specifies an LLQ&nbhy;LEASE value of 0.
</t>
<t> <t>
The client MUST listen for an acknowledgment from the server. The The client <bcp14>MUST</bcp14> listen for an acknowledgment from the
client MAY re&nbhy;try up to two more times (for a total of 3 attempts) server. The
before considering the server down or unreachable. The client MUST client <bcp14>MAY</bcp14> retry up to two more times (for a total of 3
NOT re&nbhy;try a first time before 90% of the lease life has expired, and attempts)
MUST NOT re&nbhy;try again before 95% of the lease life has expired. If before considering the server down or unreachable. The client <bcp14>MUST
the server is determined to be down, the client MAY periodically NOT</bcp14> retry a first time before 90% of the LLQ&nbhy;LEASE has expired
and
<bcp14>MUST NOT</bcp14> retry again before 95% of the LLQ&nbhy;LEASE has
expired. If
the server is determined to be down, the client <bcp14>MAY</bcp14>
periodically
attempt to re-establish the LLQ via an LLQ Setup Request message. attempt to re-establish the LLQ via an LLQ Setup Request message.
The client MUST NOT attempt the LLQ Setup Request more than once per The client <bcp14>MUST NOT</bcp14> attempt the LLQ Setup Request more than
once per
hour. hour.
</t> </t>
</section> </section>
<section title="LLQ Refresh Acknowledgment"> <section numbered="true" toc="default">
<t> <name>LLQ Refresh Acknowledgment</name>
Upon receiving an LLQ Refresh message, a server MUST send an
acknowledgment of the Refresh. This acknowledgment is formatted like
the Setup ACK described in 5.2.3, but with the following variations:
</t>
<t> <t>
Upon receiving an LLQ Refresh message, a server <bcp14>MUST</bcp14> send an
acknowledgment of the Refresh. This acknowledgment is formatted like
the "ACK + Answers" message described in <xref target="ack-answers"/>, but
with the following variations:
</t>
<ul>
<li>
<t>
It contains no answers.
</t>
</li>
<li>
<t>
The LLQ&nbhy;OPCODE is set to LLQ&nbhy;REFRESH. The LLQ&nbhy;OPCODE is set to LLQ&nbhy;REFRESH.
</t> </t>
</li>
<t> <li>
NO&nbhy;SUCH&nbhy;LLQ MUST be returned as an error code if the client attempt <t>
s NO&nbhy;SUCH&nbhy;LLQ <bcp14>MUST</bcp14> be returned as an error code if
the client attempts
to refresh an expired or non-existent LLQ (as determined by the to refresh an expired or non-existent LLQ (as determined by the
LLQ&nbhy;ID in the request). LLQ&nbhy;ID in the request).
</t> </t>
</li>
<t> <li>
The LLQ&nbhy;ID in the acknowledgment is set to the LLQ&nbhy;ID in the reques <t>
t. The LLQ&nbhy;ID in the acknowledgment is set to the LLQ&nbhy;ID in the
</t> request.
<?rfc needLines="40" ?> </t>
</section> </li>
</section> </ul>
<section title="Security Considerations">
<t>
Without care taken in the design of protocols such as this, servers
may be susceptible to denial of service (DOS) attacks, and clients
may be subjected to packet storms. Mechanisms have been added to the
protocol to limit potential for these attacks.
</t>
<t> </section>
</section>
<section numbered="true" toc="default" anchor="security-considerations">
<name>Security Considerations</name>
<t>
In datagram-based protocols
(i.e., protocols running over UDP, or directly over IP, or similar), servers
may be susceptible to denial-of-service (DoS) attacks, and clients
may be subjected to packet storms. Carefully designed mechanisms are needed
to limit potential for these attacks.
</t>
<t>
Note: This section contains no new protocol elements -- it serves Note: This section contains no new protocol elements -- it serves
only to explain the rationale behind protocol elements described only to explain the rationale behind protocol elements described
above, as they relate to security. above as they relate to security.
</t> </t>
<section title="Server DOS"> <section numbered="true" toc="default" anchor="server-dos">
<t> <name>Server DoS</name>
LLQs require that servers be stateful, maintaining entries for each <t>
LLQ over a potentially long period of time. If unbounded in LLQs require that servers be stateful, maintaining entries for each LLQ
quantity, these entries may overload the server. By returning over a potentially long period of time. If unbounded in quantity, these
SERV&nbhy;FULL in Setup Challenges, the sever may limit the maximum entries may overload the server. By returning SERV&nbhy;FULL in Setup
number of LLQs it maintains. Additionally, the server may return Challenges, the server may limit the maximum number of LLQs it
SERV&nbhy;FULL to limit the number of LLQs requested for a single name and maintains. Additionally, the server may return SERV&nbhy;FULL to limit the
type, or by a single client. This throttling may be in the form of a number of LLQs requested for a single name and type, or by a single
hard limit, or, preferably, by token-bucket rate limiting. Such rate client. This throttling may be in the form of a hard limit, or, preferably,
limiting should occur rarely in normal use and is intended to prevent by token-bucket rate limiting. Such rate limiting should occur rarely in
DOS attacks -- thus it is not built into the protocol explicitly, but normal use and is intended to prevent DoS attacks -- thus, it is not built
is instead implemented at the discretion of an administrator via the into the protocol explicitly but is instead implemented at the discretion
SERV&nbhy;FULL error and the LEASE&nbhy;LIFE field to indicate a retry time t of an administrator via the SERV&nbhy;FULL error and the LLQ&nbhy;LEASE
o field to indicate a retry time to the client.
the client. </t>
</t> </section>
</section> <section numbered="true" toc="default">
<section title="Client Packet Storms"> <name>Client Packet Storms</name>
<t> <t>
In addition to protecting the server from DOS attacks, the protocol In addition to protecting the server from DoS attacks, the LLQ protocol
limits the ability of a malicious host to cause the server to flood a limits the ability of a malicious host to cause the server to flood a
client with packets. This is achieved via the four-way handshake client with packets. This is achieved via the four-way handshake
upon setup, demonstrating reachability and willingness of the client upon setup, demonstrating reachability and willingness of the client
to participate, and by requiring that gratuitous responses be ACK'd to participate, and by requiring that gratuitous responses be ACK'd
by the client. by the client.
</t> </t>
<t>
<t> Additionally, rate limiting by LLQ client address, as described in
Additionally, rate-limiting by LLQ client address, as described in <xref target="server-dos"/>, serves to limit the number of packets that can
(8.1) serves to limit the number of packets that can be delivered to be delivered to
an unsuspecting client. an unsuspecting client.
</t> </t>
</section> </section>
<section title="Spoofing"> <section numbered="true" toc="default">
<t> <name>Spoofing</name>
<t>
A large random ID greatly reduces the risk of an off-path attacker A large random ID greatly reduces the risk of an off-path attacker
sending spoof packets to the client (containing spoof events) sending spoof packets to the client (containing spoof events)
or to the server (containing phony requests or refreshes). or to the server (containing phony requests or refreshes).
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<t> <t>
The EDNS(0) OPTION CODE 1 has already been assigned for this DNS The EDNS(0) OPTION CODE 1 has already been assigned for this DNS extension.
extension. IANA is requested to update the record in the DNS EDNS(0) IANA has updated the record in the "DNS EDNS0 Option Codes (OPT)" registry
Option Codes registry from "On-hold" to "Optional", and to set the from "On-hold" to "Optional" and has set the reference to this document.
reference to indicate the RFC number under which this document is </t>
published.
</t>
<t>
TCP and UDP ports 5352 have already been assigned for LLQ. IANA is
requested to add a reference to indicate the RFC number under which
this document is published.
</t>
<t>
No additional IANA services are required by this document.
</t>
</section>
<section title="Acknowledgments">
<t>
The concepts described in this document were originally explored, developed
and implemented with help from Chris Sharp and Roger Pantos.
</t>
<t>In 2005 and 2006 Kiren Sekar made significant contributions to
the
first two drafts of this document, and he wrote much of the code
for the
implementation of LLQ that shipped in Mac OS X 10.4 Tiger in 2005
.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC1035;
&RFC2119;
&RFC2782;
&RFC6891;
&RFC8174;
<reference anchor='Push'>
<front>
<title>DNS Push Notifications [[RFC Editor note: Please update reference
"Push" to refer to assigned RFC number for that document]]</title>
<author initials='T' surname='Pusateri' fullname='Tom Pusateri'>
<organization />
</author>
<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
<organization />
</author>
<date month='September' day='18' year='2018' />
<abstract><t>The Domain Name System (DNS) was designed to return
matching records efficiently for queries for data that are relatively
static. 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 high. 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>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnssd-push-15' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dn
ssd-push-15.txt' />
</reference>
</references>
<references title='Informative References'>
&RFC2136;
&RFC4787;
&RFC4953;
&RFC5382;
&RFC6281;
&RFC6762;
&RFC6763;
&RFC6886;
&RFC6887;
&RFC7857;
<reference anchor='SYN'>
<front>
<title>Defenses Against TCP SYN Flooding Attacks</title>
<author initials='W.' surname='Eddy' fullname='Wesley Eddy'>
<organization>Verizon Federal Network Systems</organization>
<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/ac12
3/ac147/archived_issues/ipj_9-4/ipj_9-4.pdf" />
<format type='HTML' octets='65566' target="http://www.cisco.com/web/about/ac12
3/ac147/archived_issues/ipj_9-4/syn_flooding_attacks.html" />
</reference>
<reference anchor='RFC8490' target='https://www.rfc-editor.org/info/rfc8490'>
<front>
<title>DNS Stateful Operations</title>
<author initials='R' surname='Bellis' fullname='Ray Bellis'>
<organization />
</author>
<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
<organization />
</author>
<author initials='J' surname='Dickinson' fullname='John Dickinson'>
<organization />
</author>
<author initials='S' surname='Dickinson' fullname='Sara Dickinson'>
<organization />
</author>
<author initials='T' surname='Lemon' fullname='Ted Lemon'>
<organization />
</author>
<author initials='T' surname='Pusateri' fullname='Tom Pusateri'> <t>
<organization /> TCP and UDP ports 5352 have already been assigned for LLQ. IANA has
</author> added a reference to this document.
</t>
</section>
<date month='October' day='23' year='2018' /> </middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2782.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.x
ml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.x
ml"/>
<abstract><t>This document defines a new DNS OPCODE for DNS Stateful Operations <reference anchor='RFC8765' target="https://www.rfc-editor.org/info/rfc8765">
(DSO). DSO messages communicate operations within persistent stateful sessions, <front>
using type-length-value (TLV) syntax. Three TLVs are defined that manage sessi <title>DNS Push Notifications
on timeouts, termination, and encryption padding, and a framework is defined for </title>
extensions to enable new stateful operations. This document updates RFC 1035 b <author initials='T' surname='Pusateri' fullname='Tom Pusateri'>
y adding a new DNS header opcode which has different message semantics, and a ne <organization />
w result code. This document updates RFC 7766 by redefining a session, providin </author>
g new guidance on connection re-use, and providing a new mechanism for handling <author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
session idle timeouts.</t></abstract> <organization />
</front> </author>
<seriesInfo name='BCP' value='14'/> <date month='June' year='2020' />
<seriesInfo name='RFC' value='8490'/> </front>
<seriesInfo name='DOI' value='10.17487/RFC8490'/> <seriesInfo name='RFC' value='8765' />
<seriesInfo name="DOI" value="10.17487/RFC8765"/>
</reference> </reference>
</references> </references>
<references>
<?rfc needLines="40" ?> <name>Informative References</name>
<xi:include
<section anchor="problems" title="Problems with the LLQ Protocol"> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2136.x
<t> ml"/>
In the course of using LLQ since 2005, some problems were discove <xi:include
red. href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4787.x
Since no further work is being done on the LLQ protocol, ml"/>
this LLQ specification will not be updated to remedy these proble <xi:include
ms. href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4953.x
</t> ml"/>
<xi:include
<t> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5382.x
LLQ's IETF Standards Track successor, ml"/>
<xref target="Push">DNS Push Notifications</xref>, <xi:include
does not suffer from these problems, so href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6281.x
all existing LLQ implementations are RECOMMENDED to migrate to us ml"/>
ing DNS Push Notifications, <xi:include
and all new implementations are RECOMMENDED to implement DNS Push href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6762.x
Notifications instead of LLQ. ml"/>
</t> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.x
<t> ml"/>
Known problems with LLQ are documented here for the record. <xi:include
</t> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6886.x
ml"/>
<t> <xi:include
An LLQ "Setup Challenge" message from server to client is identic href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6887.x
al to ml"/>
an LLQ "ACK + Answers" message from server to client <xi:include
when there are no current answers for the query. href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7857.x
If there is packet loss, retransmission, and duplication in the n ml"/>
etwork, <xi:include
then a duplicated "Setup Challenge" message arriving late at the href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8490.x
client ml"/>
would look like an "ACK + Answers" message with no answers,
causing the client to clear its cache of any
records matching the query.
</t>
<t>
This LLQ specification states:
"Servers MUST NOT garbage collect LLQs that fail to complete the
four-way
handshake until the initially granted LEASE-LIFE has elapsed."
This is probably a mistake, since it exposes LLQ servers to an ea
sy
resource-exhaustion denial-of-service attack.
DNS Push Notifications is built using
DNS Stateful Operations <xref target="RFC8490"/>,
which uses TLS over TCP,
and a benefit of building on TCP is that there are already establ
ished
industry best practices to guard against SYN flooding and
similar attacks <xref target="SYN"/> <xref target="RFC4953"/>
</t>
<t> <reference anchor="SYN"
LLQ is built using UDP, and because the UDP protocol has no target="https://www.cisco.com/web/about/ac123/ac147/archived_i
standardized way of indicating the start and end of a ssues/ipj_9-4/ipj_9-4.pdf">
session, firewalls and NAT gateways tend to be fairly agressive a <front>
bout <title>Defenses Against TCP SYN Flooding Attacks</title>
recycling UDP mappings that they believe to be disused <seriesInfo name="Volume" value="9"/>
<xref target="RFC4787"/> <xref target="RFC5382"/> <xref target="R <seriesInfo name="Number" value="4"/>
FC7857"/>. <seriesInfo name="The Internet Protocol Journal," value="Cisco
Using a high keepalive traffic rate to maintain firewall or NAT m Systems"/>
apping <author initials="W." surname="Eddy" fullname="Wesley Eddy">
state could remedy this, but would largely defeat the purpose of <organization>Verizon Federal Network Systems</organization>
using LLQ in the first place, which is to provide efficient <address>
change notification without wasteful polling. <email>weddy@grc.nasa.gov</email>
Because of this, existing LLQ clients use </address>
<xref target="RFC6886">NAT Port Mapping Protocol (NAT-PMP)</xref> </author>
and/or <date year="2006" month="December"/>
<xref target="RFC6887">Port Control Protocol (PCP)</xref> to <keyword>TCP</keyword>
establish longer port mapping lifetimes. </front>
This solves the problem, but adds extra complexity, and doesn't w
ork
with firewalls and NAT gateways that don't support NAT-PMP or PCP
.
By using TCP instead of UDP, the DNS Push Notifications
protocol benefits from better longevity of sessions through
firewalls and NAT gateways that don't support NAT-PMP or PCP.
</t>
</section> </reference>
</back> </references>
</references>
<section anchor="problems" numbered="true" toc="default">
<name>Problems with the LLQ Protocol</name>
<t>
In the course of using LLQ since 2005, some problems were discovered.
Since no further work is being done on the LLQ protocol,
this LLQ specification will not be updated to remedy these problems.
</t>
<t>
LLQ's IETF Standards Track successor, "DNS Push Notifications"
<xref target="RFC8765" format="default"></xref>, does not
suffer from these problems, so all existing LLQ
implementations are <bcp14>RECOMMENDED</bcp14> to migrate to
using DNS Push Notifications, and all new implementations are
<bcp14>RECOMMENDED</bcp14> to implement DNS Push Notifications
instead of LLQ.
</t>
<t>
Known problems with LLQ are documented here as a cautionary tale
about the challenges of building an application protocol directly
using datagrams (like IP or UDP) without the benefit of a
mature and thoroughly reviewed
intervening transport layer (such as TCP or QUIC).
</t>
<t>
An LLQ "Setup Challenge" message from server to client is identical to
an LLQ "ACK + Answers" message from server to client
when there are no current answers for the query.
If there is packet loss, retransmission, and duplication in the
network,
then a duplicated "Setup Challenge" message arriving late at the
client
would look like an "ACK + Answers" message with no answers,
causing the client to clear its cache of any
records matching the query.
</t>
<t>
<xref target="setup-message-retransmission"/> of this LLQ
specification states, "Servers <bcp14>MUST
NOT</bcp14> garbage collect LLQs that fail to complete the
four-way handshake until the initially granted LLQ-LEASE has
elapsed." This is probably a mistake since it exposes LLQ
servers to an easy resource-exhaustion denial-of-service
attack.
LLQ's replacement,
DNS Push Notifications <xref target="RFC8765"
format="default"></xref>,
is built using DNS Stateful
Operations <xref target="RFC8490" format="default"/>, which
uses TLS over TCP; a benefit of building on 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>
The attempts here to pack multiple questions into a single UDP/IP
packet for efficiency are awkward and lead to error-prone programming
to deal with cases where some requests in a packet succeed and other
requests in the same packet fail. Fully specifying the correct
handling in all possible cases would be a lot of work to document, a
lot of work to implement, and even more work to thoroughly test. DNS
Push Notifications <xref target="RFC8765" format="default"></xref>
avoids this problem by using an underlying stream protocol (TLS/TCP)
to deal with packing small multiple messages into larger IP packets
for efficiency.
</t>
<t>
In some cases, initial LLQ answers are delivered in the "ACK +
Answers" message, and in other cases, such as when all the initial
answers will not fit in a single IP packet, some of the initial
answers are delivered in a subsequent "Add Event" message.
Having two different ways to accomplish the same thing increases
the possibility for programming errors.
DNS Push Notifications <xref target="RFC8765" format="default"></xref>
corrects this error by having only one single consistent way to
deliver results.
</t>
<t>
LLQ is built using UDP, and because UDP has no
standardized way of indicating the start and end of a session,
firewalls and NAT gateways tend to be fairly aggressive about
recycling UDP mappings that they believe to be disused <xref
target="RFC4787" format="default"/> <xref target="RFC5382"
format="default"/> <xref target="RFC7857" format="default"/>.
Using a high keepalive traffic rate to maintain firewall or
NAT mapping state could remedy this but would largely defeat
the purpose of using LLQ in the first place, which is to
provide efficient change notification without wasteful
polling. Because of this, existing LLQ clients use the NAT
Port Mapping Protocol (NAT-PMP) <xref target="RFC6886"
format="default"></xref> and/or Port Control Protocol (PCP)
<xref target="RFC6887" format="default"></xref> to establish
longer port mapping lifetimes. This solves the problem but
adds extra complexity and doesn't work with firewalls and NAT
gateways that don't support NAT-PMP or PCP. By using TCP
instead of UDP, the DNS Push Notifications protocol benefits
from better longevity of sessions through firewalls and NAT
gateways that don't support NAT-PMP or PCP.
</t>
</section>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The concepts described in this document were originally explored,
developed,
and implemented with help from <contact fullname="Chris Sharp"/> and
<contact fullname="Roger Pantos"/>.
</t>
<t><contact fullname="Kiren Sekar"/> made significant contributions to
the first draft of this document and he wrote much of the code for the
implementation of LLQ that shipped in Mac OS X 10.4 Tiger in April
2005.</t>
<t>Thanks to Independent Stream Editor <contact fullname="Adrian Farrel"/> for h
is support and
assistance in the publication of this RFC.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 144 change blocks. 
1072 lines changed or deleted 1455 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/