Apple Inc.

One Apple Park Way Cupertino CA 95014 United States of America +1 (408) 996-1010 cheshire@apple.com

Apple Inc.

One Apple Park Way Cupertino CA 95014 United States of America +1 (408) 996-1010 marc@apple.com

Async Asynchronous Change Notification Push Notification Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending the DNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From 2005 onwards, LLQ was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2020, the LLQ protocol was superseded by the IETF Standards Track RFC 8765, "DNS Push Notifications", which builds on experience gained with the LLQ protocol to create a superior replacement. 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.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents

• .  Introduction
  • .  Transition to DNS Push Notifications
• .  Conventions and Terminology Used in This Document
• .  Mechanisms
  • .  Assigned Numbers
  • .  Opt-RR Format
• .  LLQ Address and Port Identification
• .  LLQ Setup
  • .  Setup Message Retransmission
  • .  LLQ Setup Four-Way Handshake
    • .  Setup Request
    • .  Setup Challenge
    • .  Challenge Response
    • .  ACK + Answers
  • .  Resource Record TTLs
• .  Event Responses
  • .  Add Events
  • .  Remove Events
  • .  Gratuitous Response Acknowledgments
• .  LLQ Lease-Life Expiration
  • .  Refresh Request
  • .  LLQ Refresh Acknowledgment
• .  Security Considerations
  • .  Server DoS
  • .  Client Packet Storms
  • .  Spoofing
• .  IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• .  Problems with the LLQ Protocol
• Acknowledgments
• Authors' Addresses

Introduction In dynamic environments, DNS-based Service Discovery 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 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. 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. The mechanism defined in this document is now being replaced by DNS Push Notifications as explained in .

Transition to DNS Push Notifications 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 service. However, some problems were discovered, as described in . This operational experience with LLQ informed the design of its IETF Standards Track successor, DNS Push Notifications . Since no further work is being done on the LLQ protocol, this LLQ specification will not be updated to remedy these problems. All existing LLQ implementations are RECOMMENDED to migrate to using DNS Push Notifications instead. Existing LLQ servers are RECOMMENDED to implement and support DNS Push Notifications so that clients can begin migrating to the newer protocol. Existing LLQ clients are RECOMMENDED to query for the _dns‑push‑tls._tcp.<zone> SRV record first, and then only if DNS Push Notifications fail, fall back to query for _dns‑llq._udp.<zone> instead. Use of the _dns‑llq._udp.<zone> SRV record is described in . This will cause clients to prefer the newer protocol when possible. It is RECOMMENDED that clients always attempt DNS Push Notifications first for every new request, and only if that fails, then fall back to using LLQ. Clients SHOULD NOT 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. New client and server implementations are RECOMMENDED to support only DNS Push Notifications.

Conventions and Terminology Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Mechanisms DNS Long-Lived Queries (LLQ) are implemented using the standard DNS message format in conjunction with an EDNS(0) OPT pseudo‑RR with a new OPTION‑CODE and OPTION‑DATA format specified here. Encoding the LLQ request in an OPT pseudo‑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 EDNS(0) specification 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‑RR or it may return a nonzero RCODE. However, in practice, this issue is mostly theoretical, since having a zone's _dns‑llq._udp.<zone> SRV record target a host that does not implement LLQ is a configuration error. 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.

Assigned Numbers This section describes constants used in this document.

• EDNS(0) OPTION‑CODE (recorded with IANA):

  • LLQ

    1

• LLQ‑PORT 5352 (recorded with IANA)
• LLQ Opcodes (specific to this LLQ EDNS(0) Option):

  • LLQ‑SETUP

    1

    LLQ‑REFRESH

    2

    LLQ‑EVENT

    3

• LLQ Error Codes (specific to this LLQ EDNS(0) Option):

  • NO-ERROR

    0

    SERV-FULL

    1

    STATIC

    2

    FORMAT-ERR

    3

    NO-SUCH-LLQ

    4

    BAD-VERS

    5

    UNKNOWN-ERR

    6

