1Document: draft-cheshire-dnsext-multicastdns-06.txt Stuart Cheshire 2Internet-Draft Marc Krochmal 3Category: Standards Track Apple Computer, Inc. 4Expires 10th February 2007 10th August 2006 5 6 Multicast DNS 7 8 <draft-cheshire-dnsext-multicastdns-06.txt> 9 10Status of this Memo 11 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 For the purposes of this document, the term "BCP 79" refers 17 exclusively to RFC 3979, "Intellectual Property Rights in IETF 18 Technology", published March 2005. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 24 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 35 36Abstract 37 38 As networked devices become smaller, more portable, and 39 more ubiquitous, the ability to operate with less configured 40 infrastructure is increasingly important. In particular, 41 the ability to look up DNS resource record data types 42 (including, but not limited to, host names) in the absence 43 of a conventional managed DNS server, is becoming essential. 44 45 Multicast DNS (mDNS) provides the ability to do DNS-like operations 46 on the local link in the absence of any conventional unicast DNS 47 server. In addition, mDNS designates a portion of the DNS namespace 48 to be free for local use, without the need to pay any annual fee, and 49 without the need to set up delegations or otherwise configure a 50 conventional DNS server to answer for those names. 51 52 The primary benefits of mDNS names are that (i) they require little 53 or no administration or configuration to set them up, (ii) they work 54 when no infrastructure is present, and (iii) they work during 55 infrastructure failures. 56 57 58Expires 10th February 2007 Cheshire & Krochmal [Page 1] 59 60Internet Draft Multicast DNS 10th August 2006 61 62 63Table of Contents 64 65 1. Introduction....................................................3 66 2. Conventions and Terminology Used in this Document...............3 67 3. Multicast DNS Names.............................................4 68 4. Source Address Check............................................8 69 5. Reverse Address Mapping.........................................9 70 6. Querying.......................................................10 71 7. Duplicate Suppression..........................................15 72 8. Responding.....................................................17 73 9. Probing and Announcing on Startup..............................20 74 10. Conflict Resolution............................................26 75 11. Resource Record TTL Values and Cache Coherency.................28 76 12. Special Characteristics of Multicast DNS Domains...............33 77 13. Multicast DNS for Service Discovery............................34 78 14. Enabling and Disabling Multicast DNS...........................34 79 15. Considerations for Multiple Interfaces.........................35 80 16. Considerations for Multiple Responders on the Same Machine.....36 81 17. Multicast DNS and Power Management.............................38 82 18. Multicast DNS Character Set....................................39 83 19. Multicast DNS Message Size.....................................41 84 20. Multicast DNS Message Format...................................42 85 21. Choice of UDP Port Number......................................45 86 22. Summary of Differences Between Multicast DNS and Unicast DNS...46 87 23. Benefits of Multicast Responses................................47 88 24. IPv6 Considerations............................................48 89 25. Security Considerations........................................49 90 26. IANA Considerations............................................50 91 27. Acknowledgments................................................50 92 28. Deployment History.............................................50 93 29. Copyright Notice...............................................51 94 30. Normative References...........................................51 95 31. Informative References.........................................52 96 32. Authors' Addresses.............................................53 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116Expires 10th February 2007 Cheshire & Krochmal [Page 2] 117 118Internet Draft Multicast DNS 10th August 2006 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 [RFC 2462] [RFC 3927] 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 147 to make a distinction between the application behavior and the 148 underlying protocol behavior. If a chatty application uses UDP, 149 that 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 1552. Conventions and Terminology Used in this Document 156 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in "Key words for use in 160 RFCs to Indicate Requirement Levels" [RFC 2119]. 161 162 This document uses the term "host name" in the strict sense to mean 163 a fully qualified domain name that has an address record. It does 164 not use the term "host name" in the commonly used but incorrect 165 sense to mean just the first DNS label of a host's fully qualified 166 domain name. 167 168 A DNS (or mDNS) packet contains an IP TTL in the IP header, which 169 is effectively a hop-count limit for the packet, to guard against 170 routing loops. Each Resource Record also contains a TTL, which is 171 the number of seconds for which the Resource Record may be cached. 172 173 174Expires 10th February 2007 Cheshire & Krochmal [Page 3] 175 176Internet Draft Multicast DNS 10th August 2006 177 178 179 In any place where there may be potential confusion between these two 180 types of TTL, the term "IP TTL" is used to refer to the IP header TTL 181 (hop limit), and the term "RR TTL" is used to refer to the Resource 182 Record TTL (cache lifetime). 183 184 When this document uses the term "Multicast DNS", it should be taken 185 to mean: "Clients performing DNS-like queries for DNS-like resource 186 records by sending DNS-like UDP query and response packets over IP 187 Multicast to UDP port 5353." 188 189 This document uses the terms "shared" and "unique" when referring to 190 resource record sets. 191 192 A "shared" resource record set is one where several Multicast DNS 193 responders may have records with that name, rrtype, and rrclass, and 194 several responders may respond to a particular query. 195 196 A "unique" resource record set is one where all the records with 197 that name, rrtype, and rrclass are conceptually under the control 198 or ownership of a single responder, and it is expected that at most 199 one responder should respond to a query for that name, rrtype, and 200 rrclass. Before claiming ownership of a unique resource record set, 201 a responder MUST probe to verify that no other responder already 202 claims ownership of that set, as described in Section 9.1 "Probing". 203 For fault-tolerance and other reasons it is permitted sometimes to 204 have more than one responder answering for a particular "unique" 205 resource record set, but such cooperating responders MUST give 206 answers containing identical rdata for these records or the 207 answers will be perceived to be in conflict with each other. 208 209 Strictly speaking the terms "shared" and "unique" apply to resource 210 record sets, not to individual resource records, but it is sometimes 211 convenient to talk of "shared resource records" and "unique resource 212 records". When used this way, the terms should be understood to mean 213 a record that is a member of a "shared" or "unique" resource record 214 set, respectively. 215 216 2173. Multicast DNS Names 218 219 This document proposes that the DNS top-level domain ".local." be 220 designated a special domain with special semantics, namely that any 221 fully-qualified name ending in ".local." is link-local, and names 222 within this domain are meaningful only on the link where they 223 originate. This is analogous to IPv4 addresses in the 169.254/16 224 prefix, which are link-local and meaningful only on the link where 225 they originate. 226 227 Any DNS query for a name ending with ".local." MUST be sent 228 to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent 229 FF02::FB). 230 231 232Expires 10th February 2007 Cheshire & Krochmal [Page 4] 233 234Internet Draft Multicast DNS 10th August 2006 235 236 237 It is unimportant whether a name ending with ".local." occurred 238 because the user explicitly typed in a fully qualified domain name 239 ending in ".local.", or because the user entered an unqualified 240 domain name and the host software appended the suffix ".local." 241 because that suffix appears in the user's search list. The ".local." 242 suffix could appear in the search list because the user manually 243 configured it, or because it was received in a DHCP option, or via 244 any other valid mechanism for configuring the DNS search list. In 245 this respect the ".local." suffix is treated no differently to any 246 other search domain that might appear in the DNS search list. 247 248 DNS queries for names that do not end with ".local." MAY be sent to 249 the mDNS multicast address, if no other conventional DNS server is 250 available. This can allow hosts on the same link to continue 251 communicating using each other's globally unique DNS names during 252 network outages which disrupt communication with the greater 253 Internet. When resolving global names via local multicast, it is even 254 more important to use DNSSEC or other security mechanisms to ensure 255 that the response is trustworthy. Resolving global names via local 256 multicast is a contentious issue, and this document does not discuss 257 it in detail, instead concentrating on the issue of resolving local 258 names using DNS packets sent to a multicast address. 259 260 A host that belongs to an organization or individual who has control 261 over some portion of the DNS namespace can be assigned a globally 262 unique name within that portion of the DNS namespace, for example, 263 "cheshire.apple.com." For those of us who have this luxury, this 264 works very well. However, the majority of home customers do not have 265 easy access to any portion of the global DNS namespace within which 266 they have the authority to create names as they wish. This leaves the 267 majority of home computers effectively anonymous for practical 268 purposes. 269 270 To remedy this problem, this document allows any computer user to 271 elect to give their computers link-local Multicast DNS host names of 272 the form: "single-dns-label.local." For example, a laptop computer 273 may answer to the name "cheshire.local." Any computer user is granted 274 the authority to name their computer this way, provided that the 275 chosen host name is not already in use on that link. Having named 276 their computer this way, the user has the authority to continue using 277 that name until such time as a name conflict occurs on the link which 278 is not resolved in the user's favour. If this happens, the computer 279 (or its human user) SHOULD cease using the name, and may choose to 280 attempt to allocate a new unique name for use on that link. These 281 conflicts are expected to be relatively rare for people who choose 282 reasonably imaginative names, but it is still important to have a 283 mechanism in place to handle them when they happen. 284 285 The point made in the previous paragraph is very important and bears 286 repeating. It is easy for those of us in the IETF community who run 287 our own name servers at home to forget that the majority of computer 288 289 290Expires 10th February 2007 Cheshire & Krochmal [Page 5] 291 292Internet Draft Multicast DNS 10th August 2006 293 294 295 users do not run their own name server and have no easy way to create 296 their own host names. When these users wish to transfer files between 297 two laptop computers, they are frequently reduced to typing in 298 dotted-decimal IP addresses because they simply have no other way for 299 one host to refer to the other by name. This is a sorry state of 300 affairs. What is worse, most users don't even bother trying to use 301 dotted-decimal IP addresses. Most users still move data between 302 machines by burning it onto CD-R, copying it onto a USB "keychain" 303 flash drive, or similar removable media. 304 305 In a world of gigabit Ethernet and ubiquitous wireless networking it 306 is a sad indictment of the networking community that most users still 307 prefer sneakernet. 308 309 Allowing ad-hoc allocation of single-label names in a single flat 310 ".local." namespace may seem to invite chaos. However, operational 311 experience with AppleTalk NBP names [NBP], which on any given link 312 are also effectively single-label names in a flat namespace, shows 313 that in practice name collisions happen extremely rarely and are not 314 a problem. Groups of computer users from disparate organizations 315 bring Macintosh laptop computers to events such as IETF Meetings, the 316 Mac Hack conference, the Apple World Wide Developer Conference, etc., 317 and complaints at these events about users suffering conflicts and 318 being forced to rename their machines have never been an issue. 319 320 This document advocates a single flat namespace for dot-local host 321 names, (i.e. the names of DNS address records), but other DNS record 322 types (such as those used by DNS Service Discovery [DNS-SD]) may 323 contain as many labels as appropriate for the desired usage, subject 324 to the 255-byte name length limit specified below in Section 3.3 325 "Maximum Multicast DNS Name Length". 326 327 Enforcing uniqueness of host names (i.e. the names of DNS address 328 records mapping names to IP addresses) is probably desirable in the 329 common case, but this document does not mandate that. It is 330 permissible for a collection of coordinated hosts to agree to 331 maintain multiple DNS address records with the same name, possibly 332 for load balancing or fault-tolerance reasons. This document does not 333 take a position on whether that is sensible. It is important that 334 both modes of operation are supported. The Multicast DNS protocol 335 allows hosts to verify and maintain unique names for resource records 336 where that behavior is desired, and it also allows hosts to maintain 337 multiple resource records with a single shared name where that 338 behavior is desired. This consideration applies to all resource 339 records, not just address records (host names). In summary: It is 340 required that the protocol have the ability to detect and handle name 341 conflicts, but it is not required that this ability be used for every 342 record. 343 344 345 346 347 348Expires 10th February 2007 Cheshire & Krochmal [Page 6] 349 350Internet Draft Multicast DNS 10th August 2006 351 352 3533.1 Governing Standards Body 354 355 Note that this use of the ".local." suffix falls under IETF/IANA 356 jurisdiction, not ICANN jurisdiction. DNS is an IETF network 357 protocol, governed by protocol rules defined by the IETF. These IETF 358 protocol rules dictate character set, maximum name length, packet 359 format, etc. ICANN determines additional rules that apply when the 360 IETF's DNS protocol is used on the public Internet. In contrast, 361 private uses of the DNS protocol on isolated private networks are not 362 governed by ICANN. Since this proposed change is a change to the core 363 DNS protocol rules, it affects everyone, not just those machines 364 using the ICANN-governed Internet. Hence this change falls into the 365 category of an IETF protocol rule, not an ICANN usage rule. 366 367 This allocation of responsibility is formally established in 368 "Memorandum of Understanding Concerning the Technical Work of the 369 Internet Assigned Numbers Authority" [RFC 2860]. Exception (a) of 370 clause 4.3 states that the IETF has the authority to instruct IANA 371 to reserve pseudo-TLDs as required for protocol design purposes. 372 For example, "Reserved Top Level DNS Names" [RFC 2606] defines 373 the following pseudo-TLDs: 374 375 .test 376 .example 377 .invalid 378 .localhost 379 380 3813.2 Private DNS Namespaces 382 383 Note also that the special treatment of names ending in ".local." has 384 been implemented in Macintosh computers since the days of Mac OS 9, 385 and continues today in Mac OS X. There are also implementations for 386 Linux and other platforms [dotlocal]. Operators setting up private 387 internal networks ("intranets") are advised that their lives may be 388 easier if they avoid using the suffix ".local." in names in their 389 private internal DNS server. Alternative possibilities include: 390 391 .intranet 392 .internal 393 .private 394 .corp 395 .home 396 .lan 397 398 Another alternative naming scheme, advocated by Professor D. J. 399 Bernstein, is to use a numerical suffix, such as ".6." [djbdl]. 400 401 402 403 404 405 406Expires 10th February 2007 Cheshire & Krochmal [Page 7] 407 408Internet Draft Multicast DNS 10th August 2006 409 410 4113.3 Maximum Multicast DNS Name Length 412 413 RFC 1034 says: 414 415 "the total number of octets that represent a domain name (i.e., 416 the sum of all label octets and label lengths) is limited to 255." 417 418 This text implies that the final root label at the end of every name 419 is included in this count (a name can't be represented without it), 420 but the text does not explicitly state that. Implementations of 421 Multicast DNS MUST include the label length byte of the final root 422 label at the end of every name when enforcing the rule that no name 423 may be longer than 255 bytes. For example, the length of the name 424 "apple.com." is considered to be 11, which is the number of bytes it 425 takes to represent that name in a packet without using name 426 compression: 427 428 ------------------------------------------------------ 429 | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 | 430 ------------------------------------------------------ 431 432 4334. Source Address Check 434 435 All Multicast DNS responses (including responses sent via unicast) 436 SHOULD be sent with IP TTL set to 255. This is recommended to provide 437 backwards-compatibility with older Multicast DNS clients that check 438 the IP TTL on reception to determine whether the packet originated 439 on the local link. These older clients discard all packets with TTLs 440 other than 255. 441 442 A host sending Multicast DNS queries to a link-local destination 443 address (including the 224.0.0.251 link-local multicast address) 444 MUST only accept responses to that query that originate from the 445 local link, and silently discard any other response packets. Without 446 this check, it could be possible for remote rogue hosts to send 447 spoof answer packets (perhaps unicast to the victim host) which the 448 receiving machine could misinterpret as having originated on the 449 local link. 450 451 The test for whether a response originated on the local link 452 is done in two ways: 453 454 * All responses sent to the link-local multicast address 224.0.0.251 455 are necessarily deemed to have originated on the local link, 456 regardless of source IP address. This is essential to allow devices 457 to work correctly and reliably in unusual configurations, such as 458 multiple logical IP subnets overlayed on a single link, or in cases 459 of severe misconfiguration, where devices are physically connected 460 to the same link, but are currently misconfigured with completely 461 unrelated IP addresses and subnet masks. 462 463 464Expires 10th February 2007 Cheshire & Krochmal [Page 8] 465 466Internet Draft Multicast DNS 10th August 2006 467 468 469 * For responses sent to a unicast destination address, the source IP 470 address in the packet is checked to see if it is an address on a 471 local subnet. An address is determined to be on a local subnet if, 472 for (one of) the address(es) configured on the interface receiving 473 the packet, (I & M) == (P & M), where I and M are the interface 474 address and subnet mask respectively, P is the source IP address 475 from the packet, '&' represents the bitwise logical 'and' 476 operation, and '==' represents a bitwise equality test. 477 478 Since queriers will ignore responses apparently originating outside 479 the local subnet, responders SHOULD avoid generating responses that 480 it can reasonably predict will be ignored. This applies particularly 481 in the case of overlayed subnets. If a responder receives a query 482 addressed to the link-local multicast address 224.0.0.251, from a 483 source address not apparently on the same subnet as the responder, 484 then even if the query indicates that a unicast response is preferred 485 (see Section 6.5, "Questions Requesting Unicast Responses"), the 486 responder SHOULD elect to respond by multicast anyway, since it can 487 reasonably predict that a unicast response with an apparently 488 non-local source address will probably be ignored. 489 490 4915. Reverse Address Mapping 492 493 Like ".local.", the IPv4 and IPv6 reverse mapping domains are also 494 defined to be link-local. 495 496 Any DNS query for a name ending with "254.169.in-addr.arpa." MUST 497 be sent to the mDNS multicast address 224.0.0.251. Since names under 498 this domain correspond to IPv4 link-local addresses, it is logical 499 that the local link is the best place to find information pertaining 500 to those names. 501 502 Likewise, any DNS query for a name within the reverse mapping domains 503 for IPv6 Link-Local addresses ("8.e.f.ip6.arpa.", "9.e.f.ip6.arpa.", 504 "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST be sent to the IPv6 505 mDNS link-local multicast address FF02::FB. 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522Expires 10th February 2007 Cheshire & Krochmal [Page 9] 523 524Internet Draft Multicast DNS 10th August 2006 525 526 5276. Querying 528 529 There are three kinds of Multicast DNS Queries, one-shot queries of 530 the kind made by today's conventional DNS clients, one-shot queries 531 accumulating multiple responses made by multicast-aware DNS clients, 532 and continuous ongoing Multicast DNS Queries used by IP network 533 browser software. 534 535 A Multicast DNS Responder that is offering records that are intended 536 to be unique on the local link MUST also implement a Multicast DNS 537 Querier so that it can first verify the uniqueness of those records 538 before it begins answering queries for them. 539 540 5416.1 One-Shot Multicast DNS Queries 542 543 An unsophisticated DNS client may simply send its DNS queries blindly 544 to 224.0.0.251:5353, without necessarily even being aware what a 545 multicast address is. This change can typically be implemented with 546 just a few lines of code in an existing DNS resolver library. Any 547 time the name being queried for falls within one of the reserved 548 mDNS domains (see Section 12 "Special Characteristics of Multicast 549 DNS Domains") the query is sent to 224.0.0.251:5353 instead of the 550 configured unicast DNS server address that would otherwise be used. 551 Typically the timeout would also be shortened to two or three 552 seconds, but it's possible to make a minimal mDNS client with no 553 other changes apart from these. 554 555 A simple DNS client like this will typically just take the first 556 response it receives. It will not listen for additional UDP 557 responses, but in many instances this may not be a serious problem. 558 If a user types "http://cheshire.local." into their Web browser and 559 gets to see the page they were hoping for, then the protocol has met 560 the user's needs in this case. 561 562 While an unsophisticated DNS client like this is perfectly adequate 563 for simple hostname lookup, it may not get ideal behavior in 564 other cases. Additional refinements that may be adopted by more 565 sophisticated clients are described below. 566 567 5686.2 One-Shot Queries, Accumulating Multiple Responses 569 570 A more sophisticated DNS client should understand that Multicast DNS 571 is not exactly the same as unicast DNS, and should modify its 572 behavior in some simple ways. 573 574 As described above, there are some cases, such as looking up the 575 address associated with a unique host name, where a single response 576 is sufficient, and moreover may be all that is expected. However, 577 there are other DNS queries where more than one response is 578 579 580Expires 10th February 2007 Cheshire & Krochmal [Page 10] 581 582Internet Draft Multicast DNS 10th August 2006 583 584 585 possible, and for these queries a more sophisticated Multicast DNS 586 client should include the ability to wait for an appropriate period 587 of time to collect multiple responses. 588 589 A naive DNS client retransmits its query only so long as it has 590 received no response. A more sophisticated Multicast DNS client is 591 aware that having received one response is not necessarily an 592 indication that it might not receive others, and has the ability to 593 retransmit its query an appropriate number of times at appropriate 594 intervals until it is satisfied with the collection of responses it 595 has gathered. 596 597 A more sophisticated Multicast DNS client that is retransmitting 598 a query for which it has already received some responses, MUST 599 implement Known Answer Suppression, as described below in Section 7.1 600 "Known Answer Suppression". This indicates to responders who have 601 already replied that their responses have been received, and they 602 don't need to send them again in response to this repeated query. In 603 addition, when retransmitting queries, the interval between the first 604 two queries SHOULD be one second, and the intervals between 605 subsequent queries SHOULD double. 606 607 6086.3 Continuous Multicast DNS Querying 609 610 In One-Shot Queries, with either a single or multiple responses, 611 the underlying assumption is that the transaction begins when the 612 application issues a query, and ends when all the desired responses 613 have been received. There is another type of operation which is more 614 akin to continuous monitoring. 615 616 iTunes users are accustomed to seeing a list of shared network music 617 libraries in the sidebar of the iTunes window. There is no "refresh" 618 button for the user to click because the list is always accurate, 619 always reflecting the currently available libraries. When a new 620 library becomes available it promptly appears in the list, and when 621 a library becomes unavailable it promptly disappears. It is vitally 622 important that this responsive user interface be achieved without 623 naive polling that would place an unreasonable burden on the network. 624 625 Therefore, when retransmitting mDNS queries to implement this kind 626 of continuous monitoring, the interval between the first two queries 627 SHOULD be one second, the intervals between the subsequent queries 628 SHOULD double, and the querier MUST implement Known Answer 629 Suppression, as described below in Section 7.1. When the interval 630 between queries reaches or exceeds 60 minutes, a querier MAY cap the 631 interval to a maximum of 60 minutes, and perform subsequent queries 632 at a steady-state rate of one query per hour. To avoid accidental 633 synchronization when for some reason multiple clients begin querying 634 at exactly the same moment (e.g. because of some common external 635 trigger event), a Multicast DNS Querier SHOULD also delay the first 636 637 638Expires 10th February 2007 Cheshire & Krochmal [Page 11] 639 640Internet Draft Multicast DNS 10th August 2006 641 642 643 query of the series by a randomly-chosen amount in the range 644 20-120ms. 645 646 When a Multicast DNS Querier receives an answer, the answer contains 647 a TTL value that indicates for how many seconds this answer is valid. 648 After this interval has passed, the answer will no longer be valid 649 and SHOULD be deleted from the cache. Before this time is reached, 650 a Multicast DNS Querier which has clients with an active interest in 651 the state of that record (e.g. a network browsing window displaying 652 a list of discovered services to the user) SHOULD re-issue its query 653 to determine whether the record is still valid. 654 655 To perform this cache maintenance, a Multicast DNS Querier should 656 plan to re-query for records after at least 50% of the record 657 lifetime has elapsed. This document recommends the following 658 specific strategy: 659 660 The Querier should plan to issue a query at 80% of the record 661 lifetime, and then if no answer is received, at 85%, 90% and 95%. 662 If an answer is received, then the remaining TTL is reset to the 663 value given in the answer, and this process repeats for as long as 664 the Multicast DNS Querier has an ongoing interest in the record. 665 If after four queries no answer is received, the record is deleted 666 when it reaches 100% of its lifetime. A Multicast DNS Querier MUST 667 NOT perform this cache maintenance for records for which it has no 668 clients with an active interest. If the expiry of a particular record 669 from the cache would result in no net effect to any client software 670 running on the Querier device, and no visible effect to the human 671 user, then there is no reason for the Multicast DNS Querier to 672 waste network bandwidth checking whether the record remains valid. 673 674 To avoid the case where multiple Multicast DNS Queriers on a network 675 all issue their queries simultaneously, a random variation of 2% of 676 the record TTL should be added, so that queries are scheduled to be 677 performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL. 678 679 6806.4 Multiple Questions per Query 681 682 Multicast DNS allows a querier to place multiple questions in the 683 Question Section of a single Multicast DNS query packet. 684 685 The semantics of a Multicast DNS query packet containing multiple 686 questions is identical to a series of individual DNS query packets 687 containing one question each. Combining multiple questions into a 688 single packet is purely an efficiency optimization, and has no other 689 semantic significance. 690 691 692 693 694 695 696Expires 10th February 2007 Cheshire & Krochmal [Page 12] 697 698Internet Draft Multicast DNS 10th August 2006 699 700 7016.5 Questions Requesting Unicast Responses 702 703 Sending Multicast DNS responses via multicast has the benefit that 704 all the other hosts on the network get to see those responses, and 705 can keep their caches up to date, and detect conflicting responses. 706 707 However, there are situations where all the other hosts on the 708 network don't need to see every response. Some examples are a laptop 709 computer waking from sleep, or the Ethernet cable being connected to 710 a running machine, or a previously inactive interface being activated 711 through a configuration change. At the instant of wake-up or link 712 activation, the machine is a brand new participant on a new network. 713 Its Multicast DNS cache for that interface is empty, and it has no 714 knowledge of its peers on that link. It may have a significant number 715 of questions that it wants answered right away to discover 716 information about its new surroundings and present that information 717 to the user. As a new participant on the network, it has no idea 718 whether the exact same questions may have been asked and answered 719 just seconds ago. In this case, triggering a large sudden flood of 720 multicast responses may impose an unreasonable burden on the network. 721 722 To avoid large floods of potentially unnecessary responses in these 723 cases, Multicast DNS defines the top bit in the class field of a DNS 724 question as the "unicast response" bit. When this bit is set in a 725 question, it indicates that the Querier is willing to accept unicast 726 responses instead of the usual multicast responses. These questions 727 requesting unicast responses are referred to as "QU" questions, to 728 distinguish them from the more usual questions requesting multicast 729 responses ("QM" questions). A Multicast DNS Querier sending its 730 initial batch of questions immediately on wake from sleep or 731 interface activation SHOULD set the "QU" bit in those questions. 732 733 When a question is retransmitted (as described in Section 6.3 734 "Continuous Multicast DNS Querying") the "QU" bit SHOULD NOT be set 735 in subsequent retransmissions of that question. Subsequent 736 retransmissions SHOULD be usual "QM" questions. After the first 737 question has received its responses, the querier should have a large 738 known-answer list (see "Known Answer Suppression" below) so that 739 subsequent queries should elicit few, if any, further responses. 740 Reverting to multicast responses as soon as possible is important 741 because of the benefits that multicast responses provide (see 742 "Benefits of Multicast Responses" below). In addition, the "QU" bit 743 SHOULD be set only for questions that are active and ready to be sent 744 the moment of wake from sleep or interface activation. New questions 745 issued by clients afterwards should be treated as normal "QM" 746 questions and SHOULD NOT have the "QU" bit set on the first question 747 of the series. 748 749 When receiving a question with the "unicast response" bit set, a 750 responder SHOULD usually respond with a unicast packet directed back 751 to the querier. If the responder has not multicast that record 752 753 754Expires 10th February 2007 Cheshire & Krochmal [Page 13] 755 756Internet Draft Multicast DNS 10th August 2006 757 758 759 recently (within one quarter of its TTL), then the responder SHOULD 760 instead multicast the response so as to keep all the peer caches up 761 to date, and to permit passive conflict detection. In the case of 762 answering a probe question with the "unicast response" bit set, the 763 responder should always generate the requested unicast response, but 764 may also send a multicast announcement too if the time since the last 765 multicast announcement of that record is more than a quarter of its 766 TTL. 767 768 Except when defending a unique name against a probe from another host 769 unicast replies are subject to all the same packet generation rules 770 as multicast replies, including the cache flush bit (see Section 771 11.3, "Announcements to Flush Outdated Cache Entries") and randomized 772 delays to reduce network collisions (see Section 8, "Responding"). 773 774 7756.6 Delaying Initial Query 776 777 If a query is issued for which there already exist one or more 778 records in the local cache, and those record(s) were received with 779 the cache flush bit set (see Section 11.3, "Announcements to Flush 780 Outdated Cache Entries"), indicating that they form a unique RRSet, 781 then the host SHOULD delay its initial query by imposing a random 782 delay from 500-1000ms. This is to avoid the situation where a group 783 of hosts are synchronized by some external event and all perform 784 the same query simultaneously. This means that when the first host 785 (selected randomly by this algorithm) transmits its query, all the 786 other hosts that were about to transmit the same query can suppress 787 their superfluous queries, as described in "Duplicate Question 788 Suppression" below. 789 790 7916.7 Direct Unicast Queries to port 5353 792 793 In specialized applications there may be rare situations where it 794 makes sense for a Multicast DNS Querier to send its query via unicast 795 to a specific machine. When a Multicast DNS Responder receives a 796 query via direct unicast, it SHOULD respond as it would for a 797 "QU" query, as described above in Section 6.5 "Questions Requesting 798 Unicast Responses". Since it is possible for a unicast query to be 799 received from a machine outside the local link, Responders SHOULD 800 check that the source address in the query packet matches the local 801 subnet for that link, and silently ignore the packet if not. 802 803 There may be specialized situations, outside the scope of this 804 document, where it is intended and desirable to create a Responder 805 that does answer queries originating outside the local link. Such 806 a Responder would need to ensure that these non-local queries are 807 always answered via unicast back to the Querier, since an answer sent 808 via link-local multicast would not reach a Querier outside the local 809 link. 810 811 812Expires 10th February 2007 Cheshire & Krochmal [Page 14] 813 814Internet Draft Multicast DNS 10th August 2006 815 816 8177. Duplicate Suppression 818 819 A variety of techniques are used to reduce the amount of redundant 820 traffic on the network. 821 8227.1 Known Answer Suppression 823 824 When a Multicast DNS Querier sends a query to which it already knows 825 some answers, it populates the Answer Section of the DNS message with 826 those answers. 827 828 A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if 829 the answer it would give is already included in the Answer Section 830 with an RR TTL at least half the correct value. If the RR TTL of the 831 answer as given in the Answer Section is less than half of the true 832 RR TTL as known by the Multicast DNS Responder, the responder MUST 833 send an answer so as to update the Querier's cache before the record 834 becomes in danger of expiration. 835 836 Because a Multicast DNS Responder will respond if the remaining TTL 837 given in the known answer list is less than half the true TTL, it is 838 superfluous for the Querier to include such records in the known 839 answer list. Therefore a Multicast DNS Querier SHOULD NOT include 840 records in the known answer list whose remaining TTL is less than 841 half their original TTL. Doing so would simply consume space in the 842 packet without achieving the goal of suppressing responses, and would 843 therefore be a pointless waste of network bandwidth. 844 845 A Multicast DNS Querier MUST NOT cache resource records observed in 846 the Known Answer Section of other Multicast DNS Queries. The Answer 847 Section of Multicast DNS Queries is not authoritative. By placing 848 information in the Answer Section of a Multicast DNS Query the 849 querier is stating that it *believes* the information to be true. 850 It is not asserting that the information *is* true. Some of those 851 records may have come from other hosts that are no longer on the 852 network. Propagating that stale information to other Multicast DNS 853 Queriers on the network would not be helpful. 854 855 8567.2 Multi-Packet Known Answer Suppression 857 858 Sometimes a Multicast DNS Querier will already have too many answers 859 to fit in the Known Answer Section of its query packets. In this 860 case, it should issue a Multicast DNS Query containing a question and 861 as many Known Answer records as will fit. It MUST then set the TC 862 (Truncated) bit in the header before sending the Query. It MUST then 863 immediately follow the packet with another query packet containing no 864 questions, and as many more Known Answer records as will fit. If 865 there are still too many records remaining to fit in the packet, it 866 again sets the TC bit and continues until all the Known Answer 867 records have been sent. 868 869 870Expires 10th February 2007 Cheshire & Krochmal [Page 15] 871 872Internet Draft Multicast DNS 10th August 2006 873 874 875 A Multicast DNS Responder seeing a Multicast DNS Query with the TC 876 bit set defers its response for a time period randomly selected in 877 the interval 400-500ms. This gives the Multicast DNS Querier time to 878 send additional Known Answer packets before the Responder responds. 879 If the Responder sees any of its answers listed in the Known Answer 880 lists of subsequent packets from the querying host, it SHOULD delete 881 that answer from the list of answers it is planning to give, provided 882 that no other host on the network is also waiting to receive the same 883 answer record. 884 885 If the Responder receives additional Known Answer packets with the TC 886 bit set, it SHOULD extend the delay as necessary to ensure a pause of 887 400-500ms after the last such packet before it sends its answer. This 888 opens the potential risk that a continuous stream of Known Answer 889 packets could, theoretically, prevent a Responder from answering 890 indefinitely. In practice answers are never actually delayed 891 significantly, and should a situation arise where significant delays 892 did happen, that would be a scenario where the network is so 893 overloaded that it would be desirable to err on the side of caution. 894 The consequence of delaying an answer may be that it takes a user 895 longer than usual to discover all the services on the local network; 896 in contrast the consequence of incorrectly answering before all the 897 Known Answer packets have been received would be wasting bandwidth 898 sending unnecessary answers on an already overloaded network. In this 899 (rare) situation, sacrificing speed to preserve reliable network 900 operation is the right trade-off. 901 902 9037.3 Duplicate Question Suppression 904 905 If a host is planning to send a query, and it sees another host on 906 the network send a query containing the same question, and the Known 907 Answer Section of that query does not contain any records which this 908 host would not also put in its own Known Answer Section, then this 909 host should treat its own query as having been sent. When multiple 910 clients on the network are querying for the same resource records, 911 there is no need for them to all be repeatedly asking the same 912 question. 913 914 9157.4 Duplicate Answer Suppression 916 917 If a host is planning to send an answer, and it sees another host on 918 the network send a response packet containing the same answer record, 919 and the TTL in that record is not less than the TTL this host would 920 have given, then this host should treat its own answer as having been 921 sent. When multiple responders on the network have the same data, 922 there is no need for all of them to respond. 923 924 This feature is particularly useful when multiple Sleep Proxy Servers 925 are deployed (see Section 17, "Multicast DNS and Power Management"). 926 927 928Expires 10th February 2007 Cheshire & Krochmal [Page 16] 929 930Internet Draft Multicast DNS 10th August 2006 931 932 933 In the future it is possible that every general-purpose OS (Mac, 934 Windows, Linux, etc.) will implement Sleep Proxy Service as a matter 935 of course. In this case there could be a large number of Sleep Proxy 936 Servers on any given network, which is good for reliability and 937 fault-tolerance, but would be bad for the network if every Sleep 938 Proxy Server were to answer every query. 939 9408. Responding 941 942 When a Multicast DNS Responder constructs and sends a Multicast DNS 943 response packet, the Answer Section of that packet must contain only 944 records for which that Responder is explicitly authoritative. These 945 answers may be generated because the record answers a question 946 received in a Multicast DNS query packet, or at certain other times 947 that the responder determines than an unsolicited announcement is 948 warranted. A Multicast DNS Responder MUST NOT place records from its 949 cache, which have been learned from other responders on the network, 950 in the Answer Section of outgoing response packets. Only an 951 authoritative source for a given record is allowed to issue responses 952 containing that record. 953 954 The determination of whether a given record answers a given question 955 is done using the standard DNS rules: The record name must match the 956 question name, the record rrtype must match the question qtype 957 (unless the qtype is "ANY"), and the record rrclass must match the 958 question qclass (unless the qclass is "ANY"). 959 960 A Multicast DNS Responder MUST only respond when it has a positive 961 non-null response to send. Error responses must never be sent. The 962 non-existence of any name in a Multicast DNS Domain is ascertained by 963 the failure of any machine to respond to the Multicast DNS query, not 964 by NXDOMAIN errors. 965 966 Multicast DNS Responses MUST NOT contain any questions in the 967 Question Section. Any questions in the Question Section of a received 968 Multicast DNS Response MUST be silently ignored. Multicast DNS 969 Queriers receiving Multicast DNS Responses do not care what question 970 elicited the response; they care only that the information in the 971 response is true and accurate. 972 973 A Multicast DNS Responder on Ethernet [IEEE802] and similar shared 974 multiple access networks SHOULD have the capability of delaying its 975 responses by up to 500ms, as determined by the rules described below. 976 If a large number of Multicast DNS Responders were all to respond 977 immediately to a particular query, a collision would be virtually 978 guaranteed. By imposing a small random delay, the number of 979 collisions is dramatically reduced. On a full-sized Ethernet using 980 the maximum cable lengths allowed and the maximum number of repeaters 981 allowed, an Ethernet frame is vulnerable to collisions during the 982 transmission of its first 256 bits. On 10Mb/s Ethernet, this equates 983 to a vulnerable time window of 25.6us. On higher-speed variants of 984 Ethernet, the vulnerable time window is shorter. 985 986Expires 10th February 2007 Cheshire & Krochmal [Page 17] 987 988Internet Draft Multicast DNS 10th August 2006 989 990 991 In the case where a Multicast DNS Responder has good reason to 992 believe that it will be the only responder on the link with a 993 positive non-null response (i.e. because it is able to answer every 994 question in the query packet, and for all of those answer records it 995 has previously verified that the name, rrtype and rrclass are unique 996 on the link) it SHOULD NOT impose any random delay before responding, 997 and SHOULD normally generate its response within at most 10ms. 998 In particular, this applies to responding to probe queries with the 999 "unicast response" bit set. Since receiving a probe query gives a 1000 clear indication that some other Responder is planning to start using 1001 this name in the very near future, answering such probe queries 1002 to defend a unique record is a high priority and needs to be done 1003 immediately, without delay. A probe query can be distinguished from 1004 a normal query by the fact that a probe query contains a proposed 1005 record in the Authority Section which answers the question in the 1006 Question Section (for more details, see Section 9.1, "Probing"). 1007 1008 Responding immediately without delay is appropriate for records like 1009 the address record for a particular host name, when the host name has 1010 been previously verified unique. Responding immediately without delay 1011 is *not* appropriate for things like looking up PTR records used for 1012 DNS Service Discovery [DNS-SD], where a large number of responses may 1013 be anticipated. 1014 1015 In any case where there may be multiple responses, such as queries 1016 where the answer is a member of a shared resource record set, each 1017 responder SHOULD delay its response by a random amount of time 1018 selected with uniform random distribution in the range 20-120ms. 1019 The reason for requiring that the delay be at least 20ms is to 1020 accommodate the situation where two or more query packets are sent 1021 back-to-back, because in that case we want a Responder with answers 1022 to more than one of those queries to have the opportunity to 1023 aggregate all of its answers into a single response packet. 1024 1025 In the case where the query has the TC (truncated) bit set, 1026 indicating that subsequent known answer packets will follow, 1027 responders SHOULD delay their responses by a random amount of time 1028 selected with uniform random distribution in the range 400-500ms, 1029 to allow enough time for all the known answer packets to arrive, 1030 as described in Section 7.2 "Multi-Packet Known Answer Suppression". 1031 1032 Except when a unicast response has been explicitly requested via the 1033 "unicast response" bit, Multicast DNS Responses MUST be sent to UDP 1034 port 5353 (the well-known port assigned to mDNS) on the 224.0.0.251 1035 multicast address (or its IPv6 equivalent FF02::FB). Operating in a 1036 Zeroconf environment requires constant vigilance. Just because a name 1037 has been previously verified unique does not mean it will continue 1038 to be so indefinitely. By allowing all Multicast DNS Responders to 1039 constantly monitor their peers' responses, conflicts arising out 1040 of network topology changes can be promptly detected and resolved. 1041 1042 1043 1044Expires 10th February 2007 Cheshire & Krochmal [Page 18] 1045 1046Internet Draft Multicast DNS 10th August 2006 1047 1048 1049 Sending all responses by multicast also facilitates opportunistic 1050 caching by other hosts on the network. 1051 1052 To protect the network against excessive packet flooding due to 1053 software bugs or malicious attack, a Multicast DNS Responder MUST NOT 1054 (except in the one special case of answering probe queries) multicast 1055 a record on a given interface until at least one second has elapsed 1056 since the last time that record was multicast on that particular 1057 interface. A legitimate client on the network should have seen the 1058 previous transmission and cached it. A client that did not receive 1059 and cache the previous transmission will retry its request and 1060 receive a subsequent response. In the special case of answering probe 1061 queries, because of the limited time before the probing host will 1062 make its decision about whether or not to use the name, a Multicast 1063 DNS Responder MUST respond quickly. In this special case only, when 1064 responding via multicast to a probe, a Multicast DNS Responder is 1065 only required to delay its transmission as necessary to ensure an 1066 interval of at least 250ms since the last time the record was 1067 multicast on that interface. 1068 1069 10708.2 Multi-Question Queries 1071 1072 Multicast DNS Responders MUST correctly handle DNS query packets 1073 containing more than one question, by answering any or all of the 1074 questions to which they have answers. Any (non-defensive) answers 1075 generated in response to query packets containing more than one 1076 question SHOULD be randomly delayed in the range 20-120ms, or 1077 400-500ms if the TC (truncated) bit is set, as described above. 1078 (Answers defending a name, in response to a probe for that name, 1079 are not subject to this delay rule and are still sent immediately.) 1080 1081 10828.2 Response Aggregation 1083 1084 When possible, a responder SHOULD, for the sake of network 1085 efficiency, aggregate as many responses as possible into a single 1086 Multicast DNS response packet. For example, when a responder has 1087 several responses it plans to send, each delayed by a different 1088 interval, then earlier responses SHOULD be delayed by up to an 1089 additional 500ms if that will permit them to be aggregated with 1090 other responses scheduled to go out a little later. 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102Expires 10th February 2007 Cheshire & Krochmal [Page 19] 1103 1104Internet Draft Multicast DNS 10th August 2006 1105 1106 11078.3 Legacy Unicast Responses 1108 1109 If the source UDP port in a received Multicast DNS Query is not port 1110 5353, this indicates that the client originating the query is a 1111 simple client that does not fully implement all of Multicast DNS. 1112 In this case, the Multicast DNS Responder MUST send a UDP response 1113 directly back to the client, via unicast, to the query packet's 1114 source IP address and port. This unicast response MUST be a 1115 conventional unicast response as would be generated by a conventional 1116 unicast DNS server; for example, it MUST repeat the query ID and the 1117 question given in the query packet. 1118 1119 The resource record TTL given in a legacy unicast response SHOULD NOT 1120 be greater than ten seconds, even if the true TTL of the Multicast 1121 DNS resource record is higher. This is because Multicast DNS 1122 Responders that fully participate in the protocol use the cache 1123 coherency mechanisms described in Section 11 "Resource Record TTL 1124 Values and Cache Coherency" to update and invalidate stale data. Were 1125 unicast responses sent to legacy clients to use the same high TTLs, 1126 these legacy clients, which do not implement these cache coherency 1127 mechanisms, could retain stale cached resource record data long after 1128 it is no longer valid. 1129 1130 Having sent this unicast response, if the Responder has not sent this 1131 record in any multicast response recently, it SHOULD schedule the 1132 record to be sent via multicast as well, to facilitate passive 1133 conflict detection. "Recently" in this context means "if the time 1134 since the record was last sent via multicast is less than one quarter 1135 of the record's TTL". 1136 1137 Note that while legacy queries usually contain exactly one question, 1138 they are permitted to contain multiple questions, and responders 1139 listening for multicast queries on 224.0.0.251:5353 MUST be prepared 1140 to handle this correctly, responding by generating a unicast response 1141 containing the list of question(s) they are answering in the Question 1142 Section, and the records answering those question(s) in the Answer 1143 Section. 1144 1145 11469. Probing and Announcing on Startup 1147 1148 Typically a Multicast DNS Responder should have, at the very least, 1149 address records for all of its active interfaces. Creating and 1150 advertising an HINFO record on each interface as well can be useful 1151 to network administrators. 1152 1153 Whenever a Multicast DNS Responder starts up, wakes up from sleep, 1154 receives an indication of an Ethernet "Link Change" event, or has any 1155 other reason to believe that its network connectivity may have 1156 changed in some relevant way, it MUST perform the two startup steps 1157 below. 1158 1159 1160Expires 10th February 2007 Cheshire & Krochmal [Page 20] 1161 1162Internet Draft Multicast DNS 10th August 2006 1163 1164 11659.1 Probing 1166 1167 The first startup step is that for all those resource records that a 1168 Multicast DNS Responder desires to be unique on the local link, it 1169 MUST send a Multicast DNS Query asking for those resource records, to 1170 see if any of them are already in use. The primary example of this is 1171 its address record which maps its unique host name to its unique IP 1172 address. All Probe Queries SHOULD be done using the desired resource 1173 record name and query type T_ANY (255), to elicit answers for all 1174 types of records with that name. This allows a single question to be 1175 used in place of several questions, which is more efficient on the 1176 network. It also allows a host to verify exclusive ownership of a 1177 name, which is desirable in most cases. It would be confusing, for 1178 example, if one host owned the "A" record for "myhost.local.", but 1179 a different host owned the HINFO record for that name. 1180 1181 The ability to place more than one question in a Multicast DNS Query 1182 is useful here, because it can allow a host to use a single packet 1183 for all of its resource records instead of needing a separate packet 1184 for each. For example, a host can simultaneously probe for uniqueness 1185 of its "A" record and all its SRV records [DNS-SD] in the same query 1186 packet. 1187 1188 When ready to send its mDNS probe packet(s) the host should first 1189 wait for a short random delay time, uniformly distributed in the 1190 range 0-250ms. This random delay is to guard against the case where a 1191 group of devices are powered on simultaneously, or a group of devices 1192 are connected to an Ethernet hub which is then powered on, or some 1193 other external event happens that might cause a group of hosts to all 1194 send synchronized probes. 1195 1196 250ms after the first query the host should send a second, then 1197 250ms after that a third. If, by 250ms after the third probe, no 1198 conflicting Multicast DNS responses have been received, the host may 1199 move to the next step, announcing. (Note that this is the one 1200 exception from the normal rule that there should be at least one 1201 second between repetitions of the same question, and the interval 1202 between subsequent repetitions should double.) 1203 1204 When sending probe queries, a host MUST NOT consult its cache for 1205 potential answers. Only conflicting Multicast DNS responses received 1206 "live" from the network are considered valid for the purposes of 1207 determining whether probing has succeeded or failed. 1208 1209 In order to allow services to announce their presence without 1210 unreasonable delay, the time window for probing is intentionally set 1211 quite short. As a result of this, from the time the first probe 1212 packet is sent, another device on the network using that name has 1213 just 750ms to respond to defend its name. On networks that are slow, 1214 or busy, or both, it is possible for round-trip latency to account 1215 for a few hundred milliseconds, and software delays in slow devices 1216 1217 1218Expires 10th February 2007 Cheshire & Krochmal [Page 21] 1219 1220Internet Draft Multicast DNS 10th August 2006 1221 1222 1223 can add additional delay. For this reason, it is important that when 1224 a device receives a probe query for a name that it is currently using 1225 for unique records, it SHOULD generate its response to defend that 1226 name immediately and send it as quickly as possible. The usual rules 1227 about random delays before responding, to avoid sudden bursts of 1228 simultaneous answers from different hosts, do not apply here since 1229 at most one host should ever respond to a given probe question. Even 1230 when a single DNS query packet contains multiple probe questions, 1231 it would be unusual for that packet to elicit a defensive response 1232 from more than one other host. Because of the mDNS multicast rate 1233 limiting rules, the first two probes SHOULD be sent as "QU" questions 1234 with the "unicast response" bit set, to allow a defending host to 1235 respond immediately via unicast, instead of potentially having to 1236 wait before replying via multicast. At the present time, this 1237 document recommends that the third probe SHOULD be sent as a standard 1238 "QM" question, for backwards compatibility with the small number of 1239 old devices still in use that don't implement unicast responses. 1240 1241 If, at any time during probing, from the beginning of the initial 1242 random 0-250ms delay onward, any conflicting Multicast DNS responses 1243 are received, then the probing host MUST defer to the existing host, 1244 and MUST choose new names for some or all of its resource records 1245 as appropriate, to avoid conflict with pre-existing hosts on the 1246 network. In the case of a host probing using query type T_ANY as 1247 recommended above, any answer containing a record with that name, 1248 of any type, MUST be considered a conflicting response and handled 1249 accordingly. 1250 1251 If fifteen failures occur within any ten-second period, then the host 1252 MUST wait at least five seconds before each successive additional 1253 probe attempt. This is to help ensure that in the event of software 1254 bugs or other unanticipated problems, errant hosts do not flood the 1255 network with a continuous stream of multicast traffic. For very 1256 simple devices, a valid way to comply with this requirement is 1257 to always wait five seconds after any failed probe attempt before 1258 trying again. 1259 1260 If a responder knows by other means, with absolute certainty, that 1261 its unique resource record set name, rrtype and rrclass cannot 1262 already be in use by any other responder on the network, then it 1263 MAY skip the probing step for that resource record set. For example, 1264 when creating the reverse address mapping PTR records, the host can 1265 reasonably assume that no other host will be trying to create those 1266 same PTR records, since that would imply that the two hosts were 1267 trying to use the same IP address, and if that were the case, the 1268 two hosts would be suffering communication problems beyond the scope 1269 of what Multicast DNS is designed to solve. 1270 1271 1272 1273 1274 1275 1276Expires 10th February 2007 Cheshire & Krochmal [Page 22] 1277 1278Internet Draft Multicast DNS 10th August 2006 1279 1280 12819.2 Simultaneous Probe Tie-Breaking 1282 1283 The astute reader will observe that there is a race condition 1284 inherent in the previous description. If two hosts are probing for 1285 the same name simultaneously, neither will receive any response to 1286 the probe, and the hosts could incorrectly conclude that they may 1287 both proceed to use the name. To break this symmetry, each host 1288 populates the Query packets's Authority Section with the record or 1289 records with the rdata that it would be proposing to use, should its 1290 probing be successful. The Authority Section is being used here in a 1291 way analogous to the way it is used as the "Update Section" in a DNS 1292 Update packet [RFC 2136]. 1293 1294 When a host is probing for a group of related records with the same 1295 name (e.g. the SRV and TXT record describing a DNS-SD service), only 1296 a single question need be placed in the Question Section, since query 1297 type T_ANY (255) is used, which will elicit answers for all records 1298 with that name. However, for tie-breaking to work correctly in all 1299 cases, the Authority Section must contain *all* the records and 1300 proposed rdata being probed for uniqueness. 1301 1302 When a host that is probing for a record sees another host issue a 1303 query for the same record, it consults the Authority Section of that 1304 query. If it finds any resource record(s) there which answers the 1305 query, then it compares the data of that (those) resource record(s) 1306 with its own tentative data. We consider first the simple case of a 1307 host probing for a single record, receiving a simultaneous probe from 1308 another host also probing for a single record. The two records are 1309 compared and the lexicographically later data wins. This means that 1310 if the host finds that its own data is lexicographically later, it 1311 simply ignores the other host's probe. If the host finds that its own 1312 data is lexicographically earlier, then it treats this exactly as if 1313 it had received a positive answer to its query, and concludes that it 1314 may not use the desired name. 1315 1316 The determination of "lexicographically later" is performed by first 1317 comparing the record class, then the record type, then raw comparison 1318 of the binary content of the rdata without regard for meaning or 1319 structure. If the record classes differ, then the numerically greater 1320 class is considered "lexicographically later". Otherwise, if the 1321 record types differ, then the numerically greater type is considered 1322 "lexicographically later". If the rrtype and rrclass both match then 1323 the rdata is compared. 1324 1325 In the case of resource records containing rdata that is subject to 1326 name compression, the names MUST be uncompressed before comparison. 1327 (The details of how a particular name is compressed is an artifact of 1328 how and where the record is written into the DNS message; it is not 1329 an intrinsic property of the resource record itself.) 1330 1331 1332 1333 1334Expires 10th February 2007 Cheshire & Krochmal [Page 23] 1335 1336Internet Draft Multicast DNS 10th August 2006 1337 1338 1339 The bytes of the raw uncompressed rdata are compared in turn, 1340 interpreting the bytes as eight-bit UNSIGNED values, until a byte 1341 is found whose value is greater than that of its counterpart (in 1342 which case the rdata whose byte has the greater value is deemed 1343 lexicographically later) or one of the resource records runs out 1344 of rdata (in which case the resource record which still has 1345 remaining data first is deemed lexicographically later). 1346 1347 The following is an example of a conflict: 1348 1349 cheshire.local. A 169.254.99.200 1350 cheshire.local. A 169.254.200.50 1351 1352 In this case 169.254.200.50 is lexicographically later (the third 1353 byte, with value 200, is greater than its counterpart with value 99), 1354 so it is deemed the winner. 1355 1356 Note that it is vital that the bytes are interpreted as UNSIGNED 1357 values in the range 0-255, or the wrong outcome may result. In 1358 the example above, if the byte with value 200 had been incorrectly 1359 interpreted as a signed eight-bit value then it would be interpreted 1360 as value -56, and the wrong address record would be deemed the 1361 winner. 1362 1363 13649.2.1 Simultaneous Probe Tie-Breaking for Multiple Records 1365 1366 When a host is probing for a set of records with the same name, or a 1367 packet is received containing multiple tie-breaker records answering 1368 a given probe question in the Question Section, the host's records 1369 and the tie-breaker records from the packet are each sorted into 1370 order, and then compared pairwise, using the same comparison 1371 technique described above, until a difference is found. 1372 1373 The records are sorted using the same lexicographical order as 1374 described above, that is: if the record classes differ, the record 1375 with the lower class number comes first. If the classes are the same 1376 but the rrtypes differ, the record with the lower rrtype number comes 1377 first. If the class and rrtype match, then the rdata is compared 1378 bytewise until a difference is found. For example, in the common case 1379 of advertising DNS-SD services with a TXT record and an SRV record, 1380 the TXT record comes first (the rrtype for TXT is 16) and the SRV 1381 record comes second (the rrtype for SRV is 33). 1382 1383 When comparing the records, if the first records match perfectly, 1384 then the second records are compared, and so on. If either list of 1385 records runs out of records before any difference is found, then the 1386 list with records remaining is deemed to have won the tie-break. If 1387 both lists run out of records at the same time without any difference 1388 being found, then this indicates that two devices are advertising 1389 identical sets of records, as is sometimes done for fault tolerance, 1390 and there is in fact no conflict. 1391 1392Expires 10th February 2007 Cheshire & Krochmal [Page 24] 1393 1394Internet Draft Multicast DNS 10th August 2006 1395 1396 13979.3 Announcing 1398 1399 The second startup step is that the Multicast DNS Responder MUST send 1400 a gratuitous Multicast DNS Response containing, in the Answer 1401 Section, all of its resource records (both shared records, and unique 1402 records that have completed the probing step). If there are too many 1403 resource records to fit in a single packet, multiple packets should 1404 be used. 1405 1406 In the case of shared records (e.g. the PTR records used by DNS 1407 Service Discovery [DNS-SD]), the records are simply placed as-is 1408 into the Answer Section of the DNS Response. 1409 1410 In the case of records that have been verified to be unique in the 1411 previous step, they are placed into the Answer Section of the DNS 1412 Response with the most significant bit of the rrclass set to one. 1413 The most significant bit of the rrclass for a record in the Answer 1414 Section of a response packet is the mDNS "cache flush" bit and is 1415 discussed in more detail below in Section 11.3 "Announcements to 1416 Flush Outdated Cache Entries". 1417 1418 The Multicast DNS Responder MUST send at least two gratuitous 1419 responses, one second apart. A Responder MAY send up to eight 1420 gratuitous Responses, provided that the interval between gratuitous 1421 responses doubles with every response sent. 1422 1423 A Multicast DNS Responder MUST NOT send announcements in the absence 1424 of information that its network connectivity may have changed in 1425 some relevant way. In particular, a Multicast DNS Responder MUST NOT 1426 send regular periodic announcements as a matter of course. It is not 1427 uncommon for protocol designers to encounter some problem which they 1428 decide to solve using regular periodic announcements, but this is 1429 generally not a wise protocol design choice. In the small scale 1430 periodic announcements may seem to remedy the short-term problem, 1431 but they do not scale well if the protocol becomes successful. 1432 If every host on the network implements the protocol -- if multiple 1433 applications on every host on the network are implementing the 1434 protocol -- then even a low periodic rate of just one announcement 1435 per minute per application per host can add up to multiple packets 1436 per second in total. While gigabit Ethernet may be able to carry 1437 a million packets per second, other network technologies cannot. 1438 For example, while IEEE 802.11g wireless has a nominal data rate of 1439 up to 54Mb/sec, multicasting just 100 packets per second can consume 1440 the entire available bandwidth, leaving nothing for anything else. 1441 1442 With the increasing popularity of hand-held devices, unnecessary 1443 continuous packet transmission can have bad implications for battery 1444 life. It's worth pointing out the precedent that TCP was also 1445 designed with this "no regular periodic idle packets" philosophy. 1446 Standard TCP sends packets only when it has data to send or 1447 acknowledge. If neither client nor server sends any bytes, then the 1448 1449 1450Expires 10th February 2007 Cheshire & Krochmal [Page 25] 1451 1452Internet Draft Multicast DNS 10th August 2006 1453 1454 1455 TCP code will send no packets, and a TCP connection can remain active 1456 in this state indefinitely, with no packets being exchanged for 1457 hours, days, weeks or months. 1458 1459 Whenever a Multicast DNS Responder receives any Multicast DNS 1460 response (gratuitous or otherwise) containing a conflicting resource 1461 record, the conflict MUST be resolved as described below in "Conflict 1462 Resolution". 1463 1464 14659.4 Updating 1466 1467 At any time, if the rdata of any of a host's Multicast DNS records 1468 changes, the host MUST repeat the Announcing step described above to 1469 update neighboring caches. For example, if any of a host's IP 1470 addresses change, it MUST re-announce those address records. 1471 1472 In the case of shared records, a host MUST send a "goodbye" 1473 announcement with TTL zero (see Section 11.2 "Goodbye Packets") 1474 for the old rdata, to cause it to be deleted from peer caches, 1475 before announcing the new rdata. In the case of unique records, 1476 a host SHOULD omit the "goodbye" announcement, since the cache 1477 flush bit on the newly announced records will cause old rdata 1478 to be flushed from peer caches anyway. 1479 1480 A host may update the contents of any of its records at any time, 1481 though a host SHOULD NOT update records more frequently than ten 1482 times per minute. Frequent rapid updates impose a burden on the 1483 network. If a host has information to disseminate which changes more 1484 frequently than ten times per minute, then it may be more appropriate 1485 to design a protocol for that specific purpose. 1486 1487 148810. Conflict Resolution 1489 1490 A conflict occurs when a Multicast DNS Responder has a unique record 1491 for which it is authoritative, and it receives a Multicast DNS 1492 response packet containing a record with the same name, rrtype and 1493 rrclass, but inconsistent rdata. What may be considered inconsistent 1494 is context sensitive, except that resource records with identical 1495 rdata are never considered inconsistent, even if they originate from 1496 different hosts. This is to permit use of proxies and other 1497 fault-tolerance mechanisms that may cause more than one responder 1498 to be capable of issuing identical answers on the network. 1499 1500 A common example of a resource record type that is intended to be 1501 unique, not shared between hosts, is the address record that maps a 1502 host's name to its IP address. Should a host witness another host 1503 announce an address record with the same name but a different IP 1504 address, then that is considered inconsistent, and that address 1505 record is considered to be in conflict. 1506 1507 1508Expires 10th February 2007 Cheshire & Krochmal [Page 26] 1509 1510Internet Draft Multicast DNS 10th August 2006 1511 1512 1513 Whenever a Multicast DNS Responder receives any Multicast DNS 1514 response (gratuitous or otherwise) containing a conflicting resource 1515 record in the Answer Section, the Multicast DNS Responder MUST 1516 immediately reset its conflicted unique record to probing state, and 1517 go through the startup steps described above in Section 9. "Probing 1518 and Announcing on Startup". The protocol used in the Probing phase 1519 will determine a winner and a loser, and the loser MUST cease using 1520 the name, and reconfigure. 1521 1522 It is very important that any host receiving a resource record that 1523 conflicts with one of its own MUST take action as described above. 1524 In the case of two hosts using the same host name, where one has been 1525 configured to require a unique host name and the other has not, the 1526 one that has not been configured to require a unique host name will 1527 not perceive any conflict, and will not take any action. By reverting 1528 to Probing state, the host that desires a unique host name will go 1529 through the necessary steps to ensure that a unique host is obtained. 1530 1531 The recommended course of action after probing and failing is as 1532 follows: 1533 1534 o Programmatically change the resource record name in an attempt to 1535 find a new name that is unique. This could be done by adding some 1536 further identifying information (e.g. the model name of the 1537 hardware) if it is not already present in the name, appending the 1538 digit "2" to the name, or incrementing a number at the end of the 1539 name if one is already present. 1540 1541 o Probe again, and repeat until a unique name is found. 1542 1543 o Record this newly chosen name in persistent storage so that the 1544 device will use the same name the next time it is power-cycled. 1545 1546 o Display a message to the user or operator informing them of the 1547 name change. For example: 1548 1549 The name "Bob's Music" is in use by another iTunes music 1550 server on the network. Your music has been renamed to 1551 "Bob's Music (G4 Cube)". If you want to change this name, 1552 use [describe appropriate menu item or preference dialog]. 1553 1554 o If after one minute of probing the Multicast DNS Responder has been 1555 unable to find any unused name, it should display a message to the 1556 user or operator informing them of this fact. This situation should 1557 never occur in normal operation. The only situations that would 1558 cause this to happen would be either a deliberate denial-of-service 1559 attack, or some kind of very obscure hardware or software bug that 1560 acts like a deliberate denial-of-service attack. 1561 1562 How the user or operator is informed depends on context. A desktop 1563 computer with a screen might put up a dialog box. A headless server 1564 1565 1566Expires 10th February 2007 Cheshire & Krochmal [Page 27] 1567 1568Internet Draft Multicast DNS 10th August 2006 1569 1570 1571 in the closet may write a message to a log file, or use whatever 1572 mechanism (email, SNMP trap, etc.) it uses to inform the 1573 administrator of other error conditions. On the other hand a headless 1574 server in the closet may not inform the user at all -- if the user 1575 cares, they will notice the name has changed, and connect to the 1576 server in the usual way (e.g. via Web Browser) to configure a new 1577 name. 1578 1579 The examples in this section focus on address records (i.e. host 1580 names), but the same considerations apply to all resource records 1581 where uniqueness (or maintenance of some other defined constraint) 1582 is desired. 1583 1584 158511. Resource Record TTL Values and Cache Coherency 1586 1587 As a general rule, the recommended TTL value for Multicast DNS 1588 resource records with a host name as the resource record's name 1589 (e.g. A, AAAA, HINFO, etc.) or contained within the resource record's 1590 rdata (e.g. SRV, reverse mapping PTR record, etc.) is 120 seconds. 1591 1592 The recommended TTL value for other Multicast DNS resource records 1593 is 75 minutes. 1594 1595 A client with an active outstanding query will issue a query packet 1596 when one or more of the resource record(s) in its cache is (are) 80% 1597 of the way to expiry. If the TTL on those records is 75 minutes, 1598 this ongoing cache maintenance process yields a steady-state query 1599 rate of one query every 60 minutes. 1600 1601 Any distributed cache needs a cache coherency protocol. If Multicast 1602 DNS resource records follow the recommendation and have a TTL of 75 1603 minutes, that means that stale data could persist in the system for 1604 a little over an hour. Making the default TTL significantly lower 1605 would reduce the lifetime of stale data, but would produce too much 1606 extra traffic on the network. Various techniques are available to 1607 minimize the impact of such stale data. 1608 1609 161011.1 Cooperating Multicast DNS Responders 1611 1612 If a Multicast DNS Responder ("A") observes some other Multicast DNS 1613 Responder ("B") send a Multicast DNS Response packet containing a 1614 resource record with the same name, rrtype and rrclass as one of A's 1615 resource records, but different rdata, then: 1616 1617 o If A's resource record is intended to be a shared resource record, 1618 then this is no conflict, and no action is required. 1619 1620 o If A's resource record is intended to be a member of a unique 1621 resource record set owned solely by that responder, then this 1622 1623 1624Expires 10th February 2007 Cheshire & Krochmal [Page 28] 1625 1626Internet Draft Multicast DNS 10th August 2006 1627 1628 1629 is a conflict and MUST be handled as described in Section 10 1630 "Conflict Resolution". 1631 1632 If a Multicast DNS Responder ("A") observes some other Multicast DNS 1633 Responder ("B") send a Multicast DNS Response packet containing a 1634 resource record with the same name, rrtype and rrclass as one of A's 1635 resource records, and identical rdata, then: 1636 1637 o If the TTL of B's resource record given in the packet is at least 1638 half the true TTL from A's point of view, then no action is 1639 required. 1640 1641 o If the TTL of B's resource record given in the packet is less than 1642 half the true TTL from A's point of view, then A MUST mark its 1643 record to be announced via multicast. Clients receiving the record 1644 from B would use the TTL given by B, and hence may delete the 1645 record sooner than A expects. By sending its own multicast response 1646 correcting the TTL, A ensures that the record will be retained for 1647 the desired time. 1648 1649 These rules allow multiple Multicast DNS Responders to offer the same 1650 data on the network (perhaps for fault tolerance reasons) without 1651 conflicting with each other. 1652 1653 165411.2 Goodbye Packets 1655 1656 In the case where a host knows that certain resource record data is 1657 about to become invalid (for example when the host is undergoing a 1658 clean shutdown) the host SHOULD send a gratuitous announcement mDNS 1659 response packet, giving the same resource record name, rrtype, 1660 rrclass and rdata, but an RR TTL of zero. This has the effect of 1661 updating the TTL stored in neighboring hosts' cache entries to zero, 1662 causing that cache entry to be promptly deleted. 1663 1664 Clients receiving a Multicast DNS Response with a TTL of zero SHOULD 1665 NOT immediately delete the record from the cache, but instead record 1666 a TTL of 1 and then delete the record one second later. In the case 1667 of multiple Multicast DNS Responders on the network described in 1668 Section 11.1 above, if one of the Responders shuts down and 1669 incorrectly sends goodbye packets for its records, it gives the other 1670 cooperating Responders one second to send out their own response to 1671 "rescue" the records before they expire and are deleted. 1672 1673 167411.3 Announcements to Flush Outdated Cache Entries 1675 1676 Whenever a host has a resource record with potentially new data (e.g. 1677 after rebooting, waking from sleep, connecting to a new network link, 1678 changing IP address, etc.), the host MUST send a series of gratuitous 1679 announcements to update cache entries in its neighbor hosts. In 1680 1681 1682Expires 10th February 2007 Cheshire & Krochmal [Page 29] 1683 1684Internet Draft Multicast DNS 10th August 2006 1685 1686 1687 these gratuitous announcements, if the record is one that is intended 1688 to be unique, the host sets the most significant bit of the rrclass 1689 field of the resource record. This bit, the "cache flush" bit, tells 1690 neighboring hosts that this is not a shared record type. Instead of 1691 merging this new record additively into the cache in addition to any 1692 previous records with the same name, rrtype and rrclass, all old 1693 records with that name, type and class that were received more than 1694 one second ago are declared invalid, and marked to expire from the 1695 cache in one second. 1696 1697 The semantics of the cache flush bit are as follows: Normally when a 1698 resource record appears in the Answer Section of the DNS Response, it 1699 means, "This is an assertion that this information is true." When a 1700 resource record appears in the Answer Section of the DNS Response 1701 with the "cache flush" bit set, it means, "This is an assertion that 1702 this information is the truth and the whole truth, and anything you 1703 may have heard more than a second ago regarding records of this 1704 name/rrtype/rrclass is no longer valid". 1705 1706 To accommodate the case where the set of records from one host 1707 constituting a single unique RRSet is too large to fit in a single 1708 packet, only cache records that are more than one second old are 1709 flushed. This allows the announcing host to generate a quick burst of 1710 packets back-to-back on the wire containing all the members 1711 of the RRSet. When receiving records with the "cache flush" bit set, 1712 all records older than one second are marked to be deleted one second 1713 in the future. One second after the end of the little packet burst, 1714 any records not represented within that packet burst will then be 1715 expired from all peer caches. 1716 1717 Any time a host sends a response packet containing some members of a 1718 unique RRSet, it SHOULD send the entire RRSet, preferably in a single 1719 packet, or if the entire RRSet will not fit in a single packet, in a 1720 quick burst of packets sent as close together as possible. The host 1721 SHOULD set the cache flush bit on all members of the unique RRSet. 1722 In the event that for some reason the host chooses not to send the 1723 entire unique RRSet in a single packet or a rapid packet burst, 1724 it MUST NOT set the cache flush bit on any of those records. 1725 1726 The reason for waiting one second before deleting stale records from 1727 the cache is to accommodate bridged networks. For example, a host's 1728 address record announcement on a wireless interface may be bridged 1729 onto a wired Ethernet, and cause that same host's Ethernet address 1730 records to be flushed from peer caches. The one-second delay gives 1731 the host the chance to see its own announcement arrive on the wired 1732 Ethernet, and immediately re-announce its Ethernet interface's 1733 address records so that both sets remain valid and live in peer 1734 caches. 1735 1736 These rules apply regardless of *why* the response packet is being 1737 generated. They apply to startup announcements as described in 1738 1739 1740Expires 10th February 2007 Cheshire & Krochmal [Page 30] 1741 1742Internet Draft Multicast DNS 10th August 2006 1743 1744 1745 Section 9.3 "Announcing", and to responses generated as a result 1746 of receiving query packets. 1747 1748 The "cache flush" bit is only set in records in the Answer Section of 1749 Multicast DNS responses sent to UDP port 5353. The "cache flush" bit 1750 MUST NOT be set in any resource records in a response packet sent in 1751 legacy unicast responses to UDP ports other than 5353. 1752 1753 The "cache flush" bit MUST NOT be set in any resource records in the 1754 known-answer list of any query packet. 1755 1756 The "cache flush" bit MUST NOT ever be set in any shared resource 1757 record. To do so would cause all the other shared versions of this 1758 resource record with different rdata from different Responders to be 1759 immediately deleted from all the caches on the network. 1760 1761 The "cache flush" bit does apply to questions listed in the Question 1762 Section of a Multicast DNS packet. The top bit of the rrclass field 1763 in questions is used for an entirely different purpose (see Section 1764 6.5, "Questions Requesting Unicast Responses"). 1765 1766 Note that the "cache flush" bit is NOT part of the resource record 1767 class. The "cache flush" bit is the most significant bit of the 1768 second 16-bit word of a resource record in the Answer Section of 1769 an mDNS packet (the field conventionally referred to as the rrclass 1770 field), and the actual resource record class is the least-significant 1771 fifteen bits of this field. There is no mDNS resource record class 1772 0x8001. The value 0x8001 in the rrclass field of a resource record in 1773 an mDNS response packet indicates a resource record with class 1, 1774 with the "cache flush" bit set. When receiving a resource record with 1775 the "cache flush" bit set, implementations should take care to mask 1776 off that bit before storing the resource record in memory. 1777 1778 177911.4 Cache Flush on Topology change 1780 1781 If the hardware on a given host is able to indicate physical changes 1782 of connectivity, then when the hardware indicates such a change, the 1783 host should take this information into account in its mDNS cache 1784 management strategy. For example, a host may choose to immediately 1785 flush all cache records received on a particular interface when that 1786 cable is disconnected. Alternatively, a host may choose to adjust the 1787 remaining TTL on all those records to a few seconds so that if the 1788 cable is not reconnected quickly, those records will expire from the 1789 cache. 1790 1791 Likewise, when a host reboots, or wakes from sleep, or undergoes some 1792 other similar discontinuous state change, the cache management 1793 strategy should take that information into account. 1794 1795 1796 1797 1798Expires 10th February 2007 Cheshire & Krochmal [Page 31] 1799 1800Internet Draft Multicast DNS 10th August 2006 1801 1802 180311.5 Cache Flush on Failure Indication 1804 1805 Sometimes a cache record can be determined to be stale when a client 1806 attempts to use the rdata it contains, and finds that rdata to be 1807 incorrect. 1808 1809 For example, the rdata in an address record can be determined to be 1810 incorrect if attempts to contact that host fail, either because 1811 ARP/ND requests for that address go unanswered (for an address on a 1812 local subnet) or because a router returns an ICMP "Host Unreachable" 1813 error (for an address on a remote subnet). 1814 1815 The rdata in an SRV record can be determined to be incorrect if 1816 attempts to communicate with the indicated service at the host and 1817 port number indicated are not successful. 1818 1819 The rdata in a DNS-SD PTR record can be determined to be incorrect if 1820 attempts to look up the SRV record it references are not successful. 1821 1822 In any such case, the software implementing the mDNS resource record 1823 cache should provide a mechanism so that clients detecting stale 1824 rdata can inform the cache. 1825 1826 When the cache receives this hint that it should reconfirm some 1827 record, it MUST issue two or more queries for the resource record in 1828 question. If no response is received in a reasonable amount of time, 1829 then, even though its TTL may indicate that it is not yet due to 1830 expire, that record SHOULD be promptly flushed from the cache. 1831 1832 The end result of this is that if a printer suffers a sudden power 1833 failure or other abrupt disconnection from the network, its name 1834 may continue to appear in DNS-SD browser lists displayed on users' 1835 screens. Eventually that entry will expire from the cache naturally, 1836 but if a user tries to access the printer before that happens, the 1837 failure to successfully contact the printer will trigger the more 1838 hasty demise of its cache entries. This is a sensible trade-off 1839 between good user-experience and good network efficiency. If we were 1840 to insist that printers should disappear from the printer list within 1841 30 seconds of becoming unavailable, for all failure modes, the only 1842 way to achieve this would be for the client to poll the printer at 1843 least every 30 seconds, or for the printer to announce its presence 1844 at least every 30 seconds, both of which would be an unreasonable 1845 burden on most networks. 1846 1847 184811.6 Passive Observation of Failures 1849 1850 A host observes the multicast queries issued by the other hosts on 1851 the network. One of the major benefits of also sending responses 1852 using multicast is that it allows all hosts to see the responses (or 1853 lack thereof) to those queries. 1854 1855 1856Expires 10th February 2007 Cheshire & Krochmal [Page 32] 1857 1858Internet Draft Multicast DNS 10th August 2006 1859 1860 1861 If a host sees queries, for which a record in its cache would be 1862 expected to be given as an answer in a multicast response, but no 1863 such answer is seen, then the host may take this as an indication 1864 that the record may no longer be valid. 1865 1866 After seeing two or more of these queries, and seeing no multicast 1867 response containing the expected answer within a reasonable amount of 1868 time, then even though its TTL may indicate that it is not yet due to 1869 expire, that record MAY be flushed from the cache. The host SHOULD 1870 NOT perform its own queries to re-confirm that the record is truly 1871 gone. If every host on a large network were to do this, it would 1872 cause a lot of unnecessary multicast traffic. If host A sends 1873 multicast queries that remain unanswered, then there is no reason 1874 to suppose that host B or any other host is likely to be any more 1875 successful. 1876 1877 The previous section, "Cache Flush on Failure Indication", describes 1878 a situation where a user trying to print discovers that the printer 1879 is no longer available. By implementing the passive observation 1880 described here, when one user fails to contact the printer, all 1881 hosts on the network observe that failure and update their caches 1882 accordingly. 1883 1884 188512. Special Characteristics of Multicast DNS Domains 1886 1887 Unlike conventional DNS names, names that end in ".local." or 1888 "254.169.in-addr.arpa." have only local significance. The same is 1889 true of names within the IPv6 Link-Local reverse mapping domains. 1890 1891 Conventional Unicast DNS seeks to provide a single unified namespace, 1892 where a given DNS query yields the same answer no matter where on the 1893 planet it is performed or to which recursive DNS server the query is 1894 sent. In contrast, each IP link has its own private ".local.", 1895 "254.169.in-addr.arpa." and IPv6 Link-Local reverse mapping 1896 namespaces, and the answer to any query for a name within those 1897 domains depends on where that query is asked. (This characteristic is 1898 not unique to Multicast DNS. Although the original concept of DNS was 1899 a single global namespace, in recent years split views, firewalls, 1900 intranets, and the like have increasingly meant that the answer to a 1901 given DNS query has become dependent on the location of the querier.) 1902 1903 Multicast DNS Domains are not delegated from their parent domain via 1904 use of NS records. There are no NS records anywhere in Multicast DNS 1905 Domains. Instead, all Multicast DNS Domains are delegated to the IP 1906 addresses 224.0.0.251 and FF02::FB by virtue of the individual 1907 organizations producing DNS client software deciding how to handle 1908 those names. It would be extremely valuable for the industry if this 1909 special handling were ratified and recorded by IANA, since otherwise 1910 the special handling provided by each vendor is likely to be 1911 inconsistent. 1912 1913 1914Expires 10th February 2007 Cheshire & Krochmal [Page 33] 1915 1916Internet Draft Multicast DNS 10th August 2006 1917 1918 1919 The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The 1920 IPv6 name server for a Multicast DNS Domain is FF02::FB. These are 1921 multicast addresses; therefore they identify not a single host but a 1922 collection of hosts, working in cooperation to maintain some 1923 reasonable facsimile of a competently managed DNS zone. Conceptually 1924 a Multicast DNS Domain is a single DNS zone, however its server is 1925 implemented as a distributed process running on a cluster of loosely 1926 cooperating CPUs rather than as a single process running on a single 1927 CPU. 1928 1929 No delegation is performed within Multicast DNS Domains. Because the 1930 cluster of loosely coordinated CPUs is cooperating to administer a 1931 single zone, delegation is neither necessary nor desirable. Just 1932 because a particular host on the network may answer queries for a 1933 particular record type with the name "example.local." does not imply 1934 anything about whether that host will answer for the name 1935 "child.example.local.", or indeed for other record types with the 1936 name "example.local." 1937 1938 Multicast DNS Zones have no SOA record. A conventional DNS zone's 1939 SOA record contains information such as the email address of the zone 1940 administrator and the monotonically increasing serial number of the 1941 last zone modification. There is no single human administrator for 1942 any given Multicast DNS Zone, so there is no email address. Because 1943 the hosts managing any given Multicast DNS Zone are only loosely 1944 coordinated, there is no readily available monotonically increasing 1945 serial number to determine whether or not the zone contents have 1946 changed. A host holding part of the shared zone could crash or be 1947 disconnected from the network at any time without informing the other 1948 hosts. There is no reliable way to provide a zone serial number that 1949 would, whenever such a crash or disconnection occurred, immediately 1950 change to indicate that the contents of the shared zone had changed. 1951 1952 Zone transfers are not possible for any Multicast DNS Zone. 1953 1954 195513. Multicast DNS for Service Discovery 1956 1957 This document does not describe using Multicast DNS for network 1958 browsing or service discovery. However, the mechanisms this document 1959 describes are compatible with (and support) the browsing and service 1960 discovery mechanisms proposed in "DNS-Based Service Discovery" 1961 [DNS-SD]. 1962 1963 196414. Enabling and Disabling Multicast DNS 1965 1966 The option to fail-over to Multicast DNS for names not ending 1967 in ".local." SHOULD be a user-configured option, and SHOULD 1968 be disabled by default because of the possible security issues 1969 related to unintended local resolution of apparently global names. 1970 1971 1972Expires 10th February 2007 Cheshire & Krochmal [Page 34] 1973 1974Internet Draft Multicast DNS 10th August 2006 1975 1976 1977 The option to lookup unqualified (relative) names by appending 1978 ".local." (or not) is controlled by whether ".local." appears 1979 (or not) in the client's DNS search list. 1980 1981 No special control is needed for enabling and disabling Multicast DNS 1982 for names explicitly ending with ".local." as entered by the user. 1983 The user doesn't need a way to disable Multicast DNS for names ending 1984 with ".local.", because if the user doesn't want to use Multicast 1985 DNS, they can achieve this by simply not using those names. If a user 1986 *does* enter a name ending in ".local.", then we can safely assume 1987 the user's intention was probably that it should work. Having user 1988 configuration options that can be (intentionally or unintentionally) 1989 set so that local names don't work is just one more way of 1990 frustrating the user's ability to perform the tasks they want, 1991 perpetuating the view that, "IP networking is too complicated to 1992 configure and too hard to use." This in turn perpetuates the 1993 continued use of protocols like AppleTalk. If we want to retire 1994 AppleTalk, NetBIOS, etc., we need to offer users equivalent IP 1995 functionality that they can rely on to, "always work, like 1996 AppleTalk." A little Multicast DNS traffic may be a burden on the 1997 network, but it is an insignificant burden compared to continued 1998 widespread use of AppleTalk. 1999 2000 200115. Considerations for Multiple Interfaces 2002 2003 A host SHOULD defend its host name (FQDN) on all active interfaces on 2004 which it is answering Multicast DNS queries. 2005 2006 In the event of a name conflict on *any* interface, a host should 2007 configure a new host name, if it wishes to maintain uniqueness of its 2008 host name. 2009 2010 A host may choose to use the same name for all of its address records 2011 on all interfaces, or it may choose to manage its Multicast DNS host 2012 name(s) independently on each interface, potentially answering to 2013 different names on different interfaces. 2014 2015 When answering a Multicast DNS query, a multi-homed host with a 2016 link-local address (or addresses) SHOULD take care to ensure that 2017 any address going out in a Multicast DNS response is valid for use 2018 on the interface on which the response is going out. 2019 2020 Just as the same link-local IP address may validly be in use 2021 simultaneously on different links by different hosts, the same 2022 link-local host name may validly be in use simultaneously on 2023 different links, and this is not an error. A multi-homed host with 2024 connections to two different links may be able to communicate with 2025 two different hosts that are validly using the same name. While this 2026 kind of name duplication should be rare, it means that a host that 2027 wants to fully support this case needs network programming APIs that 2028 allow applications to specify on what interface to perform a 2029 2030Expires 10th February 2007 Cheshire & Krochmal [Page 35] 2031 2032Internet Draft Multicast DNS 10th August 2006 2033 2034 2035 link-local Multicast DNS query, and to discover on what interface a 2036 Multicast DNS response was received. 2037 2038 There is one other special precaution that multi-homed hosts need to 2039 take. It's common with today's laptop computers to have an Ethernet 2040 connection and an 802.11 wireless connection active at the same time. 2041 What the software on the laptop computer can't easily tell is whether 2042 the wireless connection is in fact bridged onto the same network 2043 segment as its Ethernet connection. If the two networks are bridged 2044 together, then packets the host sends on one interface will arrive on 2045 the other interface a few milliseconds later, and care must be taken 2046 to ensure that this bridging does not cause problems: 2047 2048 When the host announces its host name (i.e. its address records) on 2049 its wireless interface, those announcement records are sent with the 2050 cache-flush bit set, so when they arrive on the Ethernet segment, 2051 they will cause all the peers on the Ethernet to flush the host's 2052 Ethernet address records from their caches. The mDNS protocol has a 2053 safeguard to protect against this situation: when records are 2054 received with the cache-flush bit set, other records are not deleted 2055 from peer caches immediately, but are marked for deletion in one 2056 second. When the host sees its own wireless address records arrive on 2057 its Ethernet interface, with the cache-flush bit set, this one-second 2058 grace period gives the host time to respond and re-announce its 2059 Ethernet address records, to reinstate those records in peer caches 2060 before they are deleted. 2061 2062 As described, this solves one problem, but creates another, because 2063 when those Ethernet announcement records arrive back on the wireless 2064 interface, the host would again respond defensively to reinstate its 2065 wireless records, and this process would continue forever, 2066 continuously flooding the network with traffic. The mDNS protocol has 2067 a second safeguard, to solve this problem: the cache-flush bit does 2068 not apply to records received very recently, within the last second. 2069 This means that when the host sees its own Ethernet address records 2070 arrive on its wireless interface, with the cache-flush bit set, it 2071 knows there's no need to re-announce its wireless address records 2072 again because it already sent them less than a second ago, and this 2073 makes them immune from deletion from peer caches. 2074 207516. Considerations for Multiple Responders on the Same Machine 2076 2077 It is possible to have more than one Multicast DNS Responder and/or 2078 Querier implementation coexist on the same machine, but there are 2079 some known issues. 2080 208116.1 Receiving Unicast Responses 2082 2083 In most operating systems, incoming multicast packets can be 2084 delivered to *all* open sockets bound to the right port number, 2085 provided that the clients take the appropriate steps to allow this. 2086 For this reason, all Multicast DNS implementations SHOULD use the 2087 2088Expires 10th February 2007 Cheshire & Krochmal [Page 36] 2089 2090Internet Draft Multicast DNS 10th August 2006 2091 2092 2093 SO_REUSEPORT and/or SO_REUSEADDR options (or equivalent as 2094 appropriate for the operating system in question) so they will all be 2095 able to bind to UDP port 5353 and receive incoming multicast packets 2096 addressed to that port. However, incoming unicast UDP packets are 2097 typically delivered only to the first socket to bind to that port. 2098 This means that "QU" responses and other packets sent via unicast 2099 will be received only by the first Multicast DNS Responder and/or 2100 Querier on a system. This limitation can be partially mitigated if 2101 Multicast DNS implementations detect when they are not the first 2102 to bind to port 5353, and in that case they do not request "QU" 2103 responses. One way to detect if there is another Multicast DNS 2104 implementation already running is to attempt binding to port 5353 2105 without using SO_REUSEPORT and/or SO_REUSEADDR, and if that fails 2106 it indicates that some other socket is already bound to this port. 2107 2108 210916.2 Multi-Packet Known-Answer lists 2110 2111 When a Multicast DNS Querier issues a query with too many known 2112 answers to fit into a single packet, it divides the known answer list 2113 into two or more packets. Multicast DNS Responders associate the 2114 initial truncated query with its continuation packets by examining 2115 the source IP address in each packet. Since two independent Multicast 2116 DNS Queriers running on the same machine will be sending packets with 2117 the same source IP address, from an outside perspective they appear 2118 to be a single entity. If both Queriers happened to send the same 2119 multi-packet query at the same time, with different known answer 2120 lists, then they could each end up suppressing answers that the other 2121 needs. 2122 2123 212416.3 Efficiency 2125 2126 If different clients on a machine were to each have their own 2127 separate independent Multicast DNS implementation, they would lose 2128 certain efficiency benefits. Apart from the unnecessary code 2129 duplication, memory usage, and CPU load, the clients wouldn't get the 2130 benefit of a shared system-wide cache, and they would not be able to 2131 aggregate separate queries into single packets to reduce network 2132 traffic. 2133 2134 213516.4 Recommendation 2136 2137 Because of these issues, this document encourages implementers 2138 to design systems with a single Multicast DNS implementation that 2139 provides Multicast DNS services shared by all clients on that 2140 machine. Due to engineering constraints, there may be situations 2141 where embedding a Multicast DNS implementation in the client is the 2142 most expedient solution, and while this will work in practice, 2143 implementers should be aware of the issues outlined in this section. 2144 2145 2146Expires 10th February 2007 Cheshire & Krochmal [Page 37] 2147 2148Internet Draft Multicast DNS 10th August 2006 2149 215017. Multicast DNS and Power Management 2151 2152 Many modern network devices have the ability to go into a low-power 2153 mode where only a small part of the Ethernet hardware remains 2154 powered, and the device can be woken up by sending a specially 2155 formatted Ethernet frame which the device's power-management hardware 2156 recognizes. 2157 2158 To make use of this in conjunction with Multicast DNS, we propose a 2159 network power management service called Sleep Proxy Service. A device 2160 that wishes to enter low-power mode first uses DNS-SD to determine if 2161 Sleep Proxy Service is available on the local network. In some 2162 networks there may be more than one piece of hardware implementing 2163 Sleep Proxy Service, for fault-tolerance reasons. 2164 2165 If the device finds the network has Sleep Proxy Service, the device 2166 transmits two or more gratuitous mDNS announcements setting the TTL 2167 of its relevant resource records to zero, to delete them from 2168 neighboring caches. The relevant resource records include address 2169 records and SRV records, and other resource records as may apply to a 2170 particular device. The device then communicates all of its remaining 2171 active records, plus the names, rrtypes and rrclasses of the deleted 2172 records, to the Sleep Proxy Service(s), along with a copy of the 2173 specific "magic packet" required to wake the device up. 2174 2175 When a Sleep Proxy Service sees an mDNS query for one of the 2176 device's active records (e.g. a DNS-SD PTR record), it answers on 2177 behalf of the device without waking it up. When a Sleep Proxy Service 2178 sees an mDNS query for one of the device's deleted resource 2179 records, it deduces that some client on the network needs to make an 2180 active connection to the device, and sends the specified "magic 2181 packet" to wake the device up. The device then wakes up, reactivates 2182 its deleted resource records, and re-announces them to the network. 2183 The client waiting to connect sees the announcements, learns the 2184 current IP address and port number of the desired service on the 2185 device, and proceeds to connect to it. 2186 2187 The connecting client does not need to be aware of how Sleep Proxy 2188 Service works. Only devices that implement low power mode and wish to 2189 make use of Sleep Proxy Service need to be aware of how that protocol 2190 works. 2191 2192 The reason that a device using a Sleep Proxy Service should send more 2193 than one goodbye packet is to ensure deletion of the resource records 2194 from all peer caches. If resource records were to inadvertently 2195 remain in some peer caches, then those peers may not issue any query 2196 packets for those records when attempting to access the sleeping 2197 device, so the Sleep Proxy Service would not receive any queries for 2198 the device's SRV and/or address records, and the necessary wake-up 2199 message would not be triggered. 2200 2201 The full specification of mDNS / DNS-SD Sleep Proxy Service 2202 is described in another document [not yet published]. 2203 2204Expires 10th February 2007 Cheshire & Krochmal [Page 38] 2205 2206Internet Draft Multicast DNS 10th August 2006 2207 2208 220918. Multicast DNS Character Set 2210 2211 Unicast DNS has been plagued by the lack of any support for non-US 2212 characters. Indeed, conventional DNS is usually limited to just 2213 letters, digits and hyphens, with no spaces or other punctuation. 2214 Attempts to remedy this for unicast DNS have been badly constrained 2215 by the need to accommodate old buggy legacy DNS implementations. 2216 In reality, the DNS specification actually imposes no limits on what 2217 characters may be used in names, and good DNS implementations handle 2218 any arbitrary eight-bit data without trouble. However, the old rules 2219 for ARPANET host names back in the 1980s required names to be just 2220 letters, digits, and hyphens [RFC 1034], and since the predominant 2221 use of DNS is to store host address records, many have assumed that 2222 the DNS protocol itself suffers from the same limitation. It would be 2223 more accurate to say that certain bad implementations may not handle 2224 eight-bit data correctly, not that the protocol doesn't support it. 2225 2226 Multicast DNS is a new protocol and doesn't (yet) have old buggy 2227 legacy implementations to constrain the design choices. Accordingly, 2228 it adopts the simple obvious elegant solution: all names in Multicast 2229 DNS are encoded using precomposed UTF-8 [RFC 3629]. The characters 2230 SHOULD conform to Unicode Normalization Form C (NFC) [UAX15]: Use 2231 precomposed characters instead of combining sequences where possible, 2232 e.g. use U+00C4 ("Latin capital letter A with diaeresis") instead of 2233 U+0041 U+0308 ("Latin capital letter A", "combining diaeresis"). 2234 2235 Some users of 16-bit Unicode have taken to stuffing a "zero-width 2236 non-breaking space" character (U+FEFF) at the start of each UTF-16 2237 file, as a hint to identify whether the data is big-endian or 2238 little-endian, and calling it a "Byte Order Mark" (BOM). Since there 2239 is only one possible byte order for UTF-8 data, a BOM is neither 2240 necessary nor permitted. Multicast DNS names MUST NOT contain a "Byte 2241 Order Mark". Any occurrence of the Unicode character U+FEFF at the 2242 start or anywhere else in a Multicast DNS name MUST be interpreted as 2243 being an actual intended part of the name, representing (just as for 2244 any other legal unicode value) an actual literal instance of that 2245 character (in this case a zero-width non-breaking space character). 2246 2247 For names that are restricted to letters, digits and hyphens, the 2248 UTF-8 encoding is identical to the US-ASCII encoding, so this is 2249 entirely compatible with existing host names. For characters outside 2250 the US-ASCII range, UTF-8 encoding is used. 2251 2252 Multicast DNS implementations MUST NOT use any other encodings apart 2253 from precomposed UTF-8 (US-ASCII being considered a compatible subset 2254 of UTF-8). 2255 2256 This point bears repeating: After many years of debate, as a 2257 result of the need to accommodate certain DNS implementations that 2258 apparently couldn't handle any character that's not a letter, digit 2259 or hyphen (and apparently never will be updated to remedy this 2260 2261 2262Expires 10th February 2007 Cheshire & Krochmal [Page 39] 2263 2264Internet Draft Multicast DNS 10th August 2006 2265 2266 2267 limitation) the unicast DNS community settled on an extremely baroque 2268 encoding called "Punycode" [RFC 3492]. Punycode is a remarkably 2269 ingenious encoding solution, but it is complicated, hard to 2270 understand, and hard to implement, using sophisticated techniques 2271 including insertion unsort coding, generalized variable-length 2272 integers, and bias adaptation. The resulting encoding is remarkably 2273 compact given the constraints, but it's still not as good as simple 2274 straightforward UTF-8, and it's hard even to predict whether a given 2275 input string will encode to a Punycode string that fits within DNS's 2276 63-byte limit, except by simply trying the encoding and seeing 2277 whether it fits. Indeed, the encoded size depends not only on the 2278 input characters, but on the order they appear, so the same set of 2279 characters may or may not encode to a legal Punycode string that fits 2280 within DNS's 63-byte limit, depending on the order the characters 2281 appear. This is extremely hard to present in a user interface that 2282 explains to users why one name is allowed, but another name 2283 containing the exact same characters is not. Neither Punycode nor any 2284 other of the "Ascii Compatible Encodings" proposed for Unicast DNS 2285 may be used in Multicast DNS packets. Any text being represented 2286 internally in some other representation MUST be converted to 2287 canonical precomposed UTF-8 before being placed in any Multicast DNS 2288 packet. 2289 2290 The simple rules for case-insensitivity in Unicast DNS also apply in 2291 Multicast DNS; that is to say, in name comparisons, the lower-case 2292 letters "a" to "z" (0x61 to 0x7A) match their upper-case equivalents 2293 "A" to "Z" (0x41 to 0x5A). Hence, if a client issues a query for an 2294 address record with the name "cheshire.local", then a responder 2295 having an address record with the name "Cheshire.local" should 2296 issue a response. No other automatic equivalences should be assumed. 2297 In particular all UTF-8 multi-byte characters (codes 0x80 and higher) 2298 are compared by simple binary comparison of the raw byte values. 2299 Accented characters are *not* defined to be automatically equivalent 2300 to their unaccented counterparts. Where automatic equivalences are 2301 desired, this may be achieved through the use of programmatically- 2302 generated CNAME records. For example, if a responder has an address 2303 record for an accented name Y, and a client issues a query for a name 2304 X, where X is the same as Y with all the accents removed, then the 2305 responder may issue a response containing two resource records: 2306 A CNAME record "X CNAME Y", asserting that the requested name X 2307 (unaccented) is an alias for the true (accented) name Y, followed 2308 by the address record for Y. 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320Expires 10th February 2007 Cheshire & Krochmal [Page 40] 2321 2322Internet Draft Multicast DNS 10th August 2006 2323 2324 232519. Multicast DNS Message Size 2326 2327 RFC 1035 restricts DNS Messages carried by UDP to no more than 512 2328 bytes (not counting the IP or UDP headers) [RFC 1035]. For UDP 2329 packets carried over the wide-area Internet in 1987, this was 2330 appropriate. For link-local multicast packets on today's networks, 2331 there is no reason to retain this restriction. Given that the packets 2332 are by definition link-local, there are no Path MTU issues to 2333 consider. 2334 2335 Multicast DNS Messages carried by UDP may be up to the IP MTU of the 2336 physical interface, less the space required for the IP header (20 2337 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes). 2338 2339 In the case of a single mDNS Resource Record which is too large to 2340 fit in a single MTU-sized multicast response packet, a Multicast DNS 2341 Responder SHOULD send the Resource Record alone, in a single IP 2342 datagram, sent using multiple IP fragments. Resource Records this 2343 large SHOULD be avoided, except in the very rare cases where they 2344 really are the appropriate solution to the problem at hand. 2345 Implementers should be aware that many simple devices do not 2346 re-assemble fragmented IP datagrams, so large Resource Records 2347 SHOULD NOT be used except in specialized cases where the implementer 2348 knows that all receivers implement reassembly. 2349 2350 A Multicast DNS packet larger than the interface MTU, which is sent 2351 using fragments, MUST NOT contain more than one Resource Record. 2352 2353 Even when fragmentation is used, a Multicast DNS packet, including IP 2354 and UDP headers, MUST NOT exceed 9000 bytes. 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378Expires 10th February 2007 Cheshire & Krochmal [Page 41] 2379 2380Internet Draft Multicast DNS 10th August 2006 2381 2382 238320. Multicast DNS Message Format 2384 2385 This section describes specific restrictions on the allowable 2386 values for the header fields of a Multicast DNS message. 2387 2388 238920.1 ID (Query Identifier) 2390 2391 Multicast DNS clients SHOULD listen for gratuitous responses 2392 issued by hosts booting up (or waking up from sleep or otherwise 2393 joining the network). Since these gratuitous responses may contain a 2394 useful answer to a question for which the client is currently 2395 awaiting an answer, Multicast DNS clients SHOULD examine all received 2396 Multicast DNS response messages for useful answers, without regard to 2397 the contents of the ID field or the Question Section. In Multicast 2398 DNS, knowing which particular query message (if any) is responsible 2399 for eliciting a particular response message is less interesting than 2400 knowing whether the response message contains useful information. 2401 2402 Multicast DNS clients MAY cache any or all Multicast DNS response 2403 messages they receive, for possible future use, provided of course 2404 that normal TTL aging is performed on these cached resource records. 2405 2406 In multicast query messages, the Query ID SHOULD be set to zero on 2407 transmission. 2408 2409 In multicast responses, including gratuitous multicast responses, the 2410 Query ID MUST be set to zero on transmission, and MUST be ignored on 2411 reception. 2412 2413 In unicast response messages generated specifically in response to a 2414 particular (unicast or multicast) query, the Query ID MUST match the 2415 ID from the query message. 2416 2417 241820.2 QR (Query/Response) Bit 2419 2420 In query messages, MUST be zero. 2421 In response messages, MUST be one. 2422 2423 242420.3 OPCODE 2425 2426 In both multicast query and multicast response messages, MUST be zero 2427 (only standard queries are currently supported over multicast, unless 2428 other queries are allowed by future IETF Standards Action). 2429 2430 2431 2432 2433 2434 2435 2436Expires 10th February 2007 Cheshire & Krochmal [Page 42] 2437 2438Internet Draft Multicast DNS 10th August 2006 2439 2440 244120.4 AA (Authoritative Answer) Bit 2442 2443 In query messages, the Authoritative Answer bit MUST be zero on 2444 transmission, and MUST be ignored on reception. 2445 2446 In response messages for Multicast Domains, the Authoritative Answer 2447 bit MUST be set to one (not setting this bit implies there's some 2448 other place where "better" information may be found) and MUST be 2449 ignored on reception. 2450 2451 245220.5 TC (Truncated) Bit 2453 2454 In query messages, if the TC bit is set, it means that additional 2455 Known Answer records may be following shortly. A responder MAY choose 2456 to record this fact, and wait for those additional Known Answer 2457 records, before deciding whether to respond. If the TC bit is clear, 2458 it means that the querying host has no additional Known Answers. 2459 2460 In multicast response messages, the TC bit MUST be zero on 2461 transmission, and MUST be ignored on reception. 2462 2463 In legacy unicast response messages, the TC bit has the same meaning 2464 as in conventional unicast DNS: it means that the response was too 2465 large to fit in a single packet, so the client SHOULD re-issue its 2466 query using TCP in order to receive the larger response. 2467 2468 246920.6 RD (Recursion Desired) Bit 2470 2471 In both multicast query and multicast response messages, the 2472 Recursion Desired bit SHOULD be zero on transmission, and MUST be 2473 ignored on reception. 2474 2475 247620.7 RA (Recursion Available) Bit 2477 2478 In both multicast query and multicast response messages, the 2479 Recursion Available bit MUST be zero on transmission, and MUST be 2480 ignored on reception. 2481 2482 248320.8 Z (Zero) Bit 2484 2485 In both query and response messages, the Zero bit MUST be zero on 2486 transmission, and MUST be ignored on reception. 2487 2488 2489 2490 2491 2492 2493 2494Expires 10th February 2007 Cheshire & Krochmal [Page 43] 2495 2496Internet Draft Multicast DNS 10th August 2006 2497 2498 249920.9 AD (Authentic Data) Bit [RFC 2535] 2500 2501 In query messages the Authentic Data bit MUST be zero on 2502 transmission, and MUST be ignored on reception. 2503 2504 In response messages, the Authentic Data bit MAY be set. Resolvers 2505 receiving response messages with the AD bit set MUST NOT trust the AD 2506 bit unless they trust the source of the message and either have a 2507 secure path to it or use DNS transaction security. 2508 2509 251020.10 CD (Checking Disabled) Bit [RFC 2535] 2511 2512 In query messages, a resolver willing to do cryptography SHOULD set 2513 the Checking Disabled bit to permit it to impose its own policies. 2514 2515 In response messages, the Checking Disabled bit MUST be zero on 2516 transmission, and MUST be ignored on reception. 2517 2518 251920.11 RCODE (Response Code) 2520 2521 In both multicast query and multicast response messages, the Response 2522 Code MUST be zero on transmission. Multicast DNS messages received 2523 with non-zero Response Codes MUST be silently ignored. 2524 2525 252620.12 Repurposing of top bit of qclass in Question Section 2527 2528 In the Question Section of a Multicast DNS Query, the top bit of the 2529 qclass field is used to indicate that unicast responses are preferred 2530 for this particular question. 2531 2532 253320.13 Repurposing of top bit of rrclass in Answer Section 2534 2535 In the Answer Section of a Multicast DNS Response, the top bit of the 2536 rrclass field is used to indicate that the record is a member of a 2537 unique RRSet, and the entire RRSet has been sent together (in the 2538 same packet, or in consecutive packets if there are too many records 2539 to fit in a single packet). 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552Expires 10th February 2007 Cheshire & Krochmal [Page 44] 2553 2554Internet Draft Multicast DNS 10th August 2006 2555 2556 255721. Choice of UDP Port Number 2558 2559 Arguments were made for and against using Multicast on UDP port 53. 2560 The final decision was to use UDP port 5353. Some of the arguments 2561 for and against are given below. 2562 2563 256421.1 Arguments for using UDP port 53: 2565 2566 * This is "just DNS", so it should be the same port. 2567 2568 * There is less work to be done updating old clients to do simple 2569 mDNS queries. Only the destination address need be changed. 2570 In some cases, this can be achieved without any code changes, 2571 just by adding the address 224.0.0.251 to a configuration file. 2572 2573 257421.2 Arguments for using a different port (UDP port 5353): 2575 2576 * This is not "just DNS". This is a DNS-like protocol, but different. 2577 2578 * Changing client code to use a different port number is not hard. 2579 2580 * Using the same port number makes it hard to run an mDNS Responder 2581 and a conventional unicast DNS server on the same machine. If a 2582 conventional unicast DNS server wishes to implement mDNS as well, 2583 it can still do that, by opening two sockets. Having two different 2584 port numbers is important to allow this flexibility. 2585 2586 * Some VPN software hijacks all outgoing traffic to port 53 and 2587 redirects it to a special DNS server set up to serve those VPN 2588 clients while they are connected to the corporate network. It is 2589 questionable whether this is the right thing to do, but it is 2590 common, and redirecting link-local multicast DNS packets to a 2591 remote server rarely produces any useful results. It does mean, 2592 for example, that the user becomes unable to access their local 2593 network printer sitting on their desk right next to their computer. 2594 Using a different UDP port eliminates this particular problem. 2595 2596 * On many operating systems, unprivileged clients may not send or 2597 receive packets on low-numbered ports. This means that any client 2598 sending or receiving mDNS packets on port 53 would have to run 2599 as "root", which is an undesirable security risk. Using a higher- 2600 numbered UDP port eliminates this particular problem. 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610Expires 10th February 2007 Cheshire & Krochmal [Page 45] 2611 2612Internet Draft Multicast DNS 10th August 2006 2613 2614 261522. Summary of Differences Between Multicast DNS and Unicast DNS 2616 2617 The value of Multicast DNS is that it shares, as much as possible, 2618 the familiar APIs, naming syntax, resource record types, etc., of 2619 Unicast DNS. There are of course necessary differences by virtue of 2620 it using Multicast, and by virtue of it operating in a community of 2621 cooperating peers, rather than a precisely defined authoritarian 2622 hierarchy controlled by a strict chain of formal delegations from the 2623 top. These differences are listed below: 2624 2625 Multicast DNS... 2626 * uses multicast 2627 * uses UDP port 5353 instead of port 53 2628 * operates in well-defined parts of the DNS namespace 2629 * uses UTF-8, and only UTF-8, to encode resource record names 2630 * defines a clear limit on the maximum legal domain name (255 bytes) 2631 * allows larger UDP packets 2632 * allows more than one question in a query packet 2633 * uses the Answer Section of a query to list Known Answers 2634 * uses the TC bit in a query to indicate additional Known Answers 2635 * uses the Authority Section of a query for probe tie-breaking 2636 * ignores the Query ID field (except for generating legacy responses) 2637 * doesn't require the question to be repeated in the response packet 2638 * uses gratuitous responses to announce new records to the peer group 2639 * defines a "unicast response" bit in the rrclass of query questions 2640 * defines a "cache flush" bit in the rrclass of response answers 2641 * uses DNS TTL 0 to indicate that a record has been deleted 2642 * monitors queries to perform Duplicate Question Suppression 2643 * monitors responses to perform Duplicate Answer Suppression... 2644 * ... and Ongoing Conflict Detection 2645 * ... and Opportunistic Caching 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668Expires 10th February 2007 Cheshire & Krochmal [Page 46] 2669 2670Internet Draft Multicast DNS 10th August 2006 2671 267223. Benefits of Multicast Responses 2673 2674 Some people have argued that sending responses via multicast is 2675 inefficient on the network. In fact using multicast responses results 2676 in a net lowering of overall multicast traffic, for a variety of 2677 reasons, in addition to other benefits. 2678 2679 * One multicast response can update the cache on all machines on the 2680 network. If another machine later wants to issue the same query, it 2681 already has the answer in its cache, so it may not need to even 2682 transmit that multicast query on the network at all. 2683 2684 * When more than one machine has the same ongoing long-lived query 2685 running, every machine does not have to transmit its own 2686 independent query. When one machine transmits a query, all the 2687 other hosts see the answers, so they can suppress their own 2688 queries. 2689 2690 * When a host sees a multicast query, but does not see the corres- 2691 ponding multicast response, it can use this information to promptly 2692 delete stale data from its cache. To achieve the same level of 2693 user-interface quality and responsiveness without multicast 2694 responses would require lower cache lifetimes and more frequent 2695 network polling, resulting in a significantly higher packet rate. 2696 2697 * Multicast responses allow passive conflict detection. Without this 2698 ability, some other conflict detection mechanism would be needed, 2699 imposing its own additional burden on the network. 2700 2701 * When using delayed responses to reduce network collisions, clients 2702 need to maintain a list recording to whom each answer should be 2703 sent. The option of multicast responses allows clients with limited 2704 storage, which cannot store an arbitrarily long list of response 2705 addresses, to choose to fail-over to a single multicast response in 2706 place of multiple unicast responses, when appropriate. 2707 2708 * In the case of overlayed subnets, multicast responses allow a 2709 receiver to know with certainty that a response originated on the 2710 local link, even when its source address may apparently suggest 2711 otherwise. 2712 2713 * Link-local multicast transcends virtually every conceivable network 2714 misconfiguration. Even if you have a collection of devices where 2715 every device's IP address, subnet mask, default gateway, and DNS 2716 server address are all wrong, packets sent by any of those devices 2717 addressed to a link-local multicast destination address will still 2718 be delivered to all peers on the local link. This can be extremely 2719 helpful when diagnosing and rectifying network problems, since 2720 it facilitates a direct communication channel between client and 2721 server that works without reliance on ARP, IP routing tables, etc. 2722 Being able to discover what IP address a device has (or thinks it 2723 has) is frequently a very valuable first step in diagnosing why it 2724 is unable to communicate on the local network. 2725 2726Expires 10th February 2007 Cheshire & Krochmal [Page 47] 2727 2728Internet Draft Multicast DNS 10th August 2006 2729 2730 273124. IPv6 Considerations 2732 2733 An IPv4-only host and an IPv6-only host behave as "ships that pass in 2734 the night". Even if they are on the same Ethernet, neither is aware 2735 of the other's traffic. For this reason, each physical link may have 2736 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 2737 Since for practical purposes, a group of IPv4-only hosts and a group 2738 of IPv6-only hosts on the same Ethernet act as if they were on two 2739 entirely separate Ethernet segments, it is unsurprising that their 2740 use of the ".local." zone should occur exactly as it would if 2741 they really were on two entirely separate Ethernet segments. 2742 2743 A dual-stack (v4/v6) host can participate in both ".local." 2744 zones, and should register its name(s) and perform its lookups both 2745 using IPv4 and IPv6. This enables it to reach, and be reached by, 2746 both IPv4-only and IPv6-only hosts. In effect this acts like a 2747 multi-homed host, with one connection to the logical "IPv4 Ethernet 2748 segment", and a connection to the logical "IPv6 Ethernet segment". 2749 2750 275124.1 IPv6 Multicast Addresses by Hashing 2752 2753 Some discovery protocols use a range of multicast addresses, and 2754 determine the address to be used by a hash function of the name being 2755 sought. Queries are sent via multicast to the address as indicated by 2756 the hash function, and responses are returned to the querier via 2757 unicast. Particularly in IPv6, where multicast addresses are 2758 extremely plentiful, this approach is frequently advocated. 2759 2760 There are some problems with this: 2761 2762 * When a host has a large number of records with different names, the 2763 host may have to join a large number of multicast groups. This can 2764 place undue burden on the Ethernet hardware, which typically 2765 supports a limited number of multicast addresses efficiently. When 2766 this number is exceeded, the Ethernet hardware may have to resort 2767 to receiving all multicasts and passing them up to the host 2768 software for filtering, thereby defeating the point of using a 2769 multicast address range in the first place. 2770 2771 * Multiple questions cannot be placed in one packet if they don't all 2772 hash to the same multicast address. 2773 2774 * Duplicate Question Suppression doesn't work if queriers are not 2775 seeing each other's queries. 2776 2777 * Duplicate Answer Suppression doesn't work if responders are not 2778 seeing each other's responses. 2779 2780 * Opportunistic Caching doesn't work. 2781 2782 * Ongoing Conflict Detection doesn't work. 2783 2784Expires 10th February 2007 Cheshire & Krochmal [Page 48] 2785 2786Internet Draft Multicast DNS 10th August 2006 2787 2788 278925. Security Considerations 2790 2791 The algorithm for detecting and resolving name conflicts is, by its 2792 very nature, an algorithm that assumes cooperating participants. Its 2793 purpose is to allow a group of hosts to arrive at a mutually disjoint 2794 set of host names and other DNS resource record names, in the absence 2795 of any central authority to coordinate this or mediate disputes. In 2796 the absence of any higher authority to resolve disputes, the only 2797 alternative is that the participants must work together cooperatively 2798 to arrive at a resolution. 2799 2800 In an environment where the participants are mutually antagonistic 2801 and unwilling to cooperate, other mechanisms are appropriate, like 2802 manually administered DNS. 2803 2804 In an environment where there is a group of cooperating participants, 2805 but there may be other antagonistic participants on the same physical 2806 link, the cooperating participants need to use IPSEC signatures 2807 and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS 2808 messages from trusted participants (which they process as usual) from 2809 mDNS messages from untrusted participants (which they silently 2810 discard). 2811 2812 When DNS queries for *global* DNS names are sent to the mDNS 2813 multicast address (during network outages which disrupt communication 2814 with the greater Internet) it is *especially* important to use 2815 DNSSEC, because the user may have the impression that he or she is 2816 communicating with some authentic host, when in fact he or she is 2817 really communicating with some local host that is merely masquerading 2818 as that name. This is less critical for names ending with ".local.", 2819 because the user should be aware that those names have only local 2820 significance and no global authority is implied. 2821 2822 Most computer users neglect to type the trailing dot at the end of a 2823 fully qualified domain name, making it a relative domain name (e.g. 2824 "www.example.com"). In the event of network outage, attempts to 2825 positively resolve the name as entered will fail, resulting in 2826 application of the search list, including ".local.", if present. 2827 A malicious host could masquerade as "www.example.com" by answering 2828 the resulting Multicast DNS query for "www.example.com.local." 2829 To avoid this, a host MUST NOT append the search suffix 2830 ".local.", if present, to any relative (partially qualified) 2831 host name containing two or more labels. Appending ".local." to 2832 single-label relative host names is acceptable, since the user 2833 should have no expectation that a single-label host name will 2834 resolve as-is. 2835 2836 2837 2838 2839 2840 2841 2842Expires 10th February 2007 Cheshire & Krochmal [Page 49] 2843 2844Internet Draft Multicast DNS 10th August 2006 2845 2846 284726. IANA Considerations 2848 2849 IANA has allocated the IPv4 link-local multicast address 224.0.0.251 2850 for the use described in this document. 2851 2852 IANA has allocated the IPv6 multicast address set FF0X::FB for the 2853 use described in this document. Only address FF02::FB (Link-Local 2854 Scope) is currently in use by deployed software, but it is possible 2855 that in future implementers may experiment with Multicast DNS using 2856 larger-scoped addresses, such as FF05::FB (Site-Local Scope). 2857 2858 When this document is published, IANA should designate a list of 2859 domains which are deemed to have only link-local significance, as 2860 described in Section 12 of this document ("Special Characteristics of 2861 Multicast DNS Domains"). 2862 2863 The re-use of the top bit of the rrclass field in the Question and 2864 Answer Sections means that Multicast DNS can only carry DNS records 2865 with classes in the range 0-32767. Classes in the range 32768 to 2866 65535 are incompatible with Multicast DNS. However, since to-date 2867 only three DNS classes have been assigned by IANA (1, 3 and 4), 2868 and only one (1, "Internet") is actually in widespread use, this 2869 limitation is likely to remain a purely theoretical one. 2870 2871 No other IANA services are required by this document. 2872 2873 287427. Acknowledgments 2875 2876 The concepts described in this document have been explored, developed 2877 and implemented with help from Freek Dijkstra, Erik Guttman, Paul 2878 Vixie, Bill Woodcock, and others. 2879 2880 Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, 2881 Roger Pantos and Kiren Sekar for their significant contributions. 2882 2883 288428. Deployment History 2885 2886 Multicast DNS client software first became available to the public 2887 in Mac OS 9 in 2001. Multicast DNS Responder software first began 2888 shipping to end users in large volumes (i.e. millions) with the 2889 launch of Mac OS X 10.2 Jaguar in August 2002, and became available 2890 for Microsoft Windows users with the launch of Apple's "Rendezvous 2891 for Windows" (now "Bonjour for Windows") in June 2004. 2892 2893 Apple released the source code for the mDNSResponder daemon as Open 2894 Source in September 2002, first under Apple's standard Apple Public 2895 Source License, and then later, in August 2006, under the Apache 2896 License, Version 2.0. 2897 2898 2899 2900Expires 10th February 2007 Cheshire & Krochmal [Page 50] 2901 2902Internet Draft Multicast DNS 10th August 2006 2903 2904 2905 In addition to desktop and laptop computers running Mac OS X and 2906 Microsoft Windows, Multicast DNS is implemented in a wide range of 2907 hardware devices, such as Apple's "AirPort Extreme" and "AirPort 2908 Express" wireless base stations, home gateways from other vendors, 2909 network printers, network cameras, TiVo DVRs, etc. 2910 2911 The Open Source community has produced many independent 2912 implementations of Multicast DNS, some in C like Apple's 2913 mDNSResponder daemon, and others in a variety of different languages 2914 including Java, Python, Perl, and C#/Mono. 2915 2916 291729. Copyright Notice 2918 2919 Copyright (C) The Internet Society (2006). 2920 2921 This document is subject to the rights, licenses and restrictions 2922 contained in BCP 78, and except as set forth therein, the authors 2923 retain all their rights. For the purposes of this document, 2924 the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights 2925 in Contributions", published March 2005. 2926 2927 This document and the information contained herein are provided on an 2928 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2929 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2930 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2931 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2932 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2933 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2934 2935 293630. Normative References 2937 2938 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 2939 Facilities", STD 13, RFC 1034, November 1987. 2940 2941 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 2942 Specifications", STD 13, RFC 1035, November 1987. 2943 2944 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 2945 Requirement Levels", RFC 2119, March 1997. 2946 2947 [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO 2948 10646", RFC 3629, November 2003. 2949 2950 [UAX15] "Unicode Normalization Forms" 2951 http://www.unicode.org/reports/tr15/ 2952 2953 2954 2955 2956 2957 2958Expires 10th February 2007 Cheshire & Krochmal [Page 51] 2959 2960Internet Draft Multicast DNS 10th August 2006 2961 2962 296331. Informative References 2964 2965 [dotlocal] <http://www.dotlocal.org/> 2966 2967 [djbdl] <http://cr.yp.to/djbdns/dot-local.html> 2968 2969 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service 2970 Discovery", Internet-Draft (work in progress), 2971 draft-cheshire-dnsext-dns-sd-04.txt, August 2006. 2972 2973 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 2974 Overview and Architecture. 2975 Institute of Electrical and Electronic Engineers, 2976 IEEE Standard 802, 1990. 2977 2978 [NBP] Cheshire, S., and M. Krochmal, 2979 "Requirements for a Protocol to Replace AppleTalk NBP", 2980 Internet-Draft (work in progress), 2981 draft-cheshire-dnsext-nbp-05.txt, August 2006. 2982 2983 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 2984 System (DNS UPDATE)", RFC 2136, April 1997. 2985 2986 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address 2987 Autoconfiguration", RFC 2462, December 1998. 2988 2989 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", 2990 RFC 2535, March 1999. 2991 2992 [RFC 2606] Eastlake, D., and A. Panitz, "Reserved Top Level DNS 2993 Names", RFC 2606, June 1999. 2994 2995 [RFC 2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum 2996 of Understanding Concerning the Technical Work of the 2997 Internet Assigned Numbers Authority", RFC 2860, June 2998 2000. 2999 3000 [RFC 3492] Costello, A., "Punycode: A Bootstring encoding of 3001 Unicode for use with Internationalized Domain Names 3002 in Applications (IDNA)", RFC 3492, March 2003. 3003 3004 [RFC 3927] Cheshire, S., B. Aboba, and E. Guttman, 3005 "Dynamic Configuration of IPv4 Link-Local Addresses", 3006 RFC 3927, May 2005. 3007 3008 [ZC] Williams, A., "Requirements for Automatic Configuration 3009 of IP Hosts", Internet-Draft (work in progress), 3010 draft-ietf-zeroconf-reqts-12.txt, September 2002. 3011 3012 3013 3014 3015 3016Expires 10th February 2007 Cheshire & Krochmal [Page 52] 3017 3018Internet Draft Multicast DNS 10th August 2006 3019 3020 302132. Authors' Addresses 3022 3023 Stuart Cheshire 3024 Apple Computer, Inc. 3025 1 Infinite Loop 3026 Cupertino 3027 California 95014 3028 USA 3029 3030 Phone: +1 408 974 3207 3031 EMail: rfc [at] stuartcheshire [dot] org 3032 3033 3034 Marc Krochmal 3035 Apple Computer, Inc. 3036 1 Infinite Loop 3037 Cupertino 3038 California 95014 3039 USA 3040 3041 Phone: +1 408 974 4368 3042 EMail: marc [at] apple [dot] com 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074Expires 10th February 2007 Cheshire & Krochmal [Page 53] 3075