idnits 2.17.1 draft-sekar-dns-llq-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 215 has weird spacing: '...in name emp...' == Line 352 has weird spacing: '...esponse clie...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 16, 2019) is 1715 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-15 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Cheshire 3 Internet-Draft M. Krochmal 4 Intended status: Informational Apple Inc. 5 Expires: February 17, 2020 August 16, 2019 7 DNS Long-Lived Queries 8 draft-sekar-dns-llq-05 10 Abstract 12 DNS Long-Lived Queries (LLQ) is a protocol for extending the DNS 13 protocol to support change notification, thus allowing clients to 14 learn about changes to DNS data without polling the server. From 15 2005 onwards, LLQ was implemented in Apple products including Mac OS 16 X, Bonjour for Windows, and AirPort wireless base stations. In 2019, 17 the LLQ protocol was superseded by the IETF Standards Track RFC "DNS 18 Push Notifications", which builds on experience gained with the LLQ 19 protocol to create a superior replacement. 21 The existing deployed LLQ protocol is documented here to give 22 background regarding the operational experience that informed the 23 development of DNS Push Notifications, and to help facilitate a 24 smooth transition from LLQ to DNS Push Notifications. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 17, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Transition to DNS Push Notifications . . . . . . . . . . 4 59 2. Conventions and Terminology Used in this Document . . . . . . 4 60 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. New Assigned Numbers . . . . . . . . . . . . . . . . . . 5 62 3.2. Opt-RR Format . . . . . . . . . . . . . . . . . . . . . . 6 63 4. LLQ Address and Port Identification . . . . . . . . . . . . . 7 64 5. LLQ Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Setup Message Retransmission . . . . . . . . . . . . . . 9 66 5.2. LLQ Setup Four-Way Handshake . . . . . . . . . . . . . . 9 67 5.2.1. Setup Request . . . . . . . . . . . . . . . . . . . . 10 68 5.2.2. Setup Challenge . . . . . . . . . . . . . . . . . . . 11 69 5.2.3. Challenge Response . . . . . . . . . . . . . . . . . 14 70 5.2.4. ACK + Answers . . . . . . . . . . . . . . . . . . . . 15 71 5.3. Resource Record TTLs . . . . . . . . . . . . . . . . . . 16 72 6. Event Responses . . . . . . . . . . . . . . . . . . . . . . . 17 73 6.1. Add Events . . . . . . . . . . . . . . . . . . . . . . . 18 74 6.2. Remove Events . . . . . . . . . . . . . . . . . . . . . . 18 75 6.3. Gratuitous Response Acknowledgments . . . . . . . . . . . 18 76 7. LLQ Lease-Life Expiration . . . . . . . . . . . . . . . . . . 19 77 7.1. Refresh Request . . . . . . . . . . . . . . . . . . . . . 19 78 7.2. LLQ Refresh Acknowledgment . . . . . . . . . . . . . . . 20 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 8.1. Server DOS . . . . . . . . . . . . . . . . . . . . . . . 21 81 8.2. Client Packet Storms . . . . . . . . . . . . . . . . . . 21 82 8.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 21 83 9. Problems with the LLQ Protocol . . . . . . . . . . . . . . . 22 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 88 12.2. Informative References . . . . . . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 91 1. Introduction 93 In dynamic environments, DNS Service Discovery [RFC6763] benefits 94 significantly from clients being able to learn about changes to DNS 95 information via a mechanism that is both more timely and more 96 efficient than simple polling. Such a mechanism enables "live 97 browses" that learn when a new instance of a service appears, or when 98 an existing service disappears from the network, and allows clients 99 to monitor changes to a service. Multicast DNS [RFC6762] supports 100 this natively. When a host on the network publishes or deletes DNS 101 records, these changes are multicast to other hosts on the network. 102 These hosts deliver the change notifications to interested clients 103 (applications running on the host). Hosts also send occasional 104 queries to the network in case gratuitous announcements are not 105 received due to packet loss, and to detect records lost due to their 106 publishers crashing or having become disconnected from the network. 108 This document defines an extension to DNS that enables a client to 109 issue long-lived queries that allow a DNS server to notify clients 110 about changes to DNS data. This is a more scalable and practical 111 solution than can be achieved by polling of the name server because a 112 low polling rate could leave the client with stale information while 113 a high polling rate would have an adverse impact on the network and 114 server. 116 The mechanism defined in this document is now being replaced by DNS 117 Push Notifications [Push] as explained below in Section 1.1. 119 1.1. Transition to DNS Push Notifications 121 The LLQ protocol enjoyed over a decade of useful operation, enabling 122 timely live updates for the service discovery user interface in 123 Apple's Back to My Mac [RFC6281] service. 125 However, some problems were discovered, as described in Section 9. 126 This operational experience with LLQ informed the design of its IETF 127 Standards Track successor, DNS Push Notifications [Push]. Since no 128 further work is being done on the LLQ protocol, this LLQ 129 specification will not be updated to remedy these problems. 131 All existing LLQ implementations are RECOMMENDED to migrate to using 132 DNS Push Notifications instead. 134 For existing LLQ servers, they are RECOMMENDED to implement and 135 support DNS Push Notifications, so that clients can begin migrating 136 to the newer protocol. 138 For existing LLQ clients, they are RECOMMENDED to query for the 139 "_dns-push-tls._tcp." SRV record first, and only if DNS Push 140 fails, then fall back to query for "_dns-llq._udp." instead. 142 This will cause clients to prefer the newer protocol when possible. 143 It is RECOMMENDED that clients always attempt DNS Push Notifications 144 first for every new request, and only if that fails, then back to 145 using LLQ. Clients SHOULD NOT record that a given server only speaks 146 LLQ and subsequently default to LLQ for that server, since server 147 software gets updated, and even a server that speaks only LLQ today, 148 may be updated to support DNS Push Notifications tomorrow. 150 New client and server implementations are RECOMMENDED to support only 151 DNS Push Notifications. 153 2. Conventions and Terminology Used in this Document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in 158 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 3. Mechanisms 163 DNS Long-Lived Queries (DNS-LLQ) is implemented using the standard 164 DNS message format [RFC1035] in conjunction with an EDNS(0) OPT 165 pseudo-RR [RFC6891] with a new OPT and RDATA format specified here. 166 Encoding the LLQ request in an OPT RR allows for implementation of 167 LLQ with minimal modification to a name server's front-end. If a DNS 168 query containing an LLQ option is sent to a server that does not 169 implement LLQ, a server that complies with the EDNS(0) specification 170 [RFC6891] will silently ignore the unrecognized option and answer the 171 request as a normal DNS query, without establishing any long-lived 172 state, and without returning an LLQ option in its response. If a DNS 173 query containing an LLQ option is sent to a server that does not 174 implement EDNS(0) at all, the server may silently ignore the EDNS(0) 175 OPT pseudo-RR, or it may return a nonzero RCODE. However, in 176 practice this issue is mostly theoretical, since having a zone's 177 _dns-llq._udp. SRV record target a host that does not implement 178 LLQ is a configuration error. 180 Note that this protocol is designed for data set sizes of a few dozen 181 resource records at most, and change rates no more than one every ten 182 seconds on average. Data sets in response to queries that frequently 183 exceed a single packet, or that experience a rapid change rate, may 184 have undesirable performance implications. 186 3.1. New Assigned Numbers 188 This section describes constants uses in this document. 190 EDNS(0) Option Code (recorded with IANA): 191 LLQ 1 193 LLQ-PORT 5352 (recorded with IANA) 195 LLQ Error Codes (specific to this LLQ EDNS(0) Option): 196 NO-ERROR 0 197 SERV-FULL 1 198 STATIC 2 199 FORMAT-ERR 3 200 NO-SUCH-LLQ 4 201 BAD-VERS 5 202 UNKNOWN-ERR 6 204 LLQ Opcodes (specific to this LLQ EDNS(0) Option): 205 LLQ-SETUP 1 206 LLQ-REFRESH 2 207 LLQ-EVENT 3 209 3.2. Opt-RR Format 211 All OPT-RRs used in LLQs are formatted as follows: 213 Field Name Field Type Description 214 --------------------------------------------------------------------- 215 NAME domain name empty (root domain) 216 TYPE u_int16_t OPT 217 CLASS u_int16_t 0* 218 TTL u_int32_t 0 219 RDLEN u_int16_t describes RDATA 220 RDATA octet stream (see below) 222 * The CLASS field indicates, as per the EDNS(0) specification 223 [RFC6891], the sender's UDP payload size. However, clients and 224 servers need not be required to determine their reassembly buffer 225 size, path MTU, etc. to support LLQ. Thus, the sender of an LLQ 226 Request or Response MAY set the CLASS field to 0. The recipient MUST 227 ignore the class field if it is set to 0. 229 RDATA Format: 231 Field Name Field Type Description 232 --------------------------------------------------------------------- 233 OPTION-CODE u_int16_t LLQ 234 OPTION-LENGTH u_int16_t Length of following fields, as 235 appropriate 236 VERSION u_int16_t Version of LLQ protocol implemented 237 LLQ-OPCODE u_int16_t Identifies LLQ operation 238 ERROR-CODE u_int16_t Identifies LLQ errors 239 LLQ-ID u_int64_t Identifier for an LLQ 240 LEASE-LIFE u_int32_t Requested or granted life of LLQ, in 241 seconds 243 This data format, consisting of (OPTION-CODE, OPTION-LEN, 244 LLQ-Metadata) tuples, may be repeated an arbitrary number of times in 245 the RDATA section, with the RDLEN field set accordingly. 247 4. LLQ Address and Port Identification 249 The client requires a mechanism to determine to which server it 250 should send LLQ operations. 252 Additionally, some firewalls block direct communication with a name 253 server on port 53 to avoid spoof responses. However, this direct 254 communication is necessary for LLQs. Thus, servers MAY listen for 255 LLQs on a different port (typically 5352). Clients also therefore 256 need a mechanism to determine to which port to send LLQ operations. 258 The client determines the server responsible for a given LLQ much as 259 a client determines to which server to send a dynamic update. The 260 client begins by sending a standard DNS query for the name of the 261 LLQ, with type SOA. The server MUST answer with that SOA record in 262 the Answer section, if the record exists. The server SHOULD include 263 an SOA record for that name's zone in the Authority section, if the 264 LLQ name (type SOA) does not exist. For example, a query for 265 "_ftp._tcp.example.com." may return an SOA record named 266 "example.com." in the Authority section if there is no SOA record 267 named "_ftp._tcp.example.com." If, in this case, the server does not 268 include the SOA record in the Authority section, the client strips 269 the leading label from the name and tries again, repeating until an 270 answer is received. 272 This iterative zone apex discovery algorithm is described in more 273 detail in the DNS Push Notifications specification [Push]. 275 Upon learning the zone (SOA), the client then constructs and sends an 276 SRV query for the name _dns-llq._udp., 277 e.g., _dns-llq._udp.example.com. 279 A server implementing LLQ MUST answer with an SRV record [RFC2782] 280 for this name. The SRV RDATA is as follows: 282 PRIORITY typically 0 283 WEIGHT typically 0 284 PORT typically 53 or 5352 285 TARGET name of server providing LLQs for the requested zone 287 The server SHOULD include its address record(s) in the Additional 288 section of the response. 290 If the server does not include its address record in the Additional 291 section, the client SHOULD query explicitly for the address record 292 with the name of the SRV target. 294 The client MUST send all LLQ requests, refreshes, and acknowledgments 295 to the name server specified in the SRV target, at the address 296 contained in the address record for that target. Note that the 297 queries described in this section (including those for SOA and SRV 298 records) MAY be sent to an intermediate DNS recursive resolver -- 299 they need not be sent directly to the name server. 301 If, on issuing the SRV query, the client receives an NXDOMAIN 302 response indicating that the SRV record does not exist, the client 303 SHOULD conclude that the server does not support an LLQ in the 304 requested zone. The client then SHOULD NOT send an LLQ request for 305 the desired name, instead utilizing the behavior for LLQ-unaware 306 servers described in Section 5 "LLQ Setup". 308 Servers should send all messages to the source address and port of 309 the LLQ setup message received from the client. 311 5. LLQ Setup 313 An LLQ is initiated by a client, and is completed via a four-way 314 handshake. This handshake provides resilience to packet loss, 315 demonstrates client reachability, and reduces denial of service 316 attack opportunities (see Section 8 "Security Considerations"). 318 5.1. Setup Message Retransmission 320 LLQ Setup Requests and Responses sent by the client SHOULD be 321 retransmitted if no acknowledgments are received. The client SHOULD 322 re-try up to two more times (for a total of 3 attempts) before 323 considering the server down or unreachable. The client MUST wait at 324 least 2 seconds before the first retransmission and 4 seconds between 325 the first and second retransmissions. The client SHOULD listen for a 326 response for at least 8 seconds after the 3rd attempt before 327 considering the server down or unreachable. Upon determining a 328 server to be down, a client MAY periodically attempt to re-initiate 329 an LLQ setup, at a rate of not more than once per hour. 331 Servers MUST NOT re-transmit acknowledgments that do not generate 332 responses from the client. Retransmission in setup is client-driven, 333 freeing servers from maintaining timers for incomplete LLQ setups. 334 If servers receive duplicate messages from clients (perhaps due to 335 the loss of the server's responses mid-flight), the server MUST 336 re-send its reply (possibly modifying the LEASE-LIFE as described in 337 Section 5.2.4 "ACK + Answers"). 339 Servers MUST NOT garbage collect LLQs that fail to complete the four- 340 way handshake until the initially granted LEASE-LIFE has elapsed. 342 5.2. LLQ Setup Four-Way Handshake 344 The four phases of the handshake include: 346 1) Initial Request client to server, identifies LLQ(s) requested 348 2) Challenge server to client, provides error(s) for 349 requested LLQs, and unique identifiers for 350 the successful requests 352 3) Challenge Response client to server, echoes identifier(s), 353 demonstrating client's reachability and 354 willingness to participate 356 4) ACK + Answers server to client, confirms setup and 357 provides initial answers 359 5.2.1. Setup Request 361 A request for an LLQ is formatted like a standard DNS query, but with 362 an OPT RR containing LLQ metadata in its Additional section. LLQ 363 setup requests are identified by the LLQ-SETUP opcode and a 364 zero-valued LLQ-ID. 366 The request MAY contain multiple questions to set up multiple LLQs. 367 A request consisting of multiple questions MUST contain multiple LLQ 368 metadata sections, one per question, with metadata sections in the 369 same order as the questions they correspond to (i.e., the first 370 metadata section corresponds to the first question, the second 371 metadata section corresponds to the second question, etc.) If 372 requesting multiple LLQs, clients SHOULD request the same LEASE-LIFE 373 for each LLQ. Requests over UDP MUST NOT contain multiple questions 374 if doing so would cause the message to not fit in a single packet. 376 A client MUST NOT request multiple identical LLQs (i.e., containing 377 the same qname/type/class) from a single source IP address and port. 378 This requirement is to avoid unnecessary load on servers. 380 The query MUST NOT be for record type ANY (255), class ANY (255), or 381 class NONE (0). 383 Setup Request OPT-RR LLQ Metadata Format: 385 Field Name Field Type Description 386 --------------------------------------------------------------------- 387 OPTION-CODE u_int16_t LLQ (1) 388 OPTION-LENGTH u_int16_t Length of following fields (18) 389 VERSION u_int16_t Version of LLQ protocol implemented 390 by requester (1) 391 LLQ-OPCODE u_int16_t LLQ-SETUP (1) 392 ERROR-CODE u_int16_t NOERROR (0) 393 LLQ-ID u_int64_t 0 394 LEASE-LIFE u_int32_t Desired life of LLQ request 396 These fields MUST be repeated once for each additional query in the 397 Question section. 399 5.2.2. Setup Challenge 401 Upon receiving an LLQ Setup Request, a server implementing LLQs will 402 send a Setup Challenge to the requester (client). An LLQ Setup 403 Challenge is a DNS Response, with the DNS message ID matching that of 404 the request, and with all questions contained in the request present 405 in the Question section of the response. Additionally, the challenge 406 contains a single OPT-RR with an LLQ metadata section for each LLQ 407 request, indicating the success or failure of each request. Metadata 408 sections MUST be in the same order as the questions they correspond 409 to. Note that in a request containing multiple questions some LLQs 410 may succeed, while others may fail. 412 Setup Challenge OPT-RR RDATA Format: 414 Field Name Field Type Description 415 --------------------------------------------------------------------- 416 OPTION-CODE u_int16_t LLQ (1) 417 OPTION-LENGTH u_int16_t Length of following fields (18) 418 VERSION u_int16_t Version of LLQ protocol implemented 419 in server (1) 420 LLQ-OPCODE u_int16_t LLQ-SETUP (1) 421 ERROR-CODE u_int16_t [As Appropriate] 422 LLQ-ID u_int64_t [As Appropriate] 423 LEASE-LIFE u_int32_t [As Appropriate] 425 These fields MUST be repeated once for each query in the Questions 426 section of the Setup Request. 428 LLQ Metadata field descriptions: 430 ERROR-CODE: Possible values include: 432 NO-ERROR: The LLQ Setup Request was successful. 434 FORMAT-ERR: The LLQ was improperly formatted. Note that if the 435 rest of the DNS message is properly formatted, the 436 DNS header error code MUST NOT include a format error 437 code, as this would cause confusion between a server 438 that does not understand the LLQ format, and a client 439 that sends malformed LLQs. 441 SERV-FULL: The server cannot grant the LLQ request because it is 442 overloaded, or the request exceeds the server's rate 443 limit (see Section 8 "Security Considerations"). 444 Upon returning this error, the server MUST include 445 in the LEASE-LIFE field a time interval, in seconds, 446 after which the client may re-try the LLQ Setup. 448 STATIC: The data for this name and type is not expected to 449 change frequently, and the server therefore does not 450 support the requested LLQ. The client MUST NOT poll 451 for this name and type, nor should it re-try the LLQ 452 Setup, and should instead honor the normal resource 453 record TTLs returned. 455 BAD-VERS: The protocol version specified in the client's 456 request is not supported by the server. 458 UNKNOWN-ERR: The LLQ was not granted for an unknown reason 460 LLQ-ID: On success, a random number generated by the server that is 461 unique for the requested name/type/class. The LLQ-ID SHOULD be an 462 unpredictable random number. A possible method of allocating LLQ-IDs 463 with minimal bookkeeping would be to store the time, in seconds since 464 the Epoch, in the high 32 bits of the field, and a cryptographically 465 generated 32-bit random integer in the low 32 bits. 467 On error, the LLQ-ID is set to 0. 469 LEASE-LIFE: On success, the actual life of the LLQ, in seconds. 470 Value may be greater than, less than, or equal to the value requested 471 by the client, as per the server administrator's policy. The server 472 MAY discard the LLQ after this LEASE-LIFE expires unless the LLQ has 473 been renewed by the client (see Section 7 "LLQ Lease-Life 474 Expiration"). The server MUST NOT generate events (see Section 6 475 "Event Responses") for expired LLQs. 477 On SERV-FULL error, LEASE-LIFE MUST be set to a time interval, in 478 seconds, after which the client may re-try the LLQ Setup. 480 On other errors, the LEASE-LIFE MUST be set to 0. 482 5.2.3. Challenge Response 484 Upon issuing a Setup Request, a client listens for a Setup Challenge 485 (5.2.2), re-transmitting the request as necessary (5.1). After 486 receiving a successful Challenge, the client SHOULD send a Challenge 487 Response to the server. This Challenge Response is a DNS request 488 with questions from the request and challenge, and a single OPT-RR in 489 the Additional section, with the OPT-RR RDATA identical to the OPT-RR 490 RDATA contained in the Setup Challenge (i.e., echoing, for each set 491 of fields, the random LLQ-ID and the granted lease life). If the 492 challenge response contains multiple questions, the first question 493 MUST correspond to the first OPT-RR RDATA tuple, etc. 495 If the Setup Request fails with a STATIC error, the client MUST NOT 496 poll the server. The client SHOULD honor the resource record TTLs 497 contained in the response. 499 If the Setup Request fails with a SERV-FULL error, the client MAY 500 re-try the LLQ Setup Request (5.2.1) after the time indicated in the 501 LEASE-LIFE field. 503 If the Setup Request fails with an error other than STATIC or 504 SERV-FULL, or the server is determined not to support LLQ (i.e., the 505 client receives a DNS response with a nonzero RCODE, or a DNS 506 response containing no LLQ option), the client MAY poll the server 507 periodically with standard DNS queries, inferring Add and Remove 508 events (see Section 6 "Event Responses") by comparing answers to 509 these queries. The client SHOULD NOT poll more than once every 15 510 minutes for a given query. The client MUST NOT poll if it receives a 511 STATIC error code in the acknowledgment. 513 5.2.4. ACK + Answers 515 Upon receiving a correct Challenge Response, a server MUST return an 516 acknowledgment, completing the LLQ setup, and provide all current 517 answers to the question(s). 519 To acknowledge a successful Challenge Response, i.e., a Challenge 520 Response in which the LLQ-ID and LEASE-LIFE echoed by the client 521 match the values issued by the server, the server MUST send a DNS 522 response containing all available answers to the question(s) 523 contained in the original Setup Request, along with all additional 524 resource records appropriate for those answers in the Additional 525 section. The Additional section also contains an OPT-RR formatted as 526 follows: 528 Successful ACK + Answers OPT-RR RDATA Format: 530 Field Name Field Type Description 531 --------------------------------------------------------------------- 532 OPTION-CODE u_int16_t LLQ 533 OPTION-LENGTH u_int16_t Length of following fields, as 534 appropriate 535 VERSION u_int16_t Version of LLQ protocol implemented 536 in server 537 LLQ-OPCODE u_int16_t LLQ-SETUP (1) 538 ERROR-CODE u_int16_t NO-ERROR 539 LLQ-ID u_int64_t Originally granted ID, echoed in 540 client's Response 541 LEASE-LIFE u_int32_t Remaining life of LLQ, in seconds 543 If there is a significant delay in receiving a Challenge Response, or 544 multiple Challenge Responses are issued (possibly because they were 545 lost en route to the client, causing the client to re-send the 546 Challenge Response), the server MAY decrement the LEASE-LIFE by the 547 time elapsed since the Setup Challenge was initially issued. 549 If the setup is completed over UDP and all initially available 550 answers to the question(s), additional records, and the OPT-RR do not 551 fit in a single packet, some or all additional records (excluding the 552 OPT-RR) MUST be omitted. If, after omission of all additional 553 records, the answers still do not fit in a single message, answers 554 MUST be removed until the message fits in a single packet. These 555 answers not delivered in the ACK + Answers MUST be delivered without 556 undue delay to the client via Add Events (Section 6 "Event 557 Responses"). 559 5.3. Resource Record TTLs 561 The TTLs of resource records contained in answers to successful LLQs 562 SHOULD be ignored by the client. The client MAY cache LLQ answers 563 until the client receives a gratuitous announcement (see Section 6 564 "Event Responses") indicating that the answer to the LLQ has changed. 565 The client MUST NOT cache answers after the LLQs LEASE-LIFE expires 566 without being refreshed (see Section 7 "LLQ Lease-Life Expiration"). 567 If an LLQ request fails, the client SHOULD NOT cache answers for a 568 period longer than the client's polling interval. 570 Note that resource records intended specifically to be transmitted 571 via LLQs (e.g., DNS Service Discovery resource records) may have 572 unusually short TTLs. This is because it is assumed that the records 573 may change frequently, and that a client's cache coherence will be 574 maintained via the LLQ and gratuitous responses. Short TTLs prevent 575 stale information from residing in intermediate DNS recursive 576 resolvers that are not LLQ-aware. 578 TTLs of resource records included in the Additional section of an LLQ 579 response (which do not directly answer the LLQ) SHOULD be honored by 580 the client. 582 6. Event Responses 584 When a change ("event") occurs to a name server's zone, the server 585 MUST check if the new or deleted resource records answer any LLQs. 586 If so, the changes MUST be communicated to the LLQ requesters in the 587 form of a gratuitous DNS response sent to the client, with the 588 question(s) being answered in the Question section, and answers to 589 these questions in the Answer section. The response also includes an 590 OPT RR in the Additional section. This OPT RR contains, in its 591 RDATA, an entry for each LLQ being answered in the message. Entries 592 must include the LLQ-ID. This reduces the potential for spoof events 593 being sent to a client. 595 Event Response OPT-RR RDATA Format: 597 Field Name Field Type Description 598 --------------------------------------------------------------------- 599 OPTION-CODE u_int16_t LLQ (1) 600 OPTION-LENGTH u_int16_t Length of following fields (18) 601 VERSION u_int16_t Version of LLQ protocol implemented 602 in server (1) 603 LLQ-OPCODE u_int16_t LLQ-EVENT (3) 604 ERROR-CODE u_int16_t 0 605 LLQ-ID u_int64_t [As Appropriate] 606 LEASE-LIFE u_int32_t 0 608 Gratuitous responses for a single LLQ MAY be batched, such that 609 multiple changes are communicated in a single message. Responses 610 MUST NOT be batched if this would cause a message that would 611 otherwise fit in a single packet to be truncated. While responses 612 MAY be deferred to provide opportunities for batching, responses 613 SHOULD NOT be delayed, for purposes of batching, for more than 30 614 seconds, as this would cause an unacceptable latency for the client. 616 After sending a gratuitous response, the server MUST listen for an 617 acknowledgment from the client. If the client does not respond, the 618 server MUST re-send the response. The server MUST re-send 2 times 619 (for a total of 3 transmissions), after which the server MUST 620 consider the client to be unreachable and delete its LLQ. The server 621 MUST listen for 2 seconds before re-sending the response, 4 more 622 seconds before re-sending again, and must wait an additional 8 623 seconds after the 3rd transmission before terminating the LLQ. 625 The DNS message header of the response SHOULD include an 626 unpredictable random number in the DNS message ID field, which is to 627 be echoed in the client's acknowledgement. 629 6.1. Add Events 631 Add events occur when a new resource record appears, usually as the 632 result of a dynamic update [RFC2136], that answers an LLQ. This 633 record must be sent in the Answer section of the event to the client. 634 Records that normally accompany this record in responses MAY be 635 included in the Additional section, as per truncation restrictions 636 described above. 638 6.2. Remove Events 640 Remove events occur when a resource record previously sent to a 641 client, either in an initial response, or in an Add Event, becomes 642 invalid (normally as a result of being removed via a dynamic update). 643 The deleted resource record is sent in the Answer section of the 644 event to the client. The resource record TTL is set to -1, 645 indicating that the record has been removed. 647 6.3. Gratuitous Response Acknowledgments 649 Upon receiving a gratuitous response ("event"), the client MUST send 650 an acknowledgment to the server. This acknowledgment is a DNS 651 response echoing the OPT-RR contained in the event, with the message 652 ID of the gratuitous response echoed in the message header. The 653 acknowledgment MUST be sent to the source IP address and port from 654 which the event originated. 656 7. LLQ Lease-Life Expiration 658 7.1. Refresh Request 660 If the client desires to maintain the LLQ beyond the duration 661 specified in the LEASE-LIFE field of the Ack + Answers (5.2), the 662 client MUST send a Refresh Request. A Refresh Request is identical 663 to an LLQ Challenge Response (5.3), but with the LLQ-OPCODE set to 664 LLQ-REFRESH. Unlike a Challenge Response, a Refresh Request returns 665 no answers. 667 The client SHOULD refresh an LLQ when 80% of its lease life has 668 elapsed. 670 As a means of reducing network traffic, when constructing refresh 671 messages the client SHOULD include all LLQs established with a given 672 server, even those not yet close to expiration. However, at least 673 one LLQ MUST have elapsed at least 80% of its original LEASE-LIFE. 674 The client MUST NOT include additional LLQs if doing so would cause 675 the message to no longer fit in a single packet. In this case, the 676 LLQs furthest from expiration should be omitted such that the message 677 fits in a single packet. (These LLQs SHOULD be refreshed in a 678 separate message when 80% of one or more of their lease lives have 679 elapsed.) When refreshing multiple LLQs simultaneously, the message 680 contains multiple questions, and a single OPT-RR with multiple LLQ 681 metadata sections, one per question, with the metadata sections in 682 the same order as the questions they correspond to. 684 The client SHOULD specify the original lease life granted in the LLQ 685 response as the desired LEASE-LIFE in the refresh request. If 686 refreshing multiple LLQs simultaneously, the client SHOULD request 687 the same lease life for all LLQs being refreshed (with the exception 688 of termination requests, see below). 690 To terminate an LLQ prior to its scheduled expiration (for instance, 691 when the client terminates a DNS Service Discovery browse operation, 692 or a client is about to go to sleep or shut down) the client 693 specifies a lease life of 0. 695 The client MUST listen for an acknowledgment from the server. The 696 client MAY re-try up to two more times (for a total of 3 attempts) 697 before considering the server down or unreachable. The client MUST 698 NOT re-try a first time before 90% of the lease life has expired, and 699 MUST NOT re-try again before 95% of the lease life has expired. If 700 the server is determined to be down, the client MAY periodically 701 attempt to re-establish the LLQ via an LLQ Setup Request message. 702 The client MUST NOT attempt the LLQ Setup Request more than once per 703 hour. 705 7.2. LLQ Refresh Acknowledgment 707 Upon receiving an LLQ Refresh message, a server MUST send an 708 acknowledgment of the Refresh. This acknowledgment is formatted like 709 the Setup ACK described in 5.2.3, but with the following variations: 711 The LLQ-OPCODE is set to LLQ-REFRESH. 713 NO-SUCH-LLQ MUST be returned as an error code if the client attempts 714 to refresh an expired or non-existent LLQ (as determined by the 715 LLQ-ID in the request). 717 The LLQ-ID in the acknowledgment is set to the LLQ-ID in the request. 719 8. Security Considerations 721 Without care taken in the design of protocols such as this, servers 722 may be susceptible to denial of service (DOS) attacks, and clients 723 may be subjected to packet storms. Mechanisms have been added to the 724 protocol to limit potential for these attacks. 726 Note: This section contains no new protocol elements -- it serves 727 only to explain the rationale behind protocol elements described 728 above, as they relate to security. 730 8.1. Server DOS 732 LLQs require that servers be stateful, maintaining entries for each 733 LLQ over a potentially long period of time. If unbounded in 734 quantity, these entries may overload the server. By returning 735 SERV-FULL in Setup Challenges, the sever may limit the maximum number 736 of LLQs it maintains. Additionally, the server may return SERV-FULL 737 to limit the number of LLQs requested for a single name and type, or 738 by a single client. This throttling may be in the form of a hard 739 limit, or, preferably, by token-bucket rate limiting. Such rate 740 limiting should occur rarely in normal use and is intended to prevent 741 DOS attacks -- thus it is not built into the protocol explicitly, but 742 is instead implemented at the discretion of an administrator via the 743 SERV-FULL error and the LEASE-LIFE field to indicate a retry time to 744 the client. 746 8.2. Client Packet Storms 748 In addition to protecting the server from DOS attacks, the protocol 749 limits the ability of a malicious host to cause the server to flood a 750 client with packets. This is achieved via the four-way handshake 751 upon setup, demonstrating reachability and willingness of the client 752 to participate, and by requiring that gratuitous responses be ACK'd 753 by the client. 755 Additionally, rate-limiting by LLQ client address, as described in 756 (8.1) serves to limit the number of packets that can be delivered to 757 an unsuspecting client. 759 8.3. Spoofing 761 A large random ID greatly reduces the risk of an off-path attacker 762 sending spoof packets to the client (containing spoof events) or to 763 the server (containing phony requests or refreshes). 765 9. Problems with the LLQ Protocol 767 In the course of using LLQ since 2005, some problems were discovered. 768 Since no further work is being done on the LLQ protocol, this LLQ 769 specification will not be updated to remedy these problems. 771 LLQ's IETF Standards Track successor, DNS Push Notifications [Push], 772 does not suffer from these problems, so all existing LLQ 773 implementations are RECOMMENDED to migrate to using DNS Push 774 Notifications, and all new implementations are RECOMMENDED to 775 implement DNS Push Notifications instead of LLQ. 777 Known problems with LLQ are documented here for the record. 779 An LLQ "Setup Challenge" message from server to client is identical 780 to an LLQ "ACK + Answers" message from server to client when there 781 are no current answers for the query. If there is packet loss, 782 retransmission, and duplication in the network, then a duplicated 783 "Setup Challenge" message arriving late at the client would look like 784 an "ACK + Answers" message with no answers, causing the client to 785 clear its cache of any records matching the query. 787 This LLQ specification states: "Servers MUST NOT garbage collect LLQs 788 that fail to complete the four-way handshake until the initially 789 granted LEASE-LIFE has elapsed." This is probably a mistake, since 790 it exposes LLQ servers to an easy resource-exhaustion denial-of- 791 service attack. DNS Push Notifications is built using DNS Stateful 792 Operations [RFC8490], which uses TLS over TCP, and a benefit of 793 building on TCP is that there are already established industry best 794 practices to guard against SYN flooding and similar attacks [SYN] 795 [RFC4953] 797 LLQ is built using UDP, and because the UDP protocol has no 798 standardized way of indicating the start and end of a session, 799 firewalls and NAT gateways tend to be fairly agressive about 800 recycling UDP mappings that they believe to be disused [RFC4787] 801 [RFC5382] [RFC7857]. Using a high keepalive traffic rate to maintain 802 firewall or NAT mapping state could remedy this, but would largely 803 defeat the purpose of using LLQ in the first place, which is to 804 provide efficient change notification without wasteful polling. 805 Because of this, existing LLQ clients use NAT Port Mapping Protocol 806 (NAT-PMP) [RFC6886] and/or Port Control Protocol (PCP) [RFC6887] to 807 establish longer port mapping lifetimes. This solves the problem, 808 but adds extra complexity, and doesn't work with firewalls and NAT 809 gateways that don't support NAT-PMP or PCP. By using TCP instead of 810 UDP, the DNS Push Notifications protocol benefits from better 811 longevity of sessions through firewalls and NAT gateways that don't 812 support NAT-PMP or PCP. 814 10. IANA Considerations 816 The EDNS(0) OPTION CODE 1 has already been assigned for this DNS 817 extension. IANA is requested to update the record in the DNS EDNS(0) 818 Option Codes registry from "On-hold" to "Optional", and to set the 819 reference to indicate the RFC number under which this document is 820 published. 822 TCP and UDP ports 5352 have already been assigned for LLQ. IANA is 823 requested to add a reference to indicate the RFC number under which 824 this document is published. 826 No additional IANA services are required by this document. 828 11. Acknowledgments 830 The concepts described in this document were originally explored, 831 developed and implemented with help from Chris Sharp and Roger 832 Pantos. 834 In 2005 and 2006 Kiren Sekar made significant contributions to the 835 first two drafts of this document, and he wrote much of the code for 836 the implementation of LLQ that shipped in Mac OS X 10.4 Tiger in 837 2005. 839 12. References 841 12.1. Normative References 843 [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 844 draft-ietf-dnssd-push-15 (work in progress), September 845 2018. 847 [RFC1035] Mockapetris, P., "Domain names - implementation and 848 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 849 November 1987, . 851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 852 Requirement Levels", BCP 14, RFC 2119, 853 DOI 10.17487/RFC2119, March 1997, 854 . 856 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 857 specifying the location of services (DNS SRV)", RFC 2782, 858 DOI 10.17487/RFC2782, February 2000, 859 . 861 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 862 for DNS (EDNS(0))", STD 75, RFC 6891, 863 DOI 10.17487/RFC6891, April 2013, 864 . 866 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 867 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 868 May 2017, . 870 12.2. Informative References 872 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 873 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 874 RFC 2136, DOI 10.17487/RFC2136, April 1997, 875 . 877 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 878 Translation (NAT) Behavioral Requirements for Unicast 879 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 880 2007, . 882 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 883 RFC 4953, DOI 10.17487/RFC4953, July 2007, 884 . 886 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 887 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 888 RFC 5382, DOI 10.17487/RFC5382, October 2008, 889 . 891 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 892 "Understanding Apple's Back to My Mac (BTMM) Service", 893 RFC 6281, DOI 10.17487/RFC6281, June 2011, 894 . 896 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 897 DOI 10.17487/RFC6762, February 2013, 898 . 900 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 901 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 902 . 904 [RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol 905 (NAT-PMP)", RFC 6886, DOI 10.17487/RFC6886, April 2013, 906 . 908 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 909 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 910 DOI 10.17487/RFC6887, April 2013, 911 . 913 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 914 S., and K. Naito, "Updates to Network Address Translation 915 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 916 DOI 10.17487/RFC7857, April 2016, 917 . 919 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 920 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 921 BCP 14, RFC 8490, DOI 10.17487/RFC8490, October 2018, 922 . 924 [SYN] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The 925 Internet Protocol Journal, Cisco Systems, Volume 9, 926 Number 4, December 2006. 928 Authors' Addresses 930 Stuart Cheshire 931 Apple Inc. 932 One Apple Park Way 933 Cupertino, CA 95014 934 United States of America 936 Phone: +1 (408) 996-1010 937 Email: cheshire@apple.com 939 Marc Krochmal 940 Apple Inc. 941 One Apple Park Way 942 Cupertino, California 95014 943 USA 945 Email: marc@apple.com