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