1 Document: draft-cheshire-dnsext-multicastdns-05.txt Stuart Cheshire
2 Category: Standards Track Apple Computer, Inc.
3 Expires 7th December 2005 Marc Krochmal
9 <draft-cheshire-dnsext-multicastdns-05.txt>
14 By submitting this Internet-Draft, each author represents
15 that any applicable patent or other IPR claims of which he or she is
16 aware have been or will be disclosed, and any of which he or she
17 become aware will be disclosed, in accordance with RFC 3979.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
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.
60 Expires 7th December 2005 Cheshire & Krochmal [Page 1]
62 Internet Draft Multicast DNS 7th June 2005
67 1. Introduction...................................................3
68 2. Conventions and Terminology Used in this Document..............4
69 3. Multicast DNS Names............................................5
70 4. Source Address Check...........................................8
71 5. Reverse Address Mapping........................................9
72 6. Querying.......................................................9
73 7. Duplicate Suppression.........................................13
74 8. Responding....................................................15
75 9. Probing and Announcing on Startup.............................18
76 10. Conflict Resolution...........................................22
77 11. Resource Record TTL Values and Cache Coherency................23
78 12. Special Characteristics of Multicast DNS Domains..............28
79 13. Multicast DNS for Service Discovery...........................30
80 14. Enabling and Disabling Multicast DNS..........................30
81 15. Considerations for Multiple Interfaces........................30
82 16. Multicast DNS and Power Management............................31
83 17. Multicast DNS Character Set...................................32
84 18. Multicast DNS Message Size....................................34
85 19. Multicast DNS Message Format..................................34
86 20. Choice of UDP Port Number.....................................37
87 21. Summary of Differences Between Multicast DNS and Unicast DNS..38
88 22. Benefits of Multicast Responses...............................38
89 23. IPv6 Considerations...........................................39
90 24. Security Considerations.......................................40
91 25. IANA Considerations...........................................41
92 26. Acknowledgments...............................................42
93 27. Copyright.....................................................42
94 28. Normative References..........................................42
95 29. Informative References........................................43
96 30. Authors' Addresses............................................44
120 Expires 7th December 2005 Cheshire & Krochmal [Page 2]
122 Internet Draft Multicast DNS 7th June 2005
127 When reading this document, familiarity with the concepts of Zero
128 Configuration Networking [ZC] and automatic link-local addressing
129 [RFC 2462] [RFC 3927] is helpful.
131 This document proposes no change to the structure of DNS messages,
132 and no new operation codes, response codes, or resource record types.
133 This document simply discusses what needs to happen if DNS clients
134 start sending DNS queries to a multicast address, and how a
135 collection of hosts can cooperate to collectively answer those
136 queries in a useful manner.
138 There has been discussion of how much burden Multicast DNS might
139 impose on a network. It should be remembered that whenever IPv4 hosts
140 communicate, they broadcast ARP packets on the network on a regular
141 basis, and this is not disastrous. The approximate amount of
142 multicast traffic generated by hosts making conventional use of
143 Multicast DNS is anticipated to be roughly the same order of
144 magnitude as the amount of broadcast ARP traffic those hosts already
147 New applications making new use of Multicast DNS capabilities for
148 unconventional purposes may generate more traffic. If some of those
149 new applications are "chatty", then work will be needed to help them
150 become less chatty. When performing any analysis, it is important to
151 make a distinction between the application behavior and the
152 underlying protocol behavior. If a chatty application uses UDP, that
153 doesn't mean that UDP is chatty, or that IP is chatty, or that
154 Ethernet is chatty. What it means is that the application is chatty.
155 The same applies to any future applications that may decide to layer
156 increasing portions of their functionality over Multicast DNS.
180 Expires 7th December 2005 Cheshire & Krochmal [Page 3]
182 Internet Draft Multicast DNS 7th June 2005
185 2. Conventions and Terminology Used in this Document
187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
189 document are to be interpreted as described in "Key words for use in
190 RFCs to Indicate Requirement Levels" [RFC 2119].
192 This document uses the term "host name" in the strict sense to mean a
193 fully qualified domain name that has an address record. It does not
194 use the term "host name" in the commonly used but incorrect sense to
195 mean just the first DNS label of a host's fully qualified domain
198 A DNS (or mDNS) packet contains an IP TTL in the IP header, which
199 is effectively a hop-count limit for the packet, to guard against
200 routing loops. Each Resource Record also contains a TTL, which is
201 the number of seconds for which the Resource Record may be cached.
203 In any place where there may be potential confusion between these two
204 types of TTL, the term "IP TTL" is used to refer to the IP header TTL
205 (hop limit), and the term "RR TTL" is used to refer to the Resource
206 Record TTL (cache lifetime).
208 When this document uses the term "Multicast DNS", it should be taken
209 to mean: "Clients performing DNS-like queries for DNS-like resource
210 records by sending DNS-like UDP query and response packets over IP
211 Multicast to UDP port 5353."
213 This document uses the terms "shared" and "unique" when referring to
214 resource record sets.
216 A "shared" resource record set is one where several Multicast DNS
217 responders may have records with that name, rrtype, and rrclass, and
218 several responders may respond to a particular query.
220 A "unique" resource record set is one where all the records with that
221 name, rrtype, and rrclass are under the control or ownership of a
222 single responder, and at most one responder should respond to any
223 given query. Before claiming ownership of a unique resource record
224 set, a responder MUST probe to verify that no other responder
225 already claims ownership of that set, as described in Section 9.1
228 Strictly speaking the terms "shared" and "unique" apply to resource
229 record sets, not to individual resource records, but it is sometimes
230 convenient to talk of "shared resource records" and "unique resource
231 records". When used this way, the terms should be understood to mean
232 a record that is a member of a "shared" or "unique" resource record
240 Expires 7th December 2005 Cheshire & Krochmal [Page 4]
242 Internet Draft Multicast DNS 7th June 2005
245 3. Multicast DNS Names
247 This document proposes that the DNS top-level domain ".local." be
248 designated a special domain with special semantics, namely that any
249 fully-qualified name ending in ".local." is link-local, and names
250 within this domain are meaningful only on the link where they
251 originate. This is analogous to IPv4 addresses in the 169.254/16
252 prefix, which are link-local and meaningful only on the link where
255 Any DNS query for a name ending with ".local." MUST be sent
256 to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent
259 It is unimportant whether a name ending with ".local." occurred
260 because the user explicitly typed in a fully qualified domain name
261 ending in ".local.", or because the user entered an unqualified
262 domain name and the host software appended the suffix ".local."
263 because that suffix appears in the user's search list. The ".local."
264 suffix could appear in the search list because the user manually
265 configured it, or because it was received in a DHCP option, or via
266 any other valid mechanism for configuring the DNS search list. In
267 this respect the ".local." suffix is treated no differently to any
268 other search domain that might appear in the DNS search list.
270 DNS queries for names that do not end with ".local." MAY be sent to
271 the mDNS multicast address, if no other conventional DNS server is
272 available. This can allow hosts on the same link to continue
273 communicating using each other's globally unique DNS names during
274 network outages which disrupt communication with the greater
275 Internet. When resolving global names via local multicast, it is even
276 more important to use DNSSEC or other security mechanisms to ensure
277 that the response is trustworthy. Resolving global names via local
278 multicast is a contentious issue, and this document does not discuss
279 it in detail, instead concentrating on the issue of resolving local
280 names using DNS packets sent to a multicast address.
282 A host which belongs to an organization or individual who has control
283 over some portion of the DNS namespace can be assigned a globally
284 unique name within that portion of the DNS namespace, for example,
285 "cheshire.apple.com." For those of us who have this luxury, this
286 works very well. However, the majority of home customers do not have
287 easy access to any portion of the global DNS namespace within which
288 they have the authority to create names as they wish. This leaves the
289 majority of home computers effectively anonymous for practical
292 To remedy this problem, this document allows any computer user to
293 elect to give their computers link-local Multicast DNS host names of
294 the form: "single-dns-label.local." For example, a laptop computer
295 may answer to the name "cheshire.local." Any computer user is granted
296 the authority to name their computer this way, provided that the
297 chosen host name is not already in use on that link. Having named
300 Expires 7th December 2005 Cheshire & Krochmal [Page 5]
302 Internet Draft Multicast DNS 7th June 2005
305 their computer this way, the user has the authority to continue using
306 that name until such time as a name conflict occurs on the link which
307 is not resolved in the user's favour. If this happens, the computer
308 (or its human user) SHOULD cease using the name, and may choose to
309 attempt to allocate a new unique name for use on that link. These
310 conflicts are expected to be relatively rare for people who choose
311 reasonably imaginative names, but it is still important to have a
312 mechanism in place to handle them when they happen.
314 The point made in the previous paragraph is very important and bears
315 repeating. It is easy for those of us in the IETF community who run
316 our own name servers at home to forget that the majority of computer
317 users do not run their own name server and have no easy way to create
318 their own host names. When these users wish to transfer files between
319 two laptop computers, they are frequently reduced to typing in
320 dotted-decimal IP addresses because they simply have no other way for
321 one host to refer to the other by name. This is a sorry state of
322 affairs. What is worse, most users don't even bother trying to use
323 dotted-decimal IP addresses. Most users still move data between
324 machines by copying it onto a floppy disk or similar removable media.
326 In a world of gigabit Ethernet and ubiquitous wireless networking it
327 is a sad indictment of the networking community that the preferred
328 communication medium for most computer users is still the floppy
331 Allowing ad-hoc allocation of single-label names in a single flat
332 ".local." namespace may seem to invite chaos. However, operational
333 experience with AppleTalk NBP names [NBP], which on any given link
334 are also effectively single-label names in a flat namespace, shows
335 that in practice name collisions happen extremely rarely and are not
336 a problem. Groups of computer users from disparate organizations
337 bring Macintosh laptop computers to events such as IETF Meetings, the
338 Mac Hack conference, the Apple World Wide Developer Conference, etc.,
339 and complaints at these events about users suffering conflicts and
340 being forced to rename their machines have never been an issue.
342 Enforcing uniqueness of host names (i.e. the names of DNS address
343 records mapping names to IP addresses) is probably desirable in the
344 common case, but this document does not mandate that. It is
345 permissible for a collection of coordinated hosts to agree to
346 maintain multiple DNS address records with the same name, possibly
347 for load balancing or fault-tolerance reasons. This document does not
348 take a position on whether that is sensible. It is important that
349 both modes of operation are supported. The Multicast DNS protocol
350 allows hosts to verify and maintain unique names for resource records
351 where that behavior is desired, and it also allows hosts to maintain
352 multiple resource records with a single shared name where that
353 behavior is desired. This consideration applies to all resource
354 records, not just address records (host names). In summary: It is
355 required that the protocol have the ability to detect and handle name
356 conflicts, but it is not required that this ability be used for every
360 Expires 7th December 2005 Cheshire & Krochmal [Page 6]
362 Internet Draft Multicast DNS 7th June 2005
365 3.1 Governing Standards Body
367 Note that this use of the ".local." suffix falls under IETF
368 jurisdiction, not ICANN jurisdiction. DNS is an IETF network
369 protocol, governed by protocol rules defined by the IETF. These IETF
370 protocol rules dictate character set, maximum name length, packet
371 format, etc. ICANN determines additional rules that apply when the
372 IETF's DNS protocol is used on the public Internet. In contrast,
373 private uses of the DNS protocol on isolated private networks are not
374 governed by ICANN. Since this proposed change is a change to the core
375 DNS protocol rules, it affects everyone, not just those machines
376 using the ICANN-governed Internet. Hence this change falls into the
377 category of an IETF protocol rule, not an ICANN usage rule.
379 3.2 Private DNS Namespaces
381 Note also that the special treatment of names ending in ".local." has
382 been implemented in Macintosh computers since the days of Mac OS 9,
383 and continues today in Mac OS X. There are also implementations for
384 Linux and other platforms [dotlocal]. Operators setting up private
385 internal networks ("intranets") are advised that their lives may be
386 easier if they avoid using the suffix ".local." in names in their
387 private internal DNS server. Alternative possibilities include:
395 Another alternative naming scheme, advocated by Professor D. J.
396 Bernstein, is to use a numerical suffix, such as ".6." [djbdl].
398 3.3 Maximum Multicast DNS Name Length
402 "the total number of octets that represent a domain name (i.e.,
403 the sum of all label octets and label lengths) is limited to 255."
405 This text implies that the final root label at the end of every name
406 is included in this count (a name can't be represented without it),
407 but the text does not explicitly state that. Implementations of
408 Multicast DNS MUST include the label length byte of the final root
409 label at the end of every name when enforcing the rule that no name
410 may be longer than 255 bytes. For example, the length of the name
411 "apple.com." is considered to be 11, which is the number of bytes it
412 takes to represent that name in a packet without using name
415 ------------------------------------------------------
416 | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 |
417 ------------------------------------------------------
420 Expires 7th December 2005 Cheshire & Krochmal [Page 7]
422 Internet Draft Multicast DNS 7th June 2005
425 4. Source Address Check
427 All Multicast DNS responses (including responses sent via unicast)
428 SHOULD be sent with IP TTL set to 255. This is recommended to provide
429 backwards-compatibility with older Multicast DNS clients that check
430 the IP TTL on reception to determine whether the packet originated
431 on the local link. These older clients discard all packets with TTLs
434 A host sending Multicast DNS queries to a link-local destination
435 address (including the 224.0.0.251 link-local multicast address)
436 MUST only accept responses to that query that originate from the
437 local link, and silently discard any other response packets. Without
438 this check, it could be possible for remote rogue hosts to send
439 spoof answer packets (perhaps unicast to the victim host) which the
440 receiving machine could misinterpret as having originated on the
443 The test for whether a response originated on the local link
446 * All responses sent to the link-local multicast address 224.0.0.251
447 are necessarily deemed to have originated on the local link,
448 regardless of source IP address. This is essential to allow devices
449 to work correctly and reliably in unusual configurations, such as
450 multiple logical IP subnets overlayed on a single link, or in cases
451 of severe misconfiguration, where devices are physically connected
452 to the same link, but are currently misconfigured with completely
453 unrelated IP addresses and subnet masks.
455 * For responses sent to a unicast destination address, the source IP
456 address in the packet is checked to see if it is an address on a
457 local subnet. An address is determined to be on a local subnet if,
458 for (one of) the address(es) configured on the interface receiving
459 the packet, (I & M) == (P & M), where I and M are the interface
460 address and subnet mask respectively, P is the source IP address
461 from the packet, '&' represents the bitwise logical 'and'
462 operation, and '==' represents a bitwise equality test.
464 Since queriers will ignore responses apparently originating outside
465 the local subnet, responders SHOULD avoid generating responses that
466 it can reasonably predict will be ignored. This applies particularly
467 in the case of overlayed subnets. If a responder receives a query
468 addressed to the link-local multicast address 224.0.0.251, from a
469 source address not apparently on the same subnet as the responder,
470 then even if the query indicates that a unicast response is preferred
471 (see Section 6.5, "Questions Requesting Unicast Responses"), the
472 responder SHOULD elect to respond by multicast anyway, since it can
473 reasonably predict that a unicast response with an apparently
474 non-local source address will probably be ignored.
480 Expires 7th December 2005 Cheshire & Krochmal [Page 8]
482 Internet Draft Multicast DNS 7th June 2005
485 5. Reverse Address Mapping
487 Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also
488 defined to be link-local.
490 Any DNS query for a name ending with "254.169.in-addr.arpa." MUST
491 be sent to the mDNS multicast address 224.0.0.251. Since names under
492 this domain correspond to IPv4 link-local addresses, it is logical
493 that the local link is the best place to find information pertaining
494 to those names. As an optimization, these queries MAY be first
495 unicast directly to the address in question, but if this query is not
496 answered, the query MUST also be sent via multicast, to accommodate
497 the case where the machine in question is not answering for itself
498 (for example, because it is currently sleeping).
500 Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa."
501 MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB,
502 with or without an optional initial query unicast directly to the
508 There are three kinds of Multicast DNS Queries, one-shot queries of
509 the kind made by today's conventional DNS clients, one-shot queries
510 accumulating multiple responses made by multicast-aware DNS clients,
511 and continuous ongoing Multicast DNS Queries used by IP network
514 A Multicast DNS Responder that is offering records that are intended
515 to be unique on the local link MUST also implement a Multicast DNS
516 Querier so that it can first verify the uniqueness of those records
517 before it begins answering queries for them.
522 An unsophisticated DNS client may simply send its DNS queries
523 blindly to the 224.0.0.251 multicast address, without necessarily
524 even being aware what a multicast address is.
526 Such an unsophisticated DNS client may not get ideal behavior. Such
527 a client may simply take the first response it receives and fail to
528 wait to see if there are more, but in many instances this may not be
529 a serious problem. If a user types "http://cheshire.local." into
530 their Web browser and gets to see the page they were hoping for,
531 then the protocol has met the user's needs in this case.
540 Expires 7th December 2005 Cheshire & Krochmal [Page 9]
542 Internet Draft Multicast DNS 7th June 2005
545 6.2 One-Shot Queries, Accumulating Multiple Responses
547 A more sophisticated DNS client should understand that Multicast DNS
548 is not exactly the same as unicast DNS, and should modify its
549 behavior in some simple ways.
551 As described above, there are some cases, such as looking up the
552 address associated with a unique host name, where a single response
553 is sufficient, and moreover may be all that is expected. However,
554 there are other DNS queries where more than one response is
555 possible, and for these queries a more sophisticated Multicast DNS
556 client should include the ability to wait for an appropriate period
557 of time to collect multiple responses.
559 A naive DNS client retransmits its query only so long as it has
560 received no response. A more sophisticated Multicast DNS client is
561 aware that having received one response is not necessarily an
562 indication that it might not receive others, and has the ability to
563 retransmit its query an appropriate number of times at appropriate
564 intervals until it is satisfied with the collection of responses it
567 A more sophisticated Multicast DNS client that is retransmitting
568 a query for which it has already received some responses, MUST
569 implement Known Answer Suppression, as described below in Section
570 7.1. This indicates to responders who have already replied that their
571 responses have been received, and they don't need to send them again
572 in response to this repeated query. In addition, the interval between
573 the first two queries SHOULD be one second, and the intervals between
574 subsequent queries SHOULD double.
577 6.3 Continuous Querying
579 In One-Shot Queries, with either a single or multiple responses,
580 the underlying assumption is that the transaction begins when the
581 application issues a query, and ends when all the desired responses
582 have been received. There is another type of operation which is more
583 akin to continuous monitoring.
585 Macintosh users are accustomed to opening the "Chooser" window,
586 selecting a desired printer, and then closing the Chooser window.
587 However, when the desired printer does not appear in the list, the
588 user will typically leave the "Chooser" window open while they go and
589 check to verify that the printer is plugged in, powered on, connected
590 to the Ethernet, etc. While the user jiggles the wires, hits the
591 Ethernet hub, and so forth, they keep an eye on the Chooser window,
592 and when the printer name appears, they know they have fixed whatever
593 the problem was. This can be a useful and intuitive troubleshooting
594 technique, but a user who goes home for the weekend leaving the
595 Chooser window open places a non-trivial burden on the network.
600 Expires 7th December 2005 Cheshire & Krochmal [Page 10]
602 Internet Draft Multicast DNS 7th June 2005
605 With continuous querying, multiple queries are sent over a long
606 period of time, until the user terminates the operation. It is
607 important that an IP network browser window displaying live
608 information from the network using Multicast DNS, if left running
609 for an extended period of time, should generate significantly less
610 multicast traffic on the network than the old AppleTalk Chooser.
611 Therefore, the interval between the first two queries SHOULD be one
612 second, the intervals between subsequent queries SHOULD double, and
613 the querier MUST implement Known Answer Suppression, as described
614 below in Section 7.1. When the interval between queries reaches or
615 exceeds 60 minutes, a querier MAY cap the interval to a maximum of 60
616 minutes, and perform subsequent queries at a steady-state rate of one
619 When a Multicast DNS Querier receives an answer, the answer contains
620 a TTL value that indicates for how many seconds this answer is valid.
621 After this interval has passed, the answer will no longer be valid
622 and SHOULD be deleted from the cache. Before this time is reached, a
623 Multicast DNS Querier with an ongoing interest in that record SHOULD
624 re-issue its query to determine whether the record is still valid,
625 and if so update its expiry time.
627 To perform this cache maintenance, a Multicast DNS Querier should
628 plan to re-query for records after at least 50% of the record
629 lifetime has elapsed. This document recommends the following
632 The Querier should plan to issue a query at 80% of the record
633 lifetime, and then if no answer is received, at 85%, 90% and 95%. If
634 an answer is received, then the remaining TTL is reset to the value
635 given in the answer, and this process repeats for as long as the
636 Multicast DNS Querier has an ongoing interest in the record. If after
637 four queries no answer is received, the record is deleted when it
638 reaches 100% of its lifetime.
640 To avoid the case where multiple Multicast DNS Queriers on a network
641 all issue their queries simultaneously, a random variation of 2% of
642 the record TTL should be added, so that queries are scheduled to be
643 performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL.
646 6.4 Multiple Questions per Query
648 Multicast DNS allows a querier to place multiple questions in the
649 Question Section of a single Multicast DNS query packet.
651 The semantics of a Multicast DNS query packet containing multiple
652 questions is identical to a series of individual DNS query packets
653 containing one question each. Combining multiple questions into a
654 single packet is purely an efficiency optimization, and has no other
655 semantic significance.
660 Expires 7th December 2005 Cheshire & Krochmal [Page 11]
662 Internet Draft Multicast DNS 7th June 2005
665 A useful technique for adaptively combining multiple questions into a
666 single query is to use a Nagle-style algorithm: When a client issues
667 its first question, a Query packet is immediately built and sent,
668 without delay. If the client then continues issuing a rapid series of
669 questions they are held until either the first query receives at
670 least one answer, or 100ms has passed, or there are enough questions
671 to fill the Question Section of a Multicast DNS query packet. At this
672 time, all the held questions are placed into a Multicast DNS query
675 6.5 Questions Requesting Unicast Responses
677 Sending Multicast DNS responses via multicast has the benefit that
678 all the other hosts on the network get to see those responses, and
679 can keep their caches up to date, and detect conflicting responses.
681 However, there are situations where all the other hosts on the
682 network don't need to see every response. One example is a laptop
683 computer waking from sleep. At that instant it is a brand new
684 participant on a new network. Its Multicast DNS cache is empty, and
685 it has no knowledge of its surroundings. It may have a significant
686 number of queries that it wants answered right away to discover
687 information about its new surroundings and present that information
688 to the user. As a new participant on the network, it has no idea
689 whether the exact same questions may have been asked and answered
690 just seconds ago. In this case, trigging a large sudden flood of
691 multicast responses may impose an unreasonable burden on the network.
692 To avoid this, the Multicast DNS Querier SHOULD set the top bit in
693 the class field of its DNS question(s), to indicate that it is
694 willing to accept unicast responses instead of the usual multicast
695 responses. These questions requesting unicast responses are referred
696 to as "QU" questions, to distinguish them from the more usual
697 questions requesting multicast responses ("QM" questions).
699 When retransmitting a question more than once, the 'unicast response'
700 bit SHOULD be set only for the first question of the series. After
701 the first question has received its responses, the querier should
702 have a large known-answer list (see "Known Answer Suppression" below)
703 so that subsequent queries should elicit few, if any, further
704 responses. Reverting to multicast responses as soon as possible is
705 important because of the benefits that multicast responses provide
706 (see "Benefits of Multicast Responses" below).
708 When receiving a question with the 'unicast response' bit set, a
709 responder SHOULD usually respond with a unicast packet directed back
710 to the querier. If the responder has not multicast that record
711 recently (within one quarter of its TTL), then the responder SHOULD
712 instead multicast the response so as to keep all the peer caches up
713 to date, and to permit passive conflict detection.
715 Unicast replies are subject to all the same packet generation rules
716 as multicast replies, including the cache flush bit (see Section
717 11.3, "Announcements to Flush Outdated Cache Entries") and randomized
718 delays to reduce network collisions (see Section 8, "Responding").
720 Expires 7th December 2005 Cheshire & Krochmal [Page 12]
722 Internet Draft Multicast DNS 7th June 2005
725 6.6 Suppressing Initial Query
727 If a query is issued for which there already exist one or more
728 records in the local cache, and those record(s) were received with
729 the cache flush bit set (see Section 11.3, "Announcements to Flush
730 Outdated Cache Entries"), indicating that they form a unique RRSet,
731 then the host SHOULD suppress its initial "QU" query, and proceed to
732 issue a "QM" query. To avoid the situation where a group of hosts
733 are synchronized by some external event and all perform the same
734 query simultaneously, a host suppressing its initial "QU" query
735 SHOULD impose a random delay from 500-1000ms before transmitting its
736 first "QM" query for this question. This means that when the first
737 host (selected randomly by this algorithm) transmits its "QM" query,
738 all the other hosts that were about to transmit the same query can
739 suppress their superfluous query, as described in "Duplicate
740 Question Suppression" below.
742 7. Duplicate Suppression
744 A variety of techniques are used to reduce the amount of redundant
745 traffic on the network.
747 7.1 Known Answer Suppression
749 When a Multicast DNS Querier sends a query to which it already knows
750 some answers, it populates the Answer Section of the DNS message with
753 A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if
754 the answer it would give is already included in the Answer Section
755 with an RR TTL at least half the correct value. If the RR TTL of the
756 answer as given in the Answer Section is less than half of the true
757 RR TTL as known by the Multicast DNS Responder, the responder MUST
758 send an answer so as to update the Querier's cache before the record
759 becomes in danger of expiration.
761 Because a Multicast DNS Responder will respond if the remaining TTL
762 given in the known answer list is less than half the true TTL, it is
763 superfluous for the Querier to include such records in the known
764 answer list. Therefore a Multicast DNS Querier SHOULD NOT include
765 records in the known answer list whose remaining TTL is less than
766 half their original TTL. Doing so would simply consume space in the
767 packet without achieving the goal of suppressing responses, and would
768 therefore be a pointless waste of network bandwidth.
770 A Multicast DNS Querier MUST NOT cache resource records observed in
771 the Known Answer Section of other Multicast DNS Queries. The Answer
772 Section of Multicast DNS Queries is not authoritative. By placing
773 information in the Answer Section of a Multicast DNS Query the
774 querier is stating that it *believes* the information to be true.
775 It is not asserting that the information *is* true. Some of those
776 records may have come from other hosts that are no longer on the
777 network. Propagating that stale information to other Multicast DNS
778 Queriers on the network would not be helpful.
780 Expires 7th December 2005 Cheshire & Krochmal [Page 13]
782 Internet Draft Multicast DNS 7th June 2005
785 7.2 Multi-Packet Known Answer Suppression
787 Sometimes a Multicast DNS Querier will already have too many answers
788 to fit in the Known Answer Section of its query packets. In this
789 case, it should issue a Multicast DNS Query containing a question and
790 as many Known Answer records as will fit. It MUST then set the TC
791 (Truncated) bit in the header before sending the Query. It MUST then
792 immediately follow the packet with another query packet containing no
793 questions, and as many more Known Answer records as will fit. If
794 there are still too many records remaining to fit in the packet, it
795 again sets the TC bit and continues until all the Known Answer
796 records have been sent.
798 A Multicast DNS Responder seeing a Multicast DNS Query with the TC
799 bit set defers its response for a time period randomly selected in
800 the interval 400-500ms. This gives the Multicast DNS Querier time to
801 send additional Known Answer packets before the Responder responds.
802 If the Responder sees any of its answers listed in the Known Answer
803 lists of subsequent packets from the querying host, it SHOULD delete
804 that answer from the list of answers it is planning to give, provided
805 that no other host on the network is also waiting to receive the same
808 Previous versions of this draft specified a delay of 20-120ms before
809 answering queries with multi-packet Known Answer lists. However,
810 operational experience showed that, while this works well on
811 Ethernet, on very busy 802.11 networks, it is not uncommon to observe
812 consecutively sent packets arriving separated by as much as
816 7.3 Duplicate Question Suppression
818 If a host is planning to send a query, and it sees another host on
819 the network send a query containing the same question, and the Known
820 Answer Section of that query does not contain any records which this
821 host would not also put in its own Known Answer Section, then this
822 host should treat its own query as having been sent. When multiple
823 clients on the network are querying for the same resource records,
824 there is no need for them to all be repeatedly asking the same
828 7.4 Duplicate Answer Suppression
830 If a host is planning to send an answer, and it sees another host on
831 the network send a response packet containing the same answer record,
832 and the TTL in that record is not less than the TTL this host would
833 have given, then this host should treat its own answer as having been
834 sent. When multiple responders on the network have the same data,
835 there is no need for all of them to respond.
840 Expires 7th December 2005 Cheshire & Krochmal [Page 14]
842 Internet Draft Multicast DNS 7th June 2005
845 This feature is particularly useful when multiple Sleep Proxy Servers
846 are deployed (see Section 16, "Multicast DNS and Power Management").
847 In the future it is possible that every general-purpose OS (Mac,
848 Windows, Linux, etc.) will implement Sleep Proxy Service as a matter
849 of course. In this case there could be a large number of Sleep Proxy
850 Servers on any given network, which is good for reliability and
851 fault-tolerance, but would be bad for the network if every Sleep
852 Proxy Server were to answer every query.
857 When a Multicast DNS Responder constructs and sends a Multicast DNS
858 response packet, the Answer Section of that packet must contain only
859 records for which that Responder is explicitly authoritative. These
860 answers may be generated because the record answers a question
861 received in a Multicast DNS query packet, or at certain other times
862 that the responder determines than an unsolicited announcement is
863 warranted. A Multicast DNS Responder MUST NOT place records from its
864 cache, which have been learned from other responders on the network,
865 in the Answer Section of outgoing response packets. Only an
866 authoritative source for a given record is allowed to issue responses
867 containing that record.
869 The determination of whether a given record answers a given question
870 is done using the standard DNS rules: The record name must match the
871 question name, the record rrtype must match the question qtype
872 (unless the qtype is "ANY"), and the record rrclass must match the
873 question qclass (unless the qclass is "ANY").
875 A Multicast DNS Responder MUST only respond when it has a positive
876 non-null response to send. Error responses must never be sent. The
877 non-existence of any name in a Multicast DNS Domain is ascertained by
878 the failure of any machine to respond to the Multicast DNS query, not
881 Multicast DNS Responses MUST NOT contain any questions in the
882 Question Section. Any questions in the Question Section of a received
883 Multicast DNS Response MUST be silently ignored. Multicast DNS
884 Queriers receiving Multicast DNS Responses do not care what question
885 elicited the response; they care only that the information in the
886 response is true and accurate.
888 A Multicast DNS Responder on Ethernet [IEEE802] and similar shared
889 multiple access networks SHOULD have the capability of delaying its
890 responses by up to 500ms, as determined by the rules described below.
891 If multiple Multicast DNS Responders were all to respond immediately
892 to a particular query, a collision would be virtually guaranteed. By
893 imposing a small random delay, the number of collisions is
894 dramatically reduced. On a full-sized Ethernet using the maximum
895 cable lengths allowed and the maximum number of repeaters allowed, an
896 Ethernet frame is vulnerable to collisions during the transmission of
897 its first 256 bits. On 10Mb/s Ethernet, this equates to a vulnerable
900 Expires 7th December 2005 Cheshire & Krochmal [Page 15]
902 Internet Draft Multicast DNS 7th June 2005
905 time window of 25.6us. On higher-speed variants of Ethernet, the
906 vulnerable time window is shorter.
908 In the case where a Multicast DNS Responder has good reason to
909 believe that it will be the only responder on the link with a
910 positive non-null response, it SHOULD NOT impose any random delay
911 before responding, and SHOULD normally generate its response within
912 at most 10ms. In particular, this applies to responding to probe
913 queries. Since receiving a probe query gives a clear indication that
914 some other Responder is planning to start using this name in the very
915 near future, answering such probe queries to defend a unique record
916 is a high priority and needs to be done immediately, without delay. A
917 probe query can be distinguished from a normal query by the fact that
918 a probe query contains a proposed record in the Authority Section
919 which answers the question in the Question Section (for more details,
920 see Section 9.1, "Probing").
922 To generate immediate responses safely, it MUST have previously
923 verified that the requested name, rrtype and rrclass in the DNS query
924 are unique on this link. Responding immediately without delay is
925 appropriate for things like looking up the address record for a
926 particular host name, when the host name has been previously verified
927 unique. Responding immediately without delay is *not* appropriate for
928 things like looking up PTR records used for DNS Service Discovery
929 [DNS-SD], where a large number of responses may be anticipated.
931 In any case where there may be multiple responses, such as queries
932 where the answer is a member of a shared resource record set, each
933 responder SHOULD delay its response by a random amount of time
934 selected with uniform random distribution in the range 20-120ms.
936 In the case where the query has the TC (truncated) bit set,
937 indicating that subsequent known answer packets will follow,
938 responders SHOULD delay their responses by a random amount of time
939 selected with uniform random distribution in the range 400-500ms,
940 to allow enough time for all the known answer packets to arrive.
942 Except when a unicast reply has been explicitly requested via the
943 "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port
944 5353 (the well-known port assigned to mDNS) on the 224.0.0.251
945 multicast address (or its IPv6 equivalent FF02::FB). Operating in a
946 Zeroconf environment requires constant vigilance. Just because a name
947 has been previously verified unique does not mean it will continue to
948 be so indefinitely. By allowing all Multicast DNS Responders to
949 constantly monitor their peers' responses, conflicts arising out of
950 network topology changes can be promptly detected and resolved.
952 Sending all responses by multicast also facilitates opportunistic
953 caching by other hosts on the network.
955 To protect the network against excessive packet flooding due to
956 software bugs or malicious attack, a Multicast DNS Responder MUST NOT
957 multicast a given record on a given interface if it has previously
960 Expires 7th December 2005 Cheshire & Krochmal [Page 16]
962 Internet Draft Multicast DNS 7th June 2005
965 multicast that record on that interface within the last second. A
966 legitimate client on the network should have seen the previous
967 transmission and cached it. A client that did not receive and cache
968 the previous transmission will retry its request and receive a
969 subsequent response. Under no circumstances is there any legitimate
970 reason for a Multicast DNS Responder to multicast a given record more
971 than once per second on any given interface.
974 8.1 Legacy Unicast Responses
976 If the source UDP port in a received Multicast DNS Query is not port
977 5353, this indicates that the client originating the query is a
978 simple client that does not fully implement all of Multicast DNS. In
979 this case, the Multicast DNS Responder MUST send a UDP response
980 directly back to the client, via unicast, to the query packet's
981 source IP address and port. This unicast response MUST be a
982 conventional unicast response as would be generated by a conventional
983 unicast DNS server; for example, it MUST repeat the query ID and the
984 question given in the query packet.
986 The resource record TTL given in a legacy unicast response SHOULD NOT
987 be greater than ten seconds, even if the true TTL of the Multicast
988 DNS resource record is higher. This is because Multicast DNS
989 Responders that fully participate in the protocol use the cache
990 coherency mechanisms described in Section 13 to update and invalidate
991 stale data. Were unicast responses sent to legacy clients to use the
992 same high TTLs, these legacy clients, which do not implement these
993 cache coherency mechanisms, could retain stale cached resource record
994 data long after it is no longer valid.
996 Having sent this unicast response, if the Responder has not sent this
997 record in any multicast response recently, it SHOULD schedule the
998 record to be sent via multicast as well, to facilitate passive
999 conflict detection. "Recently" in this context means "if the time
1000 since the record was last sent via multicast is less than one quarter
1001 of the record's TTL".
1004 8.2 Multi-Question Queries
1006 Multicast DNS Responders MUST correctly handle DNS query packets
1007 containing more than one question, by answering any or all of the
1008 questions to which they have answers. Any (non-defensive) answers
1009 generated in response to query packets containing more than one
1010 question SHOULD be randomly delayed in the range 20-120ms, or
1011 400-500ms if the TC (truncated) bit is set, as described above.
1012 (Answers defending a name, in response to a probe for that name,
1013 are not subject to this delay rule and are still sent immediately.)
1020 Expires 7th December 2005 Cheshire & Krochmal [Page 17]
1022 Internet Draft Multicast DNS 7th June 2005
1025 8.3 Response Aggregation
1027 When possible, a responder SHOULD, for the sake of network
1028 efficiency, aggregate as many responses as possible into a single
1029 Multicast DNS response packet. For example, when a responder has
1030 several responses it plans to send, each delayed by a different
1031 interval, then earlier responses SHOULD be delayed by up to an
1032 additional 500ms if that will permit them to be aggregated with
1033 other responses scheduled to go out a little later.
1036 9. Probing and Announcing on Startup
1038 Typically a Multicast DNS Responder should have, at the very least,
1039 address records for all of its active interfaces. Creating and
1040 advertising an HINFO record on each interface as well can be useful
1041 to network administrators.
1043 Whenever a Multicast DNS Responder starts up, wakes up from sleep,
1044 receives an indication of an Ethernet "Link Change" event, or has any
1045 other reason to believe that its network connectivity may have
1046 changed in some relevant way, it MUST perform the two startup steps
1052 The first startup step is that for all those resource records that a
1053 Multicast DNS Responder desires to be unique on the local link, it
1054 MUST send a Multicast DNS Query asking for those resource records, to
1055 see if any of them are already in use. The primary example of this is
1056 its address record which maps its unique host name to its unique IP
1057 address. All Probe Queries SHOULD be done using the desired resource
1058 record name and query type T_ANY (255), to elicit answers for all
1059 types of records with that name. This allows a single question to be
1060 used in place of several questions, which is more efficient on the
1061 network. It also allows a host to verify exclusive ownership of a
1062 name, which is desirable in most cases. It would be confusing, for
1063 example, if one host owned the "A" record for "myhost.local.", but a
1064 different host owned the HINFO record for that name.
1066 The ability to place more than one question in a Multicast DNS Query
1067 is useful here, because it can allow a host to use a single packet
1068 for all of its resource records instead of needing a separate packet
1069 for each. For example, a host can simultaneously probe for uniqueness
1070 of its "A" record and all its SRV records [DNS-SD] in the same query
1073 When ready to send its mDNS probe packet(s) the host should first
1074 wait for a short random delay time, uniformly distributed in the
1075 range 0-250ms. This random delay is to guard against the case where a
1076 group of devices are powered on simultaneously, or a group of devices
1077 are connected to an Ethernet hub which is then powered on, or some
1080 Expires 7th December 2005 Cheshire & Krochmal [Page 18]
1082 Internet Draft Multicast DNS 7th June 2005
1085 other external event happens that might cause a group of hosts to all
1086 send synchronized probes.
1088 250ms after the first query the host should send a second, then
1089 250ms after that a third. If, by 250ms after the third probe, no
1090 conflicting Multicast DNS responses have been received, the host may
1091 move to the next step, announcing. (Note that this is the one
1092 exception from the normal rule that there should be at least one
1093 second between repetitions of the same question, and the interval
1094 between subsequent repetitions should double.)
1096 If any conflicting Multicast DNS responses are received, then the
1097 probing host MUST defer to the existing host, and MUST choose new
1098 names for some or all of its resource records as appropriate, to
1099 avoid conflict with pre-existing hosts on the network. In the case
1100 of a host probing using query type T_ANY as recommended above, any
1101 answer containing a record with that name, of any type, MUST be
1102 considered a conflicting response and handled accordingly.
1104 If fifteen failures occur within any ten-second period, then the host
1105 MUST wait at least five seconds before each successive additional
1106 probe attempt. This is to help ensure that in the event of software
1107 bugs or other unanticipated problems, errant hosts do not flood the
1108 network with a continuous stream of multicast traffic. For very
1109 simple devices, a valid way to comply with this requirement is to
1110 always wait five seconds after any failed probe attempt.
1112 If a responder knows by other means, with absolute certainty, that
1113 its unique resource record set name, rrtype and rrclass cannot
1114 already be in use by any other responder on the network, then it MAY
1115 skip the probing step for that resource record set. For example, when
1116 creating the reverse address mapping PTR records, the host can
1117 reasonably assume that no other host will be trying to create those
1118 same PTR records, since that would imply that the two hosts were
1119 trying to use the same IP address, and if that were the case, the two
1120 hosts would be suffering communication problems beyond the scope of
1121 what Multicast DNS is designed to solve.
1124 9.2 Simultaneous Probe Tie-Breaking
1126 The astute reader will observe that there is a race condition
1127 inherent in the previous description. If two hosts are probing for
1128 the same name simultaneously, neither will receive any response to
1129 the probe, and the hosts could incorrectly conclude that they may
1130 both proceed to use the name. To break this symmetry, each host
1131 populates the Authority Section of its queries with records giving
1132 the rdata that it would be proposing to use, should its probing be
1133 successful. The Authority Section is being used here in a way
1134 analogous to the Update Section of a DNS Update packet [RFC 2136].
1136 When a host that is probing for a record sees another host issue a
1137 query for the same record, it consults the Authority Section of that
1140 Expires 7th December 2005 Cheshire & Krochmal [Page 19]
1142 Internet Draft Multicast DNS 7th June 2005
1145 query. If it finds any resource record there which answers the query,
1146 then it compares the data of that resource record with its own
1147 tentative data. The lexicographically later data wins. This means
1148 that if the host finds that its own data is lexicographically later,
1149 it simply ignores the other host's probe. If the host finds that its
1150 own data is lexicographically earlier, then it treats this exactly
1151 as if it had received a positive answer to its query, and concludes
1152 that it may not use the desired name.
1154 The determination of 'lexicographically later' is performed by first
1155 comparing the record class, then the record type, then raw comparison
1156 of the binary content of the rdata without regard for meaning or
1157 structure. If the record classes differ, then the numerically greater
1158 class is considered 'lexicographically later'. Otherwise, if the
1159 record types differ, then the numerically greater type is considered
1160 'lexicographically later'. If the rrtype and rrclass both match then
1161 the rdata is compared.
1163 In the case of resource records containing rdata that is subject to
1164 name compression, the names MUST be uncompressed before comparison.
1165 (The details of how a particular name is compressed is an artifact of
1166 how and where the record is written into the DNS message; it is not
1167 an intrinsic property of the resource record itself.)
1169 The bytes of the raw uncompressed rdata are compared in turn,
1170 interpreting the bytes as eight-bit UNSIGNED values, until a byte
1171 is found whose value is greater than that of its counterpart (in
1172 which case the rdata whose byte has the greater value is deemed
1173 lexicographically later) or one of the resource records runs out
1174 of rdata (in which case the resource record which still has
1175 remaining data first is deemed lexicographically later).
1177 The following is an example of a conflict:
1179 cheshire.local. A 169.254.99.200
1180 cheshire.local. A 169.254.200.50
1182 In this case 169.254.200.50 is lexicographically later (the third
1183 byte, with value 200, is greater than its counterpart with value 99),
1184 so it is deemed the winner.
1186 Note that it is vital that the bytes are interpreted as UNSIGNED
1187 values, or the wrong outcome may result. In the example above, if
1188 the byte with value 200 had been incorrectly interpreted as a
1189 signed value then it would be interpreted as value -56, and the
1190 wrong address record would be deemed the winner.
1195 The second startup step is that the Multicast DNS Responder MUST send
1196 a gratuitous Multicast DNS Response containing, in the Answer
1197 Section, all of its resource records (both shared records, and unique
1200 Expires 7th December 2005 Cheshire & Krochmal [Page 20]
1202 Internet Draft Multicast DNS 7th June 2005
1205 records that have completed the probing step). If there are too many
1206 resource records to fit in a single packet, multiple packets should
1209 In the case of shared records (e.g. the PTR records used by DNS
1210 Service Discovery [DNS-SD]), the records are simply placed as-is
1211 into the Answer Section of the DNS Response.
1213 In the case of records that have been verified to be unique in the
1214 previous step, they are placed into the Answer Section of the DNS
1215 Response with the most significant bit of the rrclass set to one.
1216 The most significant bit of the rrclass for a record in the Answer
1217 Section of a response packet is the mDNS "cache flush" bit and is
1218 discussed in more detail below in Section 11.3 "Announcements to
1219 Flush Outdated Cache Entries".
1221 The Multicast DNS Responder MUST send at least two gratuitous
1222 responses, one second apart. A Responder MAY send up to ten
1223 gratuitous Responses, provided that the interval between gratuitous
1224 responses doubles with every response sent.
1226 A Multicast DNS Responder SHOULD NOT continue sending gratuitous
1227 Responses for longer than the TTL of the record. The purpose of
1228 announcing new records via gratuitous Responses is to ensure that
1229 peer caches are up to date. After a time interval equal to the TTL of
1230 the record has passed, it is very likely that old stale copies of
1231 that record in peer caches will have expired naturally, so subsequent
1232 announcements serve little purpose.
1234 A Multicast DNS Responder MUST NOT send announcements in the absence
1235 of information that its network connectivity may have changed in some
1236 relevant way. In particular, a Multicast DNS Responder MUST NOT send
1237 regular periodic announcements as a matter of course.
1239 Whenever a Multicast DNS Responder receives any Multicast DNS
1240 response (gratuitous or otherwise) containing a conflicting resource
1241 record, the conflict MUST be resolved as described below in "Conflict
1246 At any time, if the rdata of any of a host's Multicast DNS records
1247 changes, the host MUST repeat the Announcing step described above to
1248 update neighboring caches. For example, if any of a host's IP
1249 addresses change, it MUST re-announce those address records.
1251 In the case of shared records, a host MUST send a 'goodbye'
1252 announcement with TTL zero (see Section 11.2 "Goodbye Packets")
1253 for the old rdata, to cause it to be deleted from peer caches,
1254 before announcing the new rdata. In the case of unique records,
1255 a host SHOULD omit the 'goodbye' announcement, since the cache
1256 flush bit on the newly announced records will cause old rdata
1257 to be flushed from peer caches anyway.
1260 Expires 7th December 2005 Cheshire & Krochmal [Page 21]
1262 Internet Draft Multicast DNS 7th June 2005
1265 A host may update the contents of any of its records at any time,
1266 though a host SHOULD NOT update records more frequently than ten
1267 times per minute. Frequent rapid updates impose a burden on the
1268 network. If a host has information to disseminate which changes more
1269 frequently than ten times per minute, then it may be more appropriate
1270 to design a protocol for that specific purpose.
1273 10. Conflict Resolution
1275 A conflict occurs when a Multicast DNS Responder has a unique record
1276 for which it is authoritative, and it receives, in the Answer Section
1277 of a Multicast DNS response another record with the same name, rrtype
1278 and rrclass, but inconsistent rdata. What may be considered
1279 inconsistent is context sensitive, except that resource records with
1280 identical rdata are never considered inconsistent, even if they
1281 originate from different hosts. This is to permit use of proxies and
1282 other fault-tolerance mechanisms that may cause more than one
1283 responder to be capable of issuing identical answers on the network.
1285 A common example of a resource record type that is intended to be
1286 unique, not shared between hosts, is the address record that maps a
1287 host's name to its IP address. Should a host witness another host
1288 announce an address record with the same name but a different IP
1289 address, then that is considered inconsistent, and that address
1290 record is considered to be in conflict.
1292 Whenever a Multicast DNS Responder receives any Multicast DNS
1293 response (gratuitous or otherwise) containing a conflicting resource
1294 record in the Answer Section, the Multicast DNS Responder MUST
1295 immediately reset its conflicted unique record to probing state, and
1296 go through the startup steps described above in Section 9. "Probing
1297 and Announcing on Startup". The protocol used in the Probing phase
1298 will determine a winner and a loser, and the loser MUST cease using
1299 the name, and reconfigure.
1301 It is very important that any host receiving a resource record that
1302 conflicts with one of its own MUST take action as described above.
1303 In the case of two hosts using the same host name, where one has been
1304 configured to require a unique host name and the other has not, the
1305 one that has not been configured to require a unique host name will
1306 not perceive any conflict, and will not take any action. By reverting
1307 to Probing state, the host that desires a unique host name will go
1308 through the necessary steps to ensure that a unique host is obtained.
1310 The recommended course of action after probing and failing is as
1313 o Programmatically change the resource record name in an attempt to
1314 find a new name that is unique. This could be done by adding some
1315 further identifying information (e.g. the model name of the
1316 hardware) if it is not already present in the name, appending the
1317 digit "2" to the name, or incrementing a number at the end of the
1318 name if one is already present.
1320 Expires 7th December 2005 Cheshire & Krochmal [Page 22]
1322 Internet Draft Multicast DNS 7th June 2005
1325 o Probe again, and repeat until a unique name is found.
1327 o Record this newly chosen name in persistent storage so that the
1328 device will use the same name the next time it is power-cycled.
1330 o Display a message to the user or operator informing them of the
1331 name change. For example:
1333 The name "Bob's Music" is in use by another iTunes music
1334 server on the network. Your music has been renamed to
1335 "Bob's Music (G4 Cube)". If you want to change this name,
1336 use [describe appropriate menu item or preference dialog].
1338 How the user or operator is informed depends on context. A desktop
1339 computer with a screen might put up a dialog box. A headless server
1340 in the closet may write a message to a log file, or use whatever
1341 mechanism (email, SNMP trap, etc.) it uses to inform the
1342 administrator of other error conditions. On the other hand a headless
1343 server in the closet may not inform the user at all -- if the user
1344 cares, they will notice the name has changed, and connect to the
1345 server in the usual way (e.g. via Web Browser) to configure a new
1348 The examples in this section focus on address records (i.e. host
1349 names), but the same considerations apply to all resource records
1350 where uniqueness (or maintenance of some other defined constraint)
1355 11. Resource Record TTL Values and Cache Coherency
1357 As a general rule, the recommended TTL value for Multicast DNS
1358 resource records with a host name as the resource record's name
1359 (e.g. A, AAAA, HINFO, etc.) or contained within the resource record's
1360 rdata (e.g. SRV, reverse mapping PTR record, etc.) is 120 seconds.
1362 The recommended TTL value for other Multicast DNS resource records
1365 A client with an active outstanding query will issue a query packet
1366 when one or more of the resource record(s) in its cache is (are) 80%
1367 of the way to expiry. If the TTL on those records is 75 minutes,
1368 this ongoing cache maintenance process yields a steady-state query
1369 rate of one query every 60 minutes.
1371 Any distributed cache needs a cache coherency protocol. If Multicast
1372 DNS resource records follow the recommendation and have a TTL of 75
1373 minutes, that means that stale data could persist in the system for
1374 a little over an hour. Making the default TTL significantly lower
1375 would reduce the lifetime of stale data, but would produce too much
1376 extra traffic on the network. Various techniques are available to
1377 minimize the impact of such stale data.
1380 Expires 7th December 2005 Cheshire & Krochmal [Page 23]
1382 Internet Draft Multicast DNS 7th June 2005
1385 11.1 Cooperating Multicast DNS Responders
1387 If a Multicast DNS Responder ("A") observes some other Multicast DNS
1388 Responder ("B") send a Multicast DNS Response packet containing a
1389 resource record with the same name, rrtype and rrclass as one of A's
1390 resource records, but different rdata, then:
1392 o If A's resource record is intended to be a shared resource record,
1393 then this is no conflict, and no action is required.
1395 o If A's resource record is intended to be a member of a unique
1396 resource record set owned solely by that responder, then this
1397 is a conflict and MUST be handled as described in Section 10
1398 "Conflict Resolution".
1400 If a Multicast DNS Responder ("A") observes some other Multicast DNS
1401 Responder ("B") send a Multicast DNS Response packet containing a
1402 resource record with the same name, rrtype and rrclass as one of A's
1403 resource records, and identical rdata, then:
1405 o If the TTL of B's resource record given in the packet is at least
1406 half the true TTL from A's point of view, then no action is
1409 o If the TTL of B's resource record given in the packet is less than
1410 half the true TTL from A's point of view, then A MUST mark its
1411 record to be announced via multicast. Clients receiving the record
1412 from B would use the TTL given by B, and hence may delete the
1413 record sooner than A expects. By sending its own multicast response
1414 correcting the TTL, A ensures that the record will be retained for
1417 These rules allow multiple Multicast DNS Responders to offer the same
1418 data on the network (perhaps for fault tolerance reasons) without
1419 conflicting with each other.
1422 11.2 Goodbye Packets
1424 In the case where a host knows that certain resource record data is
1425 about to become invalid (for example when the host is undergoing a
1426 clean shutdown) the host SHOULD send a gratuitous announcement mDNS
1427 response packet, giving the same resource record name, rrtype,
1428 rrclass and rdata, but an RR TTL of zero. This has the effect of
1429 updating the TTL stored in neighboring hosts' cache entries to zero,
1430 causing that cache entry to be promptly deleted.
1432 Clients receiving a Multicast DNS Response with a TTL of zero SHOULD
1433 NOT immediately delete the record from the cache, but instead record
1434 a TTL of 1 and then delete the record one second later. In the case
1435 of multiple Multicast DNS Responders on the network described in
1436 Section 11.1 above, if one of the Responders shuts down and
1437 incorrectly sends goodbye packets for its records, it gives the other
1440 Expires 7th December 2005 Cheshire & Krochmal [Page 24]
1442 Internet Draft Multicast DNS 7th June 2005
1445 cooperating Responders one second to send out their own response to
1446 "rescue" the records before they expire and are deleted.
1448 Generally speaking, it is more important to send goodbye packets for
1449 shared records than unique records. A given shared record name (such
1450 as a PTR record used for DNS Service Discovery [DNS-SD]) by its
1451 nature often has many representatives from many different hosts, and
1452 tends to be the subject of long-lived ongoing queries. Those
1453 long-lived queries are often concerned not just about being informed
1454 when records appear, but also about being informed if those records
1455 vanish again. In contrast, a unique record set (such as an SRV
1456 record, or a host address record), by its nature, often has far fewer
1457 members than a shared record set, and is usually the subject of
1458 one-shot queries which simply retrieve the data and then cease
1459 querying once they have the answer they are seeking. Therefore,
1460 sending a goodbye packet for a unique record set is likely to offer
1461 less benefit, because it is likely at any given moment that no one
1462 has an active query running for that record set. One example where
1463 goodbye packets for SRV and address records are useful is when
1464 transferring control to a Sleep Proxy Server (see Section 16,
1465 "Multicast DNS and Power Management").
1468 11.3 Announcements to Flush Outdated Cache Entries
1470 Whenever a host has a resource record with potentially new data (e.g.
1471 after rebooting, waking from sleep, connecting to a new network link,
1472 changing IP address, etc.), the host MUST send a series of gratuitous
1473 announcements to update cache entries in its neighbor hosts. In
1474 these gratuitous announcements, if the record is one that is intended
1475 to be unique, the host sets the most significant bit of the rrclass
1476 field of the resource record. This bit, the "cache flush" bit, tells
1477 neighboring hosts that this is not a shared record type. Instead of
1478 merging this new record additively into the cache in addition to any
1479 previous records with the same name, rrtype and rrclass, all old
1480 records with that name, type and class that were received more than
1481 one second ago are declared invalid, and marked to expire from the
1482 cache in one second.
1484 The semantics of the cache flush bit are as follows: Normally when a
1485 resource record appears in the Answer Section of the DNS Response, it
1486 means, "This is an assertion that this information is true." When a
1487 resource record appears in the Answer Section of the DNS Response
1488 with the "cache flush" bit set, it means, "This is an assertion that
1489 this information is the truth and the whole truth, and anything you
1490 may have heard more than a second ago regarding records of this
1491 name/rrtype/rrclass is no longer valid".
1493 To accommodate the case where the set of records from one host
1494 constituting a single unique RRSet is too large to fit in a single
1495 packet, only cache records that are more than one second old are
1496 flushed. This allows the announcing host to generate a quick burst of
1497 packets back-to-back on the wire containing all the members
1500 Expires 7th December 2005 Cheshire & Krochmal [Page 25]
1502 Internet Draft Multicast DNS 7th June 2005
1505 of the RRSet. When receiving records with the "cache flush" bit set,
1506 all records older than one second are marked to be deleted one second
1507 in the future. One second after the end of the little packet burst,
1508 any records not represented within that packet burst will then be
1509 expired from all peer caches.
1511 Any time a host sends a response packet containing some members of a
1512 unique RRSet, it SHOULD send the entire RRSet, preferably in a single
1513 packet, or if the entire RRSet will not fit in a single packet, in a
1514 quick burst of packets sent as close together as possible. The host
1515 SHOULD set the cache flush bit on all members of the unique RRSet.
1516 In the event that for some reason the host chooses not to send the
1517 entire unique RRSet in a single packet or a rapid packet burst,
1518 it MUST NOT set the cache flush bit on any of those records.
1520 The reason for waiting one second before deleting stale records from
1521 the cache is to accommodate bridged networks. For example, a host's
1522 address record announcement on a wireless interface may be bridged
1523 onto a wired Ethernet, and cause that same host's Ethernet address
1524 records to be flushed from peer caches. The one-second delay gives
1525 the host the chance to see its own announcement arrive on the wired
1526 Ethernet, and immediately re-announce its Ethernet interface's
1527 address records so that both sets remain valid and live in peer
1530 These rules apply regardless of *why* the response packet is being
1531 generated. They apply to startup announcements as described in
1532 Section 9.3, and to responses generated as a result of receiving
1535 The "cache flush" bit is only set in records in the Answer Section of
1536 Multicast DNS responses sent to UDP port 5353. The "cache flush" bit
1537 MUST NOT be set in any resource records in a response packet sent in
1538 legacy unicast responses to UDP ports other than 5353.
1540 The "cache flush" bit MUST NOT be set in any resource records in the
1541 known-answer list of any query packet.
1543 The "cache flush" bit MUST NOT ever be set in any shared resource
1544 record. To do so would cause all the other shared versions of this
1545 resource record with different rdata from different Responders to be
1546 immediately deleted from all the caches on the network.
1548 The "cache flush" bit does apply to questions listed in the Question
1549 Section of a Multicast DNS packet. The top bit of the rrclass field
1550 in questions is used for an entirely different purpose (see Section
1551 6.5, "Questions Requesting Unicast Responses").
1553 Note that the "cache flush" bit is NOT part of the resource record
1554 class. The "cache flush" bit is the most significant bit of the
1555 second 16-bit word of a resource record in the Answer Section of
1556 an mDNS packet (the field conventionally referred to as the rrclass
1557 field), and the actual resource record class is the least-significant
1560 Expires 7th December 2005 Cheshire & Krochmal [Page 26]
1562 Internet Draft Multicast DNS 7th June 2005
1565 fifteen bits of this field. There is no mDNS resource record class
1566 0x8001. The value 0x8001 in the rrclass field of a resource record in
1567 an mDNS response packet indicates a resource record with class 1,
1568 with the "cache flush" bit set. When receiving a resource record with
1569 the "cache flush" bit set, implementations should take care to mask
1570 off that bit before storing the resource record in memory.
1573 11.4 Cache Flush on Topology change
1575 If the hardware on a given host is able to indicate physical changes
1576 of connectivity, then when the hardware indicates such a change, the
1577 host should take this information into account in its mDNS cache
1578 management strategy. For example, a host may choose to immediately
1579 flush all cache records received on a particular interface when that
1580 cable is disconnected. Alternatively, a host may choose to adjust the
1581 remaining TTL on all those records to a few seconds so that if the
1582 cable is not reconnected quickly, those records will expire from the
1585 Likewise, when a host reboots, or wakes from sleep, or undergoes some
1586 other similar discontinuous state change, the cache management
1587 strategy should take that information into account.
1590 11.5 Cache Flush on Failure Indication
1592 Sometimes a cache record can be determined to be stale when a client
1593 attempts to use the rdata it contains, and finds that rdata to be
1596 For example, the rdata in an address record can be determined to be
1597 incorrect if attempts to contact that host fail, either because
1598 ARP/ND requests for that address go unanswered (for an address on a
1599 local subnet) or because a router returns an ICMP "Host Unreachable"
1600 error (for an address on a remote subnet).
1602 The rdata in an SRV record can be determined to be incorrect if
1603 attempts to communicate with the indicated service at the host and
1604 port number indicated are not successful.
1606 The rdata in a DNS-SD PTR record can be determined to be incorrect if
1607 attempts to look up the SRV record it references are not successful.
1609 In any such case, the software implementing the mDNS resource record
1610 cache should provide a mechanism so that clients detecting stale
1611 rdata can inform the cache.
1613 When the cache receives this hint that it should reconfirm some
1614 record, it MUST issue two or more queries for the resource record in
1615 question. If no response is received in a reasonable amount of time,
1616 then, even though its TTL may indicate that it is not yet due to
1617 expire, that record SHOULD be promptly flushed from the cache.
1620 Expires 7th December 2005 Cheshire & Krochmal [Page 27]
1622 Internet Draft Multicast DNS 7th June 2005
1625 The end result of this is that if a printer suffers a sudden power
1626 failure or other abrupt disconnection from the network, its name may
1627 continue to appear in DNS-SD browser lists displayed on users'
1628 screens. Eventually that entry will expire from the cache naturally,
1629 but if a user tries to access the printer before that happens, the
1630 failure to successfully contact the printer will trigger the more
1631 hasty demise of its cache entries. This is a sensible trade-off
1632 between good user-experience and good network efficiency. If we were
1633 to insist that printers should disappear from the printer list within
1634 30 seconds of becoming unavailable, for all failure modes, the only
1635 way to achieve this would be for the client to poll the printer at
1636 least every 30 seconds, or for the printer to announce its presence
1637 at least every 30 seconds, both of which would be an unreasonable
1638 burden on most networks.
1641 11.6 Passive Observation of Failures
1643 A host observes the multicast queries issued by the other hosts on
1644 the network. One of the major benefits of also sending responses
1645 using multicast is that it allows all hosts to see the responses (or
1646 lack thereof) to those queries.
1648 If a host sees queries, for which a record in its cache would be
1649 expected to be given as an answer in a multicast response, but no
1650 such answer is seen, then the host may take this as an indication
1651 that the record may no longer be valid.
1653 After seeing two or more of these queries, and seeing no multicast
1654 response containing the expected answer within a reasonable amount of
1655 time, then even though its TTL may indicate that it is not yet due to
1656 expire, that record MAY be flushed from the cache. The host SHOULD
1657 NOT perform its own queries to re-confirm that the record is truly
1658 gone. If every host on a large network were to do this, it would
1659 cause a lot of unnecessary multicast traffic. If host A sends
1660 multicast queries that remain unanswered, then there is no reason to
1661 suppose that host B or any other host is likely to be any more
1664 The previous section, "Cache Flush on Failure Indication", describes
1665 a situation where a user trying to print discovers that the printer
1666 is no longer available. By implementing the passive observation
1667 described here, when one user fails to contact the printer, all hosts
1668 on the network observe that failure and update their caches
1672 12. Special Characteristics of Multicast DNS Domains
1674 Unlike conventional DNS names, names that end in ".local.",
1675 "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local
1676 significance. Conventional DNS seeks to provide a single unified
1677 namespace, where a given DNS query yields the same answer no matter
1680 Expires 7th December 2005 Cheshire & Krochmal [Page 28]
1682 Internet Draft Multicast DNS 7th June 2005
1685 where on the planet it is performed or to which recursive DNS server
1686 the query is sent. (However, split views, firewalls, intranets and
1687 the like have somewhat interfered with this goal of DNS representing
1688 a single universal truth.) In contrast, each IP link has its own
1689 private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa."
1690 namespaces, and the answer to any query for a name within those
1691 domains depends on where that query is asked.
1693 Multicast DNS Domains are not delegated from their parent domain via
1694 use of NS records. There are no NS records anywhere in Multicast DNS
1695 Domains. Instead, all Multicast DNS Domains are delegated to the IP
1696 addresses 224.0.0.251 and FF02::FB by virtue of the individual
1697 organizations producing DNS client software deciding how to handle
1698 those names. It would be extremely valuable for the industry if this
1699 special handling were ratified and recorded by IANA, since otherwise
1700 the special handling provided by each vendor is likely to be
1703 The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The
1704 IPv6 name server for a Multicast DNS Domain is FF02::FB. These are
1705 multicast addresses; therefore they identify not a single host but a
1706 collection of hosts, working in cooperation to maintain some
1707 reasonable facsimile of a competently managed DNS zone. Conceptually
1708 a Multicast DNS Domain is a single DNS zone, however its server is
1709 implemented as a distributed process running on a cluster of loosely
1710 cooperating CPUs rather than as a single process running on a single
1713 No delegation is performed within Multicast DNS Domains. Because the
1714 cluster of loosely coordinated CPUs is cooperating to administer a
1715 single zone, delegation is neither necessary nor desirable. Just
1716 because a particular host on the network may answer queries for a
1717 particular record type with the name "example.local." does not imply
1718 anything about whether that host will answer for the name
1719 "child.example.local.", or indeed for other record types with the
1720 name "example.local."
1722 Multicast DNS Zones have no SOA record. A conventional DNS zone's
1723 SOA record contains information such as the email address of the zone
1724 administrator and the monotonically increasing serial number of the
1725 last zone modification. There is no single human administrator for
1726 any given Multicast DNS Zone, so there is no email address. Because
1727 the hosts managing any given Multicast DNS Zone are only loosely
1728 coordinated, there is no readily available monotonically increasing
1729 serial number to determine whether or not the zone contents have
1730 changed. A host holding part of the shared zone could crash or be
1731 disconnected from the network at any time without informing the other
1732 hosts. There is no reliable way to provide a zone serial number that
1733 would, whenever such a crash or disconnection occurred, immediately
1734 change to indicate that the contents of the shared zone had changed.
1736 Zone transfers are not possible for any Multicast DNS Zone.
1740 Expires 7th December 2005 Cheshire & Krochmal [Page 29]
1742 Internet Draft Multicast DNS 7th June 2005
1745 13. Multicast DNS for Service Discovery
1747 This document does not describe using Multicast DNS for network
1748 browsing or service discovery. However, the mechanisms this document
1749 describes are compatible with (and support) the browsing and service
1750 discovery mechanisms proposed in "DNS-Based Service Discovery"
1754 14. Enabling and Disabling Multicast DNS
1756 The option to fail-over to Multicast DNS for names not ending in
1757 ".local." SHOULD be a user-configured option, and SHOULD
1758 be disabled by default because of the possible security issues
1759 related to unintended local resolution of apparently global names.
1761 The option to lookup unqualified (relative) names by appending
1762 ".local." (or not) is controlled by whether ".local." appears
1763 (or not) in the client's DNS search list.
1765 No special control is needed for enabling and disabling Multicast DNS
1766 for names explicitly ending with ".local." as entered by the user.
1767 The user doesn't need a way to disable Multicast DNS for names ending
1768 with ".local.", because if the user doesn't want to use Multicast
1769 DNS, they can achieve this by simply not using those names. If a user
1770 *does* enter a name ending in ".local.", then we can safely assume
1771 the user's intention was probably that it should work. Having user
1772 configuration options that can be (intentionally or unintentionally)
1773 set so that local names don't work is just one more way of
1774 frustrating the user's ability to perform the tasks they want,
1775 perpetuating the view that, "IP networking is too complicated to
1776 configure and too hard to use." This in turn perpetuates the
1777 continued use of protocols like AppleTalk. If we want to retire
1778 AppleTalk, NetBIOS, etc., we need to offer users equivalent IP
1779 functionality that they can rely on to, "always work, like
1780 AppleTalk." A little Multicast DNS traffic may be a burden on the
1781 network, but it is an insignificant burden compared to continued
1782 widespread use of AppleTalk.
1785 15. Considerations for Multiple Interfaces
1787 A host should defend its host name (FQDN) on all active interfaces on
1788 which it is answering Multicast DNS queries.
1790 In the event of a name conflict on *any* interface, a host should
1791 configure a new host name, if it wishes to maintain uniqueness of its
1794 A host may choose to use the same name for all of its address records
1795 on all interfaces, or it may choose to manage its Multicast DNS host
1796 name(s) independently on each interface, potentially answering to
1797 different names on different interfaces.
1800 Expires 7th December 2005 Cheshire & Krochmal [Page 30]
1802 Internet Draft Multicast DNS 7th June 2005
1805 When answering a Multicast DNS query, a multi-homed host with a
1806 link-local address (or addresses) should take care to ensure that
1807 any address going out in a Multicast DNS response is valid for use
1808 on the interface on which the response is going out.
1810 Just as the same link-local IP address may validly be in use
1811 simultaneously on different links by different hosts, the same
1812 link-local host name may validly be in use simultaneously on
1813 different links, and this is not an error. A multi-homed host with
1814 connections to two different links may be able to communicate with
1815 two different hosts that are validly using the same name. While this
1816 kind of name duplication should be rare, it means that a host that
1817 wants to fully support this case needs network programming APIs that
1818 allow applications to specify on what interface to perform a
1819 link-local Multicast DNS query, and to discover on what interface a
1820 Multicast DNS response was received.
1823 16. Multicast DNS and Power Management
1825 Many modern network devices have the ability to go into a low-power
1826 mode where only a small part of the Ethernet hardware remains
1827 powered, and the device can be woken up by sending a specially
1828 formatted Ethernet frame which the device's power-management hardware
1831 To make use of this in conjunction with Multicast DNS, we propose a
1832 network power management service called Sleep Proxy Service. A device
1833 that wishes to enter low-power mode first uses DNS-SD to determine if
1834 Sleep Proxy Service is available on the local network. In some
1835 networks there may be more than one piece of hardware implementing
1836 Sleep Proxy Service, for fault-tolerance reasons.
1838 If the device finds the network has Sleep Proxy Service, the device
1839 transmits two or more gratuitous mDNS announcements setting the TTL
1840 of its relevant resource records to zero, to delete them from
1841 neighboring caches. The relevant resource records include address
1842 records and SRV records, and other resource records as may apply to a
1843 particular device. The device then communicates all of its remaining
1844 active records, plus the names, rrtypes and rrclasses of the deleted
1845 records, to the Sleep Proxy Service(s), along with a copy of the
1846 specific "magic packet" required to wake the device up.
1848 When a Sleep Proxy Service sees an mDNS query for one of the
1849 device's active records (e.g. a DNS-SD PTR record), it answers on
1850 behalf of the device without waking it up. When a Sleep Proxy Service
1851 sees an mDNS query for one of the device's deleted resource
1852 records, it deduces that some client on the network needs to make an
1853 active connection to the device, and sends the specified "magic
1854 packet" to wake the device up. The device then wakes up, reactivates
1855 its deleted resource records, and re-announces them to the network.
1856 The client waiting to connect sees the announcements, learns the
1857 current IP address and port number of the desired service on the
1858 device, and proceeds to connect to it.
1860 Expires 7th December 2005 Cheshire & Krochmal [Page 31]
1862 Internet Draft Multicast DNS 7th June 2005
1865 The connecting client does not need to be aware of how Sleep Proxy
1866 Service works. Only devices that implement low power mode and wish to
1867 make use of Sleep Proxy Service need to be aware of how that protocol
1870 The reason that a device using a Sleep Proxy Service should send more
1871 than one goodbye packet is to ensure deletion of the resource records
1872 from all peer caches. If resource records were to inadvertently
1873 remain in some peer caches, then those peers may not issue any query
1874 packets for those records when attempting to access the sleeping
1875 device, so the Sleep Proxy Service would not receive any queries for
1876 the device's SRV and/or address records, and the necessary wake-up
1877 message would not be triggered.
1879 The full specification of mDNS / DNS-SD Sleep Proxy Service
1880 is described in another document [not yet published].
1883 17. Multicast DNS Character Set
1885 Unicast DNS has been plagued by the lack of any support for non-US
1886 characters. Indeed, conventional DNS is usually limited to just
1887 letters, digits and hyphens, with no spaces or other punctuation.
1888 Attempts to remedy this for unicast DNS have been badly constrained
1889 by the need to accommodate old buggy legacy DNS implementations.
1890 In reality, the DNS specification actually imposes no limits on what
1891 characters may be used in names, and good DNS implementations handle
1892 any arbitrary eight-bit data without trouble. However, the old rules
1893 for ARPANET host names back in the 1980s required names to be just
1894 letters, digits, and hyphens [RFC 1034], and since the predominant
1895 use of DNS is to store host address records, many have assumed that
1896 the DNS protocol itself suffers from the same limitation. It would be
1897 more accurate to say that certain bad implementations may not handle
1898 eight-bit data correctly, not that the protocol doesn't support it.
1900 Multicast DNS is a new protocol and doesn't (yet) have old buggy
1901 legacy implementations to constrain the design choices. Accordingly,
1902 it adopts the simple obvious elegant solution: all names in Multicast
1903 DNS are encoded using precomposed UTF-8 [RFC 3629]. The
1904 characters SHOULD conform to Unicode Normalization Form C (NFC): Use
1905 precomposed characters instead of combining sequences where possible,
1906 e.g. use U+00C4 ("Latin capital letter A with diaeresis") instead of
1907 U+0041 U+0308 ("Latin capital letter A", "combining diaeresis").
1909 For names that are restricted to letters, digits and hyphens, the
1910 UTF-8 encoding is identical to the US-ASCII encoding, so this is
1911 entirely compatible with existing host names. For characters outside
1912 the US-ASCII range, UTF-8 encoding is used.
1914 Multicast DNS implementations MUST NOT use any other encodings apart
1915 from precomposed UTF-8 (US-ASCII being considered a compatible subset
1920 Expires 7th December 2005 Cheshire & Krochmal [Page 32]
1922 Internet Draft Multicast DNS 7th June 2005
1925 This point bears repeating: After many years of debate, as a result
1926 of the need to accommodate certain DNS implementations that
1927 apparently couldn't handle any character that's not a letter, digit
1928 or hyphen (and apparently never will be updated to remedy this
1929 limitation) the unicast DNS community settled on an extremely baroque
1930 encoding called "Punycode" [RFC 3492]. Punycode is a remarkably
1931 ingenious encoding solution, but it is complicated, hard to
1932 understand, and hard to implement, using sophisticated techniques
1933 including insertion unsort coding, generalized variable-length
1934 integers, and bias adaptation. The resulting encoding is remarkably
1935 compact given the constraints, but it's still not as good as simple
1936 straightforward UTF-8, and it's hard even to predict whether a given
1937 input string will encode to a Punycode string that fits within DNS's
1938 63-byte limit, except by simply trying the encoding and seeing
1939 whether it fits. Indeed, the encoded size depends not only on the
1940 input characters, but on the order they appear, so the same set of
1941 characters may or may not encode to a legal Punycode string that fits
1942 within DNS's 63-byte limit, depending on the order the characters
1943 appear. This is extremely hard to present in a user interface that
1944 explains to users why one name is allowed, but another name
1945 containing the exact same characters is not. Neither Punycode nor any
1946 other of the "Ascii Compatible Encodings" proposed for Unicast DNS
1947 may be used in Multicast DNS packets. Any text being represented
1948 internally in some other representation MUST be converted to
1949 canonical precomposed UTF-8 before being placed in any Multicast DNS
1952 The simple rules for case-insensitivity in Unicast DNS also apply in
1953 Multicast DNS; that is to say, in name comparisons, the lower-case
1954 letters "a" to "z" (0x61 to 0x7A) match their upper-case equivalents
1955 "A" to "Z" (0x41 to 0x5A). Hence, if a client issues a query for an
1956 address record with the name "cheshire.local", then a responder
1957 having an address record with the name "Cheshire.local" should
1958 issue a response. No other automatic equivalences should be assumed.
1959 In particular all UTF-8 multi-byte characters (codes 0x80 and higher)
1960 are compared by simple binary comparison of the raw byte values.
1962 No other automatic character equivalence is defined in Multicast DNS.
1963 For example, accented characters are not defined to be automatically
1964 equivalent to their unaccented counterparts. Where automatic
1965 equivalences are desired, this may be achieved through the use of
1966 programmatically-generated CNAME records. For example, if a responder
1967 has an address record for an accented name Y, and a client issues a
1968 query for a name X, where X is the same as Y with all the accents
1969 removed, then the responder may issue a response containing two
1970 resource records: A CNAME record "X CNAME Y", asserting that the
1971 requested name X (unaccented) is an alias for the true (accented)
1972 name Y, followed by the address record for Y.
1980 Expires 7th December 2005 Cheshire & Krochmal [Page 33]
1982 Internet Draft Multicast DNS 7th June 2005
1985 18. Multicast DNS Message Size
1987 RFC 1035 restricts DNS Messages carried by UDP to no more than 512
1988 bytes (not counting the IP or UDP headers). For UDP packets carried
1989 over the wide-area Internet in 1987, this was appropriate. For
1990 link-local multicast packets on today's networks, there is no reason
1991 to retain this restriction. Given that the packets are by definition
1992 link-local, there are no Path MTU issues to consider.
1994 Multicast DNS Messages carried by UDP may be up to the IP MTU of the
1995 physical interface, less the space required for the IP header (20
1996 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
1998 In the case of a single mDNS Resource Record which is too large to
1999 fit in a single MTU-sized multicast response packet, a Multicast DNS
2000 Responder SHOULD send the Resource Record alone, in a single IP
2001 datagram, sent using multiple IP fragments. Resource Records this
2002 large SHOULD be avoided, except in the very rare cases where they
2003 really are the appropriate solution to the problem at hand.
2004 Implementers should be aware that many simple devices do not
2005 re-assemble fragmented IP datagrams, so large Resource Records SHOULD
2006 NOT be used except in specialized cases where the implementer knows
2007 that all receivers implement reassembly.
2009 A Multicast DNS packet larger than the interface MTU, which is sent
2010 using fragments, MUST NOT contain more than one Resource Record.
2012 Even when fragmentation is used, a Multicast DNS packet, including IP
2013 and UDP headers, MUST NOT exceed 9000 bytes.
2016 19. Multicast DNS Message Format
2018 This section describes specific restrictions on the allowable
2019 values for the header fields of a Multicast DNS message.
2021 19.1. ID (Query Identifier)
2023 Multicast DNS clients SHOULD listen for gratuitous responses
2024 issued by hosts booting up (or waking up from sleep or otherwise
2025 joining the network). Since these gratuitous responses may contain a
2026 useful answer to a question for which the client is currently
2027 awaiting an answer, Multicast DNS clients SHOULD examine all received
2028 Multicast DNS response messages for useful answers, without regard to
2029 the contents of the ID field or the Question Section. In Multicast
2030 DNS, knowing which particular query message (if any) is responsible
2031 for eliciting a particular response message is less interesting than
2032 knowing whether the response message contains useful information.
2034 Multicast DNS clients MAY cache any or all Multicast DNS response
2035 messages they receive, for possible future use, provided of course
2036 that normal TTL aging is performed on these cached resource records.
2040 Expires 7th December 2005 Cheshire & Krochmal [Page 34]
2042 Internet Draft Multicast DNS 7th June 2005
2045 In multicast query messages, the Query ID SHOULD be set to zero on
2048 In multicast responses, including gratuitous multicast responses, the
2049 Query ID MUST be set to zero on transmission, and MUST be ignored on
2052 In unicast response messages generated specifically in response to a
2053 particular (unicast or multicast) query, the Query ID MUST match the
2054 ID from the query message.
2057 19.2. QR (Query/Response) Bit
2059 In query messages, MUST be zero.
2061 In response messages, MUST be one.
2066 In both multicast query and multicast response messages, MUST be zero
2067 (only standard queries are currently supported over multicast, unless
2068 other queries are allowed by future IETF Standards Action).
2071 19.4. AA (Authoritative Answer) Bit
2073 In query messages, the Authoritative Answer bit MUST be zero on
2074 transmission, and MUST be ignored on reception.
2076 In response messages for Multicast Domains, the Authoritative Answer
2077 bit MUST be set to one (not setting this bit implies there's some
2078 other place where "better" information may be found) and MUST be
2079 ignored on reception.
2082 19.5. TC (Truncated) Bit
2084 In query messages, if the TC bit is set, it means that additional
2085 Known Answer records may be following shortly. A responder MAY choose
2086 to record this fact, and wait for those additional Known Answer
2087 records, before deciding whether to respond. If the TC bit is clear,
2088 it means that the querying host has no additional Known Answers.
2090 In multicast response messages, the TC bit MUST be zero on
2091 transmission, and MUST be ignored on reception.
2093 In legacy unicast response messages, the TC bit has the same meaning
2094 as in conventional unicast DNS: it means that the response was too
2095 large to fit in a single packet, so the client SHOULD re-issue its
2096 query using TCP in order to receive the larger response.
2100 Expires 7th December 2005 Cheshire & Krochmal [Page 35]
2102 Internet Draft Multicast DNS 7th June 2005
2105 19.6. RD (Recursion Desired) Bit
2107 In both multicast query and multicast response messages, the
2108 Recursion Desired bit SHOULD be zero on transmission, and MUST be
2109 ignored on reception.
2112 19.7. RA (Recursion Available) Bit
2114 In both multicast query and multicast response messages, the
2115 Recursion Available bit MUST be zero on transmission, and MUST be
2116 ignored on reception.
2121 In both query and response messages, the Zero bit MUST be zero on
2122 transmission, and MUST be ignored on reception.
2125 19.9. AD (Authentic Data) Bit [RFC 2535]
2127 In query messages the Authentic Data bit MUST be zero on
2128 transmission, and MUST be ignored on reception.
2130 In response messages, the Authentic Data bit MAY be set. Resolvers
2131 receiving response messages with the AD bit set MUST NOT trust the AD
2132 bit unless they trust the source of the message and either have a
2133 secure path to it or use DNS transaction security.
2136 19.10. CD (Checking Disabled) Bit [RFC 2535]
2138 In query messages, a resolver willing to do cryptography SHOULD set
2139 the Checking Disabled bit to permit it to impose its own policies.
2141 In response messages, the Checking Disabled bit MUST be zero on
2142 transmission, and MUST be ignored on reception.
2145 19.11. RCODE (Response Code)
2147 In both multicast query and multicast response messages, the Response
2148 Code MUST be zero on transmission. Multicast DNS messages received
2149 with non-zero Response Codes MUST be silently ignored.
2152 19.12. Repurposing of top bit of qclass in Question Section
2154 In the Question Section of a Multicast DNS Query, the top bit of the
2155 qclass field is used to indicate that unicast responses are preferred
2156 for this particular question.
2160 Expires 7th December 2005 Cheshire & Krochmal [Page 36]
2162 Internet Draft Multicast DNS 7th June 2005
2165 19.12. Repurposing of top bit of rrclass in Answer Section
2167 In the Answer Section of a Multicast DNS Response, the top bit of the
2168 rrclass field is used to indicate that the record is a member of a
2169 unique RRSet, and the entire RRSet has been sent together (in the
2170 same packet, or in consecutive packets if there are too many records
2171 to fit in a single packet).
2174 20. Choice of UDP Port Number
2176 Arguments were made for and against using Multicast on UDP port 53.
2177 The final decision was to use UDP port 5353. Some of the arguments
2178 for and against are given below.
2181 20.1 Arguments for using UDP port 53:
2183 * This is "just DNS", so it should be the same port.
2185 * There is less work to be done updating old clients to do simple
2186 mDNS queries. Only the destination address need be changed.
2187 In some cases, this can be achieved without any code changes,
2188 just by adding the address 224.0.0.251 to a configuration file.
2191 20.2 Arguments for using a different port (UDP port 5353):
2193 * This is not "just DNS". This is a DNS-like protocol, but different.
2195 * Changing client code to use a different port number is not hard.
2197 * Using the same port number makes it hard to run an mDNS Responder
2198 and a conventional unicast DNS server on the same machine. If a
2199 conventional unicast DNS server wishes to implement mDNS as well,
2200 it can still do that, by opening two sockets. Having two different
2201 port numbers is important to allow this flexibility.
2203 * Some VPN software hijacks all outgoing traffic to port 53 and
2204 redirects it to a special DNS server set up to serve those VPN
2205 clients while they are connected to the corporate network. It is
2206 questionable whether this is the right thing to do, but it is
2207 common, and redirecting link-local multicast DNS packets to a
2208 remote server rarely produces any useful results. It does mean, for
2209 example, that the user becomes unable to access their local network
2210 printer sitting on their desk right next to their computer. Using
2211 a different UDP port eliminates this particular problem.
2213 * On many operating systems, unprivileged clients may not send or
2214 receive packets on low-numbered ports. This means that any client
2215 sending or receiving mDNS packets on port 53 would have to run as
2216 "root", which is an undesirable security risk. Using a higher-
2217 numbered UDP port eliminates this particular problem.
2220 Expires 7th December 2005 Cheshire & Krochmal [Page 37]
2222 Internet Draft Multicast DNS 7th June 2005
2225 Continuing the previous point, since using an unprivileged port
2226 allows normal user-level code to bind, a given machine may have more
2227 than one such user-level application running at a time. Because of
2228 this, any code binding to UDP port 5353 MUST use the SO_REUSEPORT
2229 option, so as to be a good citizen and not block other clients on the
2230 machine from also binding to that port.
2233 21. Summary of Differences Between Multicast DNS and Unicast DNS
2235 The value of Multicast DNS is that it shares, as much as possible,
2236 the familiar APIs, naming syntax, resource record types, etc., of
2237 Unicast DNS. There are of course necessary differences by virtue of
2238 it using Multicast, and by virtue of it operating in a community of
2239 cooperating peers, rather than a precisely defined authoritarian
2240 hierarchy controlled by a strict chain of formal delegations from the
2241 top. These differences are listed below:
2245 * uses UDP port 5353 instead of port 53
2246 * operates in well-defined parts of the DNS namespace
2247 * uses UTF-8, and only UTF-8, to encode resource record names
2248 * defines a clear limit on the maximum legal domain name (255 bytes)
2249 * allows larger UDP packets
2250 * allows more than one question in a query packet
2251 * uses the Answer Section of a query to list Known Answers
2252 * uses the TC bit in a query to indicate additional Known Answers
2253 * uses the Authority Section of a query for probe tie-breaking
2254 * ignores the Query ID field (except for generating legacy responses)
2255 * doesn't require the question to be repeated in the response packet
2256 * uses gratuitous responses to announce new records to the peer group
2257 * defines a "unicast response" bit in the rrclass of query questions
2258 * defines a "cache flush" bit in the rrclass of response answers
2259 * uses DNS TTL 0 to indicate that a record has been deleted
2260 * monitors queries to perform Duplicate Question Suppression
2261 * monitors responses to perform Duplicate Answer Suppression...
2262 * ... and Ongoing Conflict Detection
2263 * ... and Opportunistic Caching
2266 22. Benefits of Multicast Responses
2268 Some people have argued that sending responses via multicast is
2269 inefficient on the network. In fact the benefits of using multicast
2270 responses result in a net lowering of overall multicast traffic, for
2271 a variety of reasons.
2273 * One multicast response can update the cache on all machines on the
2274 network. If another machine later wants to issue the same query, it
2275 already has the answer in its cache, so it may not need to even
2276 transmit that multicast query on the network at all.
2280 Expires 7th December 2005 Cheshire & Krochmal [Page 38]
2282 Internet Draft Multicast DNS 7th June 2005
2285 * When more than one machine has the same ongoing long-lived query
2286 running, every machine does not have to transmit its own
2287 independent query. When one machine transmits a query, all the
2288 other hosts see the answers, so they can suppress their own
2291 * When a host sees a multicast query, but does not see the
2292 corresponding multicast response, it can use this information to
2293 promptly delete stale data from its cache. To achieve the same
2294 level of user-interface quality and responsiveness without
2295 multicast responses would require lower cache lifetimes and more
2296 frequent network polling, resulting in a significantly higher
2299 * Multicast responses allow passive conflict detection. Without this
2300 ability, some other conflict detection mechanism would be needed,
2301 imposing its own additional burden on the network.
2303 * When using delayed responses to reduce network collisions, clients
2304 need to maintain a list recording to whom each answer should be
2305 sent. The option of multicast responses allows clients with limited
2306 storage, which cannot store an arbitrarily long list of response
2307 addresses, to choose to fail-over to a single multicast response in
2308 place of multiple unicast responses, when appropriate.
2310 * In the case of overlayed subnets and other misconfigurations,
2311 multicast responses allow a receiver to know with certainty that
2312 a response originated on the local link, even when its source
2313 address may apparently suggest otherwise. This can be extremely
2314 helpful when diagnosing and rectifying network problems, since
2315 it facilitates a direct communication channel between client and
2316 server that works without reliance on ARP, IP routing tables, etc.
2317 Being able to discover what IP address a device has (or thinks it
2318 has) is frequently a very valuable first step in diagnosing why
2319 it unable to communicate on the local network.
2322 23. IPv6 Considerations
2324 An IPv4-only host and an IPv6-only host behave as "ships that pass in
2325 the night". Even if they are on the same Ethernet, neither is aware
2326 of the other's traffic. For this reason, each physical link may have
2327 *two* unrelated ".local." zones, one for IPv4 and one for IPv6.
2328 Since for practical purposes, a group of IPv4-only hosts and a group
2329 of IPv6-only hosts on the same Ethernet act as if they were on two
2330 entirely separate Ethernet segments, it is unsurprising that their
2331 use of the ".local." zone should occur exactly as it would if
2332 they really were on two entirely separate Ethernet segments.
2334 A dual-stack (v4/v6) host can participate in both ".local."
2335 zones, and should register its name(s) and perform its lookups both
2336 using IPv4 and IPv6. This enables it to reach, and be reached by,
2337 both IPv4-only and IPv6-only hosts. In effect this acts like a
2340 Expires 7th December 2005 Cheshire & Krochmal [Page 39]
2342 Internet Draft Multicast DNS 7th June 2005
2345 multi-homed host, with one connection to the logical "IPv4 Ethernet
2346 segment", and a connection to the logical "IPv6 Ethernet segment".
2348 23.1 IPv6 Multicast Addresses by Hashing
2350 Some discovery protocols use a range of multicast addresses, and
2351 determine the address to be used by a hash function of the name being
2352 sought. Queries are sent via multicast to the address as indicated by
2353 the hash function, and responses are returned to the querier via
2354 unicast. Particularly in IPv6, where multicast addresses are
2355 extremely plentiful, this approach is frequently advocated.
2357 There are some problems with this:
2359 * When a host has a large number of records with different names, the
2360 host may have to join a large number of multicast groups. This can
2361 place undue burden on the Ethernet hardware, which typically
2362 supports a limited number of multicast addresses efficiently. When
2363 this number is exceeded, the Ethernet hardware may have to resort
2364 to receiving all multicasts and passing them up to the host
2365 software for filtering, thereby defeating the point of using a
2366 multicast address range in the first place.
2368 * Multiple questions cannot be placed in one packet if they don't all
2369 hash to the same multicast address.
2371 * Duplicate Question Suppression doesn't work if queriers are not
2372 seeing each other's queries.
2374 * Duplicate Answer Suppression doesn't work if responders are not
2375 seeing each other's responses.
2377 * Opportunistic Caching doesn't work.
2379 * Ongoing Conflict Detection doesn't work.
2382 24. Security Considerations
2384 The algorithm for detecting and resolving name conflicts is, by its
2385 very nature, an algorithm that assumes cooperating participants. Its
2386 purpose is to allow a group of hosts to arrive at a mutually disjoint
2387 set of host names and other DNS resource record names, in the absence
2388 of any central authority to coordinate this or mediate disputes. In
2389 the absence of any higher authority to resolve disputes, the only
2390 alternative is that the participants must work together cooperatively
2391 to arrive at a resolution.
2393 In an environment where the participants are mutually antagonistic
2394 and unwilling to cooperate, other mechanisms are appropriate, like
2395 manually administered DNS.
2400 Expires 7th December 2005 Cheshire & Krochmal [Page 40]
2402 Internet Draft Multicast DNS 7th June 2005
2405 In an environment where there is a group of cooperating participants,
2406 but there may be other antagonistic participants on the same physical
2407 link, the cooperating participants need to use IPSEC signatures
2408 and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS
2409 messages from trusted participants (which they process as usual) from
2410 mDNS messages from untrusted participants (which they silently
2413 When DNS queries for *global* DNS names are sent to the mDNS
2414 multicast address (during network outages which disrupt communication
2415 with the greater Internet) it is *especially* important to use
2416 DNSSEC, because the user may have the impression that he or she is
2417 communicating with some authentic host, when in fact he or she is
2418 really communicating with some local host that is merely masquerading
2419 as that name. This is less critical for names ending with ".local.",
2420 because the user should be aware that those names have only local
2421 significance and no global authority is implied.
2423 Most computer users neglect to type the trailing dot at the end of a
2424 fully qualified domain name, making it a relative domain name (e.g.
2425 "www.example.com"). In the event of network outage, attempts to
2426 positively resolve the name as entered will fail, resulting in
2427 application of the search list, including ".local.", if present.
2428 A malicious host could masquerade as "www.example.com" by answering
2429 the resulting Multicast DNS query for "www.example.com.local."
2430 To avoid this, a host MUST NOT append the search suffix
2431 ".local.", if present, to any relative (partially qualified)
2432 domain name containing two or more labels. Appending ".local." to
2433 single-label relative domain names is acceptable, since the user
2434 should have no expectation that a single-label domain name will
2438 25. IANA Considerations
2440 IANA has allocated the IPv4 link-local multicast address 224.0.0.251
2441 for the use described in this document.
2443 IANA has allocated the IPv6 multicast address set FF0X::FB for the
2444 use described in this document. Only address FF02::FB (Link-Local
2445 Scope) is currently in use by deployed software, but it is possible
2446 that in future implementers may experiment with Multicast DNS using
2447 larger-scoped addresses, such as FF05::FB (Site-Local Scope).
2449 When this document is published, IANA should designate a list of
2450 domains which are deemed to have only link-local significance, as
2451 described in Section 12 of this document ("Special Characteristics of
2452 Multicast DNS Domains").
2454 The re-use of the top bit of the rrclass field in the Question and
2455 Answer Sections means that Multicast DNS can only carry DNS records
2456 with classes in the range 0-32767. Classes in the range 32768 to
2457 65535 are incompatible with Multicast DNS. However, since to-date
2460 Expires 7th December 2005 Cheshire & Krochmal [Page 41]
2462 Internet Draft Multicast DNS 7th June 2005
2465 only three DNS classes have been assigned by IANA (1, 3 and 4),
2466 and only one (1, "Internet") is actually in widespread use, this
2467 limitation is likely to remain a purely theoretical one.
2469 No other IANA services are required by this document.
2474 The concepts described in this document have been explored, developed
2475 and implemented with help from Freek Dijkstra, Erik Guttman, Paul
2476 Vixie, Bill Woodcock, and others.
2478 Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher,
2479 Roger Pantos and Kiren Sekar for their significant contributions.
2484 Copyright (C) The Internet Society 2005.
2485 All Rights Reserved.
2487 This document and translations of it may be copied and furnished to
2488 others, and derivative works that comment on or otherwise explain it
2489 or assist in its implementation may be prepared, copied, published
2490 and distributed, in whole or in part, without restriction of any
2491 kind, provided that the above copyright notice and this paragraph are
2492 included on all such copies and derivative works. However, this
2493 document itself may not be modified in any way, such as by removing
2494 the copyright notice or references to the Internet Society or other
2495 Internet organizations, except as needed for the purpose of
2496 developing Internet standards in which case the procedures for
2497 copyrights defined in the Internet Standards process must be
2498 followed, or as required to translate it into languages other than
2501 The limited permissions granted above are perpetual and will not be
2502 revoked by the Internet Society or its successors or assigns.
2504 This document and the information contained herein is provided on an
2505 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2506 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2507 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2508 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2509 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2512 28. Normative References
2514 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
2515 Facilities", STD 13, RFC 1034, November 1987.
2517 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
2518 Specifications", STD 13, RFC 1035, November 1987.
2520 Expires 7th December 2005 Cheshire & Krochmal [Page 42]
2522 Internet Draft Multicast DNS 7th June 2005
2525 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
2526 Requirement Levels", RFC 2119, March 1997.
2528 [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO
2529 10646", RFC 3629, November 2003.
2532 29. Informative References
2534 [dotlocal] <http://www.dotlocal.org/>
2536 [djbdl] <http://cr.yp.to/djbdns/dot-local.html>
2538 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service
2539 Discovery", Internet-Draft (work in progress),
2540 draft-cheshire-dnsext-dns-sd-03.txt, June 2005.
2542 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
2543 Overview and Architecture.
2544 Institute of Electrical and Electronic Engineers,
2545 IEEE Standard 802, 1990.
2547 [NBP] Cheshire, S., and M. Krochmal,
2548 "Requirements for a Protocol to Replace AppleTalk NBP",
2549 Internet-Draft (work in progress),
2550 draft-cheshire-dnsext-nbp-04.txt, June 2005.
2552 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
2553 System (DNS UPDATE)", RFC 2136, April 1997.
2555 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address
2556 Autoconfiguration", RFC 2462, December 1998.
2558 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
2559 RFC 2535, March 1999.
2561 [RFC 3492] Costello, A., "Punycode: A Bootstring encoding of
2562 Unicode for use with Internationalized Domain Names
2563 in Applications (IDNA)", RFC 3492, March 2003.
2565 [RFC 3927] Cheshire, S., B. Aboba, and E. Guttman,
2566 "Dynamic Configuration of IPv4 Link-Local Addresses",
2569 [ZC] Williams, A., "Requirements for Automatic Configuration
2570 of IP Hosts", Internet-Draft (work in progress),
2571 draft-ietf-zeroconf-reqts-12.txt, September 2002.
2580 Expires 7th December 2005 Cheshire & Krochmal [Page 43]
2582 Internet Draft Multicast DNS 7th June 2005
2585 30. Authors' Addresses
2588 Apple Computer, Inc.
2594 Phone: +1 408 974 3207
2595 EMail: rfc@stuartcheshire.org
2599 Apple Computer, Inc.
2605 Phone: +1 408 974 4368
2606 EMail: marc@apple.com
2640 Expires 7th December 2005 Cheshire & Krochmal [Page 44]