Opt-RR Format As required by the EDNS(0) specification , all OPT pseudo‑RRs used in LLQs are formatted as follows: OPT-RRs Used in LLQs

Field Name	Field Type	Description
NAME	domain name	MUST be 0 (root domain)
TYPE	u_int16_t	OPT (41)
CLASS	u_int16_t	0*
TTL	u_int32_t	0
RDLEN	u_int16_t	length of all RDATA
RDATA	octet stream	(see below)

* The CLASS field indicates, as per the EDNS(0) specification , the sender's UDP payload size. However, clients and servers are not required to determine their reassembly buffer size, path MTU, etc., to support LLQ. Thus, the sender of an LLQ Request or Response MAY set the CLASS field to 0. The recipient MUST ignore the class field if it is set to 0. The RDATA of an EDNS(0) OPT pseudo‑RR consists of zero or more options of the form { OPTION‑CODE, OPTION‑LENGTH, OPTION‑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‑RR may contain zero or more LLQ OPTIONS in addition to zero or more other EDNS(0) options. LLQ OPTION

Field Name	Field Type	Description
OPTION-CODE	u_int16_t	LLQ (1)
OPTION-LENGTH	u_int16_t	Length of following fields (18)
LLQ-VERSION	u_int16_t	Version of LLQ protocol implemented
LLQ-OPCODE	u_int16_t	Identifies LLQ operation
LLQ-ERROR	u_int16_t	Identifies LLQ errors
LLQ-ID	u_int64_t	Identifier for an LLQ
LLQ-LEASE	u_int32_t	Requested or granted life of LLQ, in seconds

The size and meaning of the OPTION‑CODE and OPTION‑LENGTH fields are as described in the EDNS(0) specification . The remainder of the fields comprise the OPTION‑DATA of the EDNS(0) LLQ OPTION. Since for LLQ the OPTION‑DATA is a fixed size, in EDNS(0) LLQ OPTIONS the OPTION‑LENGTH field always has the value 18. 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).

LLQ Address and Port Identification The client requires a mechanism to determine to which server it should send LLQ operations. Additionally, some firewalls block direct communication with a name server on port 53 to avoid spoof responses. However, this direct communication is necessary for LLQs. Thus, servers MAY listen for LLQs on a different port (typically 5352). Clients, therefore, also need a mechanism to determine to which port to send LLQ operations. The client determines the server responsible for a given LLQ much as a client determines to which server to send a DNS dynamic update. The client begins by sending a standard DNS query for the name of the LLQ, with type SOA. If the record exists, then the server MUST answer with that SOA record in the Answer section. If a record of type SOA with the LLQ name does not exist, then the server SHOULD include an SOA record for that name's zone in the Authority section. For example, a query for "_ftp._tcp.example.com" with type SOA, when there is no SOA record with that name, might return an SOA record named "example.com" in the Authority section. If the named SOA record does not exist and the server fails to include the enclosing SOA record in the Authority section, the client strips the leading label from the name and tries again, repeating until an answer is received. This iterative zone apex discovery algorithm is described in more detail in the DNS Push Notifications specification . Upon learning the zone apex (SOA), the client then constructs and sends an SRV query for the name, "_dns‑llq._udp.<zone>", e.g., "_dns‑llq._udp.example.com". An authoritative server for a zone implementing LLQ MUST answer with an SRV record for this name. The SRV RDATA is as follows: SRV RDATA

PRIORITY	typically 0
WEIGHT	typically 0
PORT	typically 53 or 5352
TARGET	name of server providing LLQs for the requested zone

