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