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 https://www.rfc-editor.org/info/rfc8764.¶

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 (https://trustee.ietf.org/license-info) 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

1. Introduction

In dynamic environments, DNS-based Service Discovery [RFC6763] 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 [RFC6762] 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 [RFC8765] as explained in Section 1.1.¶

4. 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 [RFC8765].¶

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 [RFC2782] for this name. The SRV RDATA is as follows:¶

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 Section 5, "LLQ Setup".¶

Servers should send all messages to the source address and port of the LLQ setup message received from the client.¶

5. 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 Section 8, "Security Considerations").¶

6. 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.¶

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.¶

7. LLQ Lease-Life Expiration

8. 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.¶

Appendix A. 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" [RFC8765], 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.¶

Section 5.1 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 [RFC8765], is built using DNS Stateful Operations [RFC8490], 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 [SYN] [RFC4953].¶

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 [RFC8765] 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 [RFC8765] 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 [RFC4787] [RFC5382] [RFC7857]. 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) [RFC6886] and/or Port Control Protocol (PCP) [RFC6887] 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.¶

Authors' Addresses