RFC 6763

This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6763.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.

This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values.

This document specifies that a particular service instance can be described using a DNS SRV [RFC2782] and DNS TXT [RFC1035] record. The SRV record has a name of the form "<Instance>.<Service>.<Domain>" and gives the target host and port where the service instance can be reached. The DNS TXT record of the same name gives additional information about this instance, in a structured form using key/value pairs, described in Section 6. A client discovers the list of available instances of a given service type using a query for a DNS PTR [RFC1035] record with a name of the form "<Service>.<Domain>", which returns a set of zero or more names, which are the names of the aforementioned DNS SRV/TXT record pairs.

This specification is compatible with both Multicast DNS [RFC6762] and with today’s existing Unicast DNS server and client software.

When used with Multicast DNS, DNS-SD can provide zero-configuration operation — just connect a DNS-SD/mDNS device, and its services are advertised on the local link with no further user interaction [ZC].

When used with conventional Unicast DNS, some configuration will usually be required — such as configuring the device with the DNS domain(s) in which it should advertise its services, and configuring it with the DNS Update [RFC2136] [RFC3007] keys to give it permission to do so. In rare cases, such as a secure corporate network behind a firewall where no DNS Update keys are required, zero-configuration operation may be achieved by simply having the device register its services in a default registration domain learned from the network (see Section 11, "Discovery of Browsing and Registration Domains"), but this is the exception and usually security credentials will be required to perform DNS updates.

Note that when using DNS-SD with Unicast DNS, the Unicast DNS-SD service does NOT have to be provided by the same DNS server hardware that is currently providing an organization’s conventional host name lookup service. While many people think of "DNS" exclusively in the context of mapping host names to IP addresses, in fact, "the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose" [RFC2181]. By delegating the "_tcp" and "_udp" subdomains, all the workload related to DNS-SD can be offloaded to a different machine. This flexibility, to handle DNS-SD on the main DNS server or not, at the network administrator’s discretion, is one of the benefits of using DNS.

Even when the DNS-SD functions are delegated to a different machine, the benefits of using DNS remain: it is mature technology, well understood, with multiple independent implementations from different vendors, a wide selection of books published on the subject, and an established workforce experienced in its operation. In contrast, adopting some other service discovery technology would require every site in the world to install, learn, configure, operate, and maintain some entirely new and unfamiliar server software. Faced with these obstacles, it seems unlikely that any other service discovery technology could hope to compete with the ubiquitous deployment that DNS already enjoys. For further discussion, see Appendix A, "Rationale for Using DNS as a Basis for Service Discovery".

This document is written for two audiences: for developers creating application software that offers or accesses services on the network, and for developers creating DNS-SD libraries to implement the advertising and discovery mechanisms. For both audiences, understanding the entire document is helpful. For developers creating application software, this document provides guidance on choosing instance names, service names, and other aspects that play a role in creating a good overall user experience. However, also understanding the underlying DNS mechanisms used to provide the service discovery facilities helps application developers understand the capabilities and limitations of those underlying mechanisms (e.g., name length limits). For library developers writing software to construct the DNS records (to advertise a service) and generate the DNS queries (to discover and use a service), understanding the ultimate user-experience goals helps them provide APIs that can meet those goals.

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" [RFC2119].

Of the many properties a good service discovery protocol needs to have, three of particular importance are:

In addition, if it is to become successful, a service discovery protocol should be so simple to implement that virtually any device capable of implementing IP should not have any trouble implementing the service discovery software as well.

These goals are discussed in more detail in the remainder of this document. A more thorough treatment of service discovery requirements may be found in "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)" [RFC6760]. That document draws upon examples from two decades of operational experience with AppleTalk to develop a list of universal requirements that are broadly applicable to any potential service discovery protocol.

Traditional DNS SRV records [RFC2782] are useful for locating instances of a particular type of service when all the instances are effectively indistinguishable and provide the same service to the client.

