idnits 2.17.1 draft-cheshire-dnsext-multicastdns-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 8 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7621 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 1034' is defined on line 1602, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 1605, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-01 -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Document: draft-cheshire-dnsext-multicastdns-02.txt Stuart Cheshire 2 Category: Standards Track Apple Computer, Inc. 3 Expires 20th December 2003 Marc Krochmal 4 Apple Computer, Inc. 5 20th June 2003 7 Performing DNS queries via IP Multicast 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), 16 its areas, and its working groups. Note that other groups may 17 also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Distribution of this memo is unlimited. 32 Abstract 34 As networked devices become smaller, more portable, and more 35 ubiquitous, the ability to operate with less configured 36 infrastructure is increasingly important. In particular, the ability 37 to look up host names and similar DNS resource record data types, in 38 the absence of a conventional managed DNS server, is becoming 39 essential. 41 Acknowledgements 43 The concepts described in this document have been explored and 44 developed with help from Erik Guttman, Paul Vixie, Bill Woodcock, 45 and others. 47 Table of Contents 49 1. Introduction...................................................3 50 2. Conventions and Terminology Used in this Document..............3 51 3. Multicast DNS Names............................................4 52 3.1 Standards Body.................................................6 53 3.2 Private DNS Namespaces.........................................7 54 3.3 Maximum Multicast DNS Name Length..............................7 55 4. IP TTL Checks..................................................8 56 5. Reverse Address Mapping........................................8 57 6. Querying.......................................................9 58 6.1 One-Shot Queries...............................................9 59 6.2 One-Shot Queries, Accumulating Multiple Responses..............9 60 6.3 Continuous Querying...........................................10 61 7. Duplicate Suppression.........................................11 62 7.1 Known Answer Suppression......................................11 63 7.2 Multi-Packet Known Answer Suppression.........................11 64 7.3 Duplicate Question Suppression................................12 65 7.4 Duplicate Answer Suppression..................................12 66 8. Responding....................................................13 67 9. Probing and Announcing on Startup.............................15 68 9.1 Probing.......................................................15 69 9.2 Simultaneous Probe Tie-Breaking...............................16 70 9.3 Announcing....................................................17 71 10. Conflict Resolution...........................................17 72 11. Special Characteristics of Multicast DNS Domains..............19 73 12. Multicast DNS for Service Discovery...........................20 74 13. Resource Record TTL Values and Cache Coherency................20 75 13.1 Cooperating Multicast DNS Responders..........................21 76 13.2 Goodbye Packets...............................................22 77 13.3 Announcements to Flush Outdated Cache Entries.................23 78 13.4 Cache Flush on Topology change................................23 79 13.5 Cache Flush on Failure Indication.............................24 80 14. Enabling and Disabling Multicast DNS..........................25 81 15. Considerations for Multiple Interfaces........................25 82 16. Multicast DNS and Power Management............................26 83 17. Multicast DNS Character Set...................................27 84 18. Multicast DNS Message Size....................................28 85 19. Multicast DNS Message Format..................................28 86 20. Choice of UDP Port Number.....................................31 87 20.1 Arguments for using UDP port 53:..............................31 88 20.2 Arguments for using a different port (UDP port 5353):.........31 89 21. Summary of Differences Between Multicast DNS and Unicast DNS..32 90 22. IPv6 Considerations...........................................33 91 22.1 Multicast Addresses by Hashing................................33 92 23. Security Considerations.......................................34 93 24. IANA Considerations...........................................35 94 25. Copyright.....................................................35 95 26. Normative References..........................................36 96 27. Informative References........................................36 97 28. Author's Addresses............................................37 99 1. Introduction 101 When reading this document, familiarity with the concepts of Zero 102 Configuration Networking [ZC] and automatic link-local addressing 103 [v4LL] [RFC 2462] is helpful. 105 This document proposes no change to the structure of DNS messages, 106 and no new operation codes, response codes, or resource record types. 107 This document simply discusses what needs to happen if DNS clients 108 start sending DNS queries to a multicast address, and how a 109 collection of hosts can cooperate to collectively answer those 110 queries in a useful manner. 112 There has been discussion of how much burden Multicast DNS might 113 impose on a network. It should be remembered that whenever IPv4 hosts 114 communicate, they broadcast ARP packets on the network on a regular 115 basis, and this is not disastrous. The approximate amount of 116 multicast traffic generated by hosts making conventional use of 117 Multicast DNS is anticipated to be roughly the same order of 118 magnitude as the amount of broadcast ARP traffic those hosts already 119 generate. 121 New applications making new use of Multicast DNS capabilities for 122 unconventional purposes may generate more traffic. If some of those 123 new applications are "chatty", then work will be needed to help them 124 become less chatty. When performing any analysis, it is important to 125 make a distinction between the application behavior and the 126 underlying protocol behavior. If a chatty application uses UDP, that 127 doesn't mean that UDP is chatty, or that IP is chatty, or that 128 Ethernet is chatty. What it means is that the application is chatty. 129 The same applies to any future applications that may decide to layer 130 increasing portions of their functionality over Multicast DNS. 132 2. Conventions and Terminology Used in this Document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in "Key words for use in 137 RFCs to Indicate Requirement Levels" [RFC 2119]. 139 This document uses the term "host name" in the strict sense to mean a 140 fully qualified domain name that has an address record. It does not 141 use the term "host name" in the commonly used but incorrect sense to 142 mean just the first DNS label of a host's fully qualified domain 143 name. 145 A DNS (or mDNS) packet contains an IP TTL in the IP header, which 146 is effectively a hop-count limit for the packet, to guard against 147 routing loops. Each Resource Record also contains a TTL, which is 148 the number of seconds for which the Resource Record may be cached. 150 In any place where there may be potential confusion between these two 151 types of TTL, the term "IP TTL" is used to refer to the IP header TTL 152 (hop limit), and the term "RR TTL" is used to refer to the Resource 153 Record TTL (cache lifetime). 155 When this document uses the term "Multicast DNS", it should be taken 156 to mean: Clients performing DNS-like queries for DNS-like resource 157 records by sending DNS-like UDP query and response packets over IP 158 Multicast to UDP port 5353." 160 3. Multicast DNS Names 162 This document proposes that the DNS top-level domain ".local." be 163 designated a special domain with special semantics, namely that any 164 fully-qualified name ending in ".local." is link-local, and names 165 within this domain are meaningful only on the link where they 166 originate. This is analogous to IPv4 addresses in the 169.254/16 167 prefix, which are link-local and meaningful only on the link where 168 they originate. 170 Any DNS query for a name ending with ".local." MUST be sent 171 to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent 172 FF02::FB). 174 It is unimportant whether a name ending with ".local." occurred 175 because the user explicitly typed in a fully qualified domain name 176 ending in ".local.", or because the user entered an unqualified 177 domain name and the host software appended the suffix ".local." 178 because that suffix appears in the user's search list. The ".local." 179 suffix could appear in the search list because the user manually 180 configured it, or because it was received in a DHCP option, or via 181 any other valid mechanism for configuring the DNS search list. In 182 this respect the ".local." suffix is treated no differently to any 183 other search domain that might appear in the DNS search list. 185 DNS queries for names that do not end with ".local." MAY be sent to 186 the mDNS multicast address, if no other conventional DNS server is 187 available. This can allow hosts on the same link to continue 188 communicating using each other's globally unique DNS names during 189 network outages which disrupt communication with the greater 190 Internet. When resolving global names via local multicast, it is even 191 more important to use DNSSEC or other security mechanisms to ensure 192 that the response is trustworthy. Resolving global names via local 193 multicast is a contentious issue, and this document does not discuss 194 it in detail, instead concentrating on the issue of resolving local 195 names using DNS packets sent to a multicast address. 197 A host which belongs to an organization or individual who has control 198 over some portion of the DNS namespace can be assigned a globally 199 unique name within that portion of the DNS namespace, for example, 200 "cheshire.apple.com." For those of us who have this luxury, this 201 works very well. However, the majority of home customers do not have 202 easy access to any portion of the global DNS namespace within which 203 they have the authority to create names as they wish. This leaves the 204 majority of home computers effectively anonymous for practical 205 purposes. 207 To remedy this problem, this document allows any computer user to 208 elect to give their computers link-local Multicast DNS host names of 209 the form: "single-dns-label.local." For example, my Titanium 210 PowerBook laptop computer answers to the name "sctibook.local." Any 211 computer user is granted the authority to name their computer this 212 way, providing that the chosen host name is not already in use on 213 that link. Having named their computer this way, the user has the 214 authority to continue using that name until such time as a name 215 conflict occurs on the link which is not resolved in the user's 216 favour. If this happens, the computer (or its human user) SHOULD 217 cease using the name, and may choose to attempt to allocate a new 218 unique name for use on that link. Like law suits over global DNS 219 names, these conflicts are expected to be relatively rare for people 220 who choose reasonably imaginative names, but it is still important 221 to have a mechanism in place to handle them when they happen. 223 The point made in the previous paragraph is very important and bears 224 repeating. It is easy for those of us in the IETF community who run 225 our own name servers at home to forget that the majority of computer 226 users do not run their own name server and have no easy way to create 227 their own host names. When these users wish to transfer files between 228 two laptop computers, they are frequently reduced to typing in 229 dotted-decimal IP addresses because they simply have no other way for 230 one host to refer to the other by name. This is a sorry state of 231 affairs. What is worse, most users don't even bother trying to use 232 dotted-decimal IP addresses. Most users still move data between 233 machines by copying it onto a floppy disk or similar removable media. 235 In a world of gigabit Ethernet and ubiquitous wireless networking it 236 is a sad indictment of the networking community that the preferred 237 communication medium for most computer users is still the floppy 238 disk. 240 Allowing ad-hoc allocation of single-label names in a single flat 241 ".local." namespace may seem to invite chaos. However, operational 242 experience with AppleTalk NBP names, which on any given link are also 243 effectively single-label names in a flat namespace, shows that in 244 practice name collisions happen extremely rarely and are not a 245 problem. Groups of computer users from disparate organizations bring 246 Macintosh laptop computers to events such as IETF Meetings, the Mac 247 Hack conference, the Apple World Wide Developer Conference, etc., and 248 complaints at these events about users suffering conflicts and being 249 forced to rename their machines have never been an issue. 251 Enforcing uniqueness of host names (i.e. the names of DNS address 252 records mapping names to IP addresses) is probably desirable in the 253 common case, but this document does not mandate that. It is 254 permissible for a collection of coordinated hosts to agree to 255 maintain multiple DNS address records with the same name, possibly 256 for load balancing or fault-tolerance reasons. This document does not 257 take a position on whether that is sensible. It is important that 258 both modes of operation are supported. The Multicast DNS protocol 259 allows hosts to verify and maintain unique names for resource records 260 where that behaviour is desired, and it also allows hosts to maintain 261 multiple resource records with a single shared name where that 262 behaviour is desired. This consideration applies to all resource 263 records, not just address records (host names). In summary: It is 264 required that the protocol have the ability to detect and handle name 265 conflicts. It is not required that the user should use that ability 266 in every case. 268 3.1 Standards Body 270 Note that this use of the ".local." suffix falls under IETF 271 jurisdiction, not ICANN jurisdiction. DNS is an IETF network 272 protocol, governed by protocol rules defined by the IETF. These IETF 273 protocol rules dictate character set, maximum name length, packet 274 format, etc. ICANN determines additional rules that apply when the 275 IETF's DNS protocol is used on the public Internet. In contrast, 276 private uses of the DNS protocol on isolated private networks are not 277 governed by ICANN. Since this proposed change is a change to the core 278 DNS protocol rules, it affects everyone, not just those machines 279 using the ICANN-governed Internet. Hence this change falls into the 280 category of an IETF protocol rule, not an ICANN usage rule. 282 3.2 Private DNS Namespaces 284 Note also that the special treatment of names ending in ".local." has 285 been implemented in Macintosh computers since the days of Mac OS 9, 286 and continues today in Mac OS X. There are also implementations for 287 Linux and other platforms [dotlocal]. Operators setting up private 288 internal networks ("intranets") are advised that their lives may be 289 easier if they avoid using the suffix ".local." in names in their 290 private internal DNS server. Alternative possibilities include: 292 .intranet 293 .internal 294 .private 295 .corp 296 .home 298 Another alternative naming scheme, advocated by Professor D. J. 299 Bernstein, is to use a numerical suffix, such as ".6." [djbdl]. 301 3.3 Maximum Multicast DNS Name Length 303 RFC 1034 says: 305 "the total number of octets that represent a domain name (i.e., 306 the sum of all label octets and label lengths) is limited to 255." 308 This text implies that the final root label at the end of every name 309 is included in this count (a name can't be represented without it), 310 but the text does not explicitly state that. Implementations of 311 Multicast DNS MUST include the label length byte of the final root 312 label at the end of every name when enforcing the rule that no name 313 may be longer than 255 bytes. For example, the length of the name 314 "apple.com." is considered to be 11, which is the number of bytes it 315 takes to represent that name in a packet: 317 ------------------------------------------------------ 318 | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 | 319 ------------------------------------------------------ 321 4. IP TTL Checks 323 A host sending Multicast DNS queries to a link-local destination 324 address (including the 224.0.0.251 link-local multicast address) MUST 325 verify that the IP TTL in response packets is 255, and silently 326 discard any response packets where the IP TTL is not 255. Without 327 this check, it could be possible for remote rogue hosts to send spoof 328 answer packets (perhaps unicast to the victim host) which the 329 receiving machine could misinterpret as having originated on the 330 local link. 332 There has been some discussion that many current network programming 333 APIs do not provide any indication of the IP TTL on received packets. 334 This is unfortunate, and should be fixed for hosts that want to be 335 able to guard against spoof packets arriving from off-link. 337 5. Reverse Address Mapping 339 Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also 340 defined to be link-local. 342 Any DNS query for a name ending with "254.169.in-addr.arpa." MUST be 343 sent to the mDNS multicast address 224.0.0.251. Since names under 344 this domain correspond to IPv4 link-local addresses, it is logical 345 that the local link is the best place to find information pertaining 346 to those names. 348 Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa." 349 MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB. 351 6. Querying 353 There are three kinds of Multicast DNS Queries, one-shot queries of 354 the kind made by today's conventional DNS clients, one-shot queries 355 accumulating multiple responses made by multicast-aware DNS clients, 356 and continuous ongoing Multicast DNS Queries used by IP network 357 browser software. 359 A Multicast DNS Responder that is offering records that are intended 360 to be unique on the local link MUST also implement a Multicast DNS 361 Querier so that it can first verify the uniqueness of those records 362 before it begins answering queries for them. 364 6.1 One-Shot Queries 366 An unsophisticated DNS client may simply send its DNS queries 367 blindly to the 224.0.0.251 multicast address, without necessarily 368 even being aware what a multicast address is. 370 Such an unsophisticated DNS client may not get ideal behaviour. Such 371 a client may simply take the first response it receives and fail to 372 wait to see if there are more, but in many instances this may not be 373 a serious problem. If a user types "http://stu.local." into their Web 374 browser and gets to see the page they were hoping for, then the 375 protocol has met the user's needs in this case. 377 6.2 One-Shot Queries, Accumulating Multiple Responses 379 A more sophisticated DNS client should understand that Multicast DNS 380 is not exactly the same as unicast DNS, and should modify its 381 behaviour in some simple ways. 383 As described above, there are some cases, such as looking up the 384 address associated with a unique host name, where a single response 385 is sufficient, and moreover may be all that is expected. However, 386 there are other DNS queries where more than one response is 387 possible, and for these queries a more sophisticated Multicast DNS 388 client should include the ability to wait for an appropriate period 389 of time to collect multiple responses. 391 A naive DNS client retransmits its query only so long as it has 392 received no response. A more sophisticated Multicast DNS client is 393 aware that having received one response is not necessarily an 394 indication that it might not receive others, and has the ability to 395 retransmit its query an appropriate number of times at appropriate 396 intervals until it is satisfied with the collection of responses it 397 has gathered. 399 A more sophisticated Multicast DNS client that is retransmitting a 400 query for which it has already received some responses, MUST 401 implement Known Answer Suppression, as described below in Section 402 7.1. This indicates to responders who have already replied that their 403 responses have been received, and they don't need to send them again 404 in response to this repeated query. 406 A Multicast DNS Querier MAY place more than one question into the 407 Question Section of a Multicast DNS Query. 409 6.3 Continuous Querying 411 In One-Shot Queries, with either a single or multiple responses, the 412 underlying assumption is that the transaction begins when the 413 application issues a query, and ends when all the desired responses 414 have been received. There is another type of operation which is more 415 akin to continuous monitoring. 417 Macintosh users are accustomed to opening the "Chooser" window, 418 selecting a desired printer, and then closing the Chooser window. 419 However, when the desired printer does not appear in the list, the 420 user will typically leave the "Chooser" window open while they go and 421 check to verify that the printer is plugged in, powered on, connected 422 to the Ethernet, etc. While the user jiggles the wires, hits the 423 Ethernet hub, and so forth, they keep an eye on the Chooser window, 424 and when the printer name appears, they know they have fixed whatever 425 the problem was. This can be a useful and intuitive troubleshooting 426 technique, but a user who goes home for the weekend leaving the 427 Chooser window open places a non-trivial burden on the network. 429 It is important that an IP network browser window displaying 430 live information from the network using Multicast DNS, if left 431 running for an extended period of time, should generate significantly 432 less multicast traffic on the network than the old AppleTalk Chooser. 434 A Multicast DNS Querier asking the same question repeatedly for an 435 indefinite period of time MUST implement Known Answer Suppression, as 436 described below in Section 7.1. 438 7. Duplicate Suppression 440 A variety of techniques are used to reduce the amount of redundant 441 traffic on the network. 443 7.1 Known Answer Suppression 445 When a Multicast DNS Querier sends a query to which it already knows 446 some answers, it populates the Answer Section of the DNS message with 447 those cached resource records whose remaining TTL values indicate 448 that they will remain valid for at least the time anticipated to send 449 this DNS query, and the next, and the one after that. For example, if 450 the query DNS Querier is planning to wait four seconds after this 451 query before sending the next, and then eight seconds after that, 452 then only resource records with TTL values greater than twelve 453 seconds should be included in the answer section. This is to ensure 454 that when a resource record's TTL is close to expiration, the 455 Multicast DNS Querier has *two* chances to refresh it before the 456 cached record expires and has to be removed from the list. 458 A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if 459 the answer it would give is already included in the Answer Section 460 with an RR TTL at least half the correct value. If the RR TTL of the 461 answer as given in the Answer Section is less than half of the real 462 RR TTL as known by the Multicast DNS Responder, the responder MUST 463 send an answer so as to update the Querier's cache before the record 464 becomes in danger of expiration. 466 A Multicast DNS Querier MUST NOT cache resource records observed in 467 the Answer Section of other Multicast DNS Queries. The Answer 468 Section of Multicast DNS Queries is not authoritative. By placing 469 information in the Answer Section of a Multicast DNS Query the 470 querier is stating that it *believes* the information to be true. 471 It is not asserting that the information *is* true. Some of those 472 records may have come from other hosts that are no longer on the 473 network. Propagating that stale information to other Multicast DNS 474 Queriers on the network would not be helpful. 476 7.2 Multi-Packet Known Answer Suppression 478 Sometimes a Multicast DNS Querier will already have too many answers 479 to fit in the Known Answer section of its query packets. In this 480 case, it should issue a Multicast DNS Query containing a question and 481 as many Known Answer records as will fit. It should then set the TC 482 (Truncated) bit in the header before sending the Query. It should 483 then immediately follow the packet with another query containing no 484 questions, and as many more Known Answer records as will fit. If 485 there are still too many records remaining to fit in the packet, it 486 again sets the TC bit and continues until all the Known Answer 487 records have been sent. 489 A Multicast DNS Responder seeing a Multicast DNS Query with the TC 490 bit set defers its response for a time period randomly selected in 491 the interval 20-120ms. This gives the Multicast DNS Querier time to 492 send additional Known Answer packets before the Responder responds. 493 If the Responder sees any of its answers listed in the Known Answer 494 lists of subsequent packets from the querying host, it should delete 495 that answer from the list of answers it is planning to give, provided 496 that no other host on the network is also waiting to receive the same 497 answer record. 499 7.3 Duplicate Question Suppression 501 If a host is planning to send a query, and it sees another host on 502 the network send a query containing the same question, and the Known 503 Answer section of that query does not contain any records which this 504 host would not also put in its own Known Answer section, then this 505 host should treat its own query as having been sent. When multiple 506 clients on the network are querying for the same resource records, 507 there is no need for them to all be repeatedly asking the same 508 question. 510 7.4 Duplicate Answer Suppression 512 If a host is planning to send an answer, and it sees another host on 513 the network send a response packet containing the same answer record, 514 and the TTL in that record is not less than the TTL this host would 515 have given, then this host should treat its own answer as having been 516 sent. When multiple responders on the network have the same data, 517 there is no need for all of them to respond. 519 The feature is particularly useful when multiple Sleep Proxy Servers 520 are deployed (see Section 16. "Multicast DNS and Power Management"). 521 In the future it is possible that every general-purpose OS (Mac, 522 Windows, Linux, etc.) will implement Sleep Proxy Service as a matter 523 of course. In this case there could be a large number of Sleep Proxy 524 Servers on any given network, which is good for reliability and 525 fault-tolerance, but would be bad for the network if every Sleep 526 Proxy Server were to answer every query. 528 8. Responding 530 A Multicast DNS Responder MUST only respond when it has a positive 531 non-null response to send. Error responses must never be sent. The 532 non-existence of any name in a Multicast DNS Domain is ascertained by 533 the failure of any machine to respond to the Multicast DNS query, not 534 by NXDOMAIN errors. 536 Multicast DNS Responses SHOULD NOT contain any questions in the 537 Question Section. Any questions in the Question Section of a received 538 Multicast DNS Response MUST be silently ignored. Multicast DNS 539 Queriers receiving Multicast DNS Responses do not care what question 540 elicited the response; they care only that the information in the 541 response is true and accurate. 543 A Multicast DNS Responder on Ethernet [IEEE802] and similar shared 544 multiple access networks SHOULD delay its responses by a random 545 amount of time selected with uniform random distribution in the range 546 20-120ms. If multiple Multicast DNS Responders were all to respond 547 immediately to a particular query, a collision would be virtually 548 guaranteed. By imposing a small random delay, the number of 549 collisions is dramatically reduced. 120ms is a short enough time that 550 it is almost imperceptible to a human user, but long enough to 551 significantly reduce the risk of Ethernet collisions. On a full-sized 552 Ethernet using the maximum cable lengths allowed and the maximum 553 number of repeaters allowed, an Ethernet frame is vulnerable to 554 collisions during the transmission of its first 256 bits. On 10Mb/s 555 Ethernet, this equates to a vulnerable time window of 25.6us. 557 In the case where a Multicast DNS Responder has good reason to 558 believe that it will be the only responder on the link with a 559 positive non-null response, it SHOULD NOT impose the random delay 560 before replying, and SHOULD normally generate its reply within 10ms. 561 To do this safely, it MUST have previously verified that the 562 requested name, type and class in the DNS query are unique on this 563 link. This is appropriate for things like looking up the address 564 record for a particular host name, when the host name has been 565 previously verified unique. This is *not* appropriate for things like 566 looking up PTR records used for DNS Service Discovery [DNS-SD], where 567 a large number of responses may be anticipated. 569 Multicast DNS Responses MUST be sent to UDP port 5353 (the well-known 570 port assigned to mDNS) on the 224.0.0.251 multicast address (or its 571 IPv6 equivalent). Operating in a Zeroconf environment requires 572 constant vigilance. Just because a name has been previously verified 573 unique does not mean it will continue to be so indefinitely. By 574 allowing all Multicast DNS Responders to constantly monitor their 575 peers' responses, conflicts arising out of network topology changes 576 can be promptly detected and resolved. Sending all responses by 577 multicast also facilitates opportunistic caching by other hosts on 578 the network. 580 8.1 Legacy Unicast Replies 582 If the source UDP port in a received Multicast DNS Query is not port 583 5353, this indicates that the client originating the query is a 584 simple client that does not fully implement all of Multicast DNS. In 585 this case, the Multicast DNS Responder MUST send a UDP response 586 directly back to the client, via unicast, to the query packet's 587 source IP address and port. This unicast response MUST be a 588 conventional unicast response as would be generated by a conventional 589 unicast DNS server; for example, it must repeat the query ID and the 590 question given in the query packet. 592 In the case of Multicast DNS resource records with TTLs measured in 593 minutes, or hours, or longer, the TTL given in the unicast reply 594 SHOULD be significantly lower, typically ten seconds. This is because 595 Multicast DNS Responders that fully participate in the protocol use 596 the cache coherency mechanisms described in Section 13 to update and 597 invalidate stale data. Were unicast replies sent to legacy clients to 598 use the same high TTLs, these legacy clients, which do not implement 599 these cache coherency mechanisms, could retain stale cached resource 600 record data long after it is no longer valid. 602 Having sent this unicast response, if the Responder has not sent this 603 record in any multicast response recently, it SHOULD schedule the 604 record to be sent via multicast too, to facilitate passive conflict 605 detection. "Recently" means "if the time since the record was last 606 sent via multicast is less than half of the record's TTL". 608 8.2 Multi-Question Queries 610 Multicast DNS Responders MUST correctly handle DNS query packets 611 containing more than one question, by answering any or all of the 612 questions to which they have answers. Any answers generated 613 in response to query packets containing more than one question 614 MUST be randomly delayed in the range 20-120ms, as described above. 616 8.3 Reply Aggregation 618 Having delayed one or more multicast responses by 20-120ms as 619 described above in Section 8 "Responding", a Multicast DNS Responder 620 SHOULD, for the sake of network efficiency, aggregate as many of its 621 pending responses as possible into a single Multicast DNS reply 622 packet. 624 9. Probing and Announcing on Startup 626 Whenever a Multicast DNS Responder starts up, wakes up from sleep, 627 receives an indication of an Ethernet "Link Change" event, or has any 628 other reason to believe that its network connectivity may have 629 changed in some relevant way, it MUST perform two startup steps. 631 9.1 Probing 633 The first startup step is that for all those resource records that a 634 Multicast DNS Responder desires to be unique on the local link, it 635 MUST send a Multicast DNS Query asking for those resource records, to 636 see if any of them are already in use. The primary example of this is 637 its address record which maps its unique host name to its unique IP 638 address. All Probe Queries SHOULD be done using the desired resource 639 record name and query type T_ANY (255), to elicit answers for all 640 types of records with that name. This allows a single question to be 641 used in place of several questions, which is more efficient on the 642 network. It also allows a host to verify exclusive ownership of a 643 name, which is desirable in most cases. It would be confusing, for 644 example, if one host owned the "A" record for "myhost.local.", but a 645 different host owned the HINFO record for that name. 647 The ability to place more than one question in a Multicast DNS Query 648 is useful here, because it can allow a host to use a single packet 649 for all of its resource records instead of needing a separate packet 650 for each. For example, a host can simultaneously probe for uniqueness 651 of its "A" record and all its SRV records [DNS-SD] in the same query 652 packet. 654 250ms after the first query it should send a second, then 250ms after 655 that a third. If, after a total of 750ms, no conflicting Multicast 656 DNS responses have been received, the host may move to the second 657 step. 659 If any conflicting Multicast DNS responses are received, then the 660 probing host MUST defer to the existing host, and must choose new 661 names for some or all of its resource records as appropriate, to 662 avoid conflict with pre-existing hosts on the network. 664 If ten failures occur within any ten-second period, then the host 665 MUST wait at least five seconds before each successive additional 666 probe attempt. This is to help ensure that in the event of software 667 bugs or other unanticipated problems, errant hosts do not flood the 668 network with a continuous stream of multicast traffic. For very 669 simple devices, a valid alternative way to comply with this 670 requirement is to always wait five seconds after any failed probe 671 attempt. 673 9.2 Simultaneous Probe Tie-Breaking 675 The astute reader will observe that there is a race condition 676 inherent in the previous description. If two hosts are probing for 677 the same name simultaneously, neither will receive any response to 678 the probe, and the hosts could incorrectly conclude that they may 679 both proceed to use the name. To break this symmetry, each host 680 populates the Authority Section of its queries with records giving 681 the rdata that it would be proposing to use, should its probing be 682 successful. The Authority Section is being used here in a way 683 analogous to the Update section of a DNS Update packet [RFC 2136]. 685 When a host that is probing for a record sees another host issue a 686 query for the same record, it consults the Authority Section of that 687 query. If it finds any resource record there which answers the query, 688 then it compares the rdata in that resource record with its own 689 tentative rdata. The lexicographically later rdata wins. This means 690 that if the host finds that its own rdata is lexicographically later, 691 it simply ignores the other host's probe. If the host finds that its 692 own rdata is lexicographically earlier, then it treats this exactly 693 as if it had received a positive answer to its query, and concludes 694 that it may not use the desired name. 696 The determination of 'lexicographically later' is performed by raw 697 comparison of the binary content of the rdata without regard for 698 meaning or structure. In the case of resource records containing 699 rdata that is subject to name compression, the names must be 700 uncompressed before comparison. The details of how a particular name 701 is compressed is an artifact of how and where the record is written 702 into the DNS message; it is not an intrinsic property of the resource 703 record itself. The bytes of the raw uncompressed rdata are compared 704 in turn until a byte is found whose value is greater than that of its 705 counterpart (in which case the rdata whose byte has the greater value 706 is deemed lexicographically later) or one of the resource records 707 runs out of rdata (in which case the resource record which still has 708 remaining data first is deemed lexicographically later). 710 The following is an example of a conflict: 712 sctibook.local. A 196.254.50.100 713 sctibook.local. A 196.254.100.50 715 In this case 196.254.100.50 is lexicographically later, so it is 716 deemed the winner. 718 9.3 Announcing 720 The second startup step is that the Multicast DNS Responder MUST send 721 a gratuitous Multicast DNS Response containing, in the Answer 722 Section, all of its resource records. If there are too many resource 723 records to fit in a single packet, multiple packets should be used. 725 In the case of shared records (e.g. the PTR records used by DNS 726 Service Discovery [DNS-SD]) the records are simply placed as-is into 727 the answer section of the DNS Response. 729 In the case of records that have been verified to be unique in the 730 previous step, they are placed into the answer section of the DNS 731 Response with the most significant bit of the rrclass set to one. The 732 most significant bit of the rrclass is the mDNS "cache flush" bit and 733 is discussed in more detail below in Section 13.3 "Announcements to 734 Flush Outdated Cache Entries". 736 The Multicast DNS Responder MUST send at least two gratuitous 737 responses, one second apart. A Responder MAY send up to ten 738 gratuitous Responses, providing that the interval between gratuitous 739 responses doubles with every response sent. 741 Whenever a Multicast DNS Responder receives any Multicast DNS 742 response (gratuitous or otherwise) containing a conflicting resource 743 record, the conflict MUST be resolved as described below in "Conflict 744 Resolution". 746 A Multicast DNS Responder MUST NOT send announcements in the absence 747 of information that its network connectivity may have changed in some 748 relevant way. In particular, a Multicast DNS Responder MUST NOT send 749 regular periodic announcements as a matter of course. 751 10. Conflict Resolution 753 A conflict occurs when two resource records with the same name, type 754 and class have inconsistent rdata. What may be considered 755 inconsistent is context sensitive, except that resource records with 756 identical rdata are never considered inconsistent, even if they 757 originate from different hosts. A common example of a resource record 758 type that is intended to be unique, not shared between hosts, is the 759 address record that maps a host's name to its IP address. Should a 760 host witness another host announce an address record with the same 761 name but a different IP address, then that is considered 762 inconsistent, and that address record is considered to be in 763 conflict. 765 Whenever a Multicast DNS Responder receives any Multicast DNS 766 response (gratuitous or otherwise) containing a conflicting resource 767 record, the Multicast DNS Responder MUST immediately reset that 768 record to probing state, and go through the startup steps described 769 above in Section 9. "Probing and Announcing on Startup". The 770 protocol used in the Probing phase will determine a winner and a 771 loser, and the loser must cease using the name, and reconfigure. 773 It is very important that any host that observes an apparent conflict 774 MUST take action. In the case of two hosts using the same host name, 775 where one has been configured to require a unique host name and the 776 other has not, the one that has not been configured to require a 777 unique host name will not perceive any conflict, and will not take 778 any action. By reverting to Probing state, the host that desires a 779 unique host name will go through the necessary steps to ensure that a 780 unique host is obtained. 782 The recommended course of action after probing and failing is as 783 follows: 785 o Programmatically change the resource record name in an attempt to 786 find a new name that is unique. This could be done by adding some 787 further identifying information (e.g. the model name of the 788 hardware) if it is not already present in the name, appending the 789 digit "2" to the name, or incrementing a number at the end of the 790 name if one is already present. 792 o Probe again, and repeat until a unique name is found. 794 o Record this newly chosen name in persistent storage so that the 795 device will use the same name the next time it is power-cycled. 797 o Display a message to the user or operator informing them of the 798 name change. For example: 800 The name "Bob's Music" is in use by another iTunes music 801 server on the network. Your music has been renamed to 802 "Bob's Music (G4 Cube)". If you want to change this name, 803 use [describe appropriate menu item or preference dialog]. 805 How the user or operator is informed depends on context. A desktop 806 computer with a screen might put up a dialog box. A headless server 807 in the closet may use whatever mechanism (email, SNMP trap, etc.) it 808 uses to inform the administrator of other error conditions. On the 809 other hand a headless server in the closet may not inform the user at 810 all -- if the user cares, they will notice the name has changed, and 811 connect to the server in the usual way (e.g. via Web Browser?) to 812 configure a new name. 814 The examples in this section focus on address records (i.e. host 815 names), but the same considerations apply to all resource records 816 where uniqueness (or maintenance of some other defined constraint) is 817 desired. 819 11. Special Characteristics of Multicast DNS Domains 821 Unlike conventional DNS names, names that end in ".local.", 822 "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local 823 significance. Conventional DNS seeks to provide a single unified 824 namespace, where a given DNS query yields the same answer no matter 825 where on the planet it is performed or to which recursive DNS server 826 the query is sent. (However, split views, firewalls, intranets and 827 the like have somewhat interfered with this goal of DNS representing 828 a single universal truth.) In contrast, each IP link has its own 829 private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa." 830 namespaces, and the answer to any query for a name within those 831 domains depends on where that query is asked. 833 Multicast DNS Domains are not delegated from their parent domain via 834 use of NS records. There are no NS records anywhere in Multicast DNS 835 Domains. Instead, all Multicast DNS Domains are delegated to the IP 836 addresses 224.0.0.251 and FF02::FB by virtue of the individual 837 organizations producing DNS client software deciding how to handle 838 those names. It would be extremely valuable for the industry if this 839 special handling were ratified and recorded by IANA, since otherwise 840 the special handling provided by each vendor is likely to be 841 inconsistent. 843 The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The 844 IPv6 name server for a Multicast DNS Domain is FF02::FB. These are 845 multicast addresses; therefore they identify not a single host but a 846 collection of hosts, working in cooperation to maintain some 847 reasonable facsimile of a competently managed DNS zone. Conceptually 848 a Multicast DNS Domain is a single DNS zone, however its server is 849 implemented as a distributed process running on a cluster of loosely 850 cooperating CPUs rather than as a single process running on a single 851 CPU. 853 No delegation is performed within Multicast DNS Domains. Because the 854 cluster of loosely coordinated CPUs is cooperating to administer a 855 single zone, delegation is neither necessary nor desirable. Just 856 because a particular host on the network may answer queries for a 857 particular record type with the name "example.local." does not imply 858 anything about whether that host will answer for the name 859 "child.example.local.", or indeed for other record types with the 860 name "example.local." 862 Multicast DNS Zones have no SOA record. A conventional DNS zone's 863 SOA record contains information such as the email address of the zone 864 administrator and the monotonically increasing serial number of the 865 last zone modification. There is no single human administrator for 866 any given Multicast DNS Zone, so there is no email address. Because 867 the hosts managing any given Multicast DNS Zone are only loosely 868 coordinated, there is no readily available monotonically increasing 869 serial number to determine whether or not the zone contents have 870 changed. A host holding part of the shared zone could crash or be 871 disconnected from the network at any time without informing the other 872 hosts. There is no reliable way to provide a zone serial number that 873 would, whenever such a crash or disconnection occurred, immediately 874 change to indicate that the contents of the shared zone had changed. 876 Zone transfers are not possible for any Multicast DNS Zone. 878 12. Multicast DNS for Service Discovery 880 This document does not describe using Multicast DNS for network 881 browsing or service discovery. However, the mechanisms this document 882 describes are compatible with (and support) the browsing and service 883 discovery mechanisms proposed in "DNS-Based Service Discovery" 884 [DNS-SD]. 886 This document places few limitations on what DNS record types may be 887 looked up using local multicast. One particular kind of Multicast DNS 888 query that might be useful is a query for the SRV record named 889 "_domain._udp.local.", yielding the port number and IP address of a 890 conventional DNS server willing to perform general recursive DNS 891 lookups. This could solve a particular problem facing the IPv6 892 community, which is that IPv6 is able to self-configure almost all of 893 the information it needs to operate [RFC 2462], except for the 894 address of the DNS server. Bringing in all of the mechanisms of DHCP 895 just for that one little additional piece of information is not an 896 attractive solution. Using DNS-format messages and DNS-format 897 resource records to find the address of the DNS server has an elegant 898 self-sufficiency about it. Any host that needs to know the address of 899 the DNS server must already have code to generate and parse DNS 900 packets, so using that same code and those same packets to find the 901 DNS server in the first place is a simple self-reliant solution that 902 avoids taking external dependencies on other protocols. 904 13. Resource Record TTL Values and Cache Coherency 906 The recommended TTL value for Multicast DNS resource records is 907 120 minutes. 909 A client with an active outstanding query will issue a query packet 910 when one or more of the resource record(s) in its cache is (are) 911 half-way to expiry. If the TTL on those records is 120 minutes, this 912 ongoing cache maintenance process yields a steady-state query rate of 913 one query per hour. 915 Any distributed cache needs a cache coherency protocol. If Multicast 916 DNS resource records follow the recommendation and have a TTL of 120 917 minutes, that means that stale data could persist in the system for 918 up to two hours. Making the default TTL significantly lower would 919 reduce the lifetime of stale data, but would produce too much extra 920 traffic on the network. Various techniques are available to minimize 921 the impact of such stale data. 923 13.1 Cooperating Multicast DNS Responders 925 If a Multicast DNS Responder ("A") observes some other Multicast DNS 926 Responder ("B") send a Multicast DNS Response packet containing a 927 resource record with the same name type and class as one of A's 928 resource records, but different rdata, then: 930 o If A's resource record is intended to be a shared resource record, 931 then this is no conflict, and no action is required. 933 o If A's resource record is intended to be a unique resource record 934 then this is a conflict and MUST be handled as described in Section 935 10 "Conflict Resolution". 937 If a Multicast DNS Responder ("A") observes some other Multicast DNS 938 Responder ("B") send a Multicast DNS Response packet containing a 939 resource record with the same name type and class as one of A's 940 resource records, and identical rdata, then: 942 o If the TTL of B's resource record given in the packet is at least 943 half the real TTL from A's point of view, then no action is 944 required. 946 o If the TTL of B's resource record given in the packet is less than 947 half the real TTL from A's point of view, then A MUST mark its 948 record to be announced via multicast. Clients receiving the record 949 from B would use the TTL given by B, and hence may delete the 950 record sooner than A expects. By sending its own multicast response 951 correcting the TTL, A ensures that the record will be retained for 952 the desired time. 954 These rules allow multiple Multicast DNS Responders to offer the same 955 data on the network (perhaps for fault tolerance reasons) without 956 conflicting with each other. 958 13.2 Goodbye Packets 960 In the case where a host knows that certain resource record data is 961 about to become invalid (for example when the host is undergoing a 962 clean shutdown) the host sends a gratuitous announcement mDNS 963 response packet, giving the same resource record name, type, class 964 and rdata, but an RR TTL of zero. This has the effect of updating the 965 TTL stored in neighbouring hosts' cache entries to zero, causing that 966 cache entry to be promptly deleted. 968 Clients receiving a Multicast DNS Response with a TTL of zero should 969 not immediately delete the record from the cache, but instead record 970 a TTL of 1 and then delete the record one second later. In the case 971 of multiple Multicast DNS Responders on the network described in 972 Section 13.1 above, if one of the Responders shuts down and 973 incorrectly sends goodbye packets for its records, it gives the other 974 cooperating Responders one second to send out their own response to 975 "rescue" the records before they expire and are deleted. 977 13.3 Announcements to Flush Outdated Cache Entries 979 Whenever a host has a resource record with potentially new data (e.g. 980 after rebooting, waking from sleep, connecting to a new network link, 981 changing IP address, etc.), the host MUST send a series of gratuitous 982 announcements to update cache entries in its neighbour hosts. In 983 these gratuitous announcements, if the record is one that is intended 984 to be unique, the host sets the most significant bit of the rrclass 985 field of the resource record. This bit, the "cache flush" bit, tells 986 neighbouring hosts that this is not a shared record type. Instead of 987 merging this new record additively into the cache in addition to any 988 previous records with the same name, type and class, all old records 989 with that name, type and class are summarily declared invalid and 990 immediately flushed from the cache. 992 The semantics of the cache flush bit are as follows: Normally when a 993 resource record appears in the answer section of the DNS Response, it 994 means, "This is an assertion that this information is true." When a 995 resource record appears in the answer section of the DNS Response 996 with the "cache flush" bit set, it means, "This is an assertion that 997 this information is the truth and the whole truth, and anything you 998 may have heard more than a second ago regarding records of this 999 name/type/class is no longer valid". 1001 To accommodate the case where the set of records from one host 1002 constituting a single unique RRSet is too large to fit in a single 1003 packet, only cache records that are more than one second old are 1004 flushed. This allows the announcing host to generate a quick burst of 1005 packets back-to-back on the wire containing all the members 1006 of the RRSet. The cache flush bit is only set on the last member 1007 of the RRSet in the last packet of the burst. On receiving this 1008 record with the cache flush bit set, the recipients then flush all 1009 records that were received more than one second ago, leaving only 1010 the current RRSet remaining in the cache. 1012 Any time a host sends a response packet containing some but not 1013 all members of an RRSet, it MUST NOT set the cache flush bit on any 1014 of those records. 1016 These rules apply regardless of *why* the response packet is being 1017 generated. They apply to startup announcements as described in 1018 Section 9.3, and to responses generated as a result of receiving 1019 query packets. 1021 The "cache flush" bit is only set in Multicast DNS responses sent via 1022 multicast. The "cache flush" bit MUST NOT be set in any resource 1023 records in a response packet sent via unicast to any host. 1025 The "cache flush" bit MUST NOT be set in any resource records in the 1026 known-answer list of any query packet. 1028 The "cache flush" bit MUST NOT ever be set in any shared resource 1029 record. To do so would cause all the other shared versions of this 1030 resource record with different rdata from different Responders to be 1031 immediately deleted from all the caches on the network. 1033 Note that the "cache flush" bit is NOT part of the resource record 1034 class. The "cache flush" bit is the most significant bit of the 1035 second 16-bit word of a resource record in an mDNS packet (the field 1036 conventionally referred to as the rrclass field), and the actual 1037 resource record class is the least-significant fifteen bits of this 1038 field. There is no mDNS resource record class 0x8001. The value 1039 0x8001 in the rrclass field of a resource record in an mDNS response 1040 packet indicates a resource record with class 1, with the "cache 1041 flush" bit set. When receiving a resource record with the "cache 1042 flush" bit set, implementations should take care to mask off that bit 1043 before storing the resource record in memory. 1045 13.4 Cache Flush on Topology change 1047 If the hardware on a given host is able to indicate physical changes 1048 of connectivity, then when the hardware indicates such a change, the 1049 host should take this information into account in its mDNS cache 1050 management strategy. For example, a host may choose to immediately 1051 flush all cache records received on a particular interface when that 1052 cable is disconnected. Alternatively, a host may choose to adjust the 1053 remaining TTL on all those records to a few seconds so that if the 1054 cable is not reconnected quickly, those records will expire from the 1055 cache. 1057 Likewise, when a host reboots, or wakes from sleep, or undergoes some 1058 other similar discontinuous state change, the cache management 1059 strategy should take that information into account. 1061 13.5 Cache Flush on Failure Indication 1063 Sometimes a cache record can be determined to be stale when a client 1064 attempts to use the rdata it contains, and finds that rdata to be 1065 incorrect. 1067 For example, the rdata in an address record can be determined to be 1068 incorrect if attempts to contact that host fail, either because 1069 ARP/ND requests for that address go unanswered (for an address on a 1070 local subnet) or because a router returns an ICMP "Host Unreachable" 1071 error (for an address on a remote subnet). 1073 The rdata in an SRV record can be determined to be incorrect if 1074 attempts to communicate with the indicated service at the host and 1075 port number indicated are not successful. 1077 The rdata in a DNS-SD PTR record can be determined to be incorrect if 1078 attempts to look up the SRV record it references are not successful. 1080 In any such case, the software implementing the mDNS resource record 1081 cache should provide a mechanism so that clients detecting stale 1082 rdata can inform the cache and have that data flushed. 1084 The end result of this is that if a printer suffers a sudden power 1085 failure or other abrupt disconnection from the network, its name may 1086 continue to appear in DNS-SD browser lists displayed on users' 1087 screens. Eventually that entry will expire from the cache naturally, 1088 but if a user tries to access the printer before that happens, the 1089 failure to successfully contact the printer will trigger the more 1090 hasty demise of its cache entries. This is a sensible trade-off 1091 between good user-experience and good network efficiency. If we were 1092 to insist that printers should disappear from the printer list within 1093 30 seconds of becoming unavailable, for all failure modes, the only 1094 way to achieve this would be for the client to poll the printer at 1095 least every 30 seconds, or for the printer to announce its presence 1096 at least every 30 seconds, both of which would be an unreasonable 1097 burden on most networks. 1099 14. Enabling and Disabling Multicast DNS 1101 The option to fail-over to Multicast DNS for names not ending in 1102 ".local." SHOULD be a user-configured option, and SHOULD 1103 be disabled by default because of the possible security issues 1104 related to unintended local resolution of apparently global names. 1106 The option to lookup unqualified (relative) names by appending 1107 ".local." (or not) is controlled by whether ".local." appears 1108 (or not) in the client's DNS search list. 1110 No special control is needed for enabling and disabling Multicast DNS 1111 for names explicitly ending with ".local." as entered by the user. 1112 The user doesn't need a way to disable Multicast DNS for names ending 1113 with ".local.", because if the user doesn't want to use Multicast 1114 DNS, they can achieve this by simply not using those names. If a user 1115 *does* enter a name ending in ".local.", then we can safely assume 1116 the user's intention was probably that it should work. Having user 1117 configuration options that can be (intentionally or unintentionally) 1118 set so that local names don't work is just one more way of 1119 frustrating the user's ability to perform the tasks they want, 1120 perpetuating the view that, "IP networking is too complicated to 1121 configure and too hard to use." This in turn perpetuates the 1122 continued use of protocols like AppleTalk. If we want to retire 1123 AppleTalk, NetBIOS, etc., we need to offer users equivalent IP 1124 functionality that they can rely on to, "always work, like 1125 AppleTalk." A little Multicast DNS traffic may be a burden on the 1126 network, but it is an insignificant burden compared to continued 1127 widespread use of AppleTalk. 1129 15. Considerations for Multiple Interfaces 1131 A host should defend its host name (FQDN) on all active interfaces on 1132 which it is answering Multicast DNS queries. 1134 In the event of a name conflict on *any* interface, a host should 1135 configure a new host name, if it wishes to maintain uniqueness of its 1136 host name. 1138 When answering a Multicast DNS query, a multi-homed host with a 1139 link-local address (or addresses) should take care to ensure that 1140 any address going out in a Multicast DNS response is valid for use 1141 on the interface on which the response is going out. 1143 Just as the same link-local IP address may validly be in use 1144 simultaneously on different links by different hosts, the same 1145 link-local host name may validly be in use simultaneously on 1146 different links, and this is not an error. A multi-homed host with 1147 connections to two different links may be able to communicate with 1148 two different hosts that are validly using the same name. While this 1149 kind of name duplication should be rare, it means that a host that 1150 wants to fully support this case needs network programming APIs that 1151 allow applications to specify on what interface to perform a 1152 link-local Multicast DNS query, and to discover on what interface a 1153 Multicast DNS response was received. 1155 16. Multicast DNS and Power Management 1157 Many modern network devices have the ability to go into a low-power 1158 mode where only a small part of the Ethernet hardware remains 1159 powered, and the device can be woken up by sending a specially 1160 formatted Ethernet frame which the device's power-management hardware 1161 recognizes. 1163 To make use of this in conjunction with Multicast DNS, the device 1164 first uses DNS-SD to determine if Sleep Proxy Service is available on 1165 the local network. In some networks there may be more than one piece 1166 of hardware implementing Sleep Proxy Service, for fault-tolerance 1167 reasons. 1169 If the device finds the network has Sleep Proxy Service, the device 1170 transmits two or more gratuitous mDNS announcements setting the TTL 1171 of its relevant resource records to zero, to delete them from 1172 neighbouring caches. The relevant resource records include address 1173 records and SRV records, and other resource records as may apply to a 1174 particular device. The device then communicates all of its remaining 1175 active records, plus the names, types and classes of the deleted 1176 records, to the Sleep Proxy Service(s), along with a copy of the 1177 specific "magic packet" required to wake the device up. 1179 When a Sleep Proxy Service sees an mDNS query for one of the 1180 device's active records (e.g. a DNS-SD PTR record), it answers on 1181 behalf of the device without waking it up. When a Sleep Proxy Service 1182 sees an mDNS query for one of the device's deleted resource 1183 records, it deduces that some client on the network needs to make an 1184 active connection to the device, and sends the specified "magic 1185 packet" to wake the device up. The device then wakes up, reactivates 1186 its deleted resource records, and re-announces them to the network. 1187 The client waiting to connect sees the announcements, learns the 1188 current IP address and port number of the desired service on the 1189 device, and proceeds to connect to it. 1191 The connecting client does not need to be aware of how Sleep Proxy 1192 Service works. Only devices that implement low power mode and wish to 1193 make use of Sleep Proxy Service need to be aware of how that protocol 1194 works. 1196 The full specification of mDNS / DNS-SD Sleep Proxy Service 1197 is described in another document [not yet published]. 1199 17. Multicast DNS Character Set 1201 Unicast DNS has been plagued by the lack of any support for non-US 1202 characters. Indeed, conventional DNS is usually limited to just 1203 letters, digits and hyphens, with no spaces or other punctuation. 1204 Attempts to remedy this have made slow progress because of the need 1205 to accommodate old buggy legacy implementations. 1207 Multicast DNS is a new protocol and doesn't (yet) have old buggy 1208 legacy implementations to constrain the design choices. Accordingly, 1209 it adopts the obvious simple solution: all names in Multicast DNS are 1210 encoded using UTF-8 [RFC 2279]. For names that are restricted to 1211 letters, digits and hyphens, the UTF-8 encoding is identical to the 1212 US-ASCII encoding, so this is entirely compatible with existing host 1213 names. For characters outside the US-ASCII range, UTF-8 encoding is 1214 used. 1216 Multicast DNS implementations MUST NOT use any other encodings apart 1217 from UTF-8 (US-ASCII being considered a compatible subset of UTF-8). 1219 This point bears repeating: There are various baroque representations 1220 of international text being proposed for Unicast DNS. None of these 1221 representations may be used in Multicast DNS packets. Any text being 1222 represented internally in some other representation MUST be converted 1223 to canonical UTF-8 before being placed in any Multicast DNS packet. 1225 The simple rules for case-insensitivity in Unicast DNS also apply in 1226 Multicast DNS; that is to say, in name comparisons, the lower-case 1227 letters "a" to "z" match their upper-case equivalents "A" to "Z". 1228 Hence, if a client issues a query for an address record with the name 1229 "stuartcheshire.local", then a responder having an address record 1230 with the name "StuartCheshire.local" should issue a response. 1232 No other automatic character equivalence is defined in Multicast DNS. 1233 For example, accented characters are not defined to be automatically 1234 equivalent to their unaccented counterparts. Where automatic 1235 equivalences are desired, this may be achieved through the use of 1236 programmatically-generated CNAME records. For example, if a responder 1237 has an address record for an accented name Y, and a client issues a 1238 query for a name X, where X is the same as Y with all the accents 1239 removed, then the responder may issue a response containing two 1240 resource records: A CNAME record "X CNAME Y", asserting that the 1241 requested name X (unaccented) is an alias for the real (accented) 1242 name Y, followed by the address record for Y. 1244 18. Multicast DNS Message Size 1246 RFC 1035 restricts DNS Messages carried by UDP to no more than 512 1247 bytes (not counting the IP or UDP headers). For UDP packets carried 1248 over the wide-area Internet in 1987, this was appropriate. For 1249 link-local multicast packets on today's networks, there is no reason 1250 to retain this restriction. Given that the packets are by definition 1251 link-local, there are no Path MTU issues to consider. 1253 Multicast DNS Messages carried by UDP may be up to the IP MTU of the 1254 physical interface, less the space required for the IP header (20 1255 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes). 1257 In the case of a single mDNS Resource Record which is too large to 1258 fit in a single MTU-sized multicast response packet, a Multicast DNS 1259 Responder SHOULD send the Resource Record alone, in a single IP 1260 datagram, sent using multiple IP fragments. Resource Records this 1261 large SHOULD be avoided, except in the very rare cases where they 1262 really are the appropriate solution to the problem at hand. 1263 Implementers should be aware that many simple devices do not 1264 re-assemble fragmented IP datagrams, so large Resource Records SHOULD 1265 only be used in specialized cases where the implementer knows that 1266 all receivers implement reassembly. 1268 A Multicast DNS packet larger than the interface MTU, which is sent 1269 using fragments, MUST NOT contain more than one Resource Record. 1271 Even when fragmentation is used, a Multicast DNS packet, including IP 1272 and UDP headers, MUST NOT exceed 9000 bytes. 1274 19. Multicast DNS Message Format 1276 This section describes specific restrictions on the allowable 1277 values for the header fields of a Multicast DNS message. 1279 19.1. ID (Query Identifier) 1281 Multicast DNS clients SHOULD listen for gratuitous responses 1282 issued by hosts booting up (or waking up from sleep or otherwise 1283 joining the network). Since these gratuitous responses may contain a 1284 useful answer to a question for which the client is currently 1285 awaiting an answer, Multicast DNS clients SHOULD examine all received 1286 Multicast DNS response messages for useful answers, without regard to 1287 the contents of the ID field or the question section. In multicast 1288 DNS, knowing which particular query message (if any) is responsible 1289 for eliciting a particular response message is less interesting than 1290 knowing whether the response message contains useful information. 1292 Multicast DNS clients MAY cache any or all Multicast DNS response 1293 messages they receive, for possible future use, providing of course 1294 that normal TTL aging is performed on these cashed resource records. 1296 In multicast query messages, the Query ID SHOULD be set to zero on 1297 transmission. 1299 In multicast responses, including gratuitous multicast responses, the 1300 Query ID MUST be set to zero on transmission, and MUST be ignored on 1301 reception. 1303 In unicast response messages generated specifically in response to a 1304 particular (unicast or multicast) query, the Query ID MUST match the 1305 ID from the query message. 1307 19.2. QR (Query/Response) Bit 1309 In query messages, MUST be zero. 1311 In response messages, MUST be one. 1313 19.3. OPCODE 1315 In both multicast query and multicast response messages, MUST be zero 1316 (only standard queries are currently supported over multicast, unless 1317 other queries are allowed by future IETF Standards Action). 1319 19.4. AA (Authoritative Answer) Bit 1321 In query messages, the Authoritative Answer bit MUST be zero on 1322 transmission, and MUST be ignored on reception. 1324 In response messages for Multicast Domains, the Authoritative Answer 1325 bit MUST be set to one (not setting this bit implies there's some 1326 other place where "better" information may be found) and MUST be 1327 ignored on reception. 1329 19.5. TC (Truncated) Bit 1331 In query messages, if the TC bit is set, it means that additional 1332 Known Answer records may be following shortly. A responder MAY choose 1333 to record this fact, and wait for those additional Known Answer 1334 records, before deciding whether to reply. If the TC bit is clear, 1335 it means that the querying host has no additional Known Answers. 1337 In multicast response messages, the TC bit MUST be zero on 1338 transmission, and MUST be ignored on reception. 1340 In legacy unicast response messages, the TC bit has the same meaning 1341 as in conventional unicast DNS: it means that the response was too 1342 large to fit in a single packet, so the client SHOULD re-issue its 1343 query using TCP in order to receive the larger response. 1345 19.6. RD (Recursion Desired) Bit 1347 In both multicast query and multicast response messages, the 1348 Recursion Desired bit SHOULD be zero on transmission, and MUST be 1349 ignored on reception. 1351 19.7. RA (Recursion Available) Bit 1353 In both multicast query and multicast response messages, the 1354 Recursion Available bit MUST be zero on transmission, and MUST be 1355 ignored on reception. 1357 19.8. Z (Zero) Bit 1359 In both query and response messages, the Zero bit MUST be zero on 1360 transmission, and MUST be ignored on reception. 1362 19.9. AD (Authentic Data) Bit [RFC 2535] 1364 In query messages the Authentic Data bit MUST be zero on 1365 transmission, and MUST be ignored on reception. 1367 In response messages, the Authentic Data bit MAY be set. Resolvers 1368 receiving response messages with the AD bit set MUST NOT trust the AD 1369 bit unless they trust the source of the message and either have a 1370 secure path to it or use DNS transaction security. 1372 19.10. CD (Checking Disabled) Bit [RFC 2535] 1374 In query messages, a resolver willing to do cryptography SHOULD set 1375 the Checking Disabled bit to permit it to impose its own policies. 1377 In response messages, the Checking Disabled bit MUST be zero on 1378 transmission, and MUST be ignored on reception. 1380 19.11. RCODE (Response Code) 1382 In both multicast query and multicast response messages, the Response 1383 Code MUST be zero on transmission. Multicast DNS messages received 1384 with non-zero Response Codes MUST be silently ignored. 1386 20. Choice of UDP Port Number 1388 Arguments were made for and against using Multicast on UDP port 53. 1389 The final decision was to use UDP port 5353. Some of the arguments 1390 for and against are given below. 1392 20.1 Arguments for using UDP port 53: 1394 * This is "just DNS", so it should be the same port. 1396 * There is less work to be done updating old clients to do simple 1397 mDNS queries. Only the destination address need be changed. 1398 In some cases, this can be achieved without any code changes, 1399 just by adding the address 224.0.0.251 to a configuration file. 1401 20.2 Arguments for using a different port (UDP port 5353): 1403 * This is not "just DNS". This is a DNS-like protocol, but different. 1405 * Changing client code to use a different port number is not hard. 1407 * Using the same port number makes it hard to run an mDNS Responder 1408 and a conventional unicast DNS server on the same machine. If a 1409 conventional unicast DNS server wishes to implement mDNS as well, 1410 it can still do that, by opening two sockets. Having two different 1411 port numbers is important to allow this flexibility. 1413 * Some VPN software hijacks all outgoing traffic to port 53 and 1414 redirects it to a special DNS server set up to serve those VPN 1415 clients while they are connected to the corporate network. It is 1416 questionable whether this is the right thing to do, but it is 1417 common, and redirecting link-local multicast DNS packets to a 1418 remote server rarely produces any useful results. It does mean, for 1419 example, that the user becomes unable to access their local network 1420 printer sitting on their desk right next to their computer. Using 1421 a different UDP port eliminates this particular problem. 1423 * On many operating systems, unprivileged clients may not send or 1424 receive packets on low-numbered ports. This means that any client 1425 sending or receiving mDNS packets on port 53 would have to run as 1426 "root", which is an undesirable security risk. Using a higher- 1427 numbered UDP port eliminates this particular problem. 1429 21. Summary of Differences Between Multicast DNS and Unicast DNS 1431 The value of Multicast DNS is that it shares, as much as possible, 1432 the familiar APIs, naming syntax, resource record types, etc., of 1433 Unicast DNS. There are of course necessary differences by virtue of 1434 it using Multicast, and by virtue of it operating in a community of 1435 cooperating peers, rather than a precisely defined authoritarian 1436 hierarchy controlled by a strict chain of formal delegations from the 1437 top. These differences are listed below: 1439 Multicast DNS... 1440 * uses multicast 1441 * uses UDP port 5353 instead of port 53 1442 * operates in well-defined parts of the DNS namespace 1443 * uses UTF-8, and only UTF-8, to encode resource record names 1444 * allows larger UDP packets 1445 * allows more than one question in a query packet 1446 * uses the Answer Section of a query to list Known Answers 1447 * uses the TC bit in a query to indicate additional Known Answers 1448 * uses the Authority Section of a query for probe tie-breaking 1449 * ignores the Query ID field (except for generating legacy responses) 1450 * doesn't require the question to be repeated in the response packet 1451 * uses gratuitous responses to announce new records to the peer group 1452 * defines a "cache flush" bit in the rrclass of responses 1453 * monitors queries to perform Duplicate Question Suppression 1454 * monitors responses to perform Duplicate Answer Suppression... 1455 * ... and Ongoing Conflict Detection 1456 * ... and Opportunistic Caching 1458 22. IPv6 Considerations 1460 An IPv4-only host and an IPv6-only host behave as "ships that pass in 1461 the night". Even if they are on the same Ethernet, neither is aware 1462 of the other's traffic. For this reason, each physical link may have 1463 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 1464 Since for practical purposes, a group of IPv4-only hosts and a group 1465 of IPv6-only hosts on the same Ethernet act as if they were on two 1466 entirely separate Ethernet segments, it is unsurprising that their 1467 use of the ".local." zone should occur exactly as it would if 1468 they really were on two entirely separate Ethernet segments. 1470 A dual-stack (v4/v6) host can participate in both ".local." 1471 zones, and should register its name(s) and perform its lookups both 1472 using IPv4 and IPv6. This enables it to reach, and be reached by, 1473 both IPv4-only and IPv6-only hosts. In effect this acts like a 1474 multi-homed host, with one connection to the logical "IPv4 Ethernet 1475 segment", and a connection to the logical "IPv6 Ethernet segment". 1477 22.1 IPv6 Multicast Addresses by Hashing 1479 Some discovery protocols use a range of multicast addresses, and 1480 determine the address to be used by a hash function of the name being 1481 sought. Queries are sent via multicast to the address as indicated by 1482 the hash function, and responses are returned to the querier via 1483 unicast. Particularly in IPv6, where multicast addresses are 1484 extremely plentiful, this approach is frequently advocated. 1486 There are some problems with this: 1488 * When a host has a large number of records with different names, the 1489 host may have to join a large number of multicast groups. This can 1490 place undue burden on the Ethernet hardware, which typically 1491 supports a limited number of multicast addresses efficiently. When 1492 this number is exceeded, the Ethernet hardware may have to resort 1493 to receiving all multicasts and passing them up to the host 1494 software for filtering, thereby defeating the point of using a 1495 multicast address range in the first place. 1497 * Multiple questions cannot be placed in one packet if they don't all 1498 hash to the same multicast address. 1500 * Duplicate Question Suppression doesn't work if queriers are not 1501 seeing each other's queries. 1503 * Duplicate Answer Suppression doesn't work if responders are not 1504 seeing each other's responses. 1506 * Opportunistic Caching doesn't work. 1508 * Ongoing Conflict Detection doesn't work. 1510 23. Security Considerations 1512 The algorithm for detecting and resolving name conflicts is, by its 1513 very nature, an algorithm that assumes cooperating participants. Its 1514 purpose is to allow a group of hosts to arrive at a mutually disjoint 1515 set of host names and other DNS resource record names, in the absence 1516 of any central authority to coordinate this or mediate disputes. In 1517 the absence of any higher authority to resolve disputes, the only 1518 alternative is that the participants must work together cooperatively 1519 to arrive at a resolution. 1521 In an environment where the participants are mutually antagonistic 1522 and unwilling to cooperate, other mechanisms are appropriate, like 1523 manually administered DNS. 1525 In an environment where there is a group of cooperating participants, 1526 but there may be other antagonistic participants on the same physical 1527 link, the cooperating participants need to use IPSEC signatures 1528 and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS 1529 messages from trusted participants (which they process as usual) from 1530 mDNS messages from untrusted participants (which they silently 1531 discard). 1533 When DNS queries for *global* DNS names are sent to the mDNS 1534 multicast address (during network outages which disrupt communication 1535 with the greater Internet) it is *especially* important to use 1536 DNSSEC, because the user may have the impression that he or she is 1537 communicating with some authentic host, when in fact he or she is 1538 really communicating with some local host that is merely masquerading 1539 as that name. This is less critical for names ending with ".local.", 1540 because the user should be aware that those names have only local 1541 significance and no global authority is implied. 1543 Most computer users neglect to type the trailing dot at the end of a 1544 fully qualified domain name, making it a relative domain name (e.g. 1545 "www.example.com"). In the event of network outage, attempts to 1546 positively resolve the name as entered will fail, resulting in 1547 application of the search list, including ".local.", if present. 1548 A malicious host could masquerade as "www.example.com" by answering 1549 the resulting Multicast DNS query for "www.example.com.local." 1550 To avoid this, a host MUST NOT append the search suffix 1551 ".local.", if present, to any relative (partially qualified) 1552 domain name containing two or more labels. Appending ".local." to 1553 single-label relative domain names is acceptable, since the user 1554 should have no expectation that a single-label domain name will 1555 resolve as-is. 1557 24. IANA Considerations 1559 The IANA has allocated the IPv4 link-local multicast address 1560 224.0.0.251 for the use described in this document. 1562 The IANA has allocated the IPv6 multicast address set FF0X::FB 1563 for the use described in this document. 1565 When this document is published, IANA should designate a list 1566 of domains which are deemed to have only link-local significance, 1567 as described in this document. 1569 No other IANA services are required by this document. 1571 25. Copyright 1573 Copyright (C) The Internet Society 20th June 2003. 1574 All Rights Reserved. 1576 This document and translations of it may be copied and furnished to 1577 others, and derivative works that comment on or otherwise explain it 1578 or assist in its implementation may be prepared, copied, published 1579 and distributed, in whole or in part, without restriction of any 1580 kind, provided that the above copyright notice and this paragraph are 1581 included on all such copies and derivative works. However, this 1582 document itself may not be modified in any way, such as by removing 1583 the copyright notice or references to the Internet Society or other 1584 Internet organizations, except as needed for the purpose of 1585 developing Internet standards in which case the procedures for 1586 copyrights defined in the Internet Standards process must be 1587 followed, or as required to translate it into languages other than 1588 English. 1590 The limited permissions granted above are perpetual and will not be 1591 revoked by the Internet Society or its successors or assigns. 1593 This document and the information contained herein is provided on an 1594 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1595 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1596 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1597 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1598 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1600 26. Normative References 1602 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 1603 Facilities", STD 13, RFC 1034, November 1987. 1605 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 1606 Specifications", STD 13, RFC 1035, November 1987. 1608 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1609 Requirement Levels", RFC 2119, March 1997. 1611 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO 1612 10646", RFC 2279, January 1998. 1614 27. Informative References 1616 [dotlocal] 1618 [djbdl] 1620 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 1621 Overview and Architecture. 1622 Institute of Electrical and Electronic Engineers, 1623 IEEE Standard 802, 1990. 1625 [DNS-SD] Cheshire, S. "DNS-Based Service Discovery", Internet-Draft 1626 (work in progress), draft-cheshire-dnsext-dns-sd-01.txt, 1627 June 2003. 1629 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 1630 System (DNS UPDATE)", RFC 2136, April 1997. 1632 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address 1633 Autoconfiguration", RFC 2462, December 1998. 1635 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", 1636 RFC 2535, March 1999. 1638 [v4LL] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic 1639 Configuration of IPv4 Link-Local Addresses", 1640 Internet-Draft (work in progress), 1641 draft-ietf-zeroconf-ipv4-linklocal-08.txt, June 2003. 1643 [ZC] Williams, A., "Requirements for Automatic Configuration 1644 of IP Hosts", Internet-Draft (work in progress), 1645 draft-ietf-zeroconf-reqts-12.txt, September 2002. 1647 28. Author's Addresses 1649 Stuart Cheshire 1650 Apple Computer, Inc. 1651 1 Infinite Loop 1652 Cupertino 1653 California 95014 1654 USA 1656 Phone: +1 408 974 3207 1657 EMail: rfc@stuartcheshire.org 1659 Marc Krochmal 1660 Apple Computer, Inc. 1661 1 Infinite Loop 1662 Cupertino 1663 California 95014 1664 USA 1666 Phone: +1 408 974 4368 1667 EMail: marc@apple.com 1669 Appendix. Earlier Simultaneous Probe Tie-Breaking Rules 1671 Earlier versions of this document had previously proposed the 1672 opposite tie-breaking rules for simultaneous probes. Operational 1673 experience discovered a minor problem with this, which is why the 1674 specification was updated. 1676 When reading the following description, familiarity with DNS-Based 1677 Service Discovery [DNS-SD] is useful. Remember that an SRV record 1678 contains two names, the service name, and the target host name where 1679 that service can be found (the SRV "rdata"). 1681 We found cases where certain network switches would delay packets a 1682 few milliseconds and then re-broadcast them. This meant that after 1683 detecting a host name conflict and picking a new host name (e.g. 1684 renaming device.local. to device2.local.), a host could then see one 1685 of its *own* previous SRV probes containing the old (pre-change) host 1686 name. In the tie-breaking between the current rdata and the old rdata 1687 in the stale packet from its former self, the host would conclude 1688 that it has lost the tie-break (with itself!). 1690 This could result (for example) in the device then renaming the 1691 "Stuart's Printer" service as "Stuart's Printer 2". Given that there 1692 isn't really any other "Stuart's Printer" on the network, this 1693 spurious rename would be confusing and annoying for the user. 1695 Since picking a new host name normally entails incrementing or 1696 appending a digit to the name, the new name is almost always 1697 lexicographically later in sorting order than the previous new name. 1699 By saying that the rdata that is lexicographically later wins, this 1700 means that new SRV rdata beats old rdata, instead of the other way 1701 around. 1703 The situations where this problem manifested were exceedingly rare -- 1704 but nevertheless we wanted to fix it, and make sure that even those 1705 exceedingly rare cases were handled the best way possible. 1707 This change has raised a concern in some people's minds that it will 1708 result in a catastrophic failure if a device implementing the old 1709 rules and a device implementing the new rules are connected to the 1710 same network. This is incorrect. The behaviour will certainly be 1711 sub-optimal, but not catastrophic. The two scenarios are described 1712 below: 1714 Both hosts think they have won the tie-break: Both hosts will ignore 1715 each other's probes. After three probes, one or other host will 1716 announce its resource records, the other host will see the 1717 announcement as an answer to its probe, and then pick an new name. If 1718 the two hosts are so precisely synchronized that they both send their 1719 announcements at the exact same instant, then they will detect it as 1720 a late conflict, and return to probing state and try again, until the 1721 conflict is resolved. Since "new" hosts implement probe 1722 rate-limiting, and no old hosts ever did, if the hosts remain 1723 perfectly synchronized and the conflict persists after ten tries, the 1724 new host will pause for five seconds and effectively defer to the 1725 "old" host. 1727 Both hosts think they have lost the tie-break: Both hosts will pick a 1728 new name and try again. If they both pick the same new name to try 1729 with, they will both fail again. As above, after ten of these 1730 repeated failures, the new host will wait for five seconds, allow the 1731 old host to complete its probing, and then try again. 1733 There are very few devices still implementing the "old" rules. All 1734 Macintosh computers running OS X 10.2.5 or later implement the 1735 current rules. Most early devices implementing the "old" rules have 1736 upgradable firmware that has already been updated. For a protocol 1737 that may be with us for decades to come, it was felt to be preferable 1738 to suffer a minor inconvenience now and fix the problem, rather then 1739 not fix it, and then regret it in years to come.