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