For example, SRV records with the (hypothetical) name "_http._tcp.example.com." would allow a client to discover servers implementing the "_http._tcp" service (i.e., web servers) for the "example.com." domain. The unstated assumption is that all these servers offer an identical set of web pages, and it doesn’t matter to the client which of the servers it uses, as long as it selects one at random according to the weight and priority rules laid out in the DNS SRV specification [RFC2782].

Instances of other kinds of service are less easily interchangeable. If a word processing application were to look up the (hypothetical) SRV record "_ipp._tcp.example.com." to find the list of Internet Printing Protocol (IPP) [RFC2910] printers at Example Co., then picking one at random and printing on it would probably not be what the user wanted.

The remainder of this section describes how SRV records may be used in a slightly different way, to allow a user to discover the names of all available instances of a given type of service, and then select, from that list, the particular instance they desire.

When a client needs to contact a particular service, identified by a Service Instance Name, previously discovered via Service Instance Enumeration (browsing), it queries for the SRV and TXT records of that name. The SRV record for a service gives the port number and target host name where the service may be found. The TXT record gives additional information about the service, as described in Section 6, "Data Syntax for DNS-SD TXT Records".

SRV records are extremely useful because they remove the need for preassigned port numbers. There are only 65535 TCP port numbers available. These port numbers are traditionally allocated one per application protocol [RFC6335]. Some protocols like the X Window System have a block of 64 TCP ports allocated (6000-6063). Using a different TCP port for each different instance of a given service on a given machine is entirely sensible, but allocating each application its own large static range, as was done for the X Window System, is not a practical way to do that. On any given host, most TCP ports are reserved for services that will never run on that particular host in its lifetime. This is very poor utilization of the limited port space. Using SRV records allows each host to allocate its available port numbers dynamically to those services actually running on that host that need them, and then advertise the allocated port numbers via SRV records. Allocating the available listening port numbers locally on a per-host basis as needed allows much better utilization of the available port space than today’s centralized global allocation.

In the event that more than one SRV is returned, clients MUST correctly interpret the priority and weight fields — i.e., lower- numbered priority servers should be used in preference to higher- numbered priority servers, and servers with equal priority should be selected randomly in proportion to their relative weights. However, in the overwhelmingly common case, a single advertised DNS-SD service instance is described by exactly one SRV record, and in this common case the priority and weight fields of the SRV record SHOULD both be set to zero.

Some services discovered via Service Instance Enumeration may need more than just an IP address and port number to completely identify the service instance. For example, printing via the old Unix LPR (port 515) protocol [RFC1179] often specifies a queue name [BJP]. This queue name is typically short and cryptic, and need not be shown to the user. It should be regarded the same way as the IP address and port number: it is another component of the addressing information required to identify a specific instance of a service being offered by some piece of hardware. Similarly, a file server may have multiple volumes, each identified by its own volume name. A web server typically has multiple pages, each identified by its own URL. In these cases, the necessary additional data is stored in a TXT record with the same name as the SRV record. The specific nature of that additional data, and how it is to be used, is service- dependent, but the overall syntax of the data in the TXT record is standardized, as described below.

Every DNS-SD service MUST have a TXT record in addition to its SRV record, with the same name, even if the service has no additional data to store and the TXT record contains no more than a single zero byte. This allows a service to have explicit control over the Time to Live (TTL) of its (empty) TXT record, rather than using the default negative caching TTL, which would otherwise be used for a "no error no answer" DNS response.

Note that this requirement for a mandatory TXT record applies exclusively to DNS-SD service advertising, i.e., services advertised using the PTR+SRV+TXT convention specified in this document. It is not a requirement of SRV records in general. The DNS SRV record datatype [RFC2782] may still be used in other contexts without any requirement for accompanying PTR and TXT records.

The <Service> portion of a Service Instance Name consists of a pair of DNS labels, following the convention already established for SRV records [RFC2782].

