< draft-sekar-dns-llq-04.txt   draft-sekar-dns-llq-05.txt >
Network Working Group S. Cheshire Network Working Group S. Cheshire
Internet-Draft M. Krochmal Internet-Draft M. Krochmal
Intended status: Informational Apple Inc. Intended status: Informational Apple Inc.
Expires: February 14, 2020 August 13, 2019 Expires: February 17, 2020 August 16, 2019
DNS Long-Lived Queries DNS Long-Lived Queries
draft-sekar-dns-llq-04 draft-sekar-dns-llq-05
Abstract Abstract
DNS Long-Lived Queries (LLQ) is a protocol for extending the DNS DNS Long-Lived Queries (LLQ) is a protocol for extending the DNS
protocol to support change notification, thus allowing clients to protocol to support change notification, thus allowing clients to
learn about changes to DNS data without polling the server. From learn about changes to DNS data without polling the server. From
2007 onwards, LLQ was implemented in Apple products including Mac OS 2005 onwards, LLQ was implemented in Apple products including Mac OS
X, Bonjour for Windows, and AirPort wireless base stations. In 2019, X, Bonjour for Windows, and AirPort wireless base stations. In 2019,
the LLQ protocol was superseded by the IETF Standards Track RFC "DNS the LLQ protocol was superseded by the IETF Standards Track RFC "DNS
Push Notifications", which builds on experience gained with the LLQ Push Notifications", which builds on experience gained with the LLQ
protocol to create a superior replacement. protocol to create a superior replacement.
The existing deployed LLQ protocol is documented here to give The existing deployed LLQ protocol is documented here to give
background regarding the operational experience that informed the background regarding the operational experience that informed the
development of DNS Push Notifications, and to help facilitate a development of DNS Push Notifications, and to help facilitate a
smooth transition from LLQ to DNS Push Notifications. smooth transition from LLQ to DNS Push Notifications.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 14, 2020. This Internet-Draft will expire on February 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
1. Introduction 1. Introduction
In dynamic environments, DNS Service Discovery [RFC6763] benefits In dynamic environments, DNS Service Discovery [RFC6763] benefits
significantly from clients being able to learn about changes to DNS significantly from clients being able to learn about changes to DNS
information via a mechanism that is both more timely and more information via a mechanism that is both more timely and more
efficient than simple polling. Such a mechanism enables "live efficient than simple polling. Such a mechanism enables "live
browses" that learn when a new instance of a service appears, or when browses" that learn when a new instance of a service appears, or when
an existing service disappears from the network, and allows clients an existing service disappears from the network, and allows clients
to monitor changes to a service. Multicast DNS [RFC6762] supports to monitor changes to a service. Multicast DNS [RFC6762] supports
this natively. When a host on the network publishes or deletes DNS this natively. When a host on the network publishes or deletes DNS
records, these records are multicast to other hosts on the network. records, these changes are multicast to other hosts on the network.
These hosts deliver the records to interested clients (applications These hosts deliver the change notifications to interested clients
running on the host). Hosts also send occasional queries to the (applications running on the host). Hosts also send occasional
network in case gratuitous announcements are not received due to queries to the network in case gratuitous announcements are not
packet loss, and to detect records lost due to their publishers received due to packet loss, and to detect records lost due to their
crashing or having become disconnected from the network. publishers crashing or having become disconnected from the network.
This document defines an extension to DNS that enables a client to This document defines an extension to DNS that enables a client to
issue long-lived queries that allow a DNS server to notify clients issue long-lived queries that allow a DNS server to notify clients
about changes to DNS data. This is a more scalable and practical 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 solution than can be achieved by polling of the name server because a
low polling rate could leave the client with stale information while low polling rate could leave the client with stale information while
a high polling rate would have an adverse impact on the network and a high polling rate would have an adverse impact on the network and
server. server.
The mechanism defined in this document is now being replaced by DNS The mechanism defined in this document is now being replaced by DNS
skipping to change at page 5, line 18 skipping to change at page 5, line 18
DNS message format [RFC1035] in conjunction with an EDNS(0) OPT DNS message format [RFC1035] in conjunction with an EDNS(0) OPT
pseudo-RR [RFC6891] with a new OPT and RDATA format specified here. pseudo-RR [RFC6891] with a new OPT and RDATA format specified here.
Encoding the LLQ request in an OPT RR allows for implementation of 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 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 query containing an LLQ option is sent to a server that does not
implement LLQ, a server that complies with the EDNS(0) specification implement LLQ, a server that complies with the EDNS(0) specification
[RFC6891] will silently ignore the unrecognized option and answer the [RFC6891] will silently ignore the unrecognized option and answer the
request as a normal DNS query, without establishing any long-lived request as a normal DNS query, without establishing any long-lived
state, and without returning an LLQ option in its response. If a DNS 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 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) implement EDNS(0) at all, the server may silently ignore the EDNS(0)
OPT pseudo-RR, or it may return a nonzero RCODE. However, in OPT pseudo-RR, or it may return a nonzero RCODE. However, in
practice this issue is mostly theoretical, since having a zone's practice this issue is mostly theoretical, since having a zone's
_dns-llq._udp.<zone> SRV record target a host that does not implement _dns-llq._udp.<zone> SRV record target a host that does not implement
LLQ is a configuration error. LLQ is a configuration error.
Note that this protocol is designed for data set sizes of a few dozen Note that this protocol is designed for data set sizes of a few dozen
resource records at most, and change rates no more than one every ten resource records at most, and change rates no more than one every ten
seconds on average. Data sets in response to queries that frequently seconds on average. Data sets in response to queries that frequently
exceed a single packet, or that experience a rapid change rate, may exceed a single packet, or that experience a rapid change rate, may
have undesirable performance implications. have undesirable performance implications.
3.1. New Assigned Numbers 3.1. New Assigned Numbers
This section describes constants uses in this document. This section describes constants uses in this document.
EDNS(0) Option Code (recorded with IANA): EDNS(0) Option Code (recorded with IANA):
LLQ 1 LLQ 1
LLQ-PORT 5352 (recorded with IANA) LLQ-PORT 5352 (recorded with IANA)
LLQ Error Codes (specific to the LLQ EDNS(0) Option): LLQ Error Codes (specific to this LLQ EDNS(0) Option):
NO-ERROR 0 NO-ERROR 0
SERV-FULL 1 SERV-FULL 1
STATIC 2 STATIC 2
FORMAT-ERR 3 FORMAT-ERR 3
NO-SUCH-LLQ 4 NO-SUCH-LLQ 4
BAD-VERS 5 BAD-VERS 5
UNKNOWN-ERR 6 UNKNOWN-ERR 6
LLQ Opcodes (specific to the LLQ EDNS(0) Option): LLQ Opcodes (specific to this LLQ EDNS(0) Option):
LLQ-SETUP 1 LLQ-SETUP 1
LLQ-REFRESH 2 LLQ-REFRESH 2
LLQ-EVENT 3 LLQ-EVENT 3
3.2. Opt-RR Format 3.2. Opt-RR Format
All OPT-RRs used in LLQs are formatted as follows: All OPT-RRs used in LLQs are formatted as follows:
Field Name Field Type Description Field Name Field Type Description
--------------------------------------------------------------------- ---------------------------------------------------------------------
skipping to change at page 7, line 10 skipping to change at page 7, line 10
This data format, consisting of (OPTION-CODE, OPTION-LEN, This data format, consisting of (OPTION-CODE, OPTION-LEN,
LLQ-Metadata) tuples, may be repeated an arbitrary number of times in LLQ-Metadata) tuples, may be repeated an arbitrary number of times in
the RDATA section, with the RDLEN field set accordingly. the RDATA section, with the RDLEN field set accordingly.
4. LLQ Address and Port Identification 4. LLQ Address and Port Identification
The client requires a mechanism to determine to which server it The client requires a mechanism to determine to which server it
should send LLQ operations. should send LLQ operations.
Additionally, some firewalls block communication directly with a name Additionally, some firewalls block direct communication with a name
server on port 53 to avoid spoof responses. However, this direct server on port 53 to avoid spoof responses. However, this direct
communication is necessary for LLQs. Thus, servers MAY listen for communication is necessary for LLQs. Thus, servers MAY listen for
LLQs on a different port (typically 5352). Clients also therefore LLQs on a different port (typically 5352). Clients also therefore
need a mechanism to determine to which port to send LLQ operations. need a mechanism to determine to which port to send LLQ operations.
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 client determines to which server to send a dynamic update. The a client determines to which server to send a dynamic update. The
client begins by sending a standard DNS query for the name of the client begins by sending a standard DNS query for the name of the
LLQ, with type SOA. The server MUST answer with that SOA record in LLQ, with type SOA. The server MUST answer with that SOA record in
the Answer section, if the record exists. The server SHOULD include the Answer section, if the record exists. The server SHOULD include
skipping to change at page 11, line 15 skipping to change at page 11, line 15
5.2.2. Setup Challenge 5.2.2. Setup Challenge
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 request, and with all questions contained in the request present
in the Question section of the response. Additionally, the challenge in the Question section of the response. Additionally, the challenge
contains a single OPT-RR with an LLQ metadata section for each LLQ contains a single OPT-RR with an LLQ metadata section for each LLQ
request, indicating the success or failure of each request. Metadata request, indicating the success or failure of each request. Metadata
sections MUST be in the same order as the questions they correspond sections MUST be in the same order as the questions they correspond
to. Note that some LLQs in a request containing multiple questions to. Note that in a request containing multiple questions some LLQs
may succeed, while others may fail. may succeed, while others may fail.
Setup Challenge OPT-RR RDATA Format: Setup Challenge OPT-RR RDATA Format:
Field Name Field Type Description Field Name Field Type Description
--------------------------------------------------------------------- ---------------------------------------------------------------------
OPTION-CODE u_int16_t LLQ (1) OPTION-CODE u_int16_t LLQ (1)
OPTION-LENGTH u_int16_t Length of following fields (18) OPTION-LENGTH u_int16_t Length of following fields (18)
VERSION u_int16_t Version of LLQ protocol implemented VERSION u_int16_t Version of LLQ protocol implemented
in server (1) in server (1)
skipping to change at page 13, line 18 skipping to change at page 13, line 18
with minimal bookkeeping would be to store the time, in seconds since 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 the Epoch, in the high 32 bits of the field, and a cryptographically
generated 32-bit random integer in the low 32 bits. generated 32-bit random integer in the low 32 bits.
On error, the LLQ-ID is set to 0. On error, the LLQ-ID is set to 0.
LEASE-LIFE: On success, the actual life of the LLQ, in seconds. LEASE-LIFE: On success, the actual life of the LLQ, in seconds.
Value may be greater than, less than, or equal to the value requested Value may be greater than, less than, or equal to the value requested
by the client, as per the server administrator's policy. The server by the client, as per the server administrator's policy. The server
MAY discard the LLQ after this LEASE-LIFE expires unless the LLQ has MAY discard the LLQ after this LEASE-LIFE expires unless the LLQ has
been renewed by the client (see Section 8 "Security Considerations"). been renewed by the client (see Section 7 "LLQ Lease-Life
The server MUST NOT generate events (see Section 6 "Event Responses") Expiration"). The server MUST NOT generate events (see Section 6
for expired LLQs. "Event Responses") for expired LLQs.
On SERV-FULL error, LEASE-LIFE MUST be set to a time interval, in On SERV-FULL error, LEASE-LIFE MUST be set to a time interval, in
seconds, after which the client may re-try the LLQ Setup. seconds, after which the client may re-try the LLQ Setup.
On other errors, the LEASE-LIFE MUST be set to 0. On other errors, the LEASE-LIFE MUST be set to 0.
5.2.3. Challenge Response 5.2.3. Challenge Response
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 (5.2.2), re-transmitting the request as necessary (5.1). After
receiving a successful Challenge, the client SHOULD send a Challenge receiving a successful Challenge, the client SHOULD 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-RR in with questions from the request and challenge, and a single OPT-RR in
the Additional section, with the OPT-RR RDATA identical to the OPT-RR the Additional section, with the OPT-RR RDATA identical to the OPT-RR
RDATA contained in the Setup Request ACK (i.e., echoing, for each set RDATA contained in the Setup Challenge (i.e., echoing, for each set
of fields, the random LLQ-ID and the granted lease life). If the of fields, the random LLQ-ID and the granted lease life). If the
challenge response contains multiple questions, the first question challenge response contains multiple questions, the first question
MUST correspond to the first OPT-RR RDATA tuple, etc. MUST correspond to the first OPT-RR RDATA tuple, etc.
If the Setup Request fails with a STATIC error, the client MUST NOT If the Setup Request fails with a STATIC error, the client MUST NOT
poll the server. The client SHOULD honor the resource record TTLs poll the server. The client SHOULD honor the resource record TTLs
contained in the response. contained in the response.
If the Setup Request fails with a SERV-FULL error, the client MAY If the Setup Request fails with a SERV-FULL error, the client MAY
re-try the LLQ Setup Request (5.2.1) after the time indicated in the re-try the LLQ Setup Request (5.2.1) after the time indicated in the
LEASE-LIFE field. LEASE-LIFE field.
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-FULL, or the server is determined not to support LLQ (i.e., the SERV-FULL, or the server is determined not to support LLQ (i.e., the
client receives a DNS response with a nonzero RCODE, or a DNS client receives a DNS response with a nonzero RCODE, or a DNS
response containing no LLQ option), the client MAY poll the server response containing no LLQ option), the client MAY poll the server
periodically with standard DNS queries, inferring Add and Remove periodically with standard DNS queries, inferring Add and Remove
events (see Section 8 "Security Considerations") by comparing answers events (see Section 6 "Event Responses") by comparing answers to
to these queries. The client SHOULD NOT poll more than once every 15 these queries. The client SHOULD NOT poll more than once every 15
minutes for a given query. The client MUST NOT poll if it receives a minutes for a given query. The client MUST NOT poll if it receives a
STATIC error code in the acknowledgment. STATIC error code in the acknowledgment.
5.2.4. ACK + Answers 5.2.4. ACK + Answers
Upon receiving a Challenge Response, a server MUST return an Upon receiving a correct Challenge Response, a server MUST 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).
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-ID and LEASE-LIFE echoed by the client Response in which the LLQ-ID and LEASE-LIFE 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 MUST 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-RR formatted as section. The Additional section also contains an OPT-RR formatted as
follows: follows:
Successful Setup Response ACK OPT-RR RDATA Format: Successful ACK + Answers OPT-RR RDATA Format:
Field Name Field Type Description Field Name Field Type Description
--------------------------------------------------------------------- ---------------------------------------------------------------------
OPTION-CODE u_int16_t LLQ OPTION-CODE u_int16_t LLQ
OPTION-LENGTH u_int16_t Length of following fields, as OPTION-LENGTH u_int16_t Length of following fields, as
appropriate appropriate
VERSION u_int16_t Version of LLQ protocol implemented VERSION u_int16_t Version of LLQ protocol implemented
in server in server
LLQ-OPCODE u_int16_t LLQ-SETUP (1) LLQ-OPCODE u_int16_t LLQ-SETUP (1)
ERROR-CODE u_int16_t NO-ERROR ERROR-CODE u_int16_t NO-ERROR
LLQ-ID u_int64_t Originally granted ID, echoed in LLQ-ID u_int64_t Originally granted ID, echoed in
client's Response client's Response
LEASE-LIFE u_int32_t Remaining life of LLQ, in seconds LEASE-LIFE u_int32_t Remaining life of LLQ, in seconds
If there is a significant delay in receiving a Setup Response, or If there is a significant delay in receiving a Challenge Response, or
multiple Setup Responses are issued (possibly because they were lost multiple Challenge Responses are issued (possibly because they were
en route to the client, causing the client to re-send the Setup lost en route to the client, causing the client to re-send the
Response), the server MAY decrement the LEASE-LIFE by the time Challenge Response), the server MAY decrement the LEASE-LIFE by the
elapsed since the Setup Request ACK was initially issued. time elapsed since the Setup Challenge was initially issued.
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-RR do not answers to the question(s), additional records, and the OPT-RR do not
fit in a single packet, some or all additional records (excluding the fit in a single packet, some or all additional records (excluding the
OPT-RR) MUST be omitted. If, after omission of all additional OPT-RR) MUST 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 MUST be removed until the message fits in a single packet. These
answers not delivered in the Setup Response ACK MUST be delivered answers not delivered in the ACK + Answers MUST be delivered without
without undue delay to the client via Add Events (Section 7 "LLQ undue delay to the client via Add Events (Section 6 "Event
Lease-Life Expiration"). Responses").
5.3. Resource Record TTLs 5.3. Resource Record TTLs
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 SHOULD be ignored by the client. The client MAY cache LLQ answers
until the client receives a gratuitous announcement (see Section 6 until the client receives a gratuitous announcement (see Section 6
"Event Responses") indicating that the answer to the LLQ has changed. "Event Responses") indicating that the answer to the LLQ has changed.
The client MUST NOT cache answers after the LLQs LEASE-LIFE expires The client MUST NOT cache answers after the LLQs LEASE-LIFE expires
without being refreshed (see Section 8 "Security Considerations"). without being refreshed (see Section 7 "LLQ Lease-Life Expiration").
If an LLQ request fails, the client SHOULD NOT cache answers for a If an LLQ request fails, the client SHOULD NOT cache answers for a
period longer than the client's polling interval. period longer than the client's polling interval.
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 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 stale information from residing in intermediate DNS recursive
resolvers that are not LLQ-aware. resolvers that are not LLQ-aware.
TTLs of resource records included in the Additional section of an LLQ TTLs of resource records included in the Additional section of an LLQ
response (which do not actually answer the LLQ) SHOULD be honored by response (which do not directly answer the LLQ) SHOULD be honored by
the client. the client.
6. Event Responses 6. Event Responses
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. MUST check if the new or deleted resource records answer any LLQs.
If so, the resource records MUST be sent to the LLQ requesters in the If so, the changes MUST be communicated to the LLQ requesters in the
form of a gratuitous DNS response sent to the client, with the form of a gratuitous DNS response sent to the client, with the
question(s) being answered in the Question section, and answers to question(s) being answered in the Question section, and answers to
these questions in the Answer section. The response also includes an these questions in the Answer section. The response also includes an
OPT RR in the Additional section. This OPT RR contains, in its OPT RR in the Additional section. This OPT RR contains, in its
RDATA, an entry for each LLQ being answered in the message. Entries RDATA, an entry for each LLQ being answered in the message. Entries
must include the LLQ-ID. This reduces the potential for spoof events must include the LLQ-ID. This reduces the potential for spoof events
being sent to a client. being sent to a client.
Event Response OPT-RR RDATA Format: Event Response OPT-RR RDATA Format:
skipping to change at page 17, line 32 skipping to change at page 17, line 32
OPTION-CODE u_int16_t LLQ (1) OPTION-CODE u_int16_t LLQ (1)
OPTION-LENGTH u_int16_t Length of following fields (18) OPTION-LENGTH u_int16_t Length of following fields (18)
VERSION u_int16_t Version of LLQ protocol implemented VERSION u_int16_t Version of LLQ protocol implemented
in server (1) in server (1)
LLQ-OPCODE u_int16_t LLQ-EVENT (3) LLQ-OPCODE u_int16_t LLQ-EVENT (3)
ERROR-CODE u_int16_t 0 ERROR-CODE u_int16_t 0
LLQ-ID u_int64_t [As Appropriate] LLQ-ID u_int64_t [As Appropriate]
LEASE-LIFE u_int32_t 0 LEASE-LIFE u_int32_t 0
Gratuitous responses for a single LLQ MAY be batched, such that Gratuitous responses for a single LLQ MAY be batched, such that
multiple resource records are contained in a single message. multiple changes are communicated in a single message. Responses
Responses MUST NOT be batched if this would cause a message that MUST NOT be batched if this would cause a message that would
would otherwise fit in a single packet to be truncated. While otherwise fit in a single packet to be truncated. While responses
responses MAY be deferred to provide opportunities for batching, MAY be deferred to provide opportunities for batching, responses
responses SHOULD NOT be delayed, for purposes of batching, for more SHOULD NOT be delayed, for purposes of batching, for more than 30
than 30 seconds, as this would cause an unacceptable latency for the seconds, as this would cause an unacceptable latency for the client.
client.
After sending a gratuitous response, the server MUST listen for an After sending a gratuitous response, the server MUST listen 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-send the response. The server MUST re-send 2 times server MUST re-send the response. The server MUST re-send 2 times
(for a total of 3 transmissions), after which the server MUST (for a total of 3 transmissions), after which the server MUST
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-sending the response, 4 more MUST listen for 2 seconds before re-sending the response, 4 more
seconds before re-sending again, and must wait an additional 8 seconds before re-sending 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.
skipping to change at page 19, line 10 skipping to change at page 19, line 10
response echoing the OPT-RR contained in the event, with the message response echoing the OPT-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 MUST be sent to the source IP address and port from
which the event originated. which the event originated.
7. LLQ Lease-Life Expiration 7. LLQ Lease-Life Expiration
7.1. Refresh Request 7.1. Refresh Request
If the client desires to maintain the LLQ beyond the duration If the client desires to maintain the LLQ beyond the duration
specified in the LEASE-LIFE field of the Request Acknowledgment specified in the LEASE-LIFE field of the Ack + Answers (5.2), the
(5.2), the client MUST send a Refresh Request. A Refresh Request is client MUST send a Refresh Request. A Refresh Request is identical
identical to an LLQ Challenge Response (5.3), but with the LLQ-OPCODE to an LLQ Challenge Response (5.3), but with the LLQ-OPCODE set to
set to LLQ-REFRESH. Unlike a Challenge Response, a Refresh Request LLQ-REFRESH. Unlike a Challenge Response, a Refresh Request returns
returns no answers. no answers.
The client SHOULD refresh an LLQ when 80% of its lease life has The client SHOULD refresh an LLQ when 80% of its lease life has
elapsed. elapsed.
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 SHOULD 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-LIFE. one LLQ MUST have elapsed at least 80% of its original LEASE-LIFE.
The client MUST NOT include additional LLQs if doing so would cause The client MUST NOT include additional LLQs if doing so would cause
the message to no longer fit in a single packet. In this case, the the message to no longer fit in a single packet. In this case, the
skipping to change at page 19, line 39 skipping to change at page 19, line 39
contains multiple questions, and a single OPT-RR with multiple LLQ contains multiple questions, and a single OPT-RR with multiple LLQ
metadata sections, one per question, with the metadata sections in metadata sections, one per question, with the metadata sections in
the same order as the questions they correspond to. the same order as the questions they correspond to.
The client SHOULD specify the original lease life granted in the LLQ The client SHOULD specify the original lease life granted in the LLQ
response as the desired LEASE-LIFE in the refresh request. If response as the desired LEASE-LIFE in the refresh request. If
refreshing multiple LLQs simultaneously, the client SHOULD request refreshing multiple LLQs simultaneously, the client SHOULD request
the same lease life for all LLQs being refreshed (with the exception the same lease life for all LLQs being refreshed (with the exception
of termination requests, see below). of termination requests, see below).
The client SHOULD specify a lease life of 0 to terminate an LLQ prior To terminate an LLQ prior to its scheduled expiration (for instance,
to its scheduled expiration (for instance, when the client terminates when the client terminates a DNS Service Discovery browse operation,
a DNS Service Discovery browse operation, or a client is about to go or a client is about to go to sleep or shut down) the client
to sleep or shut down.) specifies a lease life of 0.
The client SHOULD listen for an acknowledgment from the server. The The client MUST listen for an acknowledgment from the server. The
client MAY re-try up to two more times (for a total of 3 attempts) client MAY re-try up to two more times (for a total of 3 attempts)
before considering the server down or unreachable. The client MUST before considering the server down or unreachable. The client MUST
NOT re-try a first time before 90% of the lease life has expired, and NOT re-try a first time before 90% of the lease life has expired, and
MUST NOT re-try again before 95% of the lease life has expired. If MUST NOT re-try again before 95% of the lease life has expired. If
the server is determined to be down, the client MAY periodically the server is determined to be down, the client MAY 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 MUST NOT attempt the LLQ Setup Request more than once per
hour. hour.
7.2. LLQ Refresh Acknowledgment 7.2. LLQ Refresh Acknowledgment
skipping to change at page 21, line 21 skipping to change at page 21, line 21
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.
8.1. Server DOS 8.1. Server DOS
LLQs require that servers be stateful, maintaining entries for each LLQs require that servers be stateful, maintaining entries for each
LLQ over a potentially long period of time. If unbounded in LLQ over a potentially long period of time. If unbounded in
quantity, these entries may overload the server. By returning quantity, these entries may overload the server. By returning
SERV-FULL in Request Acknowledgments, the sever may limit the maximum SERV-FULL in Setup Challenges, the sever may limit the maximum number
number of LLQs it maintains. Additionally, the server may return of LLQs it maintains. Additionally, the server may return SERV-FULL
SERV-FULL to limit the number of LLQs requested for a single name and to limit the number of LLQs requested for a single name and type, or
type, or by a single client. This throttling may be in the form of a by a single client. This throttling may be in the form of a hard
hard limit, or, preferably, by token-bucket rate limiting. Such rate limit, or, preferably, by token-bucket rate limiting. Such rate
limiting should occur rarely in normal use and is intended to prevent limiting should occur rarely in normal use and is intended to prevent
DOS attacks -- thus it is not built into the protocol explicitly, but DOS attacks -- thus it is not built into the protocol explicitly, but
is instead implemented at the discretion of an administrator via the is instead implemented at the discretion of an administrator via the
SERV-FULL error and the LEASE-LIFE field to indicate a retry time to SERV-FULL error and the LEASE-LIFE field to indicate a retry time to
the client. the client.
8.2. Client Packet Storms 8.2. Client Packet Storms
In addition to protecting the server from DOS attacks, the protocol In addition to protecting the server from DOS attacks, the 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
skipping to change at page 21, line 47 skipping to change at page 21, line 47
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.
Additionally, rate-limiting by LLQ client address, as described in Additionally, rate-limiting by LLQ client address, as described in
(8.1) serves to limit the number of packets that can be delivered to (8.1) serves to limit the number of packets that can be delivered to
an unsuspecting client. an unsuspecting client.
8.3. Spoofing 8.3. Spoofing
A large random ID greatly reduces the risk of spoofing either the A large random ID greatly reduces the risk of an off-path attacker
client (by sending spoof events) or the server (by sending phony sending spoof packets to the client (containing spoof events) or to
requests or refreshes). the server (containing phony requests or refreshes).
9. Problems with the LLQ Protocol 9. Problems with the LLQ Protocol
In the course of using LLQ since 2007, some problems were discovered. 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 Since no further work is being done on the LLQ protocol, this LLQ
specification will not be updated to remedy these problems. specification will not be updated to remedy these problems.
LLQ's IETF Standards Track successor, DNS Push Notifications [Push], LLQ's IETF Standards Track successor, DNS Push Notifications [Push],
does not suffer from these problems, so all existing LLQ does not suffer from these problems, so all existing LLQ
implementations are RECOMMENDED to migrate to using DNS Push implementations are RECOMMENDED to migrate to using DNS Push
Notifications, and all new implementations are RECOMMENDED to Notifications, and all new implementations are RECOMMENDED to
implement DNS Push Notifications instead of LLQ. implement DNS Push Notifications instead of LLQ.
Known problems with LLQ are documented here for the record. Known problems with LLQ are documented here for the record.
skipping to change at page 22, line 38 skipping to change at page 22, line 38
that fail to complete the four-way handshake until the initially that fail to complete the four-way handshake until the initially
granted LEASE-LIFE has elapsed." This is probably a mistake, since granted LEASE-LIFE has elapsed." This is probably a mistake, since
it exposes LLQ servers to an easy resource-exhaustion denial-of- it exposes LLQ servers to an easy resource-exhaustion denial-of-
service attack. DNS Push Notifications is built using DNS Stateful service attack. DNS Push Notifications is built using DNS Stateful
Operations [RFC8490], which uses TLS over TCP, and a benefit of Operations [RFC8490], which uses TLS over TCP, and a benefit of
building on TCP is that there are already established industry best building on TCP is that there are already established industry best
practices to guard against SYN flooding and similar attacks [SYN] practices to guard against SYN flooding and similar attacks [SYN]
[RFC4953] [RFC4953]
LLQ is built using UDP, and because the UDP protocol has no LLQ is built using UDP, and because the UDP protocol has no
standardized way of indicating the start and end of a session, NAT standardized way of indicating the start and end of a session,
gateways tend to be fairly agressive about recycling UDP mappings firewalls and NAT gateways tend to be fairly agressive about
that they believe to be disused [RFC4787] [RFC5382] [RFC7857]. Using recycling UDP mappings that they believe to be disused [RFC4787]
a high keepalive traffic rate to maintain NAT mapping state could [RFC5382] [RFC7857]. Using a high keepalive traffic rate to maintain
remedy this, but would largely defeat the purpose of using LLQ in the firewall or NAT mapping state could remedy this, but would largely
first place, which is to provide efficient change notification defeat the purpose of using LLQ in the first place, which is to
without wasteful polling. Because of this, LLQ clients use NAT Port provide efficient change notification without wasteful polling.
Mapping Protocol (NAT-PMP) [RFC6886] and/or Port Control Protocol Because of this, existing LLQ clients use NAT Port Mapping Protocol
(PCP) [RFC6887] to establish longer NAT mapping lifetimes. This (NAT-PMP) [RFC6886] and/or Port Control Protocol (PCP) [RFC6887] to
solves the problem, but adds extra complexity, and doesn't work with establish longer port mapping lifetimes. This solves the problem,
NAT gateways that don't support NAT-PMP or PCP. By using TCP instead but adds extra complexity, and doesn't work with firewalls and NAT
of UDP, the DNS Push Notifications protocol benefits from better gateways that don't support NAT-PMP or PCP. By using TCP instead of
longevity of sessions through NAT gateways that don't support NAT-PMP UDP, the DNS Push Notifications protocol benefits from better
or PCP. longevity of sessions through firewalls and NAT gateways that don't
support NAT-PMP or PCP.
10. IANA Considerations 10. IANA Considerations
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. The IANA record in the DNS EDNS0 Option Codes registry extension. IANA is requested to update the record in the DNS EDNS(0)
should be updated from "On-hold" to refer to this specification. Option Codes registry from "On-hold" to "Optional", and to set the
reference to indicate the RFC number under which this document is
published.
TCP and UDP ports 5352 should be recorded as assigned to this TCP and UDP ports 5352 have already been assigned for LLQ. IANA is
specification. No additional IANA services are required by this requested to add a reference to indicate the RFC number under which
document. this document is published.
No additional IANA services are required by this document.
11. Acknowledgments 11. Acknowledgments
The concepts described in this document were originally explored, The concepts described in this document were originally explored,
developed and implemented with help from Chris Sharp and Roger developed and implemented with help from Chris Sharp and Roger
Pantos. Pantos.
In 2005 and 2006 Kiren Sekar made significant contributions to the 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 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.5 Leopard in the implementation of LLQ that shipped in Mac OS X 10.4 Tiger in
2007. 2005.
12. References 12. References
12.1. Normative References 12.1. Normative References
[Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
draft-ietf-dnssd-push-15 (work in progress), September draft-ietf-dnssd-push-15 (work in progress), September
2018. 2018.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
 End of changes. 31 change blocks. 
81 lines changed or deleted 85 lines changed or added

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