The server SHOULD include the address record(s) for the target host in the Additional section of the response. If the server does not include the target host's address record(s) in the Additional section, the client SHOULD query explicitly for the address record(s) with the name of the SRV target. The client MUST send all LLQ requests, refreshes, and acknowledgments to the name server specified in the SRV target, at the address contained in the address record for that target. Note that the queries described in this section (including those for SOA and SRV records) MAY be sent to an intermediate DNS recursive resolver -- they need not be sent directly to the name server. If, on issuing the SRV query, the client receives a negative response indicating that the SRV record does not exist, the client SHOULD conclude that the zone does not support LLQ. The client then SHOULD NOT send an LLQ request for the desired name, instead utilizing the behavior for LLQ-unaware servers described in , "". Servers should send all messages to the source address and port of the LLQ setup message received from the client.

LLQ Setup An LLQ is initiated by a client and is completed via a four-way handshake. This handshake provides resilience to packet loss, demonstrates client reachability, and reduces denial-of-service attack opportunities (see , "").

Setup Message Retransmission LLQ Setup Requests and Responses sent by the client SHOULD be retransmitted if no acknowledgments are received. The client SHOULD retry up to two more times (for a total of 3 attempts) before considering the server down or unreachable. The client MUST wait at least 2 seconds before the first retransmission and 4 seconds between the first and second retransmissions. The client SHOULD listen for a response for at least 8 seconds after the 3rd attempt before considering the server down or unreachable. Upon determining a server to be down, a client MAY periodically attempt to re-initiate an LLQ setup at a rate of not more than once per hour. Servers MUST NOT retransmit acknowledgments that do not generate responses from the client. Retransmission in setup is client driven, freeing servers from maintaining timers for incomplete LLQ setups. If servers receive duplicate messages from clients (perhaps due to the loss of the server's responses mid-flight), the server MUST resend its reply (possibly modifying the LLQ‑LEASE as described in , ""). Servers MUST NOT garbage collect LLQs that fail to complete the four-way handshake until the initially granted LLQ‑LEASE has elapsed.

LLQ Setup Four-Way Handshake The four phases of the handshake include:

• 1) Setup Request

  client to server, identifies LLQ(s) requested

  2) Setup Challenge

  server to client, provides unique identifiers for successful requested LLQs, and error(s) for unsuccessful requested LLQs.

  3) Challenge Response

  client to server, echoes identifier(s), demonstrating client's reachability and willingness to participate

  4) ACK + Answers

  server to client, confirms setup and provides initial answers

Setup Request A request for an LLQ is formatted like a standard DNS query but with an OPT pseudo‑RR containing LLQ metadata in its Additional section. LLQ Setup Requests are identified by the LLQ‑SETUP opcode and a zero‑valued LLQ‑ID. The request MAY contain multiple questions to set up multiple LLQs. A Setup Request consisting of multiple questions MUST 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 LLQ OPTION corresponds to the first question, the second LLQ OPTION corresponds to the second question, etc.). If requesting multiple LLQs, clients SHOULD request the same LLQ‑LEASE for each LLQ. Requests over UDP MUST NOT contain multiple questions if doing so would cause the message to exceed a single IP packet. A client MUST NOT request multiple identical LLQs (i.e., containing the same qname/type/class) from the same source IP address and port. This requirement is to avoid unnecessary load on servers. In the case of multiple independent client implementations that may run on the same device without knowledge of each other, it is allowable if they by chance send LLQ requests for the same qname/type/class. These independent implementations on the same client will be using different source ports. Likewise, to the server, multiple independent clients behind the same NAT gateway will appear as if they were multiple independent clients using different ports on the same host, and this is also allowable. The query MUST NOT be for record type ANY (255), class ANY (255), or class NONE (0). Setup Request LLQ OPTION Format

Field Name	Field Type	Description
OPTION-CODE	u_int16_t	LLQ (1)
OPTION-LENGTH	u_int16_t	Length of following fields (18)
LLQ-VERSION	u_int16_t	Version of LLQ protocol implemented by requester (1)
LLQ-OPCODE	u_int16_t	LLQ-SETUP (1)
LLQ-ERROR	u_int16_t	NO-ERROR (0)
LLQ-ID	u_int64_t	0
LLQ-LEASE	u_int32_t	Desired life of LLQ request

