idnits 2.17.1 draft-cheshire-dnsext-multicastdns-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2130. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == The page length should not exceed 58 lines per page, but there was 45 longer pages, the longest (page 1) being 60 lines 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 10 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2005) is 6883 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 1035' is defined on line 2137, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-03 == Outdated reference: A later version (-10) exists of draft-cheshire-dnsext-nbp-04 -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Document: draft-cheshire-dnsext-multicastdns-05.txt Stuart Cheshire 2 Category: Standards Track Marc Krochmal 3 Expires 7th December 2005 Apple Computer, Inc. 4 7th June 2005 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 more 39 ubiquitous, the ability to operate with less configured 40 infrastructure is increasingly important. In particular, the ability 41 to look up DNS resource record data types (including, but not limited 42 to, host names) in the absence of a conventional managed DNS server, 43 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..............4 61 3. Multicast DNS Names............................................5 62 4. Source Address Check...........................................8 63 5. Reverse Address Mapping........................................9 64 6. Querying.......................................................9 65 7. Duplicate Suppression.........................................13 66 8. Responding....................................................15 67 9. Probing and Announcing on Startup.............................18 68 10. Conflict Resolution...........................................22 69 11. Resource Record TTL Values and Cache Coherency................23 70 12. Special Characteristics of Multicast DNS Domains..............28 71 13. Multicast DNS for Service Discovery...........................30 72 14. Enabling and Disabling Multicast DNS..........................30 73 15. Considerations for Multiple Interfaces........................31 74 16. Multicast DNS and Power Management............................32 75 17. Multicast DNS Character Set...................................33 76 18. Multicast DNS Message Size....................................34 77 19. Multicast DNS Message Format..................................35 78 20. Choice of UDP Port Number.....................................38 79 21. Summary of Differences Between Multicast DNS and Unicast DNS..39 80 22. Benefits of Multicast Responses...............................40 81 23. IPv6 Considerations...........................................41 82 24. Security Considerations.......................................42 83 25. IANA Considerations...........................................43 84 26. Acknowledgments...............................................43 85 27. Copyright Notice..............................................43 86 28. Normative References..........................................44 87 29. Informative References........................................44 88 30. Authors' Addresses............................................45 90 1. Introduction 92 When reading this document, familiarity with the concepts of Zero 93 Configuration Networking [ZC] and automatic link-local addressing 94 [RFC 2462] [RFC 3927] is helpful. 96 This document proposes no change to the structure of DNS messages, 97 and no new operation codes, response codes, or resource record types. 98 This document simply discusses what needs to happen if DNS clients 99 start sending DNS queries to a multicast address, and how a 100 collection of hosts can cooperate to collectively answer those 101 queries in a useful manner. 103 There has been discussion of how much burden Multicast DNS might 104 impose on a network. It should be remembered that whenever IPv4 hosts 105 communicate, they broadcast ARP packets on the network on a regular 106 basis, and this is not disastrous. The approximate amount of 107 multicast traffic generated by hosts making conventional use of 108 Multicast DNS is anticipated to be roughly the same order of 109 magnitude as the amount of broadcast ARP traffic those hosts already 110 generate. 112 New applications making new use of Multicast DNS capabilities for 113 unconventional purposes may generate more traffic. If some of those 114 new applications are "chatty", then work will be needed to help them 115 become less chatty. When performing any analysis, it is important to 116 make a distinction between the application behavior and the 117 underlying protocol behavior. If a chatty application uses UDP, that 118 doesn't mean that UDP is chatty, or that IP is chatty, or that 119 Ethernet is chatty. What it means is that the application is chatty. 120 The same applies to any future applications that may decide to layer 121 increasing portions of their functionality over Multicast DNS. 123 2. Conventions and Terminology Used in this Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in "Key words for use in 128 RFCs to Indicate Requirement Levels" [RFC 2119]. 130 This document uses the term "host name" in the strict sense to mean a 131 fully qualified domain name that has an address record. It does not 132 use the term "host name" in the commonly used but incorrect sense to 133 mean just the first DNS label of a host's fully qualified domain 134 name. 136 A DNS (or mDNS) packet contains an IP TTL in the IP header, which 137 is effectively a hop-count limit for the packet, to guard against 138 routing loops. Each Resource Record also contains a TTL, which is 139 the number of seconds for which the Resource Record may be cached. 141 In any place where there may be potential confusion between these two 142 types of TTL, the term "IP TTL" is used to refer to the IP header TTL 143 (hop limit), and the term "RR TTL" is used to refer to the Resource 144 Record TTL (cache lifetime). 146 When this document uses the term "Multicast DNS", it should be taken 147 to mean: "Clients performing DNS-like queries for DNS-like resource 148 records by sending DNS-like UDP query and response packets over IP 149 Multicast to UDP port 5353." 151 This document uses the terms "shared" and "unique" when referring to 152 resource record sets. 154 A "shared" resource record set is one where several Multicast DNS 155 responders may have records with that name, rrtype, and rrclass, and 156 several responders may respond to a particular query. 158 A "unique" resource record set is one where all the records with that 159 name, rrtype, and rrclass are under the control or ownership of a 160 single responder, and at most one responder should respond to any 161 given query. Before claiming ownership of a unique resource record 162 set, a responder MUST probe to verify that no other responder 163 already claims ownership of that set, as described in Section 9.1 164 "Probing". 166 Strictly speaking the terms "shared" and "unique" apply to resource 167 record sets, not to individual resource records, but it is sometimes 168 convenient to talk of "shared resource records" and "unique resource 169 records". When used this way, the terms should be understood to mean 170 a record that is a member of a "shared" or "unique" resource record 171 set, respectively. 173 3. Multicast DNS Names 175 This document proposes that the DNS top-level domain ".local." be 176 designated a special domain with special semantics, namely that any 177 fully-qualified name ending in ".local." is link-local, and names 178 within this domain are meaningful only on the link where they 179 originate. This is analogous to IPv4 addresses in the 169.254/16 180 prefix, which are link-local and meaningful only on the link where 181 they originate. 183 Any DNS query for a name ending with ".local." MUST be sent 184 to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent 185 FF02::FB). 187 It is unimportant whether a name ending with ".local." occurred 188 because the user explicitly typed in a fully qualified domain name 189 ending in ".local.", or because the user entered an unqualified 190 domain name and the host software appended the suffix ".local." 191 because that suffix appears in the user's search list. The ".local." 192 suffix could appear in the search list because the user manually 193 configured it, or because it was received in a DHCP option, or via 194 any other valid mechanism for configuring the DNS search list. In 195 this respect the ".local." suffix is treated no differently to any 196 other search domain that might appear in the DNS search list. 198 DNS queries for names that do not end with ".local." MAY be sent to 199 the mDNS multicast address, if no other conventional DNS server is 200 available. This can allow hosts on the same link to continue 201 communicating using each other's globally unique DNS names during 202 network outages which disrupt communication with the greater 203 Internet. When resolving global names via local multicast, it is even 204 more important to use DNSSEC or other security mechanisms to ensure 205 that the response is trustworthy. Resolving global names via local 206 multicast is a contentious issue, and this document does not discuss 207 it in detail, instead concentrating on the issue of resolving local 208 names using DNS packets sent to a multicast address. 210 A host which belongs to an organization or individual who has control 211 over some portion of the DNS namespace can be assigned a globally 212 unique name within that portion of the DNS namespace, for example, 213 "cheshire.apple.com." For those of us who have this luxury, this 214 works very well. However, the majority of home customers do not have 215 easy access to any portion of the global DNS namespace within which 216 they have the authority to create names as they wish. This leaves the 217 majority of home computers effectively anonymous for practical 218 purposes. 220 To remedy this problem, this document allows any computer user to 221 elect to give their computers link-local Multicast DNS host names of 222 the form: "single-dns-label.local." For example, a laptop computer 223 may answer to the name "cheshire.local." Any computer user is granted 224 the authority to name their computer this way, provided that the 225 chosen host name is not already in use on that link. Having named 226 their computer this way, the user has the authority to continue using 227 that name until such time as a name conflict occurs on the link which 228 is not resolved in the user's favour. If this happens, the computer 229 (or its human user) SHOULD cease using the name, and may choose to 230 attempt to allocate a new unique name for use on that link. These 231 conflicts are expected to be relatively rare for people who choose 232 reasonably imaginative names, but it is still important to have a 233 mechanism in place to handle them when they happen. 235 The point made in the previous paragraph is very important and bears 236 repeating. It is easy for those of us in the IETF community who run 237 our own name servers at home to forget that the majority of computer 238 users do not run their own name server and have no easy way to create 239 their own host names. When these users wish to transfer files between 240 two laptop computers, they are frequently reduced to typing in 241 dotted-decimal IP addresses because they simply have no other way for 242 one host to refer to the other by name. This is a sorry state of 243 affairs. What is worse, most users don't even bother trying to use 244 dotted-decimal IP addresses. Most users still move data between 245 machines by copying it onto a floppy disk or similar removable media. 247 In a world of gigabit Ethernet and ubiquitous wireless networking it 248 is a sad indictment of the networking community that the preferred 249 communication medium for most computer users is still the floppy 250 disk. 252 Allowing ad-hoc allocation of single-label names in a single flat 253 ".local." namespace may seem to invite chaos. However, operational 254 experience with AppleTalk NBP names [NBP], which on any given link 255 are also effectively single-label names in a flat namespace, shows 256 that in practice name collisions happen extremely rarely and are not 257 a problem. Groups of computer users from disparate organizations 258 bring Macintosh laptop computers to events such as IETF Meetings, the 259 Mac Hack conference, the Apple World Wide Developer Conference, etc., 260 and complaints at these events about users suffering conflicts and 261 being forced to rename their machines have never been an issue. 263 Enforcing uniqueness of host names (i.e. the names of DNS address 264 records mapping names to IP addresses) is probably desirable in the 265 common case, but this document does not mandate that. It is 266 permissible for a collection of coordinated hosts to agree to 267 maintain multiple DNS address records with the same name, possibly 268 for load balancing or fault-tolerance reasons. This document does not 269 take a position on whether that is sensible. It is important that 270 both modes of operation are supported. The Multicast DNS protocol 271 allows hosts to verify and maintain unique names for resource records 272 where that behavior is desired, and it also allows hosts to maintain 273 multiple resource records with a single shared name where that 274 behavior is desired. This consideration applies to all resource 275 records, not just address records (host names). In summary: It is 276 required that the protocol have the ability to detect and handle name 277 conflicts, but it is not required that this ability be used for every 278 record. 280 3.1 Governing Standards Body 282 Note that this use of the ".local." suffix falls under IETF 283 jurisdiction, not ICANN jurisdiction. DNS is an IETF network 284 protocol, governed by protocol rules defined by the IETF. These IETF 285 protocol rules dictate character set, maximum name length, packet 286 format, etc. ICANN determines additional rules that apply when the 287 IETF's DNS protocol is used on the public Internet. In contrast, 288 private uses of the DNS protocol on isolated private networks are not 289 governed by ICANN. Since this proposed change is a change to the core 290 DNS protocol rules, it affects everyone, not just those machines 291 using the ICANN-governed Internet. Hence this change falls into the 292 category of an IETF protocol rule, not an ICANN usage rule. 294 3.2 Private DNS Namespaces 296 Note also that the special treatment of names ending in ".local." has 297 been implemented in Macintosh computers since the days of Mac OS 9, 298 and continues today in Mac OS X. There are also implementations for 299 Linux and other platforms [dotlocal]. Operators setting up private 300 internal networks ("intranets") are advised that their lives may be 301 easier if they avoid using the suffix ".local." in names in their 302 private internal DNS server. Alternative possibilities include: 304 .intranet 305 .internal 306 .private 307 .corp 308 .home 310 Another alternative naming scheme, advocated by Professor D. J. 311 Bernstein, is to use a numerical suffix, such as ".6." [djbdl]. 313 3.3 Maximum Multicast DNS Name Length 315 RFC 1034 says: 317 "the total number of octets that represent a domain name (i.e., 318 the sum of all label octets and label lengths) is limited to 255." 320 This text implies that the final root label at the end of every name 321 is included in this count (a name can't be represented without it), 322 but the text does not explicitly state that. Implementations of 323 Multicast DNS MUST include the label length byte of the final root 324 label at the end of every name when enforcing the rule that no name 325 may be longer than 255 bytes. For example, the length of the name 326 "apple.com." is considered to be 11, which is the number of bytes it 327 takes to represent that name in a packet without using name 328 compression: 330 ------------------------------------------------------ 331 | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 | 332 ------------------------------------------------------ 334 4. Source Address Check 336 All Multicast DNS responses (including responses sent via unicast) 337 SHOULD be sent with IP TTL set to 255. This is recommended to provide 338 backwards-compatibility with older Multicast DNS clients that check 339 the IP TTL on reception to determine whether the packet originated 340 on the local link. These older clients discard all packets with TTLs 341 other than 255. 343 A host sending Multicast DNS queries to a link-local destination 344 address (including the 224.0.0.251 link-local multicast address) 345 MUST only accept responses to that query that originate from the 346 local link, and silently discard any other response packets. Without 347 this check, it could be possible for remote rogue hosts to send 348 spoof answer packets (perhaps unicast to the victim host) which the 349 receiving machine could misinterpret as having originated on the 350 local link. 352 The test for whether a response originated on the local link 353 is done in two ways: 355 * All responses sent to the link-local multicast address 224.0.0.251 356 are necessarily deemed to have originated on the local link, 357 regardless of source IP address. This is essential to allow devices 358 to work correctly and reliably in unusual configurations, such as 359 multiple logical IP subnets overlayed on a single link, or in cases 360 of severe misconfiguration, where devices are physically connected 361 to the same link, but are currently misconfigured with completely 362 unrelated IP addresses and subnet masks. 364 * For responses sent to a unicast destination address, the source IP 365 address in the packet is checked to see if it is an address on a 366 local subnet. An address is determined to be on a local subnet if, 367 for (one of) the address(es) configured on the interface receiving 368 the packet, (I & M) == (P & M), where I and M are the interface 369 address and subnet mask respectively, P is the source IP address 370 from the packet, '&' represents the bitwise logical 'and' 371 operation, and '==' represents a bitwise equality test. 373 Since queriers will ignore responses apparently originating outside 374 the local subnet, responders SHOULD avoid generating responses that 375 it can reasonably predict will be ignored. This applies particularly 376 in the case of overlayed subnets. If a responder receives a query 377 addressed to the link-local multicast address 224.0.0.251, from a 378 source address not apparently on the same subnet as the responder, 379 then even if the query indicates that a unicast response is preferred 380 (see Section 6.5, "Questions Requesting Unicast Responses"), the 381 responder SHOULD elect to respond by multicast anyway, since it can 382 reasonably predict that a unicast response with an apparently 383 non-local source address will probably be ignored. 385 5. Reverse Address Mapping 387 Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also 388 defined to be link-local. 390 Any DNS query for a name ending with "254.169.in-addr.arpa." MUST 391 be sent to the mDNS multicast address 224.0.0.251. Since names under 392 this domain correspond to IPv4 link-local addresses, it is logical 393 that the local link is the best place to find information pertaining 394 to those names. As an optimization, these queries MAY be first 395 unicast directly to the address in question, but if this query is not 396 answered, the query MUST also be sent via multicast, to accommodate 397 the case where the machine in question is not answering for itself 398 (for example, because it is currently sleeping). 400 Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa." 401 MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB, 402 with or without an optional initial query unicast directly to the 403 address in question. 405 6. Querying 407 There are three kinds of Multicast DNS Queries, one-shot queries of 408 the kind made by today's conventional DNS clients, one-shot queries 409 accumulating multiple responses made by multicast-aware DNS clients, 410 and continuous ongoing Multicast DNS Queries used by IP network 411 browser software. 413 A Multicast DNS Responder that is offering records that are intended 414 to be unique on the local link MUST also implement a Multicast DNS 415 Querier so that it can first verify the uniqueness of those records 416 before it begins answering queries for them. 418 6.1 One-Shot Queries 420 An unsophisticated DNS client may simply send its DNS queries 421 blindly to the 224.0.0.251 multicast address, without necessarily 422 even being aware what a multicast address is. 424 Such an unsophisticated DNS client may not get ideal behavior. Such 425 a client may simply take the first response it receives and fail to 426 wait to see if there are more, but in many instances this may not be 427 a serious problem. If a user types "http://cheshire.local." into 428 their Web browser and gets to see the page they were hoping for, 429 then the protocol has met the user's needs in this case. 431 6.2 One-Shot Queries, Accumulating Multiple Responses 433 A more sophisticated DNS client should understand that Multicast DNS 434 is not exactly the same as unicast DNS, and should modify its 435 behavior in some simple ways. 437 As described above, there are some cases, such as looking up the 438 address associated with a unique host name, where a single response 439 is sufficient, and moreover may be all that is expected. However, 440 there are other DNS queries where more than one response is 441 possible, and for these queries a more sophisticated Multicast DNS 442 client should include the ability to wait for an appropriate period 443 of time to collect multiple responses. 445 A naive DNS client retransmits its query only so long as it has 446 received no response. A more sophisticated Multicast DNS client is 447 aware that having received one response is not necessarily an 448 indication that it might not receive others, and has the ability to 449 retransmit its query an appropriate number of times at appropriate 450 intervals until it is satisfied with the collection of responses it 451 has gathered. 453 A more sophisticated Multicast DNS client that is retransmitting 454 a query for which it has already received some responses, MUST 455 implement Known Answer Suppression, as described below in Section 456 7.1. This indicates to responders who have already replied that their 457 responses have been received, and they don't need to send them again 458 in response to this repeated query. In addition, the interval between 459 the first two queries SHOULD be one second, and the intervals between 460 subsequent queries SHOULD double. 462 6.3 Continuous Querying 464 In One-Shot Queries, with either a single or multiple responses, 465 the underlying assumption is that the transaction begins when the 466 application issues a query, and ends when all the desired responses 467 have been received. There is another type of operation which is more 468 akin to continuous monitoring. 470 Macintosh users are accustomed to opening the "Chooser" window, 471 selecting a desired printer, and then closing the Chooser window. 472 However, when the desired printer does not appear in the list, the 473 user will typically leave the "Chooser" window open while they go and 474 check to verify that the printer is plugged in, powered on, connected 475 to the Ethernet, etc. While the user jiggles the wires, hits the 476 Ethernet hub, and so forth, they keep an eye on the Chooser window, 477 and when the printer name appears, they know they have fixed whatever 478 the problem was. This can be a useful and intuitive troubleshooting 479 technique, but a user who goes home for the weekend leaving the 480 Chooser window open places a non-trivial burden on the network. 482 With continuous querying, multiple queries are sent over a long 483 period of time, until the user terminates the operation. It is 484 important that an IP network browser window displaying live 485 information from the network using Multicast DNS, if left running 486 for an extended period of time, should generate significantly less 487 multicast traffic on the network than the old AppleTalk Chooser. 488 Therefore, the interval between the first two queries SHOULD be one 489 second, the intervals between subsequent queries SHOULD double, and 490 the querier MUST implement Known Answer Suppression, as described 491 below in Section 7.1. When the interval between queries reaches or 492 exceeds 60 minutes, a querier MAY cap the interval to a maximum of 60 493 minutes, and perform subsequent queries at a steady-state rate of one 494 query per hour. 496 When a Multicast DNS Querier receives an answer, the answer contains 497 a TTL value that indicates for how many seconds this answer is valid. 498 After this interval has passed, the answer will no longer be valid 499 and SHOULD be deleted from the cache. Before this time is reached, a 500 Multicast DNS Querier with an ongoing interest in that record SHOULD 501 re-issue its query to determine whether the record is still valid, 502 and if so update its expiry time. 504 To perform this cache maintenance, a Multicast DNS Querier should 505 plan to re-query for records after at least 50% of the record 506 lifetime has elapsed. This document recommends the following 507 specific strategy: 509 The Querier should plan to issue a query at 80% of the record 510 lifetime, and then if no answer is received, at 85%, 90% and 95%. If 511 an answer is received, then the remaining TTL is reset to the value 512 given in the answer, and this process repeats for as long as the 513 Multicast DNS Querier has an ongoing interest in the record. If after 514 four queries no answer is received, the record is deleted when it 515 reaches 100% of its lifetime. 517 To avoid the case where multiple Multicast DNS Queriers on a network 518 all issue their queries simultaneously, a random variation of 2% of 519 the record TTL should be added, so that queries are scheduled to be 520 performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL. 522 6.4 Multiple Questions per Query 524 Multicast DNS allows a querier to place multiple questions in the 525 Question Section of a single Multicast DNS query packet. 527 The semantics of a Multicast DNS query packet containing multiple 528 questions is identical to a series of individual DNS query packets 529 containing one question each. Combining multiple questions into a 530 single packet is purely an efficiency optimization, and has no other 531 semantic significance. 533 A useful technique for adaptively combining multiple questions into a 534 single query is to use a Nagle-style algorithm: When a client issues 535 its first question, a Query packet is immediately built and sent, 536 without delay. If the client then continues issuing a rapid series of 537 questions they are held until either the first query receives at 538 least one answer, or 100ms has passed, or there are enough questions 539 to fill the Question Section of a Multicast DNS query packet. At this 540 time, all the held questions are placed into a Multicast DNS query 541 packet and sent. 543 6.5 Questions Requesting Unicast Responses 545 Sending Multicast DNS responses via multicast has the benefit that 546 all the other hosts on the network get to see those responses, and 547 can keep their caches up to date, and detect conflicting responses. 549 However, there are situations where all the other hosts on the 550 network don't need to see every response. One example is a laptop 551 computer waking from sleep. At that instant it is a brand new 552 participant on a new network. Its Multicast DNS cache is empty, and 553 it has no knowledge of its surroundings. It may have a significant 554 number of queries that it wants answered right away to discover 555 information about its new surroundings and present that information 556 to the user. As a new participant on the network, it has no idea 557 whether the exact same questions may have been asked and answered 558 just seconds ago. In this case, trigging a large sudden flood of 559 multicast responses may impose an unreasonable burden on the network. 560 To avoid this, the Multicast DNS Querier SHOULD set the top bit in 561 the class field of its DNS question(s), to indicate that it is 562 willing to accept unicast responses instead of the usual multicast 563 responses. These questions requesting unicast responses are referred 564 to as "QU" questions, to distinguish them from the more usual 565 questions requesting multicast responses ("QM" questions). 567 When retransmitting a question more than once, the 'unicast response' 568 bit SHOULD be set only for the first question of the series. After 569 the first question has received its responses, the querier should 570 have a large known-answer list (see "Known Answer Suppression" below) 571 so that subsequent queries should elicit few, if any, further 572 responses. Reverting to multicast responses as soon as possible is 573 important because of the benefits that multicast responses provide 574 (see "Benefits of Multicast Responses" below). 576 When receiving a question with the 'unicast response' bit set, a 577 responder SHOULD usually respond with a unicast packet directed back 578 to the querier. If the responder has not multicast that record 579 recently (within one quarter of its TTL), then the responder SHOULD 580 instead multicast the response so as to keep all the peer caches up 581 to date, and to permit passive conflict detection. 583 Unicast replies are subject to all the same packet generation rules 584 as multicast replies, including the cache flush bit (see Section 585 11.3, "Announcements to Flush Outdated Cache Entries") and randomized 586 delays to reduce network collisions (see Section 8, "Responding"). 588 6.6 Suppressing Initial Query 590 If a query is issued for which there already exist one or more 591 records in the local cache, and those record(s) were received with 592 the cache flush bit set (see Section 11.3, "Announcements to Flush 593 Outdated Cache Entries"), indicating that they form a unique RRSet, 594 then the host SHOULD suppress its initial "QU" query, and proceed to 595 issue a "QM" query. To avoid the situation where a group of hosts 596 are synchronized by some external event and all perform the same 597 query simultaneously, a host suppressing its initial "QU" query 598 SHOULD impose a random delay from 500-1000ms before transmitting its 599 first "QM" query for this question. This means that when the first 600 host (selected randomly by this algorithm) transmits its "QM" query, 601 all the other hosts that were about to transmit the same query can 602 suppress their superfluous query, as described in "Duplicate 603 Question Suppression" below. 605 7. Duplicate Suppression 607 A variety of techniques are used to reduce the amount of redundant 608 traffic on the network. 610 7.1 Known Answer Suppression 612 When a Multicast DNS Querier sends a query to which it already knows 613 some answers, it populates the Answer Section of the DNS message with 614 those answers. 616 A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if 617 the answer it would give is already included in the Answer Section 618 with an RR TTL at least half the correct value. If the RR TTL of the 619 answer as given in the Answer Section is less than half of the true 620 RR TTL as known by the Multicast DNS Responder, the responder MUST 621 send an answer so as to update the Querier's cache before the record 622 becomes in danger of expiration. 624 Because a Multicast DNS Responder will respond if the remaining TTL 625 given in the known answer list is less than half the true TTL, it is 626 superfluous for the Querier to include such records in the known 627 answer list. Therefore a Multicast DNS Querier SHOULD NOT include 628 records in the known answer list whose remaining TTL is less than 629 half their original TTL. Doing so would simply consume space in the 630 packet without achieving the goal of suppressing responses, and would 631 therefore be a pointless waste of network bandwidth. 633 A Multicast DNS Querier MUST NOT cache resource records observed in 634 the Known Answer Section of other Multicast DNS Queries. The Answer 635 Section of Multicast DNS Queries is not authoritative. By placing 636 information in the Answer Section of a Multicast DNS Query the 637 querier is stating that it *believes* the information to be true. 638 It is not asserting that the information *is* true. Some of those 639 records may have come from other hosts that are no longer on the 640 network. Propagating that stale information to other Multicast DNS 641 Queriers on the network would not be helpful. 643 7.2 Multi-Packet Known Answer Suppression 645 Sometimes a Multicast DNS Querier will already have too many answers 646 to fit in the Known Answer Section of its query packets. In this 647 case, it should issue a Multicast DNS Query containing a question and 648 as many Known Answer records as will fit. It MUST then set the TC 649 (Truncated) bit in the header before sending the Query. It MUST then 650 immediately follow the packet with another query packet containing no 651 questions, and as many more Known Answer records as will fit. If 652 there are still too many records remaining to fit in the packet, it 653 again sets the TC bit and continues until all the Known Answer 654 records have been sent. 656 A Multicast DNS Responder seeing a Multicast DNS Query with the TC 657 bit set defers its response for a time period randomly selected in 658 the interval 400-500ms. This gives the Multicast DNS Querier time to 659 send additional Known Answer packets before the Responder responds. 660 If the Responder sees any of its answers listed in the Known Answer 661 lists of subsequent packets from the querying host, it SHOULD delete 662 that answer from the list of answers it is planning to give, provided 663 that no other host on the network is also waiting to receive the same 664 answer record. 666 Previous versions of this draft specified a delay of 20-120ms before 667 answering queries with multi-packet Known Answer lists. However, 668 operational experience showed that, while this works well on 669 Ethernet, on very busy 802.11 networks, it is not uncommon to observe 670 consecutively sent packets arriving separated by as much as 671 200-400ms. 673 7.3 Duplicate Question Suppression 675 If a host is planning to send a query, and it sees another host on 676 the network send a query containing the same question, and the Known 677 Answer Section of that query does not contain any records which this 678 host would not also put in its own Known Answer Section, then this 679 host should treat its own query as having been sent. When multiple 680 clients on the network are querying for the same resource records, 681 there is no need for them to all be repeatedly asking the same 682 question. 684 7.4 Duplicate Answer Suppression 686 If a host is planning to send an answer, and it sees another host on 687 the network send a response packet containing the same answer record, 688 and the TTL in that record is not less than the TTL this host would 689 have given, then this host should treat its own answer as having been 690 sent. When multiple responders on the network have the same data, 691 there is no need for all of them to respond. 693 This feature is particularly useful when multiple Sleep Proxy Servers 694 are deployed (see Section 16, "Multicast DNS and Power Management"). 695 In the future it is possible that every general-purpose OS (Mac, 696 Windows, Linux, etc.) will implement Sleep Proxy Service as a matter 697 of course. In this case there could be a large number of Sleep Proxy 698 Servers on any given network, which is good for reliability and 699 fault-tolerance, but would be bad for the network if every Sleep 700 Proxy Server were to answer every query. 702 8. Responding 704 When a Multicast DNS Responder constructs and sends a Multicast DNS 705 response packet, the Answer Section of that packet must contain only 706 records for which that Responder is explicitly authoritative. These 707 answers may be generated because the record answers a question 708 received in a Multicast DNS query packet, or at certain other times 709 that the responder determines than an unsolicited announcement is 710 warranted. A Multicast DNS Responder MUST NOT place records from its 711 cache, which have been learned from other responders on the network, 712 in the Answer Section of outgoing response packets. Only an 713 authoritative source for a given record is allowed to issue responses 714 containing that record. 716 The determination of whether a given record answers a given question 717 is done using the standard DNS rules: The record name must match the 718 question name, the record rrtype must match the question qtype 719 (unless the qtype is "ANY"), and the record rrclass must match the 720 question qclass (unless the qclass is "ANY"). 722 A Multicast DNS Responder MUST only respond when it has a positive 723 non-null response to send. Error responses must never be sent. The 724 non-existence of any name in a Multicast DNS Domain is ascertained by 725 the failure of any machine to respond to the Multicast DNS query, not 726 by NXDOMAIN errors. 728 Multicast DNS Responses MUST NOT contain any questions in the 729 Question Section. Any questions in the Question Section of a received 730 Multicast DNS Response MUST be silently ignored. Multicast DNS 731 Queriers receiving Multicast DNS Responses do not care what question 732 elicited the response; they care only that the information in the 733 response is true and accurate. 735 A Multicast DNS Responder on Ethernet [IEEE802] and similar shared 736 multiple access networks SHOULD have the capability of delaying its 737 responses by up to 500ms, as determined by the rules described below. 738 If multiple Multicast DNS Responders were all to respond immediately 739 to a particular query, a collision would be virtually guaranteed. By 740 imposing a small random delay, the number of collisions is 741 dramatically reduced. On a full-sized Ethernet using the maximum 742 cable lengths allowed and the maximum number of repeaters allowed, an 743 Ethernet frame is vulnerable to collisions during the transmission of 744 its first 256 bits. On 10Mb/s Ethernet, this equates to a vulnerable 745 time window of 25.6us. On higher-speed variants of Ethernet, the 746 vulnerable time window is shorter. 748 In the case where a Multicast DNS Responder has good reason to 749 believe that it will be the only responder on the link with a 750 positive non-null response, it SHOULD NOT impose any random delay 751 before responding, and SHOULD normally generate its response within 752 at most 10ms. In particular, this applies to responding to probe 753 queries. Since receiving a probe query gives a clear indication that 754 some other Responder is planning to start using this name in the very 755 near future, answering such probe queries to defend a unique record 756 is a high priority and needs to be done immediately, without delay. A 757 probe query can be distinguished from a normal query by the fact that 758 a probe query contains a proposed record in the Authority Section 759 which answers the question in the Question Section (for more details, 760 see Section 9.1, "Probing"). 762 To generate immediate responses safely, it MUST have previously 763 verified that the requested name, rrtype and rrclass in the DNS query 764 are unique on this link. Responding immediately without delay is 765 appropriate for things like looking up the address record for a 766 particular host name, when the host name has been previously verified 767 unique. Responding immediately without delay is *not* appropriate for 768 things like looking up PTR records used for DNS Service Discovery 769 [DNS-SD], where a large number of responses may be anticipated. 771 In any case where there may be multiple responses, such as queries 772 where the answer is a member of a shared resource record set, each 773 responder SHOULD delay its response by a random amount of time 774 selected with uniform random distribution in the range 20-120ms. 776 In the case where the query has the TC (truncated) bit set, 777 indicating that subsequent known answer packets will follow, 778 responders SHOULD delay their responses by a random amount of time 779 selected with uniform random distribution in the range 400-500ms, 780 to allow enough time for all the known answer packets to arrive. 782 Except when a unicast reply has been explicitly requested via the 783 "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port 784 5353 (the well-known port assigned to mDNS) on the 224.0.0.251 785 multicast address (or its IPv6 equivalent FF02::FB). Operating in a 786 Zeroconf environment requires constant vigilance. Just because a name 787 has been previously verified unique does not mean it will continue to 788 be so indefinitely. By allowing all Multicast DNS Responders to 789 constantly monitor their peers' responses, conflicts arising out of 790 network topology changes can be promptly detected and resolved. 792 Sending all responses by multicast also facilitates opportunistic 793 caching by other hosts on the network. 795 To protect the network against excessive packet flooding due to 796 software bugs or malicious attack, a Multicast DNS Responder MUST NOT 797 multicast a given record on a given interface if it has previously 798 multicast that record on that interface within the last second. A 799 legitimate client on the network should have seen the previous 800 transmission and cached it. A client that did not receive and cache 801 the previous transmission will retry its request and receive a 802 subsequent response. Under no circumstances is there any legitimate 803 reason for a Multicast DNS Responder to multicast a given record more 804 than once per second on any given interface. 806 8.1 Legacy Unicast Responses 808 If the source UDP port in a received Multicast DNS Query is not port 809 5353, this indicates that the client originating the query is a 810 simple client that does not fully implement all of Multicast DNS. In 811 this case, the Multicast DNS Responder MUST send a UDP response 812 directly back to the client, via unicast, to the query packet's 813 source IP address and port. This unicast response MUST be a 814 conventional unicast response as would be generated by a conventional 815 unicast DNS server; for example, it MUST repeat the query ID and the 816 question given in the query packet. 818 The resource record TTL given in a legacy unicast response SHOULD NOT 819 be greater than ten seconds, even if the true TTL of the Multicast 820 DNS resource record is higher. This is because Multicast DNS 821 Responders that fully participate in the protocol use the cache 822 coherency mechanisms described in Section 13 to update and invalidate 823 stale data. Were unicast responses sent to legacy clients to use the 824 same high TTLs, these legacy clients, which do not implement these 825 cache coherency mechanisms, could retain stale cached resource record 826 data long after it is no longer valid. 828 Having sent this unicast response, if the Responder has not sent this 829 record in any multicast response recently, it SHOULD schedule the 830 record to be sent via multicast as well, to facilitate passive 831 conflict detection. "Recently" in this context means "if the time 832 since the record was last sent via multicast is less than one quarter 833 of the record's TTL". 835 8.2 Multi-Question Queries 837 Multicast DNS Responders MUST correctly handle DNS query packets 838 containing more than one question, by answering any or all of the 839 questions to which they have answers. Any (non-defensive) answers 840 generated in response to query packets containing more than one 841 question SHOULD be randomly delayed in the range 20-120ms, or 842 400-500ms if the TC (truncated) bit is set, as described above. 843 (Answers defending a name, in response to a probe for that name, 844 are not subject to this delay rule and are still sent immediately.) 846 8.3 Response Aggregation 848 When possible, a responder SHOULD, for the sake of network 849 efficiency, aggregate as many responses as possible into a single 850 Multicast DNS response packet. For example, when a responder has 851 several responses it plans to send, each delayed by a different 852 interval, then earlier responses SHOULD be delayed by up to an 853 additional 500ms if that will permit them to be aggregated with 854 other responses scheduled to go out a little later. 856 9. Probing and Announcing on Startup 858 Typically a Multicast DNS Responder should have, at the very least, 859 address records for all of its active interfaces. Creating and 860 advertising an HINFO record on each interface as well can be useful 861 to network administrators. 863 Whenever a Multicast DNS Responder starts up, wakes up from sleep, 864 receives an indication of an Ethernet "Link Change" event, or has any 865 other reason to believe that its network connectivity may have 866 changed in some relevant way, it MUST perform the two startup steps 867 below. 869 9.1 Probing 871 The first startup step is that for all those resource records that a 872 Multicast DNS Responder desires to be unique on the local link, it 873 MUST send a Multicast DNS Query asking for those resource records, to 874 see if any of them are already in use. The primary example of this is 875 its address record which maps its unique host name to its unique IP 876 address. All Probe Queries SHOULD be done using the desired resource 877 record name and query type T_ANY (255), to elicit answers for all 878 types of records with that name. This allows a single question to be 879 used in place of several questions, which is more efficient on the 880 network. It also allows a host to verify exclusive ownership of a 881 name, which is desirable in most cases. It would be confusing, for 882 example, if one host owned the "A" record for "myhost.local.", but a 883 different host owned the HINFO record for that name. 885 The ability to place more than one question in a Multicast DNS Query 886 is useful here, because it can allow a host to use a single packet 887 for all of its resource records instead of needing a separate packet 888 for each. For example, a host can simultaneously probe for uniqueness 889 of its "A" record and all its SRV records [DNS-SD] in the same query 890 packet. 892 When ready to send its mDNS probe packet(s) the host should first 893 wait for a short random delay time, uniformly distributed in the 894 range 0-250ms. This random delay is to guard against the case where a 895 group of devices are powered on simultaneously, or a group of devices 896 are connected to an Ethernet hub which is then powered on, or some 897 other external event happens that might cause a group of hosts to all 898 send synchronized probes. 900 250ms after the first query the host should send a second, then 901 250ms after that a third. If, by 250ms after the third probe, no 902 conflicting Multicast DNS responses have been received, the host may 903 move to the next step, announcing. (Note that this is the one 904 exception from the normal rule that there should be at least one 905 second between repetitions of the same question, and the interval 906 between subsequent repetitions should double.) 908 If any conflicting Multicast DNS responses are received, then the 909 probing host MUST defer to the existing host, and MUST choose new 910 names for some or all of its resource records as appropriate, to 911 avoid conflict with pre-existing hosts on the network. In the case 912 of a host probing using query type T_ANY as recommended above, any 913 answer containing a record with that name, of any type, MUST be 914 considered a conflicting response and handled accordingly. 916 If fifteen failures occur within any ten-second period, then the host 917 MUST wait at least five seconds before each successive additional 918 probe attempt. This is to help ensure that in the event of software 919 bugs or other unanticipated problems, errant hosts do not flood the 920 network with a continuous stream of multicast traffic. For very 921 simple devices, a valid way to comply with this requirement is to 922 always wait five seconds after any failed probe attempt. 924 If a responder knows by other means, with absolute certainty, that 925 its unique resource record set name, rrtype and rrclass cannot 926 already be in use by any other responder on the network, then it MAY 927 skip the probing step for that resource record set. For example, when 928 creating the reverse address mapping PTR records, the host can 929 reasonably assume that no other host will be trying to create those 930 same PTR records, since that would imply that the two hosts were 931 trying to use the same IP address, and if that were the case, the two 932 hosts would be suffering communication problems beyond the scope of 933 what Multicast DNS is designed to solve. 935 9.2 Simultaneous Probe Tie-Breaking 937 The astute reader will observe that there is a race condition 938 inherent in the previous description. If two hosts are probing for 939 the same name simultaneously, neither will receive any response to 940 the probe, and the hosts could incorrectly conclude that they may 941 both proceed to use the name. To break this symmetry, each host 942 populates the Authority Section of its queries with records giving 943 the rdata that it would be proposing to use, should its probing be 944 successful. The Authority Section is being used here in a way 945 analogous to the Update Section of a DNS Update packet [RFC 2136]. 947 When a host that is probing for a record sees another host issue a 948 query for the same record, it consults the Authority Section of that 949 query. If it finds any resource record there which answers the query, 950 then it compares the data of that resource record with its own 951 tentative data. The lexicographically later data wins. This means 952 that if the host finds that its own data is lexicographically later, 953 it simply ignores the other host's probe. If the host finds that its 954 own data is lexicographically earlier, then it treats this exactly 955 as if it had received a positive answer to its query, and concludes 956 that it may not use the desired name. 958 The determination of 'lexicographically later' is performed by first 959 comparing the record class, then the record type, then raw comparison 960 of the binary content of the rdata without regard for meaning or 961 structure. If the record classes differ, then the numerically greater 962 class is considered 'lexicographically later'. Otherwise, if the 963 record types differ, then the numerically greater type is considered 964 'lexicographically later'. If the rrtype and rrclass both match then 965 the rdata is compared. 967 In the case of resource records containing rdata that is subject to 968 name compression, the names MUST be uncompressed before comparison. 969 (The details of how a particular name is compressed is an artifact of 970 how and where the record is written into the DNS message; it is not 971 an intrinsic property of the resource record itself.) 973 The bytes of the raw uncompressed rdata are compared in turn, 974 interpreting the bytes as eight-bit UNSIGNED values, until a byte 975 is found whose value is greater than that of its counterpart (in 976 which case the rdata whose byte has the greater value is deemed 977 lexicographically later) or one of the resource records runs out 978 of rdata (in which case the resource record which still has 979 remaining data first is deemed lexicographically later). 981 The following is an example of a conflict: 983 cheshire.local. A 169.254.99.200 984 cheshire.local. A 169.254.200.50 986 In this case 169.254.200.50 is lexicographically later (the third 987 byte, with value 200, is greater than its counterpart with value 99), 988 so it is deemed the winner. 990 Note that it is vital that the bytes are interpreted as UNSIGNED 991 values, or the wrong outcome may result. In the example above, if 992 the byte with value 200 had been incorrectly interpreted as a 993 signed value then it would be interpreted as value -56, and the 994 wrong address record would be deemed the winner. 996 9.3 Announcing 998 The second startup step is that the Multicast DNS Responder MUST send 999 a gratuitous Multicast DNS Response containing, in the Answer 1000 Section, all of its resource records (both shared records, and unique 1001 records that have completed the probing step). If there are too many 1002 resource records to fit in a single packet, multiple packets should 1003 be used. 1005 In the case of shared records (e.g. the PTR records used by DNS 1006 Service Discovery [DNS-SD]), the records are simply placed as-is 1007 into the Answer Section of the DNS Response. 1009 In the case of records that have been verified to be unique in the 1010 previous step, they are placed into the Answer Section of the DNS 1011 Response with the most significant bit of the rrclass set to one. 1012 The most significant bit of the rrclass for a record in the Answer 1013 Section of a response packet is the mDNS "cache flush" bit and is 1014 discussed in more detail below in Section 11.3 "Announcements to 1015 Flush Outdated Cache Entries". 1017 The Multicast DNS Responder MUST send at least two gratuitous 1018 responses, one second apart. A Responder MAY send up to ten 1019 gratuitous Responses, provided that the interval between gratuitous 1020 responses doubles with every response sent. 1022 A Multicast DNS Responder SHOULD NOT continue sending gratuitous 1023 Responses for longer than the TTL of the record. The purpose of 1024 announcing new records via gratuitous Responses is to ensure that 1025 peer caches are up to date. After a time interval equal to the TTL of 1026 the record has passed, it is very likely that old stale copies of 1027 that record in peer caches will have expired naturally, so subsequent 1028 announcements serve little purpose. 1030 A Multicast DNS Responder MUST NOT send announcements in the absence 1031 of information that its network connectivity may have changed in some 1032 relevant way. In particular, a Multicast DNS Responder MUST NOT send 1033 regular periodic announcements as a matter of course. 1035 Whenever a Multicast DNS Responder receives any Multicast DNS 1036 response (gratuitous or otherwise) containing a conflicting resource 1037 record, the conflict MUST be resolved as described below in "Conflict 1038 Resolution". 1040 9.4 Updating 1042 At any time, if the rdata of any of a host's Multicast DNS records 1043 changes, the host MUST repeat the Announcing step described above to 1044 update neighboring caches. For example, if any of a host's IP 1045 addresses change, it MUST re-announce those address records. 1047 In the case of shared records, a host MUST send a 'goodbye' 1048 announcement with TTL zero (see Section 11.2 "Goodbye Packets") 1049 for the old rdata, to cause it to be deleted from peer caches, 1050 before announcing the new rdata. In the case of unique records, 1051 a host SHOULD omit the 'goodbye' announcement, since the cache 1052 flush bit on the newly announced records will cause old rdata 1053 to be flushed from peer caches anyway. 1055 A host may update the contents of any of its records at any time, 1056 though a host SHOULD NOT update records more frequently than ten 1057 times per minute. Frequent rapid updates impose a burden on the 1058 network. If a host has information to disseminate which changes more 1059 frequently than ten times per minute, then it may be more appropriate 1060 to design a protocol for that specific purpose. 1062 10. Conflict Resolution 1064 A conflict occurs when a Multicast DNS Responder has a unique record 1065 for which it is authoritative, and it receives, in the Answer Section 1066 of a Multicast DNS response another record with the same name, rrtype 1067 and rrclass, but inconsistent rdata. What may be considered 1068 inconsistent is context sensitive, except that resource records with 1069 identical rdata are never considered inconsistent, even if they 1070 originate from different hosts. This is to permit use of proxies and 1071 other fault-tolerance mechanisms that may cause more than one 1072 responder to be capable of issuing identical answers on the network. 1074 A common example of a resource record type that is intended to be 1075 unique, not shared between hosts, is the address record that maps a 1076 host's name to its IP address. Should a host witness another host 1077 announce an address record with the same name but a different IP 1078 address, then that is considered inconsistent, and that address 1079 record is considered to be in conflict. 1081 Whenever a Multicast DNS Responder receives any Multicast DNS 1082 response (gratuitous or otherwise) containing a conflicting resource 1083 record in the Answer Section, the Multicast DNS Responder MUST 1084 immediately reset its conflicted unique record to probing state, and 1085 go through the startup steps described above in Section 9. "Probing 1086 and Announcing on Startup". The protocol used in the Probing phase 1087 will determine a winner and a loser, and the loser MUST cease using 1088 the name, and reconfigure. 1090 It is very important that any host receiving a resource record that 1091 conflicts with one of its own MUST take action as described above. 1092 In the case of two hosts using the same host name, where one has been 1093 configured to require a unique host name and the other has not, the 1094 one that has not been configured to require a unique host name will 1095 not perceive any conflict, and will not take any action. By reverting 1096 to Probing state, the host that desires a unique host name will go 1097 through the necessary steps to ensure that a unique host is obtained. 1099 The recommended course of action after probing and failing is as 1100 follows: 1102 o Programmatically change the resource record name in an attempt to 1103 find a new name that is unique. This could be done by adding some 1104 further identifying information (e.g. the model name of the 1105 hardware) if it is not already present in the name, appending the 1106 digit "2" to the name, or incrementing a number at the end of the 1107 name if one is already present. 1109 o Probe again, and repeat until a unique name is found. 1111 o Record this newly chosen name in persistent storage so that the 1112 device will use the same name the next time it is power-cycled. 1114 o Display a message to the user or operator informing them of the 1115 name change. For example: 1117 The name "Bob's Music" is in use by another iTunes music 1118 server on the network. Your music has been renamed to 1119 "Bob's Music (G4 Cube)". If you want to change this name, 1120 use [describe appropriate menu item or preference dialog]. 1122 How the user or operator is informed depends on context. A desktop 1123 computer with a screen might put up a dialog box. A headless server 1124 in the closet may write a message to a log file, or use whatever 1125 mechanism (email, SNMP trap, etc.) it uses to inform the 1126 administrator of other error conditions. On the other hand a headless 1127 server in the closet may not inform the user at all -- if the user 1128 cares, they will notice the name has changed, and connect to the 1129 server in the usual way (e.g. via Web Browser) to configure a new 1130 name. 1132 The examples in this section focus on address records (i.e. host 1133 names), but the same considerations apply to all resource records 1134 where uniqueness (or maintenance of some other defined constraint) 1135 is desired. 1137 11. Resource Record TTL Values and Cache Coherency 1139 As a general rule, the recommended TTL value for Multicast DNS 1140 resource records with a host name as the resource record's name 1141 (e.g. A, AAAA, HINFO, etc.) or contained within the resource record's 1142 rdata (e.g. SRV, reverse mapping PTR record, etc.) is 120 seconds. 1144 The recommended TTL value for other Multicast DNS resource records 1145 is 75 minutes. 1147 A client with an active outstanding query will issue a query packet 1148 when one or more of the resource record(s) in its cache is (are) 80% 1149 of the way to expiry. If the TTL on those records is 75 minutes, 1150 this ongoing cache maintenance process yields a steady-state query 1151 rate of one query every 60 minutes. 1153 Any distributed cache needs a cache coherency protocol. If Multicast 1154 DNS resource records follow the recommendation and have a TTL of 75 1155 minutes, that means that stale data could persist in the system for 1156 a little over an hour. Making the default TTL significantly lower 1157 would reduce the lifetime of stale data, but would produce too much 1158 extra traffic on the network. Various techniques are available to 1159 minimize the impact of such stale data. 1161 11.1 Cooperating Multicast DNS Responders 1163 If a Multicast DNS Responder ("A") observes some other Multicast DNS 1164 Responder ("B") send a Multicast DNS Response packet containing a 1165 resource record with the same name, rrtype and rrclass as one of A's 1166 resource records, but different rdata, then: 1168 o If A's resource record is intended to be a shared resource record, 1169 then this is no conflict, and no action is required. 1171 o If A's resource record is intended to be a member of a unique 1172 resource record set owned solely by that responder, then this 1173 is a conflict and MUST be handled as described in Section 10 1174 "Conflict Resolution". 1176 If a Multicast DNS Responder ("A") observes some other Multicast DNS 1177 Responder ("B") send a Multicast DNS Response packet containing a 1178 resource record with the same name, rrtype and rrclass as one of A's 1179 resource records, and identical rdata, then: 1181 o If the TTL of B's resource record given in the packet is at least 1182 half the true TTL from A's point of view, then no action is 1183 required. 1185 o If the TTL of B's resource record given in the packet is less than 1186 half the true TTL from A's point of view, then A MUST mark its 1187 record to be announced via multicast. Clients receiving the record 1188 from B would use the TTL given by B, and hence may delete the 1189 record sooner than A expects. By sending its own multicast response 1190 correcting the TTL, A ensures that the record will be retained for 1191 the desired time. 1193 These rules allow multiple Multicast DNS Responders to offer the same 1194 data on the network (perhaps for fault tolerance reasons) without 1195 conflicting with each other. 1197 11.2 Goodbye Packets 1199 In the case where a host knows that certain resource record data is 1200 about to become invalid (for example when the host is undergoing a 1201 clean shutdown) the host SHOULD send a gratuitous announcement mDNS 1202 response packet, giving the same resource record name, rrtype, 1203 rrclass and rdata, but an RR TTL of zero. This has the effect of 1204 updating the TTL stored in neighboring hosts' cache entries to zero, 1205 causing that cache entry to be promptly deleted. 1207 Clients receiving a Multicast DNS Response with a TTL of zero SHOULD 1208 NOT immediately delete the record from the cache, but instead record 1209 a TTL of 1 and then delete the record one second later. In the case 1210 of multiple Multicast DNS Responders on the network described in 1211 Section 11.1 above, if one of the Responders shuts down and 1212 incorrectly sends goodbye packets for its records, it gives the other 1213 cooperating Responders one second to send out their own response to 1214 "rescue" the records before they expire and are deleted. 1216 Generally speaking, it is more important to send goodbye packets for 1217 shared records than unique records. A given shared record name (such 1218 as a PTR record used for DNS Service Discovery [DNS-SD]) by its 1219 nature often has many representatives from many different hosts, and 1220 tends to be the subject of long-lived ongoing queries. Those 1221 long-lived queries are often concerned not just about being informed 1222 when records appear, but also about being informed if those records 1223 vanish again. In contrast, a unique record set (such as an SRV 1224 record, or a host address record), by its nature, often has far fewer 1225 members than a shared record set, and is usually the subject of 1226 one-shot queries which simply retrieve the data and then cease 1227 querying once they have the answer they are seeking. Therefore, 1228 sending a goodbye packet for a unique record set is likely to offer 1229 less benefit, because it is likely at any given moment that no one 1230 has an active query running for that record set. One example where 1231 goodbye packets for SRV and address records are useful is when 1232 transferring control to a Sleep Proxy Server (see Section 16, 1233 "Multicast DNS and Power Management"). 1235 11.3 Announcements to Flush Outdated Cache Entries 1237 Whenever a host has a resource record with potentially new data (e.g. 1238 after rebooting, waking from sleep, connecting to a new network link, 1239 changing IP address, etc.), the host MUST send a series of gratuitous 1240 announcements to update cache entries in its neighbor hosts. In 1241 these gratuitous announcements, if the record is one that is intended 1242 to be unique, the host sets the most significant bit of the rrclass 1243 field of the resource record. This bit, the "cache flush" bit, tells 1244 neighboring hosts that this is not a shared record type. Instead of 1245 merging this new record additively into the cache in addition to any 1246 previous records with the same name, rrtype and rrclass, all old 1247 records with that name, type and class that were received more than 1248 one second ago are declared invalid, and marked to expire from the 1249 cache in one second. 1251 The semantics of the cache flush bit are as follows: Normally when a 1252 resource record appears in the Answer Section of the DNS Response, it 1253 means, "This is an assertion that this information is true." When a 1254 resource record appears in the Answer Section of the DNS Response 1255 with the "cache flush" bit set, it means, "This is an assertion that 1256 this information is the truth and the whole truth, and anything you 1257 may have heard more than a second ago regarding records of this 1258 name/rrtype/rrclass is no longer valid". 1260 To accommodate the case where the set of records from one host 1261 constituting a single unique RRSet is too large to fit in a single 1262 packet, only cache records that are more than one second old are 1263 flushed. This allows the announcing host to generate a quick burst of 1264 packets back-to-back on the wire containing all the members 1265 of the RRSet. When receiving records with the "cache flush" bit set, 1266 all records older than one second are marked to be deleted one second 1267 in the future. One second after the end of the little packet burst, 1268 any records not represented within that packet burst will then be 1269 expired from all peer caches. 1271 Any time a host sends a response packet containing some members of a 1272 unique RRSet, it SHOULD send the entire RRSet, preferably in a single 1273 packet, or if the entire RRSet will not fit in a single packet, in a 1274 quick burst of packets sent as close together as possible. The host 1275 SHOULD set the cache flush bit on all members of the unique RRSet. 1276 In the event that for some reason the host chooses not to send the 1277 entire unique RRSet in a single packet or a rapid packet burst, 1278 it MUST NOT set the cache flush bit on any of those records. 1280 The reason for waiting one second before deleting stale records from 1281 the cache is to accommodate bridged networks. For example, a host's 1282 address record announcement on a wireless interface may be bridged 1283 onto a wired Ethernet, and cause that same host's Ethernet address 1284 records to be flushed from peer caches. The one-second delay gives 1285 the host the chance to see its own announcement arrive on the wired 1286 Ethernet, and immediately re-announce its Ethernet interface's 1287 address records so that both sets remain valid and live in peer 1288 caches. 1290 These rules apply regardless of *why* the response packet is being 1291 generated. They apply to startup announcements as described in 1292 Section 9.3, and to responses generated as a result of receiving 1293 query packets. 1295 The "cache flush" bit is only set in records in the Answer Section of 1296 Multicast DNS responses sent to UDP port 5353. The "cache flush" bit 1297 MUST NOT be set in any resource records in a response packet sent in 1298 legacy unicast responses to UDP ports other than 5353. 1300 The "cache flush" bit MUST NOT be set in any resource records in the 1301 known-answer list of any query packet. 1303 The "cache flush" bit MUST NOT ever be set in any shared resource 1304 record. To do so would cause all the other shared versions of this 1305 resource record with different rdata from different Responders to be 1306 immediately deleted from all the caches on the network. 1308 The "cache flush" bit does apply to questions listed in the Question 1309 Section of a Multicast DNS packet. The top bit of the rrclass field 1310 in questions is used for an entirely different purpose (see Section 1311 6.5, "Questions Requesting Unicast Responses"). 1313 Note that the "cache flush" bit is NOT part of the resource record 1314 class. The "cache flush" bit is the most significant bit of the 1315 second 16-bit word of a resource record in the Answer Section of 1316 an mDNS packet (the field conventionally referred to as the rrclass 1317 field), and the actual resource record class is the least-significant 1318 fifteen bits of this field. There is no mDNS resource record class 1319 0x8001. The value 0x8001 in the rrclass field of a resource record in 1320 an mDNS response packet indicates a resource record with class 1, 1321 with the "cache flush" bit set. When receiving a resource record with 1322 the "cache flush" bit set, implementations should take care to mask 1323 off that bit before storing the resource record in memory. 1325 11.4 Cache Flush on Topology change 1327 If the hardware on a given host is able to indicate physical changes 1328 of connectivity, then when the hardware indicates such a change, the 1329 host should take this information into account in its mDNS cache 1330 management strategy. For example, a host may choose to immediately 1331 flush all cache records received on a particular interface when that 1332 cable is disconnected. Alternatively, a host may choose to adjust the 1333 remaining TTL on all those records to a few seconds so that if the 1334 cable is not reconnected quickly, those records will expire from the 1335 cache. 1337 Likewise, when a host reboots, or wakes from sleep, or undergoes some 1338 other similar discontinuous state change, the cache management 1339 strategy should take that information into account. 1341 11.5 Cache Flush on Failure Indication 1343 Sometimes a cache record can be determined to be stale when a client 1344 attempts to use the rdata it contains, and finds that rdata to be 1345 incorrect. 1347 For example, the rdata in an address record can be determined to be 1348 incorrect if attempts to contact that host fail, either because 1349 ARP/ND requests for that address go unanswered (for an address on a 1350 local subnet) or because a router returns an ICMP "Host Unreachable" 1351 error (for an address on a remote subnet). 1353 The rdata in an SRV record can be determined to be incorrect if 1354 attempts to communicate with the indicated service at the host and 1355 port number indicated are not successful. 1357 The rdata in a DNS-SD PTR record can be determined to be incorrect if 1358 attempts to look up the SRV record it references are not successful. 1360 In any such case, the software implementing the mDNS resource record 1361 cache should provide a mechanism so that clients detecting stale 1362 rdata can inform the cache. 1364 When the cache receives this hint that it should reconfirm some 1365 record, it MUST issue two or more queries for the resource record in 1366 question. If no response is received in a reasonable amount of time, 1367 then, even though its TTL may indicate that it is not yet due to 1368 expire, that record SHOULD be promptly flushed from the cache. 1370 The end result of this is that if a printer suffers a sudden power 1371 failure or other abrupt disconnection from the network, its name 1372 may continue to appear in DNS-SD browser lists displayed on users' 1373 screens. Eventually that entry will expire from the cache naturally, 1374 but if a user tries to access the printer before that happens, the 1375 failure to successfully contact the printer will trigger the more 1376 hasty demise of its cache entries. This is a sensible trade-off 1377 between good user-experience and good network efficiency. If we were 1378 to insist that printers should disappear from the printer list within 1379 30 seconds of becoming unavailable, for all failure modes, the only 1380 way to achieve this would be for the client to poll the printer at 1381 least every 30 seconds, or for the printer to announce its presence 1382 at least every 30 seconds, both of which would be an unreasonable 1383 burden on most networks. 1385 11.6 Passive Observation of Failures 1387 A host observes the multicast queries issued by the other hosts on 1388 the network. One of the major benefits of also sending responses 1389 using multicast is that it allows all hosts to see the responses (or 1390 lack thereof) to those queries. 1392 If a host sees queries, for which a record in its cache would be 1393 expected to be given as an answer in a multicast response, but no 1394 such answer is seen, then the host may take this as an indication 1395 that the record may no longer be valid. 1397 After seeing two or more of these queries, and seeing no multicast 1398 response containing the expected answer within a reasonable amount of 1399 time, then even though its TTL may indicate that it is not yet due to 1400 expire, that record MAY be flushed from the cache. The host SHOULD 1401 NOT perform its own queries to re-confirm that the record is truly 1402 gone. If every host on a large network were to do this, it would 1403 cause a lot of unnecessary multicast traffic. If host A sends 1404 multicast queries that remain unanswered, then there is no reason 1405 to suppose that host B or any other host is likely to be any more 1406 successful. 1408 The previous section, "Cache Flush on Failure Indication", describes 1409 a situation where a user trying to print discovers that the printer 1410 is no longer available. By implementing the passive observation 1411 described here, when one user fails to contact the printer, all 1412 hosts on the network observe that failure and update their caches 1413 accordingly. 1415 12. Special Characteristics of Multicast DNS Domains 1417 Unlike conventional DNS names, names that end in ".local.", 1418 "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local 1419 significance. Conventional DNS seeks to provide a single unified 1420 namespace, where a given DNS query yields the same answer no matter 1421 where on the planet it is performed or to which recursive DNS server 1422 the query is sent. (However, split views, firewalls, intranets and 1423 the like have somewhat interfered with this goal of DNS representing 1424 a single universal truth.) In contrast, each IP link has its own 1425 private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa." 1426 namespaces, and the answer to any query for a name within those 1427 domains depends on where that query is asked. 1429 Multicast DNS Domains are not delegated from their parent domain via 1430 use of NS records. There are no NS records anywhere in Multicast DNS 1431 Domains. Instead, all Multicast DNS Domains are delegated to the IP 1432 addresses 224.0.0.251 and FF02::FB by virtue of the individual 1433 organizations producing DNS client software deciding how to handle 1434 those names. It would be extremely valuable for the industry if this 1435 special handling were ratified and recorded by IANA, since otherwise 1436 the special handling provided by each vendor is likely to be 1437 inconsistent. 1439 The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The 1440 IPv6 name server for a Multicast DNS Domain is FF02::FB. These are 1441 multicast addresses; therefore they identify not a single host but a 1442 collection of hosts, working in cooperation to maintain some 1443 reasonable facsimile of a competently managed DNS zone. Conceptually 1444 a Multicast DNS Domain is a single DNS zone, however its server is 1445 implemented as a distributed process running on a cluster of loosely 1446 cooperating CPUs rather than as a single process running on a single 1447 CPU. 1449 No delegation is performed within Multicast DNS Domains. Because the 1450 cluster of loosely coordinated CPUs is cooperating to administer a 1451 single zone, delegation is neither necessary nor desirable. Just 1452 because a particular host on the network may answer queries for a 1453 particular record type with the name "example.local." does not imply 1454 anything about whether that host will answer for the name 1455 "child.example.local.", or indeed for other record types with the 1456 name "example.local." 1458 Multicast DNS Zones have no SOA record. A conventional DNS zone's 1459 SOA record contains information such as the email address of the zone 1460 administrator and the monotonically increasing serial number of the 1461 last zone modification. There is no single human administrator for 1462 any given Multicast DNS Zone, so there is no email address. Because 1463 the hosts managing any given Multicast DNS Zone are only loosely 1464 coordinated, there is no readily available monotonically increasing 1465 serial number to determine whether or not the zone contents have 1466 changed. A host holding part of the shared zone could crash or be 1467 disconnected from the network at any time without informing the other 1468 hosts. There is no reliable way to provide a zone serial number that 1469 would, whenever such a crash or disconnection occurred, immediately 1470 change to indicate that the contents of the shared zone had changed. 1472 Zone transfers are not possible for any Multicast DNS Zone. 1474 13. Multicast DNS for Service Discovery 1476 This document does not describe using Multicast DNS for network 1477 browsing or service discovery. However, the mechanisms this document 1478 describes are compatible with (and support) the browsing and service 1479 discovery mechanisms proposed in "DNS-Based Service Discovery" 1480 [DNS-SD]. 1482 14. Enabling and Disabling Multicast DNS 1484 The option to fail-over to Multicast DNS for names not ending in 1485 ".local." SHOULD be a user-configured option, and SHOULD 1486 be disabled by default because of the possible security issues 1487 related to unintended local resolution of apparently global names. 1489 The option to lookup unqualified (relative) names by appending 1490 ".local." (or not) is controlled by whether ".local." appears 1491 (or not) in the client's DNS search list. 1493 No special control is needed for enabling and disabling Multicast DNS 1494 for names explicitly ending with ".local." as entered by the user. 1495 The user doesn't need a way to disable Multicast DNS for names ending 1496 with ".local.", because if the user doesn't want to use Multicast 1497 DNS, they can achieve this by simply not using those names. If a user 1498 *does* enter a name ending in ".local.", then we can safely assume 1499 the user's intention was probably that it should work. Having user 1500 configuration options that can be (intentionally or unintentionally) 1501 set so that local names don't work is just one more way of 1502 frustrating the user's ability to perform the tasks they want, 1503 perpetuating the view that, "IP networking is too complicated to 1504 configure and too hard to use." This in turn perpetuates the 1505 continued use of protocols like AppleTalk. If we want to retire 1506 AppleTalk, NetBIOS, etc., we need to offer users equivalent IP 1507 functionality that they can rely on to, "always work, like 1508 AppleTalk." A little Multicast DNS traffic may be a burden on the 1509 network, but it is an insignificant burden compared to continued 1510 widespread use of AppleTalk. 1512 15. Considerations for Multiple Interfaces 1514 A host should defend its host name (FQDN) on all active interfaces on 1515 which it is answering Multicast DNS queries. 1517 In the event of a name conflict on *any* interface, a host should 1518 configure a new host name, if it wishes to maintain uniqueness of its 1519 host name. 1521 A host may choose to use the same name for all of its address records 1522 on all interfaces, or it may choose to manage its Multicast DNS host 1523 name(s) independently on each interface, potentially answering to 1524 different names on different interfaces. 1526 When answering a Multicast DNS query, a multi-homed host with a 1527 link-local address (or addresses) should take care to ensure that 1528 any address going out in a Multicast DNS response is valid for use 1529 on the interface on which the response is going out. 1531 Just as the same link-local IP address may validly be in use 1532 simultaneously on different links by different hosts, the same 1533 link-local host name may validly be in use simultaneously on 1534 different links, and this is not an error. A multi-homed host with 1535 connections to two different links may be able to communicate with 1536 two different hosts that are validly using the same name. While this 1537 kind of name duplication should be rare, it means that a host that 1538 wants to fully support this case needs network programming APIs that 1539 allow applications to specify on what interface to perform a 1540 link-local Multicast DNS query, and to discover on what interface a 1541 Multicast DNS response was received. 1543 16. Multicast DNS and Power Management 1545 Many modern network devices have the ability to go into a low-power 1546 mode where only a small part of the Ethernet hardware remains 1547 powered, and the device can be woken up by sending a specially 1548 formatted Ethernet frame which the device's power-management hardware 1549 recognizes. 1551 To make use of this in conjunction with Multicast DNS, we propose a 1552 network power management service called Sleep Proxy Service. A device 1553 that wishes to enter low-power mode first uses DNS-SD to determine if 1554 Sleep Proxy Service is available on the local network. In some 1555 networks there may be more than one piece of hardware implementing 1556 Sleep Proxy Service, for fault-tolerance reasons. 1558 If the device finds the network has Sleep Proxy Service, the device 1559 transmits two or more gratuitous mDNS announcements setting the TTL 1560 of its relevant resource records to zero, to delete them from 1561 neighboring caches. The relevant resource records include address 1562 records and SRV records, and other resource records as may apply to a 1563 particular device. The device then communicates all of its remaining 1564 active records, plus the names, rrtypes and rrclasses of the deleted 1565 records, to the Sleep Proxy Service(s), along with a copy of the 1566 specific "magic packet" required to wake the device up. 1568 When a Sleep Proxy Service sees an mDNS query for one of the 1569 device's active records (e.g. a DNS-SD PTR record), it answers on 1570 behalf of the device without waking it up. When a Sleep Proxy Service 1571 sees an mDNS query for one of the device's deleted resource 1572 records, it deduces that some client on the network needs to make an 1573 active connection to the device, and sends the specified "magic 1574 packet" to wake the device up. The device then wakes up, reactivates 1575 its deleted resource records, and re-announces them to the network. 1576 The client waiting to connect sees the announcements, learns the 1577 current IP address and port number of the desired service on the 1578 device, and proceeds to connect to it. 1580 The connecting client does not need to be aware of how Sleep Proxy 1581 Service works. Only devices that implement low power mode and wish to 1582 make use of Sleep Proxy Service need to be aware of how that protocol 1583 works. 1585 The reason that a device using a Sleep Proxy Service should send more 1586 than one goodbye packet is to ensure deletion of the resource records 1587 from all peer caches. If resource records were to inadvertently 1588 remain in some peer caches, then those peers may not issue any query 1589 packets for those records when attempting to access the sleeping 1590 device, so the Sleep Proxy Service would not receive any queries for 1591 the device's SRV and/or address records, and the necessary wake-up 1592 message would not be triggered. 1594 The full specification of mDNS / DNS-SD Sleep Proxy Service 1595 is described in another document [not yet published]. 1597 17. Multicast DNS Character Set 1599 Unicast DNS has been plagued by the lack of any support for non-US 1600 characters. Indeed, conventional DNS is usually limited to just 1601 letters, digits and hyphens, with no spaces or other punctuation. 1602 Attempts to remedy this for unicast DNS have been badly constrained 1603 by the need to accommodate old buggy legacy DNS implementations. 1604 In reality, the DNS specification actually imposes no limits on what 1605 characters may be used in names, and good DNS implementations handle 1606 any arbitrary eight-bit data without trouble. However, the old rules 1607 for ARPANET host names back in the 1980s required names to be just 1608 letters, digits, and hyphens [RFC 1034], and since the predominant 1609 use of DNS is to store host address records, many have assumed that 1610 the DNS protocol itself suffers from the same limitation. It would be 1611 more accurate to say that certain bad implementations may not handle 1612 eight-bit data correctly, not that the protocol doesn't support it. 1614 Multicast DNS is a new protocol and doesn't (yet) have old buggy 1615 legacy implementations to constrain the design choices. Accordingly, 1616 it adopts the simple obvious elegant solution: all names in 1617 Multicast DNS are encoded using precomposed UTF-8 [RFC 3629]. The 1618 characters SHOULD conform to Unicode Normalization Form C (NFC): Use 1619 precomposed characters instead of combining sequences where possible, 1620 e.g. use U+00C4 ("Latin capital letter A with diaeresis") instead 1621 of U+0041 U+0308 ("Latin capital letter A", "combining diaeresis"). 1622 Some users of 16-bit Unicode have taken to stuffing a "zero-width 1623 non-breaking space" character (U+FEFF) at the start of each UTF-16 1624 file, as a hint to identify whether the data is big-endian or little- 1625 endian, and calling it a "Byte Order Mark" (BOM). Since there is only 1626 one possible byte order for UTF-8 data, a BOM is neither necessary 1627 nor permitted. Multicast DNS names MUST NOT contain a "Byte Order 1628 Mark". Any occurrence of the Unicode character U+FEFF in a Multicast 1629 DNS name MUST be interpreted as a zero-width non-breaking space. 1631 For names that are restricted to letters, digits and hyphens, the 1632 UTF-8 encoding is identical to the US-ASCII encoding, so this is 1633 entirely compatible with existing host names. For characters outside 1634 the US-ASCII range, UTF-8 encoding is used. 1636 Multicast DNS implementations MUST NOT use any other encodings apart 1637 from precomposed UTF-8 (US-ASCII being considered a compatible subset 1638 of UTF-8). 1640 This point bears repeating: After many years of debate, as a result 1641 of the need to accommodate certain DNS implementations that 1642 apparently couldn't handle any character that's not a letter, digit 1643 or hyphen (and apparently never will be updated to remedy this 1644 limitation) the unicast DNS community settled on an extremely baroque 1645 encoding called "Punycode" [RFC 3492]. Punycode is a remarkably 1646 ingenious encoding solution, but it is complicated, hard to 1647 understand, and hard to implement, using sophisticated techniques 1648 including insertion unsort coding, generalized variable-length 1649 integers, and bias adaptation. The resulting encoding is remarkably 1650 compact given the constraints, but it's still not as good as simple 1651 straightforward UTF-8, and it's hard even to predict whether a given 1652 input string will encode to a Punycode string that fits within DNS's 1653 63-byte limit, except by simply trying the encoding and seeing 1654 whether it fits. Indeed, the encoded size depends not only on the 1655 input characters, but on the order they appear, so the same set of 1656 characters may or may not encode to a legal Punycode string that fits 1657 within DNS's 63-byte limit, depending on the order the characters 1658 appear. This is extremely hard to present in a user interface that 1659 explains to users why one name is allowed, but another name 1660 containing the exact same characters is not. Neither Punycode nor any 1661 other of the "Ascii Compatible Encodings" proposed for Unicast DNS 1662 may be used in Multicast DNS packets. Any text being represented 1663 internally in some other representation MUST be converted to 1664 canonical precomposed UTF-8 before being placed in any Multicast DNS 1665 packet. 1667 The simple rules for case-insensitivity in Unicast DNS also apply in 1668 Multicast DNS; that is to say, in name comparisons, the lower-case 1669 letters "a" to "z" (0x61 to 0x7A) match their upper-case equivalents 1670 "A" to "Z" (0x41 to 0x5A). Hence, if a client issues a query for an 1671 address record with the name "cheshire.local", then a responder 1672 having an address record with the name "Cheshire.local" should 1673 issue a response. No other automatic equivalences should be assumed. 1674 In particular all UTF-8 multi-byte characters (codes 0x80 and higher) 1675 are compared by simple binary comparison of the raw byte values. 1677 No other automatic character equivalence is defined in Multicast DNS. 1678 For example, accented characters are not defined to be automatically 1679 equivalent to their unaccented counterparts. Where automatic 1680 equivalences are desired, this may be achieved through the use of 1681 programmatically-generated CNAME records. For example, if a responder 1682 has an address record for an accented name Y, and a client issues a 1683 query for a name X, where X is the same as Y with all the accents 1684 removed, then the responder may issue a response containing two 1685 resource records: A CNAME record "X CNAME Y", asserting that the 1686 requested name X (unaccented) is an alias for the true (accented) 1687 name Y, followed by the address record for Y. 1689 18. Multicast DNS Message Size 1691 RFC 1035 restricts DNS Messages carried by UDP to no more than 512 1692 bytes (not counting the IP or UDP headers). For UDP packets carried 1693 over the wide-area Internet in 1987, this was appropriate. For 1694 link-local multicast packets on today's networks, there is no reason 1695 to retain this restriction. Given that the packets are by definition 1696 link-local, there are no Path MTU issues to consider. 1698 Multicast DNS Messages carried by UDP may be up to the IP MTU of the 1699 physical interface, less the space required for the IP header (20 1700 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes). 1702 In the case of a single mDNS Resource Record which is too large to 1703 fit in a single MTU-sized multicast response packet, a Multicast DNS 1704 Responder SHOULD send the Resource Record alone, in a single IP 1705 datagram, sent using multiple IP fragments. Resource Records this 1706 large SHOULD be avoided, except in the very rare cases where they 1707 really are the appropriate solution to the problem at hand. 1708 Implementers should be aware that many simple devices do not 1709 re-assemble fragmented IP datagrams, so large Resource Records SHOULD 1710 NOT be used except in specialized cases where the implementer knows 1711 that all receivers implement reassembly. 1713 A Multicast DNS packet larger than the interface MTU, which is sent 1714 using fragments, MUST NOT contain more than one Resource Record. 1716 Even when fragmentation is used, a Multicast DNS packet, including IP 1717 and UDP headers, MUST NOT exceed 9000 bytes. 1719 19. Multicast DNS Message Format 1721 This section describes specific restrictions on the allowable 1722 values for the header fields of a Multicast DNS message. 1724 19.1. ID (Query Identifier) 1726 Multicast DNS clients SHOULD listen for gratuitous responses 1727 issued by hosts booting up (or waking up from sleep or otherwise 1728 joining the network). Since these gratuitous responses may contain a 1729 useful answer to a question for which the client is currently 1730 awaiting an answer, Multicast DNS clients SHOULD examine all received 1731 Multicast DNS response messages for useful answers, without regard to 1732 the contents of the ID field or the Question Section. In Multicast 1733 DNS, knowing which particular query message (if any) is responsible 1734 for eliciting a particular response message is less interesting than 1735 knowing whether the response message contains useful information. 1737 Multicast DNS clients MAY cache any or all Multicast DNS response 1738 messages they receive, for possible future use, provided of course 1739 that normal TTL aging is performed on these cached resource records. 1741 In multicast query messages, the Query ID SHOULD be set to zero on 1742 transmission. 1744 In multicast responses, including gratuitous multicast responses, the 1745 Query ID MUST be set to zero on transmission, and MUST be ignored on 1746 reception. 1748 In unicast response messages generated specifically in response to a 1749 particular (unicast or multicast) query, the Query ID MUST match the 1750 ID from the query message. 1752 19.2. QR (Query/Response) Bit 1754 In query messages, MUST be zero. 1755 In response messages, MUST be one. 1757 19.3. OPCODE 1759 In both multicast query and multicast response messages, MUST be zero 1760 (only standard queries are currently supported over multicast, unless 1761 other queries are allowed by future IETF Standards Action). 1763 19.4. AA (Authoritative Answer) Bit 1765 In query messages, the Authoritative Answer bit MUST be zero on 1766 transmission, and MUST be ignored on reception. 1768 In response messages for Multicast Domains, the Authoritative Answer 1769 bit MUST be set to one (not setting this bit implies there's some 1770 other place where "better" information may be found) and MUST be 1771 ignored on reception. 1773 19.5. TC (Truncated) Bit 1775 In query messages, if the TC bit is set, it means that additional 1776 Known Answer records may be following shortly. A responder MAY choose 1777 to record this fact, and wait for those additional Known Answer 1778 records, before deciding whether to respond. If the TC bit is clear, 1779 it means that the querying host has no additional Known Answers. 1781 In multicast response messages, the TC bit MUST be zero on 1782 transmission, and MUST be ignored on reception. 1784 In legacy unicast response messages, the TC bit has the same meaning 1785 as in conventional unicast DNS: it means that the response was too 1786 large to fit in a single packet, so the client SHOULD re-issue its 1787 query using TCP in order to receive the larger response. 1789 19.6. RD (Recursion Desired) Bit 1791 In both multicast query and multicast response messages, the 1792 Recursion Desired bit SHOULD be zero on transmission, and MUST be 1793 ignored on reception. 1795 19.7. RA (Recursion Available) Bit 1797 In both multicast query and multicast response messages, the 1798 Recursion Available bit MUST be zero on transmission, and MUST be 1799 ignored on reception. 1801 19.8. Z (Zero) Bit 1803 In both query and response messages, the Zero bit MUST be zero on 1804 transmission, and MUST be ignored on reception. 1806 19.9. AD (Authentic Data) Bit [RFC 2535] 1808 In query messages the Authentic Data bit MUST be zero on 1809 transmission, and MUST be ignored on reception. 1811 In response messages, the Authentic Data bit MAY be set. Resolvers 1812 receiving response messages with the AD bit set MUST NOT trust the AD 1813 bit unless they trust the source of the message and either have a 1814 secure path to it or use DNS transaction security. 1816 19.10. CD (Checking Disabled) Bit [RFC 2535] 1818 In query messages, a resolver willing to do cryptography SHOULD set 1819 the Checking Disabled bit to permit it to impose its own policies. 1821 In response messages, the Checking Disabled bit MUST be zero on 1822 transmission, and MUST be ignored on reception. 1824 19.11. RCODE (Response Code) 1826 In both multicast query and multicast response messages, the Response 1827 Code MUST be zero on transmission. Multicast DNS messages received 1828 with non-zero Response Codes MUST be silently ignored. 1830 19.12. Repurposing of top bit of qclass in Question Section 1832 In the Question Section of a Multicast DNS Query, the top bit of the 1833 qclass field is used to indicate that unicast responses are preferred 1834 for this particular question. 1836 19.13. Repurposing of top bit of rrclass in Answer Section 1838 In the Answer Section of a Multicast DNS Response, the top bit of the 1839 rrclass field is used to indicate that the record is a member of a 1840 unique RRSet, and the entire RRSet has been sent together (in the 1841 same packet, or in consecutive packets if there are too many records 1842 to fit in a single packet). 1844 20. Choice of UDP Port Number 1846 Arguments were made for and against using Multicast on UDP port 53. 1847 The final decision was to use UDP port 5353. Some of the arguments 1848 for and against are given below. 1850 20.1 Arguments for using UDP port 53: 1852 * This is "just DNS", so it should be the same port. 1854 * There is less work to be done updating old clients to do simple 1855 mDNS queries. Only the destination address need be changed. 1856 In some cases, this can be achieved without any code changes, 1857 just by adding the address 224.0.0.251 to a configuration file. 1859 20.2 Arguments for using a different port (UDP port 5353): 1861 * This is not "just DNS". This is a DNS-like protocol, but different. 1863 * Changing client code to use a different port number is not hard. 1865 * Using the same port number makes it hard to run an mDNS Responder 1866 and a conventional unicast DNS server on the same machine. If a 1867 conventional unicast DNS server wishes to implement mDNS as well, 1868 it can still do that, by opening two sockets. Having two different 1869 port numbers is important to allow this flexibility. 1871 * Some VPN software hijacks all outgoing traffic to port 53 and 1872 redirects it to a special DNS server set up to serve those VPN 1873 clients while they are connected to the corporate network. It is 1874 questionable whether this is the right thing to do, but it is 1875 common, and redirecting link-local multicast DNS packets to a 1876 remote server rarely produces any useful results. It does mean, 1877 for example, that the user becomes unable to access their local 1878 network printer sitting on their desk right next to their computer. 1879 Using a different UDP port eliminates this particular problem. 1881 * On many operating systems, unprivileged clients may not send or 1882 receive packets on low-numbered ports. This means that any client 1883 sending or receiving mDNS packets on port 53 would have to run as 1884 "root", which is an undesirable security risk. Using a higher- 1885 numbered UDP port eliminates this particular problem. 1887 Continuing the previous point, since using an unprivileged port 1888 allows normal user-level code to bind, a given machine may have more 1889 than one such user-level application running at a time. Because of 1890 this, any code binding to UDP port 5353 MUST use the SO_REUSEPORT 1891 option, so as to be a good citizen and not block other clients on the 1892 machine from also binding to that port. 1894 21. Summary of Differences Between Multicast DNS and Unicast DNS 1896 The value of Multicast DNS is that it shares, as much as possible, 1897 the familiar APIs, naming syntax, resource record types, etc., of 1898 Unicast DNS. There are of course necessary differences by virtue of 1899 it using Multicast, and by virtue of it operating in a community of 1900 cooperating peers, rather than a precisely defined authoritarian 1901 hierarchy controlled by a strict chain of formal delegations from the 1902 top. These differences are listed below: 1904 Multicast DNS... 1905 * uses multicast 1906 * uses UDP port 5353 instead of port 53 1907 * operates in well-defined parts of the DNS namespace 1908 * uses UTF-8, and only UTF-8, to encode resource record names 1909 * defines a clear limit on the maximum legal domain name (255 bytes) 1910 * allows larger UDP packets 1911 * allows more than one question in a query packet 1912 * uses the Answer Section of a query to list Known Answers 1913 * uses the TC bit in a query to indicate additional Known Answers 1914 * uses the Authority Section of a query for probe tie-breaking 1915 * ignores the Query ID field (except for generating legacy responses) 1916 * doesn't require the question to be repeated in the response packet 1917 * uses gratuitous responses to announce new records to the peer group 1918 * defines a "unicast response" bit in the rrclass of query questions 1919 * defines a "cache flush" bit in the rrclass of response answers 1920 * uses DNS TTL 0 to indicate that a record has been deleted 1921 * monitors queries to perform Duplicate Question Suppression 1922 * monitors responses to perform Duplicate Answer Suppression... 1923 * ... and Ongoing Conflict Detection 1924 * ... and Opportunistic Caching 1926 22. Benefits of Multicast Responses 1928 Some people have argued that sending responses via multicast is 1929 inefficient on the network. In fact using multicast responses results 1930 in a net lowering of overall multicast traffic, for a variety of 1931 reasons, in addition to other benefits. 1933 * One multicast response can update the cache on all machines on the 1934 network. If another machine later wants to issue the same query, it 1935 already has the answer in its cache, so it may not need to even 1936 transmit that multicast query on the network at all. 1938 * When more than one machine has the same ongoing long-lived query 1939 running, every machine does not have to transmit its own 1940 independent query. When one machine transmits a query, all the 1941 other hosts see the answers, so they can suppress their own 1942 queries. 1944 * When a host sees a multicast query, but does not see the corres- 1945 ponding multicast response, it can use this information to promptly 1946 delete stale data from its cache. To achieve the same level of 1947 user-interface quality and responsiveness without multicast 1948 responses would require lower cache lifetimes and more frequent 1949 network polling, resulting in a significantly higher packet rate. 1951 * Multicast responses allow passive conflict detection. Without this 1952 ability, some other conflict detection mechanism would be needed, 1953 imposing its own additional burden on the network. 1955 * When using delayed responses to reduce network collisions, clients 1956 need to maintain a list recording to whom each answer should be 1957 sent. The option of multicast responses allows clients with limited 1958 storage, which cannot store an arbitrarily long list of response 1959 addresses, to choose to fail-over to a single multicast response in 1960 place of multiple unicast responses, when appropriate. 1962 * In the case of overlayed subnets, multicast responses allow a 1963 receiver to know with certainty that a response originated on the 1964 local link, even when its source address may apparently suggest 1965 otherwise. 1967 * Link-local multicast transcends virtually every conceivable network 1968 misconfiguration. Even if you have a collection of devices where 1969 every device's IP address, subnet mask, default gateway, and DNS 1970 server address are all wrong, packets sent by any of those devices 1971 addressed to a link-local multicast destination address will still 1972 be delivered to all peers on the local link. This can be extremely 1973 helpful when diagnosing and rectifying network problems, since 1974 it facilitates a direct communication channel between client and 1975 server that works without reliance on ARP, IP routing tables, etc. 1976 Being able to discover what IP address a device has (or thinks it 1977 has) is frequently a very valuable first step in diagnosing why it 1978 unable to communicate on the local network. 1980 23. IPv6 Considerations 1982 An IPv4-only host and an IPv6-only host behave as "ships that pass in 1983 the night". Even if they are on the same Ethernet, neither is aware 1984 of the other's traffic. For this reason, each physical link may have 1985 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 1986 Since for practical purposes, a group of IPv4-only hosts and a group 1987 of IPv6-only hosts on the same Ethernet act as if they were on two 1988 entirely separate Ethernet segments, it is unsurprising that their 1989 use of the ".local." zone should occur exactly as it would if 1990 they really were on two entirely separate Ethernet segments. 1992 A dual-stack (v4/v6) host can participate in both ".local." 1993 zones, and should register its name(s) and perform its lookups both 1994 using IPv4 and IPv6. This enables it to reach, and be reached by, 1995 both IPv4-only and IPv6-only hosts. In effect this acts like a 1996 multi-homed host, with one connection to the logical "IPv4 Ethernet 1997 segment", and a connection to the logical "IPv6 Ethernet segment". 1999 23.1 IPv6 Multicast Addresses by Hashing 2001 Some discovery protocols use a range of multicast addresses, and 2002 determine the address to be used by a hash function of the name being 2003 sought. Queries are sent via multicast to the address as indicated by 2004 the hash function, and responses are returned to the querier via 2005 unicast. Particularly in IPv6, where multicast addresses are 2006 extremely plentiful, this approach is frequently advocated. 2008 There are some problems with this: 2010 * When a host has a large number of records with different names, the 2011 host may have to join a large number of multicast groups. This can 2012 place undue burden on the Ethernet hardware, which typically 2013 supports a limited number of multicast addresses efficiently. When 2014 this number is exceeded, the Ethernet hardware may have to resort 2015 to receiving all multicasts and passing them up to the host 2016 software for filtering, thereby defeating the point of using a 2017 multicast address range in the first place. 2019 * Multiple questions cannot be placed in one packet if they don't all 2020 hash to the same multicast address. 2022 * Duplicate Question Suppression doesn't work if queriers are not 2023 seeing each other's queries. 2025 * Duplicate Answer Suppression doesn't work if responders are not 2026 seeing each other's responses. 2028 * Opportunistic Caching doesn't work. 2030 * Ongoing Conflict Detection doesn't work. 2032 24. Security Considerations 2034 The algorithm for detecting and resolving name conflicts is, by its 2035 very nature, an algorithm that assumes cooperating participants. Its 2036 purpose is to allow a group of hosts to arrive at a mutually disjoint 2037 set of host names and other DNS resource record names, in the absence 2038 of any central authority to coordinate this or mediate disputes. In 2039 the absence of any higher authority to resolve disputes, the only 2040 alternative is that the participants must work together cooperatively 2041 to arrive at a resolution. 2043 In an environment where the participants are mutually antagonistic 2044 and unwilling to cooperate, other mechanisms are appropriate, like 2045 manually administered DNS. 2047 In an environment where there is a group of cooperating participants, 2048 but there may be other antagonistic participants on the same physical 2049 link, the cooperating participants need to use IPSEC signatures 2050 and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS 2051 messages from trusted participants (which they process as usual) from 2052 mDNS messages from untrusted participants (which they silently 2053 discard). 2055 When DNS queries for *global* DNS names are sent to the mDNS 2056 multicast address (during network outages which disrupt communication 2057 with the greater Internet) it is *especially* important to use 2058 DNSSEC, because the user may have the impression that he or she is 2059 communicating with some authentic host, when in fact he or she is 2060 really communicating with some local host that is merely masquerading 2061 as that name. This is less critical for names ending with ".local.", 2062 because the user should be aware that those names have only local 2063 significance and no global authority is implied. 2065 Most computer users neglect to type the trailing dot at the end of a 2066 fully qualified domain name, making it a relative domain name (e.g. 2067 "www.example.com"). In the event of network outage, attempts to 2068 positively resolve the name as entered will fail, resulting in 2069 application of the search list, including ".local.", if present. 2070 A malicious host could masquerade as "www.example.com" by answering 2071 the resulting Multicast DNS query for "www.example.com.local." 2072 To avoid this, a host MUST NOT append the search suffix 2073 ".local.", if present, to any relative (partially qualified) 2074 domain name containing two or more labels. Appending ".local." to 2075 single-label relative domain names is acceptable, since the user 2076 should have no expectation that a single-label domain name will 2077 resolve as-is. 2079 25. IANA Considerations 2081 IANA has allocated the IPv4 link-local multicast address 224.0.0.251 2082 for the use described in this document. 2084 IANA has allocated the IPv6 multicast address set FF0X::FB for the 2085 use described in this document. Only address FF02::FB (Link-Local 2086 Scope) is currently in use by deployed software, but it is possible 2087 that in future implementers may experiment with Multicast DNS using 2088 larger-scoped addresses, such as FF05::FB (Site-Local Scope). 2090 When this document is published, IANA should designate a list of 2091 domains which are deemed to have only link-local significance, as 2092 described in Section 12 of this document ("Special Characteristics of 2093 Multicast DNS Domains"). 2095 The re-use of the top bit of the rrclass field in the Question and 2096 Answer Sections means that Multicast DNS can only carry DNS records 2097 with classes in the range 0-32767. Classes in the range 32768 to 2098 65535 are incompatible with Multicast DNS. However, since to-date 2099 only three DNS classes have been assigned by IANA (1, 3 and 4), 2100 and only one (1, "Internet") is actually in widespread use, this 2101 limitation is likely to remain a purely theoretical one. 2103 No other IANA services are required by this document. 2105 26. Acknowledgments 2107 The concepts described in this document have been explored, developed 2108 and implemented with help from Freek Dijkstra, Erik Guttman, Paul 2109 Vixie, Bill Woodcock, and others. 2111 Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, 2112 Roger Pantos and Kiren Sekar for their significant contributions. 2114 27. Copyright Notice 2116 Copyright (C) The Internet Society (2005). 2118 This document is subject to the rights, licenses and restrictions 2119 contained in BCP 78, and except as set forth therein, the authors 2120 retain all their rights. For the purposes of this document, 2121 the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights 2122 in Contributions", published March 2005. 2124 This document and the information contained herein are provided on an 2125 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2126 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2127 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2128 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2129 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2130 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2132 28. Normative References 2134 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and 2135 Facilities", STD 13, RFC 1034, November 1987. 2137 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and 2138 Specifications", STD 13, RFC 1035, November 1987. 2140 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 2141 Requirement Levels", RFC 2119, March 1997. 2143 [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO 2144 10646", RFC 3629, November 2003. 2146 29. Informative References 2148 [dotlocal] 2150 [djbdl] 2152 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service 2153 Discovery", Internet-Draft (work in progress), 2154 draft-cheshire-dnsext-dns-sd-03.txt, June 2005. 2156 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 2157 Overview and Architecture. 2158 Institute of Electrical and Electronic Engineers, 2159 IEEE Standard 802, 1990. 2161 [NBP] Cheshire, S., and M. Krochmal, 2162 "Requirements for a Protocol to Replace AppleTalk NBP", 2163 Internet-Draft (work in progress), 2164 draft-cheshire-dnsext-nbp-04.txt, June 2005. 2166 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name 2167 System (DNS UPDATE)", RFC 2136, April 1997. 2169 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address 2170 Autoconfiguration", RFC 2462, December 1998. 2172 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", 2173 RFC 2535, March 1999. 2175 [RFC 3492] Costello, A., "Punycode: A Bootstring encoding of 2176 Unicode for use with Internationalized Domain Names 2177 in Applications (IDNA)", RFC 3492, March 2003. 2179 [RFC 3927] Cheshire, S., B. Aboba, and E. Guttman, 2180 "Dynamic Configuration of IPv4 Link-Local Addresses", 2181 RFC 3927, May 2005. 2183 [ZC] Williams, A., "Requirements for Automatic Configuration 2184 of IP Hosts", Internet-Draft (work in progress), 2185 draft-ietf-zeroconf-reqts-12.txt, September 2002. 2187 30. Authors' Addresses 2189 Stuart Cheshire 2190 Apple Computer, Inc. 2191 1 Infinite Loop 2192 Cupertino 2193 California 95014 2194 USA 2196 Phone: +1 408 974 3207 2197 EMail: rfc [at] stuartcheshire [dot] org 2199 Marc Krochmal 2200 Apple Computer, Inc. 2201 1 Infinite Loop 2202 Cupertino 2203 California 95014 2204 USA 2206 Phone: +1 408 974 4368 2207 EMail: marc [at] apple [dot] com