1Document: draft-cheshire-dnsext-multicastdns-04.txt Stuart Cheshire 2Category: Standards Track Apple Computer, Inc. 3Expires 14th August 2004 Marc Krochmal 4 Apple Computer, Inc. 5 14th February 2004 6 7 Multicast DNS 8 9 <draft-cheshire-dnsext-multicastdns-04.txt> 10 11 12Status of this Memo 13 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), 17 its areas, and its working groups. Note that other groups may 18 also distribute working documents as Internet-Drafts. 19 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 24 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 30 31 Distribution of this memo is unlimited. 32 33 34Abstract 35 36 As networked devices become smaller, more portable, and more 37 ubiquitous, the ability to operate with less configured 38 infrastructure is increasingly important. In particular, the ability 39 to look up DNS resource record data types (including, but not limited 40 to, host names) in the absence of a conventional managed DNS server, 41 is becoming essential. 42 43 Multicast DNS (mDNS) provides the ability to do DNS-like operations 44 on the local link in the absense of any conventional unicast DNS 45 server. In addition, mDNS designates a portion of the DNS namespace 46 to be free for local use, without the need to pay any annual fee, and 47 without the need to set up delegations or otherwise configure a 48 conventional DNS server to answer for those names. 49 50 The primary benefits of mDNS names are that (i) they require little 51 or no administration or configuration to set them up, (ii) they work 52 when no infrastructure is present, and (iii) they work during 53 infrastructure failures. 54 55 56 57 58Expires 14th August 2004 Cheshire & Krochmal [Page 1] 59 60Internet Draft Multicast DNS 14th February 2004 61 62 63Table of Contents 64 65 1. Introduction...................................................3 66 2. Conventions and Terminology Used in this Document..............4 67 3. Multicast DNS Names............................................4 68 4. IP TTL Checks..................................................8 69 5. Reverse Address Mapping........................................8 70 6. Querying.......................................................9 71 7. Duplicate Suppression.........................................13 72 8. Responding....................................................15 73 9. Probing and Announcing on Startup.............................17 74 10. Conflict Resolution...........................................21 75 11. Special Characteristics of Multicast DNS Domains..............23 76 12. Multicast DNS for Service Discovery...........................24 77 13. Resource Record TTL Values and Cache Coherency................25 78 14. Enabling and Disabling Multicast DNS..........................30 79 15. Considerations for Multiple Interfaces........................30 80 16. Multicast DNS and Power Management............................31 81 17. Multicast DNS Character Set...................................32 82 18. Multicast DNS Message Size....................................33 83 19. Multicast DNS Message Format..................................33 84 20. Choice of UDP Port Number.....................................36 85 21. Summary of Differences Between Multicast DNS and Unicast DNS..37 86 22. Benefits of Multicast Responses...............................38 87 23. IPv6 Considerations...........................................39 88 24. Security Considerations.......................................40 89 25. IANA Considerations...........................................41 90 26. Acknowledgements..............................................41 91 27. Copyright.....................................................41 92 28. Normative References..........................................42 93 29. Informative References........................................42 94 30. Author's Addresses............................................43 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116Expires 14th August 2004 Cheshire & Krochmal [Page 2] 117 118Internet Draft Multicast DNS 14th February 2004 119 120 1211. Introduction 122 123 When reading this document, familiarity with the concepts of Zero 124 Configuration Networking [ZC] and automatic link-local addressing 125 [v4LL] [RFC 2462] is helpful. 126 127 This document proposes no change to the structure of DNS messages, 128 and no new operation codes, response codes, or resource record types. 129 This document simply discusses what needs to happen if DNS clients 130 start sending DNS queries to a multicast address, and how a 131 collection of hosts can cooperate to collectively answer those 132 queries in a useful manner. 133 134 There has been discussion of how much burden Multicast DNS might 135 impose on a network. It should be remembered that whenever IPv4 hosts 136 communicate, they broadcast ARP packets on the network on a regular 137 basis, and this is not disastrous. The approximate amount of 138 multicast traffic generated by hosts making conventional use of 139 Multicast DNS is anticipated to be roughly the same order of 140 magnitude as the amount of broadcast ARP traffic those hosts already 141 generate. 142 143 New applications making new use of Multicast DNS capabilities for 144 unconventional purposes may generate more traffic. If some of those 145 new applications are "chatty", then work will be needed to help them 146 become less chatty. When performing any analysis, it is important to 147 make a distinction between the application behavior and the 148 underlying protocol behavior. If a chatty application uses UDP, that 149 doesn't mean that UDP is chatty, or that IP is chatty, or that 150 Ethernet is chatty. What it means is that the application is chatty. 151 The same applies to any future applications that may decide to layer 152 increasing portions of their functionality over Multicast DNS. 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174Expires 14th August 2004 Cheshire & Krochmal [Page 3] 175 176Internet Draft Multicast DNS 14th February 2004 177 178 1792. Conventions and Terminology Used in this Document 180 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in "Key words for use in 184 RFCs to Indicate Requirement Levels" [RFC 2119]. 185 186 This document uses the term "host name" in the strict sense to mean a 187 fully qualified domain name that has an address record. It does not 188 use the term "host name" in the commonly used but incorrect sense to 189 mean just the first DNS label of a host's fully qualified domain 190 name. 191 192 A DNS (or mDNS) packet contains an IP TTL in the IP header, which 193 is effectively a hop-count limit for the packet, to guard against 194 routing loops. Each Resource Record also contains a TTL, which is 195 the number of seconds for which the Resource Record may be cached. 196 197 In any place where there may be potential confusion between these two 198 types of TTL, the term "IP TTL" is used to refer to the IP header TTL 199 (hop limit), and the term "RR TTL" is used to refer to the Resource 200 Record TTL (cache lifetime). 201 202 When this document uses the term "Multicast DNS", it should be taken 203 to mean: Clients performing DNS-like queries for DNS-like resource 204 records by sending DNS-like UDP query and response packets over IP 205 Multicast to UDP port 5353." 206 207 2083. Multicast DNS Names 209 210 This document proposes that the DNS top-level domain ".local." be 211 designated a special domain with special semantics, namely that any 212 fully-qualified name ending in ".local." is link-local, and names 213 within this domain are meaningful only on the link where they 214 originate. This is analogous to IPv4 addresses in the 169.254/16 215 prefix, which are link-local and meaningful only on the link where 216 they originate. 217 218 Any DNS query for a name ending with ".local." MUST be sent 219 to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent 220 FF02::FB). 221 222 It is unimportant whether a name ending with ".local." occurred 223 because the user explicitly typed in a fully qualified domain name 224 ending in ".local.", or because the user entered an unqualified 225 domain name and the host software appended the suffix ".local." 226 because that suffix appears in the user's search list. The ".local." 227 suffix could appear in the search list because the user manually 228 configured it, or because it was received in a DHCP option, or via 229 any other valid mechanism for configuring the DNS search list. In 230 231 232Expires 14th August 2004 Cheshire & Krochmal [Page 4] 233 234Internet Draft Multicast DNS 14th February 2004 235 236 237 this respect the ".local." suffix is treated no differently to any 238 other search domain that might appear in the DNS search list. 239 240 DNS queries for names that do not end with ".local." MAY be sent to 241 the mDNS multicast address, if no other conventional DNS server is 242 available. This can allow hosts on the same link to continue 243 communicating using each other's globally unique DNS names during 244 network outages which disrupt communication with the greater 245 Internet. When resolving global names via local multicast, it is even 246 more important to use DNSSEC or other security mechanisms to ensure 247 that the response is trustworthy. Resolving global names via local 248 multicast is a contentious issue, and this document does not discuss 249 it in detail, instead concentrating on the issue of resolving local 250 names using DNS packets sent to a multicast address. 251 252 A host which belongs to an organization or individual who has control 253 over some portion of the DNS namespace can be assigned a globally 254 unique name within that portion of the DNS namespace, for example, 255 "cheshire.apple.com." For those of us who have this luxury, this 256 works very well. However, the majority of home customers do not have 257 easy access to any portion of the global DNS namespace within which 258 they have the authority to create names as they wish. This leaves the 259 majority of home computers effectively anonymous for practical 260 purposes. 261 262 To remedy this problem, this document allows any computer user to 263 elect to give their computers link-local Multicast DNS host names of 264 the form: "single-dns-label.local." For example, my Titanium 265 PowerBook laptop computer answers to the name "sctibook.local." Any 266 computer user is granted the authority to name their computer this 267 way, providing that the chosen host name is not already in use on 268 that link. Having named their computer this way, the user has the 269 authority to continue using that name until such time as a name 270 conflict occurs on the link which is not resolved in the user's 271 favour. If this happens, the computer (or its human user) SHOULD 272 cease using the name, and may choose to attempt to allocate a new 273 unique name for use on that link. Like law suits over global DNS 274 names, these conflicts are expected to be relatively rare for people 275 who choose reasonably imaginative names, but it is still important 276 to have a mechanism in place to handle them when they happen. 277 278 The point made in the previous paragraph is very important and bears 279 repeating. It is easy for those of us in the IETF community who run 280 our own name servers at home to forget that the majority of computer 281 users do not run their own name server and have no easy way to create 282 their own host names. When these users wish to transfer files between 283 two laptop computers, they are frequently reduced to typing in 284 dotted-decimal IP addresses because they simply have no other way for 285 one host to refer to the other by name. This is a sorry state of 286 affairs. What is worse, most users don't even bother trying to use 287 288 289 290Expires 14th August 2004 Cheshire & Krochmal [Page 5] 291 292Internet Draft Multicast DNS 14th February 2004 293 294 295 dotted-decimal IP addresses. Most users still move data between 296 machines by copying it onto a floppy disk or similar removable media. 297 298 In a world of gigabit Ethernet and ubiquitous wireless networking it 299 is a sad indictment of the networking community that the preferred 300 communication medium for most computer users is still the floppy 301 disk. 302 303 Allowing ad-hoc allocation of single-label names in a single flat 304 ".local." namespace may seem to invite chaos. However, operational 305 experience with AppleTalk NBP names [NBP], which on any given link 306 are also effectively single-label names in a flat namespace, shows 307 that in practice name collisions happen extremely rarely and are not 308 a problem. Groups of computer users from disparate organizations 309 bring Macintosh laptop computers to events such as IETF Meetings, the 310 Mac Hack conference, the Apple World Wide Developer Conference, etc., 311 and complaints at these events about users suffering conflicts and 312 being forced to rename their machines have never been an issue. 313 314 Enforcing uniqueness of host names (i.e. the names of DNS address 315 records mapping names to IP addresses) is probably desirable in the 316 common case, but this document does not mandate that. It is 317 permissible for a collection of coordinated hosts to agree to 318 maintain multiple DNS address records with the same name, possibly 319 for load balancing or fault-tolerance reasons. This document does not 320 take a position on whether that is sensible. It is important that 321 both modes of operation are supported. The Multicast DNS protocol 322 allows hosts to verify and maintain unique names for resource records 323 where that behaviour is desired, and it also allows hosts to maintain 324 multiple resource records with a single shared name where that 325 behaviour is desired. This consideration applies to all resource 326 records, not just address records (host names). In summary: It is 327 required that the protocol have the ability to detect and handle name 328 conflicts, but it is not required that this ability be used for every 329 record. 330 331 3323.1 Governing Standards Body 333 334 Note that this use of the ".local." suffix falls under IETF 335 jurisdiction, not ICANN jurisdiction. DNS is an IETF network 336 protocol, governed by protocol rules defined by the IETF. These IETF 337 protocol rules dictate character set, maximum name length, packet 338 format, etc. ICANN determines additional rules that apply when the 339 IETF's DNS protocol is used on the public Internet. In contrast, 340 private uses of the DNS protocol on isolated private networks are not 341 governed by ICANN. Since this proposed change is a change to the core 342 DNS protocol rules, it affects everyone, not just those machines 343 using the ICANN-governed Internet. Hence this change falls into the 344 category of an IETF protocol rule, not an ICANN usage rule. 345 346 347 348Expires 14th August 2004 Cheshire & Krochmal [Page 6] 349 350Internet Draft Multicast DNS 14th February 2004 351 352 3533.2 Private DNS Namespaces 354 355 Note also that the special treatment of names ending in ".local." has 356 been implemented in Macintosh computers since the days of Mac OS 9, 357 and continues today in Mac OS X. There are also implementations for 358 Linux and other platforms [dotlocal]. Operators setting up private 359 internal networks ("intranets") are advised that their lives may be 360 easier if they avoid using the suffix ".local." in names in their 361 private internal DNS server. Alternative possibilities include: 362 363 .intranet 364 .internal 365 .private 366 .corp 367 .home 368 369 Another alternative naming scheme, advocated by Professor D. J. 370 Bernstein, is to use a numerical suffix, such as ".6." [djbdl]. 371 372 3733.3 Maximum Multicast DNS Name Length 374 375 RFC 1034 says: 376 377 "the total number of octets that represent a domain name (i.e., 378 the sum of all label octets and label lengths) is limited to 255." 379 380 This text implies that the final root label at the end of every name 381 is included in this count (a name can't be represented without it), 382 but the text does not explicitly state that. Implementations of 383 Multicast DNS MUST include the label length byte of the final root 384 label at the end of every name when enforcing the rule that no name 385 may be longer than 255 bytes. For example, the length of the name 386 "apple.com." is considered to be 11, which is the number of bytes it 387 takes to represent that name in a packet without using name 388 compression: 389 390 ------------------------------------------------------ 391 | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 | 392 ------------------------------------------------------ 393 394 395 396 397 398 399 400 401 402 403 404 405 406Expires 14th August 2004 Cheshire & Krochmal [Page 7] 407 408Internet Draft Multicast DNS 14th February 2004 409 410 4114. IP TTL Checks 412 413 All Multicast DNS responses (including responses sent via unicast) 414 MUST be sent with IP TTL set to 255. 415 416 A host sending Multicast DNS queries to a link-local destination 417 address (including the 224.0.0.251 link-local multicast address) MUST 418 verify that the IP TTL in response packets is 255, and silently 419 discard any response packets where the IP TTL is not 255. Without 420 this check, it could be possible for remote rogue hosts to send 421 spoof answer packets (perhaps unicast to the victim host) which the 422 receiving machine could misinterpret as having originated on the 423 local link. 424 425 The authors have heard complaints that some older network stack 426 implementations do not implement the IP_RECVTTL socket option 427 (or equivalent API) for obtaining the IP TTL of received packets. 428 This is unfortunate, and these old network stacks would benefit 429 from adding this API support so that they may benefit from this 430 enhanced protection against spoof packets arriving from off-link. 431 432 Note that Multicast DNS Responders SHOULD NOT discard queries with 433 TTLs other than 255. There may be valid future applications of 434 Multicast DNS where hosts issue unicast queries directed at Multicast 435 DNS Responders more than one hop away, if Multicast DNS Responders 436 were to discard queries where the TTL is not 255, they would not 437 answer these queries. 438 439 4405. Reverse Address Mapping 441 442 Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also 443 defined to be link-local. 444 445 Any DNS query for a name ending with "254.169.in-addr.arpa." MUST 446 be sent to the mDNS multicast address 224.0.0.251. Since names under 447 this domain correspond to IPv4 link-local addresses, it is logical 448 that the local link is the best place to find information pertaining 449 to those names. As an optimization, these queries MAY be first 450 unicast directly to the address in question, but if this query is not 451 answered, the query MUST also be sent via multicast, to accommodate 452 the case where the machine in question is not answering for itself 453 (for example, because it is currently sleeping). 454 455 Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa." 456 MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB, 457 with or without an optional initial query unicast directly to the 458 address in question. 459 460 461 462 463 464Expires 14th August 2004 Cheshire & Krochmal [Page 8] 465 466Internet Draft Multicast DNS 14th February 2004 467 468 4696. Querying 470 471 There are three kinds of Multicast DNS Queries, one-shot queries of 472 the kind made by today's conventional DNS clients, one-shot queries 473 accumulating multiple responses made by multicast-aware DNS clients, 474 and continuous ongoing Multicast DNS Queries used by IP network 475 browser software. 476 477 A Multicast DNS Responder that is offering records that are intended 478 to be unique on the local link MUST also implement a Multicast DNS 479 Querier so that it can first verify the uniqueness of those records 480 before it begins answering queries for them. 481 482 4836.1 One-Shot Queries 484 485 An unsophisticated DNS client may simply send its DNS queries 486 blindly to the 224.0.0.251 multicast address, without necessarily 487 even being aware what a multicast address is. 488 489 Such an unsophisticated DNS client may not get ideal behaviour. Such 490 a client may simply take the first response it receives and fail to 491 wait to see if there are more, but in many instances this may not be 492 a serious problem. If a user types "http://stu.local." into their Web 493 browser and gets to see the page they were hoping for, then the 494 protocol has met the user's needs in this case. 495 496 4976.2 One-Shot Queries, Accumulating Multiple Responses 498 499 A more sophisticated DNS client should understand that Multicast DNS 500 is not exactly the same as unicast DNS, and should modify its 501 behaviour in some simple ways. 502 503 As described above, there are some cases, such as looking up the 504 address associated with a unique host name, where a single response 505 is sufficient, and moreover may be all that is expected. However, 506 there are other DNS queries where more than one response is 507 possible, and for these queries a more sophisticated Multicast DNS 508 client should include the ability to wait for an appropriate period 509 of time to collect multiple responses. 510 511 A naive DNS client retransmits its query only so long as it has 512 received no response. A more sophisticated Multicast DNS client is 513 aware that having received one response is not necessarily an 514 indication that it might not receive others, and has the ability to 515 retransmit its query an appropriate number of times at appropriate 516 intervals until it is satisfied with the collection of responses it 517 has gathered. 518 519 520 521 522Expires 14th August 2004 Cheshire & Krochmal [Page 9] 523 524Internet Draft Multicast DNS 14th February 2004 525 526 527 A more sophisticated Multicast DNS client that is retransmitting 528 a query for which it has already received some responses, MUST 529 implement Known Answer Suppression, as described below in Section 530 7.1. This indicates to responders who have already replied that their 531 responses have been received, and they don't need to send them again 532 in response to this repeated query. In addition, the interval between 533 the first two queries MUST be at least one second, and the 534 intervals between subsequent queries MUST double. 535 536 5376.3 Continuous Querying 538 539 In One-Shot Queries, with either a single or multiple responses, 540 the underlying assumption is that the transaction begins when the 541 application issues a query, and ends when all the desired responses 542 have been received. There is another type of operation which is more 543 akin to continuous monitoring. 544 545 Macintosh users are accustomed to opening the "Chooser" window, 546 selecting a desired printer, and then closing the Chooser window. 547 However, when the desired printer does not appear in the list, the 548 user will typically leave the "Chooser" window open while they go and 549 check to verify that the printer is plugged in, powered on, connected 550 to the Ethernet, etc. While the user jiggles the wires, hits the 551 Ethernet hub, and so forth, they keep an eye on the Chooser window, 552 and when the printer name appears, they know they have fixed whatever 553 the problem was. This can be a useful and intuitive troubleshooting 554 technique, but a user who goes home for the weekend leaving the 555 Chooser window open places a non-trivial burden on the network. 556 557 With continuous querying, multiple queries are sent over a long 558 period of time, until the user terminates the operation. It is 559 important that an IP network browser window displaying live 560 information from the network using Multicast DNS, if left running for 561 an extended period of time, should generate significantly less 562 multicast traffic on the network than the old AppleTalk Chooser. 563 Therefore, the interval between the first two queries MUST be at 564 least one second, the intervals between subsequent queries MUST 565 double, and the querier MUST implement Known Answer Suppression, as 566 described below in Section 7.1. 567 568 When a Multicast DNS Querier receives an answer, the answer contains 569 a TTL value that indicates for how many seconds this answer is valid. 570 After this interval has passed, the answer will no longer be valid 571 and should be deleted from the cache. Before this time is reached, a 572 Multicast DNS Querier with an ongoing interest in that record SHOULD 573 re-issue its query to determine whether the record is still valid, 574 and if so update its expiry time. 575 576 577 578 579 580Expires 14th August 2004 Cheshire & Krochmal [Page 10] 581 582Internet Draft Multicast DNS 14th February 2004 583 584 585 To perform this cache maintenance, a Multicast DNS Querier should 586 plan to issue a query at 80% of the record lifetime, and then if no 587 answer is received, at 85%, 90% and 95%. If an answer is received, 588 then the remaining TTL is reset to the value given in the answer, and 589 this process repeats for as long as the Multicast DNS Querier has an 590 ongoing interest in the record. If after four queries no answer is 591 received, the record is deleted when it reaches 100% of its lifetime. 592 593 To avoid the case where multiple Multicast DNS Queriers on a network 594 all issue their queries simultaneously, a random variation of 2% of 595 the record TTL should be added, so that queries are scheduled to be 596 performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL. 597 598 5996.4 Multiple Questions per Query 600 601 Multicast DNS allows a querier to place multiple questions in the 602 question section of a single Multicast DNS query packet. 603 604 The semantics of a Multicast DNS query packet containing multiple 605 questions is identical to a series of individual DNS query packets 606 containing one question each. Combining multiple questions into a 607 single packet is purely an efficiency optimization, and has no other 608 semantic significance. 609 610 A useful technique for adaptively combining multiple questions into a 611 single query is to use a Nagle-style algorithm: When a client issues 612 its first question, a Query packet is immediately built and sent, 613 without delay. If the client then continues issuing a rapid series of 614 questions they are held until either the first query receives at 615 least one answer, or 100ms has passed, or there are enough questions 616 to fill the question section of a Multicast DNS query packet. At this 617 time, all the held questions are placed into a Multicast DNS query 618 packet and sent. 619 620 6216.5 Questions Requesting Unicast Responses 622 623 Sending Multicast DNS responses via multicast has the benefit that 624 all the other hosts on the network get to see those responses, and 625 can keep their caches up to date, and detect conflicting responses. 626 627 However, there are situations where all the other hosts on the 628 network don't need to see every response. One example is a laptop 629 computer waking from sleep. At that instant it is a brand new 630 participant on a new network. Its Multicast DNS cache is empty, and 631 it has no knowledge of its surroundings. It may have a significant 632 number of queries that it wants answered right away to discover 633 information about its new surroundings and present that information 634 to the user. As a new participant on the network, it has no idea 635 whether the exact same questions may have been asked and answered 636 637 638Expires 14th August 2004 Cheshire & Krochmal [Page 11] 639 640Internet Draft Multicast DNS 14th February 2004 641 642 643 just seconds ago. In this case, trigging a large sudden flood of 644 multicast responses may impose an unreasonable burden on the network. 645 To avoid this, the Multicast DNS Querier SHOULD set the top bit in 646 the class field of its DNS question(s), to indicate that it is 647 willing to accept unicast responses instead of the usual multicast 648 responses. These questions requesting unicast responses are referred 649 to as "QU" questions, to distinguish them from the more usual 650 questions requesting multicast responses ("QM" questions). 651 652 When retransmitting a question more than once, the 'unicast response' 653 bit SHOULD be set only for the first question of the series. After 654 the first question has received its responses, the querier should 655 have a large known-answer list (see "Known Answer Suppression" below) 656 so that subsequent queries should elicit few, if any, further 657 responses. Reverting to multicast responses as soon as possible is 658 important because of the benefits that multicast responses provide 659 (see "Benefits of Multicast Responses" below). 660 661 When receiving a question with the 'unicast response' bit set, a 662 responder SHOULD usually respond with a unicast packet directed back 663 to the querier. If the responder has not multicast that record 664 recently (within one quarter of its TTL), then the responder SHOULD 665 instead multicast the response so as to keep all the peer caches up 666 to date, and to permit passive conflict detection. 667 668 6696.6 Suppressing Initial Query 670 671 If a query is issued for which there already exist one or more 672 records in the local cache, and those record(s) were received with 673 the cache flush bit set, indicating that they form a unique RRSet, 674 then the host SHOULD suppress its initial "QU" query, and proceed to 675 issue a "QM" query. To avoid the situation where a group of hosts 676 are synchronized by some external event and all perform the same 677 query simultaneously, a host suppressing its initial "QU" query 678 SHOULD impose a random delay from 500-1000ms before transmitting its 679 first "QM" query for this question. This means that when the first 680 host (selected randomly by this algorithm) transmits its "QM" query, 681 all the other hosts that were about to transmit the same query can 682 suppress their superfluous query, as described in "Duplicate 683 Question Suppression" below. 684 685 686 687 688 689 690 691 692 693 694 695 696Expires 14th August 2004 Cheshire & Krochmal [Page 12] 697 698Internet Draft Multicast DNS 14th February 2004 699 700 7017. Duplicate Suppression 702 703 A variety of techniques are used to reduce the amount of redundant 704 traffic on the network. 705 706 7077.1 Known Answer Suppression 708 709 When a Multicast DNS Querier sends a query to which it already knows 710 some answers, it populates the Answer Section of the DNS message with 711 those answers. 712 713 A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if 714 the answer it would give is already included in the Answer Section 715 with an RR TTL at least half the correct value. If the RR TTL of the 716 answer as given in the Answer Section is less than half of the true 717 RR TTL as known by the Multicast DNS Responder, the responder MUST 718 send an answer so as to update the Querier's cache before the record 719 becomes in danger of expiration. 720 721 Because a Multicast DNS Responder will respond if the remaining TTL 722 given in the known answer list is less than half the true TTL, it is 723 superfluous for the Querier to include such records in the known 724 answer list. Therefore a Multicast DNS Querier SHOULD NOT include 725 records in the known answer list whose remaining TTL is less than 726 half their original TTL. Doing so would simply consume space in the 727 packet without achieving the goal of suppressing responses, and would 728 therefore be a pointless waste of network bandwidth. 729 730 A Multicast DNS Querier MUST NOT cache resource records observed in 731 the Known Answer Section of other Multicast DNS Queries. The Answer 732 Section of Multicast DNS Queries is not authoritative. By placing 733 information in the Answer Section of a Multicast DNS Query the 734 querier is stating that it *believes* the information to be true. 735 It is not asserting that the information *is* true. Some of those 736 records may have come from other hosts that are no longer on the 737 network. Propagating that stale information to other Multicast DNS 738 Queriers on the network would not be helpful. 739 740 7417.2 Multi-Packet Known Answer Suppression 742 743 Sometimes a Multicast DNS Querier will already have too many answers 744 to fit in the Known Answer section of its query packets. In this 745 case, it should issue a Multicast DNS Query containing a question and 746 as many Known Answer records as will fit. It should then set the TC 747 (Truncated) bit in the header before sending the Query. It should 748 then immediately follow the packet with another query containing no 749 questions, and as many more Known Answer records as will fit. If 750 there are still too many records remaining to fit in the packet, it 751 752 753 754Expires 14th August 2004 Cheshire & Krochmal [Page 13] 755 756Internet Draft Multicast DNS 14th February 2004 757 758 759 again sets the TC bit and continues until all the Known Answer 760 records have been sent. 761 762 A Multicast DNS Responder seeing a Multicast DNS Query with the TC 763 bit set defers its response for a time period randomly selected in 764 the interval 20-120ms. This gives the Multicast DNS Querier time to 765 send additional Known Answer packets before the Responder responds. 766 If the Responder sees any of its answers listed in the Known Answer 767 lists of subsequent packets from the querying host, it should delete 768 that answer from the list of answers it is planning to give, provided 769 that no other host on the network is also waiting to receive the same 770 answer record. 771 772 7737.3 Duplicate Question Suppression 774 775 If a host is planning to send a query, and it sees another host on 776 the network send a query containing the same question, and the Known 777 Answer section of that query does not contain any records which this 778 host would not also put in its own Known Answer section, then this 779 host should treat its own query as having been sent. When multiple 780 clients on the network are querying for the same resource records, 781 there is no need for them to all be repeatedly asking the same 782 question. 783 784 7857.4 Duplicate Answer Suppression 786 787 If a host is planning to send an answer, and it sees another host on 788 the network send a response packet containing the same answer record, 789 and the TTL in that record is not less than the TTL this host would 790 have given, then this host should treat its own answer as having been 791 sent. When multiple responders on the network have the same data, 792 there is no need for all of them to respond. 793 794 This feature is particularly useful when multiple Sleep Proxy Servers 795 are deployed (see Section 16. "Multicast DNS and Power Management"). 796 In the future it is possible that every general-purpose OS (Mac, 797 Windows, Linux, etc.) will implement Sleep Proxy Service as a matter 798 of course. In this case there could be a large number of Sleep Proxy 799 Servers on any given network, which is good for reliability and 800 fault-tolerance, but would be bad for the network if every Sleep 801 Proxy Server were to answer every query. 802 803 804 805 806 807 808 809 810 811 812Expires 14th August 2004 Cheshire & Krochmal [Page 14] 813 814Internet Draft Multicast DNS 14th February 2004 815 816 8178. Responding 818 819 A Multicast DNS Responder MUST only respond when it has a positive 820 non-null response to send. Error responses must never be sent. The 821 non-existence of any name in a Multicast DNS Domain is ascertained by 822 the failure of any machine to respond to the Multicast DNS query, not 823 by NXDOMAIN errors. 824 825 Multicast DNS Responses MUST NOT contain any questions in the 826 Question Section. Any questions in the Question Section of a received 827 Multicast DNS Response MUST be silently ignored. Multicast DNS 828 Queriers receiving Multicast DNS Responses do not care what question 829 elicited the response; they care only that the information in the 830 response is true and accurate. 831 832 A Multicast DNS Responder on Ethernet [IEEE802] and similar shared 833 multiple access networks SHOULD delay its responses by a random 834 amount of time selected with uniform random distribution in the range 835 20-120ms. If multiple Multicast DNS Responders were all to respond 836 immediately to a particular query, a collision would be virtually 837 guaranteed. By imposing a small random delay, the number of 838 collisions is dramatically reduced. 120ms is a short enough time that 839 it is almost imperceptible to a human user, but long enough to 840 significantly reduce the risk of Ethernet collisions. On a full-sized 841 Ethernet using the maximum cable lengths allowed and the maximum 842 number of repeaters allowed, an Ethernet frame is vulnerable to 843 collisions during the transmission of its first 256 bits. On 10Mb/s 844 Ethernet, this equates to a vulnerable time window of 25.6us. 845 846 In the case where a Multicast DNS Responder has good reason to 847 believe that it will be the only responder on the link with a 848 positive non-null response, it SHOULD NOT impose the random delay 849 before responding, and SHOULD normally generate its response within 850 10ms. To do this safely, it MUST have previously verified that the 851 requested name, type and class in the DNS query are unique on this 852 link. Responding immediately without delay is appropriate for things 853 like looking up the address record for a particular host name, when 854 the host name has been previously verified unique. Responding 855 immediately without delay is *not* appropriate for things like 856 looking up PTR records used for DNS Service Discovery [DNS-SD], where 857 a large number of responses may be anticipated. 858 859 Except when a unicast reply has been explicitly requested via the 860 "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port 861 5353 (the well-known port assigned to mDNS) on the 224.0.0.251 862 multicast address (or its IPv6 equivalent FF02::FB). Operating in a 863 Zeroconf environment requires constant vigilance. Just because a name 864 has been previously verified unique does not mean it will continue to 865 be so indefinitely. By allowing all Multicast DNS Responders to 866 constantly monitor their peers' responses, conflicts arising out of 867 network topology changes can be promptly detected and resolved. 868 869 870Expires 14th August 2004 Cheshire & Krochmal [Page 15] 871 872Internet Draft Multicast DNS 14th February 2004 873 874 875 Sending all responses by multicast also facilitates opportunistic 876 caching by other hosts on the network. 877 878 To protect the network against excessive packet flooding due to 879 software bugs or malicious attack, a Multicast DNS Responder MUST NOT 880 multicast a given record on a given interface if it has previously 881 multicast that record on that interface within the last second. A 882 legitimate client on the network should have seen the previous 883 transmission and cached it. A client that did not receive and cache 884 the previous transmission will retry its request and receive a 885 subsequent response. Under no circumstances is there any legitimate 886 reason for a Multicast DNS Responder to multicast a given record more 887 than once per second on any given interface. 888 889 8908.1 Legacy Unicast Responses 891 892 If the source UDP port in a received Multicast DNS Query is not port 893 5353, this indicates that the client originating the query is a 894 simple client that does not fully implement all of Multicast DNS. In 895 this case, the Multicast DNS Responder MUST send a UDP response 896 directly back to the client, via unicast, to the query packet's 897 source IP address and port. This unicast response MUST be a 898 conventional unicast response as would be generated by a conventional 899 unicast DNS server; for example, it must repeat the query ID and the 900 question given in the query packet. 901 902 The resource record TTL given in a unicast response SHOULD NOT be 903 greater than ten seconds, even if the true TTL of the Multicast DNS 904 resource record is higher. This is because Multicast DNS Responders 905 that fully participate in the protocol use the cache coherency 906 mechanisms described in Section 13 to update and invalidate stale 907 data. Were unicast responses sent to legacy clients to use the same 908 high TTLs, these legacy clients, which do not implement these cache 909 coherency mechanisms, could retain stale cached resource record data 910 long after it is no longer valid. 911 912 Having sent this unicast response, if the Responder has not sent this 913 record in any multicast response recently, it SHOULD schedule the 914 record to be sent via multicast as well, to facilitate passive 915 conflict detection. "Recently" in this context means "if the time 916 since the record was last sent via multicast is less than one quarter 917 of the record's TTL". 918 919 920 921 922 923 924 925 926 927 928Expires 14th August 2004 Cheshire & Krochmal [Page 16] 929 930Internet Draft Multicast DNS 14th February 2004 931 932 9338.2 Multi-Question Queries 934 935 Multicast DNS Responders MUST correctly handle DNS query packets 936 containing more than one question, by answering any or all of the 937 questions to which they have answers. Any answers generated 938 in response to query packets containing more than one question 939 MUST be randomly delayed in the range 20-120ms, as described above. 940 941 9428.3 Response Aggregation 943 944 Having delayed one or more multicast responses by 20-120ms as 945 described above in Section 8 "Responding", a Multicast DNS Responder 946 SHOULD, for the sake of network efficiency, aggregate as many of its 947 pending responses as possible into a single Multicast DNS response 948 packet. 949 950 9519. Probing and Announcing on Startup 952 953 Typically a Multicast DNS Responder should have, at the very least, 954 address records for all of its active interfaces. Creating and 955 advertising an HINFO record on each interface as well can be useful 956 to network administrators. 957 958 Whenever a Multicast DNS Responder starts up, wakes up from sleep, 959 receives an indication of an Ethernet "Link Change" event, or has any 960 other reason to believe that its network connectivity may have 961 changed in some relevant way, it MUST perform the two startup steps 962 below. 963 964 9659.1 Probing 966 967 The first startup step is that for all those resource records that a 968 Multicast DNS Responder desires to be unique on the local link, it 969 MUST send a Multicast DNS Query asking for those resource records, to 970 see if any of them are already in use. The primary example of this is 971 its address record which maps its unique host name to its unique IP 972 address. All Probe Queries SHOULD be done using the desired resource 973 record name and query type T_ANY (255), to elicit answers for all 974 types of records with that name. This allows a single question to be 975 used in place of several questions, which is more efficient on the 976 network. It also allows a host to verify exclusive ownership of a 977 name, which is desirable in most cases. It would be confusing, for 978 example, if one host owned the "A" record for "myhost.local.", but a 979 different host owned the HINFO record for that name. 980 981 The ability to place more than one question in a Multicast DNS Query 982 is useful here, because it can allow a host to use a single packet 983 for all of its resource records instead of needing a separate packet 984 985 986Expires 14th August 2004 Cheshire & Krochmal [Page 17] 987 988Internet Draft Multicast DNS 14th February 2004 989 990 991 for each. For example, a host can simultaneously probe for uniqueness 992 of its "A" record and all its SRV records [DNS-SD] in the same query 993 packet. 994 995 When ready to send its mDNS probe packet(s) the host should first 996 wait for a short random delay time, uniformly distributed in the 997 range 0-250ms. This random delay is to guard against the case where a 998 group of devices are powered on simultaneously, or a group of devices 999 are connected to an Ethernet hub which is then powered on, or some 1000 other external event happens that might cause a group of hosts to all 1001 send synchronized probes. 1002 1003 250ms after the first query the host should send a second, then 1004 250ms after that a third. If, by 250ms after the third probe, no 1005 conflicting Multicast DNS responses have been received, the host may 1006 move to the next step, announcing. 1007 1008 If any conflicting Multicast DNS responses are received, then the 1009 probing host MUST defer to the existing host, and must choose new 1010 names for some or all of its resource records as appropriate, to 1011 avoid conflict with pre-existing hosts on the network. In the case 1012 of a host probing using query type T_ANY as recommended above, any 1013 answer containing a record with that name, of any type, MUST be 1014 considered a conflicting response and handled accordingly. 1015 1016 If ten failures occur within any ten-second period, then the host 1017 MUST wait at least five seconds before each successive additional 1018 probe attempt. This is to help ensure that in the event of software 1019 bugs or other unanticipated problems, errant hosts do not flood the 1020 network with a continuous stream of multicast traffic. For very 1021 simple devices, a valid way to comply with this requirement is to 1022 always wait five seconds after any failed probe attempt. 1023 1024 10259.2 Simultaneous Probe Tie-Breaking 1026 1027 The astute reader will observe that there is a race condition 1028 inherent in the previous description. If two hosts are probing for 1029 the same name simultaneously, neither will receive any response to 1030 the probe, and the hosts could incorrectly conclude that they may 1031 both proceed to use the name. To break this symmetry, each host 1032 populates the Authority Section of its queries with records giving 1033 the rdata that it would be proposing to use, should its probing be 1034 successful. The Authority Section is being used here in a way 1035 analogous to the Update section of a DNS Update packet [RFC 2136]. 1036 1037 When a host that is probing for a record sees another host issue a 1038 query for the same record, it consults the Authority Section of that 1039 query. If it finds any resource record there which answers the query, 1040 then it compares the data of that resource record with its own 1041 tentative data. The lexicographically later data wins. This means 1042 1043 1044Expires 14th August 2004 Cheshire & Krochmal [Page 18] 1045 1046Internet Draft Multicast DNS 14th February 2004 1047 1048 1049 that if the host finds that its own data is lexicographically later, 1050 it simply ignores the other host's probe. If the host finds that its 1051 own data is lexicographically earlier, then it treats this exactly 1052 as if it had received a positive answer to its query, and concludes 1053 that it may not use the desired name. 1054 1055 The determination of 'lexicographically later' is performed by first 1056 comparing the record class, then the record type, then raw comparison 1057 of the binary content of the rdata without regard for meaning or 1058 structure. If the record classes differ, then the numerically greater 1059 class is considered 'lexicographically later'. Otherwise, if the 1060 record types differ, then the numerically greater type is considered 1061 'lexicographically later'. If the type and class both match then the 1062 rdata is compared. 1063 1064 In the case of resource records containing rdata that is subject to 1065 name compression, the names must be uncompressed before comparison. 1066 (The details of how a particular name is compressed is an artifact of 1067 how and where the record is written into the DNS message; it is not 1068 an intrinsic property of the resource record itself.) 1069 1070 The bytes of the raw uncompressed rdata are compared in turn, 1071 interpreting the bytes as eight-bit UNSIGNED values, until a byte 1072 is found whose value is greater than that of its counterpart (in 1073 which case the rdata whose byte has the greater value is deemed 1074 lexicographically later) or one of the resource records runs out 1075 of rdata (in which case the resource record which still has 1076 remaining data first is deemed lexicographically later). 1077 1078 The following is an example of a conflict: 1079 1080 sctibook.local. A 196.254.100.200 1081 sctibook.local. A 196.254.200.100 1082 1083 In this case 196.254.200.100 is lexicographically later, so it is 1084 deemed the winner. 1085 1086 Note that it is vital that the bytes are interpreted as UNSIGNED 1087 values, or the wrong outcome may result. In the example above, if 1088 the byte with value 200 had been incorrectly interpreted as a 1089 signed value then it would be interpreted as value -56, and the 1090 wrong address record would be deemed the winner. 1091 1092 10939.3 Announcing 1094 1095 The second startup step is that the Multicast DNS Responder MUST send 1096 a gratuitous Multicast DNS Response containing, in the Answer 1097 Section, all of its resource records. If there are too many resource 1098 records to fit in a single packet, multiple packets should be used. 1099 1100 1101 1102Expires 14th August 2004 Cheshire & Krochmal [Page 19] 1103 1104Internet Draft Multicast DNS 14th February 2004 1105 1106 1107 In the case of shared records (e.g. the PTR records used by DNS 1108 Service Discovery [DNS-SD]), the records are simply placed as-is 1109 into the answer section of the DNS Response. 1110 1111 In the case of records that have been verified to be unique in the 1112 previous step, they are placed into the answer section of the DNS 1113 Response with the most significant bit of the rrclass set to one. The 1114 most significant bit of the rrclass is the mDNS "cache flush" bit and 1115 is discussed in more detail below in Section 13.3 "Announcements to 1116 Flush Outdated Cache Entries". 1117 1118 The Multicast DNS Responder MUST send at least two gratuitous 1119 responses, one second apart. A Responder MAY send up to ten 1120 gratuitous Responses, providing that the interval between gratuitous 1121 responses doubles with every response sent. 1122 1123 A Multicast DNS Responder SHOULD NOT continue sending gratuitous 1124 Responses for longer than the TTL of the record. The purpose of 1125 announcing new records via gratuitous Responses is to ensure that 1126 peer caches are up to date. After a time interval equal to the TTL of 1127 the record has passed, it is very likely that old stale copies of 1128 that record in peer caches will have expired naturally, so subsequent 1129 announcements serve little purpose. 1130 1131 Whenever a Multicast DNS Responder receives any Multicast DNS 1132 response (gratuitous or otherwise) containing a conflicting resource 1133 record, the conflict MUST be resolved as described below in "Conflict 1134 Resolution". 1135 1136 A Multicast DNS Responder MUST NOT send announcements in the absence 1137 of information that its network connectivity may have changed in some 1138 relevant way. In particular, a Multicast DNS Responder MUST NOT send 1139 regular periodic announcements as a matter of course. 1140 1141 11429.4 Updating 1143 1144 At any time, if the rdata of any of a host's Multicast DNS records 1145 changes, the host MUST repeat the Announcing step described above to 1146 update neighbouring caches. For example, if any of a host's IP 1147 addresses change, it must re-announce those address records. 1148 1149 A host may update the contents of any of its records at any time, 1150 though a host SHOULD NOT update records more frequently than ten 1151 times per minute. Frequent rapid updates impose a burden on the 1152 network. If a host has information to disseminate which changes more 1153 frequently than ten times per minute, then Multicast DNS may not be 1154 the appropriate protocol to disseminate that information. 1155 1156 1157 1158 1159 1160Expires 14th August 2004 Cheshire & Krochmal [Page 20] 1161 1162Internet Draft Multicast DNS 14th February 2004 1163 1164 116510. Conflict Resolution 1166 1167 A conflict occurs when two resource records with the same name, type 1168 and class have inconsistent rdata. What may be considered 1169 inconsistent is context sensitive, except that resource records with 1170 identical rdata are never considered inconsistent, even if they 1171 originate from different hosts. A common example of a resource record 1172 type that is intended to be unique, not shared between hosts, is the 1173 address record that maps a host's name to its IP address. Should a 1174 host witness another host announce an address record with the same 1175 name but a different IP address, then that is considered 1176 inconsistent, and that address record is considered to be in 1177 conflict. 1178 1179 Whenever a Multicast DNS Responder receives any Multicast DNS 1180 response (gratuitous or otherwise) containing a conflicting resource 1181 record, the Multicast DNS Responder MUST immediately reset that 1182 record to probing state, and go through the startup steps described 1183 above in Section 9. "Probing and Announcing on Startup". The 1184 protocol used in the Probing phase will determine a winner and a 1185 loser, and the loser must cease using the name, and reconfigure. 1186 1187 It is very important that any host that observes an apparent conflict 1188 MUST take action. In the case of two hosts using the same host name, 1189 where one has been configured to require a unique host name and the 1190 other has not, the one that has not been configured to require a 1191 unique host name will not perceive any conflict, and will not take 1192 any action. By reverting to Probing state, the host that desires a 1193 unique host name will go through the necessary steps to ensure that a 1194 unique host is obtained. 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218Expires 14th August 2004 Cheshire & Krochmal [Page 21] 1219 1220Internet Draft Multicast DNS 14th February 2004 1221 1222 1223 The recommended course of action after probing and failing is as 1224 follows: 1225 1226 o Programmatically change the resource record name in an attempt to 1227 find a new name that is unique. This could be done by adding some 1228 further identifying information (e.g. the model name of the 1229 hardware) if it is not already present in the name, appending the 1230 digit "2" to the name, or incrementing a number at the end of the 1231 name if one is already present. 1232 1233 o Probe again, and repeat until a unique name is found. 1234 1235 o Record this newly chosen name in persistent storage so that the 1236 device will use the same name the next time it is power-cycled. 1237 1238 o Display a message to the user or operator informing them of the 1239 name change. For example: 1240 1241 The name "Bob's Music" is in use by another iTunes music 1242 server on the network. Your music has been renamed to 1243 "Bob's Music (G4 Cube)". If you want to change this name, 1244 use [describe appropriate menu item or preference dialog]. 1245 1246 How the user or operator is informed depends on context. A desktop 1247 computer with a screen might put up a dialog box. A headless server 1248 in the closet may write a message to a log file, or use whatever 1249 mechanism (email, SNMP trap, etc.) it uses to inform the 1250 administrator of other error conditions. On the other hand a headless 1251 server in the closet may not inform the user at all -- if the user 1252 cares, they will notice the name has changed, and connect to the 1253 server in the usual way (e.g. via Web Browser) to configure a new 1254 name. 1255 1256 The examples in this section focus on address records (i.e. host 1257 names), but the same considerations apply to all resource records 1258 where uniqueness (or maintenance of some other defined constraint) is 1259 desired. 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276Expires 14th August 2004 Cheshire & Krochmal [Page 22] 1277 1278Internet Draft Multicast DNS 14th February 2004 1279 1280 128111. Special Characteristics of Multicast DNS Domains 1282 1283 Unlike conventional DNS names, names that end in ".local.", 1284 "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local 1285 significance. Conventional DNS seeks to provide a single unified 1286 namespace, where a given DNS query yields the same answer no matter 1287 where on the planet it is performed or to which recursive DNS server 1288 the query is sent. (However, split views, firewalls, intranets and 1289 the like have somewhat interfered with this goal of DNS representing 1290 a single universal truth.) In contrast, each IP link has its own 1291 private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa." 1292 namespaces, and the answer to any query for a name within those 1293 domains depends on where that query is asked. 1294 1295 Multicast DNS Domains are not delegated from their parent domain via 1296 use of NS records. There are no NS records anywhere in Multicast DNS 1297 Domains. Instead, all Multicast DNS Domains are delegated to the IP 1298 addresses 224.0.0.251 and FF02::FB by virtue of the individual 1299 organizations producing DNS client software deciding how to handle 1300 those names. It would be extremely valuable for the industry if this 1301 special handling were ratified and recorded by IANA, since otherwise 1302 the special handling provided by each vendor is likely to be 1303 inconsistent. 1304 1305 The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The 1306 IPv6 name server for a Multicast DNS Domain is FF02::FB. These are 1307 multicast addresses; therefore they identify not a single host but a 1308 collection of hosts, working in cooperation to maintain some 1309 reasonable facsimile of a competently managed DNS zone. Conceptually 1310 a Multicast DNS Domain is a single DNS zone, however its server is 1311 implemented as a distributed process running on a cluster of loosely 1312 cooperating CPUs rather than as a single process running on a single 1313 CPU. 1314 1315 No delegation is performed within Multicast DNS Domains. Because the 1316 cluster of loosely coordinated CPUs is cooperating to administer a 1317 single zone, delegation is neither necessary nor desirable. Just 1318 because a particular host on the network may answer queries for a 1319 particular record type with the name "example.local." does not imply 1320 anything about whether that host will answer for the name 1321 "child.example.local.", or indeed for other record types with the 1322 name "example.local." 1323 1324 Multicast DNS Zones have no SOA record. A conventional DNS zone's 1325 SOA record contains information such as the email address of the zone 1326 administrator and the monotonically increasing serial number of the 1327 last zone modification. There is no single human administrator for 1328 any given Multicast DNS Zone, so there is no email address. Because 1329 the hosts managing any given Multicast DNS Zone are only loosely 1330 coordinated, there is no readily available monotonically increasing 1331 serial number to determine whether or not the zone contents have 1332 1333 1334Expires 14th August 2004 Cheshire & Krochmal [Page 23] 1335 1336Internet Draft Multicast DNS 14th February 2004 1337 1338 1339 changed. A host holding part of the shared zone could crash or be 1340 disconnected from the network at any time without informing the other 1341 hosts. There is no reliable way to provide a zone serial number that 1342 would, whenever such a crash or disconnection occurred, immediately 1343 change to indicate that the contents of the shared zone had changed. 1344 1345 Zone transfers are not possible for any Multicast DNS Zone. 1346 1347 134812. Multicast DNS for Service Discovery 1349 1350 This document does not describe using Multicast DNS for network 1351 browsing or service discovery. However, the mechanisms this document 1352 describes are compatible with (and support) the browsing and service 1353 discovery mechanisms proposed in "DNS-Based Service Discovery" 1354 [DNS-SD]. 1355 1356 This document places few limitations on what DNS record types may be 1357 looked up using local multicast. One particular kind of Multicast DNS 1358 query that might be useful is a query for the SRV record named 1359 "_domain._udp.local.", yielding the port number and IP address of a 1360 conventional DNS server willing to perform general recursive DNS 1361 lookups. This could solve a particular problem facing the IPv6 1362 community, which is that IPv6 is able to self-configure almost all of 1363 the information it needs to operate [RFC 2462], except for the 1364 address of the DNS server. Bringing in all of the mechanisms of DHCP 1365 just for that one little additional piece of information is not an 1366 attractive solution. Using DNS-format messages and DNS-format 1367 resource records to find the address of the DNS server has an elegant 1368 self-sufficiency about it. Any host that needs to know the address of 1369 the DNS server must already have code to generate and parse DNS 1370 packets, so using that same code and those same packets to find the 1371 DNS server in the first place is a simple self-reliant solution that 1372 avoids taking external dependencies on other protocols. 1373 1374 137513. Resource Record TTL Values and Cache Coherency 1376 1377 The recommended TTL value for Multicast DNS resource records is 1378 120 minutes. 1379 1380 A client with an active outstanding query will issue a query packet 1381 when one or more of the resource record(s) in its cache is (are) 80% 1382 of the way to expiry. If the TTL on those records is 120 minutes, 1383 this ongoing cache maintenance process yields a steady-state query 1384 rate of one query every 96 minutes. 1385 1386 Any distributed cache needs a cache coherency protocol. If Multicast 1387 DNS resource records follow the recommendation and have a TTL of 120 1388 minutes, that means that stale data could persist in the system for 1389 up to two hours. Making the default TTL significantly lower would 1390 1391 1392Expires 14th August 2004 Cheshire & Krochmal [Page 24] 1393 1394Internet Draft Multicast DNS 14th February 2004 1395 1396 1397 reduce the lifetime of stale data, but would produce too much extra 1398 traffic on the network. Various techniques are available to minimize 1399 the impact of such stale data. 1400 1401 140213.1 Cooperating Multicast DNS Responders 1403 1404 If a Multicast DNS Responder ("A") observes some other Multicast DNS 1405 Responder ("B") send a Multicast DNS Response packet containing a 1406 resource record with the same name type and class as one of A's 1407 resource records, but different rdata, then: 1408 1409 o If A's resource record is intended to be a shared resource record, 1410 then this is no conflict, and no action is required. 1411 1412 o If A's resource record is intended to be a unique resource record 1413 then this is a conflict and MUST be handled as described in Section 1414 10 "Conflict Resolution". 1415 1416 If a Multicast DNS Responder ("A") observes some other Multicast DNS 1417 Responder ("B") send a Multicast DNS Response packet containing a 1418 resource record with the same name type and class as one of A's 1419 resource records, and identical rdata, then: 1420 1421 o If the TTL of B's resource record given in the packet is at least 1422 half the true TTL from A's point of view, then no action is 1423 required. 1424 1425 o If the TTL of B's resource record given in the packet is less than 1426 half the true TTL from A's point of view, then A MUST mark its 1427 record to be announced via multicast. Clients receiving the record 1428 from B would use the TTL given by B, and hence may delete the 1429 record sooner than A expects. By sending its own multicast response 1430 correcting the TTL, A ensures that the record will be retained for 1431 the desired time. 1432 1433 These rules allow multiple Multicast DNS Responders to offer the same 1434 data on the network (perhaps for fault tolerance reasons) without 1435 conflicting with each other. 1436 1437 143813.2 Goodbye Packets 1439 1440 In the case where a host knows that certain resource record data is 1441 about to become invalid (for example when the host is undergoing a 1442 clean shutdown) the host SHOULD send a gratuitous announcement mDNS 1443 response packet, giving the same resource record name, type, class 1444 and rdata, but an RR TTL of zero. This has the effect of updating the 1445 TTL stored in neighbouring hosts' cache entries to zero, causing that 1446 cache entry to be promptly deleted. 1447 1448 1449 1450Expires 14th August 2004 Cheshire & Krochmal [Page 25] 1451 1452Internet Draft Multicast DNS 14th February 2004 1453 1454 1455 Clients receiving a Multicast DNS Response with a TTL of zero SHOULD 1456 NOT immediately delete the record from the cache, but instead record 1457 a TTL of 1 and then delete the record one second later. In the case 1458 of multiple Multicast DNS Responders on the network described in 1459 Section 13.1 above, if one of the Responders shuts down and 1460 incorrectly sends goodbye packets for its records, it gives the other 1461 cooperating Responders one second to send out their own response to 1462 "rescue" the records before they expire and are deleted. 1463 1464 Generally speaking, it is more important to send goodbye packets for 1465 shared records than unique records. A given shared record name (such 1466 as a PTR record used for DNS Service Discovery [DNS-SD]) by its 1467 nature often has many representatives from many different hosts, and 1468 tends to be the subject of long-lived ongoing queries. Those 1469 long-lived queries are often concerned not just about being informed 1470 when records appear, but also about being informed if those records 1471 vanish again. In contrast, a unique record set (such as an SRV 1472 record, or a host address record), by its nature, often has far fewer 1473 members than a shared record set, and is usually the subject of 1474 one-shot queries which simply retrieve the data and then cease 1475 querying once they have the answer they are seeking. Therefore, 1476 sending a goodbye packet for a unique record set is likely to offer 1477 less benefit, because it is likely at any given moment that no one 1478 has an active query running for that record set. One example where 1479 goodbye packets for SRV and address records are useful is when 1480 transferring control to a Sleep Proxy Server (see Section 16. 1481 "Multicast DNS and Power Management"). 1482 1483 148413.3 Announcements to Flush Outdated Cache Entries 1485 1486 Whenever a host has a resource record with potentially new data (e.g. 1487 after rebooting, waking from sleep, connecting to a new network link, 1488 changing IP address, etc.), the host MUST send a series of gratuitous 1489 announcements to update cache entries in its neighbour hosts. In 1490 these gratuitous announcements, if the record is one that is intended 1491 to be unique, the host sets the most significant bit of the rrclass 1492 field of the resource record. This bit, the "cache flush" bit, tells 1493 neighbouring hosts that this is not a shared record type. Instead of 1494 merging this new record additively into the cache in addition to any 1495 previous records with the same name, type and class, all old records 1496 with that name, type and class that were received more than one 1497 second ago are declared invalid, and marked to expire from the cache 1498 in one second. 1499 1500 The semantics of the cache flush bit are as follows: Normally when a 1501 resource record appears in the answer section of the DNS Response, it 1502 means, "This is an assertion that this information is true." When a 1503 resource record appears in the answer section of the DNS Response 1504 with the "cache flush" bit set, it means, "This is an assertion that 1505 this information is the truth and the whole truth, and anything you 1506 1507 1508Expires 14th August 2004 Cheshire & Krochmal [Page 26] 1509 1510Internet Draft Multicast DNS 14th February 2004 1511 1512 1513 may have heard more than a second ago regarding records of this 1514 name/type/class is no longer valid". 1515 1516 To accommodate the case where the set of records from one host 1517 constituting a single unique RRSet is too large to fit in a single 1518 packet, only cache records that are more than one second old are 1519 flushed. This allows the announcing host to generate a quick burst of 1520 packets back-to-back on the wire containing all the members 1521 of the RRSet. When receiving records with the "cache flush" bit set, 1522 all records older than one second are marked to be deleted one second 1523 in the future. One second after the end of the little packet burst, 1524 any records not represented within that packet burst will then be 1525 expired from all peer caches. 1526 1527 Any time a host sends a response packet containing some members of a 1528 unique RRSet, it SHOULD send the entire RRSet, preferably in a single 1529 packet, or if the entire RRSet will not fit in a single packet, in a 1530 quick burst of packets sent as close together as possible. The host 1531 SHOULD set the cache flush bit on all members of the unique RRSet. 1532 In the event that for some reason the host chooses not to send the 1533 entire unique RRSet in a single packet or a rapid packet burst, 1534 it MUST NOT set the cache flush bit on any of those records. 1535 1536 The reason for waiting one second before deleting stale records from 1537 the cache is to accommodate bridged networks. For example, a host's 1538 address record announcement on a wireless interface may be bridged 1539 onto a wired Ethernet, and cause that same host's Ethernet address 1540 records to be flushed from peer caches. The one-second delay gives 1541 the host the chance to see its own announcement arrive on the wired 1542 Ethernet, and immediately re-announce its Ethernet address records 1543 so that both sets remain valid and live in peer caches. 1544 1545 These rules apply regardless of *why* the response packet is being 1546 generated. They apply to startup announcements as described in 1547 Section 9.3, and to responses generated as a result of receiving 1548 query packets. 1549 1550 The "cache flush" bit is only set in Multicast DNS responses sent to 1551 UDP port 5353. The "cache flush" bit MUST NOT be set in any resource 1552 records in a response packet sent in legacy unicast responses to UDP 1553 ports other than 5353. 1554 1555 The "cache flush" bit MUST NOT be set in any resource records in the 1556 known-answer list of any query packet. 1557 1558 The "cache flush" bit MUST NOT ever be set in any shared resource 1559 record. To do so would cause all the other shared versions of this 1560 resource record with different rdata from different Responders to be 1561 immediately deleted from all the caches on the network. 1562 1563 1564 1565 1566Expires 14th August 2004 Cheshire & Krochmal [Page 27] 1567 1568Internet Draft Multicast DNS 14th February 2004 1569 1570 1571 Note that the "cache flush" bit is NOT part of the resource record 1572 class. The "cache flush" bit is the most significant bit of the 1573 second 16-bit word of a resource record in an mDNS packet (the field 1574 conventionally referred to as the rrclass field), and the actual 1575 resource record class is the least-significant fifteen bits of this 1576 field. There is no mDNS resource record class 0x8001. The value 1577 0x8001 in the rrclass field of a resource record in an mDNS response 1578 packet indicates a resource record with class 1, with the "cache 1579 flush" bit set. When receiving a resource record with the "cache 1580 flush" bit set, implementations should take care to mask off that bit 1581 before storing the resource record in memory. 1582 1583 158413.4 Cache Flush on Topology change 1585 1586 If the hardware on a given host is able to indicate physical changes 1587 of connectivity, then when the hardware indicates such a change, the 1588 host should take this information into account in its mDNS cache 1589 management strategy. For example, a host may choose to immediately 1590 flush all cache records received on a particular interface when that 1591 cable is disconnected. Alternatively, a host may choose to adjust the 1592 remaining TTL on all those records to a few seconds so that if the 1593 cable is not reconnected quickly, those records will expire from the 1594 cache. 1595 1596 Likewise, when a host reboots, or wakes from sleep, or undergoes some 1597 other similar discontinuous state change, the cache management 1598 strategy should take that information into account. 1599 1600 160113.5 Cache Flush on Failure Indication 1602 1603 Sometimes a cache record can be determined to be stale when a client 1604 attempts to use the rdata it contains, and finds that rdata to be 1605 incorrect. 1606 1607 For example, the rdata in an address record can be determined to be 1608 incorrect if attempts to contact that host fail, either because 1609 ARP/ND requests for that address go unanswered (for an address on a 1610 local subnet) or because a router returns an ICMP "Host Unreachable" 1611 error (for an address on a remote subnet). 1612 1613 The rdata in an SRV record can be determined to be incorrect if 1614 attempts to communicate with the indicated service at the host and 1615 port number indicated are not successful. 1616 1617 The rdata in a DNS-SD PTR record can be determined to be incorrect if 1618 attempts to look up the SRV record it references are not successful. 1619 1620 In any such case, the software implementing the mDNS resource record 1621 cache should provide a mechanism so that clients detecting stale 1622 rdata can inform the cache. 1623 1624Expires 14th August 2004 Cheshire & Krochmal [Page 28] 1625 1626Internet Draft Multicast DNS 14th February 2004 1627 1628 1629 When the cache receives this hint that it should reconfirm some 1630 record, it MUST issue two or more queries for the resource record in 1631 question. If no response is received in a reasonable amount of time, 1632 then, even though its TTL may indicate that it is not yet due to 1633 expire, that record SHOULD be promptly flushed from the cache. 1634 1635 The end result of this is that if a printer suffers a sudden power 1636 failure or other abrupt disconnection from the network, its name may 1637 continue to appear in DNS-SD browser lists displayed on users' 1638 screens. Eventually that entry will expire from the cache naturally, 1639 but if a user tries to access the printer before that happens, the 1640 failure to successfully contact the printer will trigger the more 1641 hasty demise of its cache entries. This is a sensible trade-off 1642 between good user-experience and good network efficiency. If we were 1643 to insist that printers should disappear from the printer list within 1644 30 seconds of becoming unavailable, for all failure modes, the only 1645 way to achieve this would be for the client to poll the printer at 1646 least every 30 seconds, or for the printer to announce its presence 1647 at least every 30 seconds, both of which would be an unreasonable 1648 burden on most networks. 1649 1650 165113.6 Passive Observation of Failures 1652 1653 A host observes the multicast queries issued by the other hosts on 1654 the network. One of the major benefits of also sending responses 1655 using multicast is that it allows all hosts to see the responses (or 1656 lack thereof) to those queries. 1657 1658 If a host sees queries, for which a record in its cache would be 1659 expected to be given as an answer in a multicast response, but no 1660 such answer is seen, then the host may take this as an indication 1661 that the record may no longer be valid. 1662 1663 After seeing two or more of these queries, and seeing no multicast 1664 response containing the expected answer within a reasonable amount of 1665 time, then even though its TTL may indicate that it is not yet due to 1666 expire, that record MAY be flushed from the cache. The host SHOULD 1667 NOT perform its own queries to re-confirm that the record is truly 1668 gone. If every host on a large network were to do this, it would 1669 cause a lot of unnecessary multicast traffic. If host A sends 1670 multicast queries that remain unanswered, then there is no reason to 1671 suppose that host B or any other host is likely to be any more 1672 successful. 1673 1674 The previous section, "Cache Flush on Failure Indication", describes 1675 a situation where a user trying to print discovers that the printer 1676 is no longer available. By implementing the passive observation 1677 described here, when one user fails to contact the printer, all hosts 1678 on the network observe that failure and update their caches 1679 accordingly. 1680 1681 1682Expires 14th August 2004 Cheshire & Krochmal [Page 29] 1683 1684Internet Draft Multicast DNS 14th February 2004 1685 1686 168714. Enabling and Disabling Multicast DNS 1688 1689 The option to fail-over to Multicast DNS for names not ending in 1690 ".local." SHOULD be a user-configured option, and SHOULD 1691 be disabled by default because of the possible security issues 1692 related to unintended local resolution of apparently global names. 1693 1694 The option to lookup unqualified (relative) names by appending 1695 ".local." (or not) is controlled by whether ".local." appears 1696 (or not) in the client's DNS search list. 1697 1698 No special control is needed for enabling and disabling Multicast DNS 1699 for names explicitly ending with ".local." as entered by the user. 1700 The user doesn't need a way to disable Multicast DNS for names ending 1701 with ".local.", because if the user doesn't want to use Multicast 1702 DNS, they can achieve this by simply not using those names. If a user 1703 *does* enter a name ending in ".local.", then we can safely assume 1704 the user's intention was probably that it should work. Having user 1705 configuration options that can be (intentionally or unintentionally) 1706 set so that local names don't work is just one more way of 1707 frustrating the user's ability to perform the tasks they want, 1708 perpetuating the view that, "IP networking is too complicated to 1709 configure and too hard to use." This in turn perpetuates the 1710 continued use of protocols like AppleTalk. If we want to retire 1711 AppleTalk, NetBIOS, etc., we need to offer users equivalent IP 1712 functionality that they can rely on to, "always work, like 1713 AppleTalk." A little Multicast DNS traffic may be a burden on the 1714 network, but it is an insignificant burden compared to continued 1715 widespread use of AppleTalk. 1716 1717 171815. Considerations for Multiple Interfaces 1719 1720 A host should defend its host name (FQDN) on all active interfaces on 1721 which it is answering Multicast DNS queries. 1722 1723 In the event of a name conflict on *any* interface, a host should 1724 configure a new host name, if it wishes to maintain uniqueness of its 1725 host name. 1726 1727 When answering a Multicast DNS query, a multi-homed host with a 1728 link-local address (or addresses) should take care to ensure that 1729 any address going out in a Multicast DNS response is valid for use 1730 on the interface on which the response is going out. 1731 1732 Just as the same link-local IP address may validly be in use 1733 simultaneously on different links by different hosts, the same 1734 link-local host name may validly be in use simultaneously on 1735 different links, and this is not an error. A multi-homed host with 1736 connections to two different links may be able to communicate with 1737 two different hosts that are validly using the same name. While this 1738 1739 1740Expires 14th August 2004 Cheshire & Krochmal [Page 30] 1741 1742Internet Draft Multicast DNS 14th February 2004 1743 1744 1745 kind of name duplication should be rare, it means that a host that 1746 wants to fully support this case needs network programming APIs that 1747 allow applications to specify on what interface to perform a 1748 link-local Multicast DNS query, and to discover on what interface a 1749 Multicast DNS response was received. 1750 1751 175216. Multicast DNS and Power Management 1753 1754 Many modern network devices have the ability to go into a low-power 1755 mode where only a small part of the Ethernet hardware remains 1756 powered, and the device can be woken up by sending a specially 1757 formatted Ethernet frame which the device's power-management hardware 1758 recognizes. 1759 1760 To make use of this in conjunction with Multicast DNS, the device 1761 first uses DNS-SD to determine if Sleep Proxy Service is available on 1762 the local network. In some networks there may be more than one piece 1763 of hardware implementing Sleep Proxy Service, for fault-tolerance 1764 reasons. 1765 1766 If the device finds the network has Sleep Proxy Service, the device 1767 transmits two or more gratuitous mDNS announcements setting the TTL 1768 of its relevant resource records to zero, to delete them from 1769 neighbouring caches. The relevant resource records include address 1770 records and SRV records, and other resource records as may apply to a 1771 particular device. The device then communicates all of its remaining 1772 active records, plus the names, types and classes of the deleted 1773 records, to the Sleep Proxy Service(s), along with a copy of the 1774 specific "magic packet" required to wake the device up. 1775 1776 When a Sleep Proxy Service sees an mDNS query for one of the 1777 device's active records (e.g. a DNS-SD PTR record), it answers on 1778 behalf of the device without waking it up. When a Sleep Proxy Service 1779 sees an mDNS query for one of the device's deleted resource 1780 records, it deduces that some client on the network needs to make an 1781 active connection to the device, and sends the specified "magic 1782 packet" to wake the device up. The device then wakes up, reactivates 1783 its deleted resource records, and re-announces them to the network. 1784 The client waiting to connect sees the announcements, learns the 1785 current IP address and port number of the desired service on the 1786 device, and proceeds to connect to it. 1787 1788 The connecting client does not need to be aware of how Sleep Proxy 1789 Service works. Only devices that implement low power mode and wish to 1790 make use of Sleep Proxy Service need to be aware of how that protocol 1791 works. 1792 1793 The reason that a device using a Sleep Proxy Service should send more 1794 than one goodbye packet is that the wakeup message is caused by the 1795 Sleep Proxy Service seeing queries for the device's SRV and/or 1796 address records, and those queries are in turn caused by the records 1797 1798Expires 14th August 2004 Cheshire & Krochmal [Page 31] 1799 1800Internet Draft Multicast DNS 14th February 2004 1801 1802 1803 being absent from peer caches. If the records are not deleted from 1804 peer caches, then those peers may use the cached value directly 1805 without querying, and no wakeup message would be generated. 1806 1807 The full specification of mDNS / DNS-SD Sleep Proxy Service 1808 is described in another document [not yet published]. 1809 1810 181117. Multicast DNS Character Set 1812 1813 Unicast DNS has been plagued by the lack of any support for non-US 1814 characters. Indeed, conventional DNS is usually limited to just 1815 letters, digits and hyphens, with no spaces or other punctuation. 1816 Attempts to remedy this have made slow progress because of the need 1817 to accommodate old buggy legacy implementations. 1818 1819 Multicast DNS is a new protocol and doesn't (yet) have old buggy 1820 legacy implementations to constrain the design choices. Accordingly, 1821 it adopts the obvious simple solution: all names in Multicast DNS are 1822 encoded using UTF-8 [RFC 2279]. For names that are restricted to 1823 letters, digits and hyphens, the UTF-8 encoding is identical to the 1824 US-ASCII encoding, so this is entirely compatible with existing host 1825 names. For characters outside the US-ASCII range, UTF-8 encoding is 1826 used. 1827 1828 Multicast DNS implementations MUST NOT use any other encodings apart 1829 from UTF-8 (US-ASCII being considered a compatible subset of UTF-8). 1830 1831 This point bears repeating: There are various baroque representations 1832 of international text being proposed for Unicast DNS. None of these 1833 representations may be used in Multicast DNS packets. Any text being 1834 represented internally in some other representation MUST be converted 1835 to canonical UTF-8 before being placed in any Multicast DNS packet. 1836 1837 The simple rules for case-insensitivity in Unicast DNS also apply in 1838 Multicast DNS; that is to say, in name comparisons, the lower-case 1839 letters "a" to "z" match their upper-case equivalents "A" to "Z". 1840 Hence, if a client issues a query for an address record with the name 1841 "stuartcheshire.local", then a responder having an address record 1842 with the name "StuartCheshire.local" should issue a response. 1843 1844 No other automatic character equivalence is defined in Multicast DNS. 1845 For example, accented characters are not defined to be automatically 1846 equivalent to their unaccented counterparts. Where automatic 1847 equivalences are desired, this may be achieved through the use of 1848 programmatically-generated CNAME records. For example, if a responder 1849 has an address record for an accented name Y, and a client issues a 1850 query for a name X, where X is the same as Y with all the accents 1851 removed, then the responder may issue a response containing two 1852 resource records: A CNAME record "X CNAME Y", asserting that the 1853 requested name X (unaccented) is an alias for the true (accented) 1854 name Y, followed by the address record for Y. 1855 1856Expires 14th August 2004 Cheshire & Krochmal [Page 32] 1857 1858Internet Draft Multicast DNS 14th February 2004 1859 1860 186118. Multicast DNS Message Size 1862 1863 RFC 1035 restricts DNS Messages carried by UDP to no more than 512 1864 bytes (not counting the IP or UDP headers). For UDP packets carried 1865 over the wide-area Internet in 1987, this was appropriate. For 1866 link-local multicast packets on today's networks, there is no reason 1867 to retain this restriction. Given that the packets are by definition 1868 link-local, there are no Path MTU issues to consider. 1869 1870 Multicast DNS Messages carried by UDP may be up to the IP MTU of the 1871 physical interface, less the space required for the IP header (20 1872 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes). 1873 1874 In the case of a single mDNS Resource Record which is too large to 1875 fit in a single MTU-sized multicast response packet, a Multicast DNS 1876 Responder SHOULD send the Resource Record alone, in a single IP 1877 datagram, sent using multiple IP fragments. Resource Records this 1878 large SHOULD be avoided, except in the very rare cases where they 1879 really are the appropriate solution to the problem at hand. 1880 Implementers should be aware that many simple devices do not 1881 re-assemble fragmented IP datagrams, so large Resource Records SHOULD 1882 only be used in specialized cases where the implementer knows that 1883 all receivers implement reassembly. 1884 1885 A Multicast DNS packet larger than the interface MTU, which is sent 1886 using fragments, MUST NOT contain more than one Resource Record. 1887 1888 Even when fragmentation is used, a Multicast DNS packet, including IP 1889 and UDP headers, MUST NOT exceed 9000 bytes. 1890 1891 189219. Multicast DNS Message Format 1893 1894 This section describes specific restrictions on the allowable 1895 values for the header fields of a Multicast DNS message. 1896 189719.1. ID (Query Identifier) 1898 1899 Multicast DNS clients SHOULD listen for gratuitous responses 1900 issued by hosts booting up (or waking up from sleep or otherwise 1901 joining the network). Since these gratuitous responses may contain a 1902 useful answer to a question for which the client is currently 1903 awaiting an answer, Multicast DNS clients SHOULD examine all received 1904 Multicast DNS response messages for useful answers, without regard to 1905 the contents of the ID field or the question section. In Multicast 1906 DNS, knowing which particular query message (if any) is responsible 1907 for eliciting a particular response message is less interesting than 1908 knowing whether the response message contains useful information. 1909 1910 Multicast DNS clients MAY cache any or all Multicast DNS response 1911 messages they receive, for possible future use, providing of course 1912 that normal TTL aging is performed on these cashed resource records. 1913 1914Expires 14th August 2004 Cheshire & Krochmal [Page 33] 1915 1916Internet Draft Multicast DNS 14th February 2004 1917 1918 1919 In multicast query messages, the Query ID SHOULD be set to zero on 1920 transmission. 1921 1922 In multicast responses, including gratuitous multicast responses, the 1923 Query ID MUST be set to zero on transmission, and MUST be ignored on 1924 reception. 1925 1926 In unicast response messages generated specifically in response to a 1927 particular (unicast or multicast) query, the Query ID MUST match the 1928 ID from the query message. 1929 1930 193119.2. QR (Query/Response) Bit 1932 1933 In query messages, MUST be zero. 1934 1935 In response messages, MUST be one. 1936 1937 193819.3. OPCODE 1939 1940 In both multicast query and multicast response messages, MUST be zero 1941 (only standard queries are currently supported over multicast, unless 1942 other queries are allowed by future IETF Standards Action). 1943 1944 194519.4. AA (Authoritative Answer) Bit 1946 1947 In query messages, the Authoritative Answer bit MUST be zero on 1948 transmission, and MUST be ignored on reception. 1949 1950 In response messages for Multicast Domains, the Authoritative Answer 1951 bit MUST be set to one (not setting this bit implies there's some 1952 other place where "better" information may be found) and MUST be 1953 ignored on reception. 1954 1955 195619.5. TC (Truncated) Bit 1957 1958 In query messages, if the TC bit is set, it means that additional 1959 Known Answer records may be following shortly. A responder MAY choose 1960 to record this fact, and wait for those additional Known Answer 1961 records, before deciding whether to respond. If the TC bit is clear, 1962 it means that the querying host has no additional Known Answers. 1963 1964 In multicast response messages, the TC bit MUST be zero on 1965 transmission, and MUST be ignored on reception. 1966 1967 In legacy unicast response messages, the TC bit has the same meaning 1968 as in conventional unicast DNS: it means that the response was too 1969 large to fit in a single packet, so the client SHOULD re-issue its 1970 query using TCP in order to receive the larger response. 1971 1972Expires 14th August 2004 Cheshire & Krochmal [Page 34] 1973 1974Internet Draft Multicast DNS 14th February 2004 1975 1976 197719.6. RD (Recursion Desired) Bit 1978 1979 In both multicast query and multicast response messages, the 1980 Recursion Desired bit SHOULD be zero on transmission, and MUST be 1981 ignored on reception. 1982 1983 198419.7. RA (Recursion Available) Bit 1985 1986 In both multicast query and multicast response messages, the 1987 Recursion Available bit MUST be zero on transmission, and MUST be 1988 ignored on reception. 1989 1990 199119.8. Z (Zero) Bit 1992 1993 In both query and response messages, the Zero bit MUST be zero on 1994 transmission, and MUST be ignored on reception. 1995 1996 199719.9. AD (Authentic Data) Bit [RFC 2535] 1998 1999 In query messages the Authentic Data bit MUST be zero on 2000 transmission, and MUST be ignored on reception. 2001 2002 In response messages, the Authentic Data bit MAY be set. Resolvers 2003 receiving response messages with the AD bit set MUST NOT trust the AD 2004 bit unless they trust the source of the message and either have a 2005 secure path to it or use DNS transaction security. 2006 2007 200819.10. CD (Checking Disabled) Bit [RFC 2535] 2009 2010 In query messages, a resolver willing to do cryptography SHOULD set 2011 the Checking Disabled bit to permit it to impose its own policies. 2012 2013 In response messages, the Checking Disabled bit MUST be zero on 2014 transmission, and MUST be ignored on reception. 2015 2016 201719.11. RCODE (Response Code) 2018 2019 In both multicast query and multicast response messages, the Response 2020 Code MUST be zero on transmission. Multicast DNS messages received 2021 with non-zero Response Codes MUST be silently ignored. 2022 2023 2024 2025 2026 2027 2028 2029 2030Expires 14th August 2004 Cheshire & Krochmal [Page 35] 2031 2032Internet Draft Multicast DNS 14th February 2004 2033 2034 203520. Choice of UDP Port Number 2036 2037 Arguments were made for and against using Multicast on UDP port 53. 2038 The final decision was to use UDP port 5353. Some of the arguments 2039 for and against are given below. 2040 2041 204220.1 Arguments for using UDP port 53: 2043 2044 * This is "just DNS", so it should be the same port. 2045 2046 * There is less work to be done updating old clients to do simple 2047 mDNS queries. Only the destination address need be changed. 2048 In some cases, this can be achieved without any code changes, 2049 just by adding the address 224.0.0.251 to a configuration file. 2050 2051 205220.2 Arguments for using a different port (UDP port 5353): 2053 2054 * This is not "just DNS". This is a DNS-like protocol, but different. 2055 2056 * Changing client code to use a different port number is not hard. 2057 2058 * Using the same port number makes it hard to run an mDNS Responder 2059 and a conventional unicast DNS server on the same machine. If a 2060 conventional unicast DNS server wishes to implement mDNS as well, 2061 it can still do that, by opening two sockets. Having two different 2062 port numbers is important to allow this flexibility. 2063 2064 * Some VPN software hijacks all outgoing traffic to port 53 and 2065 redirects it to a special DNS server set up to serve those VPN 2066 clients while they are connected to the corporate network. It is 2067 questionable whether this is the right thing to do, but it is 2068 common, and redirecting link-local multicast DNS packets to a 2069 remote server rarely produces any useful results. It does mean, for 2070 example, that the user becomes unable to access their local network 2071 printer sitting on their desk right next to their computer. Using 2072 a different UDP port eliminates this particular problem. 2073 2074 * On many operating systems, unprivileged clients may not send or 2075 receive packets on low-numbered ports. This means that any client 2076 sending or receiving mDNS packets on port 53 would have to run as 2077 "root", which is an undesirable security risk. Using a higher- 2078 numbered UDP port eliminates this particular problem. 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088Expires 14th August 2004 Cheshire & Krochmal [Page 36] 2089 2090Internet Draft Multicast DNS 14th February 2004 2091 2092 209321. Summary of Differences Between Multicast DNS and Unicast DNS 2094 2095 The value of Multicast DNS is that it shares, as much as possible, 2096 the familiar APIs, naming syntax, resource record types, etc., of 2097 Unicast DNS. There are of course necessary differences by virtue of 2098 it using Multicast, and by virtue of it operating in a community of 2099 cooperating peers, rather than a precisely defined authoritarian 2100 hierarchy controlled by a strict chain of formal delegations from the 2101 top. These differences are listed below: 2102 2103 Multicast DNS... 2104 * uses multicast 2105 * uses UDP port 5353 instead of port 53 2106 * operates in well-defined parts of the DNS namespace 2107 * uses UTF-8, and only UTF-8, to encode resource record names 2108 * defines a clear limit on the maximum legal domain name (255 bytes) 2109 * allows larger UDP packets 2110 * allows more than one question in a query packet 2111 * uses the Answer Section of a query to list Known Answers 2112 * uses the TC bit in a query to indicate additional Known Answers 2113 * uses the Authority Section of a query for probe tie-breaking 2114 * ignores the Query ID field (except for generating legacy responses) 2115 * doesn't require the question to be repeated in the response packet 2116 * uses gratuitous responses to announce new records to the peer group 2117 * defines a "unicast response" bit in the rrclass of query questions 2118 * defines a "cache flush" bit in the rrclass of responses 2119 * uses DNS TTL 0 to indicate that a record has been deleted 2120 * uses IP TTL 255 to verify that answers originated on the local link 2121 * monitors queries to perform Duplicate Question Suppression 2122 * monitors responses to perform Duplicate Answer Suppression... 2123 * ... and Ongoing Conflict Detection 2124 * ... and Opportunistic Caching 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146Expires 14th August 2004 Cheshire & Krochmal [Page 37] 2147 2148Internet Draft Multicast DNS 14th February 2004 2149 2150 215122. Benefits of Multicast Responses 2152 2153 Some people have argued that sending responses via multicast is 2154 inefficient on the network. In fact the benefits of using multicast 2155 responses result in a net lowering of overall multicast traffic, for 2156 a variety of reasons. 2157 2158 * One multicast response can update the cache on all machines on the 2159 network. If another machine later wants to issue the same query, it 2160 already has the answer in its cache, so it may not need to even 2161 transmit that multicast query on the network at all. 2162 2163 * When more than one machine has the same ongoing long-lived query 2164 running, every machine does not have to transmit its own 2165 independent query. When one machine transmits a query, all the 2166 other hosts see the answers, so they can suppress their own 2167 queries. 2168 2169 * When a host sees a multicast query, but does not see the 2170 corresponding multicast response, it can use this information to 2171 promptly delete stale data from its cache. To achieve the same 2172 level of user-interface quality and responsiveness without 2173 multicast responses would require lower cache lifetimes and more 2174 frequent network polling, resulting in a significantly higher 2175 packet rate. 2176 2177 * Multicast responses allow passive conflict detection. Without this 2178 ability, some other conflict detection mechanism would be needed, 2179 imposing its own additional burden on the network. 2180 2181 * When using delayed responses to reduce network collisions, clients 2182 need to maintain a list recording to whom each answer should be 2183 sent. The option of multicast responses allows clients with limited 2184 storage, which cannot store an arbitrarily long list of response 2185 addresses, to choose to fail-over to a single multicast response in 2186 place of multiple unicast respones, when appropriate. 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204Expires 14th August 2004 Cheshire & Krochmal [Page 38] 2205 2206Internet Draft Multicast DNS 14th February 2004 2207 2208 220923. IPv6 Considerations 2210 2211 An IPv4-only host and an IPv6-only host behave as "ships that pass in 2212 the night". Even if they are on the same Ethernet, neither is aware 2213 of the other's traffic. For this reason, each physical link may have 2214 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 2215 Since for practical purposes, a group of IPv4-only hosts and a group 2216 of IPv6-only hosts on the same Ethernet act as if they were on two 2217 entirely separate Ethernet segments, it is unsurprising that their 2218 use of the ".local." zone should occur exactly as it would if 2219 they really were on two entirely separate Ethernet segments. 2220 2221 A dual-stack (v4/v6) host can participate in both ".local." 2222 zones, and should register its name(s) and perform its lookups both 2223 using IPv4 and IPv6. This enables it to reach, and be reached by, 2224 both IPv4-only and IPv6-only hosts. In effect this acts like a 2225 multi-homed host, with one connection to the logical "IPv4 Ethernet 2226 segment", and a connection to the logical "IPv6 Ethernet segment". 2227 222823.1 IPv6 Multicast Addresses by Hashing 2229 2230 Some discovery protocols use a range of multicast addresses, and 2231 determine the address to be used by a hash function of the name being 2232 sought. Queries are sent via multicast to the address as indicated by 2233 the hash function, and responses are returned to the querier via 2234 unicast. Particularly in IPv6, where multicast addresses are 2235 extremely plentiful, this approach is frequently advocated. 2236 2237 There are some problems with this: 2238 2239 * When a host has a large number of records with different names, the 2240 host may have to join a large number of multicast groups. This can 2241 place undue burden on the Ethernet hardware, which typically 2242 supports a limited number of multicast addresses efficiently. When 2243 this number is exceeded, the Ethernet hardware may have to resort 2244 to receiving all multicasts and passing them up to the host 2245 software for filtering, thereby defeating the point of using a 2246 multicast address range in the first place. 2247 2248 * Multiple questions cannot be placed in one packet if they don't all 2249 hash to the same multicast address. 2250 2251 * Duplicate Question Suppression doesn't work if queriers are not 2252 seeing each other's queries. 2253 2254 * Duplicate Answer Suppression doesn't work if responders are not 2255 seeing each other's responses. 2256 2257 * Opportunistic Caching doesn't work. 2258 2259 * Ongoing Conflict Detection doesn't work. 2260 2261 2262Expires 14th August 2004 Cheshire & Krochmal [Page 39] 2263 2264Internet Draft Multicast DNS 14th February 2004 2265 2266 226724. Security Considerations 2268 2269 The algorithm for detecting and resolving name conflicts is, by its 2270 very nature, an algorithm that assumes cooperating participants. Its 2271 purpose is to allow a group of hosts to arrive at a mutually disjoint 2272 set of host names and other DNS resource record names, in the absence 2273 of any central authority to coordinate this or mediate disputes. In 2274 the absence of any higher authority to resolve disputes, the only 2275 alternative is that the participants must work together cooperatively 2276 to arrive at a resolution. 2277 2278 In an environment where the participants are mutually antagonistic 2279 and unwilling to cooperate, other mechanisms are appropriate, like 2280 manually administered DNS. 2281 2282 In an environment where there is a group of cooperating participants, 2283 but there may be other antagonistic participants on the same physical 2284 link, the cooperating participants need to use IPSEC signatures 2285 and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS 2286 messages from trusted participants (which they process as usual) from 2287 mDNS messages from untrusted participants (which they silently 2288 discard). 2289 2290 When DNS queries for *global* DNS names are sent to the mDNS 2291 multicast address (during network outages which disrupt communication 2292 with the greater Internet) it is *especially* important to use 2293 DNSSEC, because the user may have the impression that he or she is 2294 communicating with some authentic host, when in fact he or she is 2295 really communicating with some local host that is merely masquerading 2296 as that name. This is less critical for names ending with ".local.", 2297 because the user should be aware that those names have only local 2298 significance and no global authority is implied. 2299 2300 Most computer users neglect to type the trailing dot at the end of a 2301 fully qualified domain name, making it a relative domain name (e.g. 2302 "www.example.com"). In the event of network outage, attempts to 2303 positively resolve the name as entered will fail, resulting in 2304 application of the search list, including ".local.", if present. 2305 A malicious host could masquerade as "www.example.com" by answering 2306 the resulting Multicast DNS query for "www.example.com.local." 2307 To avoid this, a host MUST NOT append the search suffix 2308 ".local.", if present, to any relative (partially qualified) 2309 domain name containing two or more labels. Appending ".local." to 2310 single-label relative domain names is acceptable, since the user 2311 should have no expectation that a single-label domain name will 2312 resolve as-is. 2313 2314 2315 2316 2317 2318 2319 2320Expires 14th August 2004 Cheshire & Krochmal [Page 40] 2321 2322Internet Draft Multicast DNS 14th February 2004 2323 2324 232525. IANA Considerations 2326 2327 The IANA has allocated the IPv4 link-local multicast address 2328 224.0.0.251 for the use described in this document. 2329 2330 The IANA has allocated the IPv6 multicast address set FF0X::FB 2331 for the use described in this document. 2332 2333 When this document is published, IANA should designate a list 2334 of domains which are deemed to have only link-local significance, 2335 as described in this document. 2336 2337 No other IANA services are required by this document. 2338 2339 234026. Acknowledgements 2341 2342 The concepts described in this document have been explored and 2343 developed with help from Erik Guttman, Paul Vixie, Bill Woodcock, 2344 and others. 2345 2346 234727. Copyright 2348 2349 Copyright (C) The Internet Society January 2004. 2350 All Rights Reserved. 2351 2352 This document and translations of it may be copied and furnished to 2353 others, and derivative works that comment on or otherwise explain it 2354 or assist in its implementation may be prepared, copied, published 2355 and distributed, in whole or in part, without restriction of any 2356 kind, provided that the above copyright notice and this paragraph are 2357 included on all such copies and derivative works. However, this 2358 document itself may not be modified in any way, such as by removing 2359 the copyright notice or references to the Internet Society or other 2360 Internet organizations, except as needed for the purpose of 2361 developing Internet standards in which case the procedures for 2362 copyrights defined in the Internet Standards process must be 2363 followed, or as required to translate it into languages other than 2364 English. 2365 2366 The limited permissions granted above are perpetual and will not be 2367 revoked by the Internet Society or its successors or assigns. 2368 2369 This document and the information contained herein is provided on an 2370 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2371 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2372 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2373 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2374 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2375 2376 2377 2378Expires 14th August 2004 Cheshire & Krochmal [Page 41] 2379 2380Internet Draft Multicast DNS 14th February 2004 2381 2382 238328. Normative References 2384 2385 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 2386 Facilities", STD 13, RFC 1034, November 1987. 2387 2388 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 2389 Specifications", STD 13, RFC 1035, November 1987. 2390 2391 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 2392 Requirement Levels", RFC 2119, March 1997. 2393 2394 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO 2395 10646", RFC 2279, January 1998. 2396 2397 239829. Informative References 2399 2400 [dotlocal] <http://www.dotlocal.org/> 2401 2402 [djbdl] <http://cr.yp.to/djbdns/dot-local.html> 2403 2404 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service 2405 Discovery", Internet-Draft (work in progress), 2406 draft-cheshire-dnsext-dns-sd-02.txt, February 2004. 2407 2408 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 2409 Overview and Architecture. 2410 Institute of Electrical and Electronic Engineers, 2411 IEEE Standard 802, 1990. 2412 2413 [NBP] Cheshire, S., and M. Krochmal, 2414 "Requirements for a Protocol to Replace AppleTalk NBP", 2415 Internet-Draft (work in progress), 2416 draft-cheshire-dnsext-nbp-03.txt, February 2004. 2417 2418 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 2419 System (DNS UPDATE)", RFC 2136, April 1997. 2420 2421 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address 2422 Autoconfiguration", RFC 2462, December 1998. 2423 2424 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", 2425 RFC 2535, March 1999. 2426 2427 [v4LL] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic 2428 Configuration of IPv4 Link-Local Addresses", 2429 Internet-Draft (work in progress), 2430 draft-ietf-zeroconf-ipv4-linklocal-11.txt, January 2004. 2431 2432 [ZC] Williams, A., "Requirements for Automatic Configuration 2433 of IP Hosts", Internet-Draft (work in progress), 2434 draft-ietf-zeroconf-reqts-12.txt, September 2002. 2435 2436Expires 14th August 2004 Cheshire & Krochmal [Page 42] 2437 2438Internet Draft Multicast DNS 14th February 2004 2439 2440 244130. Author's Addresses 2442 2443 Stuart Cheshire 2444 Apple Computer, Inc. 2445 1 Infinite Loop 2446 Cupertino 2447 California 95014 2448 USA 2449 2450 Phone: +1 408 974 3207 2451 EMail: rfc@stuartcheshire.org 2452 2453 2454 Marc Krochmal 2455 Apple Computer, Inc. 2456 1 Infinite Loop 2457 Cupertino 2458 California 95014 2459 USA 2460 2461 Phone: +1 408 974 4368 2462 EMail: marc@apple.com 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494Expires 14th August 2004 Cheshire & Krochmal [Page 43]