forked from avahi/avahi
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-cheshire-dnsext-multicastdns-05.txt
2640 lines (1913 loc) · 119 KB
/
draft-cheshire-dnsext-multicastdns-05.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Document: draft-cheshire-dnsext-multicastdns-05.txt Stuart Cheshire
Category: Standards Track Apple Computer, Inc.
Expires 7th December 2005 Marc Krochmal
Apple Computer, Inc.
7th June 2005
Multicast DNS
<draft-cheshire-dnsext-multicastdns-05.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
become aware will be disclosed, in accordance with RFC 3979.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
As networked devices become smaller, more portable, and more
ubiquitous, the ability to operate with less configured
infrastructure is increasingly important. In particular, the ability
to look up DNS resource record data types (including, but not limited
to, host names) in the absence of a conventional managed DNS server,
is becoming essential.
Multicast DNS (mDNS) provides the ability to do DNS-like operations
on the local link in the absence of any conventional unicast DNS
server. In addition, mDNS designates a portion of the DNS namespace
to be free for local use, without the need to pay any annual fee, and
without the need to set up delegations or otherwise configure a
conventional DNS server to answer for those names.
The primary benefits of mDNS names are that (i) they require little
or no administration or configuration to set them up, (ii) they work
when no infrastructure is present, and (iii) they work during
infrastructure failures.
Expires 7th December 2005 Cheshire & Krochmal [Page 1]
Internet Draft Multicast DNS 7th June 2005
Table of Contents
1. Introduction...................................................3
2. Conventions and Terminology Used in this Document..............4
3. Multicast DNS Names............................................5
4. Source Address Check...........................................8
5. Reverse Address Mapping........................................9
6. Querying.......................................................9
7. Duplicate Suppression.........................................13
8. Responding....................................................15
9. Probing and Announcing on Startup.............................18
10. Conflict Resolution...........................................22
11. Resource Record TTL Values and Cache Coherency................23
12. Special Characteristics of Multicast DNS Domains..............28
13. Multicast DNS for Service Discovery...........................30
14. Enabling and Disabling Multicast DNS..........................30
15. Considerations for Multiple Interfaces........................30
16. Multicast DNS and Power Management............................31
17. Multicast DNS Character Set...................................32
18. Multicast DNS Message Size....................................34
19. Multicast DNS Message Format..................................34
20. Choice of UDP Port Number.....................................37
21. Summary of Differences Between Multicast DNS and Unicast DNS..38
22. Benefits of Multicast Responses...............................38
23. IPv6 Considerations...........................................39
24. Security Considerations.......................................40
25. IANA Considerations...........................................41
26. Acknowledgments...............................................42
27. Copyright.....................................................42
28. Normative References..........................................42
29. Informative References........................................43
30. Authors' Addresses............................................44
Expires 7th December 2005 Cheshire & Krochmal [Page 2]
Internet Draft Multicast DNS 7th June 2005
1. Introduction
When reading this document, familiarity with the concepts of Zero
Configuration Networking [ZC] and automatic link-local addressing
[RFC 2462] [RFC 3927] is helpful.
This document proposes no change to the structure of DNS messages,
and no new operation codes, response codes, or resource record types.
This document simply discusses what needs to happen if DNS clients
start sending DNS queries to a multicast address, and how a
collection of hosts can cooperate to collectively answer those
queries in a useful manner.
There has been discussion of how much burden Multicast DNS might
impose on a network. It should be remembered that whenever IPv4 hosts
communicate, they broadcast ARP packets on the network on a regular
basis, and this is not disastrous. The approximate amount of
multicast traffic generated by hosts making conventional use of
Multicast DNS is anticipated to be roughly the same order of
magnitude as the amount of broadcast ARP traffic those hosts already
generate.
New applications making new use of Multicast DNS capabilities for
unconventional purposes may generate more traffic. If some of those
new applications are "chatty", then work will be needed to help them
become less chatty. When performing any analysis, it is important to
make a distinction between the application behavior and the
underlying protocol behavior. If a chatty application uses UDP, that
doesn't mean that UDP is chatty, or that IP is chatty, or that
Ethernet is chatty. What it means is that the application is chatty.
The same applies to any future applications that may decide to layer
increasing portions of their functionality over Multicast DNS.
Expires 7th December 2005 Cheshire & Krochmal [Page 3]
Internet Draft Multicast DNS 7th June 2005
2. Conventions and Terminology Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC 2119].
This document uses the term "host name" in the strict sense to mean a
fully qualified domain name that has an address record. It does not
use the term "host name" in the commonly used but incorrect sense to
mean just the first DNS label of a host's fully qualified domain
name.
A DNS (or mDNS) packet contains an IP TTL in the IP header, which
is effectively a hop-count limit for the packet, to guard against
routing loops. Each Resource Record also contains a TTL, which is
the number of seconds for which the Resource Record may be cached.
In any place where there may be potential confusion between these two
types of TTL, the term "IP TTL" is used to refer to the IP header TTL
(hop limit), and the term "RR TTL" is used to refer to the Resource
Record TTL (cache lifetime).
When this document uses the term "Multicast DNS", it should be taken
to mean: "Clients performing DNS-like queries for DNS-like resource
records by sending DNS-like UDP query and response packets over IP
Multicast to UDP port 5353."
This document uses the terms "shared" and "unique" when referring to
resource record sets.
A "shared" resource record set is one where several Multicast DNS
responders may have records with that name, rrtype, and rrclass, and
several responders may respond to a particular query.
A "unique" resource record set is one where all the records with that
name, rrtype, and rrclass are under the control or ownership of a
single responder, and at most one responder should respond to any
given query. Before claiming ownership of a unique resource record
set, a responder MUST probe to verify that no other responder
already claims ownership of that set, as described in Section 9.1
"Probing".
Strictly speaking the terms "shared" and "unique" apply to resource
record sets, not to individual resource records, but it is sometimes
convenient to talk of "shared resource records" and "unique resource
records". When used this way, the terms should be understood to mean
a record that is a member of a "shared" or "unique" resource record
set, respectively.
Expires 7th December 2005 Cheshire & Krochmal [Page 4]
Internet Draft Multicast DNS 7th June 2005
3. Multicast DNS Names
This document proposes that the DNS top-level domain ".local." be
designated a special domain with special semantics, namely that any
fully-qualified name ending in ".local." is link-local, and names
within this domain are meaningful only on the link where they
originate. This is analogous to IPv4 addresses in the 169.254/16
prefix, which are link-local and meaningful only on the link where
they originate.
Any DNS query for a name ending with ".local." MUST be sent
to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent
FF02::FB).
It is unimportant whether a name ending with ".local." occurred
because the user explicitly typed in a fully qualified domain name
ending in ".local.", or because the user entered an unqualified
domain name and the host software appended the suffix ".local."
because that suffix appears in the user's search list. The ".local."
suffix could appear in the search list because the user manually
configured it, or because it was received in a DHCP option, or via
any other valid mechanism for configuring the DNS search list. In
this respect the ".local." suffix is treated no differently to any
other search domain that might appear in the DNS search list.
DNS queries for names that do not end with ".local." MAY be sent to
the mDNS multicast address, if no other conventional DNS server is
available. This can allow hosts on the same link to continue
communicating using each other's globally unique DNS names during
network outages which disrupt communication with the greater
Internet. When resolving global names via local multicast, it is even
more important to use DNSSEC or other security mechanisms to ensure
that the response is trustworthy. Resolving global names via local
multicast is a contentious issue, and this document does not discuss
it in detail, instead concentrating on the issue of resolving local
names using DNS packets sent to a multicast address.
A host which belongs to an organization or individual who has control
over some portion of the DNS namespace can be assigned a globally
unique name within that portion of the DNS namespace, for example,
"cheshire.apple.com." For those of us who have this luxury, this
works very well. However, the majority of home customers do not have
easy access to any portion of the global DNS namespace within which
they have the authority to create names as they wish. This leaves the
majority of home computers effectively anonymous for practical
purposes.
To remedy this problem, this document allows any computer user to
elect to give their computers link-local Multicast DNS host names of
the form: "single-dns-label.local." For example, a laptop computer
may answer to the name "cheshire.local." Any computer user is granted
the authority to name their computer this way, provided that the
chosen host name is not already in use on that link. Having named
Expires 7th December 2005 Cheshire & Krochmal [Page 5]
Internet Draft Multicast DNS 7th June 2005
their computer this way, the user has the authority to continue using
that name until such time as a name conflict occurs on the link which
is not resolved in the user's favour. If this happens, the computer
(or its human user) SHOULD cease using the name, and may choose to
attempt to allocate a new unique name for use on that link. These
conflicts are expected to be relatively rare for people who choose
reasonably imaginative names, but it is still important to have a
mechanism in place to handle them when they happen.
The point made in the previous paragraph is very important and bears
repeating. It is easy for those of us in the IETF community who run
our own name servers at home to forget that the majority of computer
users do not run their own name server and have no easy way to create
their own host names. When these users wish to transfer files between
two laptop computers, they are frequently reduced to typing in
dotted-decimal IP addresses because they simply have no other way for
one host to refer to the other by name. This is a sorry state of
affairs. What is worse, most users don't even bother trying to use
dotted-decimal IP addresses. Most users still move data between
machines by copying it onto a floppy disk or similar removable media.
In a world of gigabit Ethernet and ubiquitous wireless networking it
is a sad indictment of the networking community that the preferred
communication medium for most computer users is still the floppy
disk.
Allowing ad-hoc allocation of single-label names in a single flat
".local." namespace may seem to invite chaos. However, operational
experience with AppleTalk NBP names [NBP], which on any given link
are also effectively single-label names in a flat namespace, shows
that in practice name collisions happen extremely rarely and are not
a problem. Groups of computer users from disparate organizations
bring Macintosh laptop computers to events such as IETF Meetings, the
Mac Hack conference, the Apple World Wide Developer Conference, etc.,
and complaints at these events about users suffering conflicts and
being forced to rename their machines have never been an issue.
Enforcing uniqueness of host names (i.e. the names of DNS address
records mapping names to IP addresses) is probably desirable in the
common case, but this document does not mandate that. It is
permissible for a collection of coordinated hosts to agree to
maintain multiple DNS address records with the same name, possibly
for load balancing or fault-tolerance reasons. This document does not
take a position on whether that is sensible. It is important that
both modes of operation are supported. The Multicast DNS protocol
allows hosts to verify and maintain unique names for resource records
where that behavior is desired, and it also allows hosts to maintain
multiple resource records with a single shared name where that
behavior is desired. This consideration applies to all resource
records, not just address records (host names). In summary: It is
required that the protocol have the ability to detect and handle name
conflicts, but it is not required that this ability be used for every
record.
Expires 7th December 2005 Cheshire & Krochmal [Page 6]
Internet Draft Multicast DNS 7th June 2005
3.1 Governing Standards Body
Note that this use of the ".local." suffix falls under IETF
jurisdiction, not ICANN jurisdiction. DNS is an IETF network
protocol, governed by protocol rules defined by the IETF. These IETF
protocol rules dictate character set, maximum name length, packet
format, etc. ICANN determines additional rules that apply when the
IETF's DNS protocol is used on the public Internet. In contrast,
private uses of the DNS protocol on isolated private networks are not
governed by ICANN. Since this proposed change is a change to the core
DNS protocol rules, it affects everyone, not just those machines
using the ICANN-governed Internet. Hence this change falls into the
category of an IETF protocol rule, not an ICANN usage rule.
3.2 Private DNS Namespaces
Note also that the special treatment of names ending in ".local." has
been implemented in Macintosh computers since the days of Mac OS 9,
and continues today in Mac OS X. There are also implementations for
Linux and other platforms [dotlocal]. Operators setting up private
internal networks ("intranets") are advised that their lives may be
easier if they avoid using the suffix ".local." in names in their
private internal DNS server. Alternative possibilities include:
.intranet
.internal
.private
.corp
.home
Another alternative naming scheme, advocated by Professor D. J.
Bernstein, is to use a numerical suffix, such as ".6." [djbdl].
3.3 Maximum Multicast DNS Name Length
RFC 1034 says:
"the total number of octets that represent a domain name (i.e.,
the sum of all label octets and label lengths) is limited to 255."
This text implies that the final root label at the end of every name
is included in this count (a name can't be represented without it),
but the text does not explicitly state that. Implementations of
Multicast DNS MUST include the label length byte of the final root
label at the end of every name when enforcing the rule that no name
may be longer than 255 bytes. For example, the length of the name
"apple.com." is considered to be 11, which is the number of bytes it
takes to represent that name in a packet without using name
compression:
------------------------------------------------------
| 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 |
------------------------------------------------------
Expires 7th December 2005 Cheshire & Krochmal [Page 7]
Internet Draft Multicast DNS 7th June 2005
4. Source Address Check
All Multicast DNS responses (including responses sent via unicast)
SHOULD be sent with IP TTL set to 255. This is recommended to provide
backwards-compatibility with older Multicast DNS clients that check
the IP TTL on reception to determine whether the packet originated
on the local link. These older clients discard all packets with TTLs
other than 255.
A host sending Multicast DNS queries to a link-local destination
address (including the 224.0.0.251 link-local multicast address)
MUST only accept responses to that query that originate from the
local link, and silently discard any other response packets. Without
this check, it could be possible for remote rogue hosts to send
spoof answer packets (perhaps unicast to the victim host) which the
receiving machine could misinterpret as having originated on the
local link.
The test for whether a response originated on the local link
is done in two ways:
* All responses sent to the link-local multicast address 224.0.0.251
are necessarily deemed to have originated on the local link,
regardless of source IP address. This is essential to allow devices
to work correctly and reliably in unusual configurations, such as
multiple logical IP subnets overlayed on a single link, or in cases
of severe misconfiguration, where devices are physically connected
to the same link, but are currently misconfigured with completely
unrelated IP addresses and subnet masks.
* For responses sent to a unicast destination address, the source IP
address in the packet is checked to see if it is an address on a
local subnet. An address is determined to be on a local subnet if,
for (one of) the address(es) configured on the interface receiving
the packet, (I & M) == (P & M), where I and M are the interface
address and subnet mask respectively, P is the source IP address
from the packet, '&' represents the bitwise logical 'and'
operation, and '==' represents a bitwise equality test.
Since queriers will ignore responses apparently originating outside
the local subnet, responders SHOULD avoid generating responses that
it can reasonably predict will be ignored. This applies particularly
in the case of overlayed subnets. If a responder receives a query
addressed to the link-local multicast address 224.0.0.251, from a
source address not apparently on the same subnet as the responder,
then even if the query indicates that a unicast response is preferred
(see Section 6.5, "Questions Requesting Unicast Responses"), the
responder SHOULD elect to respond by multicast anyway, since it can
reasonably predict that a unicast response with an apparently
non-local source address will probably be ignored.
Expires 7th December 2005 Cheshire & Krochmal [Page 8]
Internet Draft Multicast DNS 7th June 2005
5. Reverse Address Mapping
Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also
defined to be link-local.
Any DNS query for a name ending with "254.169.in-addr.arpa." MUST
be sent to the mDNS multicast address 224.0.0.251. Since names under
this domain correspond to IPv4 link-local addresses, it is logical
that the local link is the best place to find information pertaining
to those names. As an optimization, these queries MAY be first
unicast directly to the address in question, but if this query is not
answered, the query MUST also be sent via multicast, to accommodate
the case where the machine in question is not answering for itself
(for example, because it is currently sleeping).
Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa."
MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB,
with or without an optional initial query unicast directly to the
address in question.
6. Querying
There are three kinds of Multicast DNS Queries, one-shot queries of
the kind made by today's conventional DNS clients, one-shot queries
accumulating multiple responses made by multicast-aware DNS clients,
and continuous ongoing Multicast DNS Queries used by IP network
browser software.
A Multicast DNS Responder that is offering records that are intended
to be unique on the local link MUST also implement a Multicast DNS
Querier so that it can first verify the uniqueness of those records
before it begins answering queries for them.
6.1 One-Shot Queries
An unsophisticated DNS client may simply send its DNS queries
blindly to the 224.0.0.251 multicast address, without necessarily
even being aware what a multicast address is.
Such an unsophisticated DNS client may not get ideal behavior. Such
a client may simply take the first response it receives and fail to
wait to see if there are more, but in many instances this may not be
a serious problem. If a user types "http://cheshire.local." into
their Web browser and gets to see the page they were hoping for,
then the protocol has met the user's needs in this case.
Expires 7th December 2005 Cheshire & Krochmal [Page 9]
Internet Draft Multicast DNS 7th June 2005
6.2 One-Shot Queries, Accumulating Multiple Responses
A more sophisticated DNS client should understand that Multicast DNS
is not exactly the same as unicast DNS, and should modify its
behavior in some simple ways.
As described above, there are some cases, such as looking up the
address associated with a unique host name, where a single response
is sufficient, and moreover may be all that is expected. However,
there are other DNS queries where more than one response is
possible, and for these queries a more sophisticated Multicast DNS
client should include the ability to wait for an appropriate period
of time to collect multiple responses.
A naive DNS client retransmits its query only so long as it has
received no response. A more sophisticated Multicast DNS client is
aware that having received one response is not necessarily an
indication that it might not receive others, and has the ability to
retransmit its query an appropriate number of times at appropriate
intervals until it is satisfied with the collection of responses it
has gathered.
A more sophisticated Multicast DNS client that is retransmitting
a query for which it has already received some responses, MUST
implement Known Answer Suppression, as described below in Section
7.1. This indicates to responders who have already replied that their
responses have been received, and they don't need to send them again
in response to this repeated query. In addition, the interval between
the first two queries SHOULD be one second, and the intervals between
subsequent queries SHOULD double.
6.3 Continuous Querying
In One-Shot Queries, with either a single or multiple responses,
the underlying assumption is that the transaction begins when the
application issues a query, and ends when all the desired responses
have been received. There is another type of operation which is more
akin to continuous monitoring.
Macintosh users are accustomed to opening the "Chooser" window,
selecting a desired printer, and then closing the Chooser window.
However, when the desired printer does not appear in the list, the
user will typically leave the "Chooser" window open while they go and
check to verify that the printer is plugged in, powered on, connected
to the Ethernet, etc. While the user jiggles the wires, hits the
Ethernet hub, and so forth, they keep an eye on the Chooser window,
and when the printer name appears, they know they have fixed whatever
the problem was. This can be a useful and intuitive troubleshooting
technique, but a user who goes home for the weekend leaving the
Chooser window open places a non-trivial burden on the network.
Expires 7th December 2005 Cheshire & Krochmal [Page 10]
Internet Draft Multicast DNS 7th June 2005
With continuous querying, multiple queries are sent over a long
period of time, until the user terminates the operation. It is
important that an IP network browser window displaying live
information from the network using Multicast DNS, if left running
for an extended period of time, should generate significantly less
multicast traffic on the network than the old AppleTalk Chooser.
Therefore, the interval between the first two queries SHOULD be one
second, the intervals between subsequent queries SHOULD double, and
the querier MUST implement Known Answer Suppression, as described
below in Section 7.1. When the interval between queries reaches or
exceeds 60 minutes, a querier MAY cap the interval to a maximum of 60
minutes, and perform subsequent queries at a steady-state rate of one
query per hour.
When a Multicast DNS Querier receives an answer, the answer contains
a TTL value that indicates for how many seconds this answer is valid.
After this interval has passed, the answer will no longer be valid
and SHOULD be deleted from the cache. Before this time is reached, a
Multicast DNS Querier with an ongoing interest in that record SHOULD
re-issue its query to determine whether the record is still valid,
and if so update its expiry time.
To perform this cache maintenance, a Multicast DNS Querier should
plan to re-query for records after at least 50% of the record
lifetime has elapsed. This document recommends the following
specific strategy:
The Querier should plan to issue a query at 80% of the record
lifetime, and then if no answer is received, at 85%, 90% and 95%. If
an answer is received, then the remaining TTL is reset to the value
given in the answer, and this process repeats for as long as the
Multicast DNS Querier has an ongoing interest in the record. If after
four queries no answer is received, the record is deleted when it
reaches 100% of its lifetime.
To avoid the case where multiple Multicast DNS Queriers on a network
all issue their queries simultaneously, a random variation of 2% of
the record TTL should be added, so that queries are scheduled to be
performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL.
6.4 Multiple Questions per Query
Multicast DNS allows a querier to place multiple questions in the
Question Section of a single Multicast DNS query packet.
The semantics of a Multicast DNS query packet containing multiple
questions is identical to a series of individual DNS query packets
containing one question each. Combining multiple questions into a
single packet is purely an efficiency optimization, and has no other
semantic significance.
Expires 7th December 2005 Cheshire & Krochmal [Page 11]
Internet Draft Multicast DNS 7th June 2005
A useful technique for adaptively combining multiple questions into a
single query is to use a Nagle-style algorithm: When a client issues
its first question, a Query packet is immediately built and sent,
without delay. If the client then continues issuing a rapid series of
questions they are held until either the first query receives at
least one answer, or 100ms has passed, or there are enough questions
to fill the Question Section of a Multicast DNS query packet. At this
time, all the held questions are placed into a Multicast DNS query
packet and sent.
6.5 Questions Requesting Unicast Responses
Sending Multicast DNS responses via multicast has the benefit that
all the other hosts on the network get to see those responses, and
can keep their caches up to date, and detect conflicting responses.
However, there are situations where all the other hosts on the
network don't need to see every response. One example is a laptop
computer waking from sleep. At that instant it is a brand new
participant on a new network. Its Multicast DNS cache is empty, and
it has no knowledge of its surroundings. It may have a significant
number of queries that it wants answered right away to discover
information about its new surroundings and present that information
to the user. As a new participant on the network, it has no idea
whether the exact same questions may have been asked and answered
just seconds ago. In this case, trigging a large sudden flood of
multicast responses may impose an unreasonable burden on the network.
To avoid this, the Multicast DNS Querier SHOULD set the top bit in
the class field of its DNS question(s), to indicate that it is
willing to accept unicast responses instead of the usual multicast
responses. These questions requesting unicast responses are referred
to as "QU" questions, to distinguish them from the more usual
questions requesting multicast responses ("QM" questions).
When retransmitting a question more than once, the 'unicast response'
bit SHOULD be set only for the first question of the series. After
the first question has received its responses, the querier should
have a large known-answer list (see "Known Answer Suppression" below)
so that subsequent queries should elicit few, if any, further
responses. Reverting to multicast responses as soon as possible is
important because of the benefits that multicast responses provide
(see "Benefits of Multicast Responses" below).
When receiving a question with the 'unicast response' bit set, a
responder SHOULD usually respond with a unicast packet directed back
to the querier. If the responder has not multicast that record
recently (within one quarter of its TTL), then the responder SHOULD
instead multicast the response so as to keep all the peer caches up
to date, and to permit passive conflict detection.
Unicast replies are subject to all the same packet generation rules
as multicast replies, including the cache flush bit (see Section
11.3, "Announcements to Flush Outdated Cache Entries") and randomized
delays to reduce network collisions (see Section 8, "Responding").
Expires 7th December 2005 Cheshire & Krochmal [Page 12]
Internet Draft Multicast DNS 7th June 2005
6.6 Suppressing Initial Query
If a query is issued for which there already exist one or more
records in the local cache, and those record(s) were received with
the cache flush bit set (see Section 11.3, "Announcements to Flush
Outdated Cache Entries"), indicating that they form a unique RRSet,
then the host SHOULD suppress its initial "QU" query, and proceed to
issue a "QM" query. To avoid the situation where a group of hosts
are synchronized by some external event and all perform the same
query simultaneously, a host suppressing its initial "QU" query
SHOULD impose a random delay from 500-1000ms before transmitting its
first "QM" query for this question. This means that when the first
host (selected randomly by this algorithm) transmits its "QM" query,
all the other hosts that were about to transmit the same query can
suppress their superfluous query, as described in "Duplicate
Question Suppression" below.
7. Duplicate Suppression
A variety of techniques are used to reduce the amount of redundant
traffic on the network.
7.1 Known Answer Suppression
When a Multicast DNS Querier sends a query to which it already knows
some answers, it populates the Answer Section of the DNS message with
those answers.
A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if
the answer it would give is already included in the Answer Section
with an RR TTL at least half the correct value. If the RR TTL of the
answer as given in the Answer Section is less than half of the true
RR TTL as known by the Multicast DNS Responder, the responder MUST
send an answer so as to update the Querier's cache before the record
becomes in danger of expiration.
Because a Multicast DNS Responder will respond if the remaining TTL
given in the known answer list is less than half the true TTL, it is
superfluous for the Querier to include such records in the known
answer list. Therefore a Multicast DNS Querier SHOULD NOT include
records in the known answer list whose remaining TTL is less than
half their original TTL. Doing so would simply consume space in the
packet without achieving the goal of suppressing responses, and would
therefore be a pointless waste of network bandwidth.
A Multicast DNS Querier MUST NOT cache resource records observed in
the Known Answer Section of other Multicast DNS Queries. The Answer
Section of Multicast DNS Queries is not authoritative. By placing
information in the Answer Section of a Multicast DNS Query the
querier is stating that it *believes* the information to be true.
It is not asserting that the information *is* true. Some of those
records may have come from other hosts that are no longer on the
network. Propagating that stale information to other Multicast DNS
Queriers on the network would not be helpful.
Expires 7th December 2005 Cheshire & Krochmal [Page 13]
Internet Draft Multicast DNS 7th June 2005
7.2 Multi-Packet Known Answer Suppression
Sometimes a Multicast DNS Querier will already have too many answers
to fit in the Known Answer Section of its query packets. In this
case, it should issue a Multicast DNS Query containing a question and
as many Known Answer records as will fit. It MUST then set the TC
(Truncated) bit in the header before sending the Query. It MUST then
immediately follow the packet with another query packet containing no
questions, and as many more Known Answer records as will fit. If
there are still too many records remaining to fit in the packet, it
again sets the TC bit and continues until all the Known Answer
records have been sent.
A Multicast DNS Responder seeing a Multicast DNS Query with the TC
bit set defers its response for a time period randomly selected in
the interval 400-500ms. This gives the Multicast DNS Querier time to
send additional Known Answer packets before the Responder responds.
If the Responder sees any of its answers listed in the Known Answer
lists of subsequent packets from the querying host, it SHOULD delete
that answer from the list of answers it is planning to give, provided
that no other host on the network is also waiting to receive the same
answer record.
Previous versions of this draft specified a delay of 20-120ms before
answering queries with multi-packet Known Answer lists. However,
operational experience showed that, while this works well on
Ethernet, on very busy 802.11 networks, it is not uncommon to observe
consecutively sent packets arriving separated by as much as
200-400ms.
7.3 Duplicate Question Suppression
If a host is planning to send a query, and it sees another host on
the network send a query containing the same question, and the Known
Answer Section of that query does not contain any records which this
host would not also put in its own Known Answer Section, then this
host should treat its own query as having been sent. When multiple
clients on the network are querying for the same resource records,
there is no need for them to all be repeatedly asking the same
question.
7.4 Duplicate Answer Suppression
If a host is planning to send an answer, and it sees another host on
the network send a response packet containing the same answer record,
and the TTL in that record is not less than the TTL this host would
have given, then this host should treat its own answer as having been
sent. When multiple responders on the network have the same data,
there is no need for all of them to respond.
Expires 7th December 2005 Cheshire & Krochmal [Page 14]
Internet Draft Multicast DNS 7th June 2005
This feature is particularly useful when multiple Sleep Proxy Servers
are deployed (see Section 16, "Multicast DNS and Power Management").
In the future it is possible that every general-purpose OS (Mac,
Windows, Linux, etc.) will implement Sleep Proxy Service as a matter
of course. In this case there could be a large number of Sleep Proxy
Servers on any given network, which is good for reliability and
fault-tolerance, but would be bad for the network if every Sleep
Proxy Server were to answer every query.
8. Responding
When a Multicast DNS Responder constructs and sends a Multicast DNS
response packet, the Answer Section of that packet must contain only
records for which that Responder is explicitly authoritative. These
answers may be generated because the record answers a question
received in a Multicast DNS query packet, or at certain other times
that the responder determines than an unsolicited announcement is
warranted. A Multicast DNS Responder MUST NOT place records from its
cache, which have been learned from other responders on the network,
in the Answer Section of outgoing response packets. Only an
authoritative source for a given record is allowed to issue responses
containing that record.
The determination of whether a given record answers a given question
is done using the standard DNS rules: The record name must match the
question name, the record rrtype must match the question qtype
(unless the qtype is "ANY"), and the record rrclass must match the
question qclass (unless the qclass is "ANY").
A Multicast DNS Responder MUST only respond when it has a positive
non-null response to send. Error responses must never be sent. The
non-existence of any name in a Multicast DNS Domain is ascertained by
the failure of any machine to respond to the Multicast DNS query, not
by NXDOMAIN errors.
Multicast DNS Responses MUST NOT contain any questions in the
Question Section. Any questions in the Question Section of a received
Multicast DNS Response MUST be silently ignored. Multicast DNS
Queriers receiving Multicast DNS Responses do not care what question
elicited the response; they care only that the information in the
response is true and accurate.
A Multicast DNS Responder on Ethernet [IEEE802] and similar shared
multiple access networks SHOULD have the capability of delaying its
responses by up to 500ms, as determined by the rules described below.
If multiple Multicast DNS Responders were all to respond immediately
to a particular query, a collision would be virtually guaranteed. By
imposing a small random delay, the number of collisions is
dramatically reduced. On a full-sized Ethernet using the maximum
cable lengths allowed and the maximum number of repeaters allowed, an
Ethernet frame is vulnerable to collisions during the transmission of
its first 256 bits. On 10Mb/s Ethernet, this equates to a vulnerable
Expires 7th December 2005 Cheshire & Krochmal [Page 15]
Internet Draft Multicast DNS 7th June 2005
time window of 25.6us. On higher-speed variants of Ethernet, the
vulnerable time window is shorter.
In the case where a Multicast DNS Responder has good reason to
believe that it will be the only responder on the link with a
positive non-null response, it SHOULD NOT impose any random delay
before responding, and SHOULD normally generate its response within
at most 10ms. In particular, this applies to responding to probe
queries. Since receiving a probe query gives a clear indication that
some other Responder is planning to start using this name in the very
near future, answering such probe queries to defend a unique record
is a high priority and needs to be done immediately, without delay. A
probe query can be distinguished from a normal query by the fact that
a probe query contains a proposed record in the Authority Section
which answers the question in the Question Section (for more details,
see Section 9.1, "Probing").
To generate immediate responses safely, it MUST have previously
verified that the requested name, rrtype and rrclass in the DNS query
are unique on this link. Responding immediately without delay is
appropriate for things like looking up the address record for a
particular host name, when the host name has been previously verified
unique. Responding immediately without delay is *not* appropriate for
things like looking up PTR records used for DNS Service Discovery
[DNS-SD], where a large number of responses may be anticipated.
In any case where there may be multiple responses, such as queries
where the answer is a member of a shared resource record set, each
responder SHOULD delay its response by a random amount of time
selected with uniform random distribution in the range 20-120ms.
In the case where the query has the TC (truncated) bit set,
indicating that subsequent known answer packets will follow,
responders SHOULD delay their responses by a random amount of time
selected with uniform random distribution in the range 400-500ms,
to allow enough time for all the known answer packets to arrive.
Except when a unicast reply has been explicitly requested via the
"unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port
5353 (the well-known port assigned to mDNS) on the 224.0.0.251
multicast address (or its IPv6 equivalent FF02::FB). Operating in a
Zeroconf environment requires constant vigilance. Just because a name
has been previously verified unique does not mean it will continue to
be so indefinitely. By allowing all Multicast DNS Responders to
constantly monitor their peers' responses, conflicts arising out of
network topology changes can be promptly detected and resolved.
Sending all responses by multicast also facilitates opportunistic
caching by other hosts on the network.
To protect the network against excessive packet flooding due to
software bugs or malicious attack, a Multicast DNS Responder MUST NOT
multicast a given record on a given interface if it has previously
Expires 7th December 2005 Cheshire & Krochmal [Page 16]
Internet Draft Multicast DNS 7th June 2005
multicast that record on that interface within the last second. A
legitimate client on the network should have seen the previous
transmission and cached it. A client that did not receive and cache
the previous transmission will retry its request and receive a
subsequent response. Under no circumstances is there any legitimate
reason for a Multicast DNS Responder to multicast a given record more
than once per second on any given interface.
8.1 Legacy Unicast Responses
If the source UDP port in a received Multicast DNS Query is not port
5353, this indicates that the client originating the query is a
simple client that does not fully implement all of Multicast DNS. In
this case, the Multicast DNS Responder MUST send a UDP response
directly back to the client, via unicast, to the query packet's
source IP address and port. This unicast response MUST be a
conventional unicast response as would be generated by a conventional
unicast DNS server; for example, it MUST repeat the query ID and the
question given in the query packet.
The resource record TTL given in a legacy unicast response SHOULD NOT
be greater than ten seconds, even if the true TTL of the Multicast
DNS resource record is higher. This is because Multicast DNS
Responders that fully participate in the protocol use the cache
coherency mechanisms described in Section 13 to update and invalidate
stale data. Were unicast responses sent to legacy clients to use the
same high TTLs, these legacy clients, which do not implement these
cache coherency mechanisms, could retain stale cached resource record
data long after it is no longer valid.
Having sent this unicast response, if the Responder has not sent this
record in any multicast response recently, it SHOULD schedule the
record to be sent via multicast as well, to facilitate passive
conflict detection. "Recently" in this context means "if the time
since the record was last sent via multicast is less than one quarter