The first label of the pair is an underscore character followed by the Service Name [RFC6335]. The Service Name identifies what the service does and what application protocol it uses to do it.

For applications using TCP, the second label is "_tcp".

For applications using any transport protocol other than TCP, the second label is "_udp". This applies to all other transport protocols, including User Datagram Protocol (UDP), Stream Control Transmission Protocol (SCTP) [RFC4960], Datagram Congestion Control Protocol (DCCP) [RFC4340], Adobe’s Real Time Media Flow Protocol (RTMFP), etc. In retrospect, perhaps the SRV specification should not have used the "_tcp" and "_udp" labels at all, and instead should have used a single label "_srv" to carve off a subdomain of DNS namespace for this use, but that specification is already published and deployed. At this point there is no benefit in changing established practice. While "_srv" might be aesthetically nicer than "_udp", it is not a user-visible string, and all that is required protocol-wise is (i) that it be a label that can form a DNS delegation point, and (ii) that it be short so that it does not take up too much space in the packet, and in this respect either "_udp" or "_srv" is equally good. Thus, it makes sense to use "_tcp" for TCP- based services and "_udp" for all other transport protocols — which are in fact, in today’s world, often encapsulated over UDP — rather than defining a new subdomain for every new transport protocol.

Note that this usage of the "_udp" label for all protocols other than TCP applies exclusively to DNS-SD service advertising, i.e., services advertised using the PTR+SRV+TXT convention specified in this document. It is not a requirement of SRV records in general. Other specifications that are independent of DNS-SD and not intended to interoperate with DNS-SD records are not in any way constrained by how DNS-SD works just because they also use the DNS SRV record datatype [RFC2782]; they are free to specify their own naming conventions as appropriate.

The rules for Service Names [RFC6335] state that they may be no more than fifteen characters long (not counting the mandatory underscore), consisting of only letters, digits, and hyphens, must begin and end with a letter or digit, must not contain consecutive hyphens, and must contain at least one letter. The requirement to contain at least one letter is to disallow Service Names such as "80" or "6000-6063", which could be misinterpreted as port numbers or port number ranges. While both uppercase and lowercase letters may be used for mnemonic clarity, case is ignored for comparison purposes, so the strings "HTTP" and "http" refer to the same service.

Wise selection of a Service Name is important, and the choice is not always as obvious as it may appear.

In many cases, the Service Name merely names and refers to the on- the-wire message format and semantics being used. FTP is "ftp", IPP printing is "ipp", and so on.

However, it is common to "borrow" an existing protocol and repurpose it for a new task. This is entirely sensible and sound engineering practice, but that doesn’t mean that the new protocol is providing the same semantic service as the old one, even if it borrows the same message formats. For example, the network music sharing protocol implemented by iTunes on Macintosh and Windows is built upon "HTTP GET" commands. However, that does not mean that it is sensible or useful to try to access one of these music servers by connecting to it with a standard web browser. Consequently, the DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp" (Digital Audio Access Protocol), not "_http._tcp".

If iTunes were to advertise that it offered "_http._tcp" service, that would cause iTunes servers to appear in conventional web browsers (Safari, Camino, OmniWeb, Internet Explorer, Firefox, Chrome, etc.), which is of little use since an iTunes music library offers no HTML pages containing human-readable content that a web browser could display.

Equally, if iTunes were to browse for "_http._tcp" service, that would cause it to discover generic web servers, such as the embedded web servers in devices like printers, which is of little use since printers generally don’t have much music to offer.

Analogously, Sun Microsystems’s Network File System (NFS) is built on top of Sun Microsystems’s Remote Procedure Call (Sun RPC) mechanism, but that doesn’t mean it makes sense for an NFS server to advertise that it provides "Sun RPC" service. Likewise, Microsoft’s Server Message Block (SMB) file service is built on top of Netbios running over IP, but that doesn’t mean it makes sense for an SMB file server to advertise that it provides "Netbios-over-IP" service. The DNS-SD name of a service needs to encapsulate both the "what" (semantics) and the "how" (protocol implementation) of the service, since knowledge of both is necessary for a client to use the service meaningfully. Merely advertising that a service was built on top of Sun RPC is no use if the client has no idea what the service does.