The Setup Request LLQ OPTION MUST be repeated once for each additional query in the Question section.

Setup Challenge Upon receiving an LLQ Setup Request, a server implementing LLQs will send a Setup Challenge to the requester (client). An LLQ Setup Challenge is a DNS response, with the DNS message ID matching that of the Setup Request, and with all questions contained in the Setup Request present in the Question section of the response. Additionally, the challenge contains a single OPT pseudo‑RR with an LLQ OPTION for each LLQ request, indicating the success or failure of each request. The LLQ OPTIONS MUST be in the same order as the questions they correspond to. Note that in a Setup Request containing multiple questions, some LLQs may succeed while others may fail. Setup Challenge LLQ OPTION Format

Field Name	Field Type	Description
OPTION-CODE	u_int16_t	LLQ (1)
OPTION-LENGTH	u_int16_t	Length of following fields (18)
LLQ-VERSION	u_int16_t	Version of LLQ protocol implemented in server (1)
LLQ-OPCODE	u_int16_t	LLQ-SETUP (1)
LLQ-ERROR	u_int16_t	[As Appropriate]
LLQ-ID	u_int64_t	[As Appropriate]
LLQ-LEASE	u_int32_t	[As Appropriate]

The Setup Challenge LLQ OPTION MUST be repeated once for each query in the Questions section of the Setup Challenge. Further details for LLQ‑ERROR, LLQ‑ID and LLQ‑LEASE are given below. LLQ‑ERROR:

• NO-ERROR:

  The LLQ Setup Request was successful.

  FORMAT-ERR:

  The LLQ was improperly formatted. Note that if the rest of the DNS message is properly formatted, the DNS header error code MUST NOT 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.

  SERV-FULL:

  The server cannot grant the LLQ request because it is overloaded or the request exceeds the server's rate limit (see , ). Upon returning this error, the server MUST include in the LLQ-LEASE field a time interval, in seconds, after which the client may retry the LLQ Setup.

  STATIC:

  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 MUST honor the resource record TTLs returned and MUST NOT poll sooner than indicated by those TTLs, nor should it retry the LLQ Setup for this name and type.

  BAD-VERS:

  The protocol version specified in the client's Setup Request is not supported by the server.

  UNKNOWN-ERR:

  The LLQ was not granted for some other reason not covered by the preceding error code values.

LLQ‑ID:

On success, a random number generated by the server that is unique on the server for the requested name/type/class. The LLQ‑ID SHOULD be an unpredictable random number. A possible method of allocating LLQ‑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.

On error, the LLQ‑ID is set to 0.

LLQ‑LEASE:

On success, the actual life of the LLQ, in seconds. 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 MAY discard the LLQ after this LLQ‑LEASE expires unless the LLQ has been renewed by the client (see , ""). The server MUST NOT generate events (see , "") for expired LLQs.

On SERV‑FULL error, LLQ‑LEASE MUST be set to a time interval, in seconds, after which the client may retry the LLQ Setup.

On other errors, the LLQ‑LEASE MUST be set to 0.

Challenge Response Upon issuing a Setup Request, a client listens for a Setup Challenge () retransmitting the Setup Request as necessary (). After receiving a successful Setup Challenge, the client SHOULD send a Challenge Response to the server. This Challenge Response is a DNS request with questions as in the Setup Request and Setup Challenge, and a single OPT pseudo‑RR in the Additional section, with the LLQ OPTIONS corresponding to the LLQ OPTIONS contained in the Setup Challenge (i.e., echoing, for each LLQ OPTION, the random LLQ‑ID and the granted LLQ‑LEASE). If the Challenge Response contains multiple questions, the first question MUST correspond to the first LLQ OPTION, etc. If the Setup Request for a particular LLQ fails with a STATIC error, the client MUST NOT poll the server for that LLQ. The client SHOULD honor the resource record TTLs contained in the response. If a Setup Request fails with a SERV‑FULL error, the client MAY retry the LLQ Setup Request () after the time indicated in the LLQ‑LEASE field. 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 client receives a DNS response with a nonzero RCODE, or a DNS response containing no LLQ option), the client MAY poll the server periodically with standard DNS queries, inferring Add and Remove Events (see , "Event Responses") by comparing answers to 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 STATIC error code in the acknowledgment.

