Apple's DNS Long-Lived Queries Protocol
RFC 8764
Document | Type |
RFC - Informational
(June 2020; No errata)
Was draft-sekar-dns-llq (individual)
|
|
---|---|---|---|
Authors | Stuart Cheshire , Marc Krochmal | ||
Last updated | 2020-06-22 | ||
Stream | ISE | ||
Formats | plain text html xml pdf htmlized bibtex | ||
IETF conflict review | conflict-review-sekar-dns-llq | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2019-08-13) | ||
IESG | IESG state | RFC 8764 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | Adrian Farrel <rfc-ise@rfc-editor.org> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack |
Independent Submission S. Cheshire Request for Comments: 8764 M. Krochmal Category: Informational Apple Inc. ISSN: 2070-1721 June 2020 Apple's DNS Long-Lived Queries Protocol Abstract 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 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 1.1. Transition to DNS Push Notifications 2. Conventions and Terminology Used in This Document 3. Mechanisms 3.1. Assigned Numbers 3.2. Opt-RR Format 4. LLQ Address and Port Identification 5. LLQ Setup 5.1. Setup Message Retransmission 5.2. LLQ Setup Four-Way Handshake 5.2.1. Setup Request 5.2.2. Setup Challenge 5.2.3. Challenge Response 5.2.4. ACK + Answers 5.3. Resource Record TTLs 6. Event Responses 6.1. Add Events 6.2. Remove Events 6.3. Gratuitous Response Acknowledgments 7. LLQ Lease-Life Expiration 7.1. Refresh Request 7.2. LLQ Refresh Acknowledgment 8. Security Considerations 8.1. Server DoS 8.2. Client Packet Storms 8.3. Spoofing 9. IANA Considerations 10. References 10.1. Normative References 10.2. Informative References Appendix A. Problems with the LLQ Protocol Acknowledgments Authors' Addresses 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 DNSShow full document text