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