Another common question is whether the service type advertised by iTunes should be "_daap._http._tcp." This would also be incorrect. Similarly, a protocol designer implementing a network service that happens to use the Simple Object Access Protocol [SOAP] should not feel compelled to have "_soap" appear somewhere in the Service Name. Part of the confusion here is that the presence of "_tcp" or "_udp" in the <Service> portion of a Service Instance Name has led people to assume that the visible structure of the <Service> should reflect the private internal structure of how the protocol was implemented. This is not correct. All that is required is that the service be identified by some unique opaque Service Name. Making the Service Name be English text that is at least marginally descriptive of what the service does may be convenient, but it is by no means essential.

In some cases, there may be several network protocols available that all perform roughly the same logical function. For example, the printing world has the lineprinter (LPR) protocol [RFC1179] and the Internet Printing Protocol (IPP) [RFC2910], both of which cause printed sheets to be emitted from printers in much the same way. In addition, many printer vendors send their own proprietary page description language (PDL) data over a TCP connection to TCP port 9100, herein referred to generically as the "pdl-datastream" protocol. In an ideal world, we would have only one network printing protocol, and it would be sufficiently good that no one felt a compelling need to invent a different one. However, in practice, multiple legacy protocols do exist, and a service discovery protocol has to accommodate that.

Many printers implement all three printing protocols: LPR, IPP, and pdl-datastream. For the benefit of clients that may speak only one of those protocols, all three are advertised.

However, some clients may implement two, or all three of those printing protocols. When a client looks for all three service types on the network, it will find three distinct services — an LPR service, an IPP service, and a pdl-datastream service — all of which cause printed sheets to be emitted from the same physical printer.

In a case like this, where multiple protocols all perform effectively the same function, a client may browse for all the service types it supports and display all the discovered instance names in a single aggregated list. Where the same instance name is discovered more than once because that entity supports more than one service type (e.g. a single printer which implements multiple printing protocols) the duplicates should be suppressed and the name should appear only once in the list. When the user indicates their desire to print on a given named printer, the printing client is responsible for choosing which of the available protocols will best achieve the desired effect, without, for example, requiring the user to make a manual choice between LPR and IPP.

As described so far, this all works very well. However, consider the case of: some future printer that only supports IPP printing, and some other future printer that only supports pdl-datastream printing.

The namespaces for different service types are intentionally disjoint (it is acceptable and desirable to be able to have both a file server called "Sales Department" and a printer called "Sales Department"). However, it is not desirable, in the common case, to allow two different printers both to be called "Sales Department" merely because those two printers implement different printing protocols.

To help guard against this, when there are two or more network protocols that perform roughly the same logical function, one of the protocols is declared the "flagship" of the fleet of related protocols. Typically the flagship protocol is the oldest and/or best-known protocol of the set.

If a device does not implement the flagship protocol, then it instead creates a placeholder SRV record (priority=0, weight=0, port=0, target host = host name of device) with that name. If, when it attempts to create this SRV record, it finds that a record with the same name already exists, then it knows that this name is already taken by some other entity implementing at least one of the protocols from the fleet, and it must choose another. If no SRV record already exists, then the act of creating it stakes a claim to that name so that future devices in the same protocol fleet will detect a conflict when they try to use it.

Note: When used with Multicast DNS [RFC6762], the target host field of the placeholder SRV record MUST NOT be the empty root label. The SRV record needs to contain a real target host name in order for the Multicast DNS conflict detection rules to operate. If two different devices were to create placeholder SRV records both using a null target host name (just the root label), then the two SRV records would be seen to be in agreement, and no conflict would be detected.

