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