ACK + Answers Upon receiving a correct Challenge Response, a server MUST return an acknowledgment, completing the LLQ setup, and provide all current answers to the question(s). To acknowledge a successful Challenge Response, i.e., a Challenge Response in which the LLQ‑ID and LLQ‑LEASE echoed by the client match the values issued by the server, the server MUST send a DNS response containing all available answers to the question(s) contained in the original Setup Request, along with all additional resource records appropriate for those answers in the Additional section. The Additional section also contains LLQ OPTIONS formatted as follows: Successful ACK + Answers LLQ OPTION Format

Field Name	Field Type	Description
OPTION-CODE	u_int16_t	LLQ (1)
OPTION-LENGTH	u_int16_t	Length of following fields (18)
LLQ-VERSION	u_int16_t	Version of LLQ protocol implemented in server (1)
LLQ-OPCODE	u_int16_t	LLQ-SETUP (1)
LLQ-ERROR	u_int16_t	NO-ERROR (0)
LLQ-ID	u_int64_t	Originally granted ID, echoed in client's Response
LLQ-LEASE	u_int32_t	Remaining life of LLQ, in seconds

If there is a significant delay in receiving a Challenge Response, or multiple Challenge Responses are issued (possibly because they were lost en route to the client, causing the client to resend the Challenge Response), the server MAY decrement the LLQ‑LEASE by the time elapsed since the Setup Challenge was initially issued. If the setup is completed over UDP and all initially available answers to the question(s), additional records, and the OPT pseudo‑RR do not fit in a single IP packet, some or all additional records (excluding the OPT pseudo‑RR) MUST be omitted. If, after omission of all additional records, the answers still do not fit in a single message, answers MUST be removed until the message fits in a single IP packet. These answers not delivered in the ACK + Answers MUST be delivered without undue delay to the client via Add Events (, "").

Resource Record TTLs The TTLs of resource records contained in answers to successful LLQs SHOULD be ignored by the client. The client MAY cache LLQ answers until the client receives a gratuitous announcement (see , "") indicating that the answer to the LLQ has changed. The client SHOULD NOT cache answers after the LLQs LLQ‑LEASE expires without being refreshed (see , "LLQ Lease-Life Expiration"). If an LLQ request fails, the client SHOULD NOT cache answers for a period longer than the client's polling interval. Note that resource records intended specifically to be transmitted via LLQs (e.g., DNS-based Service Discovery resource records) may have unusually short TTLs. This is because it is assumed that the records may change frequently, and that a client's cache coherence will be maintained via the LLQ and gratuitous responses. Short TTLs prevent stale information from residing in intermediate DNS recursive resolvers that are not LLQ aware. TTLs of resource records included in the Additional section of an LLQ response (which do not directly answer the LLQ) SHOULD be honored by the client.

Event Responses 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. 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 relevant question(s) in the Question section, and the corresponding answers in the Answer section. The response also includes an OPT pseudo‑RR in the Additional section. This OPT pseudo‑RR contains, in its RDATA, an LLQ OPTION for each LLQ being answered in the message. Each LLQ OPTION must include the LLQ‑ID. This reduces the potential for spoof events being sent to a client. Event Response LLQ OPTION Format