By defining a common well-known flagship protocol for the class, future devices that may not even know about each other’s protocols establish a common ground where they can coordinate to verify uniqueness of names.

No PTR record is created advertising the presence of empty flagship SRV records, since they do not represent a real service being advertised, and hence are not (and should not be) discoverable via Service Instance Enumeration (browsing).

In general, a normal client is not interested in finding every service on the network, just the services that the client knows how to use.

However, for problem diagnosis and network management tools, it may be useful for network administrators to find the list of advertised service types on the network, even if those Service Names are just opaque identifiers and not particularly informative in isolation.

For this purpose, a special meta-query is defined. A DNS query for PTR records with the name "_services._dns-sd._udp.<Domain>" yields a set of PTR records, where the rdata of each PTR record is the two- label <Service> name, plus the same domain, e.g., "_http._tcp.<Domain>". Including the domain in the PTR rdata allows for slightly better name compression in Unicast DNS responses, but only the first two labels are relevant for the purposes of service type enumeration. These two-label service types can then be used to construct subsequent Service Instance Enumeration PTR queries, in this <Domain> or others, to discover instances of that service type.

How a service’s PTR, SRV, and TXT records make their way into the DNS is outside the scope of this document, but, for illustrative purposes, some examples are given here.

On some networks, the administrator might manually enter the records into the name server’s configuration file.

A network monitoring tool could output a standard zone file to be read into a conventional DNS server. For example, a tool that can find networked PostScript laser printers using AppleTalk NBP could find the list of printers, communicate with each one to find its IP address, PostScript version, installed options, etc., and then write out a DNS zone file describing those printers and their capabilities using DNS resource records. That information would then be available to IP-only clients that implement DNS-SD but not AppleTalk NBP.

A printer manager device that has knowledge of printers on the network through some other management protocol could also output a zone file or use DNS Update [RFC2136] [RFC3007].

Alternatively, a printer manager device could implement enough of the DNS protocol that it is able to answer DNS queries directly, and Example Co.'s main DNS server could delegate the "_ipp._tcp.example.com." subdomain to the printer manager device.

IP printers could use Dynamic DNS Update [RFC2136] [RFC3007] to automatically register their own PTR, SRV, and TXT records with the DNS server.

Zeroconf printers answer Multicast DNS queries on the local link for their own PTR, SRV, and TXT names ending with ".local." [RFC6762].

One of the motivations for DNS-based Service Discovery is to enable a visiting client (e.g., a Wi-Fi-equipped [IEEEW] laptop computer, tablet, or mobile telephone) arriving on a new network to discover what services are available on that network, without any manual configuration. The logic that discovering services without manual configuration is a good idea also dictates that discovering recommended registration and browsing domains without manual configuration is a similarly good idea.

This discovery is performed using DNS queries, using Unicast or Multicast DNS. Five special RR names are reserved for this purpose:

By performing PTR queries for these names, a client can learn, respectively:

These domains are purely advisory. The client or user is free to register services and/or browse in any domains. The purpose of these special queries is to allow software to create a user interface that displays a useful list of suggested choices to the user, from which the user may make an informed selection, or ignore the offered suggestions and manually enter their own choice.

The <domain> part of the Domain Enumeration query name may be "local." (meaning "perform the query using link-local multicast") or it may be learned through some other mechanism, such as the DHCP "Domain" option (option code 15) [RFC2132], the DHCP "Domain Search" option (option code 119) [RFC3397], or IPv6 Router Advertisement Options [RFC6106].

The <domain> part of the query name may also be derived a different way, from the host’s IP address. The host takes its IP address and calculates the logical AND of that address and its subnet mask, to derive the 'base' address of the subnet (the 'network address' of that subnet, or, equivalently, the IP address of the 'all-zero' host address on that subnet). It then constructs the conventional DNS "reverse mapping" name corresponding to that base address, and uses that as the <domain> part of the name for the queries described above. For example, if a host has the address 192.168.12.34, with the subnet mask 255.255.0.0, then the 'base' address of the subnet is 192.168.0.0, and to discover the recommended automatic browsing domain(s) for devices on this subnet, the host issues a DNS PTR query for the name "lb._dns-sd._udp.0.0.168.192.in-addr.arpa."

