1 Document: draft-cheshire-dnsext-multicastdns-03.txt Stuart Cheshire
2 Category: Standards Track Apple Computer, Inc.
3 Expires 29th July 2004 Marc Krochmal
9 <draft-cheshire-dnsext-multicastdns-03.txt>
14 This document is an Internet-Draft and is in full conformance with
15 all provisions of Section 10 of RFC2026. Internet-Drafts are
16 working documents of the Internet Engineering Task Force (IETF),
17 its areas, and its working groups. Note that other groups may
18 also distribute working documents as Internet-Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six
21 months and may be updated, replaced, or obsoleted by other documents
22 at any time. It is inappropriate to use Internet-Drafts as
23 reference material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html
31 Distribution of this memo is unlimited.
36 As networked devices become smaller, more portable, and more
37 ubiquitous, the ability to operate with less configured
38 infrastructure is increasingly important. In particular, the ability
39 to look up DNS resource record data types (including, but not limited
40 to, host names) in the absence of a conventional managed DNS server,
41 is becoming essential.
43 Multicast DNS (mDNS) provides the ability to do DNS-like operations
44 on the local link in the absense of any conventional unicast DNS
45 server. In addition, mDNS designates a portion of the DNS namespace
46 to be free for local use, without the need to pay any annual fee, and
47 without the need to set up delegations or otherwise configure a
48 conventional DNS server to answer for those names.
50 The primary benefits of mDNS names are that (i) they require little
51 or no administration or configuration to set them up, (ii) they work
52 when no infrastructure is present, and (iii) they work during
53 infrastructure failures.
58 Expires 29th July 2004 Cheshire & Krochmal [Page 1]
60 Internet Draft Multicast DNS 29th January 2003
65 1. Introduction...................................................3
66 2. Conventions and Terminology Used in this Document..............4
67 3. Multicast DNS Names............................................4
68 4. IP TTL Checks..................................................8
69 5. Reverse Address Mapping........................................8
70 6. Querying.......................................................9
71 7. Duplicate Suppression.........................................13
72 8. Responding....................................................15
73 9. Probing and Announcing on Startup.............................17
74 10. Conflict Resolution...........................................21
75 11. Special Characteristics of Multicast DNS Domains..............23
76 12. Multicast DNS for Service Discovery...........................24
77 13. Resource Record TTL Values and Cache Coherency................25
78 14. Enabling and Disabling Multicast DNS..........................30
79 15. Considerations for Multiple Interfaces........................30
80 16. Multicast DNS and Power Management............................31
81 17. Multicast DNS Character Set...................................32
82 18. Multicast DNS Message Size....................................33
83 19. Multicast DNS Message Format..................................33
84 20. Choice of UDP Port Number.....................................36
85 21. Summary of Differences Between Multicast DNS and Unicast DNS..37
86 22. Benefits of Multicast Responses...............................38
87 23. IPv6 Considerations...........................................39
88 24. Security Considerations.......................................40
89 25. IANA Considerations...........................................41
90 26. Acknowledgements..............................................41
91 27. Copyright.....................................................41
92 28. Normative References..........................................42
93 29. Informative References........................................42
94 30. Author's Addresses............................................43
116 Expires 29th July 2004 Cheshire & Krochmal [Page 2]
118 Internet Draft Multicast DNS 29th January 2003
123 When reading this document, familiarity with the concepts of Zero
124 Configuration Networking [ZC] and automatic link-local addressing
125 [v4LL] [RFC 2462] is helpful.
127 This document proposes no change to the structure of DNS messages,
128 and no new operation codes, response codes, or resource record types.
129 This document simply discusses what needs to happen if DNS clients
130 start sending DNS queries to a multicast address, and how a
131 collection of hosts can cooperate to collectively answer those
132 queries in a useful manner.
134 There has been discussion of how much burden Multicast DNS might
135 impose on a network. It should be remembered that whenever IPv4 hosts
136 communicate, they broadcast ARP packets on the network on a regular
137 basis, and this is not disastrous. The approximate amount of
138 multicast traffic generated by hosts making conventional use of
139 Multicast DNS is anticipated to be roughly the same order of
140 magnitude as the amount of broadcast ARP traffic those hosts already
143 New applications making new use of Multicast DNS capabilities for
144 unconventional purposes may generate more traffic. If some of those
145 new applications are "chatty", then work will be needed to help them
146 become less chatty. When performing any analysis, it is important to
147 make a distinction between the application behavior and the
148 underlying protocol behavior. If a chatty application uses UDP, that
149 doesn't mean that UDP is chatty, or that IP is chatty, or that
150 Ethernet is chatty. What it means is that the application is chatty.
151 The same applies to any future applications that may decide to layer
152 increasing portions of their functionality over Multicast DNS.
174 Expires 29th July 2004 Cheshire & Krochmal [Page 3]
176 Internet Draft Multicast DNS 29th January 2003
179 2. Conventions and Terminology Used in this Document
181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
183 document are to be interpreted as described in "Key words for use in
184 RFCs to Indicate Requirement Levels" [RFC 2119].
186 This document uses the term "host name" in the strict sense to mean a
187 fully qualified domain name that has an address record. It does not
188 use the term "host name" in the commonly used but incorrect sense to
189 mean just the first DNS label of a host's fully qualified domain
192 A DNS (or mDNS) packet contains an IP TTL in the IP header, which
193 is effectively a hop-count limit for the packet, to guard against
194 routing loops. Each Resource Record also contains a TTL, which is
195 the number of seconds for which the Resource Record may be cached.
197 In any place where there may be potential confusion between these two
198 types of TTL, the term "IP TTL" is used to refer to the IP header TTL
199 (hop limit), and the term "RR TTL" is used to refer to the Resource
200 Record TTL (cache lifetime).
202 When this document uses the term "Multicast DNS", it should be taken
203 to mean: Clients performing DNS-like queries for DNS-like resource
204 records by sending DNS-like UDP query and response packets over IP
205 Multicast to UDP port 5353."
208 3. Multicast DNS Names
210 This document proposes that the DNS top-level domain ".local." be
211 designated a special domain with special semantics, namely that any
212 fully-qualified name ending in ".local." is link-local, and names
213 within this domain are meaningful only on the link where they
214 originate. This is analogous to IPv4 addresses in the 169.254/16
215 prefix, which are link-local and meaningful only on the link where
218 Any DNS query for a name ending with ".local." MUST be sent
219 to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent
222 It is unimportant whether a name ending with ".local." occurred
223 because the user explicitly typed in a fully qualified domain name
224 ending in ".local.", or because the user entered an unqualified
225 domain name and the host software appended the suffix ".local."
226 because that suffix appears in the user's search list. The ".local."
227 suffix could appear in the search list because the user manually
228 configured it, or because it was received in a DHCP option, or via
229 any other valid mechanism for configuring the DNS search list. In
232 Expires 29th July 2004 Cheshire & Krochmal [Page 4]
234 Internet Draft Multicast DNS 29th January 2003
237 this respect the ".local." suffix is treated no differently to any
238 other search domain that might appear in the DNS search list.
240 DNS queries for names that do not end with ".local." MAY be sent to
241 the mDNS multicast address, if no other conventional DNS server is
242 available. This can allow hosts on the same link to continue
243 communicating using each other's globally unique DNS names during
244 network outages which disrupt communication with the greater
245 Internet. When resolving global names via local multicast, it is even
246 more important to use DNSSEC or other security mechanisms to ensure
247 that the response is trustworthy. Resolving global names via local
248 multicast is a contentious issue, and this document does not discuss
249 it in detail, instead concentrating on the issue of resolving local
250 names using DNS packets sent to a multicast address.
252 A host which belongs to an organization or individual who has control
253 over some portion of the DNS namespace can be assigned a globally
254 unique name within that portion of the DNS namespace, for example,
255 "cheshire.apple.com." For those of us who have this luxury, this
256 works very well. However, the majority of home customers do not have
257 easy access to any portion of the global DNS namespace within which
258 they have the authority to create names as they wish. This leaves the
259 majority of home computers effectively anonymous for practical
262 To remedy this problem, this document allows any computer user to
263 elect to give their computers link-local Multicast DNS host names of
264 the form: "single-dns-label.local." For example, my Titanium
265 PowerBook laptop computer answers to the name "sctibook.local." Any
266 computer user is granted the authority to name their computer this
267 way, providing that the chosen host name is not already in use on
268 that link. Having named their computer this way, the user has the
269 authority to continue using that name until such time as a name
270 conflict occurs on the link which is not resolved in the user's
271 favour. If this happens, the computer (or its human user) SHOULD
272 cease using the name, and may choose to attempt to allocate a new
273 unique name for use on that link. Like law suits over global DNS
274 names, these conflicts are expected to be relatively rare for people
275 who choose reasonably imaginative names, but it is still important
276 to have a mechanism in place to handle them when they happen.
278 The point made in the previous paragraph is very important and bears
279 repeating. It is easy for those of us in the IETF community who run
280 our own name servers at home to forget that the majority of computer
281 users do not run their own name server and have no easy way to create
282 their own host names. When these users wish to transfer files between
283 two laptop computers, they are frequently reduced to typing in
284 dotted-decimal IP addresses because they simply have no other way for
285 one host to refer to the other by name. This is a sorry state of
286 affairs. What is worse, most users don't even bother trying to use
290 Expires 29th July 2004 Cheshire & Krochmal [Page 5]
292 Internet Draft Multicast DNS 29th January 2003
295 dotted-decimal IP addresses. Most users still move data between
296 machines by copying it onto a floppy disk or similar removable media.
298 In a world of gigabit Ethernet and ubiquitous wireless networking it
299 is a sad indictment of the networking community that the preferred
300 communication medium for most computer users is still the floppy
303 Allowing ad-hoc allocation of single-label names in a single flat
304 ".local." namespace may seem to invite chaos. However, operational
305 experience with AppleTalk NBP names, which on any given link are also
306 effectively single-label names in a flat namespace, shows that in
307 practice name collisions happen extremely rarely and are not a
308 problem. Groups of computer users from disparate organizations bring
309 Macintosh laptop computers to events such as IETF Meetings, the Mac
310 Hack conference, the Apple World Wide Developer Conference, etc., and
311 complaints at these events about users suffering conflicts and being
312 forced to rename their machines have never been an issue.
314 Enforcing uniqueness of host names (i.e. the names of DNS address
315 records mapping names to IP addresses) is probably desirable in the
316 common case, but this document does not mandate that. It is
317 permissible for a collection of coordinated hosts to agree to
318 maintain multiple DNS address records with the same name, possibly
319 for load balancing or fault-tolerance reasons. This document does not
320 take a position on whether that is sensible. It is important that
321 both modes of operation are supported. The Multicast DNS protocol
322 allows hosts to verify and maintain unique names for resource records
323 where that behaviour is desired, and it also allows hosts to maintain
324 multiple resource records with a single shared name where that
325 behaviour is desired. This consideration applies to all resource
326 records, not just address records (host names). In summary: It is
327 required that the protocol have the ability to detect and handle name
328 conflicts, but it is not required that this ability be used for every
332 3.1 Governing Standards Body
334 Note that this use of the ".local." suffix falls under IETF
335 jurisdiction, not ICANN jurisdiction. DNS is an IETF network
336 protocol, governed by protocol rules defined by the IETF. These IETF
337 protocol rules dictate character set, maximum name length, packet
338 format, etc. ICANN determines additional rules that apply when the
339 IETF's DNS protocol is used on the public Internet. In contrast,
340 private uses of the DNS protocol on isolated private networks are not
341 governed by ICANN. Since this proposed change is a change to the core
342 DNS protocol rules, it affects everyone, not just those machines
343 using the ICANN-governed Internet. Hence this change falls into the
344 category of an IETF protocol rule, not an ICANN usage rule.
348 Expires 29th July 2004 Cheshire & Krochmal [Page 6]
350 Internet Draft Multicast DNS 29th January 2003
353 3.2 Private DNS Namespaces
355 Note also that the special treatment of names ending in ".local." has
356 been implemented in Macintosh computers since the days of Mac OS 9,
357 and continues today in Mac OS X. There are also implementations for
358 Linux and other platforms [dotlocal]. Operators setting up private
359 internal networks ("intranets") are advised that their lives may be
360 easier if they avoid using the suffix ".local." in names in their
361 private internal DNS server. Alternative possibilities include:
369 Another alternative naming scheme, advocated by Professor D. J.
370 Bernstein, is to use a numerical suffix, such as ".6." [djbdl].
373 3.3 Maximum Multicast DNS Name Length
377 "the total number of octets that represent a domain name (i.e.,
378 the sum of all label octets and label lengths) is limited to 255."
380 This text implies that the final root label at the end of every name
381 is included in this count (a name can't be represented without it),
382 but the text does not explicitly state that. Implementations of
383 Multicast DNS MUST include the label length byte of the final root
384 label at the end of every name when enforcing the rule that no name
385 may be longer than 255 bytes. For example, the length of the name
386 "apple.com." is considered to be 11, which is the number of bytes it
387 takes to represent that name in a packet without using name
390 ------------------------------------------------------
391 | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 |
392 ------------------------------------------------------
406 Expires 29th July 2004 Cheshire & Krochmal [Page 7]
408 Internet Draft Multicast DNS 29th January 2003
413 All Multicast DNS responses (including responses sent via unicast)
414 MUST be sent with IP TTL set to 255.
416 A host sending Multicast DNS queries to a link-local destination
417 address (including the 224.0.0.251 link-local multicast address) MUST
418 verify that the IP TTL in response packets is 255, and silently
419 discard any response packets where the IP TTL is not 255. Without
420 this check, it could be possible for remote rogue hosts to send
421 spoof answer packets (perhaps unicast to the victim host) which the
422 receiving machine could misinterpret as having originated on the
425 The authors have heard complaints that some older network stack
426 implementations do not implement the IP_RECVTTL socket option
427 (or equivalent API) for obtaining the IP TTL of received packets.
428 This is unfortunate, and these old network stacks would benefit
429 from adding this API support so that they may benefit from this
430 enhanced protection against spoof packets arriving from off-link.
432 Note that Multicast DNS Responders SHOULD NOT discard queries with
433 TTLs other than 255. There may be valid future applications of
434 Multicast DNS where hosts issue unicast queries directed at Multicast
435 DNS Responders more than one hop away, if Multicast DNS Responders
436 were to discard queries where the TTL is not 255, they would not
437 answer these queries.
440 5. Reverse Address Mapping
442 Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also
443 defined to be link-local.
445 Any DNS query for a name ending with "254.169.in-addr.arpa." MUST
446 be sent to the mDNS multicast address 224.0.0.251. Since names under
447 this domain correspond to IPv4 link-local addresses, it is logical
448 that the local link is the best place to find information pertaining
449 to those names. As an optimization, these queries MAY be first
450 unicast directly to the address in question, but if this query is not
451 answered, the query MUST also be sent via multicast, to accommodate
452 the case where the machine in question is not answering for itself
453 (for example, because it is currently sleeping).
455 Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa."
456 MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB,
457 with or without an optional initial query unicast directly to the
464 Expires 29th July 2004 Cheshire & Krochmal [Page 8]
466 Internet Draft Multicast DNS 29th January 2003
471 There are three kinds of Multicast DNS Queries, one-shot queries of
472 the kind made by today's conventional DNS clients, one-shot queries
473 accumulating multiple responses made by multicast-aware DNS clients,
474 and continuous ongoing Multicast DNS Queries used by IP network
477 A Multicast DNS Responder that is offering records that are intended
478 to be unique on the local link MUST also implement a Multicast DNS
479 Querier so that it can first verify the uniqueness of those records
480 before it begins answering queries for them.
485 An unsophisticated DNS client may simply send its DNS queries
486 blindly to the 224.0.0.251 multicast address, without necessarily
487 even being aware what a multicast address is.
489 Such an unsophisticated DNS client may not get ideal behaviour. Such
490 a client may simply take the first response it receives and fail to
491 wait to see if there are more, but in many instances this may not be
492 a serious problem. If a user types "http://stu.local." into their Web
493 browser and gets to see the page they were hoping for, then the
494 protocol has met the user's needs in this case.
497 6.2 One-Shot Queries, Accumulating Multiple Responses
499 A more sophisticated DNS client should understand that Multicast DNS
500 is not exactly the same as unicast DNS, and should modify its
501 behaviour in some simple ways.
503 As described above, there are some cases, such as looking up the
504 address associated with a unique host name, where a single response
505 is sufficient, and moreover may be all that is expected. However,
506 there are other DNS queries where more than one response is
507 possible, and for these queries a more sophisticated Multicast DNS
508 client should include the ability to wait for an appropriate period
509 of time to collect multiple responses.
511 A naive DNS client retransmits its query only so long as it has
512 received no response. A more sophisticated Multicast DNS client is
513 aware that having received one response is not necessarily an
514 indication that it might not receive others, and has the ability to
515 retransmit its query an appropriate number of times at appropriate
516 intervals until it is satisfied with the collection of responses it
522 Expires 29th July 2004 Cheshire & Krochmal [Page 9]
524 Internet Draft Multicast DNS 29th January 2003
527 A more sophisticated Multicast DNS client that is retransmitting
528 a query for which it has already received some responses, MUST
529 implement Known Answer Suppression, as described below in Section
530 7.1. This indicates to responders who have already replied that their
531 responses have been received, and they don't need to send them again
532 in response to this repeated query. In addition, the interval between
533 the first two queries MUST be at least one second, and the
534 intervals between subsequent queries MUST double.
537 6.3 Continuous Querying
539 In One-Shot Queries, with either a single or multiple responses,
540 the underlying assumption is that the transaction begins when the
541 application issues a query, and ends when all the desired responses
542 have been received. There is another type of operation which is more
543 akin to continuous monitoring.
545 Macintosh users are accustomed to opening the "Chooser" window,
546 selecting a desired printer, and then closing the Chooser window.
547 However, when the desired printer does not appear in the list, the
548 user will typically leave the "Chooser" window open while they go and
549 check to verify that the printer is plugged in, powered on, connected
550 to the Ethernet, etc. While the user jiggles the wires, hits the
551 Ethernet hub, and so forth, they keep an eye on the Chooser window,
552 and when the printer name appears, they know they have fixed whatever
553 the problem was. This can be a useful and intuitive troubleshooting
554 technique, but a user who goes home for the weekend leaving the
555 Chooser window open places a non-trivial burden on the network.
557 With continuous querying, multiple queries are sent over a long
558 period of time, until the user terminates the operation. It is
559 important that an IP network browser window displaying live
560 information from the network using Multicast DNS, if left running for
561 an extended period of time, should generate significantly less
562 multicast traffic on the network than the old AppleTalk Chooser.
563 Therefore, the interval between the first two queries MUST be at
564 least one second, the intervals between subsequent queries MUST
565 double, and the querier MUST implement Known Answer Suppression, as
566 described below in Section 7.1.
568 When a Multicast DNS Querier receives an answer, the answer contains
569 a TTL value that indicates for how many seconds this answer is valid.
570 After this interval has passed, the answer will no longer be valid
571 and should be deleted from the cache. Before this time is reached, a
572 Multicast DNS Querier with an ongoing interest in that record SHOULD
573 re-issue its query to determine whether the record is still valid,
574 and if so update its expiry time.
580 Expires 29th July 2004 Cheshire & Krochmal [Page 10]
582 Internet Draft Multicast DNS 29th January 2003
585 To perform this cache maintenance, a Multicast DNS Querier should
586 plan to issue a query at 80% of the record lifetime, and then if no
587 answer is received, at 85%, 90% and 95%. If an answer is received,
588 then the remaining TTL is reset to the value given in the answer, and
589 this process repeats for as long as the Multicast DNS Querier has an
590 ongoing interest in the record. If after four queries no answer is
591 received, the record is deleted when it reaches 100% of its lifetime.
593 To avoid the case where multiple Multicast DNS Queriers on a network
594 all issue their queries simultaneously, a random variation of 2% of
595 the record TTL should be added, so that queries are scheduled to be
596 performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL.
599 6.4 Multiple Questions per Query
601 Multicast DNS allows a querier to place multiple questions in the
602 question section of a single Multicast DNS query packet.
604 The semantics of a Multicast DNS query packet containing multiple
605 questions is identical to a series of individual DNS query packets
606 containing one question each. Combining multiple questions into a
607 single packet is purely an efficiency optimization, and has no other
608 semantic significance.
610 A useful technique for adaptively combining multiple questions into a
611 single query is to use a Nagle-style algorithm: When a client issues
612 its first question, a Query packet is immediately built and sent,
613 without delay. If the client then continues issuing a rapid series of
614 questions they are held until either the first query receives at
615 least one answer, or 100ms has passed, or there are enough questions
616 to fill the question section of a Multicast DNS query packet. At this
617 time, all the held questions are placed into a Multicast DNS query
621 6.5 Questions Requesting Unicast Responses
623 Sending Multicast DNS responses via multicast has the benefit that
624 all the other hosts on the network get to see those responses, and
625 can keep their caches up to date, and detect conflicting responses.
627 However, there are situations where all the other hosts on the
628 network don't need to see every response. One example is a laptop
629 computer waking from sleep. At that instant it is a brand new
630 participant on a new network. Its Multicast DNS cache is empty, and
631 it has no knowledge of its surroundings. It may have a significant
632 number of queries that it wants answered right away to discover
633 information about its new surroundings and present that information
634 to the user. As a new participant on the network, it has no idea
635 whether the exact same questions may have been asked and answered
638 Expires 29th July 2004 Cheshire & Krochmal [Page 11]
640 Internet Draft Multicast DNS 29th January 2003
643 just seconds ago. In this case, trigging a large sudden flood of
644 multicast responses may impose an unreasonable burden on the network.
645 To avoid this, the Multicast DNS Querier SHOULD set the top bit in
646 the class field of its DNS question(s), to indicate that it is
647 willing to accept unicast responses instead of the usual multicast
648 responses. These questions requesting unicast responses are referred
649 to as "QU" questions, to distinguish them from the more usual
650 questions requesting multicast responses ("QM" questions).
652 When retransmitting a question more than once, the 'unicast response'
653 bit SHOULD be set only for the first question of the series. After
654 the first question has received its responses, the querier should
655 have a large known-answer list (see "Known Answer Suppression" below)
656 so that subsequent queries should elicit few, if any, further
657 responses. Reverting to multicast responses as soon as possible is
658 important because of the benefits that multicast responses provide
659 (see "Benefits of Multicast Responses" below).
661 When receiving a question with the 'unicast response' bit set, a
662 responder SHOULD usually respond with a unicast packet directed back
663 to the querier. If the responder has not multicast that record
664 recently (within one quarter of its TTL), then the responder SHOULD
665 instead multicast the response so as to keep all the peer caches up
666 to date, and to permit passive conflict detection.
669 6.6 Suppressing Initial Query
671 If a query is issued for which there already exist one or more
672 records in the local cache, and those record(s) were received with
673 the cache flush bit set, indicating that they form a unique RRSet,
674 then the host SHOULD suppress its initial "QU" query, and proceed to
675 issue a "QM" query. To avoid the situation where a group of hosts
676 are synchronized by some external event and all perform the same
677 query simultaneously, a host suppressing its initial "QU" query
678 SHOULD impose a random delay from 500-1000ms before transmitting its
679 first "QM" query for this question. This means that when the first
680 host (selected randomly by this algorithm) transmits its "QM" query,
681 all the other hosts that were about to transmit the same query can
682 suppress their superfluous query, as described in "Duplicate
683 Question Suppression" below.
696 Expires 29th July 2004 Cheshire & Krochmal [Page 12]
698 Internet Draft Multicast DNS 29th January 2003
701 7. Duplicate Suppression
703 A variety of techniques are used to reduce the amount of redundant
704 traffic on the network.
707 7.1 Known Answer Suppression
709 When a Multicast DNS Querier sends a query to which it already knows
710 some answers, it populates the Answer Section of the DNS message with
713 A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if
714 the answer it would give is already included in the Answer Section
715 with an RR TTL at least half the correct value. If the RR TTL of the
716 answer as given in the Answer Section is less than half of the true
717 RR TTL as known by the Multicast DNS Responder, the responder MUST
718 send an answer so as to update the Querier's cache before the record
719 becomes in danger of expiration.
721 Because a Multicast DNS Responder will respond if the remaining TTL
722 given in the known answer list is less than half the true TTL, it is
723 superfluous for the Querier to include such records in the known
724 answer list. Therefore a Multicast DNS Querier SHOULD NOT include
725 records in the known answer list whose remaining TTL is less than
726 half their original TTL. Doing so would simply consume space in the
727 packet without achieving the goal of suppressing responses, and would
728 therefore be a pointless waste of network bandwidth.
730 A Multicast DNS Querier MUST NOT cache resource records observed in
731 the Known Answer Section of other Multicast DNS Queries. The Answer
732 Section of Multicast DNS Queries is not authoritative. By placing
733 information in the Answer Section of a Multicast DNS Query the
734 querier is stating that it *believes* the information to be true.
735 It is not asserting that the information *is* true. Some of those
736 records may have come from other hosts that are no longer on the
737 network. Propagating that stale information to other Multicast DNS
738 Queriers on the network would not be helpful.
741 7.2 Multi-Packet Known Answer Suppression
743 Sometimes a Multicast DNS Querier will already have too many answers
744 to fit in the Known Answer section of its query packets. In this
745 case, it should issue a Multicast DNS Query containing a question and
746 as many Known Answer records as will fit. It should then set the TC
747 (Truncated) bit in the header before sending the Query. It should
748 then immediately follow the packet with another query containing no
749 questions, and as many more Known Answer records as will fit. If
750 there are still too many records remaining to fit in the packet, it
754 Expires 29th July 2004 Cheshire & Krochmal [Page 13]
756 Internet Draft Multicast DNS 29th January 2003
759 again sets the TC bit and continues until all the Known Answer
760 records have been sent.
762 A Multicast DNS Responder seeing a Multicast DNS Query with the TC
763 bit set defers its response for a time period randomly selected in
764 the interval 20-120ms. This gives the Multicast DNS Querier time to
765 send additional Known Answer packets before the Responder responds.
766 If the Responder sees any of its answers listed in the Known Answer
767 lists of subsequent packets from the querying host, it should delete
768 that answer from the list of answers it is planning to give, provided
769 that no other host on the network is also waiting to receive the same
773 7.3 Duplicate Question Suppression
775 If a host is planning to send a query, and it sees another host on
776 the network send a query containing the same question, and the Known
777 Answer section of that query does not contain any records which this
778 host would not also put in its own Known Answer section, then this
779 host should treat its own query as having been sent. When multiple
780 clients on the network are querying for the same resource records,
781 there is no need for them to all be repeatedly asking the same
785 7.4 Duplicate Answer Suppression
787 If a host is planning to send an answer, and it sees another host on
788 the network send a response packet containing the same answer record,
789 and the TTL in that record is not less than the TTL this host would
790 have given, then this host should treat its own answer as having been
791 sent. When multiple responders on the network have the same data,
792 there is no need for all of them to respond.
794 This feature is particularly useful when multiple Sleep Proxy Servers
795 are deployed (see Section 16. "Multicast DNS and Power Management").
796 In the future it is possible that every general-purpose OS (Mac,
797 Windows, Linux, etc.) will implement Sleep Proxy Service as a matter
798 of course. In this case there could be a large number of Sleep Proxy
799 Servers on any given network, which is good for reliability and
800 fault-tolerance, but would be bad for the network if every Sleep
801 Proxy Server were to answer every query.
812 Expires 29th July 2004 Cheshire & Krochmal [Page 14]
814 Internet Draft Multicast DNS 29th January 2003
819 A Multicast DNS Responder MUST only respond when it has a positive
820 non-null response to send. Error responses must never be sent. The
821 non-existence of any name in a Multicast DNS Domain is ascertained by
822 the failure of any machine to respond to the Multicast DNS query, not
825 Multicast DNS Responses MUST NOT contain any questions in the
826 Question Section. Any questions in the Question Section of a received
827 Multicast DNS Response MUST be silently ignored. Multicast DNS
828 Queriers receiving Multicast DNS Responses do not care what question
829 elicited the response; they care only that the information in the
830 response is true and accurate.
832 A Multicast DNS Responder on Ethernet [IEEE802] and similar shared
833 multiple access networks SHOULD delay its responses by a random
834 amount of time selected with uniform random distribution in the range
835 20-120ms. If multiple Multicast DNS Responders were all to respond
836 immediately to a particular query, a collision would be virtually
837 guaranteed. By imposing a small random delay, the number of
838 collisions is dramatically reduced. 120ms is a short enough time that
839 it is almost imperceptible to a human user, but long enough to
840 significantly reduce the risk of Ethernet collisions. On a full-sized
841 Ethernet using the maximum cable lengths allowed and the maximum
842 number of repeaters allowed, an Ethernet frame is vulnerable to
843 collisions during the transmission of its first 256 bits. On 10Mb/s
844 Ethernet, this equates to a vulnerable time window of 25.6us.
846 In the case where a Multicast DNS Responder has good reason to
847 believe that it will be the only responder on the link with a
848 positive non-null response, it SHOULD NOT impose the random delay
849 before responding, and SHOULD normally generate its response within
850 10ms. To do this safely, it MUST have previously verified that the
851 requested name, type and class in the DNS query are unique on this
852 link. Responding immediately without delay is appropriate for things
853 like looking up the address record for a particular host name, when
854 the host name has been previously verified unique. Responding
855 immediately without delay is *not* appropriate for things like
856 looking up PTR records used for DNS Service Discovery [DNS-SD], where
857 a large number of responses may be anticipated.
859 Except when a unicast reply has been explicitly requested via the
860 "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port
861 5353 (the well-known port assigned to mDNS) on the 224.0.0.251
862 multicast address (or its IPv6 equivalent FF02::FB). Operating in a
863 Zeroconf environment requires constant vigilance. Just because a name
864 has been previously verified unique does not mean it will continue to
865 be so indefinitely. By allowing all Multicast DNS Responders to
866 constantly monitor their peers' responses, conflicts arising out of
867 network topology changes can be promptly detected and resolved.
870 Expires 29th July 2004 Cheshire & Krochmal [Page 15]
872 Internet Draft Multicast DNS 29th January 2003
875 Sending all responses by multicast also facilitates opportunistic
876 caching by other hosts on the network.
878 To protect the network against excessive packet flooding due to
879 software bugs or malicious attack, a Multicast DNS Responder MUST NOT
880 multicast a given record on a given interface if it has previously
881 multicast that record on that interface within the last second. A
882 legitimate client on the network should have seen the previous
883 transmission and cached it. A client that did not receive and cache
884 the previous transmission will retry its request and receive a
885 subsequent response. Under no circumstances is there any legitimate
886 reason for a Multicast DNS Responder to multicast a given record more
887 than once per second on any given interface.
890 8.1 Legacy Unicast Responses
892 If the source UDP port in a received Multicast DNS Query is not port
893 5353, this indicates that the client originating the query is a
894 simple client that does not fully implement all of Multicast DNS. In
895 this case, the Multicast DNS Responder MUST send a UDP response
896 directly back to the client, via unicast, to the query packet's
897 source IP address and port. This unicast response MUST be a
898 conventional unicast response as would be generated by a conventional
899 unicast DNS server; for example, it must repeat the query ID and the
900 question given in the query packet.
902 The resource record TTL given in a unicast response SHOULD NOT be
903 greater than ten seconds, even if the true TTL of the Multicast DNS
904 resource record is higher. This is because Multicast DNS Responders
905 that fully participate in the protocol use the cache coherency
906 mechanisms described in Section 13 to update and invalidate stale
907 data. Were unicast responses sent to legacy clients to use the same
908 high TTLs, these legacy clients, which do not implement these cache
909 coherency mechanisms, could retain stale cached resource record data
910 long after it is no longer valid.
912 Having sent this unicast response, if the Responder has not sent this
913 record in any multicast response recently, it SHOULD schedule the
914 record to be sent via multicast as well, to facilitate passive
915 conflict detection. "Recently" in this context means "if the time
916 since the record was last sent via multicast is less than one quarter
917 of the record's TTL".
928 Expires 29th July 2004 Cheshire & Krochmal [Page 16]
930 Internet Draft Multicast DNS 29th January 2003
933 8.2 Multi-Question Queries
935 Multicast DNS Responders MUST correctly handle DNS query packets
936 containing more than one question, by answering any or all of the
937 questions to which they have answers. Any answers generated
938 in response to query packets containing more than one question
939 MUST be randomly delayed in the range 20-120ms, as described above.
942 8.3 Response Aggregation
944 Having delayed one or more multicast responses by 20-120ms as
945 described above in Section 8 "Responding", a Multicast DNS Responder
946 SHOULD, for the sake of network efficiency, aggregate as many of its
947 pending responses as possible into a single Multicast DNS response
951 9. Probing and Announcing on Startup
953 Typically a Multicast DNS Responder should have, at the very least,
954 address records for all of its active interfaces. Creating and
955 advertising an HINFO record on each interface as well can be useful
956 to network administrators.
958 Whenever a Multicast DNS Responder starts up, wakes up from sleep,
959 receives an indication of an Ethernet "Link Change" event, or has any
960 other reason to believe that its network connectivity may have
961 changed in some relevant way, it MUST perform the two startup steps
967 The first startup step is that for all those resource records that a
968 Multicast DNS Responder desires to be unique on the local link, it
969 MUST send a Multicast DNS Query asking for those resource records, to
970 see if any of them are already in use. The primary example of this is
971 its address record which maps its unique host name to its unique IP
972 address. All Probe Queries SHOULD be done using the desired resource
973 record name and query type T_ANY (255), to elicit answers for all
974 types of records with that name. This allows a single question to be
975 used in place of several questions, which is more efficient on the
976 network. It also allows a host to verify exclusive ownership of a
977 name, which is desirable in most cases. It would be confusing, for
978 example, if one host owned the "A" record for "myhost.local.", but a
979 different host owned the HINFO record for that name.
981 The ability to place more than one question in a Multicast DNS Query
982 is useful here, because it can allow a host to use a single packet
983 for all of its resource records instead of needing a separate packet
986 Expires 29th July 2004 Cheshire & Krochmal [Page 17]
988 Internet Draft Multicast DNS 29th January 2003
991 for each. For example, a host can simultaneously probe for uniqueness
992 of its "A" record and all its SRV records [DNS-SD] in the same query
995 When ready to send its mDNS probe packet(s) the host should first
996 wait for a short random delay time, uniformly distributed in the
997 range 0-250ms. This random delay is to guard against the case where a
998 group of devices are powered on simultaneously, or a group of devices
999 are connected to an Ethernet hub which is then powered on, or some
1000 other external event happens that might cause a group of hosts to all
1001 send synchronized probes.
1003 250ms after the first query the host should send a second, then
1004 250ms after that a third. If, by 250ms after the third probe, no
1005 conflicting Multicast DNS responses have been received, the host may
1006 move to the next step, announcing.
1008 If any conflicting Multicast DNS responses are received, then the
1009 probing host MUST defer to the existing host, and must choose new
1010 names for some or all of its resource records as appropriate, to
1011 avoid conflict with pre-existing hosts on the network. In the case
1012 of a host probing using query type T_ANY as recommended above, any
1013 answer containing a record with that name, of any type, MUST be
1014 considered a conflicting response and handled accordingly.
1016 If ten failures occur within any ten-second period, then the host
1017 MUST wait at least five seconds before each successive additional
1018 probe attempt. This is to help ensure that in the event of software
1019 bugs or other unanticipated problems, errant hosts do not flood the
1020 network with a continuous stream of multicast traffic. For very
1021 simple devices, a valid way to comply with this requirement is to
1022 always wait five seconds after any failed probe attempt.
1025 9.2 Simultaneous Probe Tie-Breaking
1027 The astute reader will observe that there is a race condition
1028 inherent in the previous description. If two hosts are probing for
1029 the same name simultaneously, neither will receive any response to
1030 the probe, and the hosts could incorrectly conclude that they may
1031 both proceed to use the name. To break this symmetry, each host
1032 populates the Authority Section of its queries with records giving
1033 the rdata that it would be proposing to use, should its probing be
1034 successful. The Authority Section is being used here in a way
1035 analogous to the Update section of a DNS Update packet [RFC 2136].
1037 When a host that is probing for a record sees another host issue a
1038 query for the same record, it consults the Authority Section of that
1039 query. If it finds any resource record there which answers the query,
1040 then it compares the data of that resource record with its own
1041 tentative data. The lexicographically later data wins. This means
1044 Expires 29th July 2004 Cheshire & Krochmal [Page 18]
1046 Internet Draft Multicast DNS 29th January 2003
1049 that if the host finds that its own data is lexicographically later,
1050 it simply ignores the other host's probe. If the host finds that its
1051 own data is lexicographically earlier, then it treats this exactly
1052 as if it had received a positive answer to its query, and concludes
1053 that it may not use the desired name.
1055 The determination of 'lexicographically later' is performed by first
1056 comparing the record class, then the record type, then raw comparison
1057 of the binary content of the rdata without regard for meaning or
1058 structure. If the record classes differ, then the numerically greater
1059 class is considered 'lexicographically later'. Otherwise, if the
1060 record types differ, then the numerically greater type is considered
1061 'lexicographically later'. If the type and class both match then the
1064 In the case of resource records containing rdata that is subject to
1065 name compression, the names must be uncompressed before comparison.
1066 (The details of how a particular name is compressed is an artifact of
1067 how and where the record is written into the DNS message; it is not
1068 an intrinsic property of the resource record itself.)
1070 The bytes of the raw uncompressed rdata are compared in turn,
1071 interpreting the bytes as eight-bit UNSIGNED values, until a byte
1072 is found whose value is greater than that of its counterpart (in
1073 which case the rdata whose byte has the greater value is deemed
1074 lexicographically later) or one of the resource records runs out
1075 of rdata (in which case the resource record which still has
1076 remaining data first is deemed lexicographically later).
1078 The following is an example of a conflict:
1080 sctibook.local. A 196.254.100.200
1081 sctibook.local. A 196.254.200.100
1083 In this case 196.254.200.100 is lexicographically later, so it is
1086 Note that it is vital that the bytes are interpreted as UNSIGNED
1087 values, or the wrong outcome may result. In the example above, if
1088 the byte with value 200 had been incorrectly interpreted as a
1089 signed value then it would be interpreted as value -56, and the
1090 wrong address record would be deemed the winner.
1095 The second startup step is that the Multicast DNS Responder MUST send
1096 a gratuitous Multicast DNS Response containing, in the Answer
1097 Section, all of its resource records. If there are too many resource
1098 records to fit in a single packet, multiple packets should be used.
1102 Expires 29th July 2004 Cheshire & Krochmal [Page 19]
1104 Internet Draft Multicast DNS 29th January 2003
1107 In the case of shared records (e.g. the PTR records used by DNS
1108 Service Discovery [DNS-SD]), the records are simply placed as-is
1109 into the answer section of the DNS Response.
1111 In the case of records that have been verified to be unique in the
1112 previous step, they are placed into the answer section of the DNS
1113 Response with the most significant bit of the rrclass set to one. The
1114 most significant bit of the rrclass is the mDNS "cache flush" bit and
1115 is discussed in more detail below in Section 13.3 "Announcements to
1116 Flush Outdated Cache Entries".
1118 The Multicast DNS Responder MUST send at least two gratuitous
1119 responses, one second apart. A Responder MAY send up to ten
1120 gratuitous Responses, providing that the interval between gratuitous
1121 responses doubles with every response sent.
1123 A Multicast DNS Responder SHOULD NOT continue sending gratuitous
1124 Responses for longer than the TTL of the record. The purpose of
1125 announcing new records via gratuitous Responses is to ensure that
1126 peer caches are up to date. After a time interval equal to the TTL of
1127 the record has passed, it is very likely that old stale copies of
1128 that record in peer caches will have expired naturally, so subsequent
1129 announcements serve little purpose.
1131 Whenever a Multicast DNS Responder receives any Multicast DNS
1132 response (gratuitous or otherwise) containing a conflicting resource
1133 record, the conflict MUST be resolved as described below in "Conflict
1136 A Multicast DNS Responder MUST NOT send announcements in the absence
1137 of information that its network connectivity may have changed in some
1138 relevant way. In particular, a Multicast DNS Responder MUST NOT send
1139 regular periodic announcements as a matter of course.
1144 At any time, if the rdata of any of a host's Multicast DNS records
1145 changes, the host MUST repeat the Announcing step described above to
1146 update neighbouring caches. For example, if any of a host's IP
1147 addresses change, it must re-announce those address records.
1149 A host may update the contents of any of its records at any time,
1150 though a host SHOULD NOT update records more frequently than ten
1151 times per minute. Frequent rapid updates impose a burden on the
1152 network. If a host has information to disseminate which changes more
1153 frequently than ten times per minute, then Multicast DNS may not be
1154 the appropriate protocol to disseminate that information.
1160 Expires 29th July 2004 Cheshire & Krochmal [Page 20]
1162 Internet Draft Multicast DNS 29th January 2003
1165 10. Conflict Resolution
1167 A conflict occurs when two resource records with the same name, type
1168 and class have inconsistent rdata. What may be considered
1169 inconsistent is context sensitive, except that resource records with
1170 identical rdata are never considered inconsistent, even if they
1171 originate from different hosts. A common example of a resource record
1172 type that is intended to be unique, not shared between hosts, is the
1173 address record that maps a host's name to its IP address. Should a
1174 host witness another host announce an address record with the same
1175 name but a different IP address, then that is considered
1176 inconsistent, and that address record is considered to be in
1179 Whenever a Multicast DNS Responder receives any Multicast DNS
1180 response (gratuitous or otherwise) containing a conflicting resource
1181 record, the Multicast DNS Responder MUST immediately reset that
1182 record to probing state, and go through the startup steps described
1183 above in Section 9. "Probing and Announcing on Startup". The
1184 protocol used in the Probing phase will determine a winner and a
1185 loser, and the loser must cease using the name, and reconfigure.
1187 It is very important that any host that observes an apparent conflict
1188 MUST take action. In the case of two hosts using the same host name,
1189 where one has been configured to require a unique host name and the
1190 other has not, the one that has not been configured to require a
1191 unique host name will not perceive any conflict, and will not take
1192 any action. By reverting to Probing state, the host that desires a
1193 unique host name will go through the necessary steps to ensure that a
1194 unique host is obtained.
1218 Expires 29th July 2004 Cheshire & Krochmal [Page 21]
1220 Internet Draft Multicast DNS 29th January 2003
1223 The recommended course of action after probing and failing is as
1226 o Programmatically change the resource record name in an attempt to
1227 find a new name that is unique. This could be done by adding some
1228 further identifying information (e.g. the model name of the
1229 hardware) if it is not already present in the name, appending the
1230 digit "2" to the name, or incrementing a number at the end of the
1231 name if one is already present.
1233 o Probe again, and repeat until a unique name is found.
1235 o Record this newly chosen name in persistent storage so that the
1236 device will use the same name the next time it is power-cycled.
1238 o Display a message to the user or operator informing them of the
1239 name change. For example:
1241 The name "Bob's Music" is in use by another iTunes music
1242 server on the network. Your music has been renamed to
1243 "Bob's Music (G4 Cube)". If you want to change this name,
1244 use [describe appropriate menu item or preference dialog].
1246 How the user or operator is informed depends on context. A desktop
1247 computer with a screen might put up a dialog box. A headless server
1248 in the closet may write a message to a log file, or use whatever
1249 mechanism (email, SNMP trap, etc.) it uses to inform the
1250 administrator of other error conditions. On the other hand a headless
1251 server in the closet may not inform the user at all -- if the user
1252 cares, they will notice the name has changed, and connect to the
1253 server in the usual way (e.g. via Web Browser) to configure a new
1256 The examples in this section focus on address records (i.e. host
1257 names), but the same considerations apply to all resource records
1258 where uniqueness (or maintenance of some other defined constraint) is
1276 Expires 29th July 2004 Cheshire & Krochmal [Page 22]
1278 Internet Draft Multicast DNS 29th January 2003
1281 11. Special Characteristics of Multicast DNS Domains
1283 Unlike conventional DNS names, names that end in ".local.",
1284 "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local
1285 significance. Conventional DNS seeks to provide a single unified
1286 namespace, where a given DNS query yields the same answer no matter
1287 where on the planet it is performed or to which recursive DNS server
1288 the query is sent. (However, split views, firewalls, intranets and
1289 the like have somewhat interfered with this goal of DNS representing
1290 a single universal truth.) In contrast, each IP link has its own
1291 private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa."
1292 namespaces, and the answer to any query for a name within those
1293 domains depends on where that query is asked.
1295 Multicast DNS Domains are not delegated from their parent domain via
1296 use of NS records. There are no NS records anywhere in Multicast DNS
1297 Domains. Instead, all Multicast DNS Domains are delegated to the IP
1298 addresses 224.0.0.251 and FF02::FB by virtue of the individual
1299 organizations producing DNS client software deciding how to handle
1300 those names. It would be extremely valuable for the industry if this
1301 special handling were ratified and recorded by IANA, since otherwise
1302 the special handling provided by each vendor is likely to be
1305 The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The
1306 IPv6 name server for a Multicast DNS Domain is FF02::FB. These are
1307 multicast addresses; therefore they identify not a single host but a
1308 collection of hosts, working in cooperation to maintain some
1309 reasonable facsimile of a competently managed DNS zone. Conceptually
1310 a Multicast DNS Domain is a single DNS zone, however its server is
1311 implemented as a distributed process running on a cluster of loosely
1312 cooperating CPUs rather than as a single process running on a single
1315 No delegation is performed within Multicast DNS Domains. Because the
1316 cluster of loosely coordinated CPUs is cooperating to administer a
1317 single zone, delegation is neither necessary nor desirable. Just
1318 because a particular host on the network may answer queries for a
1319 particular record type with the name "example.local." does not imply
1320 anything about whether that host will answer for the name
1321 "child.example.local.", or indeed for other record types with the
1322 name "example.local."
1324 Multicast DNS Zones have no SOA record. A conventional DNS zone's
1325 SOA record contains information such as the email address of the zone
1326 administrator and the monotonically increasing serial number of the
1327 last zone modification. There is no single human administrator for
1328 any given Multicast DNS Zone, so there is no email address. Because
1329 the hosts managing any given Multicast DNS Zone are only loosely
1330 coordinated, there is no readily available monotonically increasing
1331 serial number to determine whether or not the zone contents have
1334 Expires 29th July 2004 Cheshire & Krochmal [Page 23]
1336 Internet Draft Multicast DNS 29th January 2003
1339 changed. A host holding part of the shared zone could crash or be
1340 disconnected from the network at any time without informing the other
1341 hosts. There is no reliable way to provide a zone serial number that
1342 would, whenever such a crash or disconnection occurred, immediately
1343 change to indicate that the contents of the shared zone had changed.
1345 Zone transfers are not possible for any Multicast DNS Zone.
1348 12. Multicast DNS for Service Discovery
1350 This document does not describe using Multicast DNS for network
1351 browsing or service discovery. However, the mechanisms this document
1352 describes are compatible with (and support) the browsing and service
1353 discovery mechanisms proposed in "DNS-Based Service Discovery"
1356 This document places few limitations on what DNS record types may be
1357 looked up using local multicast. One particular kind of Multicast DNS
1358 query that might be useful is a query for the SRV record named
1359 "_domain._udp.local.", yielding the port number and IP address of a
1360 conventional DNS server willing to perform general recursive DNS
1361 lookups. This could solve a particular problem facing the IPv6
1362 community, which is that IPv6 is able to self-configure almost all of
1363 the information it needs to operate [RFC 2462], except for the
1364 address of the DNS server. Bringing in all of the mechanisms of DHCP
1365 just for that one little additional piece of information is not an
1366 attractive solution. Using DNS-format messages and DNS-format
1367 resource records to find the address of the DNS server has an elegant
1368 self-sufficiency about it. Any host that needs to know the address of
1369 the DNS server must already have code to generate and parse DNS
1370 packets, so using that same code and those same packets to find the
1371 DNS server in the first place is a simple self-reliant solution that
1372 avoids taking external dependencies on other protocols.
1375 13. Resource Record TTL Values and Cache Coherency
1377 The recommended TTL value for Multicast DNS resource records is
1380 A client with an active outstanding query will issue a query packet
1381 when one or more of the resource record(s) in its cache is (are) 80%
1382 of the way to expiry. If the TTL on those records is 120 minutes,
1383 this ongoing cache maintenance process yields a steady-state query
1384 rate of one query every 96 minutes.
1386 Any distributed cache needs a cache coherency protocol. If Multicast
1387 DNS resource records follow the recommendation and have a TTL of 120
1388 minutes, that means that stale data could persist in the system for
1389 up to two hours. Making the default TTL significantly lower would
1392 Expires 29th July 2004 Cheshire & Krochmal [Page 24]
1394 Internet Draft Multicast DNS 29th January 2003
1397 reduce the lifetime of stale data, but would produce too much extra
1398 traffic on the network. Various techniques are available to minimize
1399 the impact of such stale data.
1402 13.1 Cooperating Multicast DNS Responders
1404 If a Multicast DNS Responder ("A") observes some other Multicast DNS
1405 Responder ("B") send a Multicast DNS Response packet containing a
1406 resource record with the same name type and class as one of A's
1407 resource records, but different rdata, then:
1409 o If A's resource record is intended to be a shared resource record,
1410 then this is no conflict, and no action is required.
1412 o If A's resource record is intended to be a unique resource record
1413 then this is a conflict and MUST be handled as described in Section
1414 10 "Conflict Resolution".
1416 If a Multicast DNS Responder ("A") observes some other Multicast DNS
1417 Responder ("B") send a Multicast DNS Response packet containing a
1418 resource record with the same name type and class as one of A's
1419 resource records, and identical rdata, then:
1421 o If the TTL of B's resource record given in the packet is at least
1422 half the true TTL from A's point of view, then no action is
1425 o If the TTL of B's resource record given in the packet is less than
1426 half the true TTL from A's point of view, then A MUST mark its
1427 record to be announced via multicast. Clients receiving the record
1428 from B would use the TTL given by B, and hence may delete the
1429 record sooner than A expects. By sending its own multicast response
1430 correcting the TTL, A ensures that the record will be retained for
1433 These rules allow multiple Multicast DNS Responders to offer the same
1434 data on the network (perhaps for fault tolerance reasons) without
1435 conflicting with each other.
1438 13.2 Goodbye Packets
1440 In the case where a host knows that certain resource record data is
1441 about to become invalid (for example when the host is undergoing a
1442 clean shutdown) the host SHOULD send a gratuitous announcement mDNS
1443 response packet, giving the same resource record name, type, class
1444 and rdata, but an RR TTL of zero. This has the effect of updating the
1445 TTL stored in neighbouring hosts' cache entries to zero, causing that
1446 cache entry to be promptly deleted.
1450 Expires 29th July 2004 Cheshire & Krochmal [Page 25]
1452 Internet Draft Multicast DNS 29th January 2003
1455 Clients receiving a Multicast DNS Response with a TTL of zero SHOULD
1456 NOT immediately delete the record from the cache, but instead record
1457 a TTL of 1 and then delete the record one second later. In the case
1458 of multiple Multicast DNS Responders on the network described in
1459 Section 13.1 above, if one of the Responders shuts down and
1460 incorrectly sends goodbye packets for its records, it gives the other
1461 cooperating Responders one second to send out their own response to
1462 "rescue" the records before they expire and are deleted.
1464 Generally speaking, it is more important to send goodbye packets for
1465 shared records than unique records. A given shared record name (such
1466 as a PTR record used for DNS Service Discovery [DNS-SD]) by its
1467 nature often has many representatives from many different hosts, and
1468 tends to be the subject of long-lived ongoing queries. Those
1469 long-lived queries are often concerned not just about being informed
1470 when records appear, but also about being informed if those records
1471 vanish again. In contrast, a unique record set (such as an SRV
1472 record, or a host address record), by its nature, often has far fewer
1473 members than a shared record set, and is usually the subject of
1474 one-shot queries which simply retrieve the data and then cease
1475 querying once they have the answer they are seeking. Therefore,
1476 sending a goodbye packet for a unique record set is likely to offer
1477 less benefit, because it is likely at any given moment that no one
1478 has an active query running for that record set. One example where
1479 goodbye packets for SRV and address records are useful is when
1480 transferring control to a Sleep Proxy Server (see Section 16.
1481 "Multicast DNS and Power Management").
1484 13.3 Announcements to Flush Outdated Cache Entries
1486 Whenever a host has a resource record with potentially new data (e.g.
1487 after rebooting, waking from sleep, connecting to a new network link,
1488 changing IP address, etc.), the host MUST send a series of gratuitous
1489 announcements to update cache entries in its neighbour hosts. In
1490 these gratuitous announcements, if the record is one that is intended
1491 to be unique, the host sets the most significant bit of the rrclass
1492 field of the resource record. This bit, the "cache flush" bit, tells
1493 neighbouring hosts that this is not a shared record type. Instead of
1494 merging this new record additively into the cache in addition to any
1495 previous records with the same name, type and class, all old records
1496 with that name, type and class that were received more than one
1497 second ago are declared invalid, and marked to expire from the cache
1500 The semantics of the cache flush bit are as follows: Normally when a
1501 resource record appears in the answer section of the DNS Response, it
1502 means, "This is an assertion that this information is true." When a
1503 resource record appears in the answer section of the DNS Response
1504 with the "cache flush" bit set, it means, "This is an assertion that
1505 this information is the truth and the whole truth, and anything you
1508 Expires 29th July 2004 Cheshire & Krochmal [Page 26]
1510 Internet Draft Multicast DNS 29th January 2003
1513 may have heard more than a second ago regarding records of this
1514 name/type/class is no longer valid".
1516 To accommodate the case where the set of records from one host
1517 constituting a single unique RRSet is too large to fit in a single
1518 packet, only cache records that are more than one second old are
1519 flushed. This allows the announcing host to generate a quick burst of
1520 packets back-to-back on the wire containing all the members
1521 of the RRSet. When receiving records with the "cache flush" bit set,
1522 all records older than one second are marked to be deleted one second
1523 in the future. One second after the end of the little packet burst,
1524 any records not represented within that packet burst will then be
1525 expired from all peer caches.
1527 Any time a host sends a response packet containing some members of a
1528 unique RRSet, it SHOULD send the entire RRSet, preferably in a single
1529 packet, or if the entire RRSet will not fit in a single packet, in a
1530 quick burst of packets sent as close together as possible. The host
1531 SHOULD set the cache flush bit on all members of the unique RRSet.
1532 In the event that for some reason the host chooses not to send the
1533 entire unique RRSet in a single packet or a rapid packet burst,
1534 it MUST NOT set the cache flush bit on any of those records.
1536 The reason for waiting one second before deleting stale records from
1537 the cache is to accommodate bridged networks. For example, a host's
1538 address record announcement on a wireless interface may be bridged
1539 onto a wired Ethernet, and cause that same host's Ethernet address
1540 records to be flushed from peer caches. The one-second delay gives
1541 the host the chance to see its own announcement arrive on the wired
1542 Ethernet, and immediately re-announce its Ethernet address records
1543 so that both sets remain valid and live in peer caches.
1545 These rules apply regardless of *why* the response packet is being
1546 generated. They apply to startup announcements as described in
1547 Section 9.3, and to responses generated as a result of receiving
1550 The "cache flush" bit is only set in Multicast DNS responses sent to
1551 UDP port 5353. The "cache flush" bit MUST NOT be set in any resource
1552 records in a response packet sent in legacy unicast responses to UDP
1553 ports other than 5353.
1555 The "cache flush" bit MUST NOT be set in any resource records in the
1556 known-answer list of any query packet.
1558 The "cache flush" bit MUST NOT ever be set in any shared resource
1559 record. To do so would cause all the other shared versions of this
1560 resource record with different rdata from different Responders to be
1561 immediately deleted from all the caches on the network.
1566 Expires 29th July 2004 Cheshire & Krochmal [Page 27]
1568 Internet Draft Multicast DNS 29th January 2003
1571 Note that the "cache flush" bit is NOT part of the resource record
1572 class. The "cache flush" bit is the most significant bit of the
1573 second 16-bit word of a resource record in an mDNS packet (the field
1574 conventionally referred to as the rrclass field), and the actual
1575 resource record class is the least-significant fifteen bits of this
1576 field. There is no mDNS resource record class 0x8001. The value
1577 0x8001 in the rrclass field of a resource record in an mDNS response
1578 packet indicates a resource record with class 1, with the "cache
1579 flush" bit set. When receiving a resource record with the "cache
1580 flush" bit set, implementations should take care to mask off that bit
1581 before storing the resource record in memory.
1584 13.4 Cache Flush on Topology change
1586 If the hardware on a given host is able to indicate physical changes
1587 of connectivity, then when the hardware indicates such a change, the
1588 host should take this information into account in its mDNS cache
1589 management strategy. For example, a host may choose to immediately
1590 flush all cache records received on a particular interface when that
1591 cable is disconnected. Alternatively, a host may choose to adjust the
1592 remaining TTL on all those records to a few seconds so that if the
1593 cable is not reconnected quickly, those records will expire from the
1596 Likewise, when a host reboots, or wakes from sleep, or undergoes some
1597 other similar discontinuous state change, the cache management
1598 strategy should take that information into account.
1601 13.5 Cache Flush on Failure Indication
1603 Sometimes a cache record can be determined to be stale when a client
1604 attempts to use the rdata it contains, and finds that rdata to be
1607 For example, the rdata in an address record can be determined to be
1608 incorrect if attempts to contact that host fail, either because
1609 ARP/ND requests for that address go unanswered (for an address on a
1610 local subnet) or because a router returns an ICMP "Host Unreachable"
1611 error (for an address on a remote subnet).
1613 The rdata in an SRV record can be determined to be incorrect if
1614 attempts to communicate with the indicated service at the host and
1615 port number indicated are not successful.
1617 The rdata in a DNS-SD PTR record can be determined to be incorrect if
1618 attempts to look up the SRV record it references are not successful.
1620 In any such case, the software implementing the mDNS resource record
1621 cache should provide a mechanism so that clients detecting stale
1622 rdata can inform the cache.
1624 Expires 29th July 2004 Cheshire & Krochmal [Page 28]
1626 Internet Draft Multicast DNS 29th January 2003
1629 When the cache receives this hint that it should reconfirm some
1630 record, it MUST issue two or more queries for the resource record in
1631 question. If no response is received in a reasonable amount of time,
1632 then, even though its TTL may indicate that it is not yet due to
1633 expire, that record SHOULD be promptly flushed from the cache.
1635 The end result of this is that if a printer suffers a sudden power
1636 failure or other abrupt disconnection from the network, its name may
1637 continue to appear in DNS-SD browser lists displayed on users'
1638 screens. Eventually that entry will expire from the cache naturally,
1639 but if a user tries to access the printer before that happens, the
1640 failure to successfully contact the printer will trigger the more
1641 hasty demise of its cache entries. This is a sensible trade-off
1642 between good user-experience and good network efficiency. If we were
1643 to insist that printers should disappear from the printer list within
1644 30 seconds of becoming unavailable, for all failure modes, the only
1645 way to achieve this would be for the client to poll the printer at
1646 least every 30 seconds, or for the printer to announce its presence
1647 at least every 30 seconds, both of which would be an unreasonable
1648 burden on most networks.
1651 13.6 Passive Observation of Failures
1653 A host observes the multicast queries issued by the other hosts on
1654 the network. One of the major benefits of also sending responses
1655 using multicast is that it allows all hosts to see the responses (or
1656 lack thereof) to those queries.
1658 If a host sees queries, for which a record in its cache would be
1659 expected to be given as an answer in a multicast response, but no
1660 such answer is seen, then the host may take this as an indication
1661 that the record may no longer be valid.
1663 After seeing two or more of these queries, and seeing no multicast
1664 response containing the expected answer within a reasonable amount of
1665 time, then even though its TTL may indicate that it is not yet due to
1666 expire, that record MAY be flushed from the cache. The host SHOULD
1667 NOT perform its own queries to re-confirm that the record is truly
1668 gone. If every host on a large network were to do this, it would
1669 cause a lot of unnecessary multicast traffic. If host A sends
1670 multicast queries that remain unanswered, then there is no reason to
1671 suppose that host B or any other host is likely to be any more
1674 The previous section, "Cache Flush on Failure Indication", describes
1675 a situation where a user trying to print discovers that the printer
1676 is no longer available. By implementing the passive observation
1677 described here, when one user fails to contact the printer, all hosts
1678 on the network observe that failure and update their caches
1682 Expires 29th July 2004 Cheshire & Krochmal [Page 29]
1684 Internet Draft Multicast DNS 29th January 2003
1687 14. Enabling and Disabling Multicast DNS
1689 The option to fail-over to Multicast DNS for names not ending in
1690 ".local." SHOULD be a user-configured option, and SHOULD
1691 be disabled by default because of the possible security issues
1692 related to unintended local resolution of apparently global names.
1694 The option to lookup unqualified (relative) names by appending
1695 ".local." (or not) is controlled by whether ".local." appears
1696 (or not) in the client's DNS search list.
1698 No special control is needed for enabling and disabling Multicast DNS
1699 for names explicitly ending with ".local." as entered by the user.
1700 The user doesn't need a way to disable Multicast DNS for names ending
1701 with ".local.", because if the user doesn't want to use Multicast
1702 DNS, they can achieve this by simply not using those names. If a user
1703 *does* enter a name ending in ".local.", then we can safely assume
1704 the user's intention was probably that it should work. Having user
1705 configuration options that can be (intentionally or unintentionally)
1706 set so that local names don't work is just one more way of
1707 frustrating the user's ability to perform the tasks they want,
1708 perpetuating the view that, "IP networking is too complicated to
1709 configure and too hard to use." This in turn perpetuates the
1710 continued use of protocols like AppleTalk. If we want to retire
1711 AppleTalk, NetBIOS, etc., we need to offer users equivalent IP
1712 functionality that they can rely on to, "always work, like
1713 AppleTalk." A little Multicast DNS traffic may be a burden on the
1714 network, but it is an insignificant burden compared to continued
1715 widespread use of AppleTalk.
1718 15. Considerations for Multiple Interfaces
1720 A host should defend its host name (FQDN) on all active interfaces on
1721 which it is answering Multicast DNS queries.
1723 In the event of a name conflict on *any* interface, a host should
1724 configure a new host name, if it wishes to maintain uniqueness of its
1727 When answering a Multicast DNS query, a multi-homed host with a
1728 link-local address (or addresses) should take care to ensure that
1729 any address going out in a Multicast DNS response is valid for use
1730 on the interface on which the response is going out.
1732 Just as the same link-local IP address may validly be in use
1733 simultaneously on different links by different hosts, the same
1734 link-local host name may validly be in use simultaneously on
1735 different links, and this is not an error. A multi-homed host with
1736 connections to two different links may be able to communicate with
1737 two different hosts that are validly using the same name. While this
1740 Expires 29th July 2004 Cheshire & Krochmal [Page 30]
1742 Internet Draft Multicast DNS 29th January 2003
1745 kind of name duplication should be rare, it means that a host that
1746 wants to fully support this case needs network programming APIs that
1747 allow applications to specify on what interface to perform a
1748 link-local Multicast DNS query, and to discover on what interface a
1749 Multicast DNS response was received.
1752 16. Multicast DNS and Power Management
1754 Many modern network devices have the ability to go into a low-power
1755 mode where only a small part of the Ethernet hardware remains
1756 powered, and the device can be woken up by sending a specially
1757 formatted Ethernet frame which the device's power-management hardware
1760 To make use of this in conjunction with Multicast DNS, the device
1761 first uses DNS-SD to determine if Sleep Proxy Service is available on
1762 the local network. In some networks there may be more than one piece
1763 of hardware implementing Sleep Proxy Service, for fault-tolerance
1766 If the device finds the network has Sleep Proxy Service, the device
1767 transmits two or more gratuitous mDNS announcements setting the TTL
1768 of its relevant resource records to zero, to delete them from
1769 neighbouring caches. The relevant resource records include address
1770 records and SRV records, and other resource records as may apply to a
1771 particular device. The device then communicates all of its remaining
1772 active records, plus the names, types and classes of the deleted
1773 records, to the Sleep Proxy Service(s), along with a copy of the
1774 specific "magic packet" required to wake the device up.
1776 When a Sleep Proxy Service sees an mDNS query for one of the
1777 device's active records (e.g. a DNS-SD PTR record), it answers on
1778 behalf of the device without waking it up. When a Sleep Proxy Service
1779 sees an mDNS query for one of the device's deleted resource
1780 records, it deduces that some client on the network needs to make an
1781 active connection to the device, and sends the specified "magic
1782 packet" to wake the device up. The device then wakes up, reactivates
1783 its deleted resource records, and re-announces them to the network.
1784 The client waiting to connect sees the announcements, learns the
1785 current IP address and port number of the desired service on the
1786 device, and proceeds to connect to it.
1788 The connecting client does not need to be aware of how Sleep Proxy
1789 Service works. Only devices that implement low power mode and wish to
1790 make use of Sleep Proxy Service need to be aware of how that protocol
1793 The reason that a device using a Sleep Proxy Service should send more
1794 than one goodbye packet is that the wakeup message is caused by the
1795 Sleep Proxy Service seeing queries for the device's SRV and/or
1796 address records, and those queries are in turn caused by the records
1798 Expires 29th July 2004 Cheshire & Krochmal [Page 31]
1800 Internet Draft Multicast DNS 29th January 2003
1803 being absent from peer caches. If the records are not deleted from
1804 peer caches, then those peers may use the cached value directly
1805 without querying, and no wakeup message would be generated.
1807 The full specification of mDNS / DNS-SD Sleep Proxy Service
1808 is described in another document [not yet published].
1811 17. Multicast DNS Character Set
1813 Unicast DNS has been plagued by the lack of any support for non-US
1814 characters. Indeed, conventional DNS is usually limited to just
1815 letters, digits and hyphens, with no spaces or other punctuation.
1816 Attempts to remedy this have made slow progress because of the need
1817 to accommodate old buggy legacy implementations.
1819 Multicast DNS is a new protocol and doesn't (yet) have old buggy
1820 legacy implementations to constrain the design choices. Accordingly,
1821 it adopts the obvious simple solution: all names in Multicast DNS are
1822 encoded using UTF-8 [RFC 2279]. For names that are restricted to
1823 letters, digits and hyphens, the UTF-8 encoding is identical to the
1824 US-ASCII encoding, so this is entirely compatible with existing host
1825 names. For characters outside the US-ASCII range, UTF-8 encoding is
1828 Multicast DNS implementations MUST NOT use any other encodings apart
1829 from UTF-8 (US-ASCII being considered a compatible subset of UTF-8).
1831 This point bears repeating: There are various baroque representations
1832 of international text being proposed for Unicast DNS. None of these
1833 representations may be used in Multicast DNS packets. Any text being
1834 represented internally in some other representation MUST be converted
1835 to canonical UTF-8 before being placed in any Multicast DNS packet.
1837 The simple rules for case-insensitivity in Unicast DNS also apply in
1838 Multicast DNS; that is to say, in name comparisons, the lower-case
1839 letters "a" to "z" match their upper-case equivalents "A" to "Z".
1840 Hence, if a client issues a query for an address record with the name
1841 "stuartcheshire.local", then a responder having an address record
1842 with the name "StuartCheshire.local" should issue a response.
1844 No other automatic character equivalence is defined in Multicast DNS.
1845 For example, accented characters are not defined to be automatically
1846 equivalent to their unaccented counterparts. Where automatic
1847 equivalences are desired, this may be achieved through the use of
1848 programmatically-generated CNAME records. For example, if a responder
1849 has an address record for an accented name Y, and a client issues a
1850 query for a name X, where X is the same as Y with all the accents
1851 removed, then the responder may issue a response containing two
1852 resource records: A CNAME record "X CNAME Y", asserting that the
1853 requested name X (unaccented) is an alias for the true (accented)
1854 name Y, followed by the address record for Y.
1856 Expires 29th July 2004 Cheshire & Krochmal [Page 32]
1858 Internet Draft Multicast DNS 29th January 2003
1861 18. Multicast DNS Message Size
1863 RFC 1035 restricts DNS Messages carried by UDP to no more than 512
1864 bytes (not counting the IP or UDP headers). For UDP packets carried
1865 over the wide-area Internet in 1987, this was appropriate. For
1866 link-local multicast packets on today's networks, there is no reason
1867 to retain this restriction. Given that the packets are by definition
1868 link-local, there are no Path MTU issues to consider.
1870 Multicast DNS Messages carried by UDP may be up to the IP MTU of the
1871 physical interface, less the space required for the IP header (20
1872 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
1874 In the case of a single mDNS Resource Record which is too large to
1875 fit in a single MTU-sized multicast response packet, a Multicast DNS
1876 Responder SHOULD send the Resource Record alone, in a single IP
1877 datagram, sent using multiple IP fragments. Resource Records this
1878 large SHOULD be avoided, except in the very rare cases where they
1879 really are the appropriate solution to the problem at hand.
1880 Implementers should be aware that many simple devices do not
1881 re-assemble fragmented IP datagrams, so large Resource Records SHOULD
1882 only be used in specialized cases where the implementer knows that
1883 all receivers implement reassembly.
1885 A Multicast DNS packet larger than the interface MTU, which is sent
1886 using fragments, MUST NOT contain more than one Resource Record.
1888 Even when fragmentation is used, a Multicast DNS packet, including IP
1889 and UDP headers, MUST NOT exceed 9000 bytes.
1892 19. Multicast DNS Message Format
1894 This section describes specific restrictions on the allowable
1895 values for the header fields of a Multicast DNS message.
1897 19.1. ID (Query Identifier)
1899 Multicast DNS clients SHOULD listen for gratuitous responses
1900 issued by hosts booting up (or waking up from sleep or otherwise
1901 joining the network). Since these gratuitous responses may contain a
1902 useful answer to a question for which the client is currently
1903 awaiting an answer, Multicast DNS clients SHOULD examine all received
1904 Multicast DNS response messages for useful answers, without regard to
1905 the contents of the ID field or the question section. In Multicast
1906 DNS, knowing which particular query message (if any) is responsible
1907 for eliciting a particular response message is less interesting than
1908 knowing whether the response message contains useful information.
1910 Multicast DNS clients MAY cache any or all Multicast DNS response
1911 messages they receive, for possible future use, providing of course
1912 that normal TTL aging is performed on these cashed resource records.
1914 Expires 29th July 2004 Cheshire & Krochmal [Page 33]
1916 Internet Draft Multicast DNS 29th January 2003
1919 In multicast query messages, the Query ID SHOULD be set to zero on
1922 In multicast responses, including gratuitous multicast responses, the
1923 Query ID MUST be set to zero on transmission, and MUST be ignored on
1926 In unicast response messages generated specifically in response to a
1927 particular (unicast or multicast) query, the Query ID MUST match the
1928 ID from the query message.
1931 19.2. QR (Query/Response) Bit
1933 In query messages, MUST be zero.
1935 In response messages, MUST be one.
1940 In both multicast query and multicast response messages, MUST be zero
1941 (only standard queries are currently supported over multicast, unless
1942 other queries are allowed by future IETF Standards Action).
1945 19.4. AA (Authoritative Answer) Bit
1947 In query messages, the Authoritative Answer bit MUST be zero on
1948 transmission, and MUST be ignored on reception.
1950 In response messages for Multicast Domains, the Authoritative Answer
1951 bit MUST be set to one (not setting this bit implies there's some
1952 other place where "better" information may be found) and MUST be
1953 ignored on reception.
1956 19.5. TC (Truncated) Bit
1958 In query messages, if the TC bit is set, it means that additional
1959 Known Answer records may be following shortly. A responder MAY choose
1960 to record this fact, and wait for those additional Known Answer
1961 records, before deciding whether to respond. If the TC bit is clear,
1962 it means that the querying host has no additional Known Answers.
1964 In multicast response messages, the TC bit MUST be zero on
1965 transmission, and MUST be ignored on reception.
1967 In legacy unicast response messages, the TC bit has the same meaning
1968 as in conventional unicast DNS: it means that the response was too
1969 large to fit in a single packet, so the client SHOULD re-issue its
1970 query using TCP in order to receive the larger response.
1972 Expires 29th July 2004 Cheshire & Krochmal [Page 34]
1974 Internet Draft Multicast DNS 29th January 2003
1977 19.6. RD (Recursion Desired) Bit
1979 In both multicast query and multicast response messages, the
1980 Recursion Desired bit SHOULD be zero on transmission, and MUST be
1981 ignored on reception.
1984 19.7. RA (Recursion Available) Bit
1986 In both multicast query and multicast response messages, the
1987 Recursion Available bit MUST be zero on transmission, and MUST be
1988 ignored on reception.
1993 In both query and response messages, the Zero bit MUST be zero on
1994 transmission, and MUST be ignored on reception.
1997 19.9. AD (Authentic Data) Bit [RFC 2535]
1999 In query messages the Authentic Data bit MUST be zero on
2000 transmission, and MUST be ignored on reception.
2002 In response messages, the Authentic Data bit MAY be set. Resolvers
2003 receiving response messages with the AD bit set MUST NOT trust the AD
2004 bit unless they trust the source of the message and either have a
2005 secure path to it or use DNS transaction security.
2008 19.10. CD (Checking Disabled) Bit [RFC 2535]
2010 In query messages, a resolver willing to do cryptography SHOULD set
2011 the Checking Disabled bit to permit it to impose its own policies.
2013 In response messages, the Checking Disabled bit MUST be zero on
2014 transmission, and MUST be ignored on reception.
2017 19.11. RCODE (Response Code)
2019 In both multicast query and multicast response messages, the Response
2020 Code MUST be zero on transmission. Multicast DNS messages received
2021 with non-zero Response Codes MUST be silently ignored.
2030 Expires 29th July 2004 Cheshire & Krochmal [Page 35]
2032 Internet Draft Multicast DNS 29th January 2003
2035 20. Choice of UDP Port Number
2037 Arguments were made for and against using Multicast on UDP port 53.
2038 The final decision was to use UDP port 5353. Some of the arguments
2039 for and against are given below.
2042 20.1 Arguments for using UDP port 53:
2044 * This is "just DNS", so it should be the same port.
2046 * There is less work to be done updating old clients to do simple
2047 mDNS queries. Only the destination address need be changed.
2048 In some cases, this can be achieved without any code changes,
2049 just by adding the address 224.0.0.251 to a configuration file.
2052 20.2 Arguments for using a different port (UDP port 5353):
2054 * This is not "just DNS". This is a DNS-like protocol, but different.
2056 * Changing client code to use a different port number is not hard.
2058 * Using the same port number makes it hard to run an mDNS Responder
2059 and a conventional unicast DNS server on the same machine. If a
2060 conventional unicast DNS server wishes to implement mDNS as well,
2061 it can still do that, by opening two sockets. Having two different
2062 port numbers is important to allow this flexibility.
2064 * Some VPN software hijacks all outgoing traffic to port 53 and
2065 redirects it to a special DNS server set up to serve those VPN
2066 clients while they are connected to the corporate network. It is
2067 questionable whether this is the right thing to do, but it is
2068 common, and redirecting link-local multicast DNS packets to a
2069 remote server rarely produces any useful results. It does mean, for
2070 example, that the user becomes unable to access their local network
2071 printer sitting on their desk right next to their computer. Using
2072 a different UDP port eliminates this particular problem.
2074 * On many operating systems, unprivileged clients may not send or
2075 receive packets on low-numbered ports. This means that any client
2076 sending or receiving mDNS packets on port 53 would have to run as
2077 "root", which is an undesirable security risk. Using a higher-
2078 numbered UDP port eliminates this particular problem.
2088 Expires 29th July 2004 Cheshire & Krochmal [Page 36]
2090 Internet Draft Multicast DNS 29th January 2003
2093 21. Summary of Differences Between Multicast DNS and Unicast DNS
2095 The value of Multicast DNS is that it shares, as much as possible,
2096 the familiar APIs, naming syntax, resource record types, etc., of
2097 Unicast DNS. There are of course necessary differences by virtue of
2098 it using Multicast, and by virtue of it operating in a community of
2099 cooperating peers, rather than a precisely defined authoritarian
2100 hierarchy controlled by a strict chain of formal delegations from the
2101 top. These differences are listed below:
2105 * uses UDP port 5353 instead of port 53
2106 * operates in well-defined parts of the DNS namespace
2107 * uses UTF-8, and only UTF-8, to encode resource record names
2108 * defines a clear limit on the maximum legal domain name (255 bytes)
2109 * allows larger UDP packets
2110 * allows more than one question in a query packet
2111 * uses the Answer Section of a query to list Known Answers
2112 * uses the TC bit in a query to indicate additional Known Answers
2113 * uses the Authority Section of a query for probe tie-breaking
2114 * ignores the Query ID field (except for generating legacy responses)
2115 * doesn't require the question to be repeated in the response packet
2116 * uses gratuitous responses to announce new records to the peer group
2117 * defines a "unicast response" bit in the rrclass of query questions
2118 * defines a "cache flush" bit in the rrclass of responses
2119 * uses DNS TTL 0 to indicate that a record has been deleted
2120 * uses IP TTL 255 to verify that answers originated on the local link
2121 * monitors queries to perform Duplicate Question Suppression
2122 * monitors responses to perform Duplicate Answer Suppression...
2123 * ... and Ongoing Conflict Detection
2124 * ... and Opportunistic Caching
2146 Expires 29th July 2004 Cheshire & Krochmal [Page 37]
2148 Internet Draft Multicast DNS 29th January 2003
2151 22. Benefits of Multicast Responses
2153 Some people have argued that sending responses via multicast is
2154 inefficient on the network. In fact the benefits of using multicast
2155 responses result in a net lowering of overall multicast traffic, for
2156 a variety of reasons.
2158 * One multicast response can update the cache on all machines on the
2159 network. If another machine later wants to issue the same query, it
2160 already has the answer in its cache, so it may not need to even
2161 transmit that multicast query on the network at all.
2163 * When more than one machine has the same ongoing long-lived query
2164 running, every machine does not have to transmit its own
2165 independent query. When one machine transmits a query, all the
2166 other hosts see the answers, so they can suppress their own
2169 * When a host sees a multicast query, but does not see the
2170 corresponding multicast response, it can use this information to
2171 promptly delete stale data from its cache. To achieve the same
2172 level of user-interface quality and responsiveness without
2173 multicast responses would require lower cache lifetimes and more
2174 frequent network polling, resulting in a significantly higher
2177 * Multicast responses allow passive conflict detection. Without this
2178 ability, some other conflict detection mechanism would be needed,
2179 imposing its own additional burden on the network.
2204 Expires 29th July 2004 Cheshire & Krochmal [Page 38]
2206 Internet Draft Multicast DNS 29th January 2003
2209 23. IPv6 Considerations
2211 An IPv4-only host and an IPv6-only host behave as "ships that pass in
2212 the night". Even if they are on the same Ethernet, neither is aware
2213 of the other's traffic. For this reason, each physical link may have
2214 *two* unrelated ".local." zones, one for IPv4 and one for IPv6.
2215 Since for practical purposes, a group of IPv4-only hosts and a group
2216 of IPv6-only hosts on the same Ethernet act as if they were on two
2217 entirely separate Ethernet segments, it is unsurprising that their
2218 use of the ".local." zone should occur exactly as it would if
2219 they really were on two entirely separate Ethernet segments.
2221 A dual-stack (v4/v6) host can participate in both ".local."
2222 zones, and should register its name(s) and perform its lookups both
2223 using IPv4 and IPv6. This enables it to reach, and be reached by,
2224 both IPv4-only and IPv6-only hosts. In effect this acts like a
2225 multi-homed host, with one connection to the logical "IPv4 Ethernet
2226 segment", and a connection to the logical "IPv6 Ethernet segment".
2228 23.1 IPv6 Multicast Addresses by Hashing
2230 Some discovery protocols use a range of multicast addresses, and
2231 determine the address to be used by a hash function of the name being
2232 sought. Queries are sent via multicast to the address as indicated by
2233 the hash function, and responses are returned to the querier via
2234 unicast. Particularly in IPv6, where multicast addresses are
2235 extremely plentiful, this approach is frequently advocated.
2237 There are some problems with this:
2239 * When a host has a large number of records with different names, the
2240 host may have to join a large number of multicast groups. This can
2241 place undue burden on the Ethernet hardware, which typically
2242 supports a limited number of multicast addresses efficiently. When
2243 this number is exceeded, the Ethernet hardware may have to resort
2244 to receiving all multicasts and passing them up to the host
2245 software for filtering, thereby defeating the point of using a
2246 multicast address range in the first place.
2248 * Multiple questions cannot be placed in one packet if they don't all
2249 hash to the same multicast address.
2251 * Duplicate Question Suppression doesn't work if queriers are not
2252 seeing each other's queries.
2254 * Duplicate Answer Suppression doesn't work if responders are not
2255 seeing each other's responses.
2257 * Opportunistic Caching doesn't work.
2259 * Ongoing Conflict Detection doesn't work.
2262 Expires 29th July 2004 Cheshire & Krochmal [Page 39]
2264 Internet Draft Multicast DNS 29th January 2003
2267 24. Security Considerations
2269 The algorithm for detecting and resolving name conflicts is, by its
2270 very nature, an algorithm that assumes cooperating participants. Its
2271 purpose is to allow a group of hosts to arrive at a mutually disjoint
2272 set of host names and other DNS resource record names, in the absence
2273 of any central authority to coordinate this or mediate disputes. In
2274 the absence of any higher authority to resolve disputes, the only
2275 alternative is that the participants must work together cooperatively
2276 to arrive at a resolution.
2278 In an environment where the participants are mutually antagonistic
2279 and unwilling to cooperate, other mechanisms are appropriate, like
2280 manually administered DNS.
2282 In an environment where there is a group of cooperating participants,
2283 but there may be other antagonistic participants on the same physical
2284 link, the cooperating participants need to use IPSEC signatures
2285 and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS
2286 messages from trusted participants (which they process as usual) from
2287 mDNS messages from untrusted participants (which they silently
2290 When DNS queries for *global* DNS names are sent to the mDNS
2291 multicast address (during network outages which disrupt communication
2292 with the greater Internet) it is *especially* important to use
2293 DNSSEC, because the user may have the impression that he or she is
2294 communicating with some authentic host, when in fact he or she is
2295 really communicating with some local host that is merely masquerading
2296 as that name. This is less critical for names ending with ".local.",
2297 because the user should be aware that those names have only local
2298 significance and no global authority is implied.
2300 Most computer users neglect to type the trailing dot at the end of a
2301 fully qualified domain name, making it a relative domain name (e.g.
2302 "www.example.com"). In the event of network outage, attempts to
2303 positively resolve the name as entered will fail, resulting in
2304 application of the search list, including ".local.", if present.
2305 A malicious host could masquerade as "www.example.com" by answering
2306 the resulting Multicast DNS query for "www.example.com.local."
2307 To avoid this, a host MUST NOT append the search suffix
2308 ".local.", if present, to any relative (partially qualified)
2309 domain name containing two or more labels. Appending ".local." to
2310 single-label relative domain names is acceptable, since the user
2311 should have no expectation that a single-label domain name will
2320 Expires 29th July 2004 Cheshire & Krochmal [Page 40]
2322 Internet Draft Multicast DNS 29th January 2003
2325 25. IANA Considerations
2327 The IANA has allocated the IPv4 link-local multicast address
2328 224.0.0.251 for the use described in this document.
2330 The IANA has allocated the IPv6 multicast address set FF0X::FB
2331 for the use described in this document.
2333 When this document is published, IANA should designate a list
2334 of domains which are deemed to have only link-local significance,
2335 as described in this document.
2337 No other IANA services are required by this document.
2340 26. Acknowledgements
2342 The concepts described in this document have been explored and
2343 developed with help from Erik Guttman, Paul Vixie, Bill Woodcock,
2349 Copyright (C) The Internet Society January 2004.
2350 All Rights Reserved.
2352 This document and translations of it may be copied and furnished to
2353 others, and derivative works that comment on or otherwise explain it
2354 or assist in its implementation may be prepared, copied, published
2355 and distributed, in whole or in part, without restriction of any
2356 kind, provided that the above copyright notice and this paragraph are
2357 included on all such copies and derivative works. However, this
2358 document itself may not be modified in any way, such as by removing
2359 the copyright notice or references to the Internet Society or other
2360 Internet organizations, except as needed for the purpose of
2361 developing Internet standards in which case the procedures for
2362 copyrights defined in the Internet Standards process must be
2363 followed, or as required to translate it into languages other than
2366 The limited permissions granted above are perpetual and will not be
2367 revoked by the Internet Society or its successors or assigns.
2369 This document and the information contained herein is provided on an
2370 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2371 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2372 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2373 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2374 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2378 Expires 29th July 2004 Cheshire & Krochmal [Page 41]
2380 Internet Draft Multicast DNS 29th January 2003
2383 28. Normative References
2385 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
2386 Facilities", STD 13, RFC 1034, November 1987.
2388 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
2389 Specifications", STD 13, RFC 1035, November 1987.
2391 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
2392 Requirement Levels", RFC 2119, March 1997.
2394 [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
2395 10646", RFC 2279, January 1998.
2398 29. Informative References
2400 [dotlocal] <http://www.dotlocal.org/>
2402 [djbdl] <http://cr.yp.to/djbdns/dot-local.html>
2404 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
2405 Overview and Architecture.
2406 Institute of Electrical and Electronic Engineers,
2407 IEEE Standard 802, 1990.
2409 [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service
2410 Discovery", Internet-Draft (work in progress),
2411 draft-cheshire-dnsext-dns-sd-03.txt, January 2004.
2413 [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
2414 System (DNS UPDATE)", RFC 2136, April 1997.
2416 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address
2417 Autoconfiguration", RFC 2462, December 1998.
2419 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
2420 RFC 2535, March 1999.
2422 [v4LL] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic
2423 Configuration of IPv4 Link-Local Addresses",
2424 Internet-Draft (work in progress),
2425 draft-ietf-zeroconf-ipv4-linklocal-11.txt, January 2004.
2427 [ZC] Williams, A., "Requirements for Automatic Configuration
2428 of IP Hosts", Internet-Draft (work in progress),
2429 draft-ietf-zeroconf-reqts-12.txt, September 2002.
2436 Expires 29th July 2004 Cheshire & Krochmal [Page 42]
2438 Internet Draft Multicast DNS 29th January 2003
2441 30. Author's Addresses
2444 Apple Computer, Inc.
2450 Phone: +1 408 974 3207
2451 EMail: rfc@stuartcheshire.org
2455 Apple Computer, Inc.
2461 Phone: +1 408 974 4368
2462 EMail: marc@apple.com
2494 Expires 29th July 2004 Cheshire & Krochmal [Page 43]