idnits 2.17.1 draft-cheshire-dnsext-multicastdns-03.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 (January 2003) is 7744 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 1895, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 1898, 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-03 -- 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-03.txt Stuart Cheshire 2 Category: Standards Track Apple Computer, Inc. 3 Expires 29th July 2004 Marc Krochmal 4 Apple Computer, Inc. 5 29th January 2003 7 Multicast DNS 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 DNS resource record data types (including, but not limited 38 to, host names) in the absence of a conventional managed DNS server, 39 is becoming essential. 41 Multicast DNS (mDNS) provides the ability to do DNS-like operations 42 on the local link in the absense of any conventional unicast DNS 43 server. In addition, mDNS designates a portion of the DNS namespace 44 to be free for local use, without the need to pay any annual fee, and 45 without the need to set up delegations or otherwise configure a 46 conventional DNS server to answer for those names. 48 The primary benefits of mDNS names are that (i) they require little 49 or no administration or configuration to set them up, (ii) they work 50 when no infrastructure is present, and (iii) they work during 51 infrastructure failures. 53 Table of Contents 55 1. Introduction...................................................3 56 2. Conventions and Terminology Used in this Document..............4 57 3. Multicast DNS Names............................................4 58 4. IP TTL Checks..................................................8 59 5. Reverse Address Mapping........................................8 60 6. Querying.......................................................9 61 7. Duplicate Suppression.........................................13 62 8. Responding....................................................15 63 9. Probing and Announcing on Startup.............................17 64 10. Conflict Resolution...........................................21 65 11. Special Characteristics of Multicast DNS Domains..............23 66 12. Multicast DNS for Service Discovery...........................24 67 13. Resource Record TTL Values and Cache Coherency................25 68 14. Enabling and Disabling Multicast DNS..........................30 69 15. Considerations for Multiple Interfaces........................30 70 16. Multicast DNS and Power Management............................31 71 17. Multicast DNS Character Set...................................32 72 18. Multicast DNS Message Size....................................33 73 19. Multicast DNS Message Format..................................33 74 20. Choice of UDP Port Number.....................................36 75 21. Summary of Differences Between Multicast DNS and Unicast DNS..37 76 22. Benefits of Multicast Responses...............................38 77 23. IPv6 Considerations...........................................39 78 24. Security Considerations.......................................40 79 25. IANA Considerations...........................................41 80 26. Acknowledgements..............................................41 81 27. Copyright.....................................................41 82 28. Normative References..........................................42 83 29. Informative References........................................42 84 30. Author's Addresses............................................43 86 1. Introduction 88 When reading this document, familiarity with the concepts of Zero 89 Configuration Networking [ZC] and automatic link-local addressing 90 [v4LL] [RFC 2462] is helpful. 92 This document proposes no change to the structure of DNS messages, 93 and no new operation codes, response codes, or resource record types. 94 This document simply discusses what needs to happen if DNS clients 95 start sending DNS queries to a multicast address, and how a 96 collection of hosts can cooperate to collectively answer those 97 queries in a useful manner. 99 There has been discussion of how much burden Multicast DNS might 100 impose on a network. It should be remembered that whenever IPv4 hosts 101 communicate, they broadcast ARP packets on the network on a regular 102 basis, and this is not disastrous. The approximate amount of 103 multicast traffic generated by hosts making conventional use of 104 Multicast DNS is anticipated to be roughly the same order of 105 magnitude as the amount of broadcast ARP traffic those hosts already 106 generate. 108 New applications making new use of Multicast DNS capabilities for 109 unconventional purposes may generate more traffic. If some of those 110 new applications are "chatty", then work will be needed to help them 111 become less chatty. When performing any analysis, it is important to 112 make a distinction between the application behavior and the 113 underlying protocol behavior. If a chatty application uses UDP, that 114 doesn't mean that UDP is chatty, or that IP is chatty, or that 115 Ethernet is chatty. What it means is that the application is chatty. 116 The same applies to any future applications that may decide to layer 117 increasing portions of their functionality over Multicast DNS. 119 2. Conventions and Terminology Used in this Document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in "Key words for use in 124 RFCs to Indicate Requirement Levels" [RFC 2119]. 126 This document uses the term "host name" in the strict sense to mean a 127 fully qualified domain name that has an address record. It does not 128 use the term "host name" in the commonly used but incorrect sense to 129 mean just the first DNS label of a host's fully qualified domain 130 name. 132 A DNS (or mDNS) packet contains an IP TTL in the IP header, which 133 is effectively a hop-count limit for the packet, to guard against 134 routing loops. Each Resource Record also contains a TTL, which is 135 the number of seconds for which the Resource Record may be cached. 137 In any place where there may be potential confusion between these two 138 types of TTL, the term "IP TTL" is used to refer to the IP header TTL 139 (hop limit), and the term "RR TTL" is used to refer to the Resource 140 Record TTL (cache lifetime). 142 When this document uses the term "Multicast DNS", it should be taken 143 to mean: Clients performing DNS-like queries for DNS-like resource 144 records by sending DNS-like UDP query and response packets over IP 145 Multicast to UDP port 5353." 147 3. Multicast DNS Names 149 This document proposes that the DNS top-level domain ".local." be 150 designated a special domain with special semantics, namely that any 151 fully-qualified name ending in ".local." is link-local, and names 152 within this domain are meaningful only on the link where they 153 originate. This is analogous to IPv4 addresses in the 169.254/16 154 prefix, which are link-local and meaningful only on the link where 155 they originate. 157 Any DNS query for a name ending with ".local." MUST be sent 158 to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent 159 FF02::FB). 161 It is unimportant whether a name ending with ".local." occurred 162 because the user explicitly typed in a fully qualified domain name 163 ending in ".local.", or because the user entered an unqualified 164 domain name and the host software appended the suffix ".local." 165 because that suffix appears in the user's search list. The ".local." 166 suffix could appear in the search list because the user manually 167 configured it, or because it was received in a DHCP option, or via 168 any other valid mechanism for configuring the DNS search list. In 169 this respect the ".local." suffix is treated no differently to any 170 other search domain that might appear in the DNS search list. 172 DNS queries for names that do not end with ".local." MAY be sent to 173 the mDNS multicast address, if no other conventional DNS server is 174 available. This can allow hosts on the same link to continue 175 communicating using each other's globally unique DNS names during 176 network outages which disrupt communication with the greater 177 Internet. When resolving global names via local multicast, it is even 178 more important to use DNSSEC or other security mechanisms to ensure 179 that the response is trustworthy. Resolving global names via local 180 multicast is a contentious issue, and this document does not discuss 181 it in detail, instead concentrating on the issue of resolving local 182 names using DNS packets sent to a multicast address. 184 A host which belongs to an organization or individual who has control 185 over some portion of the DNS namespace can be assigned a globally 186 unique name within that portion of the DNS namespace, for example, 187 "cheshire.apple.com." For those of us who have this luxury, this 188 works very well. However, the majority of home customers do not have 189 easy access to any portion of the global DNS namespace within which 190 they have the authority to create names as they wish. This leaves the 191 majority of home computers effectively anonymous for practical 192 purposes. 194 To remedy this problem, this document allows any computer user to 195 elect to give their computers link-local Multicast DNS host names of 196 the form: "single-dns-label.local." For example, my Titanium 197 PowerBook laptop computer answers to the name "sctibook.local." Any 198 computer user is granted the authority to name their computer this 199 way, providing that the chosen host name is not already in use on 200 that link. Having named their computer this way, the user has the 201 authority to continue using that name until such time as a name 202 conflict occurs on the link which is not resolved in the user's 203 favour. If this happens, the computer (or its human user) SHOULD 204 cease using the name, and may choose to attempt to allocate a new 205 unique name for use on that link. Like law suits over global DNS 206 names, these conflicts are expected to be relatively rare for people 207 who choose reasonably imaginative names, but it is still important 208 to have a mechanism in place to handle them when they happen. 210 The point made in the previous paragraph is very important and bears 211 repeating. It is easy for those of us in the IETF community who run 212 our own name servers at home to forget that the majority of computer 213 users do not run their own name server and have no easy way to create 214 their own host names. When these users wish to transfer files between 215 two laptop computers, they are frequently reduced to typing in 216 dotted-decimal IP addresses because they simply have no other way for 217 one host to refer to the other by name. This is a sorry state of 218 affairs. What is worse, most users don't even bother trying to use 219 dotted-decimal IP addresses. Most users still move data between 220 machines by copying it onto a floppy disk or similar removable media. 222 In a world of gigabit Ethernet and ubiquitous wireless networking it 223 is a sad indictment of the networking community that the preferred 224 communication medium for most computer users is still the floppy 225 disk. 227 Allowing ad-hoc allocation of single-label names in a single flat 228 ".local." namespace may seem to invite chaos. However, operational 229 experience with AppleTalk NBP names, which on any given link are also 230 effectively single-label names in a flat namespace, shows that in 231 practice name collisions happen extremely rarely and are not a 232 problem. Groups of computer users from disparate organizations bring 233 Macintosh laptop computers to events such as IETF Meetings, the Mac 234 Hack conference, the Apple World Wide Developer Conference, etc., and 235 complaints at these events about users suffering conflicts and being 236 forced to rename their machines have never been an issue. 238 Enforcing uniqueness of host names (i.e. the names of DNS address 239 records mapping names to IP addresses) is probably desirable in the 240 common case, but this document does not mandate that. It is 241 permissible for a collection of coordinated hosts to agree to 242 maintain multiple DNS address records with the same name, possibly 243 for load balancing or fault-tolerance reasons. This document does not 244 take a position on whether that is sensible. It is important that 245 both modes of operation are supported. The Multicast DNS protocol 246 allows hosts to verify and maintain unique names for resource records 247 where that behaviour is desired, and it also allows hosts to maintain 248 multiple resource records with a single shared name where that 249 behaviour is desired. This consideration applies to all resource 250 records, not just address records (host names). In summary: It is 251 required that the protocol have the ability to detect and handle name 252 conflicts, but it is not required that this ability be used for every 253 record. 255 3.1 Governing Standards Body 257 Note that this use of the ".local." suffix falls under IETF 258 jurisdiction, not ICANN jurisdiction. DNS is an IETF network 259 protocol, governed by protocol rules defined by the IETF. These IETF 260 protocol rules dictate character set, maximum name length, packet 261 format, etc. ICANN determines additional rules that apply when the 262 IETF's DNS protocol is used on the public Internet. In contrast, 263 private uses of the DNS protocol on isolated private networks are not 264 governed by ICANN. Since this proposed change is a change to the core 265 DNS protocol rules, it affects everyone, not just those machines 266 using the ICANN-governed Internet. Hence this change falls into the 267 category of an IETF protocol rule, not an ICANN usage rule. 269 3.2 Private DNS Namespaces 271 Note also that the special treatment of names ending in ".local." has 272 been implemented in Macintosh computers since the days of Mac OS 9, 273 and continues today in Mac OS X. There are also implementations for 274 Linux and other platforms [dotlocal]. Operators setting up private 275 internal networks ("intranets") are advised that their lives may be 276 easier if they avoid using the suffix ".local." in names in their 277 private internal DNS server. Alternative possibilities include: 279 .intranet 280 .internal 281 .private 282 .corp 283 .home 285 Another alternative naming scheme, advocated by Professor D. J. 286 Bernstein, is to use a numerical suffix, such as ".6." [djbdl]. 288 3.3 Maximum Multicast DNS Name Length 290 RFC 1034 says: 292 "the total number of octets that represent a domain name (i.e., 293 the sum of all label octets and label lengths) is limited to 255." 295 This text implies that the final root label at the end of every name 296 is included in this count (a name can't be represented without it), 297 but the text does not explicitly state that. Implementations of 298 Multicast DNS MUST include the label length byte of the final root 299 label at the end of every name when enforcing the rule that no name 300 may be longer than 255 bytes. For example, the length of the name 301 "apple.com." is considered to be 11, which is the number of bytes it 302 takes to represent that name in a packet without using name 303 compression: 305 ------------------------------------------------------ 306 | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 | 307 ------------------------------------------------------ 309 4. IP TTL Checks 311 All Multicast DNS responses (including responses sent via unicast) 312 MUST be sent with IP TTL set to 255. 314 A host sending Multicast DNS queries to a link-local destination 315 address (including the 224.0.0.251 link-local multicast address) MUST 316 verify that the IP TTL in response packets is 255, and silently 317 discard any response packets where the IP TTL is not 255. Without 318 this check, it could be possible for remote rogue hosts to send 319 spoof answer packets (perhaps unicast to the victim host) which the 320 receiving machine could misinterpret as having originated on the 321 local link. 323 The authors have heard complaints that some older network stack 324 implementations do not implement the IP_RECVTTL socket option 325 (or equivalent API) for obtaining the IP TTL of received packets. 326 This is unfortunate, and these old network stacks would benefit 327 from adding this API support so that they may benefit from this 328 enhanced protection against spoof packets arriving from off-link. 330 Note that Multicast DNS Responders SHOULD NOT discard queries with 331 TTLs other than 255. There may be valid future applications of 332 Multicast DNS where hosts issue unicast queries directed at Multicast 333 DNS Responders more than one hop away, if Multicast DNS Responders 334 were to discard queries where the TTL is not 255, they would not 335 answer these queries. 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 343 be 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. As an optimization, these queries MAY be first 347 unicast directly to the address in question, but if this query is not 348 answered, the query MUST also be sent via multicast, to accommodate 349 the case where the machine in question is not answering for itself 350 (for example, because it is currently sleeping). 352 Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa." 353 MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB, 354 with or without an optional initial query unicast directly to the 355 address in question. 357 6. Querying 359 There are three kinds of Multicast DNS Queries, one-shot queries of 360 the kind made by today's conventional DNS clients, one-shot queries 361 accumulating multiple responses made by multicast-aware DNS clients, 362 and continuous ongoing Multicast DNS Queries used by IP network 363 browser software. 365 A Multicast DNS Responder that is offering records that are intended 366 to be unique on the local link MUST also implement a Multicast DNS 367 Querier so that it can first verify the uniqueness of those records 368 before it begins answering queries for them. 370 6.1 One-Shot Queries 372 An unsophisticated DNS client may simply send its DNS queries 373 blindly to the 224.0.0.251 multicast address, without necessarily 374 even being aware what a multicast address is. 376 Such an unsophisticated DNS client may not get ideal behaviour. Such 377 a client may simply take the first response it receives and fail to 378 wait to see if there are more, but in many instances this may not be 379 a serious problem. If a user types "http://stu.local." into their Web 380 browser and gets to see the page they were hoping for, then the 381 protocol has met the user's needs in this case. 383 6.2 One-Shot Queries, Accumulating Multiple Responses 385 A more sophisticated DNS client should understand that Multicast DNS 386 is not exactly the same as unicast DNS, and should modify its 387 behaviour in some simple ways. 389 As described above, there are some cases, such as looking up the 390 address associated with a unique host name, where a single response 391 is sufficient, and moreover may be all that is expected. However, 392 there are other DNS queries where more than one response is 393 possible, and for these queries a more sophisticated Multicast DNS 394 client should include the ability to wait for an appropriate period 395 of time to collect multiple responses. 397 A naive DNS client retransmits its query only so long as it has 398 received no response. A more sophisticated Multicast DNS client is 399 aware that having received one response is not necessarily an 400 indication that it might not receive others, and has the ability to 401 retransmit its query an appropriate number of times at appropriate 402 intervals until it is satisfied with the collection of responses it 403 has gathered. 405 A more sophisticated Multicast DNS client that is retransmitting 406 a query for which it has already received some responses, MUST 407 implement Known Answer Suppression, as described below in Section 408 7.1. This indicates to responders who have already replied that their 409 responses have been received, and they don't need to send them again 410 in response to this repeated query. In addition, the interval between 411 the first two queries MUST be at least one second, and the 412 intervals between subsequent queries MUST double. 414 6.3 Continuous Querying 416 In One-Shot Queries, with either a single or multiple responses, 417 the underlying assumption is that the transaction begins when the 418 application issues a query, and ends when all the desired responses 419 have been received. There is another type of operation which is more 420 akin to continuous monitoring. 422 Macintosh users are accustomed to opening the "Chooser" window, 423 selecting a desired printer, and then closing the Chooser window. 424 However, when the desired printer does not appear in the list, the 425 user will typically leave the "Chooser" window open while they go and 426 check to verify that the printer is plugged in, powered on, connected 427 to the Ethernet, etc. While the user jiggles the wires, hits the 428 Ethernet hub, and so forth, they keep an eye on the Chooser window, 429 and when the printer name appears, they know they have fixed whatever 430 the problem was. This can be a useful and intuitive troubleshooting 431 technique, but a user who goes home for the weekend leaving the 432 Chooser window open places a non-trivial burden on the network. 434 With continuous querying, multiple queries are sent over a long 435 period of time, until the user terminates the operation. It is 436 important that an IP network browser window displaying live 437 information from the network using Multicast DNS, if left running for 438 an extended period of time, should generate significantly less 439 multicast traffic on the network than the old AppleTalk Chooser. 440 Therefore, the interval between the first two queries MUST be at 441 least one second, the intervals between subsequent queries MUST 442 double, and the querier MUST implement Known Answer Suppression, as 443 described below in Section 7.1. 445 When a Multicast DNS Querier receives an answer, the answer contains 446 a TTL value that indicates for how many seconds this answer is valid. 447 After this interval has passed, the answer will no longer be valid 448 and should be deleted from the cache. Before this time is reached, a 449 Multicast DNS Querier with an ongoing interest in that record SHOULD 450 re-issue its query to determine whether the record is still valid, 451 and if so update its expiry time. 453 To perform this cache maintenance, a Multicast DNS Querier should 454 plan to issue a query at 80% of the record lifetime, and then if no 455 answer is received, at 85%, 90% and 95%. If an answer is received, 456 then the remaining TTL is reset to the value given in the answer, and 457 this process repeats for as long as the Multicast DNS Querier has an 458 ongoing interest in the record. If after four queries no answer is 459 received, the record is deleted when it reaches 100% of its lifetime. 461 To avoid the case where multiple Multicast DNS Queriers on a network 462 all issue their queries simultaneously, a random variation of 2% of 463 the record TTL should be added, so that queries are scheduled to be 464 performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL. 466 6.4 Multiple Questions per Query 468 Multicast DNS allows a querier to place multiple questions in the 469 question section of a single Multicast DNS query packet. 471 The semantics of a Multicast DNS query packet containing multiple 472 questions is identical to a series of individual DNS query packets 473 containing one question each. Combining multiple questions into a 474 single packet is purely an efficiency optimization, and has no other 475 semantic significance. 477 A useful technique for adaptively combining multiple questions into a 478 single query is to use a Nagle-style algorithm: When a client issues 479 its first question, a Query packet is immediately built and sent, 480 without delay. If the client then continues issuing a rapid series of 481 questions they are held until either the first query receives at 482 least one answer, or 100ms has passed, or there are enough questions 483 to fill the question section of a Multicast DNS query packet. At this 484 time, all the held questions are placed into a Multicast DNS query 485 packet and sent. 487 6.5 Questions Requesting Unicast Responses 489 Sending Multicast DNS responses via multicast has the benefit that 490 all the other hosts on the network get to see those responses, and 491 can keep their caches up to date, and detect conflicting responses. 493 However, there are situations where all the other hosts on the 494 network don't need to see every response. One example is a laptop 495 computer waking from sleep. At that instant it is a brand new 496 participant on a new network. Its Multicast DNS cache is empty, and 497 it has no knowledge of its surroundings. It may have a significant 498 number of queries that it wants answered right away to discover 499 information about its new surroundings and present that information 500 to the user. As a new participant on the network, it has no idea 501 whether the exact same questions may have been asked and answered 502 just seconds ago. In this case, trigging a large sudden flood of 503 multicast responses may impose an unreasonable burden on the network. 504 To avoid this, the Multicast DNS Querier SHOULD set the top bit in 505 the class field of its DNS question(s), to indicate that it is 506 willing to accept unicast responses instead of the usual multicast 507 responses. These questions requesting unicast responses are referred 508 to as "QU" questions, to distinguish them from the more usual 509 questions requesting multicast responses ("QM" questions). 511 When retransmitting a question more than once, the 'unicast response' 512 bit SHOULD be set only for the first question of the series. After 513 the first question has received its responses, the querier should 514 have a large known-answer list (see "Known Answer Suppression" below) 515 so that subsequent queries should elicit few, if any, further 516 responses. Reverting to multicast responses as soon as possible is 517 important because of the benefits that multicast responses provide 518 (see "Benefits of Multicast Responses" below). 520 When receiving a question with the 'unicast response' bit set, a 521 responder SHOULD usually respond with a unicast packet directed back 522 to the querier. If the responder has not multicast that record 523 recently (within one quarter of its TTL), then the responder SHOULD 524 instead multicast the response so as to keep all the peer caches up 525 to date, and to permit passive conflict detection. 527 6.6 Suppressing Initial Query 529 If a query is issued for which there already exist one or more 530 records in the local cache, and those record(s) were received with 531 the cache flush bit set, indicating that they form a unique RRSet, 532 then the host SHOULD suppress its initial "QU" query, and proceed to 533 issue a "QM" query. To avoid the situation where a group of hosts 534 are synchronized by some external event and all perform the same 535 query simultaneously, a host suppressing its initial "QU" query 536 SHOULD impose a random delay from 500-1000ms before transmitting its 537 first "QM" query for this question. This means that when the first 538 host (selected randomly by this algorithm) transmits its "QM" query, 539 all the other hosts that were about to transmit the same query can 540 suppress their superfluous query, as described in "Duplicate 541 Question Suppression" below. 543 7. Duplicate Suppression 545 A variety of techniques are used to reduce the amount of redundant 546 traffic on the network. 548 7.1 Known Answer Suppression 550 When a Multicast DNS Querier sends a query to which it already knows 551 some answers, it populates the Answer Section of the DNS message with 552 those answers. 554 A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if 555 the answer it would give is already included in the Answer Section 556 with an RR TTL at least half the correct value. If the RR TTL of the 557 answer as given in the Answer Section is less than half of the true 558 RR TTL as known by the Multicast DNS Responder, the responder MUST 559 send an answer so as to update the Querier's cache before the record 560 becomes in danger of expiration. 562 Because a Multicast DNS Responder will respond if the remaining TTL 563 given in the known answer list is less than half the true TTL, it is 564 superfluous for the Querier to include such records in the known 565 answer list. Therefore a Multicast DNS Querier SHOULD NOT include 566 records in the known answer list whose remaining TTL is less than 567 half their original TTL. Doing so would simply consume space in the 568 packet without achieving the goal of suppressing responses, and would 569 therefore be a pointless waste of network bandwidth. 571 A Multicast DNS Querier MUST NOT cache resource records observed in 572 the Known Answer Section of other Multicast DNS Queries. The Answer 573 Section of Multicast DNS Queries is not authoritative. By placing 574 information in the Answer Section of a Multicast DNS Query the 575 querier is stating that it *believes* the information to be true. 576 It is not asserting that the information *is* true. Some of those 577 records may have come from other hosts that are no longer on the 578 network. Propagating that stale information to other Multicast DNS 579 Queriers on the network would not be helpful. 581 7.2 Multi-Packet Known Answer Suppression 583 Sometimes a Multicast DNS Querier will already have too many answers 584 to fit in the Known Answer section of its query packets. In this 585 case, it should issue a Multicast DNS Query containing a question and 586 as many Known Answer records as will fit. It should then set the TC 587 (Truncated) bit in the header before sending the Query. It should 588 then immediately follow the packet with another query containing no 589 questions, and as many more Known Answer records as will fit. If 590 there are still too many records remaining to fit in the packet, it 591 again sets the TC bit and continues until all the Known Answer 592 records have been sent. 594 A Multicast DNS Responder seeing a Multicast DNS Query with the TC 595 bit set defers its response for a time period randomly selected in 596 the interval 20-120ms. This gives the Multicast DNS Querier time to 597 send additional Known Answer packets before the Responder responds. 598 If the Responder sees any of its answers listed in the Known Answer 599 lists of subsequent packets from the querying host, it should delete 600 that answer from the list of answers it is planning to give, provided 601 that no other host on the network is also waiting to receive the same 602 answer record. 604 7.3 Duplicate Question Suppression 606 If a host is planning to send a query, and it sees another host on 607 the network send a query containing the same question, and the Known 608 Answer section of that query does not contain any records which this 609 host would not also put in its own Known Answer section, then this 610 host should treat its own query as having been sent. When multiple 611 clients on the network are querying for the same resource records, 612 there is no need for them to all be repeatedly asking the same 613 question. 615 7.4 Duplicate Answer Suppression 617 If a host is planning to send an answer, and it sees another host on 618 the network send a response packet containing the same answer record, 619 and the TTL in that record is not less than the TTL this host would 620 have given, then this host should treat its own answer as having been 621 sent. When multiple responders on the network have the same data, 622 there is no need for all of them to respond. 624 This feature is particularly useful when multiple Sleep Proxy Servers 625 are deployed (see Section 16. "Multicast DNS and Power Management"). 626 In the future it is possible that every general-purpose OS (Mac, 627 Windows, Linux, etc.) will implement Sleep Proxy Service as a matter 628 of course. In this case there could be a large number of Sleep Proxy 629 Servers on any given network, which is good for reliability and 630 fault-tolerance, but would be bad for the network if every Sleep 631 Proxy Server were to answer every query. 633 8. Responding 635 A Multicast DNS Responder MUST only respond when it has a positive 636 non-null response to send. Error responses must never be sent. The 637 non-existence of any name in a Multicast DNS Domain is ascertained by 638 the failure of any machine to respond to the Multicast DNS query, not 639 by NXDOMAIN errors. 641 Multicast DNS Responses MUST NOT contain any questions in the 642 Question Section. Any questions in the Question Section of a received 643 Multicast DNS Response MUST be silently ignored. Multicast DNS 644 Queriers receiving Multicast DNS Responses do not care what question 645 elicited the response; they care only that the information in the 646 response is true and accurate. 648 A Multicast DNS Responder on Ethernet [IEEE802] and similar shared 649 multiple access networks SHOULD delay its responses by a random 650 amount of time selected with uniform random distribution in the range 651 20-120ms. If multiple Multicast DNS Responders were all to respond 652 immediately to a particular query, a collision would be virtually 653 guaranteed. By imposing a small random delay, the number of 654 collisions is dramatically reduced. 120ms is a short enough time that 655 it is almost imperceptible to a human user, but long enough to 656 significantly reduce the risk of Ethernet collisions. On a full-sized 657 Ethernet using the maximum cable lengths allowed and the maximum 658 number of repeaters allowed, an Ethernet frame is vulnerable to 659 collisions during the transmission of its first 256 bits. On 10Mb/s 660 Ethernet, this equates to a vulnerable time window of 25.6us. 662 In the case where a Multicast DNS Responder has good reason to 663 believe that it will be the only responder on the link with a 664 positive non-null response, it SHOULD NOT impose the random delay 665 before responding, and SHOULD normally generate its response within 666 10ms. To do this safely, it MUST have previously verified that the 667 requested name, type and class in the DNS query are unique on this 668 link. Responding immediately without delay is appropriate for things 669 like looking up the address record for a particular host name, when 670 the host name has been previously verified unique. Responding 671 immediately without delay is *not* appropriate for things like 672 looking up PTR records used for DNS Service Discovery [DNS-SD], where 673 a large number of responses may be anticipated. 675 Except when a unicast reply has been explicitly requested via the 676 "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port 677 5353 (the well-known port assigned to mDNS) on the 224.0.0.251 678 multicast address (or its IPv6 equivalent FF02::FB). Operating in a 679 Zeroconf environment requires constant vigilance. Just because a name 680 has been previously verified unique does not mean it will continue to 681 be so indefinitely. By allowing all Multicast DNS Responders to 682 constantly monitor their peers' responses, conflicts arising out of 683 network topology changes can be promptly detected and resolved. 685 Sending all responses by multicast also facilitates opportunistic 686 caching by other hosts on the network. 688 To protect the network against excessive packet flooding due to 689 software bugs or malicious attack, a Multicast DNS Responder MUST NOT 690 multicast a given record on a given interface if it has previously 691 multicast that record on that interface within the last second. A 692 legitimate client on the network should have seen the previous 693 transmission and cached it. A client that did not receive and cache 694 the previous transmission will retry its request and receive a 695 subsequent response. Under no circumstances is there any legitimate 696 reason for a Multicast DNS Responder to multicast a given record more 697 than once per second on any given interface. 699 8.1 Legacy Unicast Responses 701 If the source UDP port in a received Multicast DNS Query is not port 702 5353, this indicates that the client originating the query is a 703 simple client that does not fully implement all of Multicast DNS. In 704 this case, the Multicast DNS Responder MUST send a UDP response 705 directly back to the client, via unicast, to the query packet's 706 source IP address and port. This unicast response MUST be a 707 conventional unicast response as would be generated by a conventional 708 unicast DNS server; for example, it must repeat the query ID and the 709 question given in the query packet. 711 The resource record TTL given in a unicast response SHOULD NOT be 712 greater than ten seconds, even if the true TTL of the Multicast DNS 713 resource record is higher. This is because Multicast DNS Responders 714 that fully participate in the protocol use the cache coherency 715 mechanisms described in Section 13 to update and invalidate stale 716 data. Were unicast responses sent to legacy clients to use the same 717 high TTLs, these legacy clients, which do not implement these cache 718 coherency mechanisms, could retain stale cached resource record data 719 long after it is no longer valid. 721 Having sent this unicast response, if the Responder has not sent this 722 record in any multicast response recently, it SHOULD schedule the 723 record to be sent via multicast as well, to facilitate passive 724 conflict detection. "Recently" in this context means "if the time 725 since the record was last sent via multicast is less than one quarter 726 of the record's TTL". 728 8.2 Multi-Question Queries 730 Multicast DNS Responders MUST correctly handle DNS query packets 731 containing more than one question, by answering any or all of the 732 questions to which they have answers. Any answers generated 733 in response to query packets containing more than one question 734 MUST be randomly delayed in the range 20-120ms, as described above. 736 8.3 Response Aggregation 738 Having delayed one or more multicast responses by 20-120ms as 739 described above in Section 8 "Responding", a Multicast DNS Responder 740 SHOULD, for the sake of network efficiency, aggregate as many of its 741 pending responses as possible into a single Multicast DNS response 742 packet. 744 9. Probing and Announcing on Startup 746 Typically a Multicast DNS Responder should have, at the very least, 747 address records for all of its active interfaces. Creating and 748 advertising an HINFO record on each interface as well can be useful 749 to network administrators. 751 Whenever a Multicast DNS Responder starts up, wakes up from sleep, 752 receives an indication of an Ethernet "Link Change" event, or has any 753 other reason to believe that its network connectivity may have 754 changed in some relevant way, it MUST perform the two startup steps 755 below. 757 9.1 Probing 759 The first startup step is that for all those resource records that a 760 Multicast DNS Responder desires to be unique on the local link, it 761 MUST send a Multicast DNS Query asking for those resource records, to 762 see if any of them are already in use. The primary example of this is 763 its address record which maps its unique host name to its unique IP 764 address. All Probe Queries SHOULD be done using the desired resource 765 record name and query type T_ANY (255), to elicit answers for all 766 types of records with that name. This allows a single question to be 767 used in place of several questions, which is more efficient on the 768 network. It also allows a host to verify exclusive ownership of a 769 name, which is desirable in most cases. It would be confusing, for 770 example, if one host owned the "A" record for "myhost.local.", but a 771 different host owned the HINFO record for that name. 773 The ability to place more than one question in a Multicast DNS Query 774 is useful here, because it can allow a host to use a single packet 775 for all of its resource records instead of needing a separate packet 776 for each. For example, a host can simultaneously probe for uniqueness 777 of its "A" record and all its SRV records [DNS-SD] in the same query 778 packet. 780 When ready to send its mDNS probe packet(s) the host should first 781 wait for a short random delay time, uniformly distributed in the 782 range 0-250ms. This random delay is to guard against the case where a 783 group of devices are powered on simultaneously, or a group of devices 784 are connected to an Ethernet hub which is then powered on, or some 785 other external event happens that might cause a group of hosts to all 786 send synchronized probes. 788 250ms after the first query the host should send a second, then 789 250ms after that a third. If, by 250ms after the third probe, no 790 conflicting Multicast DNS responses have been received, the host may 791 move to the next step, announcing. 793 If any conflicting Multicast DNS responses are received, then the 794 probing host MUST defer to the existing host, and must choose new 795 names for some or all of its resource records as appropriate, to 796 avoid conflict with pre-existing hosts on the network. In the case 797 of a host probing using query type T_ANY as recommended above, any 798 answer containing a record with that name, of any type, MUST be 799 considered a conflicting response and handled accordingly. 801 If ten failures occur within any ten-second period, then the host 802 MUST wait at least five seconds before each successive additional 803 probe attempt. This is to help ensure that in the event of software 804 bugs or other unanticipated problems, errant hosts do not flood the 805 network with a continuous stream of multicast traffic. For very 806 simple devices, a valid way to comply with this requirement is to 807 always wait five seconds after any failed probe attempt. 809 9.2 Simultaneous Probe Tie-Breaking 811 The astute reader will observe that there is a race condition 812 inherent in the previous description. If two hosts are probing for 813 the same name simultaneously, neither will receive any response to 814 the probe, and the hosts could incorrectly conclude that they may 815 both proceed to use the name. To break this symmetry, each host 816 populates the Authority Section of its queries with records giving 817 the rdata that it would be proposing to use, should its probing be 818 successful. The Authority Section is being used here in a way 819 analogous to the Update section of a DNS Update packet [RFC 2136]. 821 When a host that is probing for a record sees another host issue a 822 query for the same record, it consults the Authority Section of that 823 query. If it finds any resource record there which answers the query, 824 then it compares the data of that resource record with its own 825 tentative data. The lexicographically later data wins. This means 826 that if the host finds that its own data is lexicographically later, 827 it simply ignores the other host's probe. If the host finds that its 828 own data is lexicographically earlier, then it treats this exactly 829 as if it had received a positive answer to its query, and concludes 830 that it may not use the desired name. 832 The determination of 'lexicographically later' is performed by first 833 comparing the record class, then the record type, then raw comparison 834 of the binary content of the rdata without regard for meaning or 835 structure. If the record classes differ, then the numerically greater 836 class is considered 'lexicographically later'. Otherwise, if the 837 record types differ, then the numerically greater type is considered 838 'lexicographically later'. If the type and class both match then the 839 rdata is compared. 841 In the case of resource records containing rdata that is subject to 842 name compression, the names must be uncompressed before comparison. 843 (The details of how a particular name is compressed is an artifact of 844 how and where the record is written into the DNS message; it is not 845 an intrinsic property of the resource record itself.) 847 The bytes of the raw uncompressed rdata are compared in turn, 848 interpreting the bytes as eight-bit UNSIGNED values, until a byte 849 is found whose value is greater than that of its counterpart (in 850 which case the rdata whose byte has the greater value is deemed 851 lexicographically later) or one of the resource records runs out 852 of rdata (in which case the resource record which still has 853 remaining data first is deemed lexicographically later). 855 The following is an example of a conflict: 857 sctibook.local. A 196.254.100.200 858 sctibook.local. A 196.254.200.100 860 In this case 196.254.200.100 is lexicographically later, so it is 861 deemed the winner. 863 Note that it is vital that the bytes are interpreted as UNSIGNED 864 values, or the wrong outcome may result. In the example above, if 865 the byte with value 200 had been incorrectly interpreted as a 866 signed value then it would be interpreted as value -56, and the 867 wrong address record would be deemed the winner. 869 9.3 Announcing 871 The second startup step is that the Multicast DNS Responder MUST send 872 a gratuitous Multicast DNS Response containing, in the Answer 873 Section, all of its resource records. If there are too many resource 874 records to fit in a single packet, multiple packets should be used. 876 In the case of shared records (e.g. the PTR records used by DNS 877 Service Discovery [DNS-SD]), the records are simply placed as-is 878 into the answer section of the DNS Response. 880 In the case of records that have been verified to be unique in the 881 previous step, they are placed into the answer section of the DNS 882 Response with the most significant bit of the rrclass set to one. The 883 most significant bit of the rrclass is the mDNS "cache flush" bit and 884 is discussed in more detail below in Section 13.3 "Announcements to 885 Flush Outdated Cache Entries". 887 The Multicast DNS Responder MUST send at least two gratuitous 888 responses, one second apart. A Responder MAY send up to ten 889 gratuitous Responses, providing that the interval between gratuitous 890 responses doubles with every response sent. 892 A Multicast DNS Responder SHOULD NOT continue sending gratuitous 893 Responses for longer than the TTL of the record. The purpose of 894 announcing new records via gratuitous Responses is to ensure that 895 peer caches are up to date. After a time interval equal to the TTL of 896 the record has passed, it is very likely that old stale copies of 897 that record in peer caches will have expired naturally, so subsequent 898 announcements serve little purpose. 900 Whenever a Multicast DNS Responder receives any Multicast DNS 901 response (gratuitous or otherwise) containing a conflicting resource 902 record, the conflict MUST be resolved as described below in "Conflict 903 Resolution". 905 A Multicast DNS Responder MUST NOT send announcements in the absence 906 of information that its network connectivity may have changed in some 907 relevant way. In particular, a Multicast DNS Responder MUST NOT send 908 regular periodic announcements as a matter of course. 910 9.4 Updating 912 At any time, if the rdata of any of a host's Multicast DNS records 913 changes, the host MUST repeat the Announcing step described above to 914 update neighbouring caches. For example, if any of a host's IP 915 addresses change, it must re-announce those address records. 917 A host may update the contents of any of its records at any time, 918 though a host SHOULD NOT update records more frequently than ten 919 times per minute. Frequent rapid updates impose a burden on the 920 network. If a host has information to disseminate which changes more 921 frequently than ten times per minute, then Multicast DNS may not be 922 the appropriate protocol to disseminate that information. 924 10. Conflict Resolution 926 A conflict occurs when two resource records with the same name, type 927 and class have inconsistent rdata. What may be considered 928 inconsistent is context sensitive, except that resource records with 929 identical rdata are never considered inconsistent, even if they 930 originate from different hosts. A common example of a resource record 931 type that is intended to be unique, not shared between hosts, is the 932 address record that maps a host's name to its IP address. Should a 933 host witness another host announce an address record with the same 934 name but a different IP address, then that is considered 935 inconsistent, and that address record is considered to be in 936 conflict. 938 Whenever a Multicast DNS Responder receives any Multicast DNS 939 response (gratuitous or otherwise) containing a conflicting resource 940 record, the Multicast DNS Responder MUST immediately reset that 941 record to probing state, and go through the startup steps described 942 above in Section 9. "Probing and Announcing on Startup". The 943 protocol used in the Probing phase will determine a winner and a 944 loser, and the loser must cease using the name, and reconfigure. 946 It is very important that any host that observes an apparent conflict 947 MUST take action. In the case of two hosts using the same host name, 948 where one has been configured to require a unique host name and the 949 other has not, the one that has not been configured to require a 950 unique host name will not perceive any conflict, and will not take 951 any action. By reverting to Probing state, the host that desires a 952 unique host name will go through the necessary steps to ensure that a 953 unique host is obtained. 955 The recommended course of action after probing and failing is as 956 follows: 958 o Programmatically change the resource record name in an attempt to 959 find a new name that is unique. This could be done by adding some 960 further identifying information (e.g. the model name of the 961 hardware) if it is not already present in the name, appending the 962 digit "2" to the name, or incrementing a number at the end of the 963 name if one is already present. 965 o Probe again, and repeat until a unique name is found. 967 o Record this newly chosen name in persistent storage so that the 968 device will use the same name the next time it is power-cycled. 970 o Display a message to the user or operator informing them of the 971 name change. For example: 973 The name "Bob's Music" is in use by another iTunes music 974 server on the network. Your music has been renamed to 975 "Bob's Music (G4 Cube)". If you want to change this name, 976 use [describe appropriate menu item or preference dialog]. 978 How the user or operator is informed depends on context. A desktop 979 computer with a screen might put up a dialog box. A headless server 980 in the closet may write a message to a log file, or use whatever 981 mechanism (email, SNMP trap, etc.) it uses to inform the 982 administrator of other error conditions. On the other hand a headless 983 server in the closet may not inform the user at all -- if the user 984 cares, they will notice the name has changed, and connect to the 985 server in the usual way (e.g. via Web Browser) to configure a new 986 name. 988 The examples in this section focus on address records (i.e. host 989 names), but the same considerations apply to all resource records 990 where uniqueness (or maintenance of some other defined constraint) is 991 desired. 993 11. Special Characteristics of Multicast DNS Domains 995 Unlike conventional DNS names, names that end in ".local.", 996 "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local 997 significance. Conventional DNS seeks to provide a single unified 998 namespace, where a given DNS query yields the same answer no matter 999 where on the planet it is performed or to which recursive DNS server 1000 the query is sent. (However, split views, firewalls, intranets and 1001 the like have somewhat interfered with this goal of DNS representing 1002 a single universal truth.) In contrast, each IP link has its own 1003 private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa." 1004 namespaces, and the answer to any query for a name within those 1005 domains depends on where that query is asked. 1007 Multicast DNS Domains are not delegated from their parent domain via 1008 use of NS records. There are no NS records anywhere in Multicast DNS 1009 Domains. Instead, all Multicast DNS Domains are delegated to the IP 1010 addresses 224.0.0.251 and FF02::FB by virtue of the individual 1011 organizations producing DNS client software deciding how to handle 1012 those names. It would be extremely valuable for the industry if this 1013 special handling were ratified and recorded by IANA, since otherwise 1014 the special handling provided by each vendor is likely to be 1015 inconsistent. 1017 The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The 1018 IPv6 name server for a Multicast DNS Domain is FF02::FB. These are 1019 multicast addresses; therefore they identify not a single host but a 1020 collection of hosts, working in cooperation to maintain some 1021 reasonable facsimile of a competently managed DNS zone. Conceptually 1022 a Multicast DNS Domain is a single DNS zone, however its server is 1023 implemented as a distributed process running on a cluster of loosely 1024 cooperating CPUs rather than as a single process running on a single 1025 CPU. 1027 No delegation is performed within Multicast DNS Domains. Because the 1028 cluster of loosely coordinated CPUs is cooperating to administer a 1029 single zone, delegation is neither necessary nor desirable. Just 1030 because a particular host on the network may answer queries for a 1031 particular record type with the name "example.local." does not imply 1032 anything about whether that host will answer for the name 1033 "child.example.local.", or indeed for other record types with the 1034 name "example.local." 1036 Multicast DNS Zones have no SOA record. A conventional DNS zone's 1037 SOA record contains information such as the email address of the zone 1038 administrator and the monotonically increasing serial number of the 1039 last zone modification. There is no single human administrator for 1040 any given Multicast DNS Zone, so there is no email address. Because 1041 the hosts managing any given Multicast DNS Zone are only loosely 1042 coordinated, there is no readily available monotonically increasing 1043 serial number to determine whether or not the zone contents have 1044 changed. A host holding part of the shared zone could crash or be 1045 disconnected from the network at any time without informing the other 1046 hosts. There is no reliable way to provide a zone serial number that 1047 would, whenever such a crash or disconnection occurred, immediately 1048 change to indicate that the contents of the shared zone had changed. 1050 Zone transfers are not possible for any Multicast DNS Zone. 1052 12. Multicast DNS for Service Discovery 1054 This document does not describe using Multicast DNS for network 1055 browsing or service discovery. However, the mechanisms this document 1056 describes are compatible with (and support) the browsing and service 1057 discovery mechanisms proposed in "DNS-Based Service Discovery" 1058 [DNS-SD]. 1060 This document places few limitations on what DNS record types may be 1061 looked up using local multicast. One particular kind of Multicast DNS 1062 query that might be useful is a query for the SRV record named 1063 "_domain._udp.local.", yielding the port number and IP address of a 1064 conventional DNS server willing to perform general recursive DNS 1065 lookups. This could solve a particular problem facing the IPv6 1066 community, which is that IPv6 is able to self-configure almost all of 1067 the information it needs to operate [RFC 2462], except for the 1068 address of the DNS server. Bringing in all of the mechanisms of DHCP 1069 just for that one little additional piece of information is not an 1070 attractive solution. Using DNS-format messages and DNS-format 1071 resource records to find the address of the DNS server has an elegant 1072 self-sufficiency about it. Any host that needs to know the address of 1073 the DNS server must already have code to generate and parse DNS 1074 packets, so using that same code and those same packets to find the 1075 DNS server in the first place is a simple self-reliant solution that 1076 avoids taking external dependencies on other protocols. 1078 13. Resource Record TTL Values and Cache Coherency 1080 The recommended TTL value for Multicast DNS resource records is 1081 120 minutes. 1083 A client with an active outstanding query will issue a query packet 1084 when one or more of the resource record(s) in its cache is (are) 80% 1085 of the way to expiry. If the TTL on those records is 120 minutes, 1086 this ongoing cache maintenance process yields a steady-state query 1087 rate of one query every 96 minutes. 1089 Any distributed cache needs a cache coherency protocol. If Multicast 1090 DNS resource records follow the recommendation and have a TTL of 120 1091 minutes, that means that stale data could persist in the system for 1092 up to two hours. Making the default TTL significantly lower would 1093 reduce the lifetime of stale data, but would produce too much extra 1094 traffic on the network. Various techniques are available to minimize 1095 the impact of such stale data. 1097 13.1 Cooperating Multicast DNS Responders 1099 If a Multicast DNS Responder ("A") observes some other Multicast DNS 1100 Responder ("B") send a Multicast DNS Response packet containing a 1101 resource record with the same name type and class as one of A's 1102 resource records, but different rdata, then: 1104 o If A's resource record is intended to be a shared resource record, 1105 then this is no conflict, and no action is required. 1107 o If A's resource record is intended to be a unique resource record 1108 then this is a conflict and MUST be handled as described in Section 1109 10 "Conflict Resolution". 1111 If a Multicast DNS Responder ("A") observes some other Multicast DNS 1112 Responder ("B") send a Multicast DNS Response packet containing a 1113 resource record with the same name type and class as one of A's 1114 resource records, and identical rdata, then: 1116 o If the TTL of B's resource record given in the packet is at least 1117 half the true TTL from A's point of view, then no action is 1118 required. 1120 o If the TTL of B's resource record given in the packet is less than 1121 half the true TTL from A's point of view, then A MUST mark its 1122 record to be announced via multicast. Clients receiving the record 1123 from B would use the TTL given by B, and hence may delete the 1124 record sooner than A expects. By sending its own multicast response 1125 correcting the TTL, A ensures that the record will be retained for 1126 the desired time. 1128 These rules allow multiple Multicast DNS Responders to offer the same 1129 data on the network (perhaps for fault tolerance reasons) without 1130 conflicting with each other. 1132 13.2 Goodbye Packets 1134 In the case where a host knows that certain resource record data is 1135 about to become invalid (for example when the host is undergoing a 1136 clean shutdown) the host SHOULD send a gratuitous announcement mDNS 1137 response packet, giving the same resource record name, type, class 1138 and rdata, but an RR TTL of zero. This has the effect of updating the 1139 TTL stored in neighbouring hosts' cache entries to zero, causing that 1140 cache entry to be promptly deleted. 1142 Clients receiving a Multicast DNS Response with a TTL of zero SHOULD 1143 NOT immediately delete the record from the cache, but instead record 1144 a TTL of 1 and then delete the record one second later. In the case 1145 of multiple Multicast DNS Responders on the network described in 1146 Section 13.1 above, if one of the Responders shuts down and 1147 incorrectly sends goodbye packets for its records, it gives the other 1148 cooperating Responders one second to send out their own response to 1149 "rescue" the records before they expire and are deleted. 1151 Generally speaking, it is more important to send goodbye packets for 1152 shared records than unique records. A given shared record name (such 1153 as a PTR record used for DNS Service Discovery [DNS-SD]) by its 1154 nature often has many representatives from many different hosts, and 1155 tends to be the subject of long-lived ongoing queries. Those 1156 long-lived queries are often concerned not just about being informed 1157 when records appear, but also about being informed if those records 1158 vanish again. In contrast, a unique record set (such as an SRV 1159 record, or a host address record), by its nature, often has far fewer 1160 members than a shared record set, and is usually the subject of 1161 one-shot queries which simply retrieve the data and then cease 1162 querying once they have the answer they are seeking. Therefore, 1163 sending a goodbye packet for a unique record set is likely to offer 1164 less benefit, because it is likely at any given moment that no one 1165 has an active query running for that record set. One example where 1166 goodbye packets for SRV and address records are useful is when 1167 transferring control to a Sleep Proxy Server (see Section 16. 1168 "Multicast DNS and Power Management"). 1170 13.3 Announcements to Flush Outdated Cache Entries 1172 Whenever a host has a resource record with potentially new data (e.g. 1173 after rebooting, waking from sleep, connecting to a new network link, 1174 changing IP address, etc.), the host MUST send a series of gratuitous 1175 announcements to update cache entries in its neighbour hosts. In 1176 these gratuitous announcements, if the record is one that is intended 1177 to be unique, the host sets the most significant bit of the rrclass 1178 field of the resource record. This bit, the "cache flush" bit, tells 1179 neighbouring hosts that this is not a shared record type. Instead of 1180 merging this new record additively into the cache in addition to any 1181 previous records with the same name, type and class, all old records 1182 with that name, type and class that were received more than one 1183 second ago are declared invalid, and marked to expire from the cache 1184 in one second. 1186 The semantics of the cache flush bit are as follows: Normally when a 1187 resource record appears in the answer section of the DNS Response, it 1188 means, "This is an assertion that this information is true." When a 1189 resource record appears in the answer section of the DNS Response 1190 with the "cache flush" bit set, it means, "This is an assertion that 1191 this information is the truth and the whole truth, and anything you 1192 may have heard more than a second ago regarding records of this 1193 name/type/class is no longer valid". 1195 To accommodate the case where the set of records from one host 1196 constituting a single unique RRSet is too large to fit in a single 1197 packet, only cache records that are more than one second old are 1198 flushed. This allows the announcing host to generate a quick burst of 1199 packets back-to-back on the wire containing all the members 1200 of the RRSet. When receiving records with the "cache flush" bit set, 1201 all records older than one second are marked to be deleted one second 1202 in the future. One second after the end of the little packet burst, 1203 any records not represented within that packet burst will then be 1204 expired from all peer caches. 1206 Any time a host sends a response packet containing some members of a 1207 unique RRSet, it SHOULD send the entire RRSet, preferably in a single 1208 packet, or if the entire RRSet will not fit in a single packet, in a 1209 quick burst of packets sent as close together as possible. The host 1210 SHOULD set the cache flush bit on all members of the unique RRSet. 1211 In the event that for some reason the host chooses not to send the 1212 entire unique RRSet in a single packet or a rapid packet burst, 1213 it MUST NOT set the cache flush bit on any of those records. 1215 The reason for waiting one second before deleting stale records from 1216 the cache is to accommodate bridged networks. For example, a host's 1217 address record announcement on a wireless interface may be bridged 1218 onto a wired Ethernet, and cause that same host's Ethernet address 1219 records to be flushed from peer caches. The one-second delay gives 1220 the host the chance to see its own announcement arrive on the wired 1221 Ethernet, and immediately re-announce its Ethernet address records 1222 so that both sets remain valid and live in peer caches. 1224 These rules apply regardless of *why* the response packet is being 1225 generated. They apply to startup announcements as described in 1226 Section 9.3, and to responses generated as a result of receiving 1227 query packets. 1229 The "cache flush" bit is only set in Multicast DNS responses sent to 1230 UDP port 5353. The "cache flush" bit MUST NOT be set in any resource 1231 records in a response packet sent in legacy unicast responses to UDP 1232 ports other than 5353. 1234 The "cache flush" bit MUST NOT be set in any resource records in the 1235 known-answer list of any query packet. 1237 The "cache flush" bit MUST NOT ever be set in any shared resource 1238 record. To do so would cause all the other shared versions of this 1239 resource record with different rdata from different Responders to be 1240 immediately deleted from all the caches on the network. 1242 Note that the "cache flush" bit is NOT part of the resource record 1243 class. The "cache flush" bit is the most significant bit of the 1244 second 16-bit word of a resource record in an mDNS packet (the field 1245 conventionally referred to as the rrclass field), and the actual 1246 resource record class is the least-significant fifteen bits of this 1247 field. There is no mDNS resource record class 0x8001. The value 1248 0x8001 in the rrclass field of a resource record in an mDNS response 1249 packet indicates a resource record with class 1, with the "cache 1250 flush" bit set. When receiving a resource record with the "cache 1251 flush" bit set, implementations should take care to mask off that bit 1252 before storing the resource record in memory. 1254 13.4 Cache Flush on Topology change 1256 If the hardware on a given host is able to indicate physical changes 1257 of connectivity, then when the hardware indicates such a change, the 1258 host should take this information into account in its mDNS cache 1259 management strategy. For example, a host may choose to immediately 1260 flush all cache records received on a particular interface when that 1261 cable is disconnected. Alternatively, a host may choose to adjust the 1262 remaining TTL on all those records to a few seconds so that if the 1263 cable is not reconnected quickly, those records will expire from the 1264 cache. 1266 Likewise, when a host reboots, or wakes from sleep, or undergoes some 1267 other similar discontinuous state change, the cache management 1268 strategy should take that information into account. 1270 13.5 Cache Flush on Failure Indication 1272 Sometimes a cache record can be determined to be stale when a client 1273 attempts to use the rdata it contains, and finds that rdata to be 1274 incorrect. 1276 For example, the rdata in an address record can be determined to be 1277 incorrect if attempts to contact that host fail, either because 1278 ARP/ND requests for that address go unanswered (for an address on a 1279 local subnet) or because a router returns an ICMP "Host Unreachable" 1280 error (for an address on a remote subnet). 1282 The rdata in an SRV record can be determined to be incorrect if 1283 attempts to communicate with the indicated service at the host and 1284 port number indicated are not successful. 1286 The rdata in a DNS-SD PTR record can be determined to be incorrect if 1287 attempts to look up the SRV record it references are not successful. 1289 In any such case, the software implementing the mDNS resource record 1290 cache should provide a mechanism so that clients detecting stale 1291 rdata can inform the cache. 1293 When the cache receives this hint that it should reconfirm some 1294 record, it MUST issue two or more queries for the resource record in 1295 question. If no response is received in a reasonable amount of time, 1296 then, even though its TTL may indicate that it is not yet due to 1297 expire, that record SHOULD be promptly flushed from the cache. 1299 The end result of this is that if a printer suffers a sudden power 1300 failure or other abrupt disconnection from the network, its name may 1301 continue to appear in DNS-SD browser lists displayed on users' 1302 screens. Eventually that entry will expire from the cache naturally, 1303 but if a user tries to access the printer before that happens, the 1304 failure to successfully contact the printer will trigger the more 1305 hasty demise of its cache entries. This is a sensible trade-off 1306 between good user-experience and good network efficiency. If we were 1307 to insist that printers should disappear from the printer list within 1308 30 seconds of becoming unavailable, for all failure modes, the only 1309 way to achieve this would be for the client to poll the printer at 1310 least every 30 seconds, or for the printer to announce its presence 1311 at least every 30 seconds, both of which would be an unreasonable 1312 burden on most networks. 1314 13.6 Passive Observation of Failures 1316 A host observes the multicast queries issued by the other hosts on 1317 the network. One of the major benefits of also sending responses 1318 using multicast is that it allows all hosts to see the responses (or 1319 lack thereof) to those queries. 1321 If a host sees queries, for which a record in its cache would be 1322 expected to be given as an answer in a multicast response, but no 1323 such answer is seen, then the host may take this as an indication 1324 that the record may no longer be valid. 1326 After seeing two or more of these queries, and seeing no multicast 1327 response containing the expected answer within a reasonable amount of 1328 time, then even though its TTL may indicate that it is not yet due to 1329 expire, that record MAY be flushed from the cache. The host SHOULD 1330 NOT perform its own queries to re-confirm that the record is truly 1331 gone. If every host on a large network were to do this, it would 1332 cause a lot of unnecessary multicast traffic. If host A sends 1333 multicast queries that remain unanswered, then there is no reason to 1334 suppose that host B or any other host is likely to be any more 1335 successful. 1337 The previous section, "Cache Flush on Failure Indication", describes 1338 a situation where a user trying to print discovers that the printer 1339 is no longer available. By implementing the passive observation 1340 described here, when one user fails to contact the printer, all hosts 1341 on the network observe that failure and update their caches 1342 accordingly. 1344 14. Enabling and Disabling Multicast DNS 1346 The option to fail-over to Multicast DNS for names not ending in 1347 ".local." SHOULD be a user-configured option, and SHOULD 1348 be disabled by default because of the possible security issues 1349 related to unintended local resolution of apparently global names. 1351 The option to lookup unqualified (relative) names by appending 1352 ".local." (or not) is controlled by whether ".local." appears 1353 (or not) in the client's DNS search list. 1355 No special control is needed for enabling and disabling Multicast DNS 1356 for names explicitly ending with ".local." as entered by the user. 1357 The user doesn't need a way to disable Multicast DNS for names ending 1358 with ".local.", because if the user doesn't want to use Multicast 1359 DNS, they can achieve this by simply not using those names. If a user 1360 *does* enter a name ending in ".local.", then we can safely assume 1361 the user's intention was probably that it should work. Having user 1362 configuration options that can be (intentionally or unintentionally) 1363 set so that local names don't work is just one more way of 1364 frustrating the user's ability to perform the tasks they want, 1365 perpetuating the view that, "IP networking is too complicated to 1366 configure and too hard to use." This in turn perpetuates the 1367 continued use of protocols like AppleTalk. If we want to retire 1368 AppleTalk, NetBIOS, etc., we need to offer users equivalent IP 1369 functionality that they can rely on to, "always work, like 1370 AppleTalk." A little Multicast DNS traffic may be a burden on the 1371 network, but it is an insignificant burden compared to continued 1372 widespread use of AppleTalk. 1374 15. Considerations for Multiple Interfaces 1376 A host should defend its host name (FQDN) on all active interfaces on 1377 which it is answering Multicast DNS queries. 1379 In the event of a name conflict on *any* interface, a host should 1380 configure a new host name, if it wishes to maintain uniqueness of its 1381 host name. 1383 When answering a Multicast DNS query, a multi-homed host with a 1384 link-local address (or addresses) should take care to ensure that 1385 any address going out in a Multicast DNS response is valid for use 1386 on the interface on which the response is going out. 1388 Just as the same link-local IP address may validly be in use 1389 simultaneously on different links by different hosts, the same 1390 link-local host name may validly be in use simultaneously on 1391 different links, and this is not an error. A multi-homed host with 1392 connections to two different links may be able to communicate with 1393 two different hosts that are validly using the same name. While this 1394 kind of name duplication should be rare, it means that a host that 1395 wants to fully support this case needs network programming APIs that 1396 allow applications to specify on what interface to perform a 1397 link-local Multicast DNS query, and to discover on what interface a 1398 Multicast DNS response was received. 1400 16. Multicast DNS and Power Management 1402 Many modern network devices have the ability to go into a low-power 1403 mode where only a small part of the Ethernet hardware remains 1404 powered, and the device can be woken up by sending a specially 1405 formatted Ethernet frame which the device's power-management hardware 1406 recognizes. 1408 To make use of this in conjunction with Multicast DNS, the device 1409 first uses DNS-SD to determine if Sleep Proxy Service is available on 1410 the local network. In some networks there may be more than one piece 1411 of hardware implementing Sleep Proxy Service, for fault-tolerance 1412 reasons. 1414 If the device finds the network has Sleep Proxy Service, the device 1415 transmits two or more gratuitous mDNS announcements setting the TTL 1416 of its relevant resource records to zero, to delete them from 1417 neighbouring caches. The relevant resource records include address 1418 records and SRV records, and other resource records as may apply to a 1419 particular device. The device then communicates all of its remaining 1420 active records, plus the names, types and classes of the deleted 1421 records, to the Sleep Proxy Service(s), along with a copy of the 1422 specific "magic packet" required to wake the device up. 1424 When a Sleep Proxy Service sees an mDNS query for one of the 1425 device's active records (e.g. a DNS-SD PTR record), it answers on 1426 behalf of the device without waking it up. When a Sleep Proxy Service 1427 sees an mDNS query for one of the device's deleted resource 1428 records, it deduces that some client on the network needs to make an 1429 active connection to the device, and sends the specified "magic 1430 packet" to wake the device up. The device then wakes up, reactivates 1431 its deleted resource records, and re-announces them to the network. 1432 The client waiting to connect sees the announcements, learns the 1433 current IP address and port number of the desired service on the 1434 device, and proceeds to connect to it. 1436 The connecting client does not need to be aware of how Sleep Proxy 1437 Service works. Only devices that implement low power mode and wish to 1438 make use of Sleep Proxy Service need to be aware of how that protocol 1439 works. 1441 The reason that a device using a Sleep Proxy Service should send more 1442 than one goodbye packet is that the wakeup message is caused by the 1443 Sleep Proxy Service seeing queries for the device's SRV and/or 1444 address records, and those queries are in turn caused by the records 1445 being absent from peer caches. If the records are not deleted from 1446 peer caches, then those peers may use the cached value directly 1447 without querying, and no wakeup message would be generated. 1449 The full specification of mDNS / DNS-SD Sleep Proxy Service 1450 is described in another document [not yet published]. 1452 17. Multicast DNS Character Set 1454 Unicast DNS has been plagued by the lack of any support for non-US 1455 characters. Indeed, conventional DNS is usually limited to just 1456 letters, digits and hyphens, with no spaces or other punctuation. 1457 Attempts to remedy this have made slow progress because of the need 1458 to accommodate old buggy legacy implementations. 1460 Multicast DNS is a new protocol and doesn't (yet) have old buggy 1461 legacy implementations to constrain the design choices. Accordingly, 1462 it adopts the obvious simple solution: all names in Multicast DNS are 1463 encoded using UTF-8 [RFC 2279]. For names that are restricted to 1464 letters, digits and hyphens, the UTF-8 encoding is identical to the 1465 US-ASCII encoding, so this is entirely compatible with existing host 1466 names. For characters outside the US-ASCII range, UTF-8 encoding is 1467 used. 1469 Multicast DNS implementations MUST NOT use any other encodings apart 1470 from UTF-8 (US-ASCII being considered a compatible subset of UTF-8). 1472 This point bears repeating: There are various baroque representations 1473 of international text being proposed for Unicast DNS. None of these 1474 representations may be used in Multicast DNS packets. Any text being 1475 represented internally in some other representation MUST be converted 1476 to canonical UTF-8 before being placed in any Multicast DNS packet. 1478 The simple rules for case-insensitivity in Unicast DNS also apply in 1479 Multicast DNS; that is to say, in name comparisons, the lower-case 1480 letters "a" to "z" match their upper-case equivalents "A" to "Z". 1481 Hence, if a client issues a query for an address record with the name 1482 "stuartcheshire.local", then a responder having an address record 1483 with the name "StuartCheshire.local" should issue a response. 1485 No other automatic character equivalence is defined in Multicast DNS. 1486 For example, accented characters are not defined to be automatically 1487 equivalent to their unaccented counterparts. Where automatic 1488 equivalences are desired, this may be achieved through the use of 1489 programmatically-generated CNAME records. For example, if a responder 1490 has an address record for an accented name Y, and a client issues a 1491 query for a name X, where X is the same as Y with all the accents 1492 removed, then the responder may issue a response containing two 1493 resource records: A CNAME record "X CNAME Y", asserting that the 1494 requested name X (unaccented) is an alias for the true (accented) 1495 name Y, followed by the address record for Y. 1497 18. Multicast DNS Message Size 1499 RFC 1035 restricts DNS Messages carried by UDP to no more than 512 1500 bytes (not counting the IP or UDP headers). For UDP packets carried 1501 over the wide-area Internet in 1987, this was appropriate. For 1502 link-local multicast packets on today's networks, there is no reason 1503 to retain this restriction. Given that the packets are by definition 1504 link-local, there are no Path MTU issues to consider. 1506 Multicast DNS Messages carried by UDP may be up to the IP MTU of the 1507 physical interface, less the space required for the IP header (20 1508 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes). 1510 In the case of a single mDNS Resource Record which is too large to 1511 fit in a single MTU-sized multicast response packet, a Multicast DNS 1512 Responder SHOULD send the Resource Record alone, in a single IP 1513 datagram, sent using multiple IP fragments. Resource Records this 1514 large SHOULD be avoided, except in the very rare cases where they 1515 really are the appropriate solution to the problem at hand. 1516 Implementers should be aware that many simple devices do not 1517 re-assemble fragmented IP datagrams, so large Resource Records SHOULD 1518 only be used in specialized cases where the implementer knows that 1519 all receivers implement reassembly. 1521 A Multicast DNS packet larger than the interface MTU, which is sent 1522 using fragments, MUST NOT contain more than one Resource Record. 1524 Even when fragmentation is used, a Multicast DNS packet, including IP 1525 and UDP headers, MUST NOT exceed 9000 bytes. 1527 19. Multicast DNS Message Format 1529 This section describes specific restrictions on the allowable 1530 values for the header fields of a Multicast DNS message. 1532 19.1. ID (Query Identifier) 1534 Multicast DNS clients SHOULD listen for gratuitous responses 1535 issued by hosts booting up (or waking up from sleep or otherwise 1536 joining the network). Since these gratuitous responses may contain a 1537 useful answer to a question for which the client is currently 1538 awaiting an answer, Multicast DNS clients SHOULD examine all received 1539 Multicast DNS response messages for useful answers, without regard to 1540 the contents of the ID field or the question section. In Multicast 1541 DNS, knowing which particular query message (if any) is responsible 1542 for eliciting a particular response message is less interesting than 1543 knowing whether the response message contains useful information. 1545 Multicast DNS clients MAY cache any or all Multicast DNS response 1546 messages they receive, for possible future use, providing of course 1547 that normal TTL aging is performed on these cashed resource records. 1549 In multicast query messages, the Query ID SHOULD be set to zero on 1550 transmission. 1552 In multicast responses, including gratuitous multicast responses, the 1553 Query ID MUST be set to zero on transmission, and MUST be ignored on 1554 reception. 1556 In unicast response messages generated specifically in response to a 1557 particular (unicast or multicast) query, the Query ID MUST match the 1558 ID from the query message. 1560 19.2. QR (Query/Response) Bit 1562 In query messages, MUST be zero. 1564 In response messages, MUST be one. 1566 19.3. OPCODE 1568 In both multicast query and multicast response messages, MUST be zero 1569 (only standard queries are currently supported over multicast, unless 1570 other queries are allowed by future IETF Standards Action). 1572 19.4. AA (Authoritative Answer) Bit 1574 In query messages, the Authoritative Answer bit MUST be zero on 1575 transmission, and MUST be ignored on reception. 1577 In response messages for Multicast Domains, the Authoritative Answer 1578 bit MUST be set to one (not setting this bit implies there's some 1579 other place where "better" information may be found) and MUST be 1580 ignored on reception. 1582 19.5. TC (Truncated) Bit 1584 In query messages, if the TC bit is set, it means that additional 1585 Known Answer records may be following shortly. A responder MAY choose 1586 to record this fact, and wait for those additional Known Answer 1587 records, before deciding whether to respond. If the TC bit is clear, 1588 it means that the querying host has no additional Known Answers. 1590 In multicast response messages, the TC bit MUST be zero on 1591 transmission, and MUST be ignored on reception. 1593 In legacy unicast response messages, the TC bit has the same meaning 1594 as in conventional unicast DNS: it means that the response was too 1595 large to fit in a single packet, so the client SHOULD re-issue its 1596 query using TCP in order to receive the larger response. 1598 19.6. RD (Recursion Desired) Bit 1600 In both multicast query and multicast response messages, the 1601 Recursion Desired bit SHOULD be zero on transmission, and MUST be 1602 ignored on reception. 1604 19.7. RA (Recursion Available) Bit 1606 In both multicast query and multicast response messages, the 1607 Recursion Available bit MUST be zero on transmission, and MUST be 1608 ignored on reception. 1610 19.8. Z (Zero) Bit 1612 In both query and response messages, the Zero bit MUST be zero on 1613 transmission, and MUST be ignored on reception. 1615 19.9. AD (Authentic Data) Bit [RFC 2535] 1617 In query messages the Authentic Data bit MUST be zero on 1618 transmission, and MUST be ignored on reception. 1620 In response messages, the Authentic Data bit MAY be set. Resolvers 1621 receiving response messages with the AD bit set MUST NOT trust the AD 1622 bit unless they trust the source of the message and either have a 1623 secure path to it or use DNS transaction security. 1625 19.10. CD (Checking Disabled) Bit [RFC 2535] 1627 In query messages, a resolver willing to do cryptography SHOULD set 1628 the Checking Disabled bit to permit it to impose its own policies. 1630 In response messages, the Checking Disabled bit MUST be zero on 1631 transmission, and MUST be ignored on reception. 1633 19.11. RCODE (Response Code) 1635 In both multicast query and multicast response messages, the Response 1636 Code MUST be zero on transmission. Multicast DNS messages received 1637 with non-zero Response Codes MUST be silently ignored. 1639 20. Choice of UDP Port Number 1641 Arguments were made for and against using Multicast on UDP port 53. 1642 The final decision was to use UDP port 5353. Some of the arguments 1643 for and against are given below. 1645 20.1 Arguments for using UDP port 53: 1647 * This is "just DNS", so it should be the same port. 1649 * There is less work to be done updating old clients to do simple 1650 mDNS queries. Only the destination address need be changed. 1651 In some cases, this can be achieved without any code changes, 1652 just by adding the address 224.0.0.251 to a configuration file. 1654 20.2 Arguments for using a different port (UDP port 5353): 1656 * This is not "just DNS". This is a DNS-like protocol, but different. 1658 * Changing client code to use a different port number is not hard. 1660 * Using the same port number makes it hard to run an mDNS Responder 1661 and a conventional unicast DNS server on the same machine. If a 1662 conventional unicast DNS server wishes to implement mDNS as well, 1663 it can still do that, by opening two sockets. Having two different 1664 port numbers is important to allow this flexibility. 1666 * Some VPN software hijacks all outgoing traffic to port 53 and 1667 redirects it to a special DNS server set up to serve those VPN 1668 clients while they are connected to the corporate network. It is 1669 questionable whether this is the right thing to do, but it is 1670 common, and redirecting link-local multicast DNS packets to a 1671 remote server rarely produces any useful results. It does mean, for 1672 example, that the user becomes unable to access their local network 1673 printer sitting on their desk right next to their computer. Using 1674 a different UDP port eliminates this particular problem. 1676 * On many operating systems, unprivileged clients may not send or 1677 receive packets on low-numbered ports. This means that any client 1678 sending or receiving mDNS packets on port 53 would have to run as 1679 "root", which is an undesirable security risk. Using a higher- 1680 numbered UDP port eliminates this particular problem. 1682 21. Summary of Differences Between Multicast DNS and Unicast DNS 1684 The value of Multicast DNS is that it shares, as much as possible, 1685 the familiar APIs, naming syntax, resource record types, etc., of 1686 Unicast DNS. There are of course necessary differences by virtue of 1687 it using Multicast, and by virtue of it operating in a community of 1688 cooperating peers, rather than a precisely defined authoritarian 1689 hierarchy controlled by a strict chain of formal delegations from the 1690 top. These differences are listed below: 1692 Multicast DNS... 1693 * uses multicast 1694 * uses UDP port 5353 instead of port 53 1695 * operates in well-defined parts of the DNS namespace 1696 * uses UTF-8, and only UTF-8, to encode resource record names 1697 * defines a clear limit on the maximum legal domain name (255 bytes) 1698 * allows larger UDP packets 1699 * allows more than one question in a query packet 1700 * uses the Answer Section of a query to list Known Answers 1701 * uses the TC bit in a query to indicate additional Known Answers 1702 * uses the Authority Section of a query for probe tie-breaking 1703 * ignores the Query ID field (except for generating legacy responses) 1704 * doesn't require the question to be repeated in the response packet 1705 * uses gratuitous responses to announce new records to the peer group 1706 * defines a "unicast response" bit in the rrclass of query questions 1707 * defines a "cache flush" bit in the rrclass of responses 1708 * uses DNS TTL 0 to indicate that a record has been deleted 1709 * uses IP TTL 255 to verify that answers originated on the local link 1710 * monitors queries to perform Duplicate Question Suppression 1711 * monitors responses to perform Duplicate Answer Suppression... 1712 * ... and Ongoing Conflict Detection 1713 * ... and Opportunistic Caching 1715 22. Benefits of Multicast Responses 1717 Some people have argued that sending responses via multicast is 1718 inefficient on the network. In fact the benefits of using multicast 1719 responses result in a net lowering of overall multicast traffic, for 1720 a variety of reasons. 1722 * One multicast response can update the cache on all machines on the 1723 network. If another machine later wants to issue the same query, it 1724 already has the answer in its cache, so it may not need to even 1725 transmit that multicast query on the network at all. 1727 * When more than one machine has the same ongoing long-lived query 1728 running, every machine does not have to transmit its own 1729 independent query. When one machine transmits a query, all the 1730 other hosts see the answers, so they can suppress their own 1731 queries. 1733 * When a host sees a multicast query, but does not see the 1734 corresponding multicast response, it can use this information to 1735 promptly delete stale data from its cache. To achieve the same 1736 level of user-interface quality and responsiveness without 1737 multicast responses would require lower cache lifetimes and more 1738 frequent network polling, resulting in a significantly higher 1739 packet rate. 1741 * Multicast responses allow passive conflict detection. Without this 1742 ability, some other conflict detection mechanism would be needed, 1743 imposing its own additional burden on the network. 1745 23. IPv6 Considerations 1747 An IPv4-only host and an IPv6-only host behave as "ships that pass in 1748 the night". Even if they are on the same Ethernet, neither is aware 1749 of the other's traffic. For this reason, each physical link may have 1750 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 1751 Since for practical purposes, a group of IPv4-only hosts and a group 1752 of IPv6-only hosts on the same Ethernet act as if they were on two 1753 entirely separate Ethernet segments, it is unsurprising that their 1754 use of the ".local." zone should occur exactly as it would if 1755 they really were on two entirely separate Ethernet segments. 1757 A dual-stack (v4/v6) host can participate in both ".local." 1758 zones, and should register its name(s) and perform its lookups both 1759 using IPv4 and IPv6. This enables it to reach, and be reached by, 1760 both IPv4-only and IPv6-only hosts. In effect this acts like a 1761 multi-homed host, with one connection to the logical "IPv4 Ethernet 1762 segment", and a connection to the logical "IPv6 Ethernet segment". 1764 23.1 IPv6 Multicast Addresses by Hashing 1766 Some discovery protocols use a range of multicast addresses, and 1767 determine the address to be used by a hash function of the name being 1768 sought. Queries are sent via multicast to the address as indicated by 1769 the hash function, and responses are returned to the querier via 1770 unicast. Particularly in IPv6, where multicast addresses are 1771 extremely plentiful, this approach is frequently advocated. 1773 There are some problems with this: 1775 * When a host has a large number of records with different names, the 1776 host may have to join a large number of multicast groups. This can 1777 place undue burden on the Ethernet hardware, which typically 1778 supports a limited number of multicast addresses efficiently. When 1779 this number is exceeded, the Ethernet hardware may have to resort 1780 to receiving all multicasts and passing them up to the host 1781 software for filtering, thereby defeating the point of using a 1782 multicast address range in the first place. 1784 * Multiple questions cannot be placed in one packet if they don't all 1785 hash to the same multicast address. 1787 * Duplicate Question Suppression doesn't work if queriers are not 1788 seeing each other's queries. 1790 * Duplicate Answer Suppression doesn't work if responders are not 1791 seeing each other's responses. 1793 * Opportunistic Caching doesn't work. 1795 * Ongoing Conflict Detection doesn't work. 1797 24. Security Considerations 1799 The algorithm for detecting and resolving name conflicts is, by its 1800 very nature, an algorithm that assumes cooperating participants. Its 1801 purpose is to allow a group of hosts to arrive at a mutually disjoint 1802 set of host names and other DNS resource record names, in the absence 1803 of any central authority to coordinate this or mediate disputes. In 1804 the absence of any higher authority to resolve disputes, the only 1805 alternative is that the participants must work together cooperatively 1806 to arrive at a resolution. 1808 In an environment where the participants are mutually antagonistic 1809 and unwilling to cooperate, other mechanisms are appropriate, like 1810 manually administered DNS. 1812 In an environment where there is a group of cooperating participants, 1813 but there may be other antagonistic participants on the same physical 1814 link, the cooperating participants need to use IPSEC signatures 1815 and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS 1816 messages from trusted participants (which they process as usual) from 1817 mDNS messages from untrusted participants (which they silently 1818 discard). 1820 When DNS queries for *global* DNS names are sent to the mDNS 1821 multicast address (during network outages which disrupt communication 1822 with the greater Internet) it is *especially* important to use 1823 DNSSEC, because the user may have the impression that he or she is 1824 communicating with some authentic host, when in fact he or she is 1825 really communicating with some local host that is merely masquerading 1826 as that name. This is less critical for names ending with ".local.", 1827 because the user should be aware that those names have only local 1828 significance and no global authority is implied. 1830 Most computer users neglect to type the trailing dot at the end of a 1831 fully qualified domain name, making it a relative domain name (e.g. 1832 "www.example.com"). In the event of network outage, attempts to 1833 positively resolve the name as entered will fail, resulting in 1834 application of the search list, including ".local.", if present. 1835 A malicious host could masquerade as "www.example.com" by answering 1836 the resulting Multicast DNS query for "www.example.com.local." 1837 To avoid this, a host MUST NOT append the search suffix 1838 ".local.", if present, to any relative (partially qualified) 1839 domain name containing two or more labels. Appending ".local." to 1840 single-label relative domain names is acceptable, since the user 1841 should have no expectation that a single-label domain name will 1842 resolve as-is. 1844 25. IANA Considerations 1846 The IANA has allocated the IPv4 link-local multicast address 1847 224.0.0.251 for the use described in this document. 1849 The IANA has allocated the IPv6 multicast address set FF0X::FB 1850 for the use described in this document. 1852 When this document is published, IANA should designate a list 1853 of domains which are deemed to have only link-local significance, 1854 as described in this document. 1856 No other IANA services are required by this document. 1858 26. Acknowledgements 1860 The concepts described in this document have been explored and 1861 developed with help from Erik Guttman, Paul Vixie, Bill Woodcock, 1862 and others. 1864 27. Copyright 1866 Copyright (C) The Internet Society January 2004. 1867 All Rights Reserved. 1869 This document and translations of it may be copied and furnished to 1870 others, and derivative works that comment on or otherwise explain it 1871 or assist in its implementation may be prepared, copied, published 1872 and distributed, in whole or in part, without restriction of any 1873 kind, provided that the above copyright notice and this paragraph are 1874 included on all such copies and derivative works. However, this 1875 document itself may not be modified in any way, such as by removing 1876 the copyright notice or references to the Internet Society or other 1877 Internet organizations, except as needed for the purpose of 1878 developing Internet standards in which case the procedures for 1879 copyrights defined in the Internet Standards process must be 1880 followed, or as required to translate it into languages other than 1881 English. 1883 The limited permissions granted above are perpetual and will not be 1884 revoked by the Internet Society or its successors or assigns. 1886 This document and the information contained herein is provided on an 1887 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1888 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1889 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1890 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1891 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1893 28. Normative References 1895 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 1896 Facilities", STD 13, RFC 1034, November 1987. 1898 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 1899 Specifications", STD 13, RFC 1035, November 1987. 1901 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1902 Requirement Levels", RFC 2119, March 1997. 1904 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO 1905 10646", RFC 2279, January 1998. 1907 29. Informative References 1909 [dotlocal] 1911 [djbdl] 1913 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 1914 Overview and Architecture. 1915 Institute of Electrical and Electronic Engineers, 1916 IEEE Standard 802, 1990. 1918 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service 1919 Discovery", Internet-Draft (work in progress), 1920 draft-cheshire-dnsext-dns-sd-03.txt, January 2004. 1922 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 1923 System (DNS UPDATE)", RFC 2136, April 1997. 1925 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address 1926 Autoconfiguration", RFC 2462, December 1998. 1928 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", 1929 RFC 2535, March 1999. 1931 [v4LL] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic 1932 Configuration of IPv4 Link-Local Addresses", 1933 Internet-Draft (work in progress), 1934 draft-ietf-zeroconf-ipv4-linklocal-11.txt, January 2004. 1936 [ZC] Williams, A., "Requirements for Automatic Configuration 1937 of IP Hosts", Internet-Draft (work in progress), 1938 draft-ietf-zeroconf-reqts-12.txt, September 2002. 1940 30. Author's Addresses 1942 Stuart Cheshire 1943 Apple Computer, Inc. 1944 1 Infinite Loop 1945 Cupertino 1946 California 95014 1947 USA 1949 Phone: +1 408 974 3207 1950 EMail: rfc@stuartcheshire.org 1952 Marc Krochmal 1953 Apple Computer, Inc. 1954 1 Infinite Loop 1955 Cupertino 1956 California 95014 1957 USA 1959 Phone: +1 408 974 4368 1960 EMail: marc@apple.com