Equivalent address-derived Domain Enumeration queries should also be done for the host’s IPv6 address(es).

Address-derived Domain Enumeration queries SHOULD NOT be done for IPv4 link-local addresses [RFC3927] or IPv6 link-local addresses [RFC4862].

Sophisticated clients may perform Domain Enumeration queries both in "local." and in one or more unicast domains, using both name-derived and address-derived queries, and then present the user with an combined result, aggregating the information received from all sources.

DNS has an efficiency feature whereby a DNS server may place additional records in the additional section of the DNS message. These additional records are records that the client did not explicitly request, but the server has reasonable grounds to expect that the client might request them shortly, so including them can save the client from having to issue additional queries.

This section recommends which additional records SHOULD be generated to improve network efficiency, for both Unicast and Multicast DNS-SD responses.

Note that while servers SHOULD add these additional records for efficiency purposes, as with all DNS additional records, it is the client’s responsibility to determine whether or not to trust them.

Generally speaking, stub resolvers that talk to a single recursive name server for all their queries will trust all records they receive from that recursive name server (whom else would they ask?). Recursive name servers that talk to multiple authoritative name servers should verify that any records they receive from a given authoritative name server are "in bailiwick" for that server, and ignore them if not.

Clients MUST be capable of functioning correctly with DNS servers (and Multicast DNS Responders) that fail to generate these additional records automatically, by issuing subsequent queries for any further record(s) they require. The additional-record generation rules in this section are RECOMMENDED for improving network efficiency, but are not required for correctness.

The following examples were prepared using standard unmodified nslookup and standard unmodified BIND running on GNU/Linux.

Note: In real products, this information is obtained and presented to the user using graphical network browser software, not command-line tools. However, if you wish, you can try these examples for yourself as you read along, using the nslookup command already available on most Unix machines.

IPv6 has only minor differences from IPv4.

The address of the SRV record’s target host is given by the appropriate IPv6 "AAAA" address records instead of (or in addition to) IPv4 "A" records.

Address-based Domain Enumeration queries are performed using names under the IPv6 reverse-mapping tree, which is different from the IPv4 reverse-mapping tree and has longer names in it.

Since DNS-SD is just a specification for how to name and use records in the existing DNS system, it has no specific additional security requirements over and above those that already apply to DNS queries and DNS updates.

For DNS queries, DNS Security Extensions (DNSSEC) [RFC4033] should be used where the authenticity of information is important.

For DNS updates, secure updates [RFC2136] [RFC3007] should generally be used to control which clients have permission to update DNS records.

IANA manages the namespace of unique Service Names [RFC6335].

When a protocol service advertising specification includes subtypes, these should be documented in the protocol specification in question and/or in the "notes" field of the registration request sent to IANA. In the event that a new subtype becomes relevant after a protocol specification has been published, this can be recorded by requesting that IANA add it to the "notes" field. For example, vendors of network printers advertise their embedded web servers using the subtype _printer. This allows printer management clients to browse for only printer-related web servers by browsing for the _printer subtype. While the existence of the _printer subtype of _http._tcp is not directly relevant to the HTTP protocol specification, it is useful to record this usage in the IANA registry to help avoid another community of developers inadvertently using the same subtype string for a different purpose. The namespace of possible subtypes is separate for each different service type. For example, the existence of the _printer subtype of _http._tcp does not imply that the _printer subtype is defined or has any meaning for any other service type.

When IANA records a Service Name registration, if the new application protocol is one that conceptually duplicates existing functionality of an older protocol, and the implementers desire the Flagship Naming behavior described in Section 8, then the registrant should request that IANA record the name of the flagship protocol in the "notes" field of the new registration. For example, the registrations for "ipp" and "pdl-datastream" both reference "printer" as the flagship name for this family of printing-related protocols.

