idnits 2.17.1 draft-cheshire-dnsext-multicastdns-01.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 (December 2002) is 7802 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 1287, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 1290, 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-00 -- 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-01.txt Stuart Cheshire 2 Category: Standards Track Apple Computer, Inc. 3 Expires 20th June 2003 20th December 2002 5 Performing DNS queries via IP Multicast 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), 14 its areas, and its working groups. Note that other groups may 15 also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Distribution of this memo is unlimited. 30 Abstract 32 As networked devices become smaller, more portable, and more 33 ubiquitous, the ability to operate with less configured 34 infrastructure is increasingly important. In particular, the ability 35 to look up host names and similar DNS resource record data types, in 36 the absence of a conventional managed DNS server, is becoming 37 essential. 39 Acknowledgements 41 This concepts described in this document have been explored and 42 developed with help from Erik Guttman, Paul Vixie, Bill Woodcock, 43 and others. 45 Table of Contents 47 1. Introduction...................................................3 48 2. Conventions and Terminology Used in this Document..............3 49 3. Multicast DNS Names............................................4 50 4. IP TTL Checks..................................................6 51 5. Reverse Address Mapping........................................6 52 6. Querying.......................................................7 53 6.1 One-Shot Queries...............................................7 54 6.2 One-Shot Queries, Accumulating Multiple Responses..............7 55 6.3 Continuous Querying............................................8 56 7. Duplicate Suppression..........................................9 57 7.1 Known Answer Suppression.......................................9 58 7.2 Multi-Packet Known Answer Suppression..........................9 59 7.3 Duplicate Question Suppression................................10 60 7.4 Duplicate Answer Suppression..................................10 61 8. Responding....................................................10 62 9. Probing and Announcing on Startup.............................12 63 9.1 Probing.......................................................12 64 9.2 Announcing....................................................13 65 10. Conflict Resolution...........................................14 66 11. Special Characteristics of Multicast DNS Domains..............14 67 12. Multicast DNS for Service Discovery...........................16 68 13. Resource Record TTL Values and Cache Coherency................16 69 13.1 Announcements to Update Cache Entries.........................17 70 13.2 Cache Flush on Topology change................................17 71 13.3 Cache Flush on Failure Indication.............................18 72 14. Enabling and Disabling Multicast DNS..........................19 73 15. Considerations for Multiple Interfaces........................19 74 16. Multicast DNS and Power Management............................20 75 17. Multicast DNS Character Set...................................21 76 18. Multicast DNS Message Format..................................21 77 19. Choice of UDP Port Number.....................................24 78 19.1 Arguments for using UDP port 53:..............................24 79 19.2 Arguments for using a different port (UDP port 5353):.........24 80 20. Summary of Differences Between Multicast DNS and Unicast DNS..25 81 21. IPv6 Considerations...........................................26 82 21.1 Multicast Addresses by Hashing................................26 83 22. Security Considerations.......................................27 84 23. IANA Considerations...........................................27 85 24. Copyright.....................................................28 86 25. Normative References..........................................28 87 26. Informative References........................................29 88 27. Author's Address..............................................29 90 1. Introduction 92 When reading this document, familiarity with the concepts of Zero 93 Configuration Networking [ZC] and automatic link-local addressing 94 [v4LL] [RFC 2462] is helpful. 96 This document proposes no change to the structure of DNS messages, 97 and no new operation codes, response codes, or resource record types. 98 This document simply discusses what needs to happen if DNS clients 99 start sending DNS queries to a multicast address, and how a 100 collection of hosts can cooperate to collectively answer those 101 queries in a useful manner. 103 There has been discussion of how much burden Multicast DNS might 104 impose on a network. It should be remembered that whenever IPv4 hosts 105 communicate they broadcast ARP packets on the network on a regular 106 basis, and this is not disastrous. The approximate amount of 107 multicast traffic generated by hosts making conventional use of 108 Multicast DNS is anticipated to be roughly the same order of 109 magnitude as the amount of broadcast ARP traffic those hosts already 110 generate. 112 New applications making new use of Multicast DNS capabilities for 113 unconventional purposes may generate more traffic. If some of those 114 new applications are "chatty", then work will be needed to help them 115 become less chatty. When performing any analysis, is important to 116 make a distinction between the application behavior and the 117 underlying protocol behavior. If a chatty application uses UDP, that 118 doesn't mean that UDP is chatty, or that IP is chatty, or that 119 Ethernet is chatty. What it means is that the application is chatty. 120 The same applies to any future applications that may decide to layer 121 increasing portions of their functionality over Multicast DNS. 123 2. Conventions and Terminology Used in this Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in "Key words for use in 128 RFCs to Indicate Requirement Levels" [RFC 2119]. 130 This document uses the term "host name" in the strict sense to mean a 131 fully qualified domain name that has an address record. It does not 132 use the term "host name" in the commonly used but incorrect sense to 133 mean just the first DNS label of a host's fully qualified domain 134 name. 136 A DNS (or mDNS) packet contains an IP TTL in the IP header, which 137 is effectively a hop-count limit for the packet, to guard against 138 routing loops. Each Resource Record also contains a TTL, which is 139 the number of seconds for which the Resource Record may be cached. 141 In any place where there may be potential confusion between these two 142 types of TTL, the term "IP TTL" is used to refer to the IP header TTL 143 (hop limit), and the term "RR TTL" is used to refer to the Resource 144 Record TTL (cache lifetime). 146 When this document uses the term "Multicast DNS", it should be taken 147 to mean: Clients performing DNS-like queries for DNS-like resource 148 records by sending DNS-like UDP query and response packets over IP 149 Multicast to UDP port 5353." 151 3. Multicast DNS Names 153 The DNS domain ".local." is (this document proposes) a special domain 154 with special semantics, namely that ".local." and all its subdomains 155 are link-local, and names within this domain are meaningful only on 156 the link where they originate, much as IPv4 addresses in the 157 169.254/16 prefix are link-local and meaningful only on the link 158 where they originate. 160 Any DNS query for a name ending with ".local." MUST be sent 161 to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent 162 FF02::FB). 164 It is unimportant whether a name ending with ".local." occurred 165 because the user explicitly typed in a fully qualified domain name 166 ending in ".local.", or because the user entered an unqualified 167 domain name and the host software appended the suffix ".local." 168 because that suffix appears in the user's search list. The ".local." 169 suffix could appear in the search list because the user manually 170 configured it, or because it was received in a DHCP option, or via 171 any other valid mechanism for configuring the DNS search list. In 172 this respect the ".local." suffix is treated no differently to any 173 other search domain that might appear in the DNS search list. 175 DNS queries for names that do not end with ".local." MAY be sent to 176 the mDNS multicast address, if no other conventional DNS server is 177 available. This can allow hosts on the same link to continue 178 communicating using each other's globally unique DNS names during 179 network outages which disrupt communication with the greater 180 Internet. When resolving global names via local multicast, it is even 181 more important to use DNSSEC or other security mechanisms to ensure 182 that the response is trustworthy. Resolving global names via local 183 multicast is a contentious issue, and this document does not discuss 184 it in detail, instead concentrating on the issue of resolving local 185 names using DNS packets sent to a multicast address. 187 A host which belongs to an organization or individual who has control 188 over some portion of the DNS namespace can be assigned a globally 189 unique name within that portion of the DNS namespace, for example, 190 "cheshire.apple.com." For those of us who have this luxury, this 191 works very well. However, the majority home customers do not have 192 easy access to any portion of the global DNS namespace within which 193 they have the authority to create names as they wish. This leaves the 194 majority of home computers effectively anonymous for practical 195 purposes. 197 To remedy this problem, this document allows any computer user to 198 elect to give their computers link-local Multicast DNS host names of 199 the form: "single-dns-label.local." For example, my Titanium 200 PowerBook laptop computer answers to the name "sctibook.local." Any 201 computer user is granted the authority to name their computer this 202 way, providing that the chosen host name is not already in use on 203 that link. Having named their computer this way, the user has the 204 authority to continue using that name until such time as name 205 conflict occurs on the link which is not resolved in the user's 206 favour. If this happens, the computer (or its human user) SHOULD 207 cease using the name, and may choose to attempt to allocate a new 208 unique name for use on that link. Like law suits over global DNS 209 names, these conflicts are expected to be relatively rare for people 210 who choose reasonably imaginative names, but it is still important 211 to have a mechanism in place to handle them when they happen. 213 The point made in the previous paragraph is very important and bears 214 repeating. It is easy for those of us in the IETF community who run 215 our own name servers at home to forget that the majority of computer 216 users do not run their own name server and have no easy way to create 217 their own host names. When these users wish to transfer files between 218 two laptop computers, they are frequently reduced to typing in 219 dotted-decimal IP addresses because they simply have no other way for 220 one host to refer to the other by name. This is a sorry state of 221 affairs. What is worse, most users don't even bother trying to use 222 dotted-decimal IP addresses. Most users still move data between 223 machines by copying it onto a floppy disk or similar removable media. 224 In a world of gigabit Ethernet and ubiquitous wireless networking it 225 is a sad indictment of the networking community that the preferred 226 communication medium for most computer users is still the floppy 227 disk. 229 Allowing ad-hoc allocation of single-label names in a single flat 230 ".local." namespace may seem to invite chaos. However, operational 231 experience with AppleTalk NBP names, which on any given link are also 232 effectively single-label names in a flat namespace, shows that in 233 practice name collisions happen extremely rarely and are not a 234 problem. Groups of computer users from disparate organizations bring 235 Macintosh laptop computers to events such as IETF Meetings, the Mac 236 Hack conference, the Apple World Wide Developer Conference, etc., and 237 complaints at these events about users suffering conflicts and being 238 forced to rename their machines have never been an issue. 240 Enforcing uniqueness of host names (i.e. the names of DNS address 241 records mapping names to IP addresses) is probably desirable in the 242 common case, but this document does not mandate that. It is 243 permissible for a collection of coordinated hosts to agree to 244 maintain multiple DNS address records with the same name, possibly 245 for load balancing or fault-tolerance reasons. This document does not 246 take a position on whether that is sensible. It is important that 247 both modes of operation are supported. The Multicast DNS protocol 248 allows hosts to verify and maintain unique names for resource records 249 where that behaviour is desired, and it also allows hosts to maintain 250 multiple resource records with a single shared name where that 251 behaviour is desired. This consideration applies to all resource 252 records, not just address records (host names). In summary: It is 253 required that the protocol have the ability to detect and handle name 254 conflicts. It is not required that the user should use that ability 255 in every case. 257 4. IP TTL Checks 259 A host sending Multicast DNS queries to a link-local destination 260 address MUST verify that the IP TTL in response packets is 255, and 261 silently discard any response packets where the IP TTL is not 255. 262 Without this check, it could be possible for remote rogue hosts to 263 send spoof answer packets (perhaps unicast to the victim host) which 264 the receiving machine could misinterpret as having originated on the 265 local link. 267 There has been some discussion that many current network programming 268 APIs to not provide any indication of the IP TTL on received packets. 269 This is unfortunate, and should be fixed for hosts that want to be 270 able to guard against spoof packets arriving from off-link. 272 5. Reverse Address Mapping 274 Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also 275 defined to be link-local. 277 Any DNS query for a name ending with "254.169.in-addr.arpa." MUST be 278 sent to the mDNS multicast address 224.0.0.251. Since names under 279 this domain correspond to IPv4 link-local addresses, it is logical 280 that the local link is the best place to find information pertaining 281 to those names. 283 Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa." 284 MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB. 286 6. Querying 288 There are three kinds of Multicast DNS Queries, one-shot queries of 289 the kind made by today's conventional DNS clients, one-shot queries 290 accumulating multiple responses made by multicast-aware DNS clients, 291 and continuous ongoing Multicast DNS Queries used by IP network 292 browser software. 294 A Multicast DNS Responder that is offering records that are intended 295 to be unique on the local link MUST also implement a Multicast DNS 296 Querier so that it can first verify the uniqueness of those records 297 before it begins answering queries for them. 299 6.1 One-Shot Queries 301 An unsophisticated DNS client may simply send its DNS queries 302 blindly to the 224.0.0.251 multicast address, without necessarily 303 even being aware what a multicast address is. 305 Such an unsophisticated DNS client may not get ideal behaviour. Such 306 a client may simply take the first response it receives and fail to 307 wait to see if there are more, but in many instances this may not be 308 a serious problem. If a user types "http://stu.local." into their Web 309 browser and gets to see the page they were hoping for, then the 310 protocol has met the user's needs in this case. 312 6.2 One-Shot Queries, Accumulating Multiple Responses 314 A more sophisticated DNS client should understand that Multicast DNS 315 is not exactly the same as unicast DNS, and should modify its 316 behaviour in some simple ways. 318 As described above, there are some cases, such as looking up the 319 address associated with a unique host name, where a single response 320 is sufficient, and moreover may be all that is expected. However, 321 there are other DNS queries where more than one response is 322 possible, and for these queries a more sophisticated Multicast DNS 323 client should include the ability to wait for an appropriate period 324 of time to collect multiple responses. 326 A naive DNS client retransmits its query only so long as it has 327 received no response. A more sophisticated Multicast DNS client is 328 aware that having received one response is not necessarily an 329 indication that it might not receive others, and has the ability to 330 retransmit its query an appropriate number of times at appropriate 331 intervals until it is satisfied with the collection of responses it 332 has gathered. 334 A more sophisticated Multicast DNS client that is retransmitting a 335 query for which is has already received some responses, MAY elect to 336 implement duplicate suppression, as described below under "Duplicate 337 Suppression". This indicates to responders who have already replied 338 that their responses have been received, and they don't need to send 339 them again in response to this repeated query. 341 A Multicast DNS Querier MAY place more than one question into the 342 Question Section of a Multicast DNS Query. 344 6.3 Continuous Querying 346 In One-Shot Queries, with either a single or multiple responses, the 347 underlying assumption is that the transaction begins when the 348 application issues a query, and ends when all the desired responses 349 have been received. There is another type of operation which is more 350 akin to continuous monitoring. 352 Macintosh users are accustomed to opening the "Chooser" window, 353 selecting a desired printer, and then closing the Chooser window. 354 However, when the desired printer does not appear in the list, the 355 user will typically leave the "Chooser" window open while they go and 356 check to verify that the printer is plugged in, powered on, connected 357 to the Ethernet, etc. While the user jiggles the wires, hits the 358 Ethernet hub, and so forth, they keep an eye on the Chooser window, 359 and when the printer name appears, they know they have fixed whatever 360 the problem was. This can be a useful and intuitive troubleshooting 361 technique, but a user who goes home for the weekend leaving the 362 Chooser window open places a non-trivial burden on the network. 364 It is important that an IP network browser window displaying 365 live information from the network using Multicast DNS, if left 366 running for an extended period of time, should generate significantly 367 less multicast traffic on the network than the old AppleTalk Chooser. 369 A Multicast DNS Querier asking the same question repeatedly for an 370 indefinite period of time MUST implement duplicate suppression, as 371 described below. 373 7. Duplicate Suppression 375 A variety of techniques are used to reduce the amount of redundant 376 traffic on the network. 378 7.1 Known Answer Suppression 380 When a Multicast DNS Querier sends a query to which it already knows 381 some answers, it populates the Answer Section of the DNS message with 382 those cached resource records whose remaining TTL values indicate 383 that they will remain valid for at least the time anticipated to send 384 this DNS query, and the next, and the one after that. For example, if 385 the query DNS Querier is planning to wait four seconds after this 386 query before sending the next, and then eight seconds after that, 387 then only resource records with TTL values greater than twelve 388 seconds should be included in the answer section. This is to ensure 389 that when a resource record's TTL is close to expiration, the 390 Multicast DNS Querier has *two* chances to refresh it before the 391 cached record expires and has to be removed from the list. 393 A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if 394 the answer it would give is already included in the Answer Section 395 with an RR TTL at least half the correct value. If the RR TTL of the 396 answer as given in the Answer Section is less than half of the real 397 RR TTL as known by the Multicast DNS Responder, the responder SHOULD 398 send an answer so as to update the Querier's cache before the record 399 becomes in danger of expiration. 401 A Multicast DNS Querier MUST NOT cache resource records observed in 402 the Answer Section of other Multicast DNS Queries. The Answer 403 Section of Multicast DNS Queries is not authoritative. By placing 404 information in the Answer Section of a Multicast DNS Query the 405 querier is stating that it *believes* the information to be true. 406 It is not asserting that the information *is* true. Some of those 407 records may have come from other hosts that are no longer on the 408 network. Propagating that stale information to other Multicast DNS 409 Queriers on the network would not be helpful. 411 7.2 Multi-Packet Known Answer Suppression 413 Sometimes a Multicast DNS Querier will already have too many answers 414 to fit in the Known Answer section of its query packets. In 415 this case, it should issue a Multicast DNS Query containing a 416 questions as many Known Answer records as will fit. It 417 should then set the TC (Truncated) bit in the header before sending 418 the Query. It should then immediately follow the packet with another 419 query containing no questions, and as many more Known Answer 420 records as will fit. If there are still too many records remaining to 421 fit in the packet, it again sets the TC bit and continues until all 422 the Known Answer records have been sent. 424 A Multicast DNS Responder seeing a Multicast DNS Query with the TC 425 bit set defers its response for a time period randomly selected in 426 the interval 20-120ms. This gives the Multicast DNS Querier time to 427 send additional Known Answer packets before the Responder 428 responds. If the Responder sees any of its answers listed in the 429 Known Answer lists of subsequent packets from the querying 430 host, it should delete that answer from the list of answers it is 431 planning to give, provided that no other host on the network is 432 also waiting to receive the same answer record. 434 7.3 Duplicate Question Suppression 436 If a host is planning to send a query, and it sees another host on 437 the network send a query containing the same question, and the Known 438 Answer section of that query does not contain any records which this 439 host would not also put in its own Known Answer section, then this 440 host should treat its own query as having been sent. When multiple 441 clients on the network are querying for the same resource records, 442 there is no need for them to all be repeatedly asking the same 443 question. 445 7.4 Duplicate Answer Suppression 447 If a host is planning to send an answer, and it sees another host on 448 the network send a response packet containing the same answer record, 449 and the TTL in that record is not less than the TTL this host would 450 have given, then this host should treat its own answer as having been 451 sent. When multiple responders on the network have the same data, 452 there is no need for all of them to respond. 454 The feature is particularly useful when multiple Sleep Proxy Servers 455 are deployed (see Section 16. "Multicast DNS and Power Management"). 456 In future it is possible that every general-purpose OS (Mac, Windows, 457 Linux, etc.) will implement Sleep Proxy Service as a matter of 458 course. In this case there could be a large number of Sleep Proxy 459 Servers on any given network, which is good for reliability and 460 fault-tolerance, but would be bad for the network if every Sleep 461 Proxy Server were to answer every query. 463 8. Responding 465 A Multicast DNS Responder MUST only respond when it has a positive 466 non-null response to send. Error responses must never be sent. The 467 non-existence of any name in a Multicast DNS Domain is ascertained by 468 the failure of any machine to respond to the Multicast DNS query, not 469 by NXDOMAIN errors. 471 Multicast DNS Responses need not contain any questions in the 472 Question Section. Multicast DNS Queriers receiving Multicast DNS 473 Responses do not care what question elicited the response; they care 474 only that the information in the response is true and accurate. 476 A Multicast DNS Responder on Ethernet [IEEE802] and similar shared 477 multiple access networks SHOULD delay its responses by a random 478 amount of time selected with uniform random distribution in the range 479 20-120ms. If multiple Multicast DNS Responders were all to respond 480 immediately to a particular query, a collision would be virtually 481 guaranteed. By imposing a small random delay, the number of 482 collisions is dramatically reduced. 120ms is a short enough time that 483 it is almost imperceptible to a human user, but long enough to 484 significantly reduce the risk of Ethernet collisions. On a full-sized 485 Ethernet using the maximum cable lengths allowed and the maximum 486 number of repeaters allowed, an Ethernet frame is vulnerable to 487 collisions during the transmission of its first 256 bits. On 10Mb/s 488 Ethernet, this equates to a vulnerable time window of 25.6us. 490 In the case where a Multicast DNS Responder has good reason to 491 believe that it will be the only responder on the link with a 492 positive non-null response, it SHOULD respond immediately, without 493 the random delay. To do this safely, it MUST have previously verified 494 that the requested name, type and class in the DNS query are unique 495 on this link. This may be appropriate for things like looking up the 496 address record for a particular host name, when the host name has 497 been previously verified unique. This is *not* appropriate for things 498 like looking up PTR records used for DNS Service Discovery [DNS-SD], 499 where a large number of responses may be anticipated. 501 Multicast DNS Responses MUST be sent to UDP port 5353 (the well-known 502 port assigned to mDNS) on the 224.0.0.251 multicast address (or its 503 IPv6 equivalent). Operating in a Zeroconf environment requires 504 constant vigilance. Just because a name has been previously verified 505 unique does not mean it will continue to be so indefinitely. By 506 allowing all Multicast DNS Responders to constantly monitor their 507 peers' responses, conflicts arising out of network topology changes 508 can be promptly detected and resolved. Sending all responses by 509 multicast also facilitates opportunistic caching by other hosts on 510 the network. 512 If the source UDP port in a received Multicast DNS Query is not 513 port 5353, this indicates that the client originating the query is 514 a simple client that does not fully implement all of Multicast DNS. 515 In this case, after sending the usual Multicast DNS Response to 516 224.0.0.251 port 5353, the Multicast DNS Responder MUST also send a 517 second UDP response to the client, via unicast, to the query 518 packet's source IP address and port. 520 Multicast DNS Responders MUST correctly handle DNS query packets 521 containing more than one question, by answering any or all of the 522 questions to which they have answers. Any answers generated 523 in response to query packets containing more than one question 524 MUST be randomly delayed in the range 20-120ms, as described above. 526 9. Probing and Announcing on Startup 528 Whenever a Multicast DNS Responder starts up, wakes up from sleep, 529 receives an indication of an Ethernet "Link Change" event, or has any 530 other reason to believe that its network connectivity may have 531 changed in some relevant way, it MUST perform two startup steps. 533 9.1 Probing 535 The first startup step is that for all those resource records that a 536 Multicast DNS Responder desires to be unique on the local link, it 537 MUST send a Multicast DNS Query asking for those resource records, to 538 see if any of them are already in use. The primary example of this is 539 its address record which maps its unique host name to its unique IP 540 address. The ability to place more than one question in a Multicast 541 DNS Query is useful here, because it can allow a host to use a single 542 packet for all of its resource records instead of needing a separate 543 packet for each. If any conflicting Multicast DNS responses are 544 received, then the host MUST defer to the other host already using 545 those names, and MUST select new names for its conflicting records 546 which need to be unique. 250ms after the first query it should send a 547 second, then 250ms after that a third. If, after a total of 750ms, no 548 conflicting Multicast DNS responses have been received, the host may 549 move to the second step. 551 The astute reader will observe that there is a race condition 552 inherent in the previous description. If two hosts are probing for 553 the same name simultaneously, neither will receive any response to 554 the probe, and the hosts could incorrectly conclude that they may 555 both proceed to use the name. To break this symmetry, each host 556 populates the Authority Section of its queries with records giving 557 the rdata that it would be proposing to use, should its probing be 558 successful. The Authority Section is being used here in a way 559 analogous to the Update section of a DNS Update packet [RFC 2136]. 561 When a host that is probing for a record sees another host issue a 562 query for the same record, it consults the Authority Section of that 563 query. If it finds any resource record there which answers the query, 564 then it compares the rdata in that resource record with its own 565 tentative rdata. The lexicographically earlier rdata wins. This means 566 that if the host finds that its own rdata is lexicographically 567 earlier, it simply ignores the other host's probe. If the host finds 568 that the rdata in the Authority Section record is lexicographically 569 earlier, then it treats this exactly as if it had received an answer 570 to its query, and concludes that it may not use the desired name. 572 The determination of 'lexicographically earlier' is performed by raw 573 comparison of the binary content of the rdata without regard for 574 meaning or structure. The bytes of the rdata are compared in turn 575 until a byte is found whose value is lesser than that of its 576 counterpart (in which case the rdata whose byte has the lesser value 577 is deemed lexicographically earlier) or one of the resource records 578 runs out of rdata (in which case the resource record which ran out of 579 data first is deemed lexicographically earlier). 581 The following is an example of a conflict: 583 sctibook.local. A 196.254.50.100 584 sctibook.local. A 196.254.100.50 586 In this case 196.254.50.100 is lexicographically earlier, so is 587 deemed the winner. 589 9.2 Announcing 591 The second startup step is that the Multicast DNS Responder MUST send 592 a gratuitous Multicast DNS Response containing, in the Answer 593 Section, all of its resource records. If there are too many resource 594 records to fit in a single packet, multiple packets may be used. 596 In the case of shared records (e.g. the PTR records used by DNS 597 Service Discovery [DNS-SD]) the records are simply placed as-is into 598 the answer section of the DNS Response. 600 In the case of records that have been verified to be unique in the 601 previous step, they are placed into the answer section of the DNS 602 Response with the most significant bit of the rrclass set to one. 604 The most significant bit of the rrclass is the mDNS "cache flush" 605 bit. Normally when a resource record appears answer in the section of 606 the DNS Response, it means, "This is an assertion that this 607 information is true." When a resource record appears answer in the 608 section of the DNS Response with the "cache flush" bit set, it means, 609 "This is an assertion that this information is the truth and the 610 whole truth, and anything you may have heard before regarding records 611 of this name/type/class is no longer valid". The "cache flush" bit is 612 described further in Section 13.1 "Announcements to Update Cache 613 Entries". 615 Up to ten of gratuitous Multicast DNS Responses may be sent, 616 providing that the interval between gratuitous responses doubles 617 with every response sent, and the interval between the first two 618 gratuitous responses is not less than one second. 620 Whenever a Multicast DNS Responder receives any Multicast DNS 621 response (gratuitous or otherwise) containing a conflicting resource 622 record, the conflict MUST be resolved as described below in "Conflict 623 Resolution". 625 A Multicast DNS Responder MUST NOT send announcements in the absence 626 of information that its network connectivity may have changed in some 627 relevant way. In particular, a Multicast DNS Responder MUST NOT send 628 regular periodic announcements as a matter of course. 630 10. Conflict Resolution 632 A conflict occurs when two resource records with the same name, type 633 and class have inconsistent rdata. What may be considered 634 inconsistent is context sensitive, except that resource records with 635 identical rdata are never considered inconsistent, even if they 636 originate from different hosts. In the case of a host desiring to 637 have a unique host name, another address record with the same name 638 but a different IP address is considered inconsistent. 640 Whenever a Multicast DNS Responder receives any Multicast DNS 641 response (gratuitous or otherwise) containing a conflicting resource 642 record, the Multicast DNS Responder must immediately reset that 643 record to probing state, and go through the startup steps described 644 above in Section 9. "Probing and Announcing on Startup". The 645 protocol used in the Probing phase will determine a winner and a 646 loser, and the loser must cease using the name, and reconfigure. 648 In the case of a typical laptop or desktop computer with a human 649 user, reconfiguration is achieved by displaying an error message to 650 the user and suggesting that they choose a new name. In the case of a 651 device with no human operator, reconfiguration is achieved by its 652 software programmatically generating a new name. In either case, the 653 host must then test the new name for uniqueness as described above in 654 "Probing and Announcing on Startup". 656 It is important that any host that observes an apparent conflict 657 should take action. In the case of two hosts using the same host 658 name, where one has been configured to require a unique host name and 659 the other has not, the one that has not been configured to require a 660 unique host name will not perceive any conflict, and will not take 661 any action. By reverting to Probing state, the host that desires a 662 unique host name will go through the necessary steps to ensure that a 663 unique host is obtained. 665 The examples in this section focus on address records (i.e. host 666 names), but the same considerations apply to all resource records 667 where uniqueness (or maintenance of some other defined constraint) is 668 desired. 670 11. Special Characteristics of Multicast DNS Domains 672 Unlike conventional DNS names, names that end in ".local.", 673 "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local 674 significance. Conventional DNS seeks to provide a single unified 675 namespace, where a given DNS query yields the same answer no matter 676 where on the planet it is performed or to which recursive DNS server 677 the query is sent. (However, split views, firewalls, intranets and 678 the like have somewhat interfered with this goal of DNS representing 679 a single universal truth.) In contrast, each IP link has its own 680 private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa." 681 namespaces, and the answer to any query for a name within those 682 domains depends on where that query is asked. 684 Multicast DNS Domains are not delegated from their parent domain via 685 use of NS records. There are no NS records anywhere in Multicast DNS 686 Domains. Instead, all Multicast DNS Domains are delegated to the IP 687 addresses 224.0.0.251 and FF02::FB by virtue of the individual 688 organizations producing DNS client software deciding how to handle 689 those names. It would be extremely valuable for the industry if this 690 special handling were ratified and recorded by IANA, since otherwise 691 the special handling provided by each vendor is likely to be 692 inconsistent. 694 The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The 695 IPv6 name server for a Multicast DNS Domain is FF02::FB. These are 696 multicast addresses; therefore they identify not a single host but a 697 collection of hosts, working in cooperation to maintain some 698 reasonable facsimile of a competently managed DNS zone. Conceptually 699 a Multicast DNS Domain is a single DNS zone, however its server is 700 implemented as a distributed process running on cluster of loosely 701 cooperating CPUs rather than as a single process running on a single 702 CPU. 704 No delegation is performed within Multicast DNS Domains. Because the 705 cluster of loosely coordinated CPUs is cooperating to administer a 706 single zone, delegation is neither necessary nor desirable. Just 707 because a particular host on the network may answer queries for a 708 particular record type with the name "example.local." does not imply 709 anything about whether that host will answer for the name 710 "child.example.local.", or indeed for other record types with the 711 name "example.local." 713 Multicast DNS Zones have no SOA record. A conventional DNS zone's 714 SOA record contains information such as the email address of the zone 715 administrator and the monotonically increasing serial number of the 716 last zone modification. There is no single human administrator for 717 any given Multicast DNS Zone, so there is no email address. Because 718 the hosts managing any given Multicast DNS Zone are only loosely 719 coordinated, there is no readily available monotonically increasing 720 serial number to determine whether or not the zone contents have 721 changed. A host holding part of the shared zone could crash or be 722 disconnected from the network at any time without informing the other 723 hosts. There is no reliable way to provide a zone serial number that 724 would, whenever such a crash or disconnection occurred, immediately 725 change to indicate that the contents of the shared zone had changed. 727 Zone transfers are not possible for any Multicast DNS Zone. 729 12. Multicast DNS for Service Discovery 731 This document does not describe using Multicast DNS for network 732 browsing or service discovery. However, the mechanisms this document 733 describes are compatible with (and support) the browsing and service 734 discovery mechanisms proposed in "Discovering Named Instances of 735 Abstract Services using DNS" [DNS-SD]. 737 This document places few limitations on what DNS record types may be 738 looked up using local multicast. One particular kind of Multicast DNS 739 query that might be useful is a query for the SRV record named 740 "_dns._udp.local.", yielding the port number and IP address of a 741 conventional DNS server willing to perform general recursive DNS 742 lookups. This could solve a particular problem facing the IPv6 743 community, which is that IPv6 is able to self-configure almost all of 744 the information it needs to operate [RFC 2462], except for the 745 address of the DNS server. Bringing in all of the mechanisms of DHCP 746 just for that one little additional piece of information is not an 747 attractive solution. Using DNS-format messages and DNS-format 748 resource records to find the address of the DNS server has an elegant 749 self-sufficiency about it. Any host that needs to know the address of 750 the DNS server must already have code to generate and parse DNS 751 packets, so using that same code and those same packets to find the 752 DNS server in the first place is a simple self-reliant solution that 753 avoids taking external dependencies on other protocols. 755 13. Resource Record TTL Values and Cache Coherency 757 The recommended TTL value for Multicast DNS resource records is 758 120 minutes. 760 A client with an active outstanding query will issue a query packet 761 when one or more of the resource record(s) in its cache is (are) 762 half-way to expiry. If the TTL on those records is 120 minutes, this 763 ongoing cache maintenance process yields a steady-state query rate of 764 one query per hour. 766 Any distributed cache needs a cache coherency protocol. If Multicast 767 DNS resource records follow the recommendation and have a TTL of 120 768 minutes, that means that stale data could persist in the system for 769 up to two hours. Making the default TTL significantly lower would 770 reduce the lifetime of stale data, but would produce too much extra 771 traffic on the network. Various techniques are available to minimize 772 the impact of such stale data. 774 13.1 Announcements to Update Cache Entries 776 In the case where a host knows that certain resource record data is 777 about to become invalid (for example when the host is undergoing a 778 clean shutdown) the host sends a gratuitous announcement mDNS 779 response packet, giving the same resource record name, type, class 780 and rdata, but an RR TTL of zero. This has the effect of updating the 781 TTL stored in neighbouring hosts' cache entries to zero, causing that 782 cache entry to be promptly deleted. 784 Whenever a host has a resource record with potentially new data (e.g. 785 after rebooting, waking from sleep, connecting to a new network link, 786 changing IP address, etc.), the host sends a series of gratuitous 787 announcements to update cache entries in its neighbour hosts. In 788 these gratuitous announcements, if the record is one that is intended 789 to be unique, the host sets the most significant bit of the rrclass 790 field of the resource record. This bit, the "cache flush" bit, tells 791 neighbouring hosts that this is not a shared record type. Instead of 792 merging this new record additively into the cache in addition to any 793 previous records with the same name, type and class, all old records 794 with that name, type and class are summarily declared invalid and 795 immediately flushed from the cache. 797 To accommodate the case where the set of records from one host 798 constituting a single unique RRSet is too large to fit in a single 799 packet, only cache records that are more than one second old are 800 flushed. This allows the announcing host to generate a quick burst of 801 two or more packets back-to-back on the wire, and the later packets 802 will not immediately flush the cache records created by the earlier 803 packets. Only cache records more than one second old will be flushed. 805 The "cache flush" bit is only used in Multicast DNS responses sent 806 via multicast. The "cache flush" bit MUST NOT be set in any resource 807 records in a response packet sent via unicast to any host. 809 13.2 Cache Flush on Topology change 811 If the hardware on a given host is able to indicate physical changes 812 of connectivity, then when the hardware indicates such a change 813 of connectivity, all cached records which were received on that 814 interface should immediately be flushed. 816 Likewise, when a host reboots, or wakes from sleep, or undergoes some 817 other similar discontinuous state change, its entire mDNS resource 818 record cache should be flushed. 820 13.3 Cache Flush on Failure Indication 822 Sometimes a cache record can be determined to be stale when a client 823 attempts to use the rdata it contains, and finds that rdata to be 824 incorrect. 826 For example, the rdata in an address record can be determined to be 827 incorrect if attempts to contact that host fail, either because 828 ARP/ND requests for that address go unanswered (for an address on a 829 local subnet) or because a router returns an ICMP "Host Unreachable" 830 error (for an address on a remote subnet). 832 The rdata in an SRV record can be determined to be incorrect if 833 attempts to communicate with the indicated service at the host and 834 port number indicated are not successful. 836 The rdata in a DNS-SD PTR record can be determined to be incorrect if 837 attempts to look up the SRV record it references are not successful. 839 In any such case, the software implementing the mDNS resource record 840 cache should provide a mechanism so that clients detecting stale 841 rdata can inform the cache and have that data flushed. 843 The end result of this is that if a printer suffers a sudden power 844 failure or other abrupt disconnection from the network, its name may 845 continue to appear in DNS-SD browser lists displayed on users' 846 screens. Eventually that entry will expire from the cache naturally, 847 but if a user tries to access the printer before that happens, the 848 failure to successfully contact the printer will trigger the more 849 hasty demise of its cache entries. This is a sensible trade-off 850 between good user-experience and good network efficiency. If we were 851 to insist that printers should disappear from the printer list within 852 30 seconds of becoming unavailable, for all failure modes, the only 853 way to achieve this would be for the client to poll the printer at 854 least every 30 seconds, or for the printer to announce its presence 855 at least every 30 seconds, both of which would be an unreasonable 856 burden on most networks. 858 14. Enabling and Disabling Multicast DNS 860 The option to fail-over to Multicast DNS for names not ending in 861 ".local." SHOULD be a user-configured option, and SHOULD 862 be disabled by default because of the possible security issues 863 related to unintended local resolution of apparently global names. 865 The option to lookup unqualified (relative) names by appending 866 ".local." (or not) is controlled by whether ".local." appears 867 (or not) in the client's DNS search list. 869 No special control is needed for enabling and disabling Multicast DNS 870 for names explicitly ending with ".local." as entered by the user. 871 The user doesn't need a way to disable Multicast DNS for names ending 872 with ".local.", because if the user doesn't want to use Multicast 873 DNS, they can achieve this by simply not using those names. If a user 874 *does* enter a name ending in ".local.", then we can safely assume 875 the user's intention was probably that it should work. Having user 876 configuration options that can be (intentionally or unintentionally) 877 set so that local names don't work is just one more way of 878 frustrating the user's ability to perform the tasks they want, 879 perpetuating the view that, "IP networking is too complicated to 880 configure and too hard to use." This in turn perpetuates the 881 continued use of protocols like AppleTalk. If we want to retire 882 AppleTalk, NetBIOS, etc., we need to offer users equivalent IP 883 functionality that they can rely on to, "always work, like 884 AppleTalk." A little Multicast DNS traffic may be a burden on the 885 network, but it is an insignificant burden compared to continued 886 widespread use of AppleTalk. 888 15. Considerations for Multiple Interfaces 890 A host should defend its host name (FQDN) on all active interfaces on 891 which it is answering Multicast DNS queries. 893 In the event of a name conflict on *any* interface, a host should 894 configure a new host name, if it wishes to maintain uniqueness of its 895 host name. 897 When answering a Multicast DNS query, a multi-homed host with a 898 link-local address (or addresses) should take care to ensure that 899 any address going out in a Multicast DNS response is valid for use 900 on the interface on which the response is going out. 902 Just as the same link-local IP address may validly be in use 903 simultaneously on different links by different hosts, the same 904 link-local host name may validly be in use simultaneously on 905 different links, and this is not an error. A multi-homed host with 906 connections to two different links may be able to communicate with 907 two different hosts that are validly using the same name. While this 908 kind of name duplication should be rare, it means that a host that 909 wants to fully support this case needs network programming APIs that 910 allow applications to specify on what interface to perform a 911 link-local Multicast DNS query, and to discover on what interface a 912 Multicast DNS response was received. 914 16. Multicast DNS and Power Management 916 Many modern network devices have the ability to go into a low-power 917 mode where only a small part of the Ethernet hardware remains 918 powered, and the device can be woken up by sending a specially 919 formatted Ethernet frame which the device's power-management hardware 920 recognizes. 922 To make use of this in conjunction with Multicast DNS, the device 923 first uses DNS-SD to determine if Sleep Proxy Service is available on 924 the local network. In some networks there may be more than one piece 925 of hardware implementing Sleep Proxy Service, for fault-tolerance 926 reasons. 928 If the device finds the network has Sleep Proxy Service, the device 929 transmits two or more gratuitous mDNS announcements setting the TTL 930 of its relevant resource records to zero, to delete them from 931 neighbouring caches. The relevant resource records include address 932 records and SRV records, and other resource records as may apply to a 933 particular device. The device then communicates all of its remaining 934 active records, plus the names, types and classes of the deleted 935 records, to the Sleep Proxy Service(s), along with a copy of the 936 specific "magic packet" required to wake the device up. 938 When a Sleep Proxy Service sees an mDNS query for one of the 939 device's active records (e.g. a DNS-SD PTR record), it answers on 940 behalf of the device without waking it up. When a Sleep Proxy Service 941 sees an mDNS query for one of the device's deleted resource 942 records, it deduces that some client on the network needs to make an 943 active connection to the device, and sends the specified "magic 944 packet" to wake the device up. The device then wakes up, reactivates 945 its deleted resource records, and re-announces them to the network. 946 The client waiting to connect sees the announcements, learns the 947 current IP address and port number of the desired service on the 948 device, and proceeds to connect to it. 950 The connecting client does not need to be aware of how Sleep Proxy 951 Service works. Only devices that implement low power mode and wish to 952 make use of Sleep Proxy Service need to be aware of how that protocol 953 works. 955 The full specification of mDNS / DNS-SD Sleep Proxy Service 956 is described in another document [not yet published]. 958 17. Multicast DNS Character Set 960 Unicast DNS has been plagued by the lack of any support for non-US 961 characters. Indeed, conventional DNS is usually limited to just 962 letters, digits and hyphens, with no spaces or other punctuation. 963 Attempts to remedy this have made slow progress because of the need 964 to accommodate old buggy legacy implementations. 966 Multicast DNS is a new protocol and doesn't (yet) have old buggy 967 legacy implementations to constrain the design choices. Accordingly, 968 it adopts the obvious simple solution: all names in Multicast DNS are 969 encoded using UTF-8 [RFC 2279]. For names that are restricted to 970 letters, digits and hyphens, the UTF-8 encoding is identical to the 971 US-ASCII encoding, so this is entirely compatible with existing host 972 names. For characters outside the US-ASCII range, UTF-8 encoding is 973 used. 975 Multicast DNS implementations MUST NOT use any other encodings apart 976 from UTF-8 (US-ASCII being considered a compatible subset of UTF-8). 978 This point bears repeating: There are various baroque representations 979 of international text being proposed for Unicast DNS. None of these 980 representations may be used in Multicast DNS packets. Any text being 981 represented internally in some other representation MUST be converted 982 to canonical UTF-8 before being placed in any Multicast DNS packet. 984 18. Multicast DNS Message Format 986 This section describes specific restrictions on the allowable 987 values for the header fields of a Multicast DNS message. 989 18.1. ID (Query Identifier) 991 Multicast DNS clients SHOULD listen for gratuitous responses 992 issued by hosts booting up (or waking up from sleep or otherwise 993 joining the network). Since these gratuitous responses may contain a 994 useful answer to a question for which the client is currently 995 awaiting an answer, Multicast DNS clients SHOULD examine all received 996 Multicast DNS response messages for useful answers, without regard to 997 the contents of the ID field or the question section. In multicast 998 DNS, knowing which particular query message (if any) is responsible 999 for eliciting a particular response message is less interesting than 1000 knowing whether the response message contains useful information. 1002 Multicast DNS clients MAY cache any or all Multicast DNS response 1003 messages they receive, for possible future use, providing of course 1004 that normal TTL aging is performed on these cashed resource records. 1006 In multicast query messages, the Query ID SHOULD be set to zero on 1007 transmission. 1009 In multicast responses, including gratuitous multicast responses, the 1010 Query ID MUST be set to zero on transmission, and MUST be ignored on 1011 reception. 1013 In unicast response messages generated specifically in response to a 1014 particular (unicast or multicast) query, the Query ID MUST match the 1015 ID from the query message. 1017 18.2. QR (Query/Response) Bit 1019 In query messages, MUST be zero. 1021 In response messages, MUST be one. 1023 18.3. OPCODE 1025 In both multicast query and multicast response messages, MUST be zero 1026 (only standard queries are currently supported over multicast, unless 1027 other queries are allowed by future IETF Standards Action). 1029 18.4. AA (Authoritative Answer) Bit 1031 In query messages, the Authoritative Answer bit MUST be zero on 1032 transmission, and MUST be ignored on reception. 1034 In response messages for Multicast Domains, the Authoritative Answer 1035 bit MUST be set to one (not setting this bit implies there's some 1036 other place where "better" information may be found) and MUST be 1037 ignored on reception. 1039 18.5. TC (Truncated) Bit 1041 In query messages, if the TC bit is set, it means that additional 1042 Known Answer records may be following shortly. A responder MAY choose 1043 to record this fact, and wait for those additional Known Answer 1044 records, before deciding whether to reply. If the TC bit is clear, 1045 it means that the querying host has no additional Known Answers. 1047 In response messages, the TC bit MUST be zero on transmission, 1048 and MUST be ignored on reception. 1050 18.6. RD (Recursion Desired) Bit 1052 In both multicast query and multicast response messages, the 1053 Recursion Desired bit SHOULD be zero on transmission, and MUST be 1054 ignored on reception. 1056 18.7. RA (Recursion Available) Bit 1058 In both multicast query and multicast response messages, the 1059 Recursion Available bit MUST be zero on transmission, and MUST be 1060 ignored on reception. 1062 18.8. Z (Zero) Bit 1064 In both query and response messages, the Zero bit MUST be zero on 1065 transmission, and MUST be ignored on reception. 1067 18.9. AD (Authentic Data) Bit [RFC 2535] 1069 In query messages the Authentic Data bit MUST be zero on 1070 transmission, and MUST be ignored on reception. 1072 In response messages, the Authentic Data bit MAY be set. Resolvers 1073 receiving response messages with the AD bit set MUST NOT trust the AD 1074 bit unless they trust the source of the message and either have a 1075 secure path to it or use DNS transaction security. 1077 18.10. CD (Checking Disabled) Bit [RFC 2535] 1079 In query messages, a resolver willing to do cryptography SHOULD set 1080 the Checking Disabled bit to permit it to impose its own policies. 1082 In response messages, the Checking Disabled bit MUST be zero on 1083 transmission, and MUST be ignored on reception. 1085 18.11. RCODE (Response Code) 1087 In both multicast query and multicast response messages, the Response 1088 Code MUST be zero on transmission. Multicast DNS messages received 1089 with non-zero Response Codes MUST be silently ignored. 1091 19. Choice of UDP Port Number 1093 Arguments were made for and against using Multicast on UDP port 53. 1094 The final decision was to use UDP port 5353. Some of the arguments 1095 for and against are given below. 1097 19.1 Arguments for using UDP port 53: 1099 * This is "just DNS", so it should be the same port. 1101 * There is less work to be done updating old clients to do simple 1102 mDNS queries. Only the destination address need be changed. 1103 In some cases, this can be achieved without any code changes, 1104 just by adding the address 224.0.0.251 to a configuration file. 1106 19.2 Arguments for using a different port (UDP port 5353): 1108 * This is not "just DNS". This is a DNS-like protocol, but different. 1110 * Changing client code to use a different port number is not hard. 1112 * Using the same port number makes it hard to run an mDNS Responder 1113 and a conventional unicast DNS server on the same machine. If a 1114 conventional unicast DNS server wishes to implement mDNS as well, 1115 it can still do that, by opening two sockets. Having two different 1116 port numbers is important to allow this flexibility. 1118 * Some VPN software hijacks all outgoing traffic to port 53 and 1119 redirects it to a special DNS server set up to serve those VPN 1120 clients while they are connected to the corporate network. It is 1121 questionable whether this is the right thing to do, but it is 1122 common, and redirecting link-local multicast DNS packets to a 1123 remote server rarely produces any useful results. It does mean, for 1124 example, that the user becomes unable to access their local network 1125 printer sitting on their desk right next to their computer. Using 1126 a different UDP port eliminates this particular problem. 1128 * On many operating systems, unprivileged clients may not send or 1129 receive packets on low-numbered ports. This means that any client 1130 sending or receiving mDNS packets on port 53 would have to run as 1131 "root", which is an undesirable security risk. Using a higher- 1132 numbered UDP port eliminates this particular problem. 1134 20. Summary of Differences Between Multicast DNS and Unicast DNS 1136 The value of Multicast DNS is that it shares, as much as possible, 1137 the familiar APIs, naming syntax, resource record types, etc., of 1138 Unicast DNS. There are of course necessary differences by virtue of 1139 it using Multicast, and by virtue of it operating in a community of 1140 cooperating peers, rather than a precisely defined authoritarian 1141 hierarchy controlled by a strict chain of formal delegations from the 1142 top. These differences are listed below: 1144 Multicast DNS... 1145 * uses multicast (of course!) 1146 * uses UDP port 5353 instead of port 53 1147 * operates in well-defined parts of the DNS namespace 1148 * uses UTF-8, and only UTF-8, to encode resource record names 1149 * allows more than one question in a query packet 1150 * uses the Answer Section of a query to list Known Answers 1151 * uses the TC bit in a query to indicate additional Known Answers 1152 * uses the Authority Section of a query for probe tie-breaking 1153 * ignores the Query ID field (except for generating legacy responses) 1154 * uses gratuitous responses to announce new records to the peer group 1155 * defines a "cache flush" bit in the rrclass of responses 1156 * monitors queries to perform Duplicate Question Suppression 1157 * monitors responses to perform Duplicate Answer Suppression... 1158 * ... and Ongoing Conflict Detection 1159 * ... and Opportunistic Caching 1161 21. IPv6 Considerations 1163 An IPv4-only host and an IPv6-only host behave as "ships that pass in 1164 the night". Even if they are on the same Ethernet, neither is aware 1165 of the other's traffic. For this reason, each physical link may have 1166 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 1167 Since for practical purposes, a group of IPv4-only hosts and a group 1168 of IPv6-only hosts on the same Ethernet act as if they were on two 1169 entirely separate Ethernet segments, it is unsurprising that their 1170 use of the ".local." zone should occur exactly as it would if 1171 they really were on two entirely separate Ethernet segments. 1173 A dual-stack (v4/v6) host can participate in both ".local." 1174 zones, and should register its name(s) and perform its lookups both 1175 using IPv4 and IPv6. This enables it to reach, and be reached by, 1176 both IPv4-only and IPv6-only hosts. In effect this acts like a 1177 multi-homed host, with one connection to the logical "IPv4 Ethernet 1178 segment", and a connection to the logical "IPv6 Ethernet segment". 1180 21.1 IPv6 Multicast Addresses by Hashing 1182 Some discovery protocols use a range of multicast addresses, and 1183 determine the address to be used by a hash function of the name being 1184 sought. Queries are sent via multicast to the address as indicated by 1185 the hash function, and responses are returned to the querier via 1186 unicast. Particularly in IPv6, where multicast addresses are 1187 extremely plentiful, this approach is frequently advocated. 1189 There are some problems with this: 1191 * When a host has a large number of records with different names, the 1192 host may have to join a large number of multicast groups. This can 1193 place undue burden on the Ethernet hardware, which typically 1194 supports a limited number of multicast addresses efficiently. When 1195 this number is exceeded, the Ethernet hardware may have to resort 1196 to receiving all multicasts and passing them up to the host 1197 software for filtering, thereby defeating the point of using a 1198 multicast address range in the first place. 1200 * Multiple questions cannot be placed in one packet if they don't all 1201 hash to the same multicast address. 1203 * Duplicate Question Suppression doesn't work if queriers are not 1204 seeing each other's queries. 1206 * Duplicate Answer Suppression doesn't work if responders are not 1207 seeing each other's responses. 1209 * Opportunistic Caching doesn't work. 1211 * Ongoing Conflict Detection doesn't work. 1213 22. Security Considerations 1215 DNSSEC [RFC 2535] should be used where the authenticity of 1216 information is important. 1218 When DNS queries for global DNS names are sent to the mDNS multicast 1219 address (during network outages which disrupt communication with the 1220 greater Internet) it is *especially* important to use DNSSEC, because 1221 the user may have the impression that he or she is communicating with 1222 some authentic host, when in fact he or she is really communicating 1223 with some local host that is merely masquerading as that name. This 1224 is less critical for names ending with ".local.", because the user 1225 should be aware that those names have only local significance and no 1226 global authority is implied. 1228 Most computer users neglect to type the trailing dot at the end of a 1229 fully qualified domain name, making it a relative domain name (e.g. 1230 "www.example.com"). In the event of network outage, attempts to 1231 positively resolve the name as entered will fail, resulting in 1232 application of the search list, including ".local.", if present. 1233 A malicious host could masquerade as "www.example.com" by answering 1234 the resulting Multicast DNS query for "www.example.com.local." 1235 To avoid this, a host MUST NOT append the search suffix 1236 ".local.", if present, to any relative (partially qualified) 1237 domain name containing two or more labels. Appending ".local." to 1238 single-label relative domain names is acceptable, since the user 1239 should have no expectation that a single-label domain name will 1240 resolve as-is. 1242 23. IANA Considerations 1244 The IANA has allocated the IPv4 link-local multicast address 1245 224.0.0.251 for the use described in this document. 1247 The IANA has allocated the IPv6 multicast address set FF0X::FB 1248 for the use described in this document. 1250 When this document is published, IANA should designate a list 1251 of domains which are deemed to have only link-local significance, 1252 as described in this document. 1254 No other IANA services are required by this document. 1256 24. Copyright 1258 Copyright (C) The Internet Society 20th December 2002. 1259 All Rights Reserved. 1261 This document and translations of it may be copied and furnished to 1262 others, and derivative works that comment on or otherwise explain it 1263 or assist in its implementation may be prepared, copied, published 1264 and distributed, in whole or in part, without restriction of any 1265 kind, provided that the above copyright notice and this paragraph are 1266 included on all such copies and derivative works. However, this 1267 document itself may not be modified in any way, such as by removing 1268 the copyright notice or references to the Internet Society or other 1269 Internet organizations, except as needed for the purpose of 1270 developing Internet standards in which case the procedures for 1271 copyrights defined in the Internet Standards process must be 1272 followed, or as required to translate it into languages other than 1273 English. 1275 The limited permissions granted above are perpetual and will not be 1276 revoked by the Internet Society or its successors or assigns. 1278 This document and the information contained herein is provided on an 1279 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1280 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1281 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1282 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1283 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1285 25. Normative References 1287 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 1288 Facilities", STD 13, RFC 1034, November 1987. 1290 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 1291 Specifications", STD 13, RFC 1035, November 1987. 1293 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1294 Requirement Levels", RFC 2119, March 1997. 1296 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO 1297 10646", RFC 2279, January 1998. 1299 26. Informative References 1301 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 1302 Overview and Architecture. 1303 Institute of Electrical and Electronic Engineers, 1304 IEEE Standard 802, 1990. 1306 [DNS-SD] Cheshire, S. "DNS-Based Service Discovery", Internet-Draft 1307 (work in progress), draft-cheshire-dnsext-dns-sd-00.txt, 1308 December 2002. 1310 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 1311 System (DNS UPDATE)", RFC 2136, April 1997. 1313 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address 1314 Autoconfiguration", RFC 2462, December 1998. 1316 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", 1317 RFC 2535, March 1999. 1319 [v4LL] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic 1320 Configuration of IPv4 Link-Local Addresses", 1321 Internet-Draft (work in progress), 1322 draft-ietf-zeroconf-ipv4-linklocal-07.txt, August 2002. 1324 [ZC] Williams, A., "Requirements for Automatic Configuration 1325 of IP Hosts", Internet-Draft (work in progress), 1326 draft-ietf-zeroconf-reqts-12.txt, September 2002. 1328 27. Author's Address 1330 Stuart Cheshire 1331 Apple Computer, Inc. 1332 1 Infinite Loop 1333 Cupertino 1334 California 95014 1335 USA 1337 Phone: +1 408 974 3207 1338 EMail: rfc@stuartcheshire.org