1 Internet Engineering Task Force (IETF) S. Cheshire
2 Request for Comments: 6762 M. Krochmal
3 Category: Standards Track Apple Inc.
4 ISSN: 2070-1721 February 2013
5
6
7 Multicast DNS
8
9 Abstract
10
11 As networked devices become smaller, more portable, and more
12 ubiquitous, the ability to operate with less configured
13 infrastructure is increasingly important. In particular, the ability
14 to look up DNS resource record data types (including, but not limited
15 to, host names) in the absence of a conventional managed DNS server
16 is useful.
17
18 Multicast DNS (mDNS) provides the ability to perform DNS-like
19 operations on the local link in the absence of any conventional
20 Unicast DNS server. In addition, Multicast DNS designates a portion
21 of the DNS namespace to be free for local use, without the need to
22 pay any annual fee, and without the need to set up delegations or
23 otherwise configure a conventional DNS server to answer for those
24 names.
25
26 The primary benefits of Multicast DNS names are that (i) they require
27 little or no administration or configuration to set them up, (ii)
28 they work when no infrastructure is present, and (iii) they work
29 during infrastructure failures.
30
31 Status of This Memo
32
33 This is an Internet Standards Track document.
34
35 This document is a product of the Internet Engineering Task Force
36 (IETF). It represents the consensus of the IETF community. It has
37 received public review and has been approved for publication by the
38 Internet Engineering Steering Group (IESG). Further information on
39 Internet Standards is available in Section 2 of RFC 5741.
40
41 Information about the current status of this document, any errata,
42 and how to provide feedback on it may be obtained at
43 http://www.rfc-editor.org/info/rfc6762.
44
45
46
47
48
49
50
51
52 Cheshire & Krochmal Standards Track [Page 1]
53 RFC 6762 Multicast DNS February 2013
54
55
56 Copyright Notice
57
58 Copyright (c) 2013 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 This document may contain material from IETF Documents or IETF
72 Contributions published or made publicly available before November
73 10, 2008. The person(s) controlling the copyright in some of this
74 material may not have granted the IETF Trust the right to allow
75 modifications of such material outside the IETF Standards Process.
76 Without obtaining an adequate license from the person(s) controlling
77 the copyright in such materials, this document may not be modified
78 outside the IETF Standards Process, and derivative works of it may
79 not be created outside the IETF Standards Process, except to format
80 it for publication as an RFC or to translate it into languages other
81 than English.
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Cheshire & Krochmal Standards Track [Page 2]
108 RFC 6762 Multicast DNS February 2013
109
110
111 Table of Contents
112
113 1. Introduction ....................................................4
114 2. Conventions and Terminology Used in This Document ...............4
115 3. Multicast DNS Names .............................................5
116 4. Reverse Address Mapping .........................................7
117 5. Querying ........................................................8
118 6. Responding .....................................................13
119 7. Traffic Reduction ..............................................22
120 8. Probing and Announcing on Startup ..............................25
121 9. Conflict Resolution ............................................31
122 10. Resource Record TTL Values and Cache Coherency ................33
123 11. Source Address Check ..........................................38
124 12. Special Characteristics of Multicast DNS Domains ..............40
125 13. Enabling and Disabling Multicast DNS ..........................41
126 14. Considerations for Multiple Interfaces ........................42
127 15. Considerations for Multiple Responders on the Same Machine ....43
128 16. Multicast DNS Character Set ...................................45
129 17. Multicast DNS Message Size ....................................46
130 18. Multicast DNS Message Format ..................................47
131 19. Summary of Differences between Multicast DNS and Unicast DNS ..51
132 20. IPv6 Considerations ...........................................52
133 21. Security Considerations .......................................52
134 22. IANA Considerations ...........................................53
135 23. Acknowledgments ...............................................56
136 24. References ....................................................56
137 Appendix A. Design Rationale for Choice of UDP Port Number ........60
138 Appendix B. Design Rationale for Not Using Hashed Multicast
139 Addresses .............................................61
140 Appendix C. Design Rationale for Maximum Multicast DNS Name
141 Length ................................................62
142 Appendix D. Benefits of Multicast Responses .......................64
143 Appendix E. Design Rationale for Encoding Negative Responses ......65
144 Appendix F. Use of UTF-8 ..........................................66
145 Appendix G. Private DNS Namespaces ................................67
146 Appendix H. Deployment History ....................................67
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162 Cheshire & Krochmal Standards Track [Page 3]
163 RFC 6762 Multicast DNS February 2013
164
165
166 1. Introduction
167
168 Multicast DNS and its companion technology DNS-Based Service
169 Discovery [RFC6763] were created to provide IP networking with the
170 ease-of-use and autoconfiguration for which AppleTalk was well-known
171 [RFC6760]. When reading this document, familiarity with the concepts
172 of Zero Configuration Networking [Zeroconf] and automatic link-local
173 addressing [RFC3927] [RFC4862] is helpful.
174
175 Multicast DNS borrows heavily from the existing DNS protocol
176 [RFC1034] [RFC1035] [RFC6195], using the existing DNS message
177 structure, name syntax, and resource record types. This document
178 specifies no new operation codes or response codes. This document
179 describes how clients send DNS-like queries via IP multicast, and how
180 a collection of hosts cooperate to collectively answer those queries
181 in a useful manner.
182
183 2. Conventions and Terminology Used in This Document
184
185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
187 document are to be interpreted as described in "Key words for use in
188 RFCs to Indicate Requirement Levels" [RFC2119].
189
190 When this document uses the term "Multicast DNS", it should be taken
191 to mean: "Clients performing DNS-like queries for DNS-like resource
192 records by sending DNS-like UDP query and response messages over IP
193 Multicast to UDP port 5353". The design rationale for selecting UDP
194 port 5353 is discussed in Appendix A.
195
196 This document uses the term "host name" in the strict sense to mean a
197 fully qualified domain name that has an IPv4 or IPv6 address record.
198 It does not use the term "host name" in the commonly used but
199 incorrect sense to mean just the first DNS label of a host's fully
200 qualified domain name.
201
202 A DNS (or mDNS) packet contains an IP Time to Live (TTL) in the IP
203 header, which is effectively a hop-count limit for the packet, to
204 guard against routing loops. Each resource record also contains a
205 TTL, which is the number of seconds for which the resource record may
206 be cached. This document uses the term "IP TTL" to refer to the IP
207 header TTL (hop limit), and the term "RR TTL" or just "TTL" to refer
208 to the resource record TTL (cache lifetime).
209
210 DNS-format messages contain a header, a Question Section, then
211 Answer, Authority, and Additional Record Sections. The Answer,
212 Authority, and Additional Record Sections all hold resource records
213
214
215
216
217 Cheshire & Krochmal Standards Track [Page 4]
218 RFC 6762 Multicast DNS February 2013
219
220
221 in the same format. Where this document describes issues that apply
222 equally to all three sections, it uses the term "Resource Record
223 Sections" to refer collectively to these three sections.
224
225 This document uses the terms "shared" and "unique" when referring to
226 resource record sets [RFC1034]:
227
228 A "shared" resource record set is one where several Multicast DNS
229 responders may have records with the same name, rrtype, and
230 rrclass, and several responders may respond to a particular query.
231
232 A "unique" resource record set is one where all the records with
233 that name, rrtype, and rrclass are conceptually under the control
234 or ownership of a single responder, and it is expected that at
235 most one responder should respond to a query for that name,
236 rrtype, and rrclass. Before claiming ownership of a unique
237 resource record set, a responder MUST probe to verify that no
238 other responder already claims ownership of that set, as described
239 in Section 8.1, "Probing". (For fault-tolerance and other
240 reasons, sometimes it is permissible to have more than one
241 responder answering for a particular "unique" resource record set,
242 but such cooperating responders MUST give answers containing
243 identical rdata for these records. If they do not give answers
244 containing identical rdata, then the probing step will reject the
245 data as being inconsistent with what is already being advertised
246 on the network for those names.)
247
248 Strictly speaking, the terms "shared" and "unique" apply to resource
249 record sets, not to individual resource records. However, it is
250 sometimes convenient to talk of "shared resource records" and "unique
251 resource records". When used this way, the terms should be
252 understood to mean a record that is a member of a "shared" or
253 "unique" resource record set, respectively.
254
255 3. Multicast DNS Names
256
257 A host that belongs to an organization or individual who has control
258 over some portion of the DNS namespace can be assigned a globally
259 unique name within that portion of the DNS namespace, such as,
260 "cheshire.example.com.". For those of us who have this luxury, this
261 works very well. However, the majority of home computer users do not
262 have easy access to any portion of the global DNS namespace within
263 which they have the authority to create names. This leaves the
264 majority of home computers effectively anonymous for practical
265 purposes.
266
267
268
269
270
271
272 Cheshire & Krochmal Standards Track [Page 5]
273 RFC 6762 Multicast DNS February 2013
274
275
276 To remedy this problem, this document allows any computer user to
277 elect to give their computers link-local Multicast DNS host names of
278 the form: "single-dns-label.local.". For example, a laptop computer
279 may answer to the name "MyComputer.local.". Any computer user is
280 granted the authority to name their computer this way, provided that
281 the chosen host name is not already in use on that link. Having
282 named their computer this way, the user has the authority to continue
283 utilizing that name until such time as a name conflict occurs on the
284 link that is not resolved in the user's favor. If this happens, the
285 computer (or its human user) MUST cease using the name, and SHOULD
286 attempt to allocate a new unique name for use on that link. These
287 conflicts are expected to be relatively rare for people who choose
288 reasonably imaginative names, but it is still important to have a
289 mechanism in place to handle them when they happen.
290
291 This document specifies that the DNS top-level domain ".local." is a
292 special domain with special semantics, namely that any fully
293 qualified name ending in ".local." is link-local, and names within
294 this domain are meaningful only on the link where they originate.
295 This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
296 addresses in the FE80::/10 prefix, which are link-local and
297 meaningful only on the link where they originate.
298
299 Any DNS query for a name ending with ".local." MUST be sent to the
300 mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6
301 equivalent FF02::FB). The design rationale for using a fixed
302 multicast address instead of selecting from a range of multicast
303 addresses using a hash function is discussed in Appendix B.
304 Implementers MAY choose to look up such names concurrently via other
305 mechanisms (e.g., Unicast DNS) and coalesce the results in some
306 fashion. Implementers choosing to do this should be aware of the
307 potential for user confusion when a given name can produce different
308 results depending on external network conditions (such as, but not
309 limited to, which name lookup mechanism responds faster).
310
311 It is unimportant whether a name ending with ".local." occurred
312 because the user explicitly typed in a fully qualified domain name
313 ending in ".local.", or because the user entered an unqualified
314 domain name and the host software appended the suffix ".local."
315 because that suffix appears in the user's search list. The ".local."
316 suffix could appear in the search list because the user manually
317 configured it, or because it was received via DHCP [RFC2132] or via
318 any other mechanism for configuring the DNS search list. In this
319 respect the ".local." suffix is treated no differently from any other
320 search domain that might appear in the DNS search list.
321
322
323
324
325
326
327 Cheshire & Krochmal Standards Track [Page 6]
328 RFC 6762 Multicast DNS February 2013
329
330
331 DNS queries for names that do not end with ".local." MAY be sent to
332 the mDNS multicast address, if no other conventional DNS server is
333 available. This can allow hosts on the same link to continue
334 communicating using each other's globally unique DNS names during
335 network outages that disrupt communication with the greater Internet.
336 When resolving global names via local multicast, it is even more
337 important to use DNS Security Extensions (DNSSEC) [RFC4033] or other
338 security mechanisms to ensure that the response is trustworthy.
339 Resolving global names via local multicast is a contentious issue,
340 and this document does not discuss it further, instead concentrating
341 on the issue of resolving local names using DNS messages sent to a
342 multicast address.
343
344 This document recommends a single flat namespace for dot-local host
345 names, (i.e., the names of DNS "A" and "AAAA" records, which map
346 names to IPv4 and IPv6 addresses), but other DNS record types (such
347 as those used by DNS-Based Service Discovery [RFC6763]) may contain
348 as many labels as appropriate for the desired usage, up to a maximum
349 of 255 bytes, plus a terminating zero byte at the end. Name length
350 issues are discussed further in Appendix C.
351
352 Enforcing uniqueness of host names is probably desirable in the
353 common case, but this document does not mandate that. It is
354 permissible for a collection of coordinated hosts to agree to
355 maintain multiple DNS address records with the same name, possibly
356 for load-balancing or fault-tolerance reasons. This document does
357 not take a position on whether that is sensible. It is important
358 that both modes of operation be supported. The Multicast DNS
359 protocol allows hosts to verify and maintain unique names for
360 resource records where that behavior is desired, and it also allows
361 hosts to maintain multiple resource records with a single shared name
362 where that behavior is desired. This consideration applies to all
363 resource records, not just address records (host names). In summary:
364 It is required that the protocol have the ability to detect and
365 handle name conflicts, but it is not required that this ability be
366 used for every record.
367
368 4. Reverse Address Mapping
369
370 Like ".local.", the IPv4 and IPv6 reverse mapping domains are also
371 defined to be link-local:
372
373 Any DNS query for a name ending with "254.169.in-addr.arpa." MUST
374 be sent to the mDNS IPv4 link-local multicast address 224.0.0.251
375 or the mDNS IPv6 multicast address FF02::FB. Since names under
376 this domain correspond to IPv4 link-local addresses, it is logical
377 that the local link is the best place to find information
378 pertaining to those names.
379
380
381
382 Cheshire & Krochmal Standards Track [Page 7]
383 RFC 6762 Multicast DNS February 2013
384
385
386 Likewise, any DNS query for a name within the reverse mapping
387 domains for IPv6 link-local addresses ("8.e.f.ip6.arpa.",
388 "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST
389 be sent to the mDNS IPv6 link-local multicast address FF02::FB or
390 the mDNS IPv4 link-local multicast address 224.0.0.251.
391
392 5. Querying
393
394 There are two kinds of Multicast DNS queries: one-shot queries of the
395 kind made by legacy DNS resolvers, and continuous, ongoing Multicast
396 DNS queries made by fully compliant Multicast DNS queriers, which
397 support asynchronous operations including DNS-Based Service Discovery
398 [RFC6763].
399
400 Except in the rare case of a Multicast DNS responder that is
401 advertising only shared resource records and no unique records, a
402 Multicast DNS responder MUST also implement a Multicast DNS querier
403 so that it can first verify the uniqueness of those records before it
404 begins answering queries for them.
405
406 5.1. One-Shot Multicast DNS Queries
407
408 The most basic kind of Multicast DNS client may simply send standard
409 DNS queries blindly to 224.0.0.251:5353, without necessarily even
410 being aware of what a multicast address is. This change can
411 typically be implemented with just a few lines of code in an existing
412 DNS resolver library. If a name being queried falls within one of
413 the reserved Multicast DNS domains (see Sections 3 and 4), then,
414 rather than using the configured Unicast DNS server address, the
415 query is instead sent to 224.0.0.251:5353 (or its IPv6 equivalent
416 [FF02::FB]:5353). Typically, the timeout would also be shortened to
417 two or three seconds. It's possible to make a minimal Multicast DNS
418 resolver with only these simple changes. These queries are typically
419 done using a high-numbered ephemeral UDP source port, but regardless
420 of whether they are sent from a dynamic port or from a fixed port,
421 these queries MUST NOT be sent using UDP source port 5353, since
422 using UDP source port 5353 signals the presence of a fully compliant
423 Multicast DNS querier, as described below.
424
425 A simple DNS resolver like this will typically just take the first
426 response it receives. It will not listen for additional UDP
427 responses, but in many instances this may not be a serious problem.
428 If a user types "http://MyPrinter.local." into their web browser, and
429 their simple DNS resolver just takes the first response it receives,
430 and the user gets to see the status and configuration web page for
431 their printer, then the protocol has met the user's needs in this
432 case.
433
434
435
436
437 Cheshire & Krochmal Standards Track [Page 8]
438 RFC 6762 Multicast DNS February 2013
439
440
441 While a basic DNS resolver like this may be adequate for simple host
442 name lookup, it may not get ideal behavior in other cases.
443 Additional refinements to create a fully compliant Multicast DNS
444 querier are described below.
445
446 5.2. Continuous Multicast DNS Querying
447
448 In one-shot queries, the underlying assumption is that the
449 transaction begins when the application issues a query, and ends when
450 the first response is received. There is another type of query
451 operation that is more asynchronous, in which having received one
452 response is not necessarily an indication that there will be no more
453 relevant responses, and the querying operation continues until no
454 further responses are required. Determining when no further
455 responses are required depends on the type of operation being
456 performed. If the operation is looking up the IPv4 and IPv6
457 addresses of another host, then no further responses are required
458 once a successful connection has been made to one of those IPv4 or
459 IPv6 addresses. If the operation is browsing to present the user
460 with a list of DNS-SD services found on the network [RFC6763], then
461 no further responses are required once the user indicates this to the
462 user-interface software, e.g., by closing the network browsing window
463 that was displaying the list of discovered services.
464
465 Imagine some hypothetical software that allows users to discover
466 network printers. The user wishes to discover all printers on the
467 local network, not only the printer that is quickest to respond.
468 When the user is actively looking for a network printer to use, they
469 open a network browsing window that displays the list of discovered
470 printers. It would be convenient for the user if they could rely on
471 this list of network printers to stay up to date as network printers
472 come and go, rather than displaying out-of-date stale information,
473 and requiring the user explicitly to click a "refresh" button any
474 time they want to see accurate information (which, from the moment it
475 is displayed, is itself already beginning to become out-of-date and
476 stale). If we are to display a continuously updated live list like
477 this, we need to be able to do it efficiently, without naive constant
478 polling, which would be an unreasonable burden on the network. It is
479 not expected that all users will be browsing to discover new printers
480 all the time, but when a user is browsing to discover service
481 instances for an extended period, we want to be able to support that
482 operation efficiently.
483
484 Therefore, when retransmitting Multicast DNS queries to implement
485 this kind of continuous monitoring, the interval between the first
486 two queries MUST be at least one second, the intervals between
487 successive queries MUST increase by at least a factor of two, and the
488 querier MUST implement Known-Answer Suppression, as described below
489
490
491
492 Cheshire & Krochmal Standards Track [Page 9]
493 RFC 6762 Multicast DNS February 2013
494
495
496 in Section 7.1. The Known-Answer Suppression mechanism tells
497 responders which answers are already known to the querier, thereby
498 allowing responders to avoid wasting network capacity with pointless
499 repeated transmission of those answers. A querier retransmits its
500 question because it wishes to receive answers it may have missed the
501 first time, not because it wants additional duplicate copies of
502 answers it already received. Failure to implement Known-Answer
503 Suppression can result in unacceptable levels of network traffic.
504 When the interval between queries reaches or exceeds 60 minutes, a
505 querier MAY cap the interval to a maximum of 60 minutes, and perform
506 subsequent queries at a steady-state rate of one query per hour. To
507 avoid accidental synchronization when, for some reason, multiple
508 clients begin querying at exactly the same moment (e.g., because of
509 some common external trigger event), a Multicast DNS querier SHOULD
510 also delay the first query of the series by a randomly chosen amount
511 in the range 20-120 ms.
512
513 When a Multicast DNS querier receives an answer, the answer contains
514 a TTL value that indicates for how many seconds this answer is valid.
515 After this interval has passed, the answer will no longer be valid
516 and SHOULD be deleted from the cache. Before the record expiry time
517 is reached, a Multicast DNS querier that has local clients with an
518 active interest in the state of that record (e.g., a network browsing
519 window displaying a list of discovered services to the user) SHOULD
520 reissue its query to determine whether the record is still valid.
521
522 To perform this cache maintenance, a Multicast DNS querier should
523 plan to retransmit its query after at least 50% of the record
524 lifetime has elapsed. This document recommends the following
525 specific strategy.
526
527 The querier should plan to issue a query at 80% of the record
528 lifetime, and then if no answer is received, at 85%, 90%, and 95%.
529 If an answer is received, then the remaining TTL is reset to the
530 value given in the answer, and this process repeats for as long as
531 the Multicast DNS querier has an ongoing interest in the record. If
532 no answer is received after four queries, the record is deleted when
533 it reaches 100% of its lifetime. A Multicast DNS querier MUST NOT
534 perform this cache maintenance for records for which it has no local
535 clients with an active interest. If the expiry of a particular
536 record from the cache would result in no net effect to any client
537 software running on the querier device, and no visible effect to the
538 human user, then there is no reason for the Multicast DNS querier to
539 waste network capacity checking whether the record remains valid.
540
541
542
543
544
545
546
547 Cheshire & Krochmal Standards Track [Page 10]
548 RFC 6762 Multicast DNS February 2013
549
550
551 To avoid the case where multiple Multicast DNS queriers on a network
552 all issue their queries simultaneously, a random variation of 2% of
553 the record TTL should be added, so that queries are scheduled to be
554 performed at 80-82%, 85-87%, 90-92%, and then 95-97% of the TTL.
555
556 An additional efficiency optimization SHOULD be performed when a
557 Multicast DNS response is received containing a unique answer (as
558 indicated by the cache-flush bit being set, described in Section
559 10.2, "Announcements to Flush Outdated Cache Entries"). In this
560 case, there is no need for the querier to continue issuing a stream
561 of queries with exponentially increasing intervals, since the receipt
562 of a unique answer is a good indication that no other answers will be
563 forthcoming. In this case, the Multicast DNS querier SHOULD plan to
564 issue its next query for this record at 80-82% of the record's TTL,
565 as described above.
566
567 A compliant Multicast DNS querier, which implements the rules
568 specified in this document, MUST send its Multicast DNS queries from
569 UDP source port 5353 (the well-known port assigned to mDNS), and MUST
570 listen for Multicast DNS replies sent to UDP destination port 5353 at
571 the mDNS link-local multicast address (224.0.0.251 and/or its IPv6
572 equivalent FF02::FB).
573
574 5.3. Multiple Questions per Query
575
576 Multicast DNS allows a querier to place multiple questions in the
577 Question Section of a single Multicast DNS query message.
578
579 The semantics of a Multicast DNS query message containing multiple
580 questions is identical to a series of individual DNS query messages
581 containing one question each. Combining multiple questions into a
582 single message is purely an efficiency optimization and has no other
583 semantic significance.
584
585 5.4. Questions Requesting Unicast Responses
586
587 Sending Multicast DNS responses via multicast has the benefit that
588 all the other hosts on the network get to see those responses,
589 enabling them to keep their caches up to date and detect conflicting
590 responses.
591
592 However, there are situations where all the other hosts on the
593 network don't need to see every response. Some examples are a laptop
594 computer waking from sleep, the Ethernet cable being connected to a
595 running machine, or a previously inactive interface being activated
596 through a configuration change. At the instant of wake-up or link
597 activation, the machine is a brand new participant on a new network.
598 Its Multicast DNS cache for that interface is empty, and it has no
599
600
601
602 Cheshire & Krochmal Standards Track [Page 11]
603 RFC 6762 Multicast DNS February 2013
604
605
606 knowledge of its peers on that link. It may have a significant
607 number of questions that it wants answered right away, to discover
608 information about its new surroundings and present that information
609 to the user. As a new participant on the network, it has no idea
610 whether the exact same questions may have been asked and answered
611 just seconds ago. In this case, triggering a large sudden flood of
612 multicast responses may impose an unreasonable burden on the network.
613
614 To avoid large floods of potentially unnecessary responses in these
615 cases, Multicast DNS defines the top bit in the class field of a DNS
616 question as the unicast-response bit. When this bit is set in a
617 question, it indicates that the querier is willing to accept unicast
618 replies in response to this specific query, as well as the usual
619 multicast responses. These questions requesting unicast responses
620 are referred to as "QU" questions, to distinguish them from the more
621 usual questions requesting multicast responses ("QM" questions). A
622 Multicast DNS querier sending its initial batch of questions
623 immediately on wake from sleep or interface activation SHOULD set the
624 unicast-response bit in those questions.
625
626 When a question is retransmitted (as described in Section 5.2), the
627 unicast-response bit SHOULD NOT be set in subsequent retransmissions
628 of that question. Subsequent retransmissions SHOULD be usual "QM"
629 questions. After the first question has received its responses, the
630 querier should have a large Known-Answer list (Section 7.1) so that
631 subsequent queries should elicit few, if any, further responses.
632 Reverting to multicast responses as soon as possible is important
633 because of the benefits that multicast responses provide (see
634 Appendix D). In addition, the unicast-response bit SHOULD be set
635 only for questions that are active and ready to be sent the moment of
636 wake from sleep or interface activation. New questions created by
637 local clients afterwards should be treated as normal "QM" questions
638 and SHOULD NOT have the unicast-response bit set on the first
639 question of the series.
640
641 When receiving a question with the unicast-response bit set, a
642 responder SHOULD usually respond with a unicast packet directed back
643 to the querier. However, if the responder has not multicast that
644 record recently (within one quarter of its TTL), then the responder
645 SHOULD instead multicast the response so as to keep all the peer
646 caches up to date, and to permit passive conflict detection. In the
647 case of answering a probe question (Section 8.1) with the unicast-
648 response bit set, the responder should always generate the requested
649 unicast response, but it may also send a multicast announcement if
650 the time since the last multicast announcement of that record is more
651 than a quarter of its TTL.
652
653
654
655
656
657 Cheshire & Krochmal Standards Track [Page 12]
658 RFC 6762 Multicast DNS February 2013
659
660
661 Unicast replies are subject to all the same packet generation rules
662 as multicast replies, including the cache-flush bit (Section 10.2)
663 and (except when defending a unique name against a probe from another
664 host) randomized delays to reduce network collisions (Section 6).
665
666 5.5. Direct Unicast Queries to Port 5353
667
668 In specialized applications there may be rare situations where it
669 makes sense for a Multicast DNS querier to send its query via unicast
670 to a specific machine. When a Multicast DNS responder receives a
671 query via direct unicast, it SHOULD respond as it would for "QU"
672 questions, as described above in Section 5.4. Since it is possible
673 for a unicast query to be received from a machine outside the local
674 link, responders SHOULD check that the source address in the query
675 packet matches the local subnet for that link (or, in the case of
676 IPv6, the source address has an on-link prefix) and silently ignore
677 the packet if not.
678
679 There may be specialized situations, outside the scope of this
680 document, where it is intended and desirable to create a responder
681 that does answer queries originating outside the local link. Such a
682 responder would need to ensure that these non-local queries are
683 always answered via unicast back to the querier, since an answer sent
684 via link-local multicast would not reach a querier outside the local
685 link.
686
687 6. Responding
688
689 When a Multicast DNS responder constructs and sends a Multicast DNS
690 response message, the Resource Record Sections of that message must
691 contain only records for which that responder is explicitly
692 authoritative. These answers may be generated because the record
693 answers a question received in a Multicast DNS query message, or at
694 certain other times that the responder determines than an unsolicited
695 announcement is warranted. A Multicast DNS responder MUST NOT place
696 records from its cache, which have been learned from other responders
697 on the network, in the Resource Record Sections of outgoing response
698 messages. Only an authoritative source for a given record is allowed
699 to issue responses containing that record.
700
701 The determination of whether a given record answers a given question
702 is made using the standard DNS rules: the record name must match the
703 question name, the record rrtype must match the question qtype unless
704 the qtype is "ANY" (255) or the rrtype is "CNAME" (5), and the record
705 rrclass must match the question qclass unless the qclass is "ANY"
706 (255). As with Unicast DNS, generally only DNS class 1 ("Internet")
707 is used, but should client software use classes other than 1, the
708 matching rules described above MUST be used.
709
710
711
712 Cheshire & Krochmal Standards Track [Page 13]
713 RFC 6762 Multicast DNS February 2013
714
715
716 A Multicast DNS responder MUST only respond when it has a positive,
717 non-null response to send, or it authoritatively knows that a
718 particular record does not exist. For unique records, where the host
719 has already established sole ownership of the name, it MUST return
720 negative answers to queries for records that it knows not to exist.
721 For example, a host with no IPv6 address, that has claimed sole
722 ownership of the name "host.local." for all rrtypes, MUST respond to
723 AAAA queries for "host.local." by sending a negative answer
724 indicating that no AAAA records exist for that name. See Section
725 6.1, "Negative Responses". For shared records, which are owned by no
726 single host, the nonexistence of a given record is ascertained by the
727 failure of any machine to respond to the Multicast DNS query, not by
728 any explicit negative response. For shared records, NXDOMAIN and
729 other error responses MUST NOT be sent.
730
731 Multicast DNS responses MUST NOT contain any questions in the
732 Question Section. Any questions in the Question Section of a
733 received Multicast DNS response MUST be silently ignored. Multicast
734 DNS queriers receiving Multicast DNS responses do not care what
735 question elicited the response; they care only that the information
736 in the response is true and accurate.
737
738 A Multicast DNS responder on Ethernet [IEEE.802.3] and similar shared
739 multiple access networks SHOULD have the capability of delaying its
740 responses by up to 500 ms, as described below.
741
742 If a large number of Multicast DNS responders were all to respond
743 immediately to a particular query, a collision would be virtually
744 guaranteed. By imposing a small random delay, the number of
745 collisions is dramatically reduced. On a full-sized Ethernet using
746 the maximum cable lengths allowed and the maximum number of repeaters
747 allowed, an Ethernet frame is vulnerable to collisions during the
748 transmission of its first 256 bits. On 10 Mb/s Ethernet, this
749 equates to a vulnerable time window of 25.6 microseconds. On higher-
750 speed variants of Ethernet, the vulnerable time window is shorter.
751
752 In the case where a Multicast DNS responder has good reason to
753 believe that it will be the only responder on the link that will send
754 a response (i.e., because it is able to answer every question in the
755 query message, and for all of those answer records it has previously
756 verified that the name, rrtype, and rrclass are unique on the link),
757 it SHOULD NOT impose any random delay before responding, and SHOULD
758 normally generate its response within at most 10 ms. In particular,
759 this applies to responding to probe queries with the unicast-response
760 bit set. Since receiving a probe query gives a clear indication that
761 some other responder is planning to start using this name in the very
762 near future, answering such probe queries to defend a unique record
763 is a high priority and needs to be done without delay. A probe query
764
765
766
767 Cheshire & Krochmal Standards Track [Page 14]
768 RFC 6762 Multicast DNS February 2013
769
770
771 can be distinguished from a normal query by the fact that a probe
772 query contains a proposed record in the Authority Section that
773 answers the question in the Question Section (for more details, see
774 Section 8.2, "Simultaneous Probe Tiebreaking").
775
776 Responding without delay is appropriate for records like the address
777 record for a particular host name, when the host name has been
778 previously verified unique. Responding without delay is *not*
779 appropriate for things like looking up PTR records used for DNS-Based
780 Service Discovery [RFC6763], where a large number of responses may be
781 anticipated.
782
783 In any case where there may be multiple responses, such as queries
784 where the answer is a member of a shared resource record set, each
785 responder SHOULD delay its response by a random amount of time
786 selected with uniform random distribution in the range 20-120 ms.
787 The reason for requiring that the delay be at least 20 ms is to
788 accommodate the situation where two or more query packets are sent
789 back-to-back, because in that case we want a responder with answers
790 to more than one of those queries to have the opportunity to
791 aggregate all of its answers into a single response message.
792
793 In the case where the query has the TC (truncated) bit set,
794 indicating that subsequent Known-Answer packets will follow,
795 responders SHOULD delay their responses by a random amount of time
796 selected with uniform random distribution in the range 400-500 ms, to
797 allow enough time for all the Known-Answer packets to arrive, as
798 described in Section 7.2, "Multipacket Known-Answer Suppression".
799
800 The source UDP port in all Multicast DNS responses MUST be 5353 (the
801 well-known port assigned to mDNS). Multicast DNS implementations
802 MUST silently ignore any Multicast DNS responses they receive where
803 the source UDP port is not 5353.
804
805 The destination UDP port in all Multicast DNS responses MUST be 5353,
806 and the destination address MUST be the mDNS IPv4 link-local
807 multicast address 224.0.0.251 or its IPv6 equivalent FF02::FB, except
808 when generating a reply to a query that explicitly requested a
809 unicast response:
810
811 * via the unicast-response bit,
812 * by virtue of being a legacy query (Section 6.7), or
813 * by virtue of being a direct unicast query.
814
815 Except for these three specific cases, responses MUST NOT be sent via
816 unicast, because then the "Passive Observation of Failures"
817 mechanisms described in Section 10.5 would not work correctly. Other
818
819
820
821
822 Cheshire & Krochmal Standards Track [Page 15]
823 RFC 6762 Multicast DNS February 2013
824
825
826 benefits of sending responses via multicast are discussed in Appendix
827 D. A Multicast DNS querier MUST only accept unicast responses if
828 they answer a recently sent query (e.g., sent within the last two
829 seconds) that explicitly requested unicast responses. A Multicast
830 DNS querier MUST silently ignore all other unicast responses.
831
832 To protect the network against excessive packet flooding due to
833 software bugs or malicious attack, a Multicast DNS responder MUST NOT
834 (except in the one special case of answering probe queries) multicast
835 a record on a given interface until at least one second has elapsed
836 since the last time that record was multicast on that particular
837 interface. A legitimate querier on the network should have seen the
838 previous transmission and cached it. A querier that did not receive
839 and cache the previous transmission will retry its request and
840 receive a subsequent response. In the special case of answering
841 probe queries, because of the limited time before the probing host
842 will make its decision about whether or not to use the name, a
843 Multicast DNS responder MUST respond quickly. In this special case
844 only, when responding via multicast to a probe, a Multicast DNS
845 responder is only required to delay its transmission as necessary to
846 ensure an interval of at least 250 ms since the last time the record
847 was multicast on that interface.
848
849 6.1. Negative Responses
850
851 In the early design of Multicast DNS it was assumed that explicit
852 negative responses would never be needed. A host can assert the
853 existence of the set of records that it claims to exist, and the
854 union of all such sets on a link is the set of Multicast DNS records
855 that exist on that link. Asserting the nonexistence of every record
856 in the complement of that set -- i.e., all possible Multicast DNS
857 records that could exist on this link but do not at this moment --
858 was felt to be impractical and unnecessary. The nonexistence of a
859 record would be ascertained by a querier querying for it and failing
860 to receive a response from any of the hosts currently attached to the
861 link.
862
863 However, operational experience showed that explicit negative
864 responses can sometimes be valuable. One such example is when a
865 querier is querying for a AAAA record, and the host name in question
866 has no associated IPv6 addresses. In this case, the responding host
867 knows it currently has exclusive ownership of that name, and it knows
868 that it currently does not have any IPv6 addresses, so an explicit
869 negative response is preferable to the querier having to retransmit
870 its query multiple times, and eventually give up with a timeout,
871 before it can conclude that a given AAAA record does not exist.
872
873
874
875
876
877 Cheshire & Krochmal Standards Track [Page 16]
878 RFC 6762 Multicast DNS February 2013
879
880
881 Any time a responder receives a query for a name for which it has
882 verified exclusive ownership, for a type for which that name has no
883 records, the responder MUST (except as allowed in (a) below) respond
884 asserting the nonexistence of that record using a DNS NSEC record
885 [RFC4034]. In the case of Multicast DNS the NSEC record is not being
886 used for its usual DNSSEC [RFC4033] security properties, but simply
887 as a way of expressing which records do or do not exist with a given
888 name.
889
890 On receipt of a question for a particular name, rrtype, and rrclass,
891 for which a responder does have one or more unique answers, the
892 responder MAY also include an NSEC record in the Additional Record
893 Section indicating the nonexistence of other rrtypes for that name
894 and rrclass.
895
896 Implementers working with devices with sufficient memory and CPU
897 resources MAY choose to implement code to handle the full generality
898 of the DNS NSEC record [RFC4034], including bitmaps up to 65,536 bits
899 long. To facilitate use by devices with limited memory and CPU
900 resources, Multicast DNS queriers are only REQUIRED to be able to
901 parse a restricted form of the DNS NSEC record. All compliant
902 Multicast DNS implementations MUST at least correctly generate and
903 parse the restricted DNS NSEC record format described below:
904
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
905 o The 'Next Domain Name' field contains the record's own name.
906 When used with name compression, this means that the 'Next
907 Domain Name' field always takes exactly two bytes in the
908 message.
909
910 o The Type Bit Map block number is 0.
911
912 o The Type Bit Map block length byte is a value in the range 1-32.
913
914 o The Type Bit Map data is 1-32 bytes, as indicated by length
915 byte.
916
917 Because this restricted form of the DNS NSEC record is limited to
918 Type Bit Map block number zero, it cannot express the existence of
919 rrtypes above 255. Consequently, if a Multicast DNS responder were
920 to have records with rrtypes above 255, it MUST NOT generate these
921 restricted-form NSEC records for those names, since to do so would
922 imply that the name has no records with rrtypes above 255, which
923 would be false. In such cases a Multicast DNS responder MUST either
924 (a) emit no NSEC record for that name, or (b) emit a full NSEC record
925 containing the appropriate Type Bit Map block(s) with the correct
926 bits set for all the record types that exist. In practice this is
927 not a significant limitation, since rrtypes above 255 are not
928 currently in widespread use.
929
930
931
932 Cheshire & Krochmal Standards Track [Page 17]
933 RFC 6762 Multicast DNS February 2013
934
935
936 If a Multicast DNS implementation receives an NSEC record where the
937 'Next Domain Name' field is not the record's own name, then the
938 implementation SHOULD ignore the 'Next Domain Name' field and process
939 the remainder of the NSEC record as usual. In Multicast DNS the
940 'Next Domain Name' field is not currently used, but it could be used
941 in a future version of this protocol, which is why a Multicast DNS
942 implementation MUST NOT reject or ignore an NSEC record it receives
943 just because it finds an unexpected value in the 'Next Domain Name'
944 field.
945
946 If a Multicast DNS implementation receives an NSEC record containing
947 more than one Type Bit Map, or where the Type Bit Map block number is
948 not zero, or where the block length is not in the range 1-32, then
949 the Multicast DNS implementation MAY silently ignore the entire NSEC
950 record. A Multicast DNS implementation MUST NOT ignore an entire
951 message just because that message contains one or more NSEC record(s)
952 that the Multicast DNS implementation cannot parse. This provision
953 is to allow future enhancements to the protocol to be introduced in a
954 backwards-compatible way that does not break compatibility with older
955 Multicast DNS implementations.
956
957 To help differentiate these synthesized NSEC records (generated
958 programmatically on-the-fly) from conventional Unicast DNS NSEC
959 records (which actually exist in a signed DNS zone), the synthesized
960 Multicast DNS NSEC records MUST NOT have the NSEC bit set in the Type
961 Bit Map, whereas conventional Unicast DNS NSEC records do have the
962 NSEC bit set.
963
964 The TTL of the NSEC record indicates the intended lifetime of the
965 negative cache entry. In general, the TTL given for an NSEC record
966 SHOULD be the same as the TTL that the record would have had, had it
967 existed. For example, the TTL for address records in Multicast DNS
968 is typically 120 seconds (see Section 10), so the negative cache
969 lifetime for an address record that does not exist should also be 120
970 seconds.
971
972 A responder MUST only generate negative responses to queries for
973 which it has legitimate ownership of the name, rrtype, and rrclass in
974 question, and can legitimately assert that no record with that name,
975 rrtype, and rrclass exists. A responder can assert that a specified
976 rrtype does not exist for one of its names if it knows a priori that
977 it has exclusive ownership of that name (e.g., names of reverse
978 address mapping PTR records, which are derived from IP addresses,
979 which should be unique on the local link) or if it previously claimed
980 unique ownership of that name using probe queries for rrtype "ANY".
981 (If it were to use probe queries for a specific rrtype, then it would
982 only own the name for that rrtype, and could not assert that other
983 rrtypes do not exist.)
984
985
986
987 Cheshire & Krochmal Standards Track [Page 18]
988 RFC 6762 Multicast DNS February 2013
989
990
991 The design rationale for this mechanism for encoding negative
992 responses is discussed further in Appendix E.
993
994 6.2. Responding to Address Queries
995
996 When a Multicast DNS responder sends a Multicast DNS response message
997 containing its own address records, it MUST include all addresses
998 that are valid on the interface on which it is sending the message,
999 and MUST NOT include addresses that are not valid on that interface
1000 (such as addresses that may be configured on the host's other
1001 interfaces). For example, if an interface has both an IPv6 link-
1002 local and an IPv6 routable address, both should be included in the
1003 response message so that queriers receive both and can make their own
1004 choice about which to use. This allows a querier that only has an
1005 IPv6 link-local address to connect to the link-local address, and a
1006 different querier that has an IPv6 routable address to connect to the
1007 IPv6 routable address instead.
1008
1009 When a Multicast DNS responder places an IPv4 or IPv6 address record
1010 (rrtype "A" or "AAAA") into a response message, it SHOULD also place
1011 any records of the other address type with the same name into the
1012 additional section, if there is space in the message. This is to
1013 provide fate sharing, so that all a device's addresses are delivered
1014 atomically in a single message, to reduce the risk that packet loss
1015 could cause a querier to receive only the IPv4 addresses and not the
1016 IPv6 addresses, or vice versa.
1017
1018 In the event that a device has only IPv4 addresses but no IPv6
1019 addresses, or vice versa, then the appropriate NSEC record SHOULD be
1020 placed into the additional section, so that queriers can know with
1021 certainty that the device has no addresses of that kind.
1022
1023 Some Multicast DNS responders treat a physical interface with both
1024 IPv4 and IPv6 address as a single interface with two addresses.
1025 Other Multicast DNS responders may treat this case as logically two
1026 interfaces (one with one or more IPv4 addresses, and the other with
1027 one or more IPv6 addresses), but responders that operate this way
1028 MUST NOT put the corresponding automatic NSEC records in replies they
1029 send (i.e., a negative IPv4 assertion in their IPv6 responses, and a
1030 negative IPv6 assertion in their IPv4 responses) because this would
1031 cause incorrect operation in responders on the network that work the
1032 former way.
1033
1034 6.3. Responding to Multiquestion Queries
1035
1036 Multicast DNS responders MUST correctly handle DNS query messages
1037 containing more than one question, by answering any or all of the
1038 questions to which they have answers. Unlike single-question
1039
1040
1041
1042 Cheshire & Krochmal Standards Track [Page 19]
1043 RFC 6762 Multicast DNS February 2013
1044
1045
1046 queries, where responding without delay is allowed in appropriate
1047 cases, for query messages containing more than one question, all
1048 (non-defensive) answers SHOULD be randomly delayed in the range
1049 20-120 ms, or 400-500 ms if the TC (truncated) bit is set. This is
1050 because when a query message contains more than one question, a
1051 Multicast DNS responder cannot generally be certain that other
1052 responders will not also be simultaneously generating answers to
1053 other questions in that query message. (Answers defending a name, in
1054 response to a probe for that name, are not subject to this delay rule
1055 and are still sent immediately.)
1056
1057 6.4. Response Aggregation
1058
1059 When possible, a responder SHOULD, for the sake of network
1060 efficiency, aggregate as many responses as possible into a single
1061 Multicast DNS response message. For example, when a responder has
1062 several responses it plans to send, each delayed by a different
1063 interval, then earlier responses SHOULD be delayed by up to an
1064 additional 500 ms if that will permit them to be aggregated with
1065 other responses scheduled to go out a little later.
1066
1067 6.5. Wildcard Queries (qtype "ANY" and qclass "ANY")
1068
1069 When responding to queries using qtype "ANY" (255) and/or qclass
1070 "ANY" (255), a Multicast DNS responder MUST respond with *ALL* of its
1071 records that match the query. This is subtly different from how
1072 qtype "ANY" and qclass "ANY" work in Unicast DNS.
1073
1074 A common misconception is that a Unicast DNS query for qtype "ANY"
1075 will elicit a response containing all matching records. This is
1076 incorrect. If there are any records that match the query, the
1077 response is required only to contain at least one of them, not
1078 necessarily all of them.
1079
1080 This somewhat surprising behavior is commonly seen with caching
1081 (i.e., "recursive") name servers. If a caching server receives a
1082 qtype "ANY" query for which it has at least one valid answer, it is
1083 allowed to return only those matching answers it happens to have
1084 already in its cache, and it is not required to reconsult the
1085 authoritative name server to check if there are any more records that
1086 also match the qtype "ANY" query.
1087
1088 For example, one might imagine that a query for qtype "ANY" for name
1089 "host.example.com" would return both the IPv4 (A) and the IPv6 (AAAA)
1090 address records for that host. In reality, what happens is that it
1091 depends on the history of what queries have been previously received
1092 by intervening caching servers. If a caching server has no records
1093 for "host.example.com", then it will consult another server (usually
1094
1095
1096
1097 Cheshire & Krochmal Standards Track [Page 20]
1098 RFC 6762 Multicast DNS February 2013
1099
1100
1101 the authoritative name server for the name in question), and, in that
1102 case, it will typically return all IPv4 and IPv6 address records.
1103 However, if some other host has recently done a query for qtype "A"
1104 for name "host.example.com", so that the caching server already has
1105 IPv4 address records for "host.example.com" in its cache but no IPv6
1106 address records, then it will return only the IPv4 address records it
1107 already has cached, and no IPv6 address records.
1108
1109 Multicast DNS does not share this property that qtype "ANY" and
1110 qclass "ANY" queries return some undefined subset of the matching
1111 records. When responding to queries using qtype "ANY" (255) and/or
1112 qclass "ANY" (255), a Multicast DNS responder MUST respond with *ALL*
1113 of its records that match the query.
1114
1115 6.6. Cooperating Multicast DNS Responders
1116
1117 If a Multicast DNS responder ("A") observes some other Multicast DNS
1118 responder ("B") send a Multicast DNS response message containing a
1119 resource record with the same name, rrtype, and rrclass as one of A's
1120 resource records, but *different* rdata, then:
1121
1122 o If A's resource record is intended to be a shared resource
1123 record, then this is no conflict, and no action is required.
1124
1125 o If A's resource record is intended to be a member of a unique
1126 resource record set owned solely by that responder, then this is
1127 a conflict and MUST be handled as described in Section 9,
1128 "Conflict Resolution".
1129
1130 If a Multicast DNS responder ("A") observes some other Multicast DNS
1131 responder ("B") send a Multicast DNS response message containing a
1132 resource record with the same name, rrtype, and rrclass as one of A's
1133 resource records, and *identical* rdata, then:
1134
1135 o If the TTL of B's resource record given in the message is at
1136 least half the true TTL from A's point of view, then no action
1137 is required.
1138
1139 o If the TTL of B's resource record given in the message is less
1140 than half the true TTL from A's point of view, then A MUST mark
1141 its record to be announced via multicast. Queriers receiving
1142 the record from B would use the TTL given by B and, hence, may
1143 delete the record sooner than A expects. By sending its own
1144 multicast response correcting the TTL, A ensures that the record
1145 will be retained for the desired time.
1146
1147
1148
1149
1150
1151
1152 Cheshire & Krochmal Standards Track [Page 21]
1153 RFC 6762 Multicast DNS February 2013
1154
1155
1156 These rules allow multiple Multicast DNS responders to offer the same
1157 data on the network (perhaps for fault-tolerance reasons) without
1158 conflicting with each other.
1159
1160 6.7. Legacy Unicast Responses
1161
1162 If the source UDP port in a received Multicast DNS query is not port
1163 5353, this indicates that the querier originating the query is a
1164 simple resolver such as described in Section 5.1, "One-Shot Multicast
1165 DNS Queries", which does not fully implement all of Multicast DNS.
1166 In this case, the Multicast DNS responder MUST send a UDP response
1167 directly back to the querier, via unicast, to the query packet's
1168 source IP address and port. This unicast response MUST be a
1169 conventional unicast response as would be generated by a conventional
1170 Unicast DNS server; for example, it MUST repeat the query ID and the
1171 question given in the query message. In addition, the cache-flush
1172 bit described in Section 10.2, "Announcements to Flush Outdated Cache
1173 Entries", MUST NOT be set in legacy unicast responses.
1174
1175 The resource record TTL given in a legacy unicast response SHOULD NOT
1176 be greater than ten seconds, even if the true TTL of the Multicast
1177 DNS resource record is higher. This is because Multicast DNS
1178 responders that fully participate in the protocol use the cache
1179 coherency mechanisms described in Section 10, "Resource Record TTL
1180 Values and Cache Coherency", to update and invalidate stale data.
1181 Were unicast responses sent to legacy resolvers to use the same high
1182 TTLs, these legacy resolvers, which do not implement these cache
1183 coherency mechanisms, could retain stale cached resource record data
1184 long after it is no longer valid.
1185
1186 7. Traffic Reduction
1187
1188 A variety of techniques are used to reduce the amount of traffic on
1189 the network.
1190
1191 7.1. Known-Answer Suppression
1192
1193 When a Multicast DNS querier sends a query to which it already knows
1194 some answers, it populates the Answer Section of the DNS query
1195 message with those answers.
1196
1197 Generally, this applies only to Shared records, not Unique records,
1198 since if a Multicast DNS querier already has at least one Unique
1199 record in its cache then it should not be expecting further different
1200 answers to this question, since the Unique record(s) it already has
1201 comprise the complete answer, so it has no reason to be sending the
1202 query at all. In contrast, having some Shared records in its cache
1203 does not necessarily imply that a Multicast DNS querier will not
1204
1205
1206
1207 Cheshire & Krochmal Standards Track [Page 22]
1208 RFC 6762 Multicast DNS February 2013
1209
1210
1211 receive further answers to this query, and it is in this case that it
1212 is beneficial to use the Known-Answer list to suppress repeated
1213 sending of redundant answers that the querier already knows.
1214
1215 A Multicast DNS responder MUST NOT answer a Multicast DNS query if
1216 the answer it would give is already included in the Answer Section
1217 with an RR TTL at least half the correct value. If the RR TTL of the
1218 answer as given in the Answer Section is less than half of the true
1219 RR TTL as known by the Multicast DNS responder, the responder MUST
1220 send an answer so as to update the querier's cache before the record
1221 becomes in danger of expiration.
1222
1223 Because a Multicast DNS responder will respond if the remaining TTL
1224 given in the Known-Answer list is less than half the true TTL, it is
1225 superfluous for the querier to include such records in the Known-
1226 Answer list. Therefore, a Multicast DNS querier SHOULD NOT include
1227 records in the Known-Answer list whose remaining TTL is less than
1228 half of their original TTL. Doing so would simply consume space in
1229 the message without achieving the goal of suppressing responses and
1230 would, therefore, be a pointless waste of network capacity.
1231
1232 A Multicast DNS querier MUST NOT cache resource records observed in
1233 the Known-Answer Section of other Multicast DNS queries. The Answer
1234 Section of Multicast DNS queries is not authoritative. By placing
1235 information in the Answer Section of a Multicast DNS query, the
1236 querier is stating that it *believes* the information to be true. It
1237 is not asserting that the information *is* true. Some of those
1238 records may have come from other hosts that are no longer on the
1239 network. Propagating that stale information to other Multicast DNS
1240 queriers on the network would not be helpful.
1241
1242 7.2. Multipacket Known-Answer Suppression
1243
1244 Sometimes a Multicast DNS querier will already have too many answers
1245 to fit in the Known-Answer Section of its query packets. In this
1246 case, it should issue a Multicast DNS query containing a question and
1247 as many Known-Answer records as will fit. It MUST then set the TC
1248 (Truncated) bit in the header before sending the query. It MUST
1249 immediately follow the packet with another query packet containing no
1250 questions and as many more Known-Answer records as will fit. If
1251 there are still too many records remaining to fit in the packet, it
1252 again sets the TC bit and continues until all the Known-Answer
1253 records have been sent.
1254
1255 A Multicast DNS responder seeing a Multicast DNS query with the TC
1256 bit set defers its response for a time period randomly selected in
1257 the interval 400-500 ms. This gives the Multicast DNS querier time
1258 to send additional Known-Answer packets before the responder
1259
1260
1261
1262 Cheshire & Krochmal Standards Track [Page 23]
1263 RFC 6762 Multicast DNS February 2013
1264
1265
1266 responds. If the responder sees any of its answers listed in the
1267 Known-Answer lists of subsequent packets from the querying host, it
1268 MUST delete that answer from the list of answers it is planning to
1269 give (provided that no other host on the network has also issued a
1270 query for that record and is waiting to receive an answer).
1271
1272 If the responder receives additional Known-Answer packets with the TC
1273 bit set, it SHOULD extend the delay as necessary to ensure a pause of
1274 400-500 ms after the last such packet before it sends its answer.
1275 This opens the potential risk that a continuous stream of Known-
1276 Answer packets could, theoretically, prevent a responder from
1277 answering indefinitely. In practice, answers are never actually
1278 delayed significantly, and should a situation arise where significant
1279 delays did happen, that would be a scenario where the network is so
1280 overloaded that it would be desirable to err on the side of caution.
1281 The consequence of delaying an answer may be that it takes a user
1282 longer than usual to discover all the services on the local network;
1283 in contrast, the consequence of incorrectly answering before all the
1284 Known-Answer packets have been received would be wasted capacity
1285 sending unnecessary answers on an already overloaded network. In
1286 this (rare) situation, sacrificing speed to preserve reliable network
1287 operation is the right trade-off.
1288
1289 7.3. Duplicate Question Suppression
1290
1291 If a host is planning to transmit (or retransmit) a query, and it
1292 sees another host on the network send a query containing the same
1293 "QM" question, and the Known-Answer Section of that query does not
1294 contain any records that this host would not also put in its own
1295 Known-Answer Section, then this host SHOULD treat its own query as
1296 having been sent. When multiple queriers on the network are querying
1297 for the same resource records, there is no need for them to all be
1298 repeatedly asking the same question.
1299
1300 7.4. Duplicate Answer Suppression
1301
1302 If a host is planning to send an answer, and it sees another host on
1303 the network send a response message containing the same answer
1304 record, and the TTL in that record is not less than the TTL this host
1305 would have given, then this host SHOULD treat its own answer as
1306 having been sent, and not also send an identical answer itself. When
1307 multiple responders on the network have the same data, there is no
1308 need for all of them to respond.
1309
1310
1311
1312
1313
1314
1315
1316
1317 Cheshire & Krochmal Standards Track [Page 24]
1318 RFC 6762 Multicast DNS February 2013
1319
1320
1321 The opportunity for duplicate answer suppression occurs when a host
1322 has received a query, and is delaying its response for some pseudo-
1323 random interval up to 500 ms, as described elsewhere in this
1324 document, and then, before the host sends its response, it sees some
1325 other host on the network send a response message containing the same
1326 answer record.
1327
1328 This feature is particularly useful when Multicast DNS Proxy Servers
1329 are in use, where there could be more than one proxy on the network
1330 giving Multicast DNS answers on behalf of some other host (e.g.,
1331 because that other host is currently asleep and is not itself
1332 responding to queries).
1333
1334 8. Probing and Announcing on Startup
1335
1336 Typically a Multicast DNS responder should have, at the very least,
1337 address records for all of its active interfaces. Creating and
1338 advertising an HINFO record on each interface as well can be useful
1339 to network administrators.
1340
1341 Whenever a Multicast DNS responder starts up, wakes up from sleep,
1342 receives an indication of a network interface "Link Change" event, or
1343 has any other reason to believe that its network connectivity may
1344 have changed in some relevant way, it MUST perform the two startup
1345 steps below: Probing (Section 8.1) and Announcing (Section 8.3).
1346
1347 8.1. Probing
1348
1349 The first startup step is that, for all those resource records that a
1350 Multicast DNS responder desires to be unique on the local link, it
1351 MUST send a Multicast DNS query asking for those resource records, to
1352 see if any of them are already in use. The primary example of this
1353 is a host's address records, which map its unique host name to its
1354 unique IPv4 and/or IPv6 addresses. All probe queries SHOULD be done
1355 using the desired resource record name and class (usually class 1,
1356 "Internet"), and query type "ANY" (255), to elicit answers for all
1357 types of records with that name. This allows a single question to be
1358 used in place of several questions, which is more efficient on the
1359 network. It also allows a host to verify exclusive ownership of a
1360 name for all rrtypes, which is desirable in most cases. It would be
1361 confusing, for example, if one host owned the "A" record for
1362 "myhost.local.", but a different host owned the "AAAA" record for
1363 that name.
1364
1365
1366
1367
1368
1369
1370
1371
1372 Cheshire & Krochmal Standards Track [Page 25]
1373 RFC 6762 Multicast DNS February 2013
1374
1375
1376 The ability to place more than one question in a Multicast DNS query
1377 is useful here, because it can allow a host to use a single message
1378 to probe for all of its resource records instead of needing a
1379 separate message for each. For example, a host can simultaneously
1380 probe for uniqueness of its "A" record and all its SRV records
1381 [RFC6763] in the same query message.
1382
1383 When ready to send its Multicast DNS probe packet(s) the host should
1384 first wait for a short random delay time, uniformly distributed in
1385 the range 0-250 ms. This random delay is to guard against the case
1386 where several devices are powered on simultaneously, or several
1387 devices are connected to an Ethernet hub, which is then powered on,
1388 or some other external event happens that might cause a group of
1389 hosts to all send synchronized probes.
1390
1391 250 ms after the first query, the host should send a second; then,
1392 250 ms after that, a third. If, by 250 ms after the third probe, no
1393 conflicting Multicast DNS responses have been received, the host may
1394 move to the next step, announcing. (Note that probing is the one
1395 exception from the normal rule that there should be at least one
1396 second between repetitions of the same question, and the interval
1397 between subsequent repetitions should at least double.)
1398
1399 When sending probe queries, a host MUST NOT consult its cache for
1400 potential answers. Only conflicting Multicast DNS responses received
1401 "live" from the network are considered valid for the purposes of
1402 determining whether probing has succeeded or failed.
1403
1404 In order to allow services to announce their presence without
1405 unreasonable delay, the time window for probing is intentionally set
1406 quite short. As a result of this, from the time the first probe
1407 packet is sent, another device on the network using that name has
1408 just 750 ms to respond to defend its name. On networks that are
1409 slow, or busy, or both, it is possible for round-trip latency to
1410 account for a few hundred milliseconds, and software delays in slow
1411 devices can add additional delay. Hence, it is important that when a
1412 device receives a probe query for a name that it is currently using,
1413 it SHOULD generate its response to defend that name immediately and
1414 send it as quickly as possible. The usual rules about random delays
1415 before responding, to avoid sudden bursts of simultaneous answers
1416 from different hosts, do not apply here since normally at most one
1417 host should ever respond to a given probe question. Even when a
1418 single DNS query message contains multiple probe questions, it would
1419 be unusual for that message to elicit a defensive response from more
1420 than one other host. Because of the mDNS multicast rate-limiting
1421
1422
1423
1424
1425
1426
1427 Cheshire & Krochmal Standards Track [Page 26]
1428 RFC 6762 Multicast DNS February 2013
1429
1430
1431 rules, the probes SHOULD be sent as "QU" questions with the unicast-
1432 response bit set, to allow a defending host to respond immediately
1433 via unicast, instead of potentially having to wait before replying
1434 via multicast.
1435
1436 During probing, from the time the first probe packet is sent until
1437 250 ms after the third probe, if any conflicting Multicast DNS
1438 response is received, then the probing host MUST defer to the
1439 existing host, and SHOULD choose new names for some or all of its
1440 resource records as appropriate. Apparently conflicting Multicast
1441 DNS responses received *before* the first probe packet is sent MUST
1442 be silently ignored (see discussion of stale probe packets in Section
1443 8.2, "Simultaneous Probe Tiebreaking", below). In the case of a host
1444 probing using query type "ANY" as recommended above, any answer
1445 containing a record with that name, of any type, MUST be considered a
1446 conflicting response and handled accordingly.
1447
1448 If fifteen conflicts occur within any ten-second period, then the
1449 host MUST wait at least five seconds before each successive
1450 additional probe attempt. This is to help ensure that, in the event
1451 of software bugs or other unanticipated problems, errant hosts do not
1452 flood the network with a continuous stream of multicast traffic. For
1453 very simple devices, a valid way to comply with this requirement is
1454 to always wait five seconds after any failed probe attempt before
1455 trying again.
1456
1457 If a responder knows by other means that its unique resource record
1458 set name, rrtype, and rrclass cannot already be in use by any other
1459 responder on the network, then it SHOULD skip the probing step for
1460 that resource record set. For example, when creating the reverse
1461 address mapping PTR records, the host can reasonably assume that no
1462 other host will be trying to create those same PTR records, since
1463 that would imply that the two hosts were trying to use the same IP
1464 address, and if that were the case, the two hosts would be suffering
1465 communication problems beyond the scope of what Multicast DNS is
1466 designed to solve. Similarly, if a responder is acting as a proxy,
1467 taking over from another Multicast DNS responder that has already
1468 verified the uniqueness of the record, then the proxy SHOULD NOT
1469 repeat the probing step for those records.
1470
1471 8.2. Simultaneous Probe Tiebreaking
1472
1473 The astute reader will observe that there is a race condition
1474 inherent in the previous description. If two hosts are probing for
1475 the same name simultaneously, neither will receive any response to
1476 the probe, and the hosts could incorrectly conclude that they may
1477 both proceed to use the name. To break this symmetry, each host
1478 populates the query message's Authority Section with the record or
1479
1480
1481
1482 Cheshire & Krochmal Standards Track [Page 27]
1483 RFC 6762 Multicast DNS February 2013
1484
1485
1486 records with the rdata that it would be proposing to use, should its
1487 probing be successful. The Authority Section is being used here in a
1488 way analogous to the way it is used as the "Update Section" in a DNS
1489 Update message [RFC2136] [RFC3007].
1490
1491 When a host is probing for a group of related records with the same
1492 name (e.g., the SRV and TXT record describing a DNS-SD service), only
1493 a single question need be placed in the Question Section, since query
1494 type "ANY" (255) is used, which will elicit answers for all records
1495 with that name. However, for tiebreaking to work correctly in all
1496 cases, the Authority Section must contain *all* the records and
1497 proposed rdata being probed for uniqueness.
1498
1499 When a host that is probing for a record sees another host issue a
1500 query for the same record, it consults the Authority Section of that
1501 query. If it finds any resource record(s) there which answers the
1502 query, then it compares the data of that (those) resource record(s)
1503 with its own tentative data. We consider first the simple case of a
1504 host probing for a single record, receiving a simultaneous probe from
1505 another host also probing for a single record. The two records are
1506 compared and the lexicographically later data wins. This means that
1507 if the host finds that its own data is lexicographically later, it
1508 simply ignores the other host's probe. If the host finds that its
1509 own data is lexicographically earlier, then it defers to the winning
1510 host by waiting one second, and then begins probing for this record
1511 again. The logic for waiting one second and then trying again is to
1512 guard against stale probe packets on the network (possibly even stale
1513 probe packets sent moments ago by this host itself, before some
1514 configuration change, which may be echoed back after a short delay by
1515 some Ethernet switches and some 802.11 base stations). If the
1516 winning simultaneous probe was from a real other host on the network,
1517 then after one second it will have completed its probing, and will
1518 answer subsequent probes. If the apparently winning simultaneous
1519 probe was in fact just an old stale packet on the network (maybe from
1520 the host itself), then when it retries its probing in one second, its
1521 probes will go unanswered, and it will successfully claim the name.
1522
1523 The determination of "lexicographically later" is performed by first
1524 comparing the record class (excluding the cache-flush bit described
1525 in Section 10.2), then the record type, then raw comparison of the
1526 binary content of the rdata without regard for meaning or structure.
1527 If the record classes differ, then the numerically greater class is
1528 considered "lexicographically later". Otherwise, if the record types
1529 differ, then the numerically greater type is considered
1530 "lexicographically later". If the rrtype and rrclass both match,
1531 then the rdata is compared.
1532
1533
1534
1535
1536
1537 Cheshire & Krochmal Standards Track [Page 28]
1538 RFC 6762 Multicast DNS February 2013
1539
1540
1541 In the case of resource records containing rdata that is subject to
1542 name compression [RFC1035], the names MUST be uncompressed before
1543 comparison. (The details of how a particular name is compressed is
1544 an artifact of how and where the record is written into the DNS
1545 message; it is not an intrinsic property of the resource record
1546 itself.)
1547
1548 The bytes of the raw uncompressed rdata are compared in turn,
1549 interpreting the bytes as eight-bit UNSIGNED values, until a byte is
1550 found whose value is greater than that of its counterpart (in which
1551 case, the rdata whose byte has the greater value is deemed
1552 lexicographically later) or one of the resource records runs out of
1553 rdata (in which case, the resource record which still has remaining
1554 data first is deemed lexicographically later). The following is an
1555 example of a conflict:
1556
1557 MyPrinter.local. A 169.254.99.200
1558 MyPrinter.local. A 169.254.200.50
1559
1560 In this case, 169.254.200.50 is lexicographically later (the third
1561 byte, with value 200, is greater than its counterpart with value 99),
1562 so it is deemed the winner.
1563
1564 Note that it is vital that the bytes are interpreted as UNSIGNED
1565 values in the range 0-255, or the wrong outcome may result. In the
1566 example above, if the byte with value 200 had been incorrectly
1567 interpreted as a signed eight-bit value, then it would be interpreted
1568 as value -56, and the wrong address record would be deemed the
1569 winner.
1570
1571 8.2.1. Simultaneous Probe Tiebreaking for Multiple Records
1572
1573 When a host is probing for a set of records with the same name, or a
1574 message is received containing multiple tiebreaker records answering
1575 a given probe question in the Question Section, the host's records
1576 and the tiebreaker records from the message are each sorted into
1577 order, and then compared pairwise, using the same comparison
1578 technique described above, until a difference is found.
1579
1580 The records are sorted using the same lexicographical order as
1581 described above, that is, if the record classes differ, the record
1582 with the lower class number comes first. If the classes are the same
1583 but the rrtypes differ, the record with the lower rrtype number comes
1584 first. If the class and rrtype match, then the rdata is compared
1585 bytewise until a difference is found. For example, in the common
1586 case of advertising DNS-SD services with a TXT record and an SRV
1587 record, the TXT record comes first (the rrtype value for TXT is 16)
1588 and the SRV record comes second (the rrtype value for SRV is 33).
1589
1590
1591
1592 Cheshire & Krochmal Standards Track [Page 29]
1593 RFC 6762 Multicast DNS February 2013
1594
1595
1596 When comparing the records, if the first records match perfectly,
1597 then the second records are compared, and so on. If either list of
1598 records runs out of records before any difference is found, then the
1599 list with records remaining is deemed to have won the tiebreak. If
1600 both lists run out of records at the same time without any difference
1601 being found, then this indicates that two devices are advertising
1602 identical sets of records, as is sometimes done for fault tolerance,
1603 and there is, in fact, no conflict.
1604
1605 8.3. Announcing
1606
1607 The second startup step is that the Multicast DNS responder MUST send
1608 an unsolicited Multicast DNS response containing, in the Answer
1609 Section, all of its newly registered resource records (both shared
1610 records, and unique records that have completed the probing step).
1611 If there are too many resource records to fit in a single packet,
1612 multiple packets should be used.
1613
1614 In the case of shared records (e.g., the PTR records used by DNS-
1615 Based Service Discovery [RFC6763]), the records are simply placed as
1616 is into the Answer Section of the DNS response.
1617
1618 In the case of records that have been verified to be unique in the
1619 previous step, they are placed into the Answer Section of the DNS
1620 response with the most significant bit of the rrclass set to one.
1621 The most significant bit of the rrclass for a record in the Answer
1622 Section of a response message is the Multicast DNS cache-flush bit
1623 and is discussed in more detail below in Section 10.2, "Announcements
1624 to Flush Outdated Cache Entries".
1625
1626 The Multicast DNS responder MUST send at least two unsolicited
1627 responses, one second apart. To provide increased robustness against
1628 packet loss, a responder MAY send up to eight unsolicited responses,
1629 provided that the interval between unsolicited responses increases by
1630 at least a factor of two with every response sent.
1631
1632 A Multicast DNS responder MUST NOT send announcements in the absence
1633 of information that its network connectivity may have changed in some
1634 relevant way. In particular, a Multicast DNS responder MUST NOT send
1635 regular periodic announcements as a matter of course.
1636
1637 Whenever a Multicast DNS responder receives any Multicast DNS
1638 response (solicited or otherwise) containing a conflicting resource
1639 record, the conflict MUST be resolved as described in Section 9,
1640 "Conflict Resolution".
1641
1642
1643
1644
1645
1646
1647 Cheshire & Krochmal Standards Track [Page 30]
1648 RFC 6762 Multicast DNS February 2013
1649
1650
1651 8.4. Updating
1652
1653 At any time, if the rdata of any of a host's Multicast DNS records
1654 changes, the host MUST repeat the Announcing step described above to
1655 update neighboring caches. For example, if any of a host's IP
1656 addresses change, it MUST re-announce those address records. The
1657 host does not need to repeat the Probing step because it has already
1658 established unique ownership of that name.
1659
1660 In the case of shared records, a host MUST send a "goodbye"
1661 announcement with RR TTL zero (see Section 10.1, "Goodbye Packets")
1662 for the old rdata, to cause it to be deleted from peer caches, before
1663 announcing the new rdata. In the case of unique records, a host
1664 SHOULD omit the "goodbye" announcement, since the cache-flush bit on
1665 the newly announced records will cause old rdata to be flushed from
1666 peer caches anyway.
1667
1668 A host may update the contents of any of its records at any time,
1669 though a host SHOULD NOT update records more frequently than ten
1670 times per minute. Frequent rapid updates impose a burden on the
1671 network. If a host has information to disseminate which changes more
1672 frequently than ten times per minute, then it may be more appropriate
1673 to design a protocol for that specific purpose.
1674
1675 9. Conflict Resolution
1676
1677 A conflict occurs when a Multicast DNS responder has a unique record
1678 for which it is currently authoritative, and it receives a Multicast
1679 DNS response message containing a record with the same name, rrtype
1680 and rrclass, but inconsistent rdata. What may be considered
1681 inconsistent is context sensitive, except that resource records with
1682 identical rdata are never considered inconsistent, even if they
1683 originate from different hosts. This is to permit use of proxies and
1684 other fault-tolerance mechanisms that may cause more than one
1685 responder to be capable of issuing identical answers on the network.
1686
1687 A common example of a resource record type that is intended to be
1688 unique, not shared between hosts, is the address record that maps a
1689 host's name to its IP address. Should a host witness another host
1690 announce an address record with the same name but a different IP
1691 address, then that is considered inconsistent, and that address
1692 record is considered to be in conflict.
1693
1694 Whenever a Multicast DNS responder receives any Multicast DNS
1695 response (solicited or otherwise) containing a conflicting resource
1696 record in any of the Resource Record Sections, the Multicast DNS
1697 responder MUST immediately reset its conflicted unique record to
1698 probing state, and go through the startup steps described above in
1699
1700
1701
1702 Cheshire & Krochmal Standards Track [Page 31]
1703 RFC 6762 Multicast DNS February 2013
1704
1705
1706 Section 8, "Probing and Announcing on Startup". The protocol used in
1707 the Probing phase will determine a winner and a loser, and the loser
1708 MUST cease using the name, and reconfigure.
1709
1710 It is very important that any host receiving a resource record that
1711 conflicts with one of its own MUST take action as described above.
1712 In the case of two hosts using the same host name, where one has been
1713 configured to require a unique host name and the other has not, the
1714 one that has not been configured to require a unique host name will
1715 not perceive any conflict, and will not take any action. By
1716 reverting to Probing state, the host that desires a unique host name
1717 will go through the necessary steps to ensure that a unique host name
1718 is obtained.
1719
1720 The recommended course of action after probing and failing is as
1721 follows:
1722
1723 1. Programmatically change the resource record name in an attempt
1724 to find a new name that is unique. This could be done by
1725 adding some further identifying information (e.g., the model
1726 name of the hardware) if it is not already present in the name,
1727 or appending the digit "2" to the name, or incrementing a
1728 number at the end of the name if one is already present.
1729
1730 2. Probe again, and repeat as necessary until a unique name is
1731 found.
1732
1733 3. Once an available unique name has been determined, by probing
1734 without receiving any conflicting response, record this newly
1735 chosen name in persistent storage so that the device will use
1736 the same name the next time it is power-cycled.
1737
1738 4. Display a message to the user or operator informing them of the
1739 name change. For example:
1740
1741 The name "Bob's Music" is in use by another music server on
1742 the network. Your music collection has been renamed to
1743 "Bob's Music (2)". If you want to change this name, use
1744 [describe appropriate menu item or preference dialog here].
1745
1746 The details of how the user or operator is informed of the new
1747 name depends on context. A desktop computer with a screen
1748 might put up a dialog box. A headless server in the closet may
1749 write a message to a log file, or use whatever mechanism
1750 (email, SNMP trap, etc.) it uses to inform the administrator of
1751 error conditions. On the other hand, a headless server in the
1752 closet may not inform the user at all -- if the user cares,
1753
1754
1755
1756
1757 Cheshire & Krochmal Standards Track [Page 32]
1758 RFC 6762 Multicast DNS February 2013
1759
1760
1761 they will notice the name has changed, and connect to the
1762 server in the usual way (e.g., via web browser) to configure a
1763 new name.
1764
1765 5. After one minute of probing, if the Multicast DNS responder has
1766 been unable to find any unused name, it should log an error
1767 message to inform the user or operator of this fact. This
1768 situation should never occur in normal operation. The only
1769 situations that would cause this to happen would be either a
1770 deliberate denial-of-service attack, or some kind of very
1771 obscure hardware or software bug that acts like a deliberate
1772 denial-of-service attack.
1773
1774 These considerations apply to address records (i.e., host names) and
1775 to all resource records where uniqueness (or maintenance of some
1776 other defined constraint) is desired.
1777
1778 10. Resource Record TTL Values and Cache Coherency
1779
1780 As a general rule, the recommended TTL value for Multicast DNS
1781 resource records with a host name as the resource record's name
1782 (e.g., A, AAAA, HINFO) or a host name contained within the resource
1783 record's rdata (e.g., SRV, reverse mapping PTR record) SHOULD be 120
1784 seconds.
1785
1786 The recommended TTL value for other Multicast DNS resource records is
1787 75 minutes.
1788
1789 A querier with an active outstanding query will issue a query message
1790 when one or more of the resource records in its cache are 80% of the
1791 way to expiry. If the TTL on those records is 75 minutes, this
1792 ongoing cache maintenance process yields a steady-state query rate of
1793 one query every 60 minutes.
1794
1795 Any distributed cache needs a cache coherency protocol. If Multicast
1796 DNS resource records follow the recommendation and have a TTL of 75
1797 minutes, that means that stale data could persist in the system for a
1798 little over an hour. Making the default RR TTL significantly lower
1799 would reduce the lifetime of stale data, but would produce too much
1800 extra traffic on the network. Various techniques are available to
1801 minimize the impact of such stale data, outlined in the five
1802 subsections below.
1803
1804 10.1. Goodbye Packets
1805
1806 In the case where a host knows that certain resource record data is
1807 about to become invalid (for example, when the host is undergoing a
1808 clean shutdown), the host SHOULD send an unsolicited Multicast DNS
1809
1810
1811
1812 Cheshire & Krochmal Standards Track [Page 33]
1813 RFC 6762 Multicast DNS February 2013
1814
1815
1816 response packet, giving the same resource record name, rrtype,
1817 rrclass, and rdata, but an RR TTL of zero. This has the effect of
1818 updating the TTL stored in neighboring hosts' cache entries to zero,
1819 causing that cache entry to be promptly deleted.
1820
1821 Queriers receiving a Multicast DNS response with a TTL of zero SHOULD
1822 NOT immediately delete the record from the cache, but instead record
1823 a TTL of 1 and then delete the record one second later. In the case
1824 of multiple Multicast DNS responders on the network described in
1825 Section 6.6 above, if one of the responders shuts down and
1826 incorrectly sends goodbye packets for its records, it gives the other
1827 cooperating responders one second to send out their own response to
1828 "rescue" the records before they expire and are deleted.
1829
1830 10.2. Announcements to Flush Outdated Cache Entries
1831
1832 Whenever a host has a resource record with new data, or with what
1833 might potentially be new data (e.g., after rebooting, waking from
1834 sleep, connecting to a new network link, or changing IP address), the
1835 host needs to inform peers of that new data. In cases where the host
1836 has not been continuously connected and participating on the network
1837 link, it MUST first probe to re-verify uniqueness of its unique
1838 records, as described above in Section 8.1, "Probing".
1839
1840 Having completed the Probing step, if necessary, the host MUST then
1841 send a series of unsolicited announcements to update cache entries in
1842 its neighbor hosts. In these unsolicited announcements, if the
1843 record is one that has been verified unique, the host sets the most
1844 significant bit of the rrclass field of the resource record. This
1845 bit, the cache-flush bit, tells neighboring hosts that this is not a
1846 shared record type. Instead of merging this new record additively
1847 into the cache in addition to any previous records with the same
1848 name, rrtype, and rrclass, all old records with that name, rrtype,
1849 and rrclass that were received more than one second ago are declared
1850 invalid, and marked to expire from the cache in one second.
1851
1852 The semantics of the cache-flush bit are as follows: normally when a
1853 resource record appears in a Resource Record Section of the DNS
1854 response it means, "This is an assertion that this information is
1855 true". When a resource record appears in a Resource Record Section
1856 of the DNS response with the cache-flush bit set, it means, "This is
1857 an assertion that this information is the truth and the whole truth,
1858 and anything you may have heard more than a second ago regarding
1859 records of this name/rrtype/rrclass is no longer true".
1860
1861 To accommodate the case where the set of records from one host
1862 constituting a single unique RRSet is too large to fit in a single
1863 packet, only cache records that are more than one second old are
1864
1865
1866
1867 Cheshire & Krochmal Standards Track [Page 34]
1868 RFC 6762 Multicast DNS February 2013
1869
1870
1871 flushed. This allows the announcing host to generate a quick burst
1872 of packets back-to-back on the wire containing all the members of the
1873 RRSet. When receiving records with the cache-flush bit set, all
1874 records older than one second are marked to be deleted one second in
1875 the future. One second after the end of the little packet burst, any
1876 records not represented within that packet burst will then be expired
1877 from all peer caches.
1878
1879 Any time a host sends a response packet containing some members of a
1880 unique RRSet, it MUST send the entire RRSet, preferably in a single
1881 packet, or if the entire RRSet will not fit in a single packet, in a
1882 quick burst of packets sent as close together as possible. The host
1883 MUST set the cache-flush bit on all members of the unique RRSet.
1884
1885 Another reason for waiting one second before deleting stale records
1886 from the cache is to accommodate bridged networks. For example, a
1887 host's address record announcement on a wireless interface may be
1888 bridged onto a wired Ethernet and may cause that same host's Ethernet
1889 address records to be flushed from peer caches. The one-second delay
1890 gives the host the chance to see its own announcement arrive on the
1891 wired Ethernet, and immediately re-announce its Ethernet interface's
1892 address records so that both sets remain valid and live in peer
1893 caches.
1894
1895 These rules, about when to set the cache-flush bit and about sending
1896 the entire rrset, apply regardless of *why* the response message is
1897 being generated. They apply to startup announcements as described in
1898 Section 8.3, "Announcing", and to responses generated as a result of
1899 receiving query messages.
1900
1901 The cache-flush bit is only set in records in the Resource Record
1902 Sections of Multicast DNS responses sent to UDP port 5353.
1903
1904 The cache-flush bit MUST NOT be set in any resource records in a
1905 response message sent in legacy unicast responses to UDP ports other
1906 than 5353.
1907
1908 The cache-flush bit MUST NOT be set in any resource records in the
1909 Known-Answer list of any query message.
1910
1911 The cache-flush bit MUST NOT ever be set in any shared resource
1912 record. To do so would cause all the other shared versions of this
1913 resource record with different rdata from different responders to be
1914 immediately deleted from all the caches on the network.
1915
1916
1917
1918
1919
1920
1921
1922 Cheshire & Krochmal Standards Track [Page 35]
1923 RFC 6762 Multicast DNS February 2013
1924
1925
1926 The cache-flush bit does *not* apply to questions listed in the
1927 Question Section of a Multicast DNS message. The top bit of the
1928 rrclass field in questions is used for an entirely different purpose
1929 (see Section 5.4, "Questions Requesting Unicast Responses").
1930
1931 Note that the cache-flush bit is NOT part of the resource record
1932 class. The cache-flush bit is the most significant bit of the second
1933 16-bit word of a resource record in a Resource Record Section of a
1934 Multicast DNS message (the field conventionally referred to as the
1935 rrclass field), and the actual resource record class is the least
1936 significant fifteen bits of this field. There is no Multicast DNS
1937 resource record class 0x8001. The value 0x8001 in the rrclass field
1938 of a resource record in a Multicast DNS response message indicates a
1939 resource record with class 1, with the cache-flush bit set. When
1940 receiving a resource record with the cache-flush bit set,
1941 implementations should take care to mask off that bit before storing
1942 the resource record in memory, or otherwise ensure that it is given
1943 the correct semantic interpretation.
1944
1945 The reuse of the top bit of the rrclass field only applies to
1946 conventional resource record types that are subject to caching, not
1947 to pseudo-RRs like OPT [RFC2671], TSIG [RFC2845], TKEY [RFC2930],
1948 SIG0 [RFC2931], etc., that pertain only to a particular transport
1949 level message and not to any actual DNS data. Since pseudo-RRs
1950 should never go into the Multicast DNS cache, the concept of a cache-
1951 flush bit for these types is not applicable. In particular, the
1952 rrclass field of an OPT record encodes the sender's UDP payload size,
1953 and should be interpreted as a sixteen-bit length value in the range
1954 0-65535, not a one-bit flag and a fifteen-bit length.
1955
1956 10.3. Cache Flush on Topology change
1957
1958 If the hardware on a given host is able to indicate physical changes
1959 of connectivity, then when the hardware indicates such a change, the
1960 host should take this information into account in its Multicast DNS
1961 cache management strategy. For example, a host may choose to
1962 immediately flush all cache records received on a particular
1963 interface when that cable is disconnected. Alternatively, a host may
1964 choose to adjust the remaining TTL on all those records to a few
1965 seconds so that if the cable is not reconnected quickly, those
1966 records will expire from the cache.
1967
1968 Likewise, when a host reboots, wakes from sleep, or undergoes some
1969 other similar discontinuous state change, the cache management
1970 strategy should take that information into account.
1971
1972
1973
1974
1975
1976
1977 Cheshire & Krochmal Standards Track [Page 36]
1978 RFC 6762 Multicast DNS February 2013
1979
1980
1981 10.4. Cache Flush on Failure Indication
1982
1983 Sometimes a cache record can be determined to be stale when a client
1984 attempts to use the rdata it contains, and the client finds that
1985 rdata to be incorrect.
1986
1987 For example, the rdata in an address record can be determined to be
1988 incorrect if attempts to contact that host fail, either because (for
1989 an IPv4 address on a local subnet) ARP requests for that address go
1990 unanswered, because (for an IPv6 address with an on-link prefix) ND
1991 requests for that address go unanswered, or because (for an address
1992 on a remote network) a router returns an ICMP "Host Unreachable"
1993 error.
1994
1995 The rdata in an SRV record can be determined to be incorrect if
1996 attempts to communicate with the indicated service at the host and
1997 port number indicated are not successful.
1998
1999 The rdata in a DNS-SD PTR record can be determined to be incorrect if
2000 attempts to look up the SRV record it references are not successful.
2001
2002 The software implementing the Multicast DNS resource record cache
2003 should provide a mechanism so that clients detecting stale rdata can
2004 inform the cache.
2005
2006 When the cache receives this hint that it should reconfirm some
2007 record, it MUST issue two or more queries for the resource record in
2008 dispute. If no response is received within ten seconds, then, even
2009 though its TTL may indicate that it is not yet due to expire, that
2010 record SHOULD be promptly flushed from the cache.
2011
2012 The end result of this is that if a printer suffers a sudden power
2013 failure or other abrupt disconnection from the network, its name may
2014 continue to appear in DNS-SD browser lists displayed on users'
2015 screens. Eventually, that entry will expire from the cache
2016 naturally, but if a user tries to access the printer before that
2017 happens, the failure to successfully contact the printer will trigger
2018 the more hasty demise of its cache entries. This is a sensible
2019 trade-off between good user experience and good network efficiency.
2020 If we were to insist that printers should disappear from the printer
2021 list within 30 seconds of becoming unavailable, for all failure
2022 modes, the only way to achieve this would be for the client to poll
2023 the printer at least every 30 seconds, or for the printer to announce
2024 its presence at least every 30 seconds, both of which would be an
2025 unreasonable burden on most networks.
2026
2027
2028
2029
2030
2031
2032 Cheshire & Krochmal Standards Track [Page 37]
2033 RFC 6762 Multicast DNS February 2013
2034
2035
2036 10.5. Passive Observation Of Failures (POOF)
2037
2038 A host observes the multicast queries issued by the other hosts on
2039 the network. One of the major benefits of also sending responses
2040 using multicast is that it allows all hosts to see the responses (or
2041 lack thereof) to those queries.
2042
2043 If a host sees queries, for which a record in its cache would be
2044 expected to be given as an answer in a multicast response, but no
2045 such answer is seen, then the host may take this as an indication
2046 that the record may no longer be valid.
2047
2048 After seeing two or more of these queries, and seeing no multicast
2049 response containing the expected answer within ten seconds, then even
2050 though its TTL may indicate that it is not yet due to expire, that
2051 record SHOULD be flushed from the cache. The host SHOULD NOT perform
2052 its own queries to reconfirm that the record is truly gone. If every
2053 host on a large network were to do this, it would cause a lot of
2054 unnecessary multicast traffic. If host A sends multicast queries
2055 that remain unanswered, then there is no reason to suppose that host
2056 B or any other host is likely to be any more successful.
2057
2058 The previous section, "Cache Flush on Failure Indication", describes
2059 a situation where a user trying to print discovers that the printer
2060 is no longer available. By implementing the passive observation
2061 described here, when one user fails to contact the printer, all hosts
2062 on the network observe that failure and update their caches
2063 accordingly.
2064
2065 11. Source Address Check
2066
2067 All Multicast DNS responses (including responses sent via unicast)
2068 SHOULD be sent with IP TTL set to 255. This is recommended to
2069 provide backwards-compatibility with older Multicast DNS queriers
2070 (implementing a draft version of this document, posted in February
2071 2004) that check the IP TTL on reception to determine whether the
2072 packet originated on the local link. These older queriers discard
2073 all packets with TTLs other than 255.
2074
2075 A host sending Multicast DNS queries to a link-local destination
2076 address (including the 224.0.0.251 and FF02::FB link-local multicast
2077 addresses) MUST only accept responses to that query that originate
2078 from the local link, and silently discard any other response packets.
2079 Without this check, it could be possible for remote rogue hosts to
2080 send spoof answer packets (perhaps unicast to the victim host), which
2081 the receiving machine could misinterpret as having originated on the
2082 local link.
2083
2084
2085
2086
2087 Cheshire & Krochmal Standards Track [Page 38]
2088 RFC 6762 Multicast DNS February 2013
2089
2090
2091 The test for whether a response originated on the local link is done
2092 in two ways:
2093
2094 * All responses received with a destination address in the IP
2095 header that is the mDNS IPv4 link-local multicast address
2096 224.0.0.251 or the mDNS IPv6 link-local multicast address
2097 FF02::FB are necessarily deemed to have originated on the local
2098 link, regardless of source IP address. This is essential to
2099 allow devices to work correctly and reliably in unusual
2100 configurations, such as multiple logical IP subnets overlayed on
2101 a single link, or in cases of severe misconfiguration, where
2102 devices are physically connected to the same link, but are
2103 currently misconfigured with completely unrelated IP addresses
2104 and subnet masks.
2105
2106 * For responses received with a unicast destination address in the
2107 IP header, the source IP address in the packet is checked to see
2108 if it is an address on a local subnet. An IPv4 source address
2109 is determined to be on a local subnet if, for (one of) the
2110 address(es) configured on the interface receiving the packet, (I
2111 & M) == (P & M), where I and M are the interface address and
2112 subnet mask respectively, P is the source IP address from the
2113 packet, '&' represents the bitwise logical 'and' operation, and
2114 '==' represents a bitwise equality test. An IPv6 source address
2115 is determined to be on the local link if, for any of the on-link
2116 IPv6 prefixes on the interface receiving the packet (learned via
2117 IPv6 router advertisements or otherwise configured on the host),
2118 the first 'n' bits of the IPv6 source address match the first
2119 'n' bits of the prefix address, where 'n' is the length of the
2120 prefix being considered.
2121
2122 Since queriers will ignore responses apparently originating outside
2123 the local subnet, a responder SHOULD avoid generating responses that
2124 it can reasonably predict will be ignored. This applies particularly
2125 in the case of overlayed subnets. If a responder receives a query
2126 addressed to the mDNS IPv4 link-local multicast address 224.0.0.251,
2127 from a source address not apparently on the same subnet as the
2128 responder (or, in the case of IPv6, from a source IPv6 address for
2129 which the responder does not have any address with the same prefix on
2130 that interface), then even if the query indicates that a unicast
2131 response is preferred (see Section 5.4, "Questions Requesting Unicast
2132 Responses"), the responder SHOULD elect to respond by multicast
2133 anyway, since it can reasonably predict that a unicast response with
2134 an apparently non-local source address will probably be ignored.
2135
2136
2137
2138
2139
2140
2141
2142 Cheshire & Krochmal Standards Track [Page 39]
2143 RFC 6762 Multicast DNS February 2013
2144
2145
2146 12. Special Characteristics of Multicast DNS Domains
2147
2148 Unlike conventional DNS names, names that end in ".local." have only
2149 local significance. The same is true of names within the IPv4 link-
2150 local reverse mapping domain "254.169.in-addr.arpa." and the IPv6
2151 link-local reverse mapping domains "8.e.f.ip6.arpa.",
2152 "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.".
2153
2154 These names function primarily as protocol identifiers, rather than
2155 as user-visible identifiers. Even though they may occasionally be
2156 visible to end users, that is not their primary purpose. As such,
2157 these names should be treated as opaque identifiers. In particular,
2158 the string "local" should not be translated or localized into
2159 different languages, much as the name "localhost" is not translated
2160 or localized into different languages.
2161
2162 Conventional Unicast DNS seeks to provide a single unified namespace,
2163 where a given DNS query yields the same answer no matter where on the
2164 planet it is performed or to which recursive DNS server the query is
2165 sent. In contrast, each IP link has its own private ".local.",
2166 "254.169.in-addr.arpa." and IPv6 link-local reverse mapping
2167 namespaces, and the answer to any query for a name within those
2168 domains depends on where that query is asked. (This characteristic
2169 is not unique to Multicast DNS. Although the original concept of DNS
2170 was a single global namespace, in recent years, split views,
2171 firewalls, intranets, DNS geolocation, and the like have increasingly
2172 meant that the answer to a given DNS query has become dependent on
2173 the location of the querier.)
2174
2175 The IPv4 name server address for a Multicast DNS domain is
2176 224.0.0.251. The IPv6 name server address for a Multicast DNS domain
2177 is FF02::FB. These are multicast addresses; therefore, they identify
2178 not a single host but a collection of hosts, working in cooperation
2179 to maintain some reasonable facsimile of a competently managed DNS
2180 zone. Conceptually, a Multicast DNS domain is a single DNS zone;
2181 however, its server is implemented as a distributed process running
2182 on a cluster of loosely cooperating CPUs rather than as a single
2183 process running on a single CPU.
2184
2185 Multicast DNS domains are not delegated from their parent domain via
2186 use of NS (Name Server) records, and there is also no concept of
2187 delegation of subdomains within a Multicast DNS domain. Just because
2188 a particular host on the network may answer queries for a particular
2189 record type with the name "example.local." does not imply anything
2190 about whether that host will answer for the name
2191 "child.example.local.", or indeed for other record types with the
2192 name "example.local.".
2193
2194
2195
2196
2197 Cheshire & Krochmal Standards Track [Page 40]
2198 RFC 6762 Multicast DNS February 2013
2199
2200
2201 There are no NS records anywhere in Multicast DNS domains. Instead,
2202 the Multicast DNS domains are reserved by IANA, and there is
2203 effectively an implicit delegation of all Multicast DNS domains to
2204 the 224.0.0.251:5353 and [FF02::FB]:5353 multicast groups, by virtue
2205 of client software implementing the protocol rules specified in this
2206 document.
2207
2208 Multicast DNS zones have no SOA (Start of Authority) record. A
2209 conventional DNS zone's SOA record contains information such as the
2210 email address of the zone administrator and the monotonically
2211 increasing serial number of the last zone modification. There is no
2212 single human administrator for any given Multicast DNS zone, so there
2213 is no email address. Because the hosts managing any given Multicast
2214 DNS zone are only loosely coordinated, there is no readily available
2215 monotonically increasing serial number to determine whether or not
2216 the zone contents have changed. A host holding part of the shared
2217 zone could crash or be disconnected from the network at any time
2218 without informing the other hosts. There is no reliable way to
2219 provide a zone serial number that would, whenever such a crash or
2220 disconnection occurred, immediately change to indicate that the
2221 contents of the shared zone had changed.
2222
2223 Zone transfers are not possible for any Multicast DNS zone.
2224
2225 13. Enabling and Disabling Multicast DNS
2226
2227 The option to fail-over to Multicast DNS for names not ending in
2228 ".local." SHOULD be a user-configured option, and SHOULD be disabled
2229 by default because of the possible security issues related to
2230 unintended local resolution of apparently global names. Enabling
2231 Multicast DNS for names not ending in ".local." may be appropriate on
2232 a secure isolated network, or on some future network were machines
2233 exclusively use DNSSEC for all DNS queries, and have Multicast DNS
2234 responders capable of generating the appropriate cryptographic DNSSEC
2235 signatures, thereby guarding against spoofing.
2236
2237 The option to look up unqualified (relative) names by appending
2238 ".local." (or not) is controlled by whether ".local." appears (or
2239 not) in the client's DNS search list.
2240
2241 No special control is needed for enabling and disabling Multicast DNS
2242 for names explicitly ending with ".local." as entered by the user.
2243 The user doesn't need a way to disable Multicast DNS for names ending
2244 with ".local.", because if the user doesn't want to use Multicast
2245 DNS, they can achieve this by simply not using those names. If a
2246 user *does* enter a name ending in ".local.", then we can safely
2247 assume the user's intention was probably that it should work. Having
2248 user configuration options that can be (intentionally or
2249
2250
2251
2252 Cheshire & Krochmal Standards Track [Page 41]
2253 RFC 6762 Multicast DNS February 2013
2254
2255
2256 unintentionally) set so that local names don't work is just one more
2257 way of frustrating the user's ability to perform the tasks they want,
2258 perpetuating the view that, "IP networking is too complicated to
2259 configure and too hard to use".
2260
2261 14. Considerations for Multiple Interfaces
2262
2263 A host SHOULD defend its dot-local host name on all active interfaces
2264 on which it is answering Multicast DNS queries.
2265
2266 In the event of a name conflict on *any* interface, a host should
2267 configure a new host name, if it wishes to maintain uniqueness of its
2268 host name.
2269
2270 A host may choose to use the same name (or set of names) for all of
2271 its address records on all interfaces, or it may choose to manage its
2272 Multicast DNS interfaces independently, potentially answering to a
2273 different name (or set of names) on different interfaces.
2274
2275 Except in the case of proxying and other similar specialized uses,
2276 addresses in IPv4 or IPv6 address records in Multicast DNS responses
2277 MUST be valid for use on the interface on which the response is being
2278 sent.
2279
2280 Just as the same link-local IP address may validly be in use
2281 simultaneously on different links by different hosts, the same link-
2282 local host name may validly be in use simultaneously on different
2283 links, and this is not an error. A multihomed host with connections
2284 to two different links may be able to communicate with two different
2285 hosts that are validly using the same name. While this kind of name
2286 duplication should be rare, it means that a host that wants to fully
2287 support this case needs network programming APIs that allow
2288 applications to specify on what interface to perform a link-local
2289 Multicast DNS query, and to discover on what interface a Multicast
2290 DNS response was received.
2291
2292 There is one other special precaution that multihomed hosts need to
2293 take. It's common with today's laptop computers to have an Ethernet
2294 connection and an 802.11 [IEEE.802.11] wireless connection active at
2295 the same time. What the software on the laptop computer can't easily
2296 tell is whether the wireless connection is in fact bridged onto the
2297 same network segment as its Ethernet connection. If the two networks
2298 are bridged together, then packets the host sends on one interface
2299 will arrive on the other interface a few milliseconds later, and care
2300 must be taken to ensure that this bridging does not cause problems:
2301
2302
2303
2304
2305
2306
2307 Cheshire & Krochmal Standards Track [Page 42]
2308 RFC 6762 Multicast DNS February 2013
2309
2310
2311 When the host announces its host name (i.e., its address records) on
2312 its wireless interface, those announcement records are sent with the
2313 cache-flush bit set, so when they arrive on the Ethernet segment,
2314 they will cause all the peers on the Ethernet to flush the host's
2315 Ethernet address records from their caches. The Multicast DNS
2316 protocol has a safeguard to protect against this situation: when
2317 records are received with the cache-flush bit set, other records are
2318 not deleted from peer caches immediately, but are marked for deletion
2319 in one second. When the host sees its own wireless address records
2320 arrive on its Ethernet interface, with the cache-flush bit set, this
2321 one-second grace period gives the host time to respond and re-
2322 announce its Ethernet address records, to reinstate those records in
2323 peer caches before they are deleted.
2324
2325 As described, this solves one problem, but creates another, because
2326 when those Ethernet announcement records arrive back on the wireless
2327 interface, the host would again respond defensively to reinstate its
2328 wireless records, and this process would continue forever,
2329 continuously flooding the network with traffic. The Multicast DNS
2330 protocol has a second safeguard, to solve this problem: the cache-
2331 flush bit does not apply to records received very recently, within
2332 the last second. This means that when the host sees its own Ethernet
2333 address records arrive on its wireless interface, with the cache-
2334 flush bit set, it knows there's no need to re-announce its wireless
2335 address records again because it already sent them less than a second
2336 ago, and this makes them immune from deletion from peer caches. (See
2337 Section 10.2.)
2338
2339 15. Considerations for Multiple Responders on the Same Machine
2340
2341 It is possible to have more than one Multicast DNS responder and/or
2342 querier implementation coexist on the same machine, but there are
2343 some known issues.
2344
2345 15.1. Receiving Unicast Responses
2346
2347 In most operating systems, incoming *multicast* packets can be
2348 delivered to *all* open sockets bound to the right port number,
2349 provided that the clients take the appropriate steps to allow this.
2350 For this reason, all Multicast DNS implementations SHOULD use the
2351 SO_REUSEPORT and/or SO_REUSEADDR options (or equivalent as
2352 appropriate for the operating system in question) so they will all be
2353 able to bind to UDP port 5353 and receive incoming multicast packets
2354 addressed to that port. However, unlike multicast packets, incoming
2355 unicast UDP packets are typically delivered only to the first socket
2356 to bind to that port. This means that "QU" responses and other
2357 packets sent via unicast will be received only by the first Multicast
2358 DNS responder and/or querier on a system. This limitation can be
2359
2360
2361
2362 Cheshire & Krochmal Standards Track [Page 43]
2363 RFC 6762 Multicast DNS February 2013
2364
2365
2366 partially mitigated if Multicast DNS implementations detect when they
2367 are not the first to bind to port 5353, and in that case they do not
2368 request "QU" responses. One way to detect if there is another
2369 Multicast DNS implementation already running is to attempt binding to
2370 port 5353 without using SO_REUSEPORT and/or SO_REUSEADDR, and if that
2371 fails it indicates that some other socket is already bound to this
2372 port.
2373
2374 15.2. Multipacket Known-Answer lists
2375
2376 When a Multicast DNS querier issues a query with too many Known
2377 Answers to fit into a single packet, it divides the Known-Answer list
2378 into two or more packets. Multicast DNS responders associate the
2379 initial truncated query with its continuation packets by examining
2380 the source IP address in each packet. Since two independent
2381 Multicast DNS queriers running on the same machine will be sending
2382 packets with the same source IP address, from an outside perspective
2383 they appear to be a single entity. If both queriers happened to send
2384 the same multipacket query at the same time, with different Known-
2385 Answer lists, then they could each end up suppressing answers that
2386 the other needs.
2387
2388 15.3. Efficiency
2389
2390 If different clients on a machine were each to have their own
2391 independent Multicast DNS implementation, they would lose certain
2392 efficiency benefits. Apart from the unnecessary code duplication,
2393 memory usage, and CPU load, the clients wouldn't get the benefit of a
2394 shared system-wide cache, and they would not be able to aggregate
2395 separate queries into single packets to reduce network traffic.
2396
2397 15.4. Recommendation
2398
2399 Because of these issues, this document encourages implementers to
2400 design systems with a single Multicast DNS implementation that
2401 provides Multicast DNS services shared by all clients on that
2402 machine, much as most operating systems today have a single TCP
2403 implementation, which is shared between all clients on that machine.
2404 Due to engineering constraints, there may be situations where
2405 embedding a "user-level" Multicast DNS implementation in the client
2406 application software is the most expedient solution, and while this
2407 will usually work in practice, implementers should be aware of the
2408 issues outlined in this section.
2409
2410
2411
2412
2413
2414
2415
2416
2417 Cheshire & Krochmal Standards Track [Page 44]
2418 RFC 6762 Multicast DNS February 2013
2419
2420
2421 16. Multicast DNS Character Set
2422
2423 Historically, Unicast DNS has been used with a very restricted set of
2424 characters. Indeed, conventional DNS is usually limited to just
2425 twenty-six letters, ten digits and the hyphen character, not even
2426 allowing spaces or other punctuation. Attempts to remedy this for
2427 Unicast DNS have been badly constrained by the perceived need to
2428 accommodate old buggy legacy DNS implementations. In reality, the
2429 DNS specification itself actually imposes no limits on what
2430 characters may be used in names, and good DNS implementations handle
2431 any arbitrary eight-bit data without trouble. "Clarifications to the
2432 DNS Specification" [RFC2181] directly discusses the subject of
2433 allowable character set in Section 11 ("Name syntax"), and explicitly
2434 states that DNS names may contain arbitrary eight-bit data. However,
2435 the old rules for ARPANET host names back in the 1980s required host
2436 names to be just letters, digits, and hyphens [RFC1034], and since
2437 the predominant use of DNS is to store host address records, many
2438 have assumed that the DNS protocol itself suffers from the same
2439 limitation. It might be accurate to say that there could be
2440 hypothetical bad implementations that do not handle eight-bit data
2441 correctly, but it would not be accurate to say that the protocol
2442 doesn't allow names containing eight-bit data.
2443
2444 Multicast DNS is a new protocol and doesn't (yet) have old buggy
2445 legacy implementations to constrain the design choices. Accordingly,
2446 it adopts the simple obvious elegant solution: all names in Multicast
2447 DNS MUST be encoded as precomposed UTF-8 [RFC3629] "Net-Unicode"
2448 [RFC5198] text.
2449
2450 Some users of 16-bit Unicode have taken to stuffing a "zero-width
2451 nonbreaking space" character (U+FEFF) at the start of each UTF-16
2452 file, as a hint to identify whether the data is big-endian or little-
2453 endian, and calling it a "Byte Order Mark" (BOM). Since there is
2454 only one possible byte order for UTF-8 data, a BOM is neither
2455 necessary nor permitted. Multicast DNS names MUST NOT contain a
2456 "Byte Order Mark". Any occurrence of the Unicode character U+FEFF at
2457 the start or anywhere else in a Multicast DNS name MUST be
2458 interpreted as being an actual intended part of the name,
2459 representing (just as for any other legal unicode value) an actual
2460 literal instance of that character (in this case a zero-width non-
2461 breaking space character).
2462
2463 For names that are restricted to US-ASCII [RFC0020] letters, digits,
2464 and hyphens, the UTF-8 encoding is identical to the US-ASCII
2465 encoding, so this is entirely compatible with existing host names.
2466 For characters outside the US-ASCII range, UTF-8 encoding is used.
2467
2468
2469
2470
2471
2472 Cheshire & Krochmal Standards Track [Page 45]
2473 RFC 6762 Multicast DNS February 2013
2474
2475
2476 Multicast DNS implementations MUST NOT use any other encodings apart
2477 from precomposed UTF-8 (US-ASCII being considered a compatible subset
2478 of UTF-8). The reasons for selecting UTF-8 instead of Punycode
2479 [RFC3492] are discussed further in Appendix F.
2480
2481 The simple rules for case-insensitivity in Unicast DNS [RFC1034]
2482 [RFC1035] also apply in Multicast DNS; that is to say, in name
2483 comparisons, the lowercase letters "a" to "z" (0x61 to 0x7A) match
2484 their uppercase equivalents "A" to "Z" (0x41 to 0x5A). Hence, if a
2485 querier issues a query for an address record with the name
2486 "myprinter.local.", then a responder having an address record with
2487 the name "MyPrinter.local." should issue a response. No other
2488 automatic equivalences should be assumed. In particular, all UTF-8
2489 multibyte characters (codes 0x80 and higher) are compared by simple
2490 binary comparison of the raw byte values. Accented characters are
2491 *not* defined to be automatically equivalent to their unaccented
2492 counterparts. Where automatic equivalences are desired, this may be
2493 achieved through the use of programmatically generated CNAME records.
2494 For example, if a responder has an address record for an accented
2495 name Y, and a querier issues a query for a name X, where X is the
2496 same as Y with all the accents removed, then the responder may issue
2497 a response containing two resource records: a CNAME record "X CNAME
2498 Y", asserting that the requested name X (unaccented) is an alias for
2499 the true (accented) name Y, followed by the address record for Y.
2500
2501 17. Multicast DNS Message Size
2502
2503 The 1987 DNS specification [RFC1035] restricts DNS messages carried
2504 by UDP to no more than 512 bytes (not counting the IP or UDP
2505 headers). For UDP packets carried over the wide-area Internet in
2506 1987, this was appropriate. For link-local multicast packets on
2507 today's networks, there is no reason to retain this restriction.
2508 Given that the packets are by definition link-local, there are no
2509 Path MTU issues to consider.
2510
2511 Multicast DNS messages carried by UDP may be up to the IP MTU of the
2512 physical interface, less the space required for the IP header (20
2513 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
2514
2515 In the case of a single Multicast DNS resource record that is too
2516 large to fit in a single MTU-sized multicast response packet, a
2517 Multicast DNS responder SHOULD send the resource record alone, in a
2518 single IP datagram, using multiple IP fragments. Resource records
2519 this large SHOULD be avoided, except in the very rare cases where
2520 they really are the appropriate solution to the problem at hand.
2521 Implementers should be aware that many simple devices do not
2522 reassemble fragmented IP datagrams, so large resource records SHOULD
2523 NOT be used except in specialized cases where the implementer knows
2524
2525
2526
2527 Cheshire & Krochmal Standards Track [Page 46]
2528 RFC 6762 Multicast DNS February 2013
2529
2530
2531 that all receivers implement reassembly, or where the large resource
2532 record contains optional data which is not essential for correct
2533 operation of the client.
2534
2535 A Multicast DNS packet larger than the interface MTU, which is sent
2536 using fragments, MUST NOT contain more than one resource record.
2537
2538 Even when fragmentation is used, a Multicast DNS packet, including IP
2539 and UDP headers, MUST NOT exceed 9000 bytes.
2540
2541 Note that 9000 bytes is also the maximum payload size of an Ethernet
2542 "Jumbo" packet [Jumbo]. However, in practice Ethernet "Jumbo"
2543 packets are not widely used, so it is advantageous to keep packets
2544 under 1500 bytes whenever possible. Even on hosts that normally
2545 handle Ethernet "Jumbo" packets and IP fragment reassembly, it is
2546 becoming more common for these hosts to implement power-saving modes
2547 where the main CPU goes to sleep and hands off packet reception tasks
2548 to a more limited processor in the network interface hardware, which
2549 may not support Ethernet "Jumbo" packets or IP fragment reassembly.
2550
2551 18. Multicast DNS Message Format
2552
2553 This section describes specific rules pertaining to the allowable
2554 values for the header fields of a Multicast DNS message, and other
2555 message format considerations.
2556
2557 18.1. ID (Query Identifier)
2558
2559 Multicast DNS implementations SHOULD listen for unsolicited responses
2560 issued by hosts booting up (or waking up from sleep or otherwise
2561 joining the network). Since these unsolicited responses may contain
2562 a useful answer to a question for which the querier is currently
2563 awaiting an answer, Multicast DNS implementations SHOULD examine all
2564 received Multicast DNS response messages for useful answers, without
2565 regard to the contents of the ID field or the Question Section. In
2566 Multicast DNS, knowing which particular query message (if any) is
2567 responsible for eliciting a particular response message is less
2568 interesting than knowing whether the response message contains useful
2569 information.
2570
2571 Multicast DNS implementations MAY cache data from any or all
2572 Multicast DNS response messages they receive, for possible future
2573 use, provided of course that normal TTL aging is performed on these
2574 cached resource records.
2575
2576 In multicast query messages, the Query Identifier SHOULD be set to
2577 zero on transmission.
2578
2579
2580
2581
2582 Cheshire & Krochmal Standards Track [Page 47]
2583 RFC 6762 Multicast DNS February 2013
2584
2585
2586 In multicast responses, including unsolicited multicast responses,
2587 the Query Identifier MUST be set to zero on transmission, and MUST be
2588 ignored on reception.
2589
2590 In legacy unicast response messages generated specifically in
2591 response to a particular (unicast or multicast) query, the Query
2592 Identifier MUST match the ID from the query message.
2593
2594 18.2. QR (Query/Response) Bit
2595
2596 In query messages the QR bit MUST be zero.
2597 In response messages the QR bit MUST be one.
2598
2599 18.3. OPCODE
2600
2601 In both multicast query and multicast response messages, the OPCODE
2602 MUST be zero on transmission (only standard queries are currently
2603 supported over multicast). Multicast DNS messages received with an
2604 OPCODE other than zero MUST be silently ignored.
2605
2606 18.4. AA (Authoritative Answer) Bit
2607
2608 In query messages, the Authoritative Answer bit MUST be zero on
2609 transmission, and MUST be ignored on reception.
2610
2611 In response messages for Multicast domains, the Authoritative Answer
2612 bit MUST be set to one (not setting this bit would imply there's some
2613 other place where "better" information may be found) and MUST be
2614 ignored on reception.
2615
2616 18.5. TC (Truncated) Bit
2617
2618 In query messages, if the TC bit is set, it means that additional
2619 Known-Answer records may be following shortly. A responder SHOULD
2620 record this fact, and wait for those additional Known-Answer records,
2621 before deciding whether to respond. If the TC bit is clear, it means
2622 that the querying host has no additional Known Answers.
2623
2624 In multicast response messages, the TC bit MUST be zero on
2625 transmission, and MUST be ignored on reception.
2626
2627 In legacy unicast response messages, the TC bit has the same meaning
2628 as in conventional Unicast DNS: it means that the response was too
2629 large to fit in a single packet, so the querier SHOULD reissue its
2630 query using TCP in order to receive the larger response.
2631
2632
2633
2634
2635
2636
2637 Cheshire & Krochmal Standards Track [Page 48]
2638 RFC 6762 Multicast DNS February 2013
2639
2640
2641 18.6. RD (Recursion Desired) Bit
2642
2643 In both multicast query and multicast response messages, the
2644 Recursion Desired bit SHOULD be zero on transmission, and MUST be
2645 ignored on reception.
2646
2647 18.7. RA (Recursion Available) Bit
2648
2649 In both multicast query and multicast response messages, the
2650 Recursion Available bit MUST be zero on transmission, and MUST be
2651 ignored on reception.
2652
2653 18.8. Z (Zero) Bit
2654
2655 In both query and response messages, the Zero bit MUST be zero on
2656 transmission, and MUST be ignored on reception.
2657
2658 18.9. AD (Authentic Data) Bit
2659
2660 In both multicast query and multicast response messages, the
2661 Authentic Data bit [RFC2535] MUST be zero on transmission, and MUST
2662 be ignored on reception.
2663
2664 18.10. CD (Checking Disabled) Bit
2665
2666 In both multicast query and multicast response messages, the Checking
2667 Disabled bit [RFC2535] MUST be zero on transmission, and MUST be
2668 ignored on reception.
2669
2670 18.11. RCODE (Response Code)
2671
2672 In both multicast query and multicast response messages, the Response
2673 Code MUST be zero on transmission. Multicast DNS messages received
2674 with non-zero Response Codes MUST be silently ignored.
2675
2676 18.12. Repurposing of Top Bit of qclass in Question Section
2677
2678 In the Question Section of a Multicast DNS query, the top bit of the
2679 qclass field is used to indicate that unicast responses are preferred
2680 for this particular question. (See Section 5.4.)
2681
2682 18.13. Repurposing of Top Bit of rrclass in Resource Record Sections
2683
2684 In the Resource Record Sections of a Multicast DNS response, the top
2685 bit of the rrclass field is used to indicate that the record is a
2686 member of a unique RRSet, and the entire RRSet has been sent together
2687 (in the same packet, or in consecutive packets if there are too many
2688 records to fit in a single packet). (See Section 10.2.)
2689
2690
2691
2692 Cheshire & Krochmal Standards Track [Page 49]
2693 RFC 6762 Multicast DNS February 2013
2694
2695
2696 18.14. Name Compression
2697
2698 When generating Multicast DNS messages, implementations SHOULD use
2699 name compression wherever possible to compress the names of resource
2700 records, by replacing some or all of the resource record name with a
2701 compact two-byte reference to an appearance of that data somewhere
2702 earlier in the message [RFC1035].
2703
2704 This applies not only to Multicast DNS responses, but also to
2705 queries. When a query contains more than one question, successive
2706 questions in the same message often contain similar names, and
2707 consequently name compression SHOULD be used, to save bytes. In
2708 addition, queries may also contain Known Answers in the Answer
2709 Section, or probe tiebreaking data in the Authority Section, and
2710 these names SHOULD similarly be compressed for network efficiency.
2711
2712 In addition to compressing the *names* of resource records, names
2713 that appear within the *rdata* of the following rrtypes SHOULD also
2714 be compressed in all Multicast DNS messages:
2715
2716 NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC
2717
2718 Until future IETF Standards Action [RFC5226] specifying that names in
2719 the rdata of other types should be compressed, names that appear
2720 within the rdata of any type not listed above MUST NOT be compressed.
2721
2722 Implementations receiving Multicast DNS messages MUST correctly
2723 decode compressed names appearing in the Question Section, and
2724 compressed names of resource records appearing in other sections.
2725
2726 In addition, implementations MUST correctly decode compressed names
2727 appearing within the *rdata* of the rrtypes listed above. Where
2728 possible, implementations SHOULD also correctly decode compressed
2729 names appearing within the *rdata* of other rrtypes known to the
2730 implementers at the time of implementation, because such forward-
2731 thinking planning helps facilitate the deployment of future
2732 implementations that may have reason to compress those rrtypes. It
2733 is possible that no future IETF Standards Action [RFC5226] will be
2734 created that mandates or permits the compression of rdata in new
2735 types, but having implementations designed such that they are capable
2736 of decompressing all known types helps keep future options open.
2737
2738 One specific difference between Unicast DNS and Multicast DNS is that
2739 Unicast DNS does not allow name compression for the target host in an
2740 SRV record, because Unicast DNS implementations before the first SRV
2741 specification in 1996 [RFC2052] may not decode these compressed
2742
2743
2744
2745
2746
2747 Cheshire & Krochmal Standards Track [Page 50]
2748 RFC 6762 Multicast DNS February 2013
2749
2750
2751 records properly. Since all Multicast DNS implementations were
2752 created after 1996, all Multicast DNS implementations are REQUIRED to
2753 decode compressed SRV records correctly.
2754
2755 In legacy unicast responses generated to answer legacy queries, name
2756 compression MUST NOT be performed on SRV records.
2757
2758 19. Summary of Differences between Multicast DNS and Unicast DNS
2759
2760 Multicast DNS shares, as much as possible, the familiar APIs, naming
2761 syntax, resource record types, etc., of Unicast DNS. There are, of
2762 course, necessary differences by virtue of it using multicast, and by
2763 virtue of it operating in a community of cooperating peers, rather
2764 than a precisely defined hierarchy controlled by a strict chain of
2765 formal delegations from the root. These differences are summarized
2766 below:
2767
2768 Multicast DNS...
2769 * uses multicast
2770 * uses UDP port 5353 instead of port 53
2771 * operates in well-defined parts of the DNS namespace
2772 * has no SOA (Start of Authority) records
2773 * uses UTF-8, and only UTF-8, to encode resource record names
2774 * allows names up to 255 bytes plus a terminating zero byte
2775 * allows name compression in rdata for SRV and other record types
2776 * allows larger UDP packets
2777 * allows more than one question in a query message
2778 * defines consistent results for qtype "ANY" and qclass "ANY" queries
2779 * uses the Answer Section of a query to list Known Answers
2780 * uses the TC bit in a query to indicate additional Known Answers
2781 * uses the Authority Section of a query for probe tiebreaking
2782 * ignores the Query ID field (except for generating legacy responses)
2783 * doesn't require the question to be repeated in the response message
2784 * uses unsolicited responses to announce new records
2785 * uses NSEC records to signal nonexistence of records
2786 * defines a unicast-response bit in the rrclass of query questions
2787 * defines a cache-flush bit in the rrclass of response records
2788 * uses DNS RR TTL 0 to indicate that a record has been deleted
2789 * recommends AAAA records in the additional section when responding
2790 to rrtype "A" queries, and vice versa
2791 * monitors queries to perform Duplicate Question Suppression
2792 * monitors responses to perform Duplicate Answer Suppression...
2793 * ... and Ongoing Conflict Detection
2794 * ... and Opportunistic Caching
2795
2796
2797
2798
2799
2800
2801
2802 Cheshire & Krochmal Standards Track [Page 51]
2803 RFC 6762 Multicast DNS February 2013
2804
2805
2806 20. IPv6 Considerations
2807
2808 An IPv4-only host and an IPv6-only host behave as "ships that pass in
2809 the night". Even if they are on the same Ethernet, neither is aware
2810 of the other's traffic. For this reason, each physical link may have
2811 *two* unrelated ".local." zones, one for IPv4 and one for IPv6.
2812 Since for practical purposes, a group of IPv4-only hosts and a group
2813 of IPv6-only hosts on the same Ethernet act as if they were on two
2814 entirely separate Ethernet segments, it is unsurprising that their
2815 use of the ".local." zone should occur exactly as it would if they
2816 really were on two entirely separate Ethernet segments.
2817
2818 A dual-stack (v4/v6) host can participate in both ".local." zones,
2819 and should register its name(s) and perform its lookups both using
2820 IPv4 and IPv6. This enables it to reach, and be reached by, both
2821 IPv4-only and IPv6-only hosts. In effect, this acts like a
2822 multihomed host, with one connection to the logical "IPv4 Ethernet
2823 segment", and a connection to the logical "IPv6 Ethernet segment".
2824 When such a host generates NSEC records, if it is using the same host
2825 name for its IPv4 addresses and its IPv6 addresses on that network
2826 interface, its NSEC records should indicate that the host name has
2827 both A and AAAA records.
2828
2829 21. Security Considerations
2830
2831 The algorithm for detecting and resolving name conflicts is, by its
2832 very nature, an algorithm that assumes cooperating participants. Its
2833 purpose is to allow a group of hosts to arrive at a mutually disjoint
2834 set of host names and other DNS resource record names, in the absence
2835 of any central authority to coordinate this or mediate disputes. In
2836 the absence of any higher authority to resolve disputes, the only
2837 alternative is that the participants must work together cooperatively
2838 to arrive at a resolution.
2839
2840 In an environment where the participants are mutually antagonistic
2841 and unwilling to cooperate, other mechanisms are appropriate, like
2842 manually configured DNS.
2843
2844 In an environment where there is a group of cooperating participants,
2845 but clients cannot be sure that there are no antagonistic hosts on
2846 the same physical link, the cooperating participants need to use
2847 IPsec signatures and/or DNSSEC [RFC4033] signatures so that they can
2848 distinguish Multicast DNS messages from trusted participants (which
2849 they process as usual) from Multicast DNS messages from untrusted
2850 participants (which they silently discard).
2851
2852
2853
2854
2855
2856
2857 Cheshire & Krochmal Standards Track [Page 52]
2858 RFC 6762 Multicast DNS February 2013
2859
2860
2861 If DNS queries for *global* DNS names are sent to the mDNS multicast
2862 address (during network outages which disrupt communication with the
2863 greater Internet) it is *especially* important to use DNSSEC, because
2864 the user may have the impression that he or she is communicating with
2865 some authentic host, when in fact he or she is really communicating
2866 with some local host that is merely masquerading as that name. This
2867 is less critical for names ending with ".local.", because the user
2868 should be aware that those names have only local significance and no
2869 global authority is implied.
2870
2871 Most computer users neglect to type the trailing dot at the end of a
2872 fully qualified domain name, making it a relative domain name (e.g.,
2873 "www.example.com"). In the event of network outage, attempts to
2874 positively resolve the name as entered will fail, resulting in
2875 application of the search list, including ".local.", if present. A
2876 malicious host could masquerade as "www.example.com." by answering
2877 the resulting Multicast DNS query for "www.example.com.local.". To
2878 avoid this, a host MUST NOT append the search suffix ".local.", if
2879 present, to any relative (partially qualified) host name containing
2880 two or more labels. Appending ".local." to single-label relative
2881 host names is acceptable, since the user should have no expectation
2882 that a single-label host name will resolve as is. However, users who
2883 have both "example.com" and "local" in their search lists should be
2884 aware that if they type "www" into their web browser, it may not be
2885 immediately clear to them whether the page that appears is
2886 "www.example.com" or "www.local".
2887
2888 Multicast DNS uses UDP port 5353. On operating systems where only
2889 privileged processes are allowed to use ports below 1024, no such
2890 privilege is required to use port 5353.
2891
2892 22. IANA Considerations
2893
2894 IANA has allocated the UDP port 5353 for the Multicast DNS protocol
2895 described in this document [SN].
2896
2897 IANA has allocated the IPv4 link-local multicast address 224.0.0.251
2898 for the use described in this document [MC4].
2899
2900 IANA has allocated the IPv6 multicast address set FF0X::FB (where "X"
2901 indicates any hexadecimal digit from '1' to 'F') for the use
2902 described in this document [MC6]. Only address FF02::FB (link-local
2903 scope) is currently in use by deployed software, but it is possible
2904 that in the future implementers may experiment with Multicast DNS
2905 using larger-scoped addresses, such as FF05::FB (site-local scope)
2906 [RFC4291].
2907
2908
2909
2910
2911
2912 Cheshire & Krochmal Standards Track [Page 53]
2913 RFC 6762 Multicast DNS February 2013
2914
2915
2916 IANA has implemented the following DNS records:
2917
2918 MDNS.MCAST.NET. IN A 224.0.0.251
2919 251.0.0.224.IN-ADDR.ARPA. IN PTR MDNS.MCAST.NET.
2920
2921 Entries for the AAAA and corresponding PTR records have not been made
2922 as there is not yet an RFC providing direction for the management of
2923 the IP6.ARPA domain relating to the IPv6 multicast address space.
2924
2925 The reuse of the top bit of the rrclass field in the Question and
2926 Resource Record Sections means that Multicast DNS can only carry DNS
2927 records with classes in the range 0-32767. Classes in the range
2928 32768 to 65535 are incompatible with Multicast DNS. IANA has noted
2929 this fact, and if IANA receives a request to allocate a DNS class
2930 value above 32767, IANA will make sure the requester is aware of this
2931 implication before proceeding. This does not mean that allocations
2932 of DNS class values above 32767 should be denied, only that they
2933 should not be allowed until the requester has indicated that they are
2934 aware of how this allocation will interact with Multicast DNS.
2935 However, to date, only three DNS classes have been assigned by IANA
2936 (1, 3, and 4), and only one (1, "Internet") is actually in widespread
2937 use, so this issue is likely to remain a purely theoretical one.
2938
2939 IANA has recorded the list of domains below as being Special-Use
2940 Domain Names [RFC6761]:
2941
2942 .local.
2943 .254.169.in-addr.arpa.
2944 .8.e.f.ip6.arpa.
2945 .9.e.f.ip6.arpa.
2946 .a.e.f.ip6.arpa.
2947 .b.e.f.ip6.arpa.
2948
2949 22.1. Domain Name Reservation Considerations
2950
2951 The six domains listed above, and any names falling within those
2952 domains (e.g., "MyPrinter.local.", "34.12.254.169.in-addr.arpa.",
2953 "Ink-Jet._pdl-datastream._tcp.local.") are special [RFC6761] in the
2954 following ways:
2955
2956 1. Users may use these names as they would other DNS names,
2957 entering them anywhere that they would otherwise enter a
2958 conventional DNS name, or a dotted decimal IPv4 address, or a
2959 literal IPv6 address.
2960
2961 Since there is no central authority responsible for assigning
2962 dot-local names, and all devices on the local network are
2963 equally entitled to claim any dot-local name, users SHOULD be
2964
2965
2966
2967 Cheshire & Krochmal Standards Track [Page 54]
2968 RFC 6762 Multicast DNS February 2013
2969
2970
2971 aware of this and SHOULD exercise appropriate caution. In an
2972 untrusted or unfamiliar network environment, users SHOULD be
2973 aware that using a name like "www.local" may not actually
2974 connect them to the web site they expected, and could easily
2975 connect them to a different web page, or even a fake or spoof
2976 of their intended web site, designed to trick them into
2977 revealing confidential information. As always with networking,
2978 end-to-end cryptographic security can be a useful tool. For
2979 example, when connecting with ssh, the ssh host key
2980 verification process will inform the user if it detects that
2981 the identity of the entity they are communicating with has
2982 changed since the last time they connected to that name.
2983
2984 2. Application software may use these names as they would other
2985 similar DNS names, and is not required to recognize the names
2986 and treat them specially. Due to the relative ease of spoofing
2987 dot-local names, end-to-end cryptographic security remains
2988 important when communicating across a local network, just as it
2989 is when communicating across the global Internet.
2990
2991 3. Name resolution APIs and libraries SHOULD recognize these names
2992 as special and SHOULD NOT send queries for these names to their
2993 configured (unicast) caching DNS server(s). This is to avoid
2994 unnecessary load on the root name servers and other name
2995 servers, caused by queries for which those name servers do not
2996 have useful non-negative answers to give, and will not ever
2997 have useful non-negative answers to give.
2998
2999 4. Caching DNS servers SHOULD recognize these names as special and
3000 SHOULD NOT attempt to look up NS records for them, or otherwise
3001 query authoritative DNS servers in an attempt to resolve these
3002 names. Instead, caching DNS servers SHOULD generate immediate
3003 NXDOMAIN responses for all such queries they may receive (from
3004 misbehaving name resolver libraries). This is to avoid
3005 unnecessary load on the root name servers and other name
3006 servers.
3007
3008 5. Authoritative DNS servers SHOULD NOT by default be configurable
3009 to answer queries for these names, and, like caching DNS
3010 servers, SHOULD generate immediate NXDOMAIN responses for all
3011 such queries they may receive. DNS server software MAY provide
3012 a configuration option to override this default, for testing
3013 purposes or other specialized uses.
3014
3015 6. DNS server operators SHOULD NOT attempt to configure
3016 authoritative DNS servers to act as authoritative for any of
3017 these names. Configuring an authoritative DNS server to act as
3018 authoritative for any of these names may not, in many cases,
3019
3020
3021
3022 Cheshire & Krochmal Standards Track [Page 55]
3023 RFC 6762 Multicast DNS February 2013
3024
3025
3026 yield the expected result. Since name resolver libraries and
3027 caching DNS servers SHOULD NOT send queries for those names
3028 (see 3 and 4 above), such queries SHOULD be suppressed before
3029 they even reach the authoritative DNS server in question, and
3030 consequently it will not even get an opportunity to answer
3031 them.
3032
3033 7. DNS Registrars MUST NOT allow any of these names to be
3034 registered in the normal way to any person or entity. These
3035 names are reserved protocol identifiers with special meaning
3036 and fall outside the set of names available for allocation by
3037 registrars. Attempting to allocate one of these names as if it
3038 were a normal domain name will probably not work as desired,
3039 for reasons 3, 4, and 6 above.
3040
3041 23. Acknowledgments
3042
3043 The concepts described in this document have been explored,
3044 developed, and implemented with help from Ran Atkinson, Richard
3045 Brown, Freek Dijkstra, Erik Guttman, Kyle McKay, Pasi Sarolahti,
3046 Pekka Savola, Robby Simpson, Mark Townsley, Paul Vixie, Bill
3047 Woodcock, and others. Special thanks go to Bob Bradley, Josh
3048 Graessley, Scott Herscher, Rory McGuire, Roger Pantos, and Kiren
3049 Sekar for their significant contributions. Special thanks also to
3050 Kerry Lynn for converting the document to xml2rfc form in May 2010,
3051 and to Area Director Ralph Droms for shepherding the document through
3052 its final steps.
3053
3054 24. References
3055
3056 24.1. Normative References
3057
3058 [MC4] IANA, "IPv4 Multicast Address Space Registry",
3059 <http://www.iana.org/assignments/multicast-addresses/>.
3060
3061 [MC6] IANA, "IPv6 Multicast Address Space Registry",
3062 <http://www.iana.org/assignments/
3063 ipv6-multicast-addresses/>.
3064
3065 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
3066 October 1969.
3067
3068 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
3069 STD 13, RFC 1034, November 1987.
3070
3071 [RFC1035] Mockapetris, P., "Domain names - implementation and
3072 specification", STD 13, RFC 1035, November 1987.
3073
3074
3075
3076
3077 Cheshire & Krochmal Standards Track [Page 56]
3078 RFC 6762 Multicast DNS February 2013
3079
3080
3081 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3082 Requirement Levels", BCP 14, RFC 2119, March 1997.
3083
3084 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
3085 10646", STD 63, RFC 3629, November 2003.
3086
3087 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
3088 Rose, "Resource Records for the DNS Security Extensions",
3089 RFC 4034, March 2005.
3090
3091 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
3092 Interchange", RFC 5198, March 2008.
3093
3094 [RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA
3095 Considerations", BCP 42, RFC 6195, March 2011.
3096
3097 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
3098 RFC 6761, February 2013.
3099
3100 [SN] IANA, "Service Name and Transport Protocol Port Number
3101 Registry", <http://www.iana.org/assignments/
3102 service-names-port-numbers/>.
3103
3104 24.2. Informative References
3105
3106 [B4W] "Bonjour for Windows",
3107 <http://en.wikipedia.org/wiki/Bonjour_(software)>.
3108
3109 [BJ] Apple Bonjour Open Source Software,
3110 <http://developer.apple.com/bonjour/>.
3111
3112 [IEEE.802.3]
3113 "Information technology - Telecommunications and
3114 information exchange between systems - Local and
3115 metropolitan area networks - Specific requirements - Part
3116 3: Carrier Sense Multiple Access with Collision Detection
3117 (CMSA/CD) Access Method and Physical Layer
3118 Specifications", IEEE Std 802.3-2008, December 2008,
3119 <http://standards.ieee.org/getieee802/802.3.html>.
3120
3121 [IEEE.802.11]
3122 "Information technology - Telecommunications and
3123 information exchange between systems - Local and
3124 metropolitan area networks - Specific requirements - Part
3125 11: Wireless LAN Medium Access Control (MAC) and Physical
3126 Layer (PHY) Specifications", IEEE Std 802.11-2007, June
3127 2007, <http://standards.ieee.org/getieee802/802.11.html>.
3128
3129
3130
3131
3132 Cheshire & Krochmal Standards Track [Page 57]
3133 RFC 6762 Multicast DNS February 2013
3134
3135
3136 [Jumbo] "Ethernet Jumbo Frames", November 2009,
3137 <http://www.ethernetalliance.org/library/whitepaper/
3138 ethernet-jumbo-frames/>.
3139
3140 [NIAS] Cheshire, S. "Discovering Named Instances of Abstract
3141 Services using DNS", Work in Progress, July 2001.
3142
3143 [NSD] "NsdManager | Android Developer", June 2012,
3144 <http://developer.android.com/reference/
3145 android/net/nsd/NsdManager.html>.
3146
3147 [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
3148 location of services (DNS SRV)", RFC 2052, October 1996.
3149
3150 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
3151 Extensions", RFC 2132, March 1997.
3152
3153 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
3154 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
3155 RFC 2136, April 1997.
3156
3157 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
3158 Specification", RFC 2181, July 1997.
3159
3160 [RFC2535] Eastlake 3rd, D., "Domain Name System Security
3161 Extensions", RFC 2535, March 1999.
3162
3163 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
3164 2671, August 1999.
3165
3166 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
3167 Wellington, "Secret Key Transaction Authentication for DNS
3168 (TSIG)", RFC 2845, May 2000.
3169
3170 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
3171 RR)", RFC 2930, September 2000.
3172
3173 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
3174 ( SIG(0)s )", RFC 2931, September 2000.
3175
3176 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
3177 Update", RFC 3007, November 2000.
3178
3179 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
3180 for Internationalized Domain Names in Applications
3181 (IDNA)", RFC 3492, March 2003.
3182
3183
3184
3185
3186
3187 Cheshire & Krochmal Standards Track [Page 58]
3188 RFC 6762 Multicast DNS February 2013
3189
3190
3191 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
3192 Configuration of IPv4 Link-Local Addresses", RFC 3927, May
3193 2005.
3194
3195 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
3196 Rose, "DNS Security Introduction and Requirements", RFC
3197 4033, March 2005.
3198
3199 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
3200 Architecture", RFC 4291, February 2006.
3201
3202 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
3203 Multicast Name Resolution (LLMNR)", RFC 4795, January
3204 2007.
3205
3206 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
3207 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
3208 September 2007.
3209
3210 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
3211 Address Autoconfiguration", RFC 4862, September 2007.
3212
3213 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
3214 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3215 May 2008.
3216
3217 [RFC5890] Klensin, J., "Internationalized Domain Names for
3218 Applications (IDNA): Definitions and Document Framework",
3219 RFC 5890, August 2010.
3220
3221 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
3222 "Understanding Apple's Back to My Mac (BTMM) Service", RFC
3223 6281, June 2011.
3224
3225 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol
3226 to Replace the AppleTalk Name Binding Protocol (NBP)", RFC
3227 6760, February 2013.
3228
3229 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
3230 Discovery", RFC 6763, February 2013.
3231
3232 [Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration
3233 Networking: The Definitive Guide", O'Reilly Media, Inc.,
3234 ISBN 0-596-10100-7, December 2005.
3235
3236
3237
3238
3239
3240
3241
3242 Cheshire & Krochmal Standards Track [Page 59]
3243 RFC 6762 Multicast DNS February 2013
3244
3245
3246 Appendix A. Design Rationale for Choice of UDP Port Number
3247
3248 Arguments were made for and against using UDP port 53, the standard
3249 Unicast DNS port. Some of the arguments are given below. The
3250 arguments for using a different port were greater in number and more
3251 compelling, so that option was ultimately selected. The UDP port
3252 "5353" was selected for its mnemonic similarity to "53".
3253
3254 Arguments for using UDP port 53:
3255
3256 * This is "just DNS", so it should be the same port.
3257
3258 * There is less work to be done updating old resolver libraries to do
3259 simple Multicast DNS queries. Only the destination address need be
3260 changed. In some cases, this can be achieved without any code
3261 changes, just by adding the address 224.0.0.251 to a configuration
3262 file.
3263
3264 Arguments for using a different port (UDP port 5353):
3265
3266 * This is not "just DNS". This is a DNS-like protocol, but
3267 different.
3268
3269 * Changing resolver library code to use a different port number is
3270 not hard. In some cases, this can be achieved without any code
3271 changes, just by adding the address 224.0.0.251:5353 to a
3272 configuration file.
3273
3274 * Using the same port number makes it hard to run a Multicast DNS
3275 responder and a conventional Unicast DNS server on the same
3276 machine. If a conventional Unicast DNS server wishes to implement
3277 Multicast DNS as well, it can still do that, by opening two
3278 sockets. Having two different port numbers allows this
3279 flexibility.
3280
3281 * Some VPN software hijacks all outgoing traffic to port 53 and
3282 redirects it to a special DNS server set up to serve those VPN
3283 clients while they are connected to the corporate network. It is
3284 questionable whether this is the right thing to do, but it is
3285 common, and redirecting link-local multicast DNS packets to a
3286 remote server rarely produces any useful results. It does mean,
3287 for example, that a user of such VPN software becomes unable to
3288 access their local network printer sitting on their desk right next
3289 to their computer. Using a different UDP port helps avoid this
3290 particular problem.
3291
3292
3293
3294
3295
3296
3297 Cheshire & Krochmal Standards Track [Page 60]
3298 RFC 6762 Multicast DNS February 2013
3299
3300
3301 * On many operating systems, unprivileged software may not send or
3302 receive packets on low-numbered ports. This means that any
3303 software sending or receiving Multicast DNS packets on port 53
3304 would have to run as "root", which is an undesirable security risk.
3305 Using a higher-numbered UDP port avoids this restriction.
3306
3307 Appendix B. Design Rationale for Not Using Hashed Multicast Addresses
3308
3309 Some discovery protocols use a range of multicast addresses, and
3310 determine the address to be used by a hash function of the name being
3311 sought. Queries are sent via multicast to the address as indicated
3312 by the hash function, and responses are returned to the querier via
3313 unicast. Particularly in IPv6, where multicast addresses are
3314 extremely plentiful, this approach is frequently advocated. For
3315 example, IPv6 Neighbor Discovery [RFC4861] sends Neighbor
3316 Solicitation messages to the "solicited-node multicast address",
3317 which is computed as a function of the solicited IPv6 address.
3318
3319 There are some disadvantages to using hashed multicast addresses like
3320 this in a service discovery protocol:
3321
3322 * When a host has a large number of records with different names, the
3323 host may have to join a large number of multicast groups. Each
3324 time a host joins or leaves a multicast group, this results in
3325 Internet Group Management Protocol (IGMP) or Multicast Listener
3326 Discovery (MLD) traffic on the network announcing this fact.
3327 Joining a large number of multicast groups can place undue burden
3328 on the Ethernet hardware, which typically supports a limited number
3329 of multicast addresses efficiently. When this number is exceeded,
3330 the Ethernet hardware may have to resort to receiving all
3331 multicasts and passing them up to the host networking code for
3332 filtering in software, thereby defeating much of the point of using
3333 a multicast address range in the first place. Finally, many IPv6
3334 stacks have a fixed limit IPV6_MAX_MEMBERSHIPS, and the code simply
3335 fails with an error if a client attempts to exceed this limit.
3336 Common values for IPV6_MAX_MEMBERSHIPS are 20 or 31.
3337
3338 * Multiple questions cannot be placed in one packet if they don't all
3339 hash to the same multicast address.
3340
3341 * Duplicate Question Suppression doesn't work if queriers are not
3342 seeing each other's queries.
3343
3344 * Duplicate Answer Suppression doesn't work if responders are not
3345 seeing each other's responses.
3346
3347 * Opportunistic Caching doesn't work.
3348
3349
3350
3351
3352 Cheshire & Krochmal Standards Track [Page 61]
3353 RFC 6762 Multicast DNS February 2013
3354
3355
3356 * Ongoing Conflict Detection doesn't work.
3357
3358 Appendix C. Design Rationale for Maximum Multicast DNS Name Length
3359
3360 Multicast DNS names may be up to 255 bytes long (in the on-the-wire
3361 message format), not counting the terminating zero byte at the end.
3362
3363 "Domain Names - Implementation and Specification" [RFC1035] says:
3364
3365 Various objects and parameters in the DNS have size limits. They
3366 are listed below. Some could be easily changed, others are more
3367 fundamental.
3368
3369 labels 63 octets or less
3370
3371 names 255 octets or less
3372
3373 ...
3374
3375 the total length of a domain name (i.e., label octets and label
3376 length octets) is restricted to 255 octets or less.
3377
3378 This text does not state whether this 255-byte limit includes the
3379 terminating zero at the end of every name.
3380
3381 Several factors lead us to conclude that the 255-byte limit does
3382 *not* include the terminating zero:
3383
3384 o It is common in software engineering to have size limits that are a
3385 power of two, or a multiple of a power of two, for efficiency. For
3386 example, an integer on a modern processor is typically 2, 4, or 8
3387 bytes, not 3 or 5 bytes. The number 255 is not a power of two, nor
3388 is it to most people a particularly noteworthy number. It is
3389 noteworthy to computer scientists for only one reason -- because it
3390 is exactly one *less* than a power of two. When a size limit is
3391 exactly one less than a power of two, that suggests strongly that
3392 the one extra byte is being reserved for some specific reason -- in
3393 this case reserved, perhaps, to leave room for a terminating zero
3394 at the end.
3395
3396 o In the case of DNS label lengths, the stated limit is 63 bytes. As
3397 with the total name length, this limit is exactly one less than a
3398 power of two. This label length limit also excludes the label
3399 length byte at the start of every label. Including that extra
3400 byte, a 63-byte label takes 64 bytes of space in memory or in a DNS
3401 message.
3402
3403
3404
3405
3406
3407 Cheshire & Krochmal Standards Track [Page 62]
3408 RFC 6762 Multicast DNS February 2013
3409
3410
3411 o It is common in software engineering for the semantic "length" of
3412 an object to be one less than the number of bytes it takes to store
3413 that object. For example, in C, strlen("foo") is 3, but
3414 sizeof("foo") (which includes the terminating zero byte at the end)
3415 is 4.
3416
3417 o The text describing the total length of a domain name mentions
3418 explicitly that label length and data octets are included, but does
3419 not mention the terminating zero at the end. The zero byte at the
3420 end of a domain name is not a label length. Indeed, the value zero
3421 is chosen as the terminating marker precisely because it is not a
3422 legal length byte value -- DNS prohibits empty labels. For
3423 example, a name like "bad..name." is not a valid domain name
3424 because it contains a zero-length label in the middle, which cannot
3425 be expressed in a DNS message, because software parsing the message
3426 would misinterpret a zero label-length byte as being a zero "end of
3427 name" marker instead.
3428
3429 Finally, "Clarifications to the DNS Specification" [RFC2181] offers
3430 additional confirmation that, in the context of DNS specifications,
3431 the stated "length" of a domain name does not include the terminating
3432 zero byte at the end. That document refers to the root name, which
3433 is typically written as "." and is represented in a DNS message by a
3434 single lone zero byte (i.e., zero bytes of data plus a terminating
3435 zero), as the "zero length full name":
3436
3437 The zero length full name is defined as representing the root of
3438 the DNS tree, and is typically written and displayed as ".".
3439
3440 This wording supports the interpretation that, in a DNS context, when
3441 talking about lengths of names, the terminating zero byte at the end
3442 is not counted. If the root name (".") is considered to be zero
3443 length, then to be consistent, the length (for example) of "org" has
3444 to be 4 and the length of "ietf.org" has to be 9, as shown below:
3445
3446 ------
3447 | 0x00 | length = 0
3448 ------
3449
3450 ------------------ ------
3451 | 0x03 | o | r | g | | 0x00 | length = 4
3452 ------------------ ------
3453
3454 ----------------------------------------- ------
3455 | 0x04 | i | e | t | f | 0x03 | o | r | g | | 0x00 | length = 9
3456 ----------------------------------------- ------
3457
3458
3459
3460
3461
3462 Cheshire & Krochmal Standards Track [Page 63]
3463 RFC 6762 Multicast DNS February 2013
3464
3465
3466 This means that the maximum length of a domain name, as represented
3467 in a Multicast DNS message, up to but not including the final
3468 terminating zero, must not exceed 255 bytes.
3469
3470 However, many Unicast DNS implementers have read these RFCs
3471 differently, and argue that the 255-byte limit does include the
3472 terminating zero, and that the "Clarifications to the DNS
3473 Specification" [RFC2181] statement that "." is the "zero length full
3474 name" was simply a mistake.
3475
3476 Hence, implementers should be aware that other Unicast DNS
3477 implementations may limit the maximum domain name to 254 bytes plus a
3478 terminating zero, depending on how that implementer interpreted the
3479 DNS specifications.
3480
3481 Compliant Multicast DNS implementations MUST support names up to 255
3482 bytes plus a terminating zero, i.e., 256 bytes total.
3483
3484 Appendix D. Benefits of Multicast Responses
3485
3486 Some people have argued that sending responses via multicast is
3487 inefficient on the network. In fact, using multicast responses can
3488 result in a net lowering of overall multicast traffic for a variety
3489 of reasons, and provides other benefits too:
3490
3491 * Opportunistic Caching. One multicast response can update the
3492 caches on all machines on the network. If another machine later
3493 wants to issue the same query, and it already has the answer in its
3494 cache, it may not need to even transmit that multicast query on the
3495 network at all.
3496
3497 * Duplicate Query Suppression. When more than one machine has the
3498 same ongoing long-lived query running, every machine does not have
3499 to transmit its own independent query. When one machine transmits
3500 a query, all the other hosts see the answers, so they can suppress
3501 their own queries.
3502
3503 * Passive Observation Of Failures (POOF). When a host sees a
3504 multicast query, but does not see the corresponding multicast
3505 response, it can use this information to promptly delete stale data
3506 from its cache. To achieve the same level of user-interface
3507 quality and responsiveness without multicast responses would
3508 require lower cache lifetimes and more frequent network polling,
3509 resulting in a higher packet rate.
3510
3511 * Passive Conflict Detection. Just because a name has been
3512 previously verified to be unique does not guarantee it will
3513 continue to be so indefinitely. By allowing all Multicast DNS
3514
3515
3516
3517 Cheshire & Krochmal Standards Track [Page 64]
3518 RFC 6762 Multicast DNS February 2013
3519
3520
3521 responders to constantly monitor their peers' responses, conflicts
3522 arising out of network topology changes can be promptly detected
3523 and resolved. If responses were not sent via multicast, some other
3524 conflict detection mechanism would be needed, imposing its own
3525 additional burden on the network.
3526
3527 * Use on devices with constrained memory resources: When using
3528 delayed responses to reduce network collisions, responders need to
3529 maintain a list recording to whom each answer should be sent. The
3530 option of multicast responses allows responders with limited
3531 storage, which cannot store an arbitrarily long list of response
3532 addresses, to choose to fail-over to a single multicast response in
3533 place of multiple unicast responses, when appropriate.
3534
3535 * Overlayed Subnets. In the case of overlayed subnets, multicast
3536 responses allow a receiver to know with certainty that a response
3537 originated on the local link, even when its source address may
3538 apparently suggest otherwise.
3539
3540 * Robustness in the face of misconfiguration: Link-local multicast
3541 transcends virtually every conceivable network misconfiguration.
3542 Even if you have a collection of devices where every device's IP
3543 address, subnet mask, default gateway, and DNS server address are
3544 all wrong, packets sent by any of those devices addressed to a
3545 link-local multicast destination address will still be delivered to
3546 all peers on the local link. This can be extremely helpful when
3547 diagnosing and rectifying network problems, since it facilitates a
3548 direct communication channel between client and server that works
3549 without reliance on ARP, IP routing tables, etc. Being able to
3550 discover what IP address a device has (or thinks it has) is
3551 frequently a very valuable first step in diagnosing why it is
3552 unable to communicate on the local network.
3553
3554 Appendix E. Design Rationale for Encoding Negative Responses
3555
3556 Alternative methods of asserting nonexistence were considered, such
3557 as using an NXDOMAIN response, or emitting a resource record with
3558 zero-length rdata.
3559
3560 Using an NXDOMAIN response does not work well with Multicast DNS. A
3561 Unicast DNS NXDOMAIN response applies to the entire message, but for
3562 efficiency Multicast DNS allows (and encourages) multiple responses
3563 in a single message. If the error code in the header were NXDOMAIN,
3564 it would not be clear to which name(s) that error code applied.
3565
3566 Asserting nonexistence by emitting a resource record with zero-length
3567 rdata would mean that there would be no way to differentiate between
3568 a record that doesn't exist, and a record that does exist, with zero-
3569
3570
3571
3572 Cheshire & Krochmal Standards Track [Page 65]
3573 RFC 6762 Multicast DNS February 2013
3574
3575
3576 length rdata. By analogy, most file systems today allow empty files,
3577 so a file that exists with zero bytes of data is not considered
3578 equivalent to a filename that does not exist.
3579
3580 A benefit of asserting nonexistence through NSEC records instead of
3581 through NXDOMAIN responses is that NSEC records can be added to the
3582 Additional Section of a DNS response to offer additional information
3583 beyond what the querier explicitly requested. For example, in
3584 response to an SRV query, a responder should include A record(s)
3585 giving its IPv4 addresses in the Additional Section, and an NSEC
3586 record indicating which other types it does or does not have for this
3587 name. If the responder is running on a host that does not support
3588 IPv6 (or does support IPv6 but currently has no IPv6 address on that
3589 interface) then this NSEC record in the Additional Section will
3590 indicate this absence of AAAA records. In effect, the responder is
3591 saying, "Here's my SRV record, and here are my IPv4 addresses, and
3592 no, I don't have any IPv6 addresses, so don't waste your time
3593 asking". Without this information in the Additional Section, it
3594 would take the querier an additional round-trip to perform an
3595 additional query to ascertain that the target host has no AAAA
3596 records. (Arguably Unicast DNS could also benefit from this ability
3597 to express nonexistence in the Additional Section, but that is
3598 outside the scope of this document.)
3599
3600 Appendix F. Use of UTF-8
3601
3602 After many years of debate, as a result of the perceived need to
3603 accommodate certain DNS implementations that apparently couldn't
3604 handle any character that's not a letter, digit, or hyphen (and
3605 apparently never would be updated to remedy this limitation), the
3606 Unicast DNS community settled on an extremely baroque encoding called
3607 "Punycode" [RFC3492]. Punycode is a remarkably ingenious encoding
3608 solution, but it is complicated, hard to understand, and hard to
3609 implement, using sophisticated techniques including insertion unsort
3610 coding, generalized variable-length integers, and bias adaptation.
3611 The resulting encoding is remarkably compact given the constraints,
3612 but it's still not as good as simple straightforward UTF-8, and it's
3613 hard even to predict whether a given input string will encode to a
3614 Punycode string that fits within DNS's 63-byte limit, except by
3615 simply trying the encoding and seeing whether it fits. Indeed, the
3616 encoded size depends not only on the input characters, but on the
3617 order they appear, so the same set of characters may or may not
3618 encode to a legal Punycode string that fits within DNS's 63-byte
3619 limit, depending on the order the characters appear. This is
3620 extremely hard to present in a user interface that explains to users
3621 why one name is allowed, but another name containing the exact same
3622 characters is not. Neither Punycode nor any other of the "ASCII-
3623 Compatible Encodings" [RFC5890] proposed for Unicast DNS may be used
3624
3625
3626
3627 Cheshire & Krochmal Standards Track [Page 66]
3628 RFC 6762 Multicast DNS February 2013
3629
3630
3631 in Multicast DNS messages. Any text being represented internally in
3632 some other representation must be converted to canonical precomposed
3633 UTF-8 before being placed in any Multicast DNS message.
3634
The 'Next Domain Name' field contains the record's own name. When used with name compression, this means that the 'Next Domain Name' field always takes exactly two bytes in the message.
The 'Next Domain Name' field contains the record's own name.When used with name compression, this means that the 'Next Domain Name' field always takes exactly two bytes in the message.
3635 Appendix G. Private DNS Namespaces
3636
3637 The special treatment of names ending in ".local." has been
3638 implemented in Macintosh computers since the days of Mac OS 9, and
3639 continues today in Mac OS X and iOS. There are also implementations
3640 for Microsoft Windows [B4W], Linux, and other platforms.
3641
3642 Some network operators setting up private internal networks
3643 ("intranets") have used unregistered top-level domains, and some may
3644 have used the ".local" top-level domain. Using ".local" as a private
3645 top-level domain conflicts with Multicast DNS and may cause problems
3646 for users. Clients can be configured to send both Multicast and
3647 Unicast DNS queries in parallel for these names, and this does allow
3648 names to be looked up both ways, but this results in additional
3649 network traffic and additional delays in name resolution, as well as
3650 potentially creating user confusion when it is not clear whether any
3651 given result was received via link-local multicast from a peer on the
3652 same link, or from the configured unicast name server. Because of
3653 this, we recommend against using ".local" as a private Unicast DNS
3654 top-level domain. We do not recommend use of unregistered top-level
3655 domains at all, but should network operators decide to do this, the
3656 following top-level domains have been used on private internal
3657 networks without the problems caused by trying to reuse ".local." for
3658 this purpose:
3659
3660 .intranet.
3661 .internal.
3662 .private.
3663 .corp.
3664 .home.
3665 .lan.
3666
3667 Appendix H. Deployment History
3668
3669 In July 1997, in an email to the net-thinkers@thumper.vmeng.com
3670 mailing list, Stuart Cheshire first proposed the idea of running the
3671 AppleTalk Name Binding Protocol [RFC6760] over IP. As a result of
3672 this and related IETF discussions, the IETF Zeroconf working group
3673 was chartered September 1999. After various working group
3674 discussions and other informal IETF discussions, several Internet-
3675 Drafts were written that were loosely related to the general themes
3676 of DNS and multicast, but did not address the service discovery
3677 aspect of NBP.
3678
3679
3680
3681
3682 Cheshire & Krochmal Standards Track [Page 67]
3683 RFC 6762 Multicast DNS February 2013
3684
3685
3686 In April 2000, Stuart Cheshire registered IPv4 multicast address
3687 224.0.0.251 with IANA [MC4] and began writing code to test and
3688 develop the idea of performing NBP-like service discovery using
3689 Multicast DNS, which was documented in a group of three Internet-
3690 Drafts:
3691
3692 o "Requirements for a Protocol to Replace the AppleTalk Name Binding
3693 Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk
3694 Name Binding Protocol, because many in the IETF community had
3695 little first-hand experience using AppleTalk, and confusion in the
3696 IETF community about what AppleTalk NBP did was causing confusion
3697 about what would be required in an IP-based replacement.
3698
3699 o "Discovering Named Instances of Abstract Services using DNS" [NIAS]
3700 proposed a way to perform NBP-like service discovery using DNS-
3701 compatible names and record types.
3702
3703 o "Multicast DNS" (this document) specifies a way to transport those
3704 DNS-compatible queries and responses using IP multicast, for zero-
3705 configuration environments where no conventional Unicast DNS server
3706 was available.
3707
3708 In 2001, an update to Mac OS 9 added resolver library support for
3709 host name lookup using Multicast DNS. If the user typed a name such
3710 as "MyPrinter.local." into any piece of networking software that used
3711 the standard Mac OS 9 name lookup APIs, then those name lookup APIs
3712 would recognize the name as a dot-local name and query for it by
3713 sending simple one-shot Multicast DNS queries to 224.0.0.251:5353.
3714 This enabled the user to, for example, enter the name
3715 "MyPrinter.local." into their web browser in order to view a
3716 printer's status and configuration web page, or enter the name
3717 "MyPrinter.local." into the printer setup utility to create a print
3718 queue for printing documents on that printer.
3719
3720 Multicast DNS responder software, with full service discovery, first
3721 began shipping to end users in volume with the launch of Mac OS X
3722 10.2 "Jaguar" in August 2002, and network printer makers (who had
3723 historically supported AppleTalk in their network printers and were
3724 receptive to IP-based technologies that could offer them similar
3725 ease-of-use) started adopting Multicast DNS shortly thereafter.
3726
3727 In September 2002, Apple released the source code for the
3728 mDNSResponder daemon as Open Source under Apple's standard Apple
3729 Public Source License (APSL).
3730
3731 Multicast DNS responder software became available for Microsoft
3732 Windows users in June 2004 with the launch of Apple's "Rendezvous for
3733 Windows" (now "Bonjour for Windows"), both in executable form (a
3734
3735
3736
3737 Cheshire & Krochmal Standards Track [Page 68]
3738 RFC 6762 Multicast DNS February 2013
3739
3740
3741 downloadable installer for end users) and as Open Source (one of the
3742 supported platforms within Apple's body of cross-platform code in the
3743 publicly accessible mDNSResponder CVS source code repository) [BJ].
3744
3745 In August 2006, Apple re-licensed the cross-platform mDNSResponder
3746 source code under the Apache License, Version 2.0.
3747
3748 In addition to desktop and laptop computers running Mac OS X and
3749 Microsoft Windows, Multicast DNS is now implemented in a wide range
3750 of hardware devices, such as Apple's "AirPort" wireless base
3751 stations, iPhone and iPad, and in home gateways from other vendors,
3752 network printers, network cameras, TiVo DVRs, etc.
3753
3754 The Open Source community has produced many independent
3755 implementations of Multicast DNS, some in C like Apple's
3756 mDNSResponder daemon, and others in a variety of different languages
3757 including Java, Python, Perl, and C#/Mono.
3758
3759 In January 2007, the IETF published the Informational RFC "Link-Local
3760 Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially
3761 similar to Multicast DNS, but incompatible in some small but
3762 important ways. In particular, the LLMNR design explicitly excluded
3763 support for service discovery, which made it an unsuitable candidate
3764 for a protocol to replace AppleTalk NBP [RFC6760].
3765
3766 While the original focus of Multicast DNS and DNS-Based Service
3767 Discovery was for zero-configuration environments without a
3768 conventional Unicast DNS server, DNS-Based Service Discovery also
3769 works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007]
3770 to create service discovery records and standard DNS queries to query
3771 for them. Apple's Back to My Mac service, launched with Mac OS X
3772 10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over
3773 Unicast DNS [RFC6281].
3774
3775 In June 2012, Google's Android operating system added native support
3776 for DNS-SD and Multicast DNS with the android.net.nsd.NsdManager
3777 class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792 Cheshire & Krochmal Standards Track [Page 69]
3793 RFC 6762 Multicast DNS February 2013
3794
3795
3796 Authors' Addresses
3797
3798 Stuart Cheshire
3799 Apple Inc.
3800 1 Infinite Loop
3801 Cupertino, CA 95014
3802 USA
3803
3804 Phone: +1 408 974 3207
3805 EMail: cheshire@apple.com
3806
3807
3808 Marc Krochmal
3809 Apple Inc.
3810 1 Infinite Loop
3811 Cupertino, CA 95014
3812 USA
3813
3814 Phone: +1 408 974 4368
3815 EMail: marc@apple.com
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847 Cheshire & Krochmal Standards Track [Page 70]
3848
We do not recommend use of unregistered top-level
domains at all, but should network operators decide to do this, the
following top-level domains have been used on private internal
networks without the problems caused by trying to reuse ".local." for
this purpose:
.intranet.
.internal.
.private.
.corp.
.home.
.lan.
We do not recommend use of unregistered top-level domains.
Since TLDs like .private are currently available for register. Appendix G is outdated and I would strongly advise the IETF to remove the suggested TLDs since they are no longer problem free. I believe that it is wise to make a harder statement in the RFC. --VERIFIER NOTES-- During the development of this RFC, the text is consistent with the consensus of the community. Later developments by ICANN superseded the appendix, but that is not applicable for an erratum. Updates to the text should be proposed via the draft publication process.