idnits 2.17.1 draft-cheshire-dnsext-multicastdns-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 60 form feeds but 62 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. == 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 IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (23 March 2010) is 5148 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) ** Obsolete normative reference: RFC 3845 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Possible downref: Non-RFC (?) normative reference: ref. 'UAX15' == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-06 == Outdated reference: A later version (-10) exists of draft-cheshire-dnsext-nbp-08 -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- 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) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Document: draft-cheshire-dnsext-multicastdns-11.txt Stuart Cheshire 2 Internet-Draft Marc Krochmal 3 Category: Standards Track Apple Inc. 4 Expires: 23 September 2010 23 March 2010 6 Multicast DNS 8 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on 23rd September 2010. 33 Abstract 35 As networked devices become smaller, more portable, and 36 more ubiquitous, the ability to operate with less configured 37 infrastructure is increasingly important. In particular, 38 the ability to look up DNS resource record data types 39 (including, but not limited to, host names) in the absence 40 of a conventional managed DNS server is becoming essential. 42 Multicast DNS (mDNS) provides the ability to do DNS-like operations 43 on the local link in the absence of any conventional unicast DNS 44 server. In addition, mDNS designates a portion of the DNS namespace 45 to be free for local use, without the need to pay any annual fee, and 46 without the need to set up delegations or otherwise configure a 47 conventional DNS server to answer for those names. 49 The primary benefits of mDNS names are that (i) they require little 50 or no administration or configuration to set them up, (ii) they work 51 when no infrastructure is present, and (iii) they work during 52 infrastructure failures. 54 Table of Contents 56 1. Introduction....................................................3 57 2. Conventions and Terminology Used in this Document...............3 58 3. Multicast DNS Names.............................................5 59 4. Reverse Address Mapping.........................................6 60 5. Querying........................................................7 61 6. Duplicate Suppression..........................................12 62 7. Responding.....................................................14 63 8. Probing and Announcing on Startup..............................21 64 9. Conflict Resolution............................................27 65 10. Resource Record TTL Values and Cache Coherency.................28 66 11. Source Address Check...........................................34 67 12. Special Characteristics of Multicast DNS Domains...............35 68 13. Multicast DNS for Service Discovery............................36 69 14. Enabling and Disabling Multicast DNS...........................36 70 15. Considerations for Multiple Interfaces.........................37 71 16. Considerations for Multiple Responders on the Same Machine.....38 72 17. Multicast DNS Character Set....................................40 73 18. Multicast DNS Message Size.....................................41 74 19. Multicast DNS Message Format...................................42 75 20. Summary of Differences Between Multicast DNS and Unicast DNS...46 76 21. IPv6 Considerations............................................47 77 22. Security Considerations........................................47 78 23. IANA Considerations............................................48 79 24. Acknowledgments................................................50 80 25. Copyright Notice...............................................50 81 26. Normative References...........................................51 82 27. Informative References.........................................51 83 28. Authors' Addresses.............................................53 85 Appendix A. Design Rationale for Choice of UDP Port Number.........54 86 Appendix B. Design Rationale for Not Using Hashed Mcast Addresses..55 87 Appendix C. Design Rationale for Max Multicast DNS Name Length.....56 88 Appendix D. Benefits of Multicast Responses........................58 89 Appendix E. Design Rationale for Encoding Negative Responses.......59 90 Appendix F. Use of UTF-8...........................................60 91 Appendix G. Governing Standards Body...............................60 92 Appendix H. Private DNS Namespaces.................................61 93 Appendix I. Deployment History.....................................62 95 1. Introduction 97 Multicast DNS and its companion technology DNS Service Discovery 98 [DNS-SD] were created to provide IP networking with the ease-of-use 99 and autoconfiguration for which AppleTalk was well known [ATalk]. 100 When reading this document, familiarity with the concepts of Zero 101 Configuration Networking [Zeroconf] and automatic link-local 102 addressing [RFC 2462] [RFC 3927] is helpful. 104 This document specifies no change to the structure of DNS messages, 105 no new operation codes or response codes, and new resource record 106 types. This document describes how clients send DNS-like queries via 107 IP multicast, and how a collection of hosts cooperate to collectively 108 answer those queries in a useful manner. 110 2. Conventions and Terminology Used in this Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in "Key words for use in 115 RFCs to Indicate Requirement Levels" [RFC 2119]. 117 When this document uses the term "Multicast DNS", it should be taken 118 to mean: "Clients performing DNS-like queries for DNS-like resource 119 records by sending DNS-like UDP query and response packets over IP 120 Multicast to UDP port 5353." The design rationale for selecting 121 UDP port 5353 is discussed in Appendix A. 123 This document uses the term "host name" in the strict sense to mean a 124 fully qualified domain name that has an IPv4 or IPv6 address record. 125 It does not use the term "host name" in the commonly used but 126 incorrect sense to mean just the first DNS label of a host's fully 127 qualified domain name. 129 A DNS (or mDNS) packet contains an IP TTL in the IP header, which 130 is effectively a hop-count limit for the packet, to guard against 131 routing loops. Each Resource Record also contains a TTL, which is 132 the number of seconds for which the Resource Record may be cached. 133 This document uses the term "IP TTL" to refer to the IP header TTL 134 (hop limit), and the term "RR TTL" or just "TTL" to refer to the 135 Resource Record TTL (cache lifetime). 137 DNS-format messages contain a header, a Question Section, then 138 Answer, Authority, and Additional Record Sections. The Answer, 139 Authority, and Additional Record Sections all hold resource records 140 in the same format. Where this document describes issues that apply 141 equally to all three sections, it uses the term "Resource Record 142 Sections" to refer collectively to these three sections. 144 This document uses the terms "shared" and "unique" when referring to 145 resource record sets: 147 A "shared" resource record set is one where several Multicast DNS 148 Responders may have records with that name, rrtype, and rrclass, and 149 several Responders may respond to a particular query. 151 A "unique" resource record set is one where all the records with 152 that name, rrtype, and rrclass are conceptually under the control 153 or ownership of a single Responder, and it is expected that at most 154 one Responder should respond to a query for that name, rrtype, and 155 rrclass. Before claiming ownership of a unique resource record set, 156 a Responder MUST probe to verify that no other Responder already 157 claims ownership of that set, as described in Section 8.1 "Probing". 158 (For fault-tolerance and other reasons it is permitted sometimes to 159 have more than one Responder answering for a particular "unique" 160 resource record set, but such cooperating Responders MUST give 161 answers containing identical rdata for these records. If they do 162 not give answers containing identical rdata then the probing step 163 will reject the data as being inconsistent with what is already 164 being advertised on the network for those names.) 166 Strictly speaking the terms "shared" and "unique" apply to resource 167 record sets, not to individual resource records, but it is sometimes 168 convenient to talk of "shared resource records" and "unique resource 169 records". When used this way, the terms should be understood to mean 170 a record that is a member of a "shared" or "unique" resource record 171 set, respectively. 173 3. Multicast DNS Names 175 This document specifies that the DNS top-level domain ".local." 176 is a special domain with special semantics, namely that any fully- 177 qualified name ending in ".local." is link-local, and names within 178 this domain are meaningful only on the link where they originate. 179 This is analogous to IPv4 addresses in the 169.254/16 prefix, which 180 are link-local and meaningful only on the link where they originate. 182 Any DNS query for a name ending with ".local." MUST be sent to the 183 mDNS multicast address (224.0.0.251 or its IPv6 equivalent FF02::FB). 184 The design rationale for using a fixed multicast address instead of 185 selecting from a range of multicast addresses using a hash function 186 is discussed in Appendix B. 188 It is unimportant whether a name ending with ".local." occurred 189 because the user explicitly typed in a fully qualified domain name 190 ending in ".local.", or because the user entered an unqualified 191 domain name and the host software appended the suffix ".local." 192 because that suffix appears in the user's search list. The ".local." 193 suffix could appear in the search list because the user manually 194 configured it, or because it was received via DHCP [RFC 2132], 195 or via any other mechanism for configuring the DNS search list. 196 In this respect the ".local." suffix is treated no differently to 197 any other search domain that might appear in the DNS search list. 199 DNS queries for names that do not end with ".local." MAY be sent 200 to the mDNS multicast address, if no other conventional DNS server 201 is available. This can allow hosts on the same link to continue 202 communicating using each other's globally unique DNS names during 203 network outages which disrupt communication with the greater 204 Internet. When resolving global names via local multicast, it is even 205 more important to use DNSSEC or other security mechanisms to ensure 206 that the response is trustworthy. Resolving global names via local 207 multicast is a contentious issue, and this document does not discuss 208 it in detail, instead concentrating on the issue of resolving local 209 names using DNS packets sent to a multicast address. 211 A host that belongs to an organization or individual who has control 212 over some portion of the DNS namespace can be assigned a globally 213 unique name within that portion of the DNS namespace, such as, 214 "cheshire.example.com." For those of us who have this luxury, this 215 works very well. However, the majority of home computer users do not 216 have easy access to any portion of the global DNS namespace within 217 which they have the authority to create names as they wish. This 218 leaves the majority of home computers effectively anonymous for 219 practical purposes. 221 To remedy this problem, this document allows any computer user to 222 elect to give their computers link-local Multicast DNS host names of 223 the form: "single-dns-label.local." For example, a laptop computer 224 may answer to the name "MyPrinter.local." Any computer user is 225 granted the authority to name their computer this way, provided that 226 the chosen host name is not already in use on that link. Having named 227 their computer this way, the user has the authority to continue using 228 that name until such time as a name conflict occurs on the link which 229 is not resolved in the user's favor. If this happens, the computer 230 (or its human user) SHOULD cease using the name, and may choose to 231 attempt to allocate a new unique name for use on that link. These 232 conflicts are expected to be relatively rare for people who choose 233 reasonably imaginative names, but it is still important to have a 234 mechanism in place to handle them when they happen. 236 This document recommends a single flat namespace for dot-local host 237 names, (i.e. the names of DNS "A" and "AAAA" records, which map names 238 to IPv4 and IPv6 addresses), but other DNS record types (such as 239 those used by DNS Service Discovery [DNS-SD]) may contain as many 240 labels as appropriate for the desired usage, up to a maximum of 241 255 bytes, not including the terminating zero byte at the end. 242 Name length issues are discussed further in Appendix C. 244 Enforcing uniqueness of host names is probably desirable in the 245 common case, but this document does not mandate that. It is 246 permissible for a collection of coordinated hosts to agree to 247 maintain multiple DNS address records with the same name, possibly 248 for load balancing or fault-tolerance reasons. This document does not 249 take a position on whether that is sensible. It is important that 250 both modes of operation are supported. The Multicast DNS protocol 251 allows hosts to verify and maintain unique names for resource records 252 where that behavior is desired, and it also allows hosts to maintain 253 multiple resource records with a single shared name where that 254 behavior is desired. This consideration applies to all resource 255 records, not just address records (host names). In summary: It is 256 required that the protocol have the ability to detect and handle name 257 conflicts, but it is not required that this ability be used for every 258 record. 260 4. Reverse Address Mapping 262 Like ".local.", the IPv4 and IPv6 reverse mapping domains are also 263 defined to be link-local: 265 Any DNS query for a name ending with "254.169.in-addr.arpa." MUST 266 be sent to the mDNS multicast address 224.0.0.251. Since names 267 under this domain correspond to IPv4 link-local addresses, it is 268 logical that the local link is the best place to find information 269 pertaining to those names. 271 Likewise, any DNS query for a name within the reverse mapping 272 domains for IPv6 Link-Local addresses ("8.e.f.ip6.arpa.", 273 "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST 274 be sent to the IPv6 mDNS link-local multicast address FF02::FB. 276 5. Querying 278 There are three kinds of Multicast DNS Queries, one-shot queries 279 of the kind made by conventional DNS clients, one-shot queries 280 accumulating multiple responses made by multicast-aware DNS clients, 281 and continuous ongoing Multicast DNS Queries used by IP network 282 browser software. 284 Except in the rare case of a Multicast DNS Responder that is 285 advertising only shared resources records and no unique records, a 286 Multicast DNS Responder MUST also implement a Multicast DNS Querier 287 so that it can first verify the uniqueness of those records before it 288 begins answering queries for them. 290 5.1 One-Shot Multicast DNS Queries 292 The most basic kind of Multicast DNS client may simply send its DNS 293 queries blindly to 224.0.0.251:5353, without necessarily even being 294 aware of what a multicast address is. This change can typically be 295 implemented with just a few lines of code in an existing DNS resolver 296 library. Any time the name being queried for falls within one of the 297 reserved mDNS domains (see Section 12 "Special Characteristics of 298 Multicast DNS Domains") rather than using the configured unicast DNS 299 server address, the query is instead sent to 224.0.0.251:5353 (or its 300 IPv6 equivalent [FF02::FB]:5353). Typically the timeout would also be 301 shortened to two or three seconds. It's possible to make a minimal 302 mDNS client with only these simple changes. These queries are 303 typically done using a high-numbered ephemeral UDP source port, 304 but regardless of whether they are sent from a dynamic port or from 305 a fixed port, these queries SHOULD NOT be sent using UDP source port 306 5353, since using UDP source port 5353 signals the presence of a 307 fully-compliant Multicast DNS client, as described below. 309 A simple DNS client like this will typically just take the first 310 response it receives. It will not listen for additional UDP 311 responses, but in many instances this may not be a serious problem. 312 If a user types "http://MyPrinter.local." into their web browser and 313 gets to see the status and configuration web page for their printer, 314 then the protocol has met the user's needs in this case. 316 While a basic DNS client like this may be adequate for simple 317 host name lookup, it may not get ideal behavior in other cases. 318 Additional refinements that may be adopted by more sophisticated 319 clients are described below. 321 5.2 One-Shot Queries, Accumulating Multiple Responses 323 A compliant Multicast DNS client, which implements the rules 324 specified in this document, MUST send its Multicast DNS Queries from 325 UDP source port 5353 (the well-known port assigned to mDNS), and MUST 326 listen for Multicast DNS Replies sent to UDP destination port 5353 at 327 the mDNS multicast address (224.0.0.251 and/or its IPv6 equivalent 328 FF02::FB). 330 As described above, there are some cases, such as looking up the 331 address associated with a unique host name, where a single response 332 is sufficient, and moreover may be all that is expected. However, 333 there are other DNS queries where more than one response is 334 possible and useful, and for these queries a more advanced Multicast 335 DNS client should include the ability to wait for an appropriate 336 period of time to collect multiple responses. 338 A naive DNS client retransmits its query only so long as it has 339 received no response. A more advanced Multicast DNS client is aware 340 that having received one response is not necessarily an indication 341 that it might not receive others, and has the ability to retransmit 342 its query until it is satisfied with the collection of responses it 343 has gathered. When retransmitting, the interval between the first two 344 queries SHOULD be at least one second, and the intervals between 345 successive queries SHOULD increase by at least a factor of two. 347 A Multicast DNS client that is retransmitting a query for which it 348 has already received some responses MUST implement Known Answer 349 Suppression, as described below in Section 6.1 "Known Answer 350 Suppression". This indicates to Responders who have already replied 351 that their responses have been received, and they don't need to send 352 them again in response to this repeated query. 354 5.3 Continuous Multicast DNS Querying 356 In One-Shot Queries, with either single or multiple responses, 357 the underlying assumption is that the transaction begins when the 358 application issues a query, and ends when the desired responses 359 have been received. There is another type of operation which is 360 more akin to continuous monitoring. 362 Imagine some hypothetical software which allows users to manage their 363 digital music collections, with a graphical user interface which 364 includes a sidebar down the left side of the window, which shows 365 other sources of shared music the software has discovered on the 366 local network. It would be convenient for the user if they could rely 367 on this list of shared music sources displayed in the window sidebar 368 to stay up to date as music sources come and go, rather than 369 displaying out-of-date stale information, and requiring the user 370 explicitly to click a "refresh" button any time they want to see 371 accurate information (which, from the moment it is displayed, is 372 itself already beginning to become out-of-date and stale). If we are 373 to to display a continuously-updated live list like this, we need to 374 be able to do it efficiently, without naive constant polling which 375 would be an unreasonable burden on the network. 377 Therefore, when retransmitting mDNS queries to implement this kind of 378 continuous monitoring, the interval between the first two queries 379 SHOULD be at least one second, the intervals between successive 380 queries SHOULD increase by at least a factor of two, and the querier 381 MUST implement Known Answer Suppression, as described below in 382 Section 6.1. When the interval between queries reaches or exceeds 60 383 minutes, a querier MAY cap the interval to a maximum of 60 minutes, 384 and perform subsequent queries at a steady-state rate of one query 385 per hour. To avoid accidental synchronization when for some reason 386 multiple clients begin querying at exactly the same moment (e.g. 387 because of some common external trigger event), a Multicast DNS 388 Querier SHOULD also delay the first query of the series by a 389 randomly-chosen amount in the range 20-120ms. 391 When a Multicast DNS Querier receives an answer, the answer contains 392 a TTL value that indicates for how many seconds this answer is valid. 393 After this interval has passed, the answer will no longer be valid 394 and SHOULD be deleted from the cache. Before this time is reached, 395 a Multicast DNS Querier which has clients with an active interest in 396 the state of that record (e.g. a network browsing window displaying 397 a list of discovered services to the user) SHOULD re-issue its query 398 to determine whether the record is still valid. 400 To perform this cache maintenance, a Multicast DNS Querier should 401 plan to re-query for records after at least 50% of the record 402 lifetime has elapsed. This document recommends the following 403 specific strategy: 405 The Querier should plan to issue a query at 80% of the record 406 lifetime, and then if no answer is received, at 85%, 90% and 95%. 407 If an answer is received, then the remaining TTL is reset to the 408 value given in the answer, and this process repeats for as long as 409 the Multicast DNS Querier has an ongoing interest in the record. 410 If after four queries no answer is received, the record is deleted 411 when it reaches 100% of its lifetime. A Multicast DNS Querier MUST 412 NOT perform this cache maintenance for records for which it has no 413 clients with an active interest. If the expiry of a particular record 414 from the cache would result in no net effect to any client software 415 running on the Querier device, and no visible effect to the human 416 user, then there is no reason for the Multicast DNS Querier to 417 waste network bandwidth checking whether the record remains valid. 419 To avoid the case where multiple Multicast DNS Queriers on a network 420 all issue their queries simultaneously, a random variation of 2% of 421 the record TTL should be added, so that queries are scheduled to be 422 performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL. 424 An additional efficiency optimization SHOULD be performed when a 425 Multicast DNS response is received containing a unique answer (as 426 indicated by the cache flush bit being set, described in Section 427 10.3, "Announcements to Flush Outdated Cache Entries"). In this case, 428 there is no need for the querier to continue issuing a stream of 429 queries with exponentially-increasing intervals, since the receipt of 430 a unique answer is a good indication that no other answers will be 431 forthcoming. In this case, the Multicast DNS Querier SHOULD plan to 432 issue its next query for this record at 80-82% of the record's TTL, 433 as described above. 435 5.4 Multiple Questions per Query 437 Multicast DNS allows a querier to place multiple questions in the 438 Question Section of a single Multicast DNS query packet. 440 The semantics of a Multicast DNS query packet containing multiple 441 questions is identical to a series of individual DNS query packets 442 containing one question each. Combining multiple questions into a 443 single packet is purely an efficiency optimization, and has no other 444 semantic significance. 446 5.5 Questions Requesting Unicast Responses 448 Sending Multicast DNS responses via multicast has the benefit that 449 all the other hosts on the network get to see those responses, and 450 can keep their caches up to date, and can detect conflicting 451 responses. 453 However, there are situations where all the other hosts on the 454 network don't need to see every response. Some examples are a laptop 455 computer waking from sleep, or the Ethernet cable being connected to 456 a running machine, or a previously inactive interface being activated 457 through a configuration change. At the instant of wake-up or link 458 activation, the machine is a brand new participant on a new network. 459 Its Multicast DNS cache for that interface is empty, and it has 460 no knowledge of its peers on that link. It may have a significant 461 number of questions that it wants answered right away to discover 462 information about its new surroundings and present that information 463 to the user. As a new participant on the network, it has no idea 464 whether the exact same questions may have been asked and answered 465 just seconds ago. In this case, triggering a large sudden flood of 466 multicast responses may impose an unreasonable burden on the network. 468 To avoid large floods of potentially unnecessary responses in these 469 cases, Multicast DNS defines the top bit in the class field of a DNS 470 question as the "unicast response" bit. When this bit is set in a 471 question, it indicates that the Querier is willing to accept unicast 472 responses instead of the usual multicast responses. These questions 473 requesting unicast responses are referred to as "QU" questions, to 474 distinguish them from the more usual questions requesting multicast 475 responses ("QM" questions). A Multicast DNS Querier sending its 476 initial batch of questions immediately on wake from sleep or 477 interface activation SHOULD set the "QU" bit in those questions. 479 When a question is retransmitted (as described in Section 5.3 480 "Continuous Multicast DNS Querying") the "QU" bit SHOULD NOT be 481 set in subsequent retransmissions of that question. Subsequent 482 retransmissions SHOULD be usual "QM" questions. After the first 483 question has received its responses, the querier should have a large 484 known-answer list (see "Known Answer Suppression" below) so that 485 subsequent queries should elicit few, if any, further responses. 486 Reverting to multicast responses as soon as possible is important 487 because of the benefits that multicast responses provide (see 488 Appendix D). In addition, the "QU" bit SHOULD be set only for 489 questions that are active and ready to be sent the moment of wake 490 from sleep or interface activation. New questions issued by clients 491 afterwards should be treated as normal "QM" questions and SHOULD NOT 492 have the "QU" bit set on the first question of the series. 494 When receiving a question with the "unicast response" bit set, a 495 Responder SHOULD usually respond with a unicast packet directed back 496 to the querier. If the Responder has not multicast that record 497 recently (within one quarter of its TTL), then the Responder SHOULD 498 instead multicast the response so as to keep all the peer caches up 499 to date, and to permit passive conflict detection. In the case of 500 answering a probe question with the "unicast response" bit set, the 501 Responder should always generate the requested unicast response, but 502 may also send a multicast announcement too if the time since the last 503 multicast announcement of that record is more than a quarter of its 504 TTL. 506 Except when defending a unique name against a probe from another 507 host, unicast replies are subject to all the same packet generation 508 rules as multicast replies, including the cache flush bit (see 509 Section 10.3, "Announcements to Flush Outdated Cache Entries") and 510 randomized delays to reduce network collisions (see Section 7, 511 "Responding"). 513 5.6 Direct Unicast Queries to port 5353 515 In specialized applications there may be rare situations where it 516 makes sense for a Multicast DNS Querier to send its query via unicast 517 to a specific machine. When a Multicast DNS Responder receives a 518 query via direct unicast, it SHOULD respond as it would for a 519 "QU" query, as described above in Section 5.5 "Questions Requesting 520 Unicast Responses". Since it is possible for a unicast query to be 521 received from a machine outside the local link, Responders SHOULD 522 check that the source address in the query packet matches the local 523 subnet for that link, and silently ignore the packet if not. 525 There may be specialized situations, outside the scope of this 526 document, where it is intended and desirable to create a Responder 527 that does answer queries originating outside the local link. Such 528 a Responder would need to ensure that these non-local queries are 529 always answered via unicast back to the Querier, since an answer sent 530 via link-local multicast would not reach a Querier outside the local 531 link. 533 6. Duplicate Suppression 535 A variety of techniques are used to reduce the amount of redundant 536 traffic on the network. 538 6.1 Known Answer Suppression 540 When a Multicast DNS Querier sends a query to which it already knows 541 some answers, it populates the Answer Section of the DNS query 542 message with those answers. 544 A Multicast DNS Responder MUST NOT answer a Multicast DNS Query if 545 the answer it would give is already included in the Answer Section 546 with an RR TTL at least half the correct value. If the RR TTL of the 547 answer as given in the Answer Section is less than half of the true 548 RR TTL as known by the Multicast DNS Responder, the Responder MUST 549 send an answer so as to update the Querier's cache before the record 550 becomes in danger of expiration. 552 Because a Multicast DNS Responder will respond if the remaining TTL 553 given in the known answer list is less than half the true TTL, it 554 is superfluous for the Querier to include such records in the known 555 answer list. Therefore a Multicast DNS Querier SHOULD NOT include 556 records in the known answer list whose remaining TTL is less than 557 half their original TTL. Doing so would simply consume space in the 558 packet without achieving the goal of suppressing responses, and would 559 therefore be a pointless waste of network bandwidth. 561 A Multicast DNS Querier MUST NOT cache resource records observed in 562 the Known Answer Section of other Multicast DNS Queries. The Answer 563 Section of Multicast DNS Queries is not authoritative. By placing 564 information in the Answer Section of a Multicast DNS Query the 565 querier is stating that it *believes* the information to be true. 566 It is not asserting that the information *is* true. Some of those 567 records may have come from other hosts that are no longer on the 568 network. Propagating that stale information to other Multicast DNS 569 Queriers on the network would not be helpful. 571 6.2 Multi-Packet Known Answer Suppression 573 Sometimes a Multicast DNS Querier will already have too many answers 574 to fit in the Known Answer Section of its query packets. In this 575 case, it should issue a Multicast DNS Query containing a question and 576 as many Known Answer records as will fit. It MUST then set the TC 577 (Truncated) bit in the header before sending the Query. It MUST then 578 immediately follow the packet with another query packet containing no 579 questions, and as many more Known Answer records as will fit. If 580 there are still too many records remaining to fit in the packet, it 581 again sets the TC bit and continues until all the Known Answer 582 records have been sent. 584 A Multicast DNS Responder seeing a Multicast DNS Query with the TC 585 bit set defers its response for a time period randomly selected in 586 the interval 400-500ms. This gives the Multicast DNS Querier time to 587 send additional Known Answer packets before the Responder responds. 588 If the Responder sees any of its answers listed in the Known Answer 589 lists of subsequent packets from the querying host, it SHOULD delete 590 that answer from the list of answers it is planning to give (provided 591 that no other host on the network has also issued a query for that 592 record and is waiting to receive an answer). 594 If the Responder receives additional Known Answer packets with the TC 595 bit set, it SHOULD extend the delay as necessary to ensure a pause of 596 400-500ms after the last such packet before it sends its answer. This 597 opens the potential risk that a continuous stream of Known Answer 598 packets could, theoretically, prevent a Responder from answering 599 indefinitely. In practice answers are never actually delayed 600 significantly, and should a situation arise where significant delays 601 did happen, that would be a scenario where the network is so 602 overloaded that it would be desirable to err on the side of caution. 603 The consequence of delaying an answer may be that it takes a user 604 longer than usual to discover all the services on the local network; 605 in contrast the consequence of incorrectly answering before all the 606 Known Answer packets have been received would be wasting bandwidth 607 sending unnecessary answers on an already overloaded network. In this 608 (rare) situation, sacrificing speed to preserve reliable network 609 operation is the right trade-off. 611 6.3 Duplicate Question Suppression 613 If a host is planning to send a query, and it sees another host on 614 the network send a QM query containing the same question, and the 615 Known Answer Section of that query does not contain any records which 616 this host would not also put in its own Known Answer Section, then 617 this host should treat its own query as having been sent. When 618 multiple clients on the network are querying for the same resource 619 records, there is no need for them to all be repeatedly asking the 620 same question. 622 6.4 Duplicate Answer Suppression 624 If a host is planning to send an answer, and it sees another host on 625 the network send a response packet containing the same answer record, 626 and the TTL in that record is not less than the TTL this host would 627 have given, then this host SHOULD treat its own answer as having been 628 sent, and not also send an identical answer itself. When multiple 629 Responders on the network have the same data, there is no need for 630 all of them to respond. 632 This feature is particularly useful when Multicast DNS Proxy Servers 633 are in use, where there could be more than one proxy on the network 634 giving Multicast DNS answers on behalf of some other host (e.g. 635 because that other host is currently asleep and is not itself 636 responding to queries). 638 7. Responding 640 When a Multicast DNS Responder constructs and sends a Multicast DNS 641 response packet, the Resource Record Sections of that packet must 642 contain only records for which that Responder is explicitly 643 authoritative. These answers may be generated because the record 644 answers a question received in a Multicast DNS query packet, or at 645 certain other times that the Responder determines than an unsolicited 646 announcement is warranted. A Multicast DNS Responder MUST NOT place 647 records from its cache, which have been learned from other Responders 648 on the network, in the Resource Record Sections of outgoing response 649 packets. Only an authoritative source for a given record is allowed 650 to issue responses containing that record. 652 The determination of whether a given record answers a given question 653 is done using the standard DNS rules: The record name must match 654 the question name, the record rrtype must match the question qtype 655 unless the qtype is "ANY" (255) or the rrtype is "CNAME" (5), and 656 the record rrclass must match the question qclass unless the qclass 657 is "ANY" (255). 659 A Multicast DNS Responder MUST only respond when it has a positive 660 non-null response to send, or it authoritatively knows that a 661 particular record does not exist. For unique records, where the host 662 has already established sole ownership of the name, it MUST return 663 negative answers to queries for records that it knows not to exist. 664 For example, a host with no IPv6 address, that has claimed sole 665 ownership of the name "host.local." for all rrtypes, MUST respond 666 to AAAA queries for "host.local." by sending a negative answer 667 indicating that no AAAA records exist for that name. See Section 7.1 668 "Negative Responses". For shared records, which are owned by no 669 single host, the nonexistence of a given record is ascertained by the 670 failure of any machine to respond to the Multicast DNS query, not by 671 any explicit negative response. NXDOMAIN and other error responses 672 MUST NOT be sent. 674 Multicast DNS Responses MUST NOT contain any questions in the 675 Question Section. Any questions in the Question Section of a received 676 Multicast DNS Response MUST be silently ignored. Multicast DNS 677 Queriers receiving Multicast DNS Responses do not care what question 678 elicited the response; they care only that the information in the 679 response is true and accurate. 681 A Multicast DNS Responder on Ethernet [IEEE 802] and similar shared 682 multiple access networks SHOULD have the capability of delaying its 683 responses by up to 500ms, as determined by the rules described below. 685 If a large number of Multicast DNS Responders were all to respond 686 immediately to a particular query, a collision would be virtually 687 guaranteed. By imposing a small random delay, the number of 688 collisions is dramatically reduced. On a full-sized Ethernet using 689 the maximum cable lengths allowed and the maximum number of repeaters 690 allowed, an Ethernet frame is vulnerable to collisions during the 691 transmission of its first 256 bits. On 10Mb/s Ethernet, this equates 692 to a vulnerable time window of 25.6us. On higher-speed variants of 693 Ethernet, the vulnerable time window is shorter. 695 In the case where a Multicast DNS Responder has good reason to 696 believe that it will be the only Responder on the link that will send 697 a response (i.e. because it is able to answer every question in the 698 query packet, and for all of those answer records it has previously 699 verified that the name, rrtype and rrclass are unique on the link) 700 it SHOULD NOT impose any random delay before responding, and SHOULD 701 normally generate its response within at most 10ms. In particular, 702 this applies to responding to probe queries with the "unicast 703 response" bit set. Since receiving a probe query gives a clear 704 indication that some other Responder is planning to start using this 705 name in the very near future, answering such probe queries to defend 706 a unique record is a high priority and needs to be done without 707 delay. A probe query can be distinguished from a normal query by the 708 fact that a probe query contains a proposed record in the Authority 709 Section which answers the question in the Question Section (for 710 more details, see Section 8.2, "Simultaneous Probe Tie-Breaking"). 712 Responding without delay is appropriate for records like the address 713 record for a particular host name, when the host name has been 714 previously verified unique. Responding without delay is *not* 715 appropriate for things like looking up PTR records used for DNS 716 Service Discovery [DNS-SD], where a large number of responses may be 717 anticipated. 719 In any case where there may be multiple responses, such as queries 720 where the answer is a member of a shared resource record set, each 721 Responder SHOULD delay its response by a random amount of time 722 selected with uniform random distribution in the range 20-120ms. 723 The reason for requiring that the delay be at least 20ms is to 724 accommodate the situation where two or more query packets are sent 725 back-to-back, because in that case we want a Responder with answers 726 to more than one of those queries to have the opportunity to 727 aggregate all of its answers into a single response packet. 729 In the case where the query has the TC (truncated) bit set, 730 indicating that subsequent known answer packets will follow, 731 Responders SHOULD delay their responses by a random amount of time 732 selected with uniform random distribution in the range 400-500ms, 733 to allow enough time for all the known answer packets to arrive, 734 as described in Section 6.2 "Multi-Packet Known Answer Suppression". 736 The source UDP port in all Multicast DNS Responses MUST be 5353 (the 737 well-known port assigned to mDNS). Multicast DNS implementations MUST 738 silently ignore any Multicast DNS Responses they receive where the 739 source UDP port is not 5353. 741 The destination UDP port in all Multicast DNS Responses MUST be 5353 742 and the destination address must be the multicast address 224.0.0.251 743 or its IPv6 equivalent FF02::FB, except when a unicast response has 744 been explicitly requested: 746 * via the "unicast response" bit, 747 * by virtue of being a Legacy Query (Section 7.6), or 748 * by virtue of being a direct unicast query. 750 The benefits of sending Responses via multicast are discussed in 751 Appendix D. 753 To protect the network against excessive packet flooding due to 754 software bugs or malicious attack, a Multicast DNS Responder MUST NOT 755 (except in the one special case of answering probe queries) multicast 756 a record on a given interface until at least one second has elapsed 757 since the last time that record was multicast on that particular 758 interface. A legitimate client on the network should have seen the 759 previous transmission and cached it. A client that did not receive 760 and cache the previous transmission will retry its request and 761 receive a subsequent response. In the special case of answering probe 762 queries, because of the limited time before the probing host will 763 make its decision about whether or not to use the name, a Multicast 764 DNS Responder MUST respond quickly. In this special case only, when 765 responding via multicast to a probe, a Multicast DNS Responder is 766 only required to delay its transmission as necessary to ensure an 767 interval of at least 250ms since the last time the record was 768 multicast on that interface. 770 7.1 Negative Responses 772 In the early design of Multicast DNS it was assumed that explicit 773 negative responses would never be needed. Hosts can assert the 774 existence of the set of records which that host claims to exist, 775 and the union of all such sets on a link is the set of Multicast DNS 776 records that exist on that link. Asserting the non-existence of every 777 record in the complement of that set -- i.e. all possible Multicast 778 DNS records that could exist on this link but do not at this moment 779 -- was felt to be impractical and unnecessary. The non-existence of 780 a record would be ascertained by a client querying for it and failing 781 to receive a response from any of the hosts currently attached to the 782 link. 784 However, operational experience showed that explicit negative 785 responses can sometimes be valuable. One such case is when a client 786 is querying for a AAAA record, and the host name in question has no 787 associated IPv6 addresses. In this case the responding host knows it 788 currently has exclusive ownership of that name, and it knows that it 789 currently does not have any IPv6 addresses, so an explicit negative 790 response is preferable to the client having to retransmit its query 791 multiple times and eventually give up with a timeout before it can 792 conclude that a given AAAA record does not exist. 794 A Multicast DNS Responder indicates the nonexistence of a record by 795 using a DNS NSEC record [RFC 3845]. In the case of Multicast DNS 796 the NSEC record is not being used for its usual DNSSEC security 797 properties, but simply as a way of expressing which records do or 798 do not exist with a given name. 800 Implementers working with devices with sufficient memory and CPU 801 resources may choose to implement code to handle the full generality 802 of the DNS NSEC record [RFC 3845], including bitmaps up to 65,536 803 bits long. To facilitate use by clients with limited memory and CPU 804 resources, Multicast DNS clients are only required to be able to 805 parse a restricted form of the DNS NSEC record. All compliant 806 Multicast DNS clients MUST at least correctly handle the restricted 807 DNS NSEC record format described below: 809 o The 'Next Domain Name' field contains the record's own name. 810 When used with name compression, this means that the 'Next 811 Domain Name' field always takes exactly two bytes in the packet. 813 o The Type Bit Map block number is 0. 815 o The Type Bit Map block length byte is a value in the range 1-32. 817 o The Type Bit Map data is 1-32 bytes, as indicated by length byte. 819 Because this restricted form of the DNS NSEC record is limited to 820 Type Bit Map block number zero, it cannot express the existence of 821 rrtypes above 255. Because of this, if a Multicast DNS Responder were 822 to have records with rrtypes above 255, it MUST NOT generate these 823 restricted-form NSEC records for those names, since to do so would 824 imply that the name has no records with rrtypes above 255, which 825 would be false. In such cases a Multicast DNS Responder MUST either 826 (a) emit no NSEC record for that name, or (b) emit a full NSEC record 827 containing the appropriate Type Bit Map block(s) with the correct 828 bits set for all the record types that exist. In practice this is not 829 a significant limitation, since rrtypes above 255 are not currently 830 in widespread use. 832 If a Multicast DNS implementation receives an NSEC record where the 833 'Next Domain Name' field is not the record's own name, then the 834 implementation SHOULD ignore the 'Next Domain Name' field and process 835 the remainder of the NSEC record as usual. In Multicast DNS the 836 'Next Domain Name' field is not currently used, but it could be used 837 in a future version of this protocol, which is why a Multicast DNS 838 implementation MUST NOT reject or ignore an NSEC record it receives 839 just because it finds an unexpected value in the 'Next Domain Name' 840 field. 842 If a Multicast DNS implementation receives an NSEC record containing 843 more than one Type Bit Map, or where the Type Bit Map block number is 844 not zero, or where the block length is not in the range 1-32, then 845 the Multicast DNS implementation MAY silently ignore the entire NSEC 846 record. A Multicast DNS implementation MUST NOT ignore an entire 847 packet just because that packet contains one or more NSEC record(s) 848 that the Multicast DNS implementation cannot parse. This provision 849 is to allow future enhancements to the protocol to be introduced in 850 a backwards-compatible way that does not break compatibility with 851 older Multicast DNS implementations. 853 To help differentiate these synthesized NSEC records (generated 854 programmatically on-the-fly) from conventional Unicast DNS NSEC 855 records (which actually exist in a signed DNS zone) the synthesized 856 Multicast DNS NSEC records MUST NOT have the 'NSEC' bit set in the 857 Type Bit Map, whereas conventional Unicast DNS NSEC records do have 858 the 'NSEC' bit set. 860 The TTL of the NSEC record indicates the intended lifetime of the 861 negative cache entry. In general, the TTL given for an NSEC record 862 SHOULD be the same as the TTL that the record would have had, had it 863 existed. For example, the TTL for address records in Multicast DNS is 864 typically 120 seconds, so the negative cache lifetime for an address 865 record that does not exist should also be 120 seconds. 867 A Responder should only generate negative responses to queries for 868 which it has legitimate ownership of the name/rrtype/rrclass in 869 question, and can legitimately assert that no record with that 870 name/rrtype/rrclass exists. A Responder can assert that a specified 871 rrtype does not exist for one of its names only if it previously 872 claimed unique ownership of that name using probe queries for rrtype 873 "ANY". (If it were to use probe queries for a specific rrtype, then 874 it would only own the name for that rrtype, and could not assert 875 that other rrtypes do not exist.) On receipt of a question for a 876 particular name/rrtype/rrclass which a Responder knows not to exist 877 by virtue of previous successful probing, the Responder MUST send a 878 response packet containing the appropriate NSEC record, if it can 879 do so using the restricted form of the NSEC record described above. 880 If a legitimate restricted-form NSEC record cannot be created (because 881 rrtypes above 255 exist for that name) the Responder MAY emit a full 882 NSEC record, or it MAY emit no NSEC record, at the implementer's 883 discretion. 885 The design rationale for this mechanism for encoding Negative 886 Responses is discussed further in Appendix E. 888 7.2 Responding to Address Queries 890 In Multicast DNS, whenever a Responder places an IPv4 or IPv6 address 891 record (rrtype "A" or "AAAA") into a response packet, it SHOULD also 892 place the corresponding other address type into the additional 893 section, if there is space in the packet. 895 This is to provide fate sharing, so that all a device's addresses are 896 delivered atomically in a single packet, to reduce the risk that 897 packet loss could cause a querier to receive only the IPv4 addresses 898 and not the IPv6 addresses, or vice versa. 900 In the event that a device has only IPv4 addresses but no IPv6 901 addresses, or vice versa, then the appropriate NSEC record SHOULD 902 be placed into the additional section, so that queriers can know 903 with certainty that the device has no addresses of that kind. 905 Some Multicast DNS Responders treat a physical interface with both 906 IPv4 and IPv6 address as a single interface with two addresses. Other 907 Multicast DNS Responders treat this case as logically two interfaces, 908 each with one address, but Responders that operate this way MUST NOT 909 put the corresponding automatic NSEC records in replies they send 910 (i.e. a negative IPv4 assertion in their IPv6 responses, and a 911 negative IPv6 assertion in their IPv4 responses) because this would 912 cause incorrect operation in Responders on the network that work the 913 former way. 915 7.3 Responding to Multi-Question Queries 917 Multicast DNS Responders MUST correctly handle DNS query packets 918 containing more than one question, by answering any or all of the 919 questions to which they have answers. Any (non-defensive) answers 920 generated in response to query packets containing more than one 921 question SHOULD be randomly delayed in the range 20-120ms, or 922 400-500ms if the TC (truncated) bit is set, as described above. 923 (Answers defending a name, in response to a probe for that name, 924 are not subject to this delay rule and are still sent immediately.) 926 7.4 Response Aggregation 928 When possible, a Responder SHOULD, for the sake of network 929 efficiency, aggregate as many responses as possible into a single 930 Multicast DNS response packet. For example, when a Responder has 931 several responses it plans to send, each delayed by a different 932 interval, then earlier responses SHOULD be delayed by up to an 933 additional 500ms if that will permit them to be aggregated with 934 other responses scheduled to go out a little later. 936 7.5 Wildcard Queries (qtype "ANY" and qclass "ANY") 938 When responding to queries using qtype "ANY" (255) and/or qclass 939 "ANY" (255), a Multicast DNS Responder MUST respond with *ALL* of its 940 records that match the query. This is subtly different to how qtype 941 "ANY" and qclass "ANY" work in Unicast DNS. 943 A common misconception is that a Unicast DNS query for qtype "ANY" 944 will elicit a response containing all matching records. This is 945 incorrect. If there are any records that match the query, the 946 response is required only to contain at least one of them, not 947 necessarily all of them. 949 This somewhat surprising behavior is commonly seen with caching 950 (i.e. "recursive") name servers. If a caching server receives a qtype 951 "ANY" query for which it has at least one valid answer, it is allowed 952 to return only those matching answers it happens to have already in 953 its cache, and is not required to reconsult the authoritative name 954 server to check if there are any more records that also match the 955 qtype "ANY" query. 957 For example, one might imagine that a query for qtype "ANY" for name 958 "host.example.com" would return both the IPv4 (A) and the IPv6 (AAAA) 959 address records for that host. In reality what happens is that it 960 depends on the history of what queries have been previously received 961 by intervening caching servers. If a caching server has no records 962 for "host.example.com" then it will consult another server (usually 963 the authoritative name server for the name in question) and in that 964 case it will typically return all IPv4 and IPv6 address records. 965 If however some other host has recently done a query for qtype "A" 966 for name "host.example.com", so that the caching server already has 967 IPv4 address records for "host.example.com" in its cache, but no IPv6 968 address records, then it will return only the IPv4 address records it 969 already has cached, and no IPv6 address records. 971 Multicast DNS does not share this property that qtype "ANY" and 972 qclass "ANY" queries return some undefined subset of the matching 973 records. When responding to queries using qtype "ANY" (255) and/or 974 qclass "ANY" (255), a Multicast DNS Responder MUST respond with *ALL* 975 of its records that match the query. 977 7.6 Legacy Unicast Responses 979 If the source UDP port in a received Multicast DNS Query is not port 980 5353, this indicates that the client originating the query is a 981 simple client that does not fully implement all of Multicast DNS. 982 In this case, the Multicast DNS Responder MUST send a UDP response 983 directly back to the client, via unicast, to the query packet's 984 source IP address and port. This unicast response MUST be a 985 conventional unicast response as would be generated by a conventional 986 unicast DNS server; for example, it MUST repeat the query ID and the 987 question given in the query packet. In addition, the "cache flush" 988 bit described in Section 10.3 "Announcements to Flush Outdated Cache 989 Entries" is specific to Multicast DNS, and MUST NOT be set in legacy 990 unicast responses. 992 The resource record TTL given in a legacy unicast response SHOULD NOT 993 be greater than ten seconds, even if the true TTL of the Multicast 994 DNS resource record is higher. This is because Multicast DNS 995 Responders that fully participate in the protocol use the cache 996 coherency mechanisms described in Section 10 "Resource Record TTL 997 Values and Cache Coherency" to update and invalidate stale data. Were 998 unicast responses sent to legacy clients to use the same high TTLs, 999 these legacy clients, which do not implement these cache coherency 1000 mechanisms, could retain stale cached resource record data long after 1001 it is no longer valid. 1003 Having sent this unicast response, if the Responder has not sent this 1004 record in any multicast response recently, it SHOULD schedule the 1005 record to be sent via multicast as well, to facilitate passive 1006 conflict detection. "Recently" in this context means "if the time 1007 since the record was last sent via multicast is less than one quarter 1008 of the record's TTL". 1010 8. Probing and Announcing on Startup 1012 Typically a Multicast DNS Responder should have, at the very least, 1013 address records for all of its active interfaces. Creating and 1014 advertising an HINFO record on each interface as well can be useful 1015 to network administrators. 1017 Whenever a Multicast DNS Responder starts up, wakes up from sleep, 1018 receives an indication of an Ethernet "Link Change" event, or has 1019 any other reason to believe that its network connectivity may have 1020 changed in some relevant way, it MUST perform the two startup steps 1021 below: Probing (Section 8.1) and Announcing (Section 8.3). 1023 8.1 Probing 1025 The first startup step is that for all those resource records that 1026 a Multicast DNS Responder desires to be unique on the local link, 1027 it MUST send a Multicast DNS Query asking for those resource records, 1028 to see if any of them are already in use. The primary example of this 1029 is a host's address records which map its unique host name to its 1030 unique IPv4 and/or IPv6 addresses. All Probe Queries SHOULD be done 1031 using the desired resource record name and query type "ANY" (255), to 1032 elicit answers for all types of records with that name. This allows 1033 a single question to be used in place of several questions, which 1034 is more efficient on the network. It also allows a host to verify 1035 exclusive ownership of a name for all rrtypes, which is desirable in 1036 most cases. It would be confusing, for example, if one host owned the 1037 "A" record for "myhost.local.", but a different host owned the "AAAA" 1038 record for that name. 1040 The ability to place more than one question in a Multicast DNS Query 1041 is useful here, because it can allow a host to use a single packet 1042 to probe for all of its resource records instead of needing a 1043 separate packet for each. For example, a host can simultaneously 1044 probe for uniqueness of its "A" record and all its SRV records 1045 [DNS-SD] in the same query packet. 1047 When ready to send its mDNS probe packet(s) the host should first 1048 wait for a short random delay time, uniformly distributed in the 1049 range 0-250ms. This random delay is to guard against the case where a 1050 group of devices are powered on simultaneously, or a group of devices 1051 are connected to an Ethernet hub which is then powered on, or some 1052 other external event happens that might cause a group of hosts to all 1053 send synchronized probes. 1055 250ms after the first query the host should send a second, then 1056 250ms after that a third. If, by 250ms after the third probe, no 1057 conflicting Multicast DNS responses have been received, the host 1058 may move to the next step, announcing. (Note that probing is the 1059 one exception from the normal rule that there should be at least 1060 one second between repetitions of the same question, and the interval 1061 between subsequent repetitions should at least double.) 1063 When sending probe queries, a host MUST NOT consult its cache for 1064 potential answers. Only conflicting Multicast DNS responses received 1065 "live" from the network are considered valid for the purposes of 1066 determining whether probing has succeeded or failed. 1068 In order to allow services to announce their presence without 1069 unreasonable delay, the time window for probing is intentionally set 1070 quite short. As a result of this, from the time the first probe 1071 packet is sent, another device on the network using that name has 1072 just 750ms to respond to defend its name. On networks that are slow, 1073 or busy, or both, it is possible for round-trip latency to account 1074 for a few hundred milliseconds, and software delays in slow devices 1075 can add additional delay. For this reason, it is important that when 1076 a device receives a probe query for a name that it is currently using 1077 it SHOULD generate its response to defend that name immediately and 1078 send it as quickly as possible. The usual rules about random delays 1079 before responding, to avoid sudden bursts of simultaneous answers 1080 from different hosts, do not apply here since normally at most one 1081 host should ever respond to a given probe question. Even when a 1082 single DNS query packet contains multiple probe questions, it would 1083 be unusual for that packet to elicit a defensive response from more 1084 than one other host. Because of the mDNS multicast rate limiting 1085 rules, the first two probes SHOULD be sent as "QU" questions with the 1086 "unicast response" bit set, to allow a defending host to respond 1087 immediately via unicast, instead of potentially having to wait before 1088 replying via multicast. At the present time, this document recommends 1089 that the third probe SHOULD be sent as a standard "QM" question, for 1090 backwards compatibility with the small number of old devices still in 1091 use that don't implement unicast responses. 1093 If, at any time during probing, from the beginning of the initial 1094 random 0-250ms delay onward, any conflicting Multicast DNS responses 1095 are received, then the probing host MUST defer to the existing host, 1096 and MUST choose new names for some or all of its resource records as 1097 appropriate. In the case of a host probing using query type "ANY" as 1098 recommended above, any answer containing a record with that name, 1099 of any type, MUST be considered a conflicting response and handled 1100 accordingly. 1102 If fifteen failures occur within any ten-second period, then the host 1103 MUST wait at least five seconds before each successive additional 1104 probe attempt. This is to help ensure that in the event of software 1105 bugs or other unanticipated problems, errant hosts do not flood the 1106 network with a continuous stream of multicast traffic. For very 1107 simple devices, a valid way to comply with this requirement is 1108 to always wait five seconds after any failed probe attempt before 1109 trying again. 1111 If a Responder knows by other means, with absolute certainty, that 1112 its unique resource record set name, rrtype and rrclass cannot 1113 already be in use by any other Responder on the network, then it 1114 MAY skip the probing step for that resource record set. For example, 1115 when creating the reverse address mapping PTR records, the host can 1116 reasonably assume that no other host will be trying to create those 1117 same PTR records, since that would imply that the two hosts were 1118 trying to use the same IP address, and if that were the case, the 1119 two hosts would be suffering communication problems beyond the scope 1120 of what Multicast DNS is designed to solve. 1122 8.2 Simultaneous Probe Tie-Breaking 1124 The astute reader will observe that there is a race condition 1125 inherent in the previous description. If two hosts are probing for 1126 the same name simultaneously, neither will receive any response to 1127 the probe, and the hosts could incorrectly conclude that they may 1128 both proceed to use the name. To break this symmetry, each host 1129 populates the Query packets's Authority Section with the record or 1130 records with the rdata that it would be proposing to use, should its 1131 probing be successful. The Authority Section is being used here in a 1132 way analogous to the way it is used as the "Update Section" in a DNS 1133 Update packet [RFC 2136]. 1135 When a host is probing for a group of related records with the same 1136 name (e.g. the SRV and TXT record describing a DNS-SD service), only 1137 a single question need be placed in the Question Section, since query 1138 type "ANY" (255) is used, which will elicit answers for all records 1139 with that name. However, for tie-breaking to work correctly in all 1140 cases, the Authority Section must contain *all* the records and 1141 proposed rdata being probed for uniqueness. 1143 When a host that is probing for a record sees another host issue a 1144 query for the same record, it consults the Authority Section of that 1145 query. If it finds any resource record(s) there which answers the 1146 query, then it compares the data of that (those) resource record(s) 1147 with its own tentative data. We consider first the simple case of a 1148 host probing for a single record, receiving a simultaneous probe from 1149 another host also probing for a single record. The two records are 1150 compared and the lexicographically later data wins. This means that 1151 if the host finds that its own data is lexicographically later, it 1152 simply ignores the other host's probe. If the host finds that its own 1153 data is lexicographically earlier, then it treats this exactly as if 1154 it had received a positive answer to its query, and concludes that it 1155 may not use the desired name. 1157 The determination of "lexicographically later" is performed by first 1158 comparing the record class (excluding the cache flush bit described 1159 in Section 10.3), then the record type, then raw comparison of the 1160 binary content of the rdata without regard for meaning or structure. 1161 If the record classes differ, then the numerically greater class 1162 is considered "lexicographically later". Otherwise, if the record 1163 types differ, then the numerically greater type is considered 1164 "lexicographically later". If the rrtype and rrclass both match 1165 then the rdata is compared. 1167 In the case of resource records containing rdata that is subject to 1168 name compression [RFC 1035], the names MUST be uncompressed before 1169 comparison. (The details of how a particular name is compressed is an 1170 artifact of how and where the record is written into the DNS message; 1171 it is not an intrinsic property of the resource record itself.) 1172 The bytes of the raw uncompressed rdata are compared in turn, 1173 interpreting the bytes as eight-bit UNSIGNED values, until a byte 1174 is found whose value is greater than that of its counterpart (in 1175 which case the rdata whose byte has the greater value is deemed 1176 lexicographically later) or one of the resource records runs out 1177 of rdata (in which case the resource record which still has 1178 remaining data first is deemed lexicographically later). 1180 The following is an example of a conflict: 1182 MyPrinter.local. A 169.254.99.200 1183 MyPrinter.local. A 169.254.200.50 1185 In this case 169.254.200.50 is lexicographically later (the third 1186 byte, with value 200, is greater than its counterpart with value 99), 1187 so it is deemed the winner. 1189 Note that it is vital that the bytes are interpreted as UNSIGNED 1190 values in the range 0-255, or the wrong outcome may result. In 1191 the example above, if the byte with value 200 had been incorrectly 1192 interpreted as a signed eight-bit value then it would be interpreted 1193 as value -56, and the wrong address record would be deemed the 1194 winner. 1196 8.2.1 Simultaneous Probe Tie-Breaking for Multiple Records 1198 When a host is probing for a set of records with the same name, or a 1199 packet is received containing multiple tie-breaker records answering 1200 a given probe question in the Question Section, the host's records 1201 and the tie-breaker records from the packet are each sorted into 1202 order, and then compared pairwise, using the same comparison 1203 technique described above, until a difference is found. 1205 The records are sorted using the same lexicographical order as 1206 described above, that is: if the record classes differ, the record 1207 with the lower class number comes first. If the classes are the same 1208 but the rrtypes differ, the record with the lower rrtype number comes 1209 first. If the class and rrtype match, then the rdata is compared 1210 bytewise until a difference is found. For example, in the common case 1211 of advertising DNS-SD services with a TXT record and an SRV record, 1212 the TXT record comes first (the rrtype value for TXT is 16) and the 1213 SRV record comes second (the rrtype value for SRV is 33). 1215 When comparing the records, if the first records match perfectly, 1216 then the second records are compared, and so on. If either list of 1217 records runs out of records before any difference is found, then the 1218 list with records remaining is deemed to have won the tie-break. If 1219 both lists run out of records at the same time without any difference 1220 being found, then this indicates that two devices are advertising 1221 identical sets of records, as is sometimes done for fault tolerance, 1222 and there is in fact no conflict. 1224 8.3 Announcing 1226 The second startup step is that the Multicast DNS Responder MUST 1227 send a gratuitous Multicast DNS Response containing, in the Answer 1228 Section, all of its newly registered resource records (both shared 1229 records, and unique records that have completed the probing step). 1230 If there are too many resource records to fit in a single packet, 1231 multiple packets should be used. 1233 In the case of shared records (e.g. the PTR records used by DNS 1234 Service Discovery [DNS-SD]), the records are simply placed as-is 1235 into the Answer Section of the DNS Response. 1237 In the case of records that have been verified to be unique in the 1238 previous step, they are placed into the Answer Section of the DNS 1239 Response with the most significant bit of the rrclass set to one. 1240 The most significant bit of the rrclass for a record in the Answer 1241 Section of a response packet is the mDNS "cache flush" bit and is 1242 discussed in more detail below in Section 10.3 "Announcements to 1243 Flush Outdated Cache Entries". 1245 The Multicast DNS Responder MUST send at least two gratuitous 1246 responses, one second apart. A Responder MAY send up to eight 1247 gratuitous Responses, provided that the interval between gratuitous 1248 responses increases by at least a factor of two with every response 1249 sent. 1251 A Multicast DNS Responder MUST NOT send announcements in the absence 1252 of information that its network connectivity may have changed in 1253 some relevant way. In particular, a Multicast DNS Responder MUST NOT 1254 send regular periodic announcements as a matter of course. 1256 Whenever a Multicast DNS Responder receives any Multicast DNS 1257 response (gratuitous or otherwise) containing a conflicting resource 1258 record, the conflict MUST be resolved as described below in "Conflict 1259 Resolution". 1261 8.4 Updating 1263 At any time, if the rdata of any of a host's Multicast DNS records 1264 changes, the host MUST repeat the Announcing step described above 1265 to update neighboring caches. For example, if any of a host's IP 1266 addresses change, it MUST re-announce those address records. 1268 In the case of shared records, a host MUST send a "goodbye" 1269 announcement with RR TTL zero (see Section 10.2 "Goodbye Packets") 1270 for the old rdata, to cause it to be deleted from peer caches, 1271 before announcing the new rdata. In the case of unique records, 1272 a host SHOULD omit the "goodbye" announcement, since the cache 1273 flush bit on the newly announced records will cause old rdata 1274 to be flushed from peer caches anyway. 1276 A host may update the contents of any of its records at any time, 1277 though a host SHOULD NOT update records more frequently than ten 1278 times per minute. Frequent rapid updates impose a burden on the 1279 network. If a host has information to disseminate which changes more 1280 frequently than ten times per minute, then it may be more appropriate 1281 to design a protocol for that specific purpose. 1283 9. Conflict Resolution 1285 A conflict occurs when a Multicast DNS Responder has a unique record 1286 for which it is currently authoritative, and it receives a Multicast 1287 DNS response packet containing a record with the same name, rrtype 1288 and rrclass, but inconsistent rdata. What may be considered 1289 inconsistent is context sensitive, except that resource records with 1290 identical rdata are never considered inconsistent, even if they 1291 originate from different hosts. This is to permit use of proxies 1292 and other fault-tolerance mechanisms that may cause more than one 1293 Responder to be capable of issuing identical answers on the network. 1295 A common example of a resource record type that is intended to be 1296 unique, not shared between hosts, is the address record that maps a 1297 host's name to its IP address. Should a host witness another host 1298 announce an address record with the same name but a different IP 1299 address, then that is considered inconsistent, and that address 1300 record is considered to be in conflict. 1302 Whenever a Multicast DNS Responder receives any Multicast DNS 1303 response (gratuitous or otherwise) containing a conflicting resource 1304 record in any of the Resource Record Sections, the Multicast DNS 1305 Responder MUST immediately reset its conflicted unique record to 1306 probing state, and go through the startup steps described above in 1307 Section 8, "Probing and Announcing on Startup". The protocol used in 1308 the Probing phase will determine a winner and a loser, and the loser 1309 MUST cease using the name, and reconfigure. 1311 It is very important that any host receiving a resource record that 1312 conflicts with one of its own MUST take action as described above. 1313 In the case of two hosts using the same host name, where one has been 1314 configured to require a unique host name and the other has not, the 1315 one that has not been configured to require a unique host name will 1316 not perceive any conflict, and will not take any action. By reverting 1317 to Probing state, the host that desires a unique host name will go 1318 through the necessary steps to ensure that a unique host name is 1319 obtained. 1321 The recommended course of action after probing and failing is as 1322 follows: 1324 1. Programmatically change the resource record name in an attempt to 1325 find a new name that is unique. This could be done by adding some 1326 further identifying information (e.g. the model name of the 1327 hardware) if it is not already present in the name, or appending 1328 the digit "2" to the name, or incrementing a number at the end 1329 of the name if one is already present. 1331 2. Probe again, and repeat as necessary until a unique name is found. 1333 3. Once an available unique name has been determined, by probing 1334 without receiving any conflicting response, record this newly 1335 chosen name in persistent storage so that the device will use 1336 the same name the next time it is power-cycled. 1338 4. Display a message to the user or operator informing them of the 1339 name change. For example: 1341 The name "Bob's Music" is in use by another music 1342 server on the network. Your music has been renamed to 1343 "Bob's Music (2)". If you want to change this name, use 1344 [describe appropriate menu item or preference dialog here]. 1346 5. If after one minute of probing the Multicast DNS Responder has been 1347 unable to find any unused name, it should display a message to 1348 the user or operator informing them of this fact. This situation 1349 should never occur in normal operation. The only situations 1350 that would cause this to happen would be either a deliberate 1351 denial-of-service attack, or some kind of very obscure hardware or 1352 software bug that acts like a deliberate denial-of-service attack. 1354 How the user or operator is informed depends on context. A desktop 1355 computer with a screen might put up a dialog box. A headless 1356 server in the closet may write a message to a log file, or use 1357 whatever mechanism (email, SNMP trap, etc.) it uses to inform the 1358 administrator of error conditions. On the other hand a headless 1359 server in the closet may not inform the user at all -- if the user 1360 cares, they will notice the name has changed, and connect to the 1361 server in the usual way (e.g. via web browser) to configure a new 1362 name. 1364 These considerations apply to address records (i.e. host names) and 1365 to all resource records where uniqueness (or maintenance of some 1366 other defined constraint) is desired. 1368 10. Resource Record TTL Values and Cache Coherency 1370 As a general rule, the recommended TTL value for Multicast DNS 1371 resource records with a host name as the resource record's name 1372 (e.g. A, AAAA, HINFO, etc.) or a host name contained within the 1373 resource record's rdata (e.g. SRV, reverse mapping PTR record, etc.) 1374 is 120 seconds. 1376 The recommended TTL value for other Multicast DNS resource records 1377 is 75 minutes. 1379 A client with an active outstanding query will issue a query packet 1380 when one or more of the resource record(s) in its cache is (are) 80% 1381 of the way to expiry. If the TTL on those records is 75 minutes, 1382 this ongoing cache maintenance process yields a steady-state query 1383 rate of one query every 60 minutes. 1385 Any distributed cache needs a cache coherency protocol. If Multicast 1386 DNS resource records follow the recommendation and have a TTL of 75 1387 minutes, that means that stale data could persist in the system for 1388 a little over an hour. Making the default RR TTL significantly lower 1389 would reduce the lifetime of stale data, but would produce too much 1390 extra traffic on the network. Various techniques are available to 1391 minimize the impact of such stale data. 1393 10.1 Cooperating Multicast DNS Responders 1395 If a Multicast DNS Responder ("A") observes some other Multicast DNS 1396 Responder ("B") send a Multicast DNS Response packet containing a 1397 resource record with the same name, rrtype and rrclass as one of A's 1398 resource records, but different rdata, then: 1400 o If A's resource record is intended to be a shared resource record, 1401 then this is no conflict, and no action is required. 1403 o If A's resource record is intended to be a member of a unique 1404 resource record set owned solely by that Responder, then this 1405 is a conflict and MUST be handled as described in Section 9 1406 "Conflict Resolution". 1408 If a Multicast DNS Responder ("A") observes some other Multicast DNS 1409 Responder ("B") send a Multicast DNS Response packet containing a 1410 resource record with the same name, rrtype and rrclass as one of A's 1411 resource records, and identical rdata, then: 1413 o If the TTL of B's resource record given in the packet is at least 1414 half the true TTL from A's point of view, then no action is 1415 required. 1417 o If the TTL of B's resource record given in the packet is less than 1418 half the true TTL from A's point of view, then A MUST mark its 1419 record to be announced via multicast. Clients receiving the record 1420 from B would use the TTL given by B, and hence may delete the 1421 record sooner than A expects. By sending its own multicast response 1422 correcting the TTL, A ensures that the record will be retained for 1423 the desired time. 1425 These rules allow multiple Multicast DNS Responders to offer the same 1426 data on the network (perhaps for fault tolerance reasons) without 1427 conflicting with each other. 1429 10.2 Goodbye Packets 1431 In the case where a host knows that certain resource record data is 1432 about to become invalid (for example when the host is undergoing a 1433 clean shutdown) the host SHOULD send a gratuitous announcement mDNS 1434 response packet, giving the same resource record name, rrtype, 1435 rrclass and rdata, but an RR TTL of zero. This has the effect of 1436 updating the TTL stored in neighboring hosts' cache entries to zero, 1437 causing that cache entry to be promptly deleted. 1439 Clients receiving a Multicast DNS Response with a TTL of zero SHOULD 1440 NOT immediately delete the record from the cache, but instead record 1441 a TTL of 1 and then delete the record one second later. In the case 1442 of multiple Multicast DNS Responders on the network described 1443 in Section 10.1 above, if one of the Responders shuts down and 1444 incorrectly sends goodbye packets for its records, it gives the other 1445 cooperating Responders one second to send out their own response to 1446 "rescue" the records before they expire and are deleted. 1448 10.3 Announcements to Flush Outdated Cache Entries 1450 Whenever a host has a resource record with new data, or with what 1451 might potentially be new data (e.g. after rebooting, waking from 1452 sleep, connecting to a new network link, changing IP address, etc.), 1453 the host needs to inform peers of that new data. In cases where the 1454 host has not been continuously connected and participating on the 1455 network link, it MUST first Probe to re-verify uniqueness of its 1456 unique records, as described above in Section 8.1 "Probing". 1458 Having completed the Probing step if necessary, the host MUST then 1459 send a series of gratuitous announcements to update cache entries 1460 in its neighbor hosts. In these gratuitous announcements, if the 1461 record is one that has been verified unique, the host sets the most 1462 significant bit of the rrclass field of the resource record. This 1463 bit, the "cache flush" bit, tells neighboring hosts that this is not 1464 a shared record type. Instead of merging this new record additively 1465 into the cache in addition to any previous records with the same 1466 name, rrtype and rrclass, all old records with that name, type and 1467 class that were received more than one second ago are declared 1468 invalid, and marked to expire from the cache in one second. 1470 The semantics of the cache flush bit are as follows: Normally when 1471 a resource record appears in a Resource Record Section of the DNS 1472 Response, it means, "This is an assertion that this information is 1473 true." When a resource record appears in a Resource Record Section of 1474 the DNS Response with the "cache flush" bit set, it means, "This is 1475 an assertion that this information is the truth and the whole truth, 1476 and anything you may have heard more than a second ago regarding 1477 records of this name/rrtype/rrclass is no longer true". 1479 To accommodate the case where the set of records from one host 1480 constituting a single unique RRSet is too large to fit in a single 1481 packet, only cache records that are more than one second old are 1482 flushed. This allows the announcing host to generate a quick burst 1483 of packets back-to-back on the wire containing all the members 1484 of the RRSet. When receiving records with the "cache flush" bit set, 1485 all records older than one second are marked to be deleted one second 1486 in the future. One second after the end of the little packet burst, 1487 any records not represented within that packet burst will then be 1488 expired from all peer caches. 1490 Any time a host sends a response packet containing some members of a 1491 unique RRSet, it SHOULD send the entire RRSet, preferably in a single 1492 packet, or if the entire RRSet will not fit in a single packet, in a 1493 quick burst of packets sent as close together as possible. The host 1494 SHOULD set the cache flush bit on all members of the unique RRSet. 1495 In the event that for some reason the host chooses not to send the 1496 entire unique RRSet in a single packet or a rapid packet burst, 1497 it MUST NOT set the cache flush bit on any of those records. 1499 The reason for waiting one second before deleting stale records from 1500 the cache is to accommodate bridged networks. For example, a host's 1501 address record announcement on a wireless interface may be bridged 1502 onto a wired Ethernet, and cause that same host's Ethernet address 1503 records to be flushed from peer caches. The one-second delay gives 1504 the host the chance to see its own announcement arrive on the wired 1505 Ethernet, and immediately re-announce its Ethernet interface's 1506 address records so that both sets remain valid and live in peer 1507 caches. 1509 These rules, about when to set the cache flush bit and about sending 1510 the entire rrset, apply regardless of *why* the response packet is 1511 being generated. They apply to startup announcements as described in 1512 Section 8.3 "Announcing", and to responses generated as a result of 1513 receiving query packets. 1515 The "cache flush" bit is only set in records in the Resource Record 1516 Sections of Multicast DNS responses sent to UDP port 5353. 1518 The "cache flush" bit MUST NOT be set in any resource records in a 1519 response packet sent in legacy unicast responses to UDP ports other 1520 than 5353. 1522 The "cache flush" bit MUST NOT be set in any resource records in the 1523 known-answer list of any query packet. 1525 The "cache flush" bit MUST NOT ever be set in any shared resource 1526 record. To do so would cause all the other shared versions of this 1527 resource record with different rdata from different Responders to be 1528 immediately deleted from all the caches on the network. 1530 The "cache flush" bit does *not* apply to questions listed in the 1531 Question Section of a Multicast DNS packet. The top bit of the 1532 rrclass field in questions is used for an entirely different purpose 1533 (see Section 5.5, "Questions Requesting Unicast Responses"). 1535 Note that the "cache flush" bit is NOT part of the resource record 1536 class. The "cache flush" bit is the most significant bit of the 1537 second 16-bit word of a resource record in a Resource Record Section 1538 of an mDNS packet (the field conventionally referred to as the 1539 rrclass field), and the actual resource record class is the 1540 least-significant fifteen bits of this field. There is no mDNS 1541 resource record class 0x8001. The value 0x8001 in the rrclass field 1542 of a resource record in an mDNS response packet indicates a resource 1543 record with class 1, with the "cache flush" bit set. When receiving 1544 a resource record with the "cache flush" bit set, implementations 1545 should take care to mask off that bit before storing the resource 1546 record in memory, or otherwise ensure that it is given the correct 1547 semantic interpretation. 1549 The re-use of the top bit of the rrclass field only applies to 1550 conventional Resource Record types that are subject to caching, not 1551 to pseudo-RRs like OPT [RFC 2671], TSIG [RFC 2845], TKEY [RFC 2930], 1552 SIG0 [RFC 2931], etc., that pertain only to a particular transport 1553 level message and not to any actual DNS data. Since pseudo-RRs should 1554 never go into the mDNS cache, the concept of a "cache flush" bit for 1555 these types is not applicable. In particular the rrclass field of 1556 an OPT records encodes the sender's UDP payload size, and should 1557 be interpreted as a 16-bit length value in the range 0-65535, not 1558 a one-bit flag and a 15-bit length. 1560 10.4 Cache Flush on Topology change 1562 If the hardware on a given host is able to indicate physical changes 1563 of connectivity, then when the hardware indicates such a change, the 1564 host should take this information into account in its mDNS cache 1565 management strategy. For example, a host may choose to immediately 1566 flush all cache records received on a particular interface when that 1567 cable is disconnected. Alternatively, a host may choose to adjust the 1568 remaining TTL on all those records to a few seconds so that if the 1569 cable is not reconnected quickly, those records will expire from the 1570 cache. 1572 Likewise, when a host reboots, or wakes from sleep, or undergoes some 1573 other similar discontinuous state change, the cache management 1574 strategy should take that information into account. 1576 10.5 Cache Flush on Failure Indication 1578 Sometimes a cache record can be determined to be stale when a client 1579 attempts to use the rdata it contains, and finds that rdata to be 1580 incorrect. 1582 For example, the rdata in an address record can be determined to 1583 be incorrect if attempts to contact that host fail, either because 1584 ARP/ND requests for that address go unanswered (for an address on a 1585 local subnet) or because a router returns an ICMP "Host Unreachable" 1586 error (for an address on a remote subnet). 1588 The rdata in an SRV record can be determined to be incorrect if 1589 attempts to communicate with the indicated service at the host and 1590 port number indicated are not successful. 1592 The rdata in a DNS-SD PTR record can be determined to be incorrect if 1593 attempts to look up the SRV record it references are not successful. 1595 In any such case, the software implementing the mDNS resource record 1596 cache should provide a mechanism so that clients detecting stale 1597 rdata can inform the cache. 1599 When the cache receives this hint that it should reconfirm some 1600 record, it MUST issue two or more queries for the resource record in 1601 question. If no response is received in a reasonable amount of time, 1602 then, even though its TTL may indicate that it is not yet due to 1603 expire, that record SHOULD be promptly flushed from the cache. 1605 The end result of this is that if a printer suffers a sudden power 1606 failure or other abrupt disconnection from the network, its name 1607 may continue to appear in DNS-SD browser lists displayed on users' 1608 screens. Eventually that entry will expire from the cache naturally, 1609 but if a user tries to access the printer before that happens, the 1610 failure to successfully contact the printer will trigger the more 1611 hasty demise of its cache entries. This is a sensible trade-off 1612 between good user-experience and good network efficiency. If we were 1613 to insist that printers should disappear from the printer list within 1614 30 seconds of becoming unavailable, for all failure modes, the only 1615 way to achieve this would be for the client to poll the printer at 1616 least every 30 seconds, or for the printer to announce its presence 1617 at least every 30 seconds, both of which would be an unreasonable 1618 burden on most networks. 1620 10.6 Passive Observation of Failures (POOF) 1622 A host observes the multicast queries issued by the other hosts on 1623 the network. One of the major benefits of also sending responses 1624 using multicast is that it allows all hosts to see the responses 1625 (or lack thereof) to those queries. 1627 If a host sees queries, for which a record in its cache would be 1628 expected to be given as an answer in a multicast response, but no 1629 such answer is seen, then the host may take this as an indication 1630 that the record may no longer be valid. 1632 After seeing two or more of these queries, and seeing no multicast 1633 response containing the expected answer within a reasonable amount of 1634 time, then even though its TTL may indicate that it is not yet due to 1635 expire, that record MAY be flushed from the cache. The host SHOULD 1636 NOT perform its own queries to re-confirm that the record is truly 1637 gone. If every host on a large network were to do this, it would 1638 cause a lot of unnecessary multicast traffic. If host A sends 1639 multicast queries that remain unanswered, then there is no reason 1640 to suppose that host B or any other host is likely to be any more 1641 successful. 1643 The previous section, "Cache Flush on Failure Indication", describes 1644 a situation where a user trying to print discovers that the printer 1645 is no longer available. By implementing the passive observation 1646 described here, when one user fails to contact the printer, all 1647 hosts on the network observe that failure and update their caches 1648 accordingly. 1650 11. Source Address Check 1652 All Multicast DNS responses (including responses sent via unicast) 1653 SHOULD be sent with IP TTL set to 255. This is recommended to provide 1654 backwards-compatibility with older Multicast DNS clients that check 1655 the IP TTL on reception to determine whether the packet originated 1656 on the local link. These older clients discard all packets with TTLs 1657 other than 255. 1659 A host sending Multicast DNS queries to a link-local destination 1660 address (including the 224.0.0.251 and FF02::FB link-local multicast 1661 addresses) MUST only accept responses to that query that originate 1662 from the local link, and silently discard any other response packets. 1663 Without this check, it could be possible for remote rogue hosts to 1664 send spoof answer packets (perhaps unicast to the victim host) which 1665 the receiving machine could misinterpret as having originated on the 1666 local link. 1668 The test for whether a response originated on the local link 1669 is done in two ways: 1671 * All responses received with a destination address in the IP header 1672 which is the link-local multicast address 224.0.0.251 or FF02::FB 1673 are necessarily deemed to have originated on the local link, 1674 regardless of source IP address. This is essential to allow devices 1675 to work correctly and reliably in unusual configurations, such as 1676 multiple logical IP subnets overlayed on a single link, or in cases 1677 of severe misconfiguration, where devices are physically connected 1678 to the same link, but are currently misconfigured with completely 1679 unrelated IP addresses and subnet masks. 1681 * For responses received with a unicast destination address in the IP 1682 header, the source IP address in the packet is checked to see if it 1683 is an address on a local subnet. An address is determined to be on 1684 a local subnet if, for (one of) the address(es) configured on the 1685 interface receiving the packet, (I & M) == (P & M), where I and M 1686 are the interface address and subnet mask respectively, P is the 1687 source IP address from the packet, '&' represents the bitwise 1688 logical 'and' operation, and '==' represents a bitwise equality 1689 test. 1691 Since queriers will ignore responses apparently originating outside 1692 the local subnet, a Responder SHOULD avoid generating responses that 1693 it can reasonably predict will be ignored. This applies particularly 1694 in the case of overlayed subnets. If a Responder receives a query 1695 addressed to the link-local multicast address 224.0.0.251, from a 1696 source address not apparently on the same subnet as the Responder, 1697 then even if the query indicates that a unicast response is preferred 1698 (see Section 5.5, "Questions Requesting Unicast Responses"), the 1699 Responder SHOULD elect to respond by multicast anyway, since it can 1700 reasonably predict that a unicast response with an apparently 1701 non-local source address will probably be ignored. 1703 12. Special Characteristics of Multicast DNS Domains 1705 Unlike conventional DNS names, names that end in ".local." or 1706 "254.169.in-addr.arpa." have only local significance. The same is 1707 true of names within the IPv6 Link-Local reverse mapping domains. 1709 Conventional Unicast DNS seeks to provide a single unified namespace, 1710 where a given DNS query yields the same answer no matter where on the 1711 planet it is performed or to which recursive DNS server the query is 1712 sent. In contrast, each IP link has its own private ".local.", 1713 "254.169.in-addr.arpa." and IPv6 Link-Local reverse mapping 1714 namespaces, and the answer to any query for a name within those 1715 domains depends on where that query is asked. (This characteristic is 1716 not unique to Multicast DNS. Although the original concept of DNS was 1717 a single global namespace, in recent years split views, firewalls, 1718 intranets, and the like have increasingly meant that the answer to a 1719 given DNS query has become dependent on the location of the querier.) 1721 The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The 1722 IPv6 name server for a Multicast DNS Domain is FF02::FB. These are 1723 multicast addresses; therefore they identify not a single host but a 1724 collection of hosts, working in cooperation to maintain some 1725 reasonable facsimile of a competently managed DNS zone. Conceptually 1726 a Multicast DNS Domain is a single DNS zone, however its server is 1727 implemented as a distributed process running on a cluster of loosely 1728 cooperating CPUs rather than as a single process running on a single 1729 CPU. 1731 Multicast DNS Domains are not delegated from their parent domain via 1732 use of NS records, and there is also no concept of delegation of 1733 subdomains within a Multicast DNS Domain. Just because a particular 1734 host on the network may answer queries for a particular record type 1735 with the name "example.local." does not imply anything about whether 1736 that host will answer for the name "child.example.local.", or indeed 1737 for other record types with the name "example.local." 1739 There are no NS records anywhere in Multicast DNS Domains. Instead, 1740 the Multicast DNS Domains are reserved by IANA and there is 1741 effectively an implicit delegation of all Multicast DNS Domains 1742 to the 224.0.0.251:5353 and [FF02::FB]:5353, by virtue of client 1743 software implementing the protocol rules specified in this document. 1745 Multicast DNS Zones have no SOA record. A conventional DNS zone's 1746 SOA record contains information such as the email address of the zone 1747 administrator and the monotonically increasing serial number of the 1748 last zone modification. There is no single human administrator for 1749 any given Multicast DNS Zone, so there is no email address. Because 1750 the hosts managing any given Multicast DNS Zone are only loosely 1751 coordinated, there is no readily available monotonically increasing 1752 serial number to determine whether or not the zone contents have 1753 changed. A host holding part of the shared zone could crash or be 1754 disconnected from the network at any time without informing the other 1755 hosts. There is no reliable way to provide a zone serial number that 1756 would, whenever such a crash or disconnection occurred, immediately 1757 change to indicate that the contents of the shared zone had changed. 1759 Zone transfers are not possible for any Multicast DNS Zone. 1761 13. Multicast DNS for Service Discovery 1763 This document does not describe using Multicast DNS for network 1764 browsing or service discovery. However, the mechanisms this document 1765 describes are compatible with, and enable, the browsing and service 1766 discovery mechanisms specified in "DNS-Based Service Discovery" 1767 [DNS-SD]. 1769 14. Enabling and Disabling Multicast DNS 1771 The option to fail-over to Multicast DNS for names not ending 1772 in ".local." SHOULD be a user-configured option, and SHOULD 1773 be disabled by default because of the possible security issues 1774 related to unintended local resolution of apparently global names. 1776 The option to lookup unqualified (relative) names by appending 1777 ".local." (or not) is controlled by whether ".local." appears 1778 (or not) in the client's DNS search list. 1780 No special control is needed for enabling and disabling Multicast DNS 1781 for names explicitly ending with ".local." as entered by the user. 1782 The user doesn't need a way to disable Multicast DNS for names ending 1783 with ".local.", because if the user doesn't want to use Multicast 1784 DNS, they can achieve this by simply not using those names. If a user 1785 *does* enter a name ending in ".local.", then we can safely assume 1786 the user's intention was probably that it should work. Having user 1787 configuration options that can be (intentionally or unintentionally) 1788 set so that local names don't work is just one more way of 1789 frustrating the user's ability to perform the tasks they want, 1790 perpetuating the view that, "IP networking is too complicated to 1791 configure and too hard to use." 1793 15. Considerations for Multiple Interfaces 1795 A host SHOULD defend its dot-local host name on all active interfaces 1796 on which it is answering Multicast DNS queries. 1798 In the event of a name conflict on *any* interface, a host should 1799 configure a new host name, if it wishes to maintain uniqueness of its 1800 host name. 1802 A host may choose to use the same name for all of its address records 1803 on all interfaces, or it may choose to manage its Multicast DNS host 1804 name(s) independently on each interface, potentially answering to 1805 different names on different interfaces. 1807 When answering a Multicast DNS query, a multi-homed host with a 1808 link-local address (or addresses) SHOULD take care to ensure that 1809 any address going out in a Multicast DNS response is valid for use 1810 on the interface on which the response is going out. 1812 Just as the same link-local IP address may validly be in use 1813 simultaneously on different links by different hosts, the same 1814 link-local host name may validly be in use simultaneously on 1815 different links, and this is not an error. A multi-homed host with 1816 connections to two different links may be able to communicate with 1817 two different hosts that are validly using the same name. While this 1818 kind of name duplication should be rare, it means that a host that 1819 wants to fully support this case needs network programming APIs 1820 that allow applications to specify on what interface to perform a 1821 link-local Multicast DNS query, and to discover on what interface 1822 a Multicast DNS response was received. 1824 There is one other special precaution that multi-homed hosts need to 1825 take. It's common with today's laptop computers to have an Ethernet 1826 connection and an 802.11 [IEEE W] wireless connection active at the 1827 same time. What the software on the laptop computer can't easily tell 1828 is whether the wireless connection is in fact bridged onto the same 1829 network segment as its Ethernet connection. If the two networks are 1830 bridged together, then packets the host sends on one interface will 1831 arrive on the other interface a few milliseconds later, and care must 1832 be taken to ensure that this bridging does not cause problems: 1834 When the host announces its host name (i.e. its address records) on 1835 its wireless interface, those announcement records are sent with the 1836 cache-flush bit set, so when they arrive on the Ethernet segment, 1837 they will cause all the peers on the Ethernet to flush the host's 1838 Ethernet address records from their caches. The mDNS protocol has 1839 a safeguard to protect against this situation: when records are 1840 received with the cache-flush bit set, other records are not deleted 1841 from peer caches immediately, but are marked for deletion in one 1842 second. When the host sees its own wireless address records arrive on 1843 its Ethernet interface, with the cache-flush bit set, this one-second 1844 grace period gives the host time to respond and re-announce its 1845 Ethernet address records, to reinstate those records in peer caches 1846 before they are deleted. 1848 As described, this solves one problem, but creates another, because 1849 when those Ethernet announcement records arrive back on the wireless 1850 interface, the host would again respond defensively to reinstate 1851 its wireless records, and this process would continue forever, 1852 continuously flooding the network with traffic. The mDNS protocol has 1853 a second safeguard, to solve this problem: the cache-flush bit does 1854 not apply to records received very recently, within the last second. 1855 This means that when the host sees its own Ethernet address records 1856 arrive on its wireless interface, with the cache-flush bit set, it 1857 knows there's no need to re-announce its wireless address records 1858 again because it already sent them less than a second ago, and 1859 this makes them immune from deletion from peer caches. 1861 16. Considerations for Multiple Responders on the Same Machine 1863 It is possible to have more than one Multicast DNS Responder and/or 1864 Querier implementation coexist on the same machine, but there are 1865 some known issues. 1867 16.1 Receiving Unicast Responses 1869 In most operating systems, incoming *multicast* packets can be 1870 delivered to *all* open sockets bound to the right port number, 1871 provided that the clients take the appropriate steps to allow this. 1872 For this reason, all Multicast DNS implementations SHOULD use 1873 the SO_REUSEPORT and/or SO_REUSEADDR options (or equivalent as 1874 appropriate for the operating system in question) so they will all be 1875 able to bind to UDP port 5353 and receive incoming multicast packets 1876 addressed to that port. However, unlike multicast packets, incoming 1877 unicast UDP packets are typically delivered only to the first socket 1878 to bind to that port. This means that "QU" responses and other 1879 packets sent via unicast will be received only by the first Multicast 1880 DNS Responder and/or Querier on a system. This limitation can be 1881 partially mitigated if Multicast DNS implementations detect when they 1882 are not the first to bind to port 5353, and in that case they do not 1883 request "QU" responses. One way to detect if there is another 1884 Multicast DNS implementation already running is to attempt binding to 1885 port 5353 without using SO_REUSEPORT and/or SO_REUSEADDR, and if that 1886 fails it indicates that some other socket is already bound to this 1887 port. 1889 16.2 Multi-Packet Known-Answer lists 1891 When a Multicast DNS Querier issues a query with too many known 1892 answers to fit into a single packet, it divides the known answer list 1893 into two or more packets. Multicast DNS Responders associate the 1894 initial truncated query with its continuation packets by examining 1895 the source IP address in each packet. Since two independent Multicast 1896 DNS Queriers running on the same machine will be sending packets with 1897 the same source IP address, from an outside perspective they appear 1898 to be a single entity. If both Queriers happened to send the same 1899 multi-packet query at the same time, with different known answer 1900 lists, then they could each end up suppressing answers that the other 1901 needs. 1903 16.3 Efficiency 1905 If different clients on a machine were to each have their own 1906 separate independent Multicast DNS implementation, they would 1907 lose certain efficiency benefits. Apart from the unnecessary code 1908 duplication, memory usage, and CPU load, the clients wouldn't get the 1909 benefit of a shared system-wide cache, and they would not be able to 1910 aggregate separate queries into single packets to reduce network 1911 traffic. 1913 16.4 Recommendation 1915 Because of these issues, this document encourages implementers to 1916 design systems with a single Multicast DNS implementation that 1917 provides Multicast DNS services shared by all clients on that 1918 machine, much as most operating systems today have a single TCP 1919 implementation, which is shared between all clients on that machine. 1920 Due to engineering constraints, there may be situations where 1921 embedding a "user level" Multicast DNS implementation in the client 1922 application software is the most expedient solution, and while this 1923 will usually work in practice, implementers should be aware of the 1924 issues outlined in this section. 1926 17. Multicast DNS Character Set 1928 Historically, unicast DNS has been plagued by the lack of any support 1929 for non-US characters. Indeed, conventional DNS is usually limited to 1930 just letters, digits and hyphens, not even allowing spaces or other 1931 punctuation. Attempts to remedy this for unicast DNS have been badly 1932 constrained by the perceived need to accommodate old buggy legacy DNS 1933 implementations. In reality, the DNS specification itself actually 1934 imposes no limits on what characters may be used in names, and good 1935 DNS implementations handle any arbitrary eight-bit data without 1936 trouble. "Clarifications to the DNS Specification" [RFC 2181] 1937 directly discusses the subject of allowable character set in Section 1938 11 ("Name syntax"), and explicitly states that DNS names may contain 1939 arbitrary eight-bit data. However, the old rules for ARPANET host 1940 names back in the 1980s required host names to be just letters, 1941 digits, and hyphens [RFC 1034], and since the predominant use of DNS 1942 is to store host address records, many have assumed that the DNS 1943 protocol itself suffers from the same limitation. It might be 1944 accurate to say that there could be hypothetical bad implementations 1945 that do not handle eight-bit data correctly, but it would not be 1946 accurate to say that the protocol doesn't allow names containing 1947 eight-bit data. 1949 Multicast DNS is a new protocol and doesn't (yet) have old buggy 1950 legacy implementations to constrain the design choices. Accordingly, 1951 it adopts the simple obvious elegant solution: all names in Multicast 1952 DNS are encoded using precomposed UTF-8 [RFC 3629]. The characters 1953 SHOULD conform to Unicode Normalization Form C (NFC) [UAX15]: Use 1954 precomposed characters instead of combining sequences where possible, 1955 e.g. use U+00C4 ("Latin capital letter A with diaeresis") instead of 1956 U+0041 U+0308 ("Latin capital letter A", "combining diaeresis"). 1958 Some users of 16-bit Unicode have taken to stuffing a "zero-width 1959 non-breaking space" character (U+FEFF) at the start of each UTF-16 1960 file, as a hint to identify whether the data is big-endian or 1961 little-endian, and calling it a "Byte Order Mark" (BOM). Since there 1962 is only one possible byte order for UTF-8 data, a BOM is neither 1963 necessary nor permitted. Multicast DNS names MUST NOT contain a "Byte 1964 Order Mark". Any occurrence of the Unicode character U+FEFF at the 1965 start or anywhere else in a Multicast DNS name MUST be interpreted as 1966 being an actual intended part of the name, representing (just as for 1967 any other legal unicode value) an actual literal instance of that 1968 character (in this case a zero-width non-breaking space character). 1970 For names that are restricted to letters, digits and hyphens, the 1971 UTF-8 encoding is identical to the US-ASCII encoding, so this is 1972 entirely compatible with existing host names. For characters outside 1973 the US-ASCII range, UTF-8 encoding is used. 1975 Multicast DNS implementations MUST NOT use any other encodings apart 1976 from precomposed UTF-8 (US-ASCII being considered a compatible subset 1977 of UTF-8). The reasons for selecting UTF-8 instead of Punycode 1978 [RFC 3492] are discussed further in Appendix F. 1980 The simple rules for case-insensitivity in Unicast DNS also apply in 1981 Multicast DNS; that is to say, in name comparisons, the lower-case 1982 letters "a" to "z" (0x61 to 0x7A) match their upper-case equivalents 1983 "A" to "Z" (0x41 to 0x5A). Hence, if a client issues a query for an 1984 address record with the name "myprinter.local.", then a Responder 1985 having an address record with the name "MyPrinter.local." should 1986 issue a response. No other automatic equivalences should be assumed. 1987 In particular all UTF-8 multi-byte characters (codes 0x80 and higher) 1988 are compared by simple binary comparison of the raw byte values. 1989 Accented characters are *not* defined to be automatically equivalent 1990 to their unaccented counterparts. Where automatic equivalences are 1991 desired, this may be achieved through the use of programmatically- 1992 generated CNAME records. For example, if a Responder has an address 1993 record for an accented name Y, and a client issues a query for a name 1994 X, where X is the same as Y with all the accents removed, then the 1995 Responder may issue a response containing two resource records: 1996 A CNAME record "X CNAME Y", asserting that the requested name X 1997 (unaccented) is an alias for the true (accented) name Y, followed 1998 by the address record for Y. 2000 18. Multicast DNS Message Size 2002 RFC 1035 restricts DNS Messages carried by UDP to no more than 512 2003 bytes (not counting the IP or UDP headers) [RFC 1035]. For UDP 2004 packets carried over the wide-area Internet in 1987, this was 2005 appropriate. For link-local multicast packets on today's networks, 2006 there is no reason to retain this restriction. Given that the packets 2007 are by definition link-local, there are no Path MTU issues to 2008 consider. 2010 Multicast DNS Messages carried by UDP may be up to the IP MTU of the 2011 physical interface, less the space required for the IP header (20 2012 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes). 2014 In the case of a single mDNS Resource Record which is too large to 2015 fit in a single MTU-sized multicast response packet, a Multicast DNS 2016 Responder SHOULD send the Resource Record alone, in a single IP 2017 datagram, sent using multiple IP fragments. Resource Records this 2018 large SHOULD be avoided, except in the very rare cases where they 2019 really are the appropriate solution to the problem at hand. 2020 Implementers should be aware that many simple devices do not 2021 re-assemble fragmented IP datagrams, so large Resource Records 2022 SHOULD NOT be used except in specialized cases where the implementer 2023 knows that all receivers implement reassembly. 2025 A Multicast DNS packet larger than the interface MTU, which is sent 2026 using fragments, MUST NOT contain more than one Resource Record. 2028 Even when fragmentation is used, a Multicast DNS packet, including IP 2029 and UDP headers, MUST NOT exceed 9000 bytes. 9000 bytes is the 2030 maximum payload size of an Ethernet "Jumbo" packet, which makes it a 2031 convenient upper limit to specify for the maximum Multicast DNS 2032 packet size. (In practice Ethernet "Jumbo" packets are not widely 2033 used, so it is advantageous to keep packets under 1500 bytes whenever 2034 possible.) 2036 19. Multicast DNS Message Format 2038 This section describes specific rules pertaining to the allowable 2039 values for the header fields of a Multicast DNS message, and other 2040 message format considerations. 2042 19.1 ID (Query Identifier) 2044 Multicast DNS clients SHOULD listen for gratuitous responses 2045 issued by hosts booting up (or waking up from sleep or otherwise 2046 joining the network). Since these gratuitous responses may contain 2047 a useful answer to a question for which the client is currently 2048 awaiting an answer, Multicast DNS clients SHOULD examine all received 2049 Multicast DNS response messages for useful answers, without regard to 2050 the contents of the ID field or the Question Section. In Multicast 2051 DNS, knowing which particular query message (if any) is responsible 2052 for eliciting a particular response message is less interesting than 2053 knowing whether the response message contains useful information. 2055 Multicast DNS clients MAY cache any or all Multicast DNS response 2056 messages they receive, for possible future use, provided of course 2057 that normal TTL aging is performed on these cached resource records. 2059 In multicast query messages, the Query ID SHOULD be set to zero on 2060 transmission. 2062 In multicast responses, including gratuitous multicast responses, the 2063 Query ID MUST be set to zero on transmission, and MUST be ignored on 2064 reception. 2066 In unicast response messages generated specifically in response to a 2067 particular (unicast or multicast) query, the Query ID MUST match the 2068 ID from the query message. 2070 19.2 QR (Query/Response) Bit 2072 In query messages, MUST be zero. 2073 In response messages, MUST be one. 2075 19.3 OPCODE 2077 In both multicast query and multicast response messages, MUST be zero 2078 (only standard queries are currently supported over multicast). 2080 19.4 AA (Authoritative Answer) Bit 2082 In query messages, the Authoritative Answer bit MUST be zero on 2083 transmission, and MUST be ignored on reception. 2085 In response messages for Multicast Domains, the Authoritative Answer 2086 bit MUST be set to one (not setting this bit would imply there's some 2087 other place where "better" information may be found) and MUST be 2088 ignored on reception. 2090 19.5 TC (Truncated) Bit 2092 In query messages, if the TC bit is set, it means that additional 2093 Known Answer records may be following shortly. A Responder SHOULD 2094 record this fact, and wait for those additional Known Answer records, 2095 before deciding whether to respond. If the TC bit is clear, it means 2096 that the querying host has no additional Known Answers. 2098 In multicast response messages, the TC bit MUST be zero on 2099 transmission, and MUST be ignored on reception. 2101 In legacy unicast response messages, the TC bit has the same meaning 2102 as in conventional unicast DNS: it means that the response was too 2103 large to fit in a single packet, so the client SHOULD re-issue its 2104 query using TCP in order to receive the larger response. 2106 19.6 RD (Recursion Desired) Bit 2108 In both multicast query and multicast response messages, the 2109 Recursion Desired bit SHOULD be zero on transmission, and MUST be 2110 ignored on reception. 2112 19.7 RA (Recursion Available) Bit 2114 In both multicast query and multicast response messages, the 2115 Recursion Available bit MUST be zero on transmission, and MUST be 2116 ignored on reception. 2118 19.8 Z (Zero) Bit 2120 In both query and response messages, the Zero bit MUST be zero on 2121 transmission, and MUST be ignored on reception. 2123 19.9 AD (Authentic Data) Bit [RFC 2535] 2125 In both multicast query and multicast response messages the Authentic 2126 Data bit MUST be zero on transmission, and MUST be ignored on 2127 reception. 2129 19.10 CD (Checking Disabled) Bit [RFC 2535] 2131 In both multicast query and multicast response messages, the Checking 2132 Disabled bit MUST be zero on transmission, and MUST be ignored on 2133 reception. 2135 19.11 RCODE (Response Code) 2137 In both multicast query and multicast response messages, the Response 2138 Code MUST be zero on transmission. Multicast DNS messages received 2139 with non-zero Response Codes MUST be silently ignored. 2141 19.12 Repurposing of top bit of qclass in Question Section 2143 In the Question Section of a Multicast DNS Query, the top bit of the 2144 qclass field is used to indicate that unicast responses are preferred 2145 for this particular question. 2147 19.13 Repurposing of top bit of rrclass in Resource Record Sections 2149 In the Resource Record Sections of a Multicast DNS Response, the top 2150 bit of the rrclass field is used to indicate that the record is a 2151 member of a unique RRSet, and the entire RRSet has been sent together 2152 (in the same packet, or in consecutive packets if there are too many 2153 records to fit in a single packet). 2155 19.14 Name Compression 2157 When generating Multicast DNS packets, implementations SHOULD use 2158 name compression wherever possible to compress the names of resource 2159 records, by replacing some or all of the resource record name with a 2160 compact two-byte reference to an appearance of that data somewhere 2161 earlier in the packet [RFC 1035]. 2163 This applies not only to Multicast DNS Responses, but also to 2164 Queries. When a Query contains more than one question, successive 2165 questions in the same message often contain similar names, and 2166 consequently name compression SHOULD be used, to save bytes. In 2167 addition, Queries may also contain Known Answers in the Answer 2168 Section, or probe tie-breaking data in the Authority Section, and 2169 these names SHOULD similarly be compressed for network efficiency. 2171 In addition to compressing the *names* of resource records, names 2172 that appear within the *rdata* of the following rrtypes SHOULD also 2173 be compressed in all Multicast DNS packets: 2175 NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC 2177 Until future IETF Standards Action specifying that names in the rdata 2178 of other types should be compressed, names that appear within the 2179 rdata of any type not listed above MUST NOT be compressed. 2181 Implementations receiving Multicast DNS packets MUST correctly decode 2182 compressed names appearing in the Question Section, and compressed 2183 names of resource records appearing in other sections. 2185 In addition, implementations MUST correctly decode compressed names 2186 appearing within the *rdata* of the rrtypes listed above. Where 2187 possible, implementations SHOULD also correctly decode compressed 2188 names appearing within the *rdata* of other rrtypes known to 2189 the implementers at the time of implementation, because such 2190 forward-thinking planning helps facilitate the deployment of future 2191 implementations that may have reason to compress those rrtypes. It is 2192 possible that no future IETF Standards Action will be created which 2193 mandates or permits the compression of rdata in new types, but having 2194 implementations designed such that they are capable of decompressing 2195 all known types known helps keep future options open. 2197 One specific difference between Unicast DNS and Multicast DNS is that 2198 Unicast DNS does not allow name compression for the target host in an 2199 SRV record, because Unicast DNS implementations before the first SRV 2200 specification in 1996 [RFC 2052] may not decode these compressed 2201 records properly. Since all Multicast DNS implementations were 2202 created after 1996, all Multicast DNS implementations are REQUIRED 2203 to decode compressed SRV records correctly. 2205 In legacy unicast responses generated to answer legacy queries, name 2206 compression MUST NOT be performed on SRV records. 2208 20. Summary of Differences Between Multicast DNS and Unicast DNS 2210 The value of Multicast DNS is that it shares, as much as possible, 2211 the familiar APIs, naming syntax, resource record types, etc., of 2212 Unicast DNS. There are of course necessary differences by virtue of 2213 it using multicast, and by virtue of it operating in a community 2214 of cooperating peers, rather than a precisely defined hierarchy 2215 controlled by a strict chain of formal delegations from the root. 2216 These differences are summarized below: 2218 Multicast DNS... 2219 * uses multicast 2220 * uses UDP port 5353 instead of port 53 2221 * operates in well-defined parts of the DNS namespace 2222 * uses UTF-8, and only UTF-8, to encode resource record names 2223 * allows names up to 255 bytes plus a terminating zero byte 2224 * allows name compression in rdata for SRV and other record types 2225 * allows larger UDP packets 2226 * allows more than one question in a query packet 2227 * defines consistent results for qtype "ANY" and qclass "ANY" queries 2228 * uses the Answer Section of a query to list Known Answers 2229 * uses the TC bit in a query to indicate additional Known Answers 2230 * uses the Authority Section of a query for probe tie-breaking 2231 * ignores the Query ID field (except for generating legacy responses) 2232 * doesn't require the question to be repeated in the response packet 2233 * uses gratuitous responses to announce new records to the peer group 2234 * uses NSEC records to signal non-existence of records 2235 * defines a "unicast response" bit in the rrclass of query questions 2236 * defines a "cache flush" bit in the rrclass of response answers 2237 * uses DNS RR TTL 0 to indicate that a record has been deleted 2238 * recommends AAAA records in the additional section when responding 2239 to rrtype "A" queries, and vice versa 2240 * monitors queries to perform Duplicate Question Suppression 2241 * monitors responses to perform Duplicate Answer Suppression... 2242 * ... and Ongoing Conflict Detection 2243 * ... and Opportunistic Caching 2245 21. IPv6 Considerations 2247 An IPv4-only host and an IPv6-only host behave as "ships that pass in 2248 the night". Even if they are on the same Ethernet, neither is aware 2249 of the other's traffic. For this reason, each physical link may have 2250 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 2251 Since for practical purposes, a group of IPv4-only hosts and a group 2252 of IPv6-only hosts on the same Ethernet act as if they were on two 2253 entirely separate Ethernet segments, it is unsurprising that their 2254 use of the ".local." zone should occur exactly as it would if 2255 they really were on two entirely separate Ethernet segments. 2257 A dual-stack (v4/v6) host can participate in both ".local." 2258 zones, and should register its name(s) and perform its lookups both 2259 using IPv4 and IPv6. This enables it to reach, and be reached by, 2260 both IPv4-only and IPv6-only hosts. In effect this acts like a 2261 multi-homed host, with one connection to the logical "IPv4 Ethernet 2262 segment", and a connection to the logical "IPv6 Ethernet segment". 2264 22. Security Considerations 2266 The algorithm for detecting and resolving name conflicts is, by its 2267 very nature, an algorithm that assumes cooperating participants. Its 2268 purpose is to allow a group of hosts to arrive at a mutually disjoint 2269 set of host names and other DNS resource record names, in the absence 2270 of any central authority to coordinate this or mediate disputes. 2271 In the absence of any higher authority to resolve disputes, the only 2272 alternative is that the participants must work together cooperatively 2273 to arrive at a resolution. 2275 In an environment where the participants are mutually antagonistic 2276 and unwilling to cooperate, other mechanisms are appropriate, like 2277 manually configured DNS. 2279 In an environment where there is a group of cooperating participants, 2280 but there may be other antagonistic participants on the same physical 2281 link, the cooperating participants need to use IPSEC signatures 2282 and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS 2283 messages from trusted participants (which they process as usual) from 2284 mDNS messages from untrusted participants (which they silently 2285 discard). 2287 When DNS queries for *global* DNS names are sent to the mDNS 2288 multicast address (during network outages which disrupt communication 2289 with the greater Internet) it is *especially* important to use 2290 DNSSEC, because the user may have the impression that he or she is 2291 communicating with some authentic host, when in fact he or she is 2292 really communicating with some local host that is merely masquerading 2293 as that name. This is less critical for names ending with ".local.", 2294 because the user should be aware that those names have only local 2295 significance and no global authority is implied. 2297 Most computer users neglect to type the trailing dot at the end of a 2298 fully qualified domain name, making it a relative domain name (e.g. 2299 "www.example.com"). In the event of network outage, attempts to 2300 positively resolve the name as entered will fail, resulting in 2301 application of the search list, including ".local.", if present. 2302 A malicious host could masquerade as "www.example.com." by answering 2303 the resulting Multicast DNS query for "www.example.com.local." 2304 To avoid this, a host MUST NOT append the search suffix 2305 ".local.", if present, to any relative (partially qualified) 2306 host name containing two or more labels. Appending ".local." to 2307 single-label relative host names is acceptable, since the user 2308 should have no expectation that a single-label host name will 2309 resolve as-is. However, users who have both "example.com" and "local" 2310 in their search lists should be aware that if they type "www" into 2311 their web browser, it may not be immediately clear to them whether 2312 the page that appears is "www.example.com" or "www.local". 2314 Multicast DNS uses UDP port 5353. On operating systems where only 2315 privileged processes are allowed to use ports below 1024, no such 2316 privilege is required to use port 5353. 2318 23. IANA Considerations 2320 IANA has allocated the IPv4 link-local multicast address 224.0.0.251 2321 for the use described in this document. 2323 IANA has allocated the IPv6 multicast address set FF0X::FB 2324 for the use described in this document. Only address FF02::FB 2325 (Link-Local Scope) is currently in use by deployed software, 2326 but it is possible that in future implementers may experiment 2327 with Multicast DNS using larger-scoped addresses, such as FF05::FB 2328 (Site-Local Scope) [RFC 4291]. 2330 When this document is published, IANA should designate a list of 2331 domains which are deemed to have only link-local significance, as 2332 described in Section 12 of this document ("Special Characteristics of 2333 Multicast DNS Domains"). For discussion of why maintaining this list 2334 of reserved domains is an IANA function rather than an ICANN 2335 function, see Appendix G. For discussion of other "private" DNS 2336 Namespaces see Appendix H. 2338 Specifically, the designated link-local domains are: 2340 local. 2341 254.169.in-addr.arpa. 2342 8.e.f.ip6.arpa. 2343 9.e.f.ip6.arpa. 2344 a.e.f.ip6.arpa. 2345 b.e.f.ip6.arpa. 2347 These domains, and any of their subdomains (e.g. "MyPrinter.local.", 2348 "34.12.254.169.in-addr.arpa.", "Ink-Jet._pdl-datastream._tcp.local.") 2349 are special in the following ways: 2351 1. Users may use these names as they would other DNS names, entering 2352 them anywhere that they would otherwise enter a conventional 2353 DNS name, or a dotted decimal IPv4 address, or a literal IPv6 2354 address. 2356 Since there is no central authority responsible for assigning 2357 dot-local names, and all devices on the local network are equally 2358 entitled to claim any dot-local name, users SHOULD be aware of 2359 this and SHOULD exercise appropriate caution. In an untrusted or 2360 unfamiliar network environment, users SHOULD be aware that using 2361 a name like "www.local" may not actually connect them to the web 2362 site they expected, and could easily connect them to a different 2363 web page, or even a fake or spoof of their intended web site, 2364 designed to trick them into revealing confidential information. 2365 As always with networking, end-to-end cryptographic security can 2366 be a useful tool. For example, when connecting with ssh, the ssh 2367 host key verification process will inform the user if it detects 2368 that the identity of the entity they are communicating with has 2369 changed since the last time they connected to that name. 2371 2. Application software may use these names as they would other 2372 similar DNS names, and is not required to recognize the names 2373 and treat them specially. Due to the relative ease of spoofing 2374 dot-local names, end-to-end cryptographic security remains 2375 important when communicating across a local network, as it 2376 is when communicating across the global Internet. 2378 3. Name resolutions APIs and libraries SHOULD recognize these names 2379 as special and SHOULD NOT send queries for these names to their 2380 configured (unicast) caching DNS server(s). 2382 4. Caching DNS servers SHOULD recognize these names as special and 2383 SHOULD NOT attempt to look up NS records for them or otherwise 2384 query authoritative DNS servers in an attempt to resolve these 2385 names. Instead, caching DNS servers SHOULD generate immediate 2386 NXDOMAIN responses for all such queries they may receive (from 2387 misbehaving name resolver libraries). 2389 5. Authoritative DNS servers SHOULD NOT by default be configurable 2390 to answer queries for these names, and, like caching DNS servers, 2391 SHOULD generate immediate NXDOMAIN responses for all such queries 2392 they may receive. DNS server software MAY provide a configuration 2393 option to override this default, for testing purposes or other 2394 specialized uses. 2396 6. DNS server operators SHOULD NOT attempt to configure 2397 authoritative DNS servers to act as authoritative for any of 2398 these names. Configuring an authoritative DNS server to act as 2399 authoritative for any of these names may not, in many cases, 2400 yield the expected result, since name resolver libraries and 2401 caching DNS servers SHOULD NOT send queries for those names 2402 (see 3 and 4 above), so such queries SHOULD be suppressed before 2403 they even reach the authoritative DNS server in question, and 2404 consequently it will not even get an opportunity to answer them. 2406 7. DNS Registrars MUST NOT allow any of these names to be registered 2407 in the normal way to any person or entity. These names are 2408 reserved protocol identifiers with special meaning and fall 2409 outside the set of names available for allocation by registrars. 2410 Attempting to allocate one of these names as if it were a normal 2411 DNS domain name will probably not work as desired, for reasons 3, 2412 4 and 6 above. 2414 These names function primarily as protocol identifiers, rather than 2415 as user-visible identifiers, and even though they may occasionally 2416 be visible to end users, that is not their primary purpose. As such 2417 these names should be treated as opaque identifiers. In particular, 2418 the string "local" should not be translated or localized into 2419 different languages, much as the name "localhost" is not translated 2420 or localized into different languages. 2422 The re-use of the top bit of the rrclass field in the Question and 2423 Resource Record Sections means that Multicast DNS can only carry DNS 2424 records with classes in the range 0-32767. Classes in the range 32768 2425 to 65535 are incompatible with Multicast DNS. However, since to-date 2426 only three DNS classes have been assigned by IANA (1, 3 and 4), and 2427 only one (1, "Internet") is actually in widespread use, this 2428 limitation is likely to remain a purely theoretical one. 2430 No other IANA services are required by this document. 2432 24. Acknowledgments 2434 The concepts described in this document have been explored, developed 2435 and implemented with help from Freek Dijkstra, Erik Guttman, Paul 2436 Vixie, Bill Woodcock, and others. Special thanks go to Bob Bradley, 2437 Josh Graessley, Scott Herscher, Rory McGuire, Roger Pantos and Kiren 2438 Sekar for their significant contributions. 2440 25. Copyright Notice 2442 Copyright (c) 2010 IETF Trust and the persons identified as the 2443 document authors. All rights reserved. 2445 This document is subject to BCP 78 and the IETF Trust's Legal 2446 Provisions Relating to IETF Documents 2447 (http://trustee.ietf.org/license-info) in effect on the date of 2448 publication of this document. Please review these documents 2449 carefully, as they describe your rights and restrictions with respect 2450 to this document. 2452 26. Normative References 2454 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 2455 Facilities", STD 13, RFC 1034, November 1987. 2457 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 2458 Specification", STD 13, RFC 1035, November 1987. 2460 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 2461 Requirement Levels", RFC 2119, March 1997. 2463 [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO 2464 10646", RFC 3629, November 2003. 2466 [RFC 3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) 2467 RDATA Format", RFC 3845, August 2004. 2469 [UAX15] "Unicode Normalization Forms" 2470 2472 27. Informative References 2474 [B4W] Bonjour for Windows 2475 2477 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service 2478 Discovery", Internet-Draft (work in progress), 2479 draft-cheshire-dnsext-dns-sd-06.txt, March 2010. 2481 [IEEE 802] IEEE Standards for Local and Metropolitan Area Networks: 2482 Overview and Architecture. 2483 Institute of Electrical and Electronic Engineers, 2484 IEEE Standard 802, 1990. 2486 [IEEE W] 2488 [ATalk] Cheshire, S., and M. Krochmal, 2489 "Requirements for a Protocol to Replace AppleTalk NBP", 2490 Internet-Draft (work in progress), 2491 draft-cheshire-dnsext-nbp-08.txt, March 2010. 2493 [RFC 2052] Gulbrandsen, A., et al., "A DNS RR for specifying the 2494 location of services (DNS SRV)", RFC 2782, October 1996. 2496 [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP 2497 Vendor Extensions", RFC 2132, March 1997. 2499 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 2500 System (DNS UPDATE)", RFC 2136, April 1997. 2502 [RFC 2181] Elz, R., and Bush, R., "Clarifications to the DNS 2503 Specification", RFC 2181, July 1997. 2505 [RFC 2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 2506 Discovery for IP Version 6", RFC 2461, December 1998. 2508 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address 2509 Autoconfiguration", RFC 2462, December 1998. 2511 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", 2512 RFC 2535, March 1999. 2514 [RFC 2606] Eastlake, D., and A. Panitz, "Reserved Top Level DNS 2515 Names", RFC 2606, June 1999. 2517 [RFC 2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 2518 RFC 2671, August 1999. 2520 [RFC 2845] Vixie, P., et al., "Secret Key Transaction Authentication 2521 for DNS (TSIG)", RFC 2845, May 2000. 2523 [RFC 2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum 2524 of Understanding Concerning the Technical Work of the 2525 Internet Assigned Numbers Authority", RFC 2860, June 2526 2000. 2528 [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS 2529 (TKEY RR)", RFC 2930, September 2000. 2531 [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures 2532 ( SIG(0)s )", RFC 2931, September 2000. 2534 [RFC 3492] Costello, A., "Punycode: A Bootstring encoding of 2535 Unicode for use with Internationalized Domain Names 2536 in Applications (IDNA)", RFC 3492, March 2003. 2538 [RFC 3927] Cheshire, S., B. Aboba, and E. Guttman, 2539 "Dynamic Configuration of IPv4 Link-Local Addresses", 2540 RFC 3927, May 2005. 2542 [RFC 4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2543 Architecture", RFC 4291, February 2006. 2545 [Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration 2546 Networking: The Definitive Guide", O'Reilly Media, Inc., 2547 December 2005. 2549 28. Authors' Addresses 2551 Stuart Cheshire 2552 Apple Inc. 2553 1 Infinite Loop 2554 Cupertino 2555 California 95014 2556 USA 2558 Phone: +1 408 974 3207 2559 EMail: cheshire@apple.com 2561 Marc Krochmal 2562 Apple Inc. 2563 1 Infinite Loop 2564 Cupertino 2565 California 95014 2566 USA 2568 Phone: +1 408 974 4368 2569 EMail: marc@apple.com 2571 Appendix A. Design Rationale for Choice of UDP Port Number 2573 Arguments were made for and against using Multicast on UDP port 53. 2574 The final decision was to use UDP port 5353. Some of the arguments 2575 for and against are given below. 2577 Arguments for using UDP port 53: 2579 * This is "just DNS", so it should be the same port. 2581 * There is less work to be done updating old clients to do simple 2582 mDNS queries. Only the destination address need be changed. 2583 In some cases, this can be achieved without any code changes, 2584 just by adding the address 224.0.0.251 to a configuration file. 2586 Arguments for using a different port (UDP port 5353): 2588 * This is not "just DNS". This is a DNS-like protocol, but different. 2590 * Changing client code to use a different port number is not hard. 2592 * Using the same port number makes it hard to run an mDNS Responder 2593 and a conventional unicast DNS server on the same machine. If a 2594 conventional unicast DNS server wishes to implement mDNS as well, 2595 it can still do that, by opening two sockets. Having two different 2596 port numbers allows this flexibility. 2598 * Some VPN software hijacks all outgoing traffic to port 53 and 2599 redirects it to a special DNS server set up to serve those VPN 2600 clients while they are connected to the corporate network. It is 2601 questionable whether this is the right thing to do, but it is 2602 common, and redirecting link-local multicast DNS packets to a 2603 remote server rarely produces any useful results. It does mean, 2604 for example, that a user of such VPN software becomes unable to 2605 access their local network printer sitting on their desk right next 2606 to their computer. Using a different UDP port helps avoid this 2607 particular problem. 2609 * On many operating systems, unprivileged clients may not send or 2610 receive packets on low-numbered ports. This means that any client 2611 sending or receiving mDNS packets on port 53 would have to run 2612 as "root", which is an undesirable security risk. Using a higher- 2613 numbered UDP port avoids this restriction. 2615 Appendix B. Design Rationale for Not Using Hashed Multicast Addresses 2617 Some discovery protocols use a range of multicast addresses, and 2618 determine the address to be used by a hash function of the name being 2619 sought. Queries are sent via multicast to the address as indicated 2620 by the hash function, and responses are returned to the querier 2621 via unicast. Particularly in IPv6, where multicast addresses 2622 are extremely plentiful, this approach is frequently advocated. 2623 For example, IPv6 Neighbor Discovery [RFC 2461] sends Neighbor 2624 Solicitation messages to the "solicited-node multicast address", 2625 which is computed as a function of the solicited IPv6 address. 2627 There are some disadvantages to using hashed multicast addresses 2628 like this in a service discovery protocol: 2630 * When a host has a large number of records with different names, 2631 the host may have to join a large number of multicast groups. This 2632 can place undue burden on the Ethernet hardware, which typically 2633 supports a limited number of multicast addresses efficiently. 2634 When this number is exceeded, the Ethernet hardware may have to 2635 resort to receiving all multicasts and passing them up to the host 2636 networking code for filtering in software, thereby defeating much 2637 of the point of using a multicast address range in the first place. 2639 * Multiple questions cannot be placed in one packet if they don't all 2640 hash to the same multicast address. 2642 * Duplicate Question Suppression doesn't work if queriers are not 2643 seeing each other's queries. 2645 * Duplicate Answer Suppression doesn't work if Responders are not 2646 seeing each other's responses. 2648 * Opportunistic Caching doesn't work. 2650 * Ongoing Conflict Detection doesn't work. 2652 Appendix C. Design Rationale for Maximum Multicast DNS Name Length 2654 Multicast DNS domain names may be up to 255 bytes long, not counting 2655 the terminating zero byte at the end. 2657 "Domain Names - Implementation and Specification" [RFC 1035] says: 2659 Various objects and parameters in the DNS have size limits. 2660 They are listed below. Some could be easily changed, others 2661 are more fundamental. 2663 labels 63 octets or less 2665 names 255 octets or less 2667 ... 2669 the total length of a domain name (i.e., label octets and 2670 label length octets) is restricted to 255 octets or less. 2672 This text does not state whether this 255-byte limit includes the 2673 terminating zero at the end of every name. 2675 Several factors lead us to conclude that the 255-byte limit does 2676 *not* include the terminating zero: 2678 o It is common in software engineering to have size limits that 2679 are a power of two, or a multiple of a power of two, for 2680 efficiency. For example, an integer on a modern processor is 2681 typically 2, 4, or 8 bytes, not 3 or 5 bytes. The number 255 is not 2682 a power of two, nor is it to most people a particularly noteworthy 2683 number. It is noteworthy to computer scientists for only one reason 2684 -- because it is exactly one *less* than a power of two. When a 2685 size limit is exactly one less than a power of two, that suggests 2686 strongly that the one extra byte is being reserved for some 2687 specific reason -- in this case reserved perhaps to leave room 2688 for a terminating zero at the end. 2690 o In the case of DNS label lengths, the stated limit is 63 bytes. 2691 As with the total name length, this limit is exactly one less than 2692 a power of two. This label length limit also excludes the label 2693 length byte at the start of every label. Including that extra byte, 2694 a 63-byte label takes 64 bytes of space in memory or in a DNS 2695 packet. 2697 o It is common in software engineering for the semantic "length" 2698 of an object to be one less than the number of bytes it takes to 2699 store that object. For example, in C, strlen("foo") is 3, but 2700 sizeof("foo") (which includes the terminating zero byte at the end) 2701 is 4. 2703 o The text describing the total length of a domain name mentions 2704 explicitly that label length and data octets are included, but does 2705 not mention the terminating zero at the end. The zero byte at the 2706 end of a domain name is not a label length. Indeed, the value zero 2707 is chosen as the terminating marker precisely because it is not a 2708 legal length byte value -- DNS prohibits empty labels. For example, 2709 a name like "bad..name." is not a valid domain name because it 2710 contains a zero-length label in the middle, which cannot be 2711 expressed in a DNS packet, because software parsing the packet 2712 would misinterpret a zero label-length byte as being a zero 2713 "end of name" marker instead. 2715 Finally, "Clarifications to the DNS Specification" [RFC 2181] offers 2716 additional confirmation that in the context of DNS specifications the 2717 stated "length" of a domain name does not include the terminating 2718 zero byte at the end. That document refers to the root name, which 2719 is typically written as "." and is represented in a DNS packet by 2720 a single lone zero byte (i.e. zero bytes of data plus a terminating 2721 zero), as the "zero length full name": 2723 The zero length full name is defined as representing the root 2724 of the DNS tree, and is typically written and displayed as ".". 2726 This wording supports the interpretation that, in a DNS context, when 2727 talking about lengths of names, the terminating zero byte at the end 2728 is not counted. If the root name (".") is considered to be zero 2729 length, then to be consistent, the length (for example) of "org" has 2730 to be 4 and the length of "ietf.org" has to be 9, as shown below: 2732 ------ 2733 | 0x00 | length = 0 2734 ------ 2736 ------------------ ------ 2737 | 0x03 | o | r | g | | 0x00 | length = 4 2738 ------------------ ------ 2740 ----------------------------------------- ------ 2741 | 0x04 | i | e | t | f | 0x03 | o | r | g | | 0x00 | length = 9 2742 ----------------------------------------- ------ 2744 This means that the maximum length of a domain name, as represented 2745 in a Multicast DNS packet, up to but not including the final 2746 terminating zero, must not exceed 255 bytes. 2748 However, many unicast DNS implementers have read these RFCs 2749 differently, and argue that the 255-byte limit does include 2750 the terminating zero, and that the "Clarifications to the DNS 2751 Specification" [RFC 2181] statement that "." is the "zero length 2752 full name" was simply a mistake. 2754 Hence, implementers should be aware that other unicast DNS 2755 implementations may limit the maximum domain name to 254 bytes plus 2756 a terminating zero, depending on how that implementer interpreted 2757 the DNS specifications. 2759 Compliant Multicast DNS implementations must support names up to 2760 255 bytes plus a terminating zero, i.e. 256 bytes total. 2762 Appendix D. Benefits of Multicast Responses 2764 Some people have argued that sending responses via multicast is 2765 inefficient on the network. In fact using multicast responses can 2766 result in a net lowering of overall multicast traffic for a variety 2767 of reasons, and provides other benefits too: 2769 * Opportunistic Caching. One multicast response can update the caches 2770 on all machines on the network. If another machine later wants to 2771 issue the same query, it already has the answer in its cache, so it 2772 may not need to even transmit that multicast query on the network 2773 at all. 2775 * Duplicate Query Suppression. When more than one machine has the 2776 same ongoing long-lived query running, every machine does not have 2777 to transmit its own independent query. When one machine transmits 2778 a query, all the other hosts see the answers, so they can suppress 2779 their own queries. 2781 * Passive Observation Of Failures (POOF). When a host sees a 2782 multicast query, but does not see the corresponding multicast 2783 response, it can use this information to promptly delete stale data 2784 from its cache. To achieve the same level of user-interface quality 2785 and responsiveness without multicast responses would require lower 2786 cache lifetimes and more frequent network polling, resulting in a 2787 higher packet rate. 2789 * Passive Conflict Detection. Just because a name has been previously 2790 verified unique does not guarantee it will continue to be 2791 so indefinitely. By allowing all Multicast DNS Responders to 2792 constantly monitor their peers' responses, conflicts arising out 2793 of network topology changes can be promptly detected and resolved. 2794 If responses were not sent via multicast, some other conflict 2795 detection mechanism would be needed, imposing its own additional 2796 burden on the network. 2798 * Use on devices with constrained memory resources: When using 2799 delayed responses to reduce network collisions, clients need to 2800 maintain a list recording to whom each answer should be sent. The 2801 option of multicast responses allows clients with limited storage, 2802 which cannot store an arbitrarily long list of response addresses, 2803 to choose to fail-over to a single multicast response in place of 2804 multiple unicast responses, when appropriate. 2806 * Overlayed Subnets. In the case of overlayed subnets, multicast 2807 responses allow a receiver to know with certainty that a response 2808 originated on the local link, even when its source address may 2809 apparently suggest otherwise. 2811 * Robustness in the face of misconfiguration: Link-local multicast 2812 transcends virtually every conceivable network misconfiguration. 2813 Even if you have a collection of devices where every device's IP 2814 address, subnet mask, default gateway, and DNS server address are 2815 all wrong, packets sent by any of those devices addressed to a 2816 link-local multicast destination address will still be delivered 2817 to all peers on the local link. This can be extremely helpful when 2818 diagnosing and rectifying network problems, since it facilitates a 2819 direct communication channel between client and server that works 2820 without reliance on ARP, IP routing tables, etc. Being able to 2821 discover what IP address a device has (or thinks it has) is 2822 frequently a very valuable first step in diagnosing why it is 2823 unable to communicate on the local network. 2825 Appendix E. Design Rationale for Encoding Negative Responses 2827 Alternative methods of asserting nonexistence were considered, such 2828 as using an NXDOMAIN response, or emitting a resource record with 2829 zero-length rdata. 2831 Using an NXDOMAIN response does not work well with Multicast DNS. 2832 A Unicast DNS NXDOMAIN response applies to the entire packet, but 2833 for efficiency Multicast DNS allows (and encourages) multiple 2834 responses in a single packet. If the error code in the header were 2835 NXDOMAIN, it would not be clear to which name(s) that error code 2836 applied. 2838 Asserting nonexistence by emitting a resource record with zero-length 2839 rdata would mean that there would be no way to differentiate between 2840 a record that doesn't exist, and a record that does exist, with 2841 zero-length rdata. By analogy, most file systems today allow empty 2842 files, so a file that exists with zero bytes of data is not 2843 considered equivalent to a filename that does not exist. 2845 A benefit of asserting nonexistence through NSEC records instead of 2846 through NXDOMAIN responses is that NSEC records can be added to the 2847 Additional Section of a DNS Response to offer additional information 2848 beyond what the client explicitly requested. For example, in a 2849 response to an SRV query, a Responder should include 'A' record(s) 2850 giving its IPv4 addresses in the Additional Section, and if it has no 2851 IPv6 addresses then it should include an NSEC record indicating this 2852 fact in the Additional Section too. In effect, the Responder is 2853 saying, "Here's my SRV record, and here are my IPv4 addresses, 2854 and no, I don't have any IPv6 addresses, so don't waste your time 2855 asking." Without this information in the Additional Section it would 2856 take the client an additional round-trip to perform an additional 2857 Query to ascertain that the target host has no AAAA records. 2858 (Arguably Unicast DNS could also benefit from this ability to express 2859 nonexistence in the Additional Section, but that is outside the scope 2860 of this document.) 2862 Appendix F. Use of UTF-8 2864 After many years of debate, as a result of the perceived need to 2865 accommodate certain DNS implementations that apparently couldn't 2866 handle any character that's not a letter, digit or hyphen (and 2867 apparently never would be updated to remedy this limitation) the 2868 unicast DNS community settled on an extremely baroque encoding called 2869 "Punycode" [RFC 3492]. Punycode is a remarkably ingenious encoding 2870 solution, but it is complicated, hard to understand, and hard to 2871 implement, using sophisticated techniques including insertion unsort 2872 coding, generalized variable-length integers, and bias adaptation. 2873 The resulting encoding is remarkably compact given the constraints, 2874 but it's still not as good as simple straightforward UTF-8, and it's 2875 hard even to predict whether a given input string will encode to a 2876 Punycode string that fits within DNS's 63-byte limit, except by 2877 simply trying the encoding and seeing whether it fits. Indeed, the 2878 encoded size depends not only on the input characters, but on the 2879 order they appear, so the same set of characters may or may not 2880 encode to a legal Punycode string that fits within DNS's 63-byte 2881 limit, depending on the order the characters appear. This is 2882 extremely hard to present in a user interface that explains to users 2883 why one name is allowed, but another name containing the exact same 2884 characters is not. Neither Punycode nor any other of the "Ascii 2885 Compatible Encodings" proposed for Unicast DNS may be used in 2886 Multicast DNS packets. Any text being represented internally in some 2887 other representation must be converted to canonical precomposed UTF-8 2888 before being placed in any Multicast DNS packet. 2890 Appendix G. Governing Standards Body 2892 Note that this use of the ".local." suffix falls under IETF/IANA 2893 jurisdiction, not ICANN jurisdiction. DNS is an IETF network 2894 protocol, governed by protocol rules defined by the IETF. These IETF 2895 protocol rules dictate character set, maximum name length, packet 2896 format, etc. ICANN determines additional rules that apply when the 2897 IETF's DNS protocol is used on the public Internet. In contrast, 2898 private uses of the DNS protocol on isolated private networks are not 2899 governed by ICANN. Since this change is a change to the core DNS 2900 protocol rules, it affects everyone, not just those machines using 2901 the public Internet. Hence this change falls into the category of an 2902 IETF protocol rule, not an ICANN usage rule. 2904 This allocation of responsibility is formally established in 2905 "Memorandum of Understanding Concerning the Technical Work of the 2906 Internet Assigned Numbers Authority" [RFC 2860]. Exception (a) of 2907 clause 4.3 states that the IETF has the authority to instruct IANA 2908 to reserve pseudo-TLDs as required for protocol design purposes. 2909 For example, "Reserved Top Level DNS Names" [RFC 2606] defines 2910 the following pseudo-TLDs: 2912 .test 2913 .example 2914 .invalid 2915 .localhost 2917 Appendix H. Private DNS Namespaces 2919 The special treatment of names ending in ".local." has been 2920 implemented in Macintosh computers since the days of Mac OS 9, and 2921 continues today in Mac OS X. There are also implementations for 2922 Microsoft Windows [B4W], Linux, and other platforms. Operators 2923 setting up private internal networks ("intranets") are advised that 2924 their lives may be easier if they avoid using the suffix ".local." in 2925 names in their private internal DNS server. Alternative possibilities 2926 include: 2928 .intranet 2929 .internal 2930 .private 2931 .corp 2932 .home 2933 .lan 2935 At sites where the DNS operator has decided to use the suffix 2936 ".local." for private internal names, clients can be configured to 2937 send both Multicast and Unicast DNS queries in parallel for these 2938 names. This allows names to be looked up both ways, but it is NOT 2939 RECOMMENDED because it results in additional network traffic and 2940 additional delays in name resolution, as well as potentially creating 2941 user confusion when it is not clear whether any given result was 2942 received via link-local multicast from a peer on the same link, 2943 or from the configured unicast name server. 2945 Appendix I. Deployment History 2947 Internet Draft "draft-cheshire-dnsext-multicastdns-00.txt" was 2948 published in July 2001, and later that same year an update to 2949 Mac OS 9 added client support for Multicast DNS. If the user typed a 2950 name such as "MyPrinter.local." into any piece of networking software 2951 that used the standard Mac OS 9 name lookup APIs, then those name 2952 lookup APIs would recognize the name as a dot-local name and 2953 query for it by sending simple one-shot Multicast DNS Queries to 2954 224.0.0.251:5353. This enabled the user to, for example, enter the 2955 name "MyPrinter.local." into their web browser in order to view 2956 a printer's status and configuration web page, or enter the name 2957 "MyPrinter.local." into the printer setup utility to create a print 2958 queue for printing documents on that printer. 2960 Multicast DNS Responder software first began shipping to end users 2961 in volume with the launch of Mac OS X 10.2 Jaguar in August 2002, 2962 and network printer makers (who had historically supported AppleTalk 2963 in their network printers, and were receptive to IP-based 2964 technologies that could offer them similar ease-of-use) started 2965 adopting Multicast DNS shortly thereafter. 2967 In September 2002 Apple released the source code for the 2968 mDNSResponder daemon as Open Source under Apple's standard Apple 2969 Public Source License (APSL). 2971 Multicast DNS Responder software became available for Microsoft 2972 Windows users in June 2004 with the launch of Apple's "Rendezvous 2973 for Windows" (now "Bonjour for Windows"), both in executable form (a 2974 downloadable installer for end users) and as Open Source (one of the 2975 supported platforms within Apple's body of cross-platform code in the 2976 publicly-accessible mDNSResponder CVS source code repository) [B4W]. 2978 In August 2006, Apple re-licensed the cross-platform mDNSResponder 2979 source code under the Apache License, Version 2.0. 2981 In addition to desktop and laptop computers running Mac OS X and 2982 Microsoft Windows, Multicast DNS is implemented in a wide range of 2983 hardware devices, such as Apple's "AirPort" wireless base stations, 2984 iPhone and iPad, and in home gateways from other vendors, network 2985 printers, network cameras, TiVo DVRs, etc. 2987 The Open Source community has produced many independent 2988 implementations of Multicast DNS, some in C like Apple's 2989 mDNSResponder daemon, and others in a variety of different languages 2990 including Java, Python, Perl, and C#/Mono.