idnits 2.17.1 draft-sekar-dns-llq-03.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 199 has weird spacing: '...in name emp...' == Line 351 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 (March 4, 2019) is 1877 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 ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) Summary: 1 error (**), 0 flaws (~~), 5 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: September 5, 2019 March 4, 2019 7 DNS Long-Lived Queries 8 draft-sekar-dns-llq-03 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 2007 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 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 5, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Transition to DNS Push Notifications . . . . . . . . . . 4 54 2. Conventions and Terminology Used in this Document . . . . . . 4 55 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. New Assigned Numbers . . . . . . . . . . . . . . . . . . 5 57 3.2. Opt-RR Format . . . . . . . . . . . . . . . . . . . . . . 6 58 4. LLQ Address and Port Identification . . . . . . . . . . . . . 7 59 4.1. Server Address and Port Identification . . . . . . . . . 7 60 4.2. Client Address and Port Identification . . . . . . . . . 8 61 5. LLQ Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 5.1. Setup Message Retransmission . . . . . . . . . . . . . . 9 63 5.2. LLQ Setup Four-Way Handshake . . . . . . . . . . . . . . 9 64 5.2.1. Setup Request . . . . . . . . . . . . . . . . . . . . 10 65 5.2.2. Setup Challenge . . . . . . . . . . . . . . . . . . . 11 66 5.2.3. Challenge Response . . . . . . . . . . . . . . . . . 14 67 5.2.4. ACK + Answers . . . . . . . . . . . . . . . . . . . . 15 68 5.3. Resource Record TTLs . . . . . . . . . . . . . . . . . . 16 69 6. Event Responses . . . . . . . . . . . . . . . . . . . . . . . 17 70 6.1. Add Events . . . . . . . . . . . . . . . . . . . . . . . 18 71 6.2. Remove Events . . . . . . . . . . . . . . . . . . . . . . 18 72 6.3. Gratuitous Response Acknowledgments . . . . . . . . . . . 18 73 7. LLQ Lease-Life Expiration . . . . . . . . . . . . . . . . . . 19 74 7.1. Refresh Request . . . . . . . . . . . . . . . . . . . . . 19 75 7.2. LLQ Refresh Acknowledgment . . . . . . . . . . . . . . . 20 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 77 8.1. Server DOS . . . . . . . . . . . . . . . . . . . . . . . 21 78 8.2. Client Packet Storms . . . . . . . . . . . . . . . . . . 21 79 8.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 21 80 9. Problems with the LLQ protocol . . . . . . . . . . . . . . . 22 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 82 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 85 12.2. Informative References . . . . . . . . . . . . . . . . . 24 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 88 1. Introduction 90 In dynamic environments, DNS Service Discovery [RFC6763] benefits 91 significantly from clients being able to learn about changes to DNS 92 information via a mechanism that is both more timely and more 93 efficient than simple polling. Such a mechanism enables "live 94 browses" that learn when a new instance of a service appears, or when 95 an existing service disappears from the network, and allows clients 96 to monitor changes to a service. Multicast DNS [RFC6762] supports 97 this natively. When a host on the network publishes or deletes DNS 98 records, these records are multicast to other hosts on the network. 99 These hosts deliver the records to interested clients (applications 100 running on the host). Hosts also send occasional queries to the 101 network in case gratuitous announcements are not received due to 102 packet loss, and to detect records lost due to their publishers 103 crashing or having become disconnected from the network. 105 There is currently no equivalent in traditional unicast DNS. Queries 106 are "one-shot" -- a name server will answer a query once, returning 107 the results available at that instant in time. Changes could be 108 inferred via polling of the name server. This solution is not 109 scalable, however, as a low polling rate could leave the client with 110 stale information, and a high polling rate would have an adverse 111 impact on the network and server. 113 Therefore, an extension to DNS is required that enables a client to 114 issue long-lived queries. This extension would allow a DNS server to 115 notify clients about changes to DNS data. 117 1.1. Transition to DNS Push Notifications 119 The LLQ protocol enjoyed over a decade of useful operation, enabling 120 timely live updates for the service discovery user interface in 121 Apple's Back to My Mac [RFC6281] service. 123 Operational experience with LLQ informed the design of its IETF 124 Standards Track successor, DNS Push Notifications [Push]. 126 Because of the significant enhancements in DNS Push Notifications, 127 all existing LLQ implementations are encouraged to migrate to using 128 DNS Push Notifications instead. 130 For existing LLQ servers, they are encouraged to implement and 131 support DNS Push Notifications, so that clients can begin migrating 132 to the newer protocol. 134 For existing LLQ clients, they are encouraged to query for the 135 "_dns-push-tls._tcp." SRV record first, and only if DNS Push 136 fails, then fall back to query for "_dns-llq._udp." instead. 138 This will cause clients to prefer the newer protocol when possible. 139 It is recommended that clients always attempt DNS Push Notifications 140 first for every new request, and only if that fails, then back to 141 using LLQ. Clients SHOULD NOT record that a given server only speaks 142 LLQ and subsequently default to LLQ for that server, since server 143 software gets updated, and even a server that speaks only LLQ today, 144 may be updated to support DNS Push Notifications tomorrow. 146 New client and server implementations are encouraged to support only 147 DNS Push Notifications. 149 2. Conventions and Terminology Used in this Document 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in 154 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 3. Mechanisms 159 DNS Long-Lived Queries (DNS-LLQ) is implemented using the standard 160 DNS message format [RFC1035] in conjunction with an ENDS0 OPT 161 pseudo-RR [RFC2671] with a new OPT and RDATA format proposed here. 162 Encoding the LLQ request in an OPT RR allows for implementation of 163 LLQ with minimal modification to a name server's front-end, and will 164 cause servers that do not implement LLQ to automatically return an 165 appropriate error (NOTIMPL). 167 Note that this protocol is designed for moderate data set sizes, and 168 moderate change rates. Data sets in response to queries that 169 frequently exceed a single packet, or that experience a rapid change 170 rate, may have undesirable performance implications. 172 3.1. New Assigned Numbers 174 EDNS0 Option Code: 175 LLQ 1 177 LLQ-PORT 5352 179 Error Codes: 180 NO-ERROR 0 181 SERV-FULL 1 182 STATIC 2 183 FORMAT-ERR 3 184 NO-SUCH-LLQ 4 185 BAD-VERS 5 186 UNKNOWN-ERR 6 188 LLQ Opcodes: 189 LLQ-SETUP 1 190 LLQ-REFRESH 2 191 LLQ-EVENT 3 193 3.2. Opt-RR Format 195 All OPT-RRs used in LLQs are formatted as follows: 197 Field Name Field Type Description 198 --------------------------------------------------------------------- 199 NAME domain name empty (root domain) 200 TYPE u_int16_t OPT 201 CLASS u_int16_t 0* 202 TTL u_int32_t 0 203 RDLEN u_int16_t describes RDATA 204 RDATA octet stream (see below) 206 * The CLASS field indicates, as per [RFC2671], the sender's UDP 207 payload size. However, clients and servers need not be required to 208 determine their reassembly buffer size, path MTU, etc. to support 209 LLQ. Thus, the sender of an LLQ Request or Response MAY set the 210 CLASS field to 0. The recipient MUST ignore the class field if it is 211 set to 0. 213 RDATA Format: 215 Field Name Field Type Description 216 --------------------------------------------------------------------- 217 OPTION-CODE u_int16_t LLQ 218 OPTION-LENGTH u_int16_t Length of following fields, as 219 appropriate 220 VERSION u_int16_t Version of LLQ protocol implemented 221 LLQ-OPCODE u_int16_t Identifies LLQ operation 222 ERROR-CODE u_int16_t Identifies LLQ errors 223 LLQ-ID u_int64_t Identifier for an LLQ 224 LEASE-LIFE u_int32_t Requested or granted life of LLQ, in 225 seconds 227 This data format, consisting of (OPTION-CODE, OPTION-LEN, 228 LLQ-Metadata) tuples, may be repeated an arbitrary number of times in 229 the RDATA section, with the RDLEN field set accordingly. 231 4. LLQ Address and Port Identification 233 A client MAY send LLQ setup and control messages to an intermediate 234 DNS cache. If the cache serves as an intermediate LLQ proxy, it will 235 communicate directly with the client, and with the server on behalf 236 of one or more clients. 238 LLQ requests sent to a DNS Cache MUST be sent to port 53. 240 DNS caches not implementing LLQ proxying will return a NOTIMPL or 241 FORMERR error to the client in the DNS message header -- the 242 intermediate cache will not forward the request, as [RFC2671] 243 specifies that OPT-RRs are not to be forwarded. If the client 244 receives a NOTIMPL error from a DNS cache, the client SHOULD contact 245 the server directly. 247 4.1. Server Address and Port Identification 249 If a client's DNS cache does not implement LLQ proxying, the client 250 requires a mechanism to determine which server to send LLQ operations 251 to. Additionally, some firewalls block communication directly with a 252 name server on port 53 to avoid spoof responses. However, this 253 direct communication is necessary for LLQs. Thus, servers MAY listen 254 for LLQs on a different port (5352). Clients also therefore need a 255 mechanism to determine which port to send LLQ operations to. 257 The client determines the server responsible for a given LLQ much as 258 a client determines which server to send a dynamic update to. The 259 client begins by sending a standard DNS query for the name of the 260 LLQ, with type SOA. The server MUST answer with that SOA record in 261 the Answer section, if the record exists. The server SHOULD include 262 an SOA record for that name's zone in the Authority section, if the 263 LLQ name (type SOA) does not exist. For example, a query for 264 "_ftp._tcp.apple.com." may return an SOA record named "apple.com." in 265 the Authority section if there is no SOA record named 266 "_ftp._tcp.apple.com." If, in this case, the server does not include 267 the SOA record in the Authority section, the client strips the 268 leading label from the name and tries again, repeating until an 269 answer is received. 271 Upon learning the zone (SOA), the client then constructs and sends an 272 SRV query for the name _dns-llq._udp., 273 e.g., _dns-llq._udp.apple.com. 275 A server implementing LLQ MUST answer with an SRV record [RFC2782] 276 for this name. The SRV RDATA is as follows: 278 PRIORITY typically 0 279 WEIGHT typically 0 280 PORT typically 53 or 5352 281 TARGET name of server providing LLQs for the requested zone 283 The SRV target and the SOA mname SHOULD be identical. In addition, 284 the server SHOULD include its address record(s) in the Additional 285 section of the response. 287 If the server does not include its address record in the Additional 288 section, the client SHOULD query explicitly for the address record 289 with the name of the SRV target. 291 The client MUST send all LLQ requests, refreshes, and acknowledgments 292 to the name server specified in the SRV target, at the address 293 contained in the address record for that target. Note that the 294 queries described in this section (including those for SOA and SRV 295 records) MAY be sent to an intermediate DNS cache -- they need not be 296 sent directly to the name server. 298 If, on issuing the SRV query, the client receives an NXDOMAIN 299 response indicating that the SRV record does not exist, the client 300 SHOULD conclude that the server does not support an LLQ in the 301 requested zone. The client then SHOULD NOT send an LLQ request for 302 the desired name, instead utilizing the behavior for LLQ-unaware 303 servers described in Section 5 "LLQ Setup". 305 4.2. Client Address and Port Identification 307 Servers should send all messages to the source address and port of 308 the LLQ setup message received from the client. 310 5. LLQ Setup 312 An LLQ is initiated by a client, and is completed via a four-way 313 handshake. This handshake provides resilience to packet loss, 314 demonstrates client reachability, and reduces denial of service 315 attack opportunities (see Section 8 "Security Considerations"). 317 5.1. Setup Message Retransmission 319 LLQ Setup Requests and Responses sent by the client SHOULD be 320 retransmitted if no acknowledgments are received. The client SHOULD 321 re-try up to two more times (for a total of 3 attempts) before 322 considering the server down or unreachable. The client MUST wait at 323 least 2 seconds before the first retransmission and 4 seconds between 324 the first and second retransmissions. The client SHOULD listen for a 325 response for at least 8 seconds after the 3rd attempt before 326 considering the server down or unreachable. Upon determining a 327 server to be down, a client MAY periodically attempt to re-initiate 328 an LLQ setup, at a rate of not more than once per hour. 330 Servers MUST NOT re-transmit acknowledgments that do not generate 331 responses from the client. Retransmission in setup is client-driven, 332 freeing servers from maintaining timers for incomplete LLQ setups. 333 If servers receive duplicate messages from clients (perhaps due to 334 the loss of the server's responses mid-flight), the server MUST 335 re-send its reply (possibly modifying the LEASE-LIFE as described in 336 Section 5.2.4 "ACK + Answers"). 338 Servers MUST NOT garbage collect LLQs that fail to complete the four- 339 way handshake until the initially granted LEASE-LIFE has elapsed. 341 5.2. LLQ Setup Four-Way Handshake 343 The four phases of the handshake include: 345 1) Initial Request client to server, identifies LLQ(s) requested 347 2) Challenge server to client, provides error(s) for 348 requested LLQs, and unique identifiers for 349 the successful requests 351 3) Challenge Response client to server, echoes identifier(s), 352 demonstrating client's reachability and 353 willingness to participate 355 4) ACK + Answers server to client, confirms setup and 356 provides initial answers 358 5.2.1. Setup Request 360 A request for an LLQ is formatted like a standard DNS query, but with 361 an OPT RR containing LLQ metadata in its Additional section. LLQ 362 setup requests are identified by the LLQ-SETUP opcode and a 363 zero-valued LLQ-ID. 365 The request MAY contain multiple questions to set up multiple LLQs. 366 A request consisting of multiple questions MUST contain multiple LLQ 367 metadata sections, one per question, with metadata sections in the 368 same order as the questions they correspond to (i.e., the first 369 metadata section corresponds to the first question, the second 370 metadata section corresponds to the second question, etc.) If 371 requesting multiple LLQs, clients SHOULD request the same LEASE-LIFE 372 for each LLQ. Requests over UDP MUST NOT contain multiple questions 373 if doing so would cause the message to not fit in a single packet. 375 A client MUST NOT request multiple identical LLQs (i.e., containing 376 the same qname/type/class) from a single source IP address and port. 378 The query MUST NOT be for record type ANY (255), class ANY (255), or 379 class NONE (0). 381 Setup Request OPT-RR LLQ Metadata Format: 383 Field Name Field Type Description 384 --------------------------------------------------------------------- 385 OPTION-CODE u_int16_t LLQ (1) 386 OPTION-LENGTH u_int16_t Length of following fields (18) 387 VERSION u_int16_t Version of LLQ protocol implemented 388 by requester (1) 389 LLQ-OPCODE u_int16_t LLQ-SETUP (1) 390 ERROR-CODE u_int16_t NOERROR (0) 391 LLQ-ID u_int64_t 0 392 LEASE-LIFE u_int32_t Desired life of LLQ request 394 These fields MUST be repeated once for each additional query in the 395 Question section. 397 5.2.2. Setup Challenge 399 Upon receiving an LLQ Setup Request, a server implementing LLQs will 400 send a Setup Challenge to the requester (client). An LLQ Setup 401 Challenge is a DNS Response, with the DNS message ID matching that of 402 the request, and with all questions contained in the request present 403 in the Question section of the response. Additionally, the challenge 404 contains a single OPT-RR with an LLQ metadata section for each LLQ 405 request, indicating the success or failure of each request. Metadata 406 sections MUST be in the same order as the questions they correspond 407 to. Note that some LLQs in a request containing multiple questions 408 may succeed, while others may fail. 410 Setup Challenge OPT-RR RDATA Format: 412 Field Name Field Type Description 413 --------------------------------------------------------------------- 414 OPTION-CODE u_int16_t LLQ (1) 415 OPTION-LENGTH u_int16_t Length of following fields (18) 416 VERSION u_int16_t Version of LLQ protocol implemented 417 in server (1) 418 LLQ-OPCODE u_int16_t LLQ-SETUP (1) 419 ERROR-CODE u_int16_t [As Appropriate] 420 LLQ-ID u_int64_t [As Appropriate] 421 LEASE-LIFE u_int32_t [As Appropriate] 423 These fields MUST be repeated once for each query in the Questions 424 section of the Setup Request. 426 LLQ Metadata field descriptions: 428 ERROR-CODE: Possible values include: 430 NO-ERROR: The LLQ Setup Request was successful. 432 FORMAT-ERR: The LLQ was improperly formatted. Note that if the 433 rest of the DNS message is properly formatted, the 434 DNS header error code MUST NOT include a format error 435 code, as this would cause confusion between a server 436 that does not understand the LLQ format, and a client 437 that sends malformed LLQs. 439 SERV-FULL: The server cannot grant the LLQ request because it is 440 overloaded, or the request exceeds the server's rate 441 limit (see Section 8 "Security Considerations"). 442 Upon returning this error, the server MUST include 443 in the LEASE-LIFE field a time interval, in seconds, 444 after which the client may re-try the LLQ Setup. 446 STATIC: The data for this name and type is not expected to 447 change frequently, and the server therefore does not 448 support the requested LLQ. The client MUST NOT poll 449 for this name and type, nor should it re-try the LLQ 450 Setup, and should instead honor the normal resource 451 record TTLs returned. To reduce server load, an 452 administrator MAY return this error for all records 453 with types other than PTR and TXT as a matter of 454 course. 456 BAD-VERS: The protocol version specified in the client's 457 request is not supported by the server. 459 UNKNOWN-ERR: The LLQ was not granted for an unknown reason 461 LLQ-ID: On success, a random number generated by the server that is 462 unique for the requested name/type/class. The LLQ-ID SHOULD be an 463 unguessable random number. A possible method of allocating LLQ-IDs 464 with minimal bookkeeping would be to store the time, in seconds since 465 the Epoch, in the high 32 bits of the field, and a cryptographically 466 generated 32-bit random integer in the low 32 bits. 468 On error, the LLQ-ID is set to 0. 470 LEASE-LIFE: On success, the actual life of the LLQ, in seconds. 471 Value may be greater than, less than, or equal to the value requested 472 by the client, as per the server administrator's policy. The server 473 MAY discard the LLQ after this LEASE-LIFE expires unless the LLQ has 474 been renewed by the client (see Section 8 "Security Considerations"). 475 The server MUST NOT generate events (see Section 6 "Event Responses") 476 for expired LLQs. 478 On SERV-FULL error, LEASE-LIFE MUST be set to a time interval, in 479 seconds, after which the client may re-try the LLQ Setup. 481 On other errors, the LEASE-LIFE MUST be set to 0. 483 5.2.3. Challenge Response 485 Upon issuing a Setup Request, a client listens for a Setup Challenge 486 (5.2.2), re-transmitting the request as necessary (5.1). After 487 receiving a successful Challenge, the client SHOULD send a Challenge 488 Response to the server. This Challenge Response is a DNS request 489 with questions from the request and challenge, and a single OPT-RR in 490 the Additional section, with the OPT-RR RDATA identical to the OPT-RR 491 RDATA contained in the Setup Request ACK (i.e., echoing, for each set 492 of fields, the random LLQ-ID and the granted lease life). If the 493 challenge response contains multiple questions, the first question 494 MUST correspond to the first OPT-RR RDATA tuple, etc. 496 If the Setup Request fails with a STATIC error, the client MUST NOT 497 poll the server. The client SHOULD honor the resource record TTLs 498 contained in the response. 500 If the Setup Request fails with a SERV-FULL error, the client MAY 501 re-try the LLQ Setup Request (5.2.1) after the time indicated in the 502 LEASE-LIFE field. 504 If the Setup Request fails with an error other than STATIC or 505 SERV-FULL, or the server is determined not to support LLQ (i.e., the 506 client receives FORMERROR or NOTIMPL in the DNS message header), the 507 client MAY poll the server periodically with standard DNS queries, 508 inferring Add and Remove events (see Section 8 "Security 509 Considerations") by comparing answers to these queries. The client 510 SHOULD NOT poll more than once every 30 minutes for a given query. 511 The client MUST NOT poll if it receives a STATIC error code in the 512 acknowledgment. 514 5.2.4. ACK + Answers 516 Upon receiving a Challenge Response, a server MUST return an 517 acknowledgment, completing the LLQ setup, and provide all current 518 answers to the question(s). 520 To acknowledge a successful Challenge Response, i.e., a Challenge 521 Response in which the LLQ-ID and LEASE-LIFE echoed by the client 522 match the values issued by the server, the server MUST send a DNS 523 response containing all available answers to the question(s) 524 contained in the original Setup Request, along with all additional 525 resource records appropriate for those answers in the Additional 526 section. The Additional section also contains an OPT-RR formatted as 527 follows: 529 Successful Setup Response ACK OPT-RR RDATA Format: 531 Field Name Field Type Description 532 --------------------------------------------------------------------- 533 OPTION-CODE u_int16_t LLQ 534 OPTION-LENGTH u_int16_t Length of following fields, as 535 appropriate 536 VERSION u_int16_t Version of LLQ protocol implemented 537 in server 538 LLQ-OPCODE u_int16_t LLQ-SETUP (1) 539 ERROR-CODE u_int16_t NO-ERROR 540 LLQ-ID u_int64_t Originally granted ID, echoed in 541 client's Response 542 LEASE-LIFE u_int32_t Remaining life of LLQ, in seconds 544 If there is a significant delay in receiving a Setup Response, or 545 multiple Setup Responses are issued (possibly because they were lost 546 en route to the client, causing the client to re-send the Setup 547 Response), the server MAY decrement the LEASE-LIFE by the time 548 elapsed since the Setup Request ACK was initially issued. 550 If the setup is completed over UDP and all initially available 551 answers to the question(s), additional records, and the OPT-RR do not 552 fit in a single packet, some or all additional records (excluding the 553 OPT-RR) MUST be omitted. If, after omission of all additional 554 records, the answers still do not fit in a single message, answers 555 MUST be removed until the message fits in a single packet. These 556 answers not delivered in the Setup Response ACK MUST be delivered 557 without undue delay to the client via Add Events (Section 7 "LLQ 558 Lease-Life Expiration"). 560 5.3. Resource Record TTLs 562 The TTLs of resource records contained in answers to successful LLQs 563 SHOULD be ignored by the client. The client MAY cache LLQ answers 564 until the client receives a gratuitous announcement (see Section 6 565 "Event Responses") indicating that the answer to the LLQ has changed. 566 The client MUST NOT cache answers after the LLQs LEASE-LIFE expires 567 without being refreshed (see Section 8 "Security Considerations"). 568 If an LLQ request fails, the client SHOULD NOT cache answers for a 569 period longer than the client's polling interval. 571 Note that resource records intended specifically to be transmitted 572 via LLQs (e.g., DNS Service Discovery resource records) may have 573 unusually short TTLs. This is because it is assumed that the records 574 may change frequently, and that a client's cache coherence will be 575 maintained via the LLQ and gratuitous responses. Short TTLs prevent 576 stale information from residing in intermediate DNS caches that are 577 not LLQ-aware. 579 TTLs of resource records included in the Additional section of an LLQ 580 response (which do not actually answer the LLQ) SHOULD be honored by 581 the client. 583 6. Event Responses 585 When a change ("event") occurs to a name server's zone, the server 586 MUST check if the new or deleted resource records answer any LLQs. 587 If so, the resource records MUST be sent to the LLQ requesters in the 588 form of a gratuitous DNS response sent to the client, with the 589 question(s) being answered in the Question section, and answers to 590 these questions in the Answer section. The response also includes an 591 OPT RR in the Additional section. This OPT RR contains, in its 592 RDATA, an entry for each LLQ being answered in the message. Entries 593 must include the LLQ-ID. This reduces the potential for spoof events 594 being sent to a client. 596 Event Response OPT-RR RDATA Format: 598 Field Name Field Type Description 599 --------------------------------------------------------------------- 600 OPTION-CODE u_int16_t LLQ (1) 601 OPTION-LENGTH u_int16_t Length of following fields (18) 602 VERSION u_int16_t Version of LLQ protocol implemented 603 in server (1) 604 LLQ-OPCODE u_int16_t LLQ-EVENT (3) 605 ERROR-CODE u_int16_t 0 606 LLQ-ID u_int64_t [As Appropriate] 607 LEASE-LIFE u_int32_t 0 609 Gratuitous responses for a single LLQ MAY be batched, such that 610 multiple resource records are contained in a single message. 611 Responses MUST NOT be batched if this would cause a message that 612 would otherwise fit in a single packet to be truncated. While 613 responses MAY be deferred to provide opportunities for batching, 614 responses SHOULD NOT be delayed, for purposes of batching, for more 615 than 30 seconds, as this would cause an unacceptable latency for the 616 client. 618 After sending a gratuitous response, the server MUST listen for an 619 acknowledgment from the client. If the client does not respond, the 620 server MUST re-send the response. The server MUST re-send 2 times 621 (for a total of 3 transmissions), after which the server MUST 622 consider the client to be unreachable and delete its LLQ. The server 623 MUST listen for 2 seconds before re-sending the response, 4 more 624 seconds before re-sending again, and must wait an additional 8 625 seconds after the 3rd transmission before terminating the LLQ. 627 The DNS message header of the response SHOULD include an unguessable 628 random number in the DNS message ID field, which is to be echoed in 629 the client's acknowledgement. 631 6.1. Add Events 633 Add events occur when a new resource record appears, usually as the 634 result of a dynamic update [RFC2136], that answers an LLQ. This 635 record must be sent in the Answer section of the event to the client. 636 Records that normally accompany this record in responses MAY be 637 included in the Additional section, as per truncation restrictions 638 described above. 640 6.2. Remove Events 642 Remove events occur when a resource record previously sent to a 643 client, either in an initial response, or in an Add Event, becomes 644 invalid (normally as a result of being removed via a dynamic update). 645 The deleted resource record is sent in the Answer section of the 646 event to the client. The resource record TTL is set to -1, 647 indicating that the record has been removed. 649 6.3. Gratuitous Response Acknowledgments 651 Upon receiving a gratuitous response ("event"), the client MUST send 652 an acknowledgment to the server. This acknowledgment is a DNS 653 response echoing the OPT-RR contained in the event, with the message 654 ID of the gratuitous response echoed in the message header. The 655 acknowledgment MUST be sent to the source IP address and port from 656 which the event originated. 658 7. LLQ Lease-Life Expiration 660 7.1. Refresh Request 662 If the client desires to maintain the LLQ beyond the duration 663 specified in the LEASE-LIFE field of the Request Acknowledgment 664 (5.2), the client MUST send a Refresh Request. A Refresh Request is 665 identical to an LLQ Challenge Response (5.3), but with the LLQ-OPCODE 666 set to LLQ-REFRESH. Unlike a Challenge Response, a Refresh Request 667 returns no answers. 669 The client SHOULD refresh an LLQ when 80% of its lease life has 670 elapsed. 672 As a means of reducing network traffic, when constructing refresh 673 messages the client SHOULD include all LLQs established with a given 674 server, even those not yet close to expiration. However, at least 675 one LLQ MUST have elapsed at least 80% of its original LEASE-LIFE. 676 The client MUST NOT include additional LLQs if doing so would cause 677 the message to no longer fit in a single packet. In this case, the 678 LLQs furthest from expiration should be omitted such that the message 679 fits in a single packet. (These LLQs SHOULD be refreshed in a 680 separate message when 80% of one or more of their lease lives have 681 elapsed.) When refreshing multiple LLQs simultaneously, the message 682 contains multiple questions, and a single OPT-RR with multiple LLQ 683 metadata sections, one per question, with the metadata sections in 684 the same order as the questions they correspond to. 686 The client SHOULD specify the original lease life granted in the LLQ 687 response as the desired LEASE-LIFE in the refresh request. If 688 refreshing multiple LLQs simultaneously, the client SHOULD request 689 the same lease life for all LLQs being refreshed (with the exception 690 of termination requests, see below). 692 The client SHOULD specify a lease life of 0 to terminate an LLQ prior 693 to its scheduled expiration (for instance, when the client terminates 694 a DNS Service Discovery browse operation, or a client is about to go 695 to sleep or shut down.) 697 The client SHOULD listen for an acknowledgment from the server. The 698 client MAY re-try up to two more times (for a total of 3 attempts) 699 before considering the server down or unreachable. The client MUST 700 NOT re-try a first time before 90% of the lease life has expired, and 701 MUST NOT re-try again before 95% of the lease life has expired. If 702 the server is determined to be down, the client MAY periodically 703 attempt to re-establish the LLQ via an LLQ Setup Request message. 704 The client MUST NOT attempt the LLQ Setup Request more than once per 705 hour. 707 7.2. LLQ Refresh Acknowledgment 709 Upon receiving an LLQ Refresh message, a server MUST send an 710 acknowledgment of the Refresh. This acknowledgment is formatted like 711 the Setup ACK described in 5.2.3, but with the following variations: 713 The LLQ-OPCODE is set to LLQ-REFRESH. 715 NO-SUCH-LLQ MUST be returned as an error code if the client attempts 716 to refresh an expired or non-existent LLQ (as determined by the 717 LLQ-ID in the request). 719 The LLQ-ID in the acknowledgment is set to the LLQ-ID in the request. 721 8. Security Considerations 723 Without care taken in the design of protocols such as this, servers 724 may be susceptible to denial of service (DOS) attacks, and clients 725 may be subjected to packet storms. Mechanisms have been added to the 726 protocol to limit potential for these attacks. 728 Note: This section contains no new protocol elements -- it serves 729 only to explain the rationale behind protocol elements described 730 above, as they relate to security. 732 8.1. Server DOS 734 LLQs require that servers be stateful, maintaining entries for each 735 LLQ over a potentially long period of time. If unbounded in 736 quantity, these entries may overload the server. By returning 737 SERV-FULL in Request Acknowledgments, the sever may limit the maximum 738 number of LLQs it maintains. Additionally, the server may return 739 SERV-FULL to limit the number of LLQs requested for a single name and 740 type, or by a single client. This throttling may be in the form of a 741 hard limit, or, preferably, by token-bucket rate limiting. Such rate 742 limiting should occur rarely in normal use and is intended to prevent 743 DOS attacks -- thus it is not built into the protocol explicitly, but 744 is instead implemented at the discretion of an administrator via the 745 SERV-FULL error and the LEASE-LIFE field to indicate a retry time to 746 the client. 748 8.2. Client Packet Storms 750 In addition to protecting the server from DOS attacks, the protocol 751 limits the ability of a malicious host to cause the server to flood a 752 client with packets. This is achieved via the four-way handshake 753 upon setup, demonstrating reachability and willingness of the client 754 to participate, and by requiring that gratuitous responses be ACK'd 755 by the client. 757 Additionally, rate-limiting by LLQ client address, as described in 758 (8.1) serves to limit the number of packets that can be delivered to 759 an unsuspecting client. 761 8.3. Spoofing 763 A large random ID greatly reduces the risk of spoofing either the 764 client (by sending spoof events) or the server (by sending phony 765 requests or refreshes). 767 9. Problems with the LLQ protocol 769 In the course of using LLQ since 2007, some problems were discovered. 770 Since no further work is being done on the LLQ protocol, this LLQ 771 specification will not be updated to remedy these problems. 773 LLQ's IETF Standards Track successor, DNS Push Notifications [Push], 774 does not suffer from these problems, so all existing LLQ 775 implementations are encouraged to migrate to using DNS Push 776 Notifications, and all new implementations are encouraged to 777 implement DNS Push Notifications instead of LLQ. 779 Known problems with LLQ are documented here for the record. 781 An LLQ "Setup Challenge" message from server to client is identical 782 to an LLQ "ACK + Answers" message from server to client when there 783 are no current answers for the query. If there is packet loss, 784 retransmission, and duplication in the network, then a duplicated 785 "Setup Challenge" message arriving late at the client would look like 786 an "ACK + Answers" message with no answers, causing the client to 787 clear its cache of any records matching the query. 789 This LLQ specification states: "Servers MUST NOT garbage collect LLQs 790 that fail to complete the four-way handshake until the initially 791 granted LEASE-LIFE has elapsed." This is probably a mistake, since 792 it exposes LLQ servers to an easy resource-exhaustion denial-of- 793 service attack. DNS Push Notifications is built using DNS Stateful 794 Operations [RFC8490], which uses TLS over TCP, and a benefit of 795 building on TCP is that there are already established industry best 796 practices to guard against SYN flooding and similar attacks [SYN] 797 [RFC4953] 799 LLQ is built using UDP, and because the UDP protocol has no 800 standardized way of indicating the start and end of a session, NAT 801 gateways tend to be fairly agressive about recycling UDP mappings 802 that they believe to be disused [RFC4787] [RFC5382] [RFC7857]. Using 803 a high keepalive traffic rate to maintain NAT mapping state could 804 remedy this, but would largely defeat the purpose of using LLQ in the 805 first place, which is to provide efficient change notification 806 without wasteful polling. Because of this, LLQ clients use NAT Port 807 Mapping Protocol (NAT-PMP) [RFC6886] and/or Port Control Protocol 808 (PCP) [RFC6887] to establish longer NAT mapping lifetimes. This 809 solves the problem, but adds extra complexity, and doesn't work with 810 NAT gateways that don't support NAT-PMP or PCP. By using TCP instead 811 of UDP, the DNS Push Notifications protocol benefits from better 812 longevity of sessions through NAT gateways that don't support NAT-PMP 813 or PCP. 815 10. IANA Considerations 817 The EDNS0 OPTION CODE 1 has already been assigned for this DNS 818 extension. No additional IANA services are required by this 819 document. 821 11. Acknowledgments 823 The concepts described in this document were originally explored, 824 developed and implemented with help from Chris Sharp and Roger 825 Pantos. 827 In 2005 and 2006 Kiren Sekar made significant contributions to the 828 first two drafts of this document, and he wrote much of the code for 829 the implementation of LLQ that shipped in Mac OS X 10.5 Leopard in 830 2007. 832 12. References 834 12.1. Normative References 836 [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 837 draft-ietf-dnssd-push-15 (work in progress), September 838 2018. 840 [RFC1035] Mockapetris, P., "Domain names - implementation and 841 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 842 November 1987, . 844 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 845 Requirement Levels", BCP 14, RFC 2119, 846 DOI 10.17487/RFC2119, March 1997, 847 . 849 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 850 RFC 2671, DOI 10.17487/RFC2671, August 1999, 851 . 853 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 854 specifying the location of services (DNS SRV)", RFC 2782, 855 DOI 10.17487/RFC2782, February 2000, 856 . 858 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 859 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 860 May 2017, . 862 12.2. Informative References 864 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 865 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 866 RFC 2136, DOI 10.17487/RFC2136, April 1997, 867 . 869 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 870 Translation (NAT) Behavioral Requirements for Unicast 871 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 872 2007, . 874 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 875 RFC 4953, DOI 10.17487/RFC4953, July 2007, 876 . 878 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 879 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 880 RFC 5382, DOI 10.17487/RFC5382, October 2008, 881 . 883 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 884 "Understanding Apple's Back to My Mac (BTMM) Service", 885 RFC 6281, DOI 10.17487/RFC6281, June 2011, 886 . 888 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 889 DOI 10.17487/RFC6762, February 2013, 890 . 892 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 893 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 894 . 896 [RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol 897 (NAT-PMP)", RFC 6886, DOI 10.17487/RFC6886, April 2013, 898 . 900 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 901 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 902 DOI 10.17487/RFC6887, April 2013, 903 . 905 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 906 S., and K. Naito, "Updates to Network Address Translation 907 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 908 DOI 10.17487/RFC7857, April 2016, 909 . 911 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 912 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 913 BCP 14, RFC 8490, DOI 10.17487/RFC8490, October 2018, 914 . 916 [SYN] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The 917 Internet Protocol Journal, Cisco Systems, Volume 9, 918 Number 4, December 2006. 920 Authors' Addresses 922 Stuart Cheshire 923 Apple Inc. 924 One Apple Park Way 925 Cupertino, CA 95014 926 United States of America 928 Phone: +1 (408) 996-1010 929 Email: cheshire@apple.com 931 Marc Krochmal 932 Apple Inc. 933 One Apple Park Way 934 Cupertino, California 95014 935 USA 937 Email: marc@apple.com