Field Name	Field Type	Description
OPTION-CODE	u_int16_t	LLQ (1)
OPTION-LENGTH	u_int16_t	Length of following fields (18)
LLQ-VERSION	u_int16_t	Version of LLQ protocol implemented in server (1)
LLQ-OPCODE	u_int16_t	LLQ-EVENT (3)
LLQ-ERROR	u_int16_t	NO-ERROR (0)
LLQ-ID	u_int64_t	[As Appropriate]
LLQ-LEASE	u_int32_t	0

Gratuitous responses for a single LLQ MAY be batched such that multiple changes are communicated in a single message. Responses MUST NOT be batched if this would cause a message that would otherwise fit in a single IP packet to be truncated. While responses MAY be deferred to provide opportunities for batching, responses SHOULD NOT be delayed, for purposes of batching, for more than 30 seconds, as this would cause an unacceptable latency for the client. After sending a gratuitous response, the server MUST listen for an acknowledgment from the client. If the client does not respond, the server MUST resend the response. The server MUST resend two times (for a total of 3 transmissions), after which the server MUST consider the client to be unreachable and delete its LLQ. The server MUST listen for 2 seconds before resending the response, 4 more seconds before resending again, and must wait an additional 8 seconds after the 3rd transmission before terminating the LLQ. The DNS message header of the response SHOULD include an unpredictable random number in the DNS message ID field, which is to be echoed in the client's acknowledgment.

Add Events Add Events occur when a new resource record appears, usually as the result of a dynamic update , that answers an LLQ. This record must be sent in the Answer section of the event to the client. Records that normally accompany this record in responses MAY be included in the Additional section as per truncation restrictions described above.

Remove Events 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). The deleted resource record is sent in the Answer section of the event to the client. The resource record TTL is set to -1, indicating that the record has been removed.

Gratuitous Response Acknowledgments Upon receiving a gratuitous response ("event"), the client MUST send an acknowledgment to the server. This acknowledgment is a DNS response echoing the OPT pseudo‑RR contained in the event, with the message ID of the gratuitous response echoed in the message header. The acknowledgment MUST be sent to the source IP address and port from which the event originated.

LLQ Lease-Life Expiration

Refresh Request If the client desires to maintain the LLQ beyond the duration specified in the LLQ‑LEASE field of the ACK + Answers (), the client MUST send a Refresh Request. A Refresh Request is identical to an LLQ Challenge Response () but with the LLQ‑OPCODE set to LLQ‑REFRESH. Unlike a Challenge Response, a Refresh Request returns no answers. The client SHOULD refresh an LLQ when 80% of its LLQ‑LEASE has elapsed. As a means of reducing network traffic, when constructing refresh messages the client SHOULD include all LLQs established with a given server, even those not yet close to expiration. However, at least one LLQ MUST have elapsed at least 80% of its original LLQ‑LEASE. The client MUST NOT 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 fits in a single IP packet. (These LLQs SHOULD be refreshed in a separate message when 80% of one or more of their lease lives have elapsed.) When refreshing multiple LLQs simultaneously, the message contains multiple questions and a single OPT pseudo‑RR with multiple LLQ OPTIONS, one per question, with the LLQ OPTIONS in the same order as the questions they correspond to. The client SHOULD specify the original LLQ‑LEASE granted in the LLQ response as the desired LLQ‑LEASE in the Refresh Request. If refreshing multiple LLQs simultaneously, the client SHOULD request the same LLQ‑LEASE for all LLQs being refreshed (with the exception of termination requests; see below). To terminate an LLQ prior to its scheduled expiration (for instance, when the client terminates a DNS-based Service Discovery browse operation or when a client is about to go to sleep or shut down), the client specifies an LLQ‑LEASE value of 0. The client MUST listen for an acknowledgment from the server. The client MAY retry up to two more times (for a total of 3 attempts) before considering the server down or unreachable. The client MUST NOT retry a first time before 90% of the LLQ‑LEASE has expired and MUST NOT retry again before 95% of the LLQ‑LEASE has expired. If the server is determined to be down, the client MAY periodically 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 hour.

