[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795, January
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
"Understanding Apple's Back to My Mac (BTMM) Service", RFC
6281, June 2011.
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol
to Replace the AppleTalk Name Binding Protocol (NBP)", RFC
6760, February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
[Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration
Networking: The Definitive Guide", O'Reilly Media, Inc.,
ISBN 0-596-10100-7, December 2005.
Appendix A. Design Rationale for Choice of UDP Port Number
Arguments were made for and against using UDP port 53, the standard
Unicast DNS port. Some of the arguments are given below. The
arguments for using a different port were greater in number and more
compelling, so that option was ultimately selected. The UDP port
"5353" was selected for its mnemonic similarity to "53".
Arguments for using UDP port 53:
* This is "just DNS", so it should be the same port.
* There is less work to be done updating old resolver libraries to do
simple Multicast DNS queries. Only the destination address need be
changed. In some cases, this can be achieved without any code
changes, just by adding the address 126.96.36.199 to a configuration
Arguments for using a different port (UDP port 5353):
* This is not "just DNS". This is a DNS-like protocol, but
* Changing resolver library code to use a different port number is
not hard. In some cases, this can be achieved without any code
changes, just by adding the address 188.8.131.52:5353 to a
* Using the same port number makes it hard to run a Multicast DNS
responder and a conventional Unicast DNS server on the same
machine. If a conventional Unicast DNS server wishes to implement
Multicast DNS as well, it can still do that, by opening two
sockets. Having two different port numbers allows this
* Some VPN software hijacks all outgoing traffic to port 53 and
redirects it to a special DNS server set up to serve those VPN
clients while they are connected to the corporate network. It is
questionable whether this is the right thing to do, but it is
common, and redirecting link-local multicast DNS packets to a
remote server rarely produces any useful results. It does mean,
for example, that a user of such VPN software becomes unable to
access their local network printer sitting on their desk right next
to their computer. Using a different UDP port helps avoid this
* On many operating systems, unprivileged software may not send or
receive packets on low-numbered ports. This means that any
software sending or receiving Multicast DNS packets on port 53
would have to run as "root", which is an undesirable security risk.
Using a higher-numbered UDP port avoids this restriction.
Appendix B. Design Rationale for Not Using Hashed Multicast Addresses
Some discovery protocols use a range of multicast addresses, and
determine the address to be used by a hash function of the name being
sought. Queries are sent via multicast to the address as indicated
by the hash function, and responses are returned to the querier via
unicast. Particularly in IPv6, where multicast addresses are
extremely plentiful, this approach is frequently advocated. For
example, IPv6 Neighbor Discovery [RFC4861] sends Neighbor
Solicitation messages to the "solicited-node multicast address",
which is computed as a function of the solicited IPv6 address.
There are some disadvantages to using hashed multicast addresses like
this in a service discovery protocol:
* When a host has a large number of records with different names, the
host may have to join a large number of multicast groups. Each
time a host joins or leaves a multicast group, this results in
Internet Group Management Protocol (IGMP) or Multicast Listener
Discovery (MLD) traffic on the network announcing this fact.
Joining a large number of multicast groups can place undue burden
on the Ethernet hardware, which typically supports a limited number
of multicast addresses efficiently. When this number is exceeded,
the Ethernet hardware may have to resort to receiving all
multicasts and passing them up to the host networking code for
filtering in software, thereby defeating much of the point of using
a multicast address range in the first place. Finally, many IPv6
stacks have a fixed limit IPV6_MAX_MEMBERSHIPS, and the code simply
fails with an error if a client attempts to exceed this limit.
Common values for IPV6_MAX_MEMBERSHIPS are 20 or 31.
* Multiple questions cannot be placed in one packet if they don't all
hash to the same multicast address.
* Duplicate Question Suppression doesn't work if queriers are not
seeing each other's queries.
* Duplicate Answer Suppression doesn't work if responders are not
seeing each other's responses.
* Opportunistic Caching doesn't work.
* Ongoing Conflict Detection doesn't work.
Appendix C. Design Rationale for Maximum Multicast DNS Name Length
Multicast DNS names may be up to 255 bytes long (in the on-the-wire
message format), not counting the terminating zero byte at the end.
"Domain Names - Implementation and Specification" [RFC1035] says:
Various objects and parameters in the DNS have size limits. They
are listed below. Some could be easily changed, others are more
labels 63 octets or less
names 255 octets or less
the total length of a domain name (i.e., label octets and label
length octets) is restricted to 255 octets or less.
This text does not state whether this 255-byte limit includes the
terminating zero at the end of every name.
Several factors lead us to conclude that the 255-byte limit does
*not* include the terminating zero:
o It is common in software engineering to have size limits that are a
power of two, or a multiple of a power of two, for efficiency. For
example, an integer on a modern processor is typically 2, 4, or 8
bytes, not 3 or 5 bytes. The number 255 is not a power of two, nor
is it to most people a particularly noteworthy number. It is
noteworthy to computer scientists for only one reason -- because it
is exactly one *less* than a power of two. When a size limit is
exactly one less than a power of two, that suggests strongly that
the one extra byte is being reserved for some specific reason -- in
this case reserved, perhaps, to leave room for a terminating zero
at the end.
o In the case of DNS label lengths, the stated limit is 63 bytes. As
with the total name length, this limit is exactly one less than a
power of two. This label length limit also excludes the label
length byte at the start of every label. Including that extra
byte, a 63-byte label takes 64 bytes of space in memory or in a DNS
o It is common in software engineering for the semantic "length" of
an object to be one less than the number of bytes it takes to store
that object. For example, in C, strlen("foo") is 3, but
sizeof("foo") (which includes the terminating zero byte at the end)
o The text describing the total length of a domain name mentions
explicitly that label length and data octets are included, but does
not mention the terminating zero at the end. The zero byte at the
end of a domain name is not a label length. Indeed, the value zero
is chosen as the terminating marker precisely because it is not a
legal length byte value -- DNS prohibits empty labels. For
example, a name like "bad..name." is not a valid domain name
because it contains a zero-length label in the middle, which cannot
be expressed in a DNS message, because software parsing the message
would misinterpret a zero label-length byte as being a zero "end of
name" marker instead.
Finally, "Clarifications to the DNS Specification" [RFC2181] offers
additional confirmation that, in the context of DNS specifications,
the stated "length" of a domain name does not include the terminating
zero byte at the end. That document refers to the root name, which
is typically written as "." and is represented in a DNS message by a
single lone zero byte (i.e., zero bytes of data plus a terminating
zero), as the "zero length full name":
The zero length full name is defined as representing the root of
the DNS tree, and is typically written and displayed as ".".
This wording supports the interpretation that, in a DNS context, when
talking about lengths of names, the terminating zero byte at the end
is not counted. If the root name (".") is considered to be zero
length, then to be consistent, the length (for example) of "org" has
to be 4 and the length of "ietf.org" has to be 9, as shown below:
| 0x00 | length = 0
| 0x03 | o | r | g | | 0x00 | length = 4
| 0x04 | i | e | t | f | 0x03 | o | r | g | | 0x00 | length = 9
This means that the maximum length of a domain name, as represented
in a Multicast DNS message, up to but not including the final
terminating zero, must not exceed 255 bytes.
However, many Unicast DNS implementers have read these RFCs
differently, and argue that the 255-byte limit does include the
terminating zero, and that the "Clarifications to the DNS
Specification" [RFC2181] statement that "." is the "zero length full
name" was simply a mistake.
Hence, implementers should be aware that other Unicast DNS
implementations may limit the maximum domain name to 254 bytes plus a
terminating zero, depending on how that implementer interpreted the
Compliant Multicast DNS implementations MUST support names up to 255
bytes plus a terminating zero, i.e., 256 bytes total.
Appendix D. Benefits of Multicast Responses
Some people have argued that sending responses via multicast is
inefficient on the network. In fact, using multicast responses can
result in a net lowering of overall multicast traffic for a variety
of reasons, and provides other benefits too:
* Opportunistic Caching. One multicast response can update the
caches on all machines on the network. If another machine later
wants to issue the same query, and it already has the answer in its
cache, it may not need to even transmit that multicast query on the
network at all.
* Duplicate Query Suppression. When more than one machine has the
same ongoing long-lived query running, every machine does not have
to transmit its own independent query. When one machine transmits
a query, all the other hosts see the answers, so they can suppress
their own queries.
* Passive Observation Of Failures (POOF). When a host sees a
multicast query, but does not see the corresponding multicast
response, it can use this information to promptly delete stale data
from its cache. To achieve the same level of user-interface
quality and responsiveness without multicast responses would
require lower cache lifetimes and more frequent network polling,
resulting in a higher packet rate.
* Passive Conflict Detection. Just because a name has been
previously verified to be unique does not guarantee 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. If responses were not sent via multicast, some other
conflict detection mechanism would be needed, imposing its own
additional burden on the network.
* Use on devices with constrained memory resources: When using
delayed responses to reduce network collisions, responders need to
maintain a list recording to whom each answer should be sent. The
option of multicast responses allows responders with limited
storage, which cannot store an arbitrarily long list of response
addresses, to choose to fail-over to a single multicast response in
place of multiple unicast responses, when appropriate.
* Overlayed Subnets. In the case of overlayed subnets, multicast
responses allow a receiver to know with certainty that a response
originated on the local link, even when its source address may
apparently suggest otherwise.
* Robustness in the face of misconfiguration: Link-local multicast
transcends virtually every conceivable network misconfiguration.
Even if you have a collection of devices where every device's IP
address, subnet mask, default gateway, and DNS server address are
all wrong, packets sent by any of those devices addressed to a
link-local multicast destination address will still be delivered to
all peers on the local link. This can be extremely helpful when
diagnosing and rectifying network problems, since it facilitates a
direct communication channel between client and server that works
without reliance on ARP, IP routing tables, etc. Being able to
discover what IP address a device has (or thinks it has) is
frequently a very valuable first step in diagnosing why it is
unable to communicate on the local network.
Appendix E. Design Rationale for Encoding Negative Responses
Alternative methods of asserting nonexistence were considered, such
as using an NXDOMAIN response, or emitting a resource record with
Using an NXDOMAIN response does not work well with Multicast DNS. A
Unicast DNS NXDOMAIN response applies to the entire message, but for
efficiency Multicast DNS allows (and encourages) multiple responses
in a single message. If the error code in the header were NXDOMAIN,
it would not be clear to which name(s) that error code applied.
Asserting nonexistence by emitting a resource record with zero-length
rdata would mean that there would be no way to differentiate between
a record that doesn't exist, and a record that does exist, with zero-
length rdata. By analogy, most file systems today allow empty files,
so a file that exists with zero bytes of data is not considered
equivalent to a filename that does not exist.
A benefit of asserting nonexistence through NSEC records instead of
through NXDOMAIN responses is that NSEC records can be added to the
Additional Section of a DNS response to offer additional information
beyond what the querier explicitly requested. For example, in
response to an SRV query, a responder should include A record(s)
giving its IPv4 addresses in the Additional Section, and an NSEC
record indicating which other types it does or does not have for this
name. If the responder is running on a host that does not support
IPv6 (or does support IPv6 but currently has no IPv6 address on that
interface) then this NSEC record in the Additional Section will
indicate this absence of AAAA records. In effect, the responder is
saying, "Here's my SRV record, and here are my IPv4 addresses, and
no, I don't have any IPv6 addresses, so don't waste your time
asking". Without this information in the Additional Section, it
would take the querier an additional round-trip to perform an
additional query to ascertain that the target host has no AAAA
records. (Arguably Unicast DNS could also benefit from this ability
to express nonexistence in the Additional Section, but that is
outside the scope of this document.)
Appendix F. Use of UTF-8
After many years of debate, as a result of the perceived need to
accommodate certain DNS implementations that apparently couldn't
handle any character that's not a letter, digit, or hyphen (and
apparently never would be updated to remedy this limitation), the
Unicast DNS community settled on an extremely baroque encoding called
"Punycode" [RFC3492]. Punycode is a remarkably ingenious encoding
solution, but it is complicated, hard to understand, and hard to
implement, using sophisticated techniques including insertion unsort
coding, generalized variable-length integers, and bias adaptation.
The resulting encoding is remarkably compact given the constraints,
but it's still not as good as simple straightforward UTF-8, and it's
hard even to predict whether a given input string will encode to a
Punycode string that fits within DNS's 63-byte limit, except by
simply trying the encoding and seeing whether it fits. Indeed, the
encoded size depends not only on the input characters, but on the
order they appear, so the same set of characters may or may not
encode to a legal Punycode string that fits within DNS's 63-byte
limit, depending on the order the characters appear. This is
extremely hard to present in a user interface that explains to users
why one name is allowed, but another name containing the exact same
characters is not. Neither Punycode nor any other of the "ASCII-
Compatible Encodings" [RFC5890] proposed for Unicast DNS may be used
in Multicast DNS messages. Any text being represented internally in
some other representation must be converted to canonical precomposed
UTF-8 before being placed in any Multicast DNS message.
Appendix G. Private DNS Namespaces
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 and iOS. There are also implementations
for Microsoft Windows [B4W], Linux, and other platforms.
Some network operators setting up private internal networks
("intranets") have used unregistered top-level domains, and some may
have used the ".local" top-level domain. Using ".local" as a private
top-level domain conflicts with Multicast DNS and may cause problems
for users. Clients can be configured to send both Multicast and
Unicast DNS queries in parallel for these names, and this does allow
names to be looked up both ways, but this results in additional
network traffic and additional delays in name resolution, as well as
potentially creating user confusion when it is not clear whether any
given result was received via link-local multicast from a peer on the
same link, or from the configured unicast name server. Because of
this, we recommend against using ".local" as a private Unicast DNS
top-level domain. We do not recommend use of unregistered top-level
domains at all, but should network operators decide to do this, the
following top-level domains have been used on private internal
networks without the problems caused by trying to reuse ".local." for
Appendix H. Deployment History
In July 1997, in an email to the email@example.com
mailing list, Stuart Cheshire first proposed the idea of running the
AppleTalk Name Binding Protocol [RFC6760] over IP. As a result of
this and related IETF discussions, the IETF Zeroconf working group
was chartered September 1999. After various working group
discussions and other informal IETF discussions, several Internet-
Drafts were written that were loosely related to the general themes
of DNS and multicast, but did not address the service discovery
aspect of NBP.
In April 2000, Stuart Cheshire registered IPv4 multicast address
184.108.40.206 with IANA [MC4] and began writing code to test and
develop the idea of performing NBP-like service discovery using
Multicast DNS, which was documented in a group of three Internet-
o "Requirements for a Protocol to Replace the AppleTalk Name Binding
Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk
Name Binding Protocol, because many in the IETF community had
little first-hand experience using AppleTalk, and confusion in the
IETF community about what AppleTalk NBP did was causing confusion
about what would be required in an IP-based replacement.
o "Discovering Named Instances of Abstract Services using DNS" [NIAS]
proposed a way to perform NBP-like service discovery using DNS-
compatible names and record types.
o "Multicast DNS" (this document) specifies a way to transport those
DNS-compatible queries and responses using IP multicast, for zero-
configuration environments where no conventional Unicast DNS server
In 2001, an update to Mac OS 9 added resolver library support for
host name lookup using Multicast DNS. If the user typed a name such
as "MyPrinter.local." into any piece of networking software that used
the standard Mac OS 9 name lookup APIs, then those name lookup APIs
would recognize the name as a dot-local name and query for it by
sending simple one-shot Multicast DNS queries to 220.127.116.11:5353.
This enabled the user to, for example, enter the name
"MyPrinter.local." into their web browser in order to view a
printer's status and configuration web page, or enter the name
"MyPrinter.local." into the printer setup utility to create a print
queue for printing documents on that printer.
Multicast DNS responder software, with full service discovery, first
began shipping to end users in volume with the launch of Mac OS X
10.2 "Jaguar" in August 2002, and network printer makers (who had
historically supported AppleTalk in their network printers and were
receptive to IP-based technologies that could offer them similar
ease-of-use) started adopting Multicast DNS shortly thereafter.
In September 2002, Apple released the source code for the
mDNSResponder daemon as Open Source under Apple's standard Apple
Public Source License (APSL).
Multicast DNS responder software became available for Microsoft
Windows users in June 2004 with the launch of Apple's "Rendezvous for
Windows" (now "Bonjour for Windows"), both in executable form (a
downloadable installer for end users) and as Open Source (one of the
supported platforms within Apple's body of cross-platform code in the
publicly accessible mDNSResponder CVS source code repository) [BJ].
In August 2006, Apple re-licensed the cross-platform mDNSResponder
source code under the Apache License, Version 2.0.
In addition to desktop and laptop computers running Mac OS X and
Microsoft Windows, Multicast DNS is now implemented in a wide range
of hardware devices, such as Apple's "AirPort" wireless base
stations, iPhone and iPad, and in home gateways from other vendors,
network printers, network cameras, TiVo DVRs, etc.
The Open Source community has produced many independent
implementations of Multicast DNS, some in C like Apple's
mDNSResponder daemon, and others in a variety of different languages
including Java, Python, Perl, and C#/Mono.
In January 2007, the IETF published the Informational RFC "Link-Local
Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially
similar to Multicast DNS, but incompatible in some small but
important ways. In particular, the LLMNR design explicitly excluded
support for service discovery, which made it an unsuitable candidate
for a protocol to replace AppleTalk NBP [RFC6760].
While the original focus of Multicast DNS and DNS-Based Service
Discovery was for zero-configuration environments without a
conventional Unicast DNS server, DNS-Based Service Discovery also
works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007]
to create service discovery records and standard DNS queries to query
for them. Apple's Back to My Mac service, launched with Mac OS X
10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over
Unicast DNS [RFC6281].
In June 2012, Google's Android operating system added native support
for DNS-SD and Multicast DNS with the android.net.nsd.NsdManager
class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].
1 Infinite Loop
Cupertino, CA 95014
Phone: +1 408 974 3207
1 Infinite Loop
Cupertino, CA 95014
Phone: +1 408 974 4368