Apple's DNS Long-Lived Queries Protocol
RFC 8764

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01
• 02
• 03
• 04
• 05
• 06



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 DNS