LLQ Refresh Acknowledgment Upon receiving an LLQ Refresh message, a server MUST send an acknowledgment of the Refresh. This acknowledgment is formatted like the "ACK + Answers" message described in , but with the following variations:

• It contains no answers.
• The LLQ‑OPCODE is set to LLQ‑REFRESH.
• NO‑SUCH‑LLQ MUST be returned as an error code if the client attempts to refresh an expired or non-existent LLQ (as determined by the LLQ‑ID in the request).
• The LLQ‑ID in the acknowledgment is set to the LLQ‑ID in the request.

Security Considerations 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. Note: This section contains no new protocol elements -- it serves only to explain the rationale behind protocol elements described above as they relate to security.

Server DoS LLQs require that servers be stateful, maintaining entries for each LLQ over a potentially long period of time. If unbounded in quantity, these entries may overload the server. By returning SERV‑FULL in Setup Challenges, the server may limit the maximum number of LLQs it maintains. Additionally, the server may return SERV‑FULL to limit the number of LLQs requested for a single name and type, or by a single client. This throttling may be in the form of a hard limit, or, preferably, by token-bucket rate limiting. Such rate limiting should occur rarely in normal use and is intended to prevent DoS attacks -- thus, it is not built into the protocol explicitly but is instead implemented at the discretion of an administrator via the SERV‑FULL error and the LLQ‑LEASE field to indicate a retry time to the client.

Client Packet Storms 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 client with packets. This is achieved via the four-way handshake upon setup, demonstrating reachability and willingness of the client to participate, and by requiring that gratuitous responses be ACK'd by the client. Additionally, rate limiting by LLQ client address, as described in , serves to limit the number of packets that can be delivered to an unsuspecting client.

Spoofing A large random ID greatly reduces the risk of an off-path attacker sending spoof packets to the client (containing spoof events) or to the server (containing phony requests or refreshes).

IANA Considerations The EDNS(0) OPTION CODE 1 has already been assigned for this DNS extension. IANA has updated the record in the "DNS EDNS0 Option Codes (OPT)" registry from "On-hold" to "Optional" and has set the reference to this document. TCP and UDP ports 5352 have already been assigned for LLQ. IANA has added a reference to this document.

References Normative References This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK] This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. This memo provides information for the Internet community. This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the implementation of Apple Inc.'s Back to My Mac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators (NATs) and mobility of devices. This document is not an Internet Standards Track specification; it is published for informational purposes. As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements. The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. This document clarifies and updates several requirements of RFCs 4787, 5382, and 5508 based on operational and development experience. The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44). This document updates RFCs 4787, 5382, and 5508. This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts. Verizon Federal Network Systems

weddy@grc.nasa.gov

TCP

Problems with the LLQ Protocol 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. LLQ's IETF Standards Track successor, "DNS Push Notifications" , does not suffer from these problems, so all existing LLQ implementations are RECOMMENDED to migrate to using DNS Push Notifications, and all new implementations are RECOMMENDED to implement DNS Push Notifications instead of LLQ. 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). 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. of this LLQ specification states, "Servers MUST NOT 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 , is built using DNS Stateful Operations , 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 . 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 avoids this problem by using an underlying stream protocol (TLS/TCP) to deal with packing small multiple messages into larger IP packets for efficiency. 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 corrects this error by having only one single consistent way to deliver results. 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 . 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) and/or Port Control Protocol (PCP) 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.

Acknowledgments The concepts described in this document were originally explored, developed, and implemented with help from and . 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. Thanks to Independent Stream Editor for his support and assistance in the publication of this RFC.

Authors' Addresses Apple Inc.

One Apple Park Way Cupertino CA 95014 United States of America +1 (408) 996-1010 cheshire@apple.com

Apple Inc.

One Apple Park Way Cupertino CA 95014 United States of America +1 (408) 996-1010 marc@apple.com