The concepts described in this document have been explored, developed, and implemented with help from Ran Atkinson, Richard Brown, Freek Dijkstra, Ralph Droms, Erik Guttman, Pasi Sarolahti, Pekka Savola, Mark Townsley, Paul Vixie, Bill Woodcock, and others. Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, Rory McGuire, Roger Pantos, and Kiren Sekar for their significant contributions.

Over the years, there have been many proposed ways to do network service discovery with IP, but none achieved ubiquity in the marketplace. Certainly none has achieved anything close to the ubiquity of today’s deployment of DNS servers, clients, and other infrastructure.

The advantage of using DNS as the basis for service discovery is that it makes use of those existing servers, clients, protocols, infrastructure, and expertise. Existing network analyzer tools already know how to decode and display DNS packets for network debugging.

For ad hoc networks such as Zeroconf environments, peer-to-peer multicast protocols are appropriate. Using DNS-SD running over Multicast DNS [RFC6762] provides zero-configuration ad hoc service discovery, while maintaining the DNS-SD semantics and record types described here.

In larger networks, a high volume of enterprise-wide IP multicast traffic may not be desirable, so any credible service discovery protocol intended for larger networks has to provide some facility to aggregate registrations and lookups at a central server (or servers) instead of working exclusively using multicast. This requires some service discovery aggregation server software to be written, debugged, deployed, and maintained. This also requires some service discovery registration protocol to be implemented and deployed for clients to register with the central aggregation server. Virtually every company with an IP network already runs a DNS server, and DNS already has a dynamic registration protocol [RFC2136] [RFC3007]. Given that virtually every company already has to operate and maintain a DNS server anyway, it makes sense to take advantage of this expertise instead of also having to learn, operate, and maintain a different service registration server. It should be stressed again that using the same software and protocols doesn’t necessarily mean using the same physical piece of hardware. The DNS-SD service discovery functions do not have to be provided by the same piece of hardware that is currently providing the company’s DNS name service. The "_tcp.<Domain>" and "_udp.<Domain>" subdomains may be delegated to a different piece of hardware. However, even when the DNS-SD service is being provided by a different piece of hardware, it is still the same familiar DNS server software, with the same configuration file syntax, the same log file format, and so forth.

Service discovery needs to be able to provide appropriate security. DNS already has existing mechanisms for security [RFC4033].

In summary:

It makes more sense to use the existing software that every network needs already, instead of deploying an entire parallel system just for service discovery.

There have been questions about why services are named using DNS Service Instance Names of the form:

instead of:

There are three reasons why it is beneficial to name service instances with the parent domain as the most-significant (rightmost) part of the name, then the abstract service type as the next-most significant, and then the specific instance name as the least- significant (leftmost) part of the name. These reasons are discussed below in Sections B.1, B.2, and B.3.

Some service discovery protocols decouple the true service identifier from the name presented to the user. The true service identifier used by the protocol is an opaque unique identifier, often represented using a long string of hexadecimal digits, which should never be seen by the typical user. The name presented to the user is merely one of the decorative ephemeral attributes attached to this opaque identifier.

The problem with this approach is that it decouples user perception from network reality:

Solving these problems requires the user or administrator to be aware of the supposedly hidden unique identifier, and to set its value correctly as hardware is moved around, repurposed, or replaced, thereby contradicting the notion that it is a hidden identifier that human users never need to deal with. Requiring the user to understand this expert behind-the-scenes knowledge of what is really going on is just one more burden placed on the user when they are trying to diagnose why their computers and network devices are not working as expected.

These anomalies and counterintuitive behaviors can be eliminated by maintaining a tight bidirectional one-to-one mapping between what the user sees on the screen and what is really happening "behind the curtain". If something is configured incorrectly, then that is apparent in the familiar day-to-day user interface that everyone understands, not in some little-known, rarely used "expert" interface.

In summary: in DNS-SD the user-visible name is also the primary identifier for a service. If the user-visible name is changed, then conceptually the service being offered is a different logical service — even though the hardware offering the service may have stayed the same. If the user-visible name doesn’t change, then conceptually the service being offered is the same logical service — even if the hardware offering the service is new hardware brought in to replace some old equipment.

There are certainly arguments on both sides of this debate. Nonetheless, the designers of any service discovery protocol have to make a choice between having the primary identifiers be hidden, or having them be visible, and these are the reasons that we chose to make them visible. We’re not claiming that there are no disadvantages of having primary identifiers be visible. We considered both alternatives, and we believe that the few disadvantages of visible identifiers are far outweighed by the many problems caused by use of hidden identifiers.

When a DNS-SD service is advertised using Multicast DNS [RFC6762], if there is already another service of the same type advertising with the same name then automatic name conflict resolution will occur. As described in the Multicast DNS specification [RFC6762], upon detecting a conflict, the service should:

This renaming behavior is very important, because it is key to providing user-friendly instance names in the out-of-the-box factory- default configuration. Some product developers apparently have not realized this, because there are some products today where the factory-default name is distinctly unfriendly, containing random- looking strings of characters, such as the device’s Ethernet address in hexadecimal. This is unnecessary and undesirable, because the point of the user-visible name is that it should be friendly and meaningful to human users. If the name is not unique on the local network then the protocol will remedy this as necessary. It is ironic that many of the devices with this design mistake are network printers, given that these same printers also simultaneously support AppleTalk-over-Ethernet, with nice user-friendly default names (and automatic conflict detection and renaming). Some examples of good factory-default names are:

To make the case for why adding long, ugly factory-unique serial numbers to the end of names is neither necessary nor desirable, consider the cases where the user has (a) only one network printer, (b) two network printers, and (c) many network printers.

Although the original DNS specifications [RFC1033] [RFC1034] [RFC1035] recommend that host names contain only letters, digits, and hyphens (because of the limitations of the typing-based user interfaces of that era), Service Instance Names are not host names. Users generally access a service by selecting it from a list presented by a user interface, not by typing in its Service Instance Name. "Clarifications to the DNS Specification" [RFC2181] directly discusses the subject of allowable character set in Section 11 ("Name syntax"), and explicitly states that the traditional letters-digits- hyphens rule applies only to conventional host names:

Note that just because DNS-based Service Discovery supports arbitrary UTF-8-encoded names doesn’t mean that any particular user or administrator is obliged to make use of that capability. Any user is free, if they wish, to continue naming their services using only letters, digits, and hyphens, with no spaces, capital letters, or other punctuation.

Of particular concern in the design of DNS-SD, especially when used in conjunction with ad hoc Multicast DNS, is the dynamic nature of service discovery in a changing network environment. Other service discovery protocols seem to have been designed with an implicit unstated assumption that the usage model is:

Superficially this usage model seems reasonable, but the problem is that it’s too optimistic. It only considers the success case, where the software immediately finds the service instance the user is looking for.

In the case where the user is looking for (say) a particular printer, and that printer is not turned on or not connected, the user first has to attempt to remedy the problem, and then has to click a "refresh" button to retry the service discovery to find out whether they were successful. Because nothing happens instantaneously in networking, and packets can be lost, necessitating some number of retransmissions, a service discovery search is not instantaneous and typically takes a few seconds. As a result, a fairly typical user experience is:

Every time the user clicks the "refresh" button they have to endure another ten-second wait, and every time the discovered list is finally shown at the end of the ten-second wait, it’s already beginning to get stale and out-of-date the moment it’s displayed on the screen.

The service discovery user experience that the DNS-SD designers had in mind has some rather different properties:

In July 1997, in an email to the net-thinkers@thumper.vmeng.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 224.0.0.251 with IANA 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-Drafts:

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 224.0.0.251: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].