Document: draft-cheshire-dnsext-dns-sd-07.txt Stuart Cheshire
Internet-Draft Marc Krochmal
Category: Standards Track Apple Inc.
Expires: 25 April 2011 25 October 2010
DNS-Based Service Discovery
<draft-cheshire-dnsext-dns-sd-07.txt>
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on 8th September 2010.
Abstract
This document describes a convention for naming and structuring DNS
resource records. Given a type of service that a client is looking
for, and a domain in which the client is looking for that service,
this convention allows clients to discover a list of named instances
of that desired service, using standard DNS queries. In short, this
is referred to as DNS-based Service Discovery, or DNS-SD.
Expires 25th April 2011 Cheshire & Krochmal [Page 1]
Internet Draft DNS-Based Service Discovery 25th October 2010
Table of Contents
1. Introduction...................................................3
2. Conventions and Terminology Used in this Document..............4
3. Design Goals...................................................4
4. Service Instance Enumeration (Browsing)........................5
4.1 Structured Instance Names......................................5
4.2 User Interface Presentation....................................8
4.3 Internal Handling of Names.....................................8
4.4 What You See Is What You Get...................................9
5. Service Name Resolution.......................................10
6. Data Syntax for DNS-SD TXT Records............................11
6.1 General Format Rules for DNS TXT Records......................12
6.2 DNS-SD TXT Record Size........................................12
6.3 DNS TXT Record Format Rules for use in DNS-SD.................13
6.4 Rules for Names in DNS-SD Name/Value Pairs....................14
6.5 Rules for Values in DNS-SD Name/Value Pairs...................16
6.6 Example TXT Record............................................17
6.7 Version Tag...................................................17
7. Application Protocol Names....................................18
7.1 Selective Instance Enumeration (Subtypes).....................19
7.2 Service Name Length Limits....................................21
8. Flagship Naming...............................................23
9. Service Type Enumeration......................................24
10. Populating the DNS with Information...........................25
11. Relationship to Multicast DNS.................................25
12. Discovery of Browsing and Registration Domains................25
13. DNS Additional Record Generation..............................27
14. Working Examples..............................................28
15. User Interface Considerations.................................29
15.1 Service Advertising User-Interface Considerations.............29
15.2 Client Browsing User-Interface Considerations.................31
16. IPv6 Considerations...........................................33
17. Security Considerations.......................................33
18. IANA Considerations...........................................33
19. Acknowledgments...............................................34
20. Copyright Notice..............................................34
21. Normative References..........................................35
22. Informative References........................................35
Appendix A. Ordering of Service Instance Name Components..........36
Appendix B. Comparison with Alternative Service Disc. Protocols...38
Appendix C. Deployment History....................................39
Authors' Addresses.................................................40
Expires 25th April 2011 Cheshire & Krochmal [Page 2]
Internet Draft DNS-Based Service Discovery 25th October 2010
1. Introduction
This document describes a convention for naming and structuring DNS
resource records. Given a type of service that a client is looking
for, and a domain in which the client is looking for that service,
this convention allows clients to discover a list of named instances
of that desired service, using standard DNS queries. In short, this
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 simply specifies
a convention for how existing resource record types can be named and
structured to facilitate service discovery.
This document specifies that a particular service instance can be
described using a DNS SRV [RFC 2782] and DNS TXT [RFC 1035] 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 [RFC 1035] record with a name of the form
"<Service>.<Domain>", which returns a list 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 [mDNS] and
with today's existing unicast DNS server and client software.
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. When many people use the term "DNS" they are thinking
exclusively of mapping host names to IP addresses, but in fact, "the
DNS is a general (if somewhat limited) hierarchical database, and can
store almost any kind of data, for almost any purpose." [RFC 2181]
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
Expires 25th April 2011 Cheshire & Krochmal [Page 3]
Internet Draft DNS-Based Service Discovery 25th October 2010
obstacles, it seems unlikely that any other service discovery
technology could hope to compete with the ubiquitous deployment
that DNS already enjoys.
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].
3. Design Goals
Of the many properties a good service discovery protocol needs to
have, three in particular are:
(i) The ability to query for services of a certain type in a certain
logical domain, and receive in response a list of named instances
(network browsing, or "Service Instance Enumeration").
(ii) Given a particular named instance, the ability to efficiently
resolve that instance name to the required information a client needs
to actually use the service, i.e. IP address and port number, at the
very least (Service Name Resolution).
(iii) Instance names should be relatively persistent. If a user
selects their default printer from a list of available choices today,
then tomorrow they should still be able to print on that printer --
even if the IP address and/or port number where the service resides
have changed -- without the user (or their software) having to repeat
the network browsing step a second time.
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 AppleTalk
NBP" [NBP]. That document draws upon examples from two decades of
operational experience with AppleTalk Name Binding Protocol to
develop a list of universal requirements that are broadly applicable
to any potential service discovery protocol.
Expires 25th April 2011 Cheshire & Krochmal [Page 4]
Internet Draft DNS-Based Service Discovery 25th October 2010
4. Service Instance Enumeration (Browsing)
Traditional DNS SRV records [RFC 2782] 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 a list of
all 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 [RFC 2782].
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 IPP 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, to allow the user
to select the particular instance they desire.
4.1 Structured Instance Names
This document borrows the logical service naming syntax and semantics
from DNS SRV records, but adds one level of indirection. Instead of
requesting records of type "SRV" with name "_ipp._tcp.example.com.",
the client requests records of type "PTR" (pointer from one name to
another in the DNS namespace).
In effect, if one thinks of the domain name "_ipp._tcp.example.com."
as being analogous to an absolute path to a directory in a file
system, then DNS-SD's PTR lookup is akin to performing a listing of
that directory to find all the files it contains. (Remember that
domain names are expressed in reverse order compared to path names:
An absolute path name is read from left to right, beginning with a
leading slash on the left, and then the top level directory, then the
next level directory, and so on. A fully-qualified domain name is
read from right to left, beginning with the dot on the right -- the
root label -- and then the top level domain to the left of that, and
the second level domain to the left of that, and so on. If the fully-
qualified domain name "_ipp._tcp.example.com." were expressed as a
file system path name, it would be "/com/example/_tcp/_ipp".)
Expires 25th April 2011 Cheshire & Krochmal [Page 5]
Internet Draft DNS-Based Service Discovery 25th October 2010
The result of this PTR lookup for the name "<Service>.<Domain>" is a
list of zero or more PTR records giving Service Instance Names of the
form:
Service Instance Name = <Instance> . <Service> . <Domain>
The <Instance> portion of the Service Instance Name is a single DNS
label, containing arbitrary precomposed (Unicode Normalization Form C
[UAX15]) UTF-8-encoded text [RFC 3629]. It is a user-friendly name.
It MUST NOT contain ASCII control characters (byte values 0x00 -
0x1F) but otherwise is allowed to contain any characters, without
restriction, including spaces, upper case, lower case, punctuation --
including dots -- accented characters, non-roman text, and anything
else that may be represented using UTF-8. Although the original DNS
specifications [RFC 1033][RFC 1034][RFC 1035] recommended 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. Service Instance Names are not
intended to ever be typed in by a user accessing a service; the user
accesses a service by selecting its name from a list of choices
presented on the screen. "Clarifications to the DNS Specification"
[RFC 2181] directly discusses the subject of allowable character set
in Section 11 ("Name syntax"), and explicitly states that the
traditional letters-digits-hyphens rule only applies to conventional
host names:
Occasionally it is assumed that the Domain Name System serves only
the purpose of mapping Internet host names to data, and mapping
Internet addresses to host names. This is not correct, the DNS is
a general (if somewhat limited) hierarchical database, and can
store almost any kind of data, for almost any purpose.
The DNS itself places only one restriction on the particular
labels that can be used to identify resource records. That one
restriction relates to the length of the label and the full name.
The length of any one label is limited to between 1 and 63 octets.
A full domain name is limited to 255 octets (including the
separators). The zero length full name is defined as representing
the root of the DNS tree, and is typically written and displayed
as ".". Those restrictions aside, any binary string whatever can
be used as the label of any resource record. Similarly, any
binary string can serve as the value of any record that includes a
domain name as some or all of its value (SOA, NS, MX, PTR, CNAME,
and any others that may be added). Implementations of the DNS
protocols must not place any restrictions on the labels that can
be used. In particular, DNS servers must not refuse to serve a
zone because it contains labels that might not be acceptable to
some DNS client programs.
Note that just because this protocol supports arbitrary UTF-8-encoded
names doesn't mean that any particular user or administrator is
Expires 25th April 2011 Cheshire & Krochmal [Page 6]
Internet Draft DNS-Based Service Discovery 25th October 2010
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.
DNS labels are currently limited to 63 octets in length. UTF-8
encoding can require up to four octets per Unicode character, which
means that in the worst case, the <Instance> portion of a name could
be limited to fifteen Unicode characters. However, the Unicode
characters with longer UTF-8 encodings tend to be the more rarely-
used ones, and tend to be the ones that convey greater meaning per
character.
Note that any character in the commonly-used 16-bit Unicode space
can be encoded with no more than three octets of UTF-8 encoding. This
means that an Instance name can contain up to 21 Kanji characters,
which is a sufficiently expressive name for most purposes.
The <Service> portion of the Service Instance Name consists of a pair
of DNS labels, following the convention already established for
SRV records [RFC 2782], namely: the first label of the pair is the
Application Protocol Name, and the second label is either "_tcp" or
"_udp", depending on the transport protocol used by the application.
More details are given in Section 7, "Application Protocol Names".
The <Domain> portion of the Service Instance Name specifies the DNS
subdomain within which the service names are registered. It may be
"local.", meaning "link-local Multicast DNS" [mDNS], or it may be
a conventional unicast DNS domain name, such as "ietf.org.",
"cs.stanford.edu.", or "eng.us.ibm.com." Because service names are
not host names, they are not constrained by the usual rules for host
names [RFC 1033][RFC 1034][RFC 1035], and rich-text service
subdomains are allowed and encouraged, for example:
Building 2, 1st Floor . example . com .
Building 2, 2nd Floor . example . com .
Building 2, 3rd Floor . example . com .
Building 2, 4th Floor . example . com .
In addition, because Service Instance Names are not constrained by
the limitations of host names, this document recommends that they
be stored in the DNS, and communicated over the wire, encoded as
straightforward canonical precomposed UTF-8, Unicode Normalization
Form C [UAX15]. In cases where the DNS server returns a negative
response for the name in question, client software MAY choose to
retry the query using "Punycode" [RFC 3492] encoding, beginning with
using Punycode encoding for the top level label, and then issuing
the query repeatedly, with successively more labels converted to
Punycode each time, and giving up if it has converted all labels
to Punycode and the query still fails.
Expires 25th April 2011 Cheshire & Krochmal [Page 7]
Internet Draft DNS-Based Service Discovery 25th October 2010
4.2 User Interface Presentation
The names resulting from the PTR lookup are presented to the user in
a list for the user to select one (or more). Typically only the first
label is shown (the user-friendly <Instance> portion of the name). In
the common case, the <Service> and <Domain> are already known to the
client software, these having been provided implicitly by the user in
the first place, by the act of indicating the service being sought,
and the domain in which to look for it. Note: The software handling
the response should be careful not to make invalid assumptions
though, since it *is* possible, though rare, for a service
enumeration in one domain to return the names of services in a
different domain. Similarly, when using subtypes (see "Selective
Instance Enumeration") the <Service> of the discovered instance may
not be exactly the same as the <Service> that was requested.
Having chosen the desired named instance, the Service Instance
Name may then be used immediately, or saved away in some persistent
user-preference data structure for future use, depending on what is
appropriate for the application in question.
4.3 Internal Handling of Names
If the <Instance>, <Service> and <Domain> portions are internally
concatenated together into a single string, then care must be taken
with the <Instance> portion, since it is allowed to contain any
characters, including dots.
Any dots in the <Instance> portion should be escaped by preceding
them with a backslash ("." becomes "\."). Likewise, any backslashes
in the <Instance> portion should also be escaped by preceding them
with a backslash ("\" becomes "\\"). Having done this, the three
components of the name may be safely concatenated. The backslash-
escaping allows literal dots in the name (escaped) to be
distinguished from label-separator dots (not escaped).
The resulting concatenated string may be safely passed to standard
DNS APIs like res_query(), which will interpret the string correctly
provided it has been escaped correctly, as described here.
Expires 25th April 2011 Cheshire & Krochmal [Page 8]
Internet Draft DNS-Based Service Discovery 25th October 2010
4.4 What You See Is What You Get
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 id, often represented using a
long string of hexadecimal digits, and 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 reality:
* What happens if there are two service instances, with different
unique ids, but they have inadvertently been given the same
user-visible name? If two instances appear in an on-screen list
with the same name, how does the user know which is which?
* Suppose a printer breaks down, and the user replaces it with
another printer of the same make and model, and configures the
new printer with the exact same name as the one being replaced:
"Stuart's Printer". Now, when the user tries to print, the
on-screen print dialog tells them that their selected default
printer is "Stuart's Printer". When they browse the network to see
what is there, they see a printer called "Stuart's Printer", yet
when the user tries to print, they are told that the printer
"Stuart's Printer" can't be found. The hidden internal unique id
that the software is trying to find on the network doesn't match
the hidden internal unique id of the new printer, even though its
apparent "name" and its logical purpose for being there are the
same. To remedy this, the user typically has to delete the print
queue they have created, and then create a new (apparently
identical) queue for the new printer, so that the new queue will
contain the right hidden internal unique id. Having all this hidden
information that the user can't see makes for a confusing and
frustrating user experience, and exposing long ugly hexadecimal
strings to the user and forcing them to understand what they mean
is even worse.
* Suppose an existing printer is moved to a new department, and given
a new name and a new function. Changing the user-visible name of
that piece of hardware doesn't change its hidden internal unique
id. Users who had previously created print queues for that printer
will still be accessing the same hardware by its unique id, even
though the logical service that used to be offered by that hardware
has ceased to exist.
Expires 25th April 2011 Cheshire & Krochmal [Page 9]
Internet Draft DNS-Based Service Discovery 25th October 2010
To solve these problems requires the user or administrator to be
aware of the supposedly hidden unique id, 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 counter-intuitive 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 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.
5. Service Name Resolution
Given a particular Service Instance Name, previously discovered via
Service Instance Enumeration (browsing), when a client needs to
contact that service, it queries for the SRV and TXT records of that
name. The SRV record for a service gives the port number and target
host where the service may be found. The TXT record gives additional
information about the service, as described in Section 6 below, "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 being allocated one-per-
Expires 25th April 2011 Cheshire & Krochmal [Page 10]
Internet Draft DNS-Based Service Discovery 25th October 2010
application-protocol. 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 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 SHOULD
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.
6. Data Syntax for DNS-SD TXT Records
Some services discovered via Service Instance Enumeration may need
more than just an IP address and port number to properly identify the
service. For example, printing via the LPR protocol often specifies a
queue name. 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.
Expires 25th April 2011 Cheshire & Krochmal [Page 11]
Internet Draft DNS-Based Service Discovery 25th October 2010
6.1 General Format Rules for DNS TXT Records
A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total
length is indicated by the length given in the resource record header
in the DNS message. There is no way to tell directly from the data
alone how long it is (e.g. there is no length count at the start, or
terminating NULL byte at the end).
Note that when using Multicast DNS [mDNS] the maximum packet size is
9000 bytes, including IP header, UDP header, and DNS message header,
which imposes an upper limit on the size of TXT records of about 8900
bytes. In practice the sensible maximum size of a DNS-SD TXT record
size is smaller even than this, typically at most a few hundred
bytes, as described below in Section 6.2.
The format of the data within a DNS TXT record is one or more
strings, packed together in memory without any intervening gaps
or padding bytes for word alignment.
The format of each constituent string within the DNS TXT record is a
single length byte, followed by 0-255 bytes of text data.
These format rules are defined in Section 3.3.14 of RFC 1035, and are
not specific to DNS-SD. DNS-SD simply specifies a usage convention
for what data should be stored in those constituent strings.
An empty TXT record containing zero strings is disallowed by RFC
1035. DNS-SD implementations MUST NOT emit empty TXT records.
DNS-SD implementations receiving empty TXT records MUST treat them
as equivalent to a one-byte TXT record containing a single zero byte
(i.e. a single empty string).
6.2 DNS-SD TXT Record Size
The total size of a typical DNS-SD TXT record is intended to be small
-- 200 bytes or less.
In cases where more data is justified (e.g. LPR printing), keeping
the total size under 400 bytes should allow it to fit in a single
standard 512-byte DNS message. (This standard DNS message size is
defined in RFC 1035.)
In extreme cases where even this is not enough, keeping the size of
the TXT record under 1300 bytes should allow it to fit in a single
1500-byte Ethernet packet.
Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this
time.
Expires 25th April 2011 Cheshire & Krochmal [Page 12]
Internet Draft DNS-Based Service Discovery 25th October 2010
Note that some Ethernet hardware vendors offer chipsets with
Multicast DNS [mDNS] offload, so that computers can sleep and still
be discoverable on the network. Early versions of such chipsets were
sometimes quite limited, and, for example, some were (unwisely)
limited to handling TXT records no larger than 256 bytes (which meant
that LPR printer services did not work, since they often have TXT
records 400-600 bytes long). Developers should be aware of this
real-world limitation, and should understand that even on hardware
which is otherwise perfectly capable, it may have low-power and sleep
modes that are more limited.
6.3 DNS TXT Record Format Rules for use in DNS-SD
DNS-SD uses DNS TXT records to store arbitrary key/value pairs
conveying additional information about the named service. Each
key/value pair is encoded as its own constituent string within the
DNS TXT record, in the form "key=value" (without the quotation
marks). Everything up to the first '=' character is the key (Section
6.4). Everything after the first '=' character to the end of the
string (including subsequent '=' characters, if any) is the value.
No quotation marks are required around the value, even if it contains
spaces, '=' characters, or other punctuation marks (see Section 6.5).
Each author defining a DNS-SD profile for discovering instances of a
particular type of service should define the base set of key/value
attributes that are valid for that type of service.
Using this standardized key/value syntax within the TXT record makes
it easier for these base definitions to be expanded later by defining
additional named attributes. If an implementation sees unknown
keys in a service TXT record, it MUST silently ignore them.
The target host name and TCP (or UDP) port number of the service are
given in the SRV record. This information -- target host name and
port number -- MUST NOT be duplicated using key/value attributes
in the TXT record.
The intention of DNS-SD TXT records is to convey a small amount of
useful additional information about a service. Ideally it SHOULD NOT
be necessary for a client to retrieve this additional information
before it can usefully establish a connection to the service. For a
well-designed TCP-based application protocol, it should be possible,
knowing only the host name and port number, to open a connection
to that listening process, and then perform version- or feature-
negotiation to determine the capabilities of the service instance.
For example, when connecting to an Apple Filing Protocol (AFP) [AFP]
server over TCP, the client enters into a protocol exchange with the
server to determine which version of AFP the server implements, and
which optional features or capabilities (if any) are available. For a
well-designed application protocol, clients should be able to connect
and use the service even if there is no information at all in the TXT
Expires 25th April 2011 Cheshire & Krochmal [Page 13]
Internet Draft DNS-Based Service Discovery 25th October 2010
record. In this case, the information in the TXT record should be
viewed as a performance optimization -- when a client discovers many
instances of a service, the TXT record allows the client to know some
rudimentary information about each instance without having to open
a TCP connection to each one and interrogate every service instance
separately. Care should be taken when doing this to ensure that the
information in the TXT record is in agreement with the information
that would be retrieved by a client connecting over TCP.
There are legacy protocols which provide no feature negotiation
capability, and in these cases it may be useful to convey necessary
information in the TXT record. For example, when printing using the
old Unix LPR (port 515) protocol, the LPR service provides no way
for the client to determine whether a particular printer accepts
PostScript, or what version of PostScript, etc. In this case it is
appropriate to embed this information in the TXT record, because the
alternative is worse -- passing around written instructions to the
users, arcane manual configuration of "/etc/printcap" files, etc.
6.4 Rules for Keys in DNS-SD Key/Value Pairs
The "Key" MUST be at least one character. Strings beginning with an
'=' character (i.e. the key is missing) SHOULD be silently ignored.
The "Key" SHOULD be no more than nine characters long. This is
because it is beneficial to keep packet sizes small for the sake of
network efficiency. When using DNS-SD in conjunction with Multicast
DNS [mDNS] this is important because on 802.11 wireless networks
multicast traffic is especially expensive [IEEE W], but even when
using conventional Unicast DNS, keeping the TXT records small helps
improve the chance that responses will fit within the standard DNS
512-byte size limit [RFC 1035]. Also, each constituent string of a
DNS TXT record is limited to 255 bytes, so excessively long keys
reduce the space available for that key's values.
The Keys in Key/Value Pairs can be as short as a single character.
A key name needs only to be unique and unambiguous within the context
of the service type for which it is defined. A key name is intended
solely to be a machine-readable identifier, not a human-readable
essay giving detailed discussion of the purpose of a parameter, with
a URL for a web page giving yet more details of the specification.
For ease of development and debugging it can be valuable to use key
names that are mnemonic textual names, but excessively verbose keys
are wasteful and inefficient, hence the recommendation to keep them
to nine characters or fewer.
The characters of "Key" MUST be printable US-ASCII values
(0x20-0x7E), excluding '=' (0x3D).
Expires 25th April 2011 Cheshire & Krochmal [Page 14]
Internet Draft DNS-Based Service Discovery 25th October 2010
Spaces in the key are significant, whether leading, trailing, or in
the middle -- so don't include any spaces unless you really intend
that.
Case is ignored when interpreting a key, so "papersize=A4",
"PAPERSIZE=A4" and "Papersize=A4" are all identical.
If there is no '=', then it is a boolean attribute, and is simply
identified as being present, with no value.
A given key may appear at most once in a TXT record. The reason for
this simplifying rule is to facilitate the creation of client
libraries that parse the TXT record into an internal data structure,
such as a hash table or dictionary object that maps from keys to
values, and then make that abstraction available to client code. The
rule that a given key may not appear more than once simplifies these
abstractions because they aren't required to support the case of
returning more than one value for a given key.
If a client receives a TXT record containing the same key more than
once, then the client MUST silently ignore all but the first
occurrence of that attribute. For client implementations that process
a DNS-SD TXT record from start to end, placing key/value pairs into a
hash table, using the key as the hash table key, this means that if
the implementation attempts to add a new key/value pair into the
table and finds an entry with the same key already present, then the
new entry being added should be silently discarded instead. For
client implementations that retrieve key/value pairs by searching the
TXT record for the requested key, they should search the TXT record
from the start, and simply return the first matching key they find.
When examining a TXT record for a given key, there are therefore four
categories of results which may be returned:
* Attribute not present (Absent)
* Attribute present, with no value
(e.g. "passreq" -- password required for this service)
* Attribute present, with empty value (e.g. "PlugIns=" --
server supports plugins, but none are presently installed)
* Attribute present, with non-empty value
(e.g. "PlugIns=JPEG,MPEG2,MPEG4")
Each author defining a DNS-SD profile for discovering instances of a
particular type of service should define the interpretation of these
different kinds of result. For example, for some keys, there may be
a natural true/false boolean interpretation:
* Absent implies 'false'
* Present implies 'true'
Expires 25th April 2011 Cheshire & Krochmal [Page 15]
Internet Draft DNS-Based Service Discovery 25th October 2010
For other keys it may be sensible to define other semantics, such as
value/no-value/unknown:
* Present with value implies that value.
E.g. "Color=4" for a four-color ink-jet printer,
or "Color=6" for a six-color ink-jet printer.
* Present with empty value implies 'false'. E.g. Not a color printer.
* Absent implies 'Unknown'. E.g. A print server connected to some
unknown printer where the print server doesn't actually know if the
printer does color or not (which gives a very bad user experience
and should be avoided wherever possible).
Note that this is a hypothetical example, not an example of actual
key/value keys used by DNS-SD network printers, which are documented
in the "Bonjour Printing Specification" [BJP].
6.5 Rules for Values in DNS-SD Key/Value Pairs
If there is an '=', then everything after the first '=' to the end
of the string is the value. The value can contain any eight-bit
values including '='. Leading or trailing spaces are part of the
value, so don't put them there unless you intend them to be there.
Any quotation marks around the value are part of the value, so don't
put them there unless you intend them to be part of the value.
The value is opaque binary data. Often the value for a particular
attribute will be US-ASCII (or UTF-8) text, but it is legal for a
value to be any binary data. For example, if the value of a key is an
IPv4 address, that address should simply be stored as four bytes of
binary data, not as a variable-length 7-15 byte ASCII string giving
the address represented in textual dotted decimal notation.
Generic debugging tools should generally display all attribute values
as a hex dump, with accompanying text alongside displaying the UTF-8
interpretation of those bytes, except for attributes where the
debugging tool has embedded knowledge that the value is some other
kind of data.
Authors defining DNS-SD profiles SHOULD NOT generically convert
binary attribute data types into printable text using hexadecimal
representation, Base-64 [RFC 4648] or UU encoding, merely for the
sake of making the data be printable text when seen in a generic
debugging tool. Doing this simply bloats the size of the TXT record,
without actually making the data any more understandable to someone
looking at it in a generic debugging tool.
Expires 25th April 2011 Cheshire & Krochmal [Page 16]
Internet Draft DNS-Based Service Discovery 25th October 2010
6.6 Example TXT Record
The TXT record below contains three syntactically valid key/value
pairs. (The meaning of these key/value pairs, if any, would depend
on the definitions pertaining to the service in question that is
using them.)
-------------------------------------------------------
| 0x09 | key=value | 0x08 | paper=A4 | 0x07 | passreq |
-------------------------------------------------------
6.7 Version Tag
It is recommended that authors defining DNS-SD profiles include an
attribute of the form "txtvers=xxx" in their definition, and require
it to be the first key/value pair in the TXT record. This
information in the TXT record can be useful to help clients maintain
backwards compatibility with older implementations if it becomes
necessary to change or update the specification over time. Even if
the profile author doesn't anticipate the need for any future
incompatible changes, having a version number in the TXT record
provides useful insurance should incompatible changes become
unavoidable. Clients SHOULD ignore TXT records with a txtvers number
higher (or lower) than the version(s) they know how to interpret.
Note that the version number in the txtvers tag describes the version
of the specification governing this TXT record, not the version of
the application protocol that will be used if the client subsequently
decides to contact that service. Ideally, every DNS-SD TXT record
specification starts at txtvers=1 and stays that way forever.
Improvements can be made by defining new keys that older clients
silently ignore. The only reason to increment the version number is
if the old specification is subsequently found to be so horribly
broken that there's no way to do a compatible forward revision, so
the txtvers number has to be incremented to tell all the old clients
they should just not even try to understand this new TXT record.
If there is a need to indicate which version number(s) of the
application protocol the service implements, the recommended key
for this is "protovers".
Expires 25th April 2011 Cheshire & Krochmal [Page 17]
Internet Draft DNS-Based Service Discovery 25th October 2010
7. Application Protocol Names
The <Service> portion of a Service Instance Name consists of a pair
of DNS labels, following the convention already established for
SRV records [RFC 2782], namely: the first label of the pair is an
underscore character followed by the Application Protocol Name, and
the second label is either "_tcp" or "_udp".
For applications using other transport protocols, such as SCTP, DCCP,
Adobe's RTMFP, etc., the second label of <Service> portion of its
DNS-SD name should be "_udp".
Application Protocol Names may be no more than fifteen characters
(not counting the mandatory underscore), conforming to normal DNS
host name rules: Only lower-case letters, digits, and hyphens; must
begin and end with lower-case letter or digit. In addition,
Application Protocol Names must contain at least one lower-case
letter. This is to prevent service names such as "80" or "6000-6063"
which could be misinterpreted as port numbers or port number ranges.
Wise selection of an Application Protocol Name is important, and the
choice is not always as obvious as it may appear.
In many cases, the Application Protocol 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 little more than
"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". Advertising
"_http._tcp" service would cause iTunes servers to show up in
conventional web browsers (Safari, Camino, OmniWeb, Internet
Explorer, Firefox, Chrome, etc.) which is of little use since it
offers no pages containing human-readable content. Similarly, if
iTunes were to browse for "_http._tcp" service, that would cause it
to find 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.
Similarly, NFS is built on top of SUN RPC, but that doesn't mean it
makes sense for an NFS server to advertise that it provides "SUN RPC"
service. Likewise, Microsoft SMB file service is built on top of
Netbios running over IP, but that doesn't mean it makes sense for
Expires 25th April 2011 Cheshire & Krochmal [Page 18]
Internet Draft DNS-Based Service Discovery 25th October 2010
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
usefully use the service. Merely advertising that a service was
built on top of SUN RPC is no use if the client has no idea what
the service actually does.
Another common question is to ask 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 Simple Object Access Protocol [SOAP] should not feel
compelled to have "_soap" appear somewhere in the Application
Protocol 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 a service name
has to 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 Application Protocol Name.
Making the Application Protocol Name be English text which is at
least marginally descriptive of what the service does may be
convenient, but it is by no means essential.
The "_tcp" or "_udp" should be regarded as little more than
boilerplate text, and care should be taken not to attach too much
importance to it. Some might argue that the "_tcp" or "_udp" labels
need not exist at all, and it would have been better to have a single
label such as "_srv", but the "_tcp" / "_udp" convention was
established by RFC 2782, and this document does not propose to change
that. For the purposes of DNS-SD, the label "_tcp" is used for
protocols that run over TCP, and the label "_udp" is used for
everything else.
7.1. Selective Instance Enumeration (Subtypes)
This document does not attempt to define a sophisticated (i.e. Turing
Complete, or even regular expression) query language for service
discovery, nor do we believe one is necessary.
However, there are some limited circumstances where narrowing the
list of results may be useful. For example, many network printers
offer a web-based user interface, for management and administration,
using HTML/HTTP. A web browser wanting to discover all advertised web
pages on the local network issues a query for "_http._tcp.<Domain>".
On the other hand, there are cases where users wish to manage
printers specifically, not to discover web pages in general, and it
would be good accommodate this. In this case we define the "_printer"
subtype of "_http._tcp", and the web browser issues a query for
"_printer._sub._http._tcp.<Domain>", to discover only pages
advertised as having that subtype property.
Expires 25th April 2011 Cheshire & Krochmal [Page 19]
Internet Draft DNS-Based Service Discovery 25th October 2010
The Safari web browser on Mac OS X Leopard uses subtypes in this way.
This can be seen by using the commands below on Mac OS X (or on
Windows, with Bonjour for Windows installed) to advertise two "fake"
services. The service instance "A web page" is displayed in the
"Webpages" section of Safari's Bonjour list, while the instance
"A printer's web page" is displayed in the "Printers" section.
dns-sd -R "A web page" _http._tcp local 123
dns-sd -R "A printer's web page" _http._tcp,_printer local 123
Note that the advertised web page's Service Instance Name is
unchanged by the use of subtypes -- it is still something of the form
"The Server._http._tcp.example.com." The subdomain in which HTTP
server SRV records are registered defines the namespace within which
HTTP server names are unique. Additional subtypes (e.g. "_printer")
of the basic service type (e.g. "_http._tcp") serve to narrow the
list of results, not to create more namespace.
Subtypes are appropriate when it is desirable for different kinds of
clients to be able to browse for services at two levels of
granularity. In the example above, we describe two classes of HTTP
clients: general web browsing clients that are interested in all web
pages, and specific printer management tools that would like to
discover only web UI pages advertised by printers. The set of HTTP
servers on the network is the same in both cases; the difference is
that some clients want to discover all of them, whereas other clients
only want to find the subset of HTTP servers whose purpose is printer
administration.
Subtypes are only appropriate in two-level scenarios such as this
one, where some clients want to find the full set of services of a
given type, and at the same time other clients only want to find some
subset. Generally speaking, if there is no client that wants to find
the entire set, then it's neither necessary nor desirable to use the
subtype mechanism. If all clients are browsing for some particular
subtype, and no client exists that browses for the parent type, then
a new Application Protocol Name representing the logical service
should be defined, and software should simply advertise and browse
for that particular service type directly. In particular, just
because a particular network service happens to be implemented in
terms of some other underlying protocol, like HTTP, Sun RPC, or SOAP,
doesn't mean that it's sensible for that service to be defined as a
subtype of "_http", "_sunrpc", or "_soap". That would only be useful
if there were some class of client for which it is sensible to say,
"I want to discover a service on the network, and I don't care what
it does, as long as it does it using the SOAP XML RPC mechanism."
As with the TXT record key/value pairs, the list of possible
subtypes, if any, are defined and specified separately for each
basic service type.
Expires 25th April 2011 Cheshire & Krochmal [Page 20]
Internet Draft DNS-Based Service Discovery 25th October 2010
Subtype strings (e.g. "_printer" in the example above) may be
constructed using arbitrary 8-bit data values. These data values may
in many cases be UTF-8 representations of text, or even (as in the
example above) plain ASCII, but they do not have to be. Note however
that even when using arbitrary 8-bit data for subtype strings, DNS
name comparisons are still case-insensitive, so (for example) the
byte values 0x41 and 0x61 will be considered equivalent for subtype
comparison purposes.
7.2 Service Name Length Limits
As specified above, application protocol names are allowed to be up
to fifteen characters long. The reason for this limit is to leave
as many bytes of the domain name as possible available for use
by both the network administrator (choosing service domain names)
and the end user (choosing instance names).
A domain name may be up to 255 bytes long, plus one byte for the
final terminating root label at the end. Domain names used by DNS-SD
take the following forms:
<app>._tcp.<servicedomain>.<parentdomain>.
<Instance>.<app>._tcp.<servicedomain>.<parentdomain>.
<sub>._sub.<app>._tcp.<servicedomain>.<parentdomain>.
The first example shows the name used for PTR queries. The second
shows a service instance name, i.e. the name of the service's SRV and
TXT records. The third shows a subtype browsing name, i.e. the name
of a PTR record pointing to a service instance name (see Section 7.1
"Selective Instance Enumeration").
The instance name <Instance> may be up to 63 bytes. Including the
length byte used by the DNS format when the name is stored in a
packet, that makes 64 bytes.
When using subtypes, the subtype identifier is allowed to be up to
63 bytes, plus the length byte, making 64. Including the "_sub"
and its length byte, this makes 69 bytes.
The application protocol name <app> may be up to 15 bytes, plus
the underscore and length byte, making a total of 17. Including
the "_udp" or "_tcp" and its length byte, this makes 22 bytes.
Typically, DNS-SD service records are placed into subdomains of their
own beneath a company's existing domain name. Since these subdomains
are intended to be accessed through graphical user interfaces, not
typed on a command-line, they are frequently long and descriptive.
Including the length byte, the user-visible service domain may be up
to 64 bytes.
Expires 25th April 2011 Cheshire & Krochmal [Page 21]
Internet Draft DNS-Based Service Discovery 25th October 2010
Of our available 255 bytes, we have now accounted for 69+22+64 =
155 bytes. This leaves 100 bytes to accommodate the organization's
existing domain name <parentdomain>. When used with Multicast DNS,
<parentdomain> is "local.", which easily fits. When used with parent
domains of 100 bytes or less, the full functionality of DNS-SD is
available without restriction. When used with parent domains longer
than 100 bytes, the protocol risks exceeding the maximum possible
length of domain names, causing failures. In this case, careful
choice of short <servicedomain> names can help avoid overflows.
If the <servicedomain> and <parentdomain> are too long, then service
instances with long instance names will not be discoverable or
resolvable, and applications making use of long subtype names
may fail.
Because of this constraint, we choose to limit Application Protocol
Names to 15 characters or less. Allowing more characters would not
increase the expressive power of the protocol, and would needlessly
reduce the maximum <parentdomain> length that may be safely used.
Note that <Instance> name lengths affect the maximum number of
services of a given type that can be discovered in a given
<servicedomain>. The largest unicast DNS response than can be sent
(typically using TCP, not UDP) is 64kB. Using DNS name compression,
a Service Instance Enumeration PTR record requires 2 bytes for the
(compressed) name, plus 10 bytes for type, class, ttl and rdata
length. The rdata of the PTR record requires up to 64 bytes for the
<Instance> part of the name, plus 2 bytes for a name compression
pointer to the common suffix, making a maximum of 78 bytes total.
This means that even using maximum-sized <Instance> names, up to
839 instances of a given service type can be discovered in a given
<servicedomain>.
Multicast DNS aggregates response packets, so it does not have the
same hard limit, but in practice it is also useful for up to a few
hundred instances of a given service type, but probably not
thousands.
However, displaying even 100 instances in a flat list is probably too
many to be helpful to a typical user. If a network has more than
100 instances of a given service type, it's probably appropriate to
divide those services into logical subdomains by building, by floor,
by department, etc.
Expires 25th April 2011 Cheshire & Krochmal [Page 22]
Internet Draft DNS-Based Service Discovery 25th October 2010
8. Flagship Naming
In some cases, there may be several network protocols available
which all perform roughly the same logical function. For example,
the printing world has the LPR protocol, and the Internet Printing
Protocol (IPP), 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 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 the case of multiple protocols like this that all perform
effectively the same function, the client should suppress duplicate
names and display each name only once. When the user prints to a
given named printer, the printing client is responsible for choosing
the protocol which 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 some
future printer that only supports IPP printing, and some other future
printer that only supports pdl-datastream printing. The name spaces
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 called "Sales Department", just because those printers
implement different protocols.
To help guard against this, when there are two or more network
protocols which 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,
Expires 25th April 2011 Cheshire & Krochmal [Page 23]
Internet Draft DNS-Based Service Discovery 25th October 2010
target host = hostname 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 [mDNS], 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 so no conflict would be registered.
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 do not (and should not) be discoverable via
Service Instance Enumeration (browsing).
9. Service Type Enumeration
In general, normal clients are 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 reason, a special meta-query is defined. A DNS query for PTR
records with the name "_services._dns-sd._udp.<Domain>" yields a list
of PTR records, where the rdata of each PTR record is the two-label
name of a service type, e.g. "_http._tcp." These two-label service
types can then be used to construct subsequent Service Instance
Enumeration PTR queries, in this <Domain> or others, to discover
a list of instances of that service type.
A Service Type Enumeration PTR record's rdata SHOULD contain just two
labels, without any additional "<Domain>" suffix. Clients processing
received Service Type Enumeration PTR records with more than two
labels SHOULD interpret the first two labels as a service type and
silently ignore any additional labels in the PTR rdata.
Expires 25th April 2011 Cheshire & Krochmal [Page 24]
Internet Draft DNS-Based Service Discovery 25th October 2010
10. Populating the DNS with Information
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 DNS-SD clients that don't implement AppleTalk NBP, and don't want
to.
IP printers could use Dynamic DNS Update [RFC 2136] to automatically
register their own PTR, SRV and TXT records with the DNS server.
A printer manager device which has knowledge of printers on the
network through some other management protocol could also use Dynamic
DNS Update [RFC 2136].
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.
Zeroconf printers answer Multicast DNS queries on the local link
for appropriate PTR, SRV and TXT names ending with ".local." [mDNS]
11. Relationship to Multicast DNS
DNS-Based Service Discovery is only peripherally related to Multicast
DNS, in that the standard unicast DNS queries used by DNS-SD may also
be performed using multicast when appropriate, which is particularly
beneficial in Zeroconf environments.
12. Discovery of Browsing and Registration Domains (Domain Enumeration)
One of the motivations for DNS-Based Service Discovery is so that
when a visiting client (e.g. a laptop computer) arrives at a new
network, it can discover what services are available on that network
without manual configuration. This logic (discovering services
without manual configuration) also applies to discovering the domains
in which services are registered without requiring manual
configuration for that either.
Expires 25th April 2011 Cheshire & Krochmal [Page 25]
Internet Draft DNS-Based Service Discovery 25th October 2010
This discovery is performed recursively, using Unicast or Multicast
DNS. Five special RR names are reserved for this purpose:
b._dns-sd._udp.<domain>.
db._dns-sd._udp.<domain>.
r._dns-sd._udp.<domain>.
dr._dns-sd._udp.<domain>.
lb._dns-sd._udp.<domain>.
By performing PTR queries for these names, a client can learn,
respectively:
o A list of domains recommended for browsing
o A single recommended default domain for browsing
o A list of domains recommended for registering services using
Dynamic Update
o A single recommended default domain for registering services.
o The final query shown yields the "legacy browsing" or "automatic
browsing" domain. Sophisticated client applications that care to
present choices of domain to the user, use the answers learned
from the previous four queries to discover the domains to present.
In contrast, many current applications browse without specifying
an explicit domain, allowing the operating system to automatically
select an appropriate domain on their behalf. It is for this class
of application that the "automatic browsing" query is provided, to
allow the network administrator to communicate to the client
operating systems which domain(s) should be used automatically for
these applications.
These domains are purely advisory. The client or user is free to
browse and/or register services 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 a suitable 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) [RFC 2132], the DHCP "Domain Search"
option (option code 119) [RFC 3397], or IPv6 Router Advertisement
Options [DNS-RA].
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. It then constructs the
Expires 25th April 2011 Cheshire & Krochmal [Page 26]
Internet Draft DNS-Based Service Discovery 25th October 2010
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 address
192.168.12.34, with 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 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."
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 aggregate result, combining the information received
from all sources.
13. DNS Additional Record Generation
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.
13.1 PTR Records
When including a DNS-SD PTR record in a response packet, the
server/responder SHOULD include the following additional records:
o The SRV record(s) named in the PTR rdata.
o The TXT record(s) named in the PTR rdata.
o All address records (type "A" and "AAAA") named in the SRV rdata.
13.2 SRV Records
When including an SRV record in a response packet, the
server/responder SHOULD include the following additional records:
o All address records (type "A" and "AAAA") named in the SRV rdata.
Expires 25th April 2011 Cheshire & Krochmal [Page 27]
Internet Draft DNS-Based Service Discovery 25th October 2010
13.3 TXT Records
When including a TXT record in a response packet, no additional
records are required.
13.4 Other Record Types
In response to address queries, or other record types, no additional
records are recommended by this document.
14. Working Examples
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, but if you wish you can try these examples for yourself as you
read along, using the nslookup command already available on most Unix
machines.
14.1 Question: What web pages are being advertised from dns-sd.org?
nslookup -q=ptr _http._tcp.dns-sd.org.
_http._tcp.dns-sd.org
name = Zeroconf._http._tcp.dns-sd.org
_http._tcp.dns-sd.org
name = Multicast\032DNS._http._tcp.dns-sd.org
_http._tcp.dns-sd.org
name = DNS\032Service\032Discovery._http._tcp.dns-sd.org
_http._tcp.dns-sd.org
name = Stuart's\032Printer._http._tcp.dns-sd.org
Answer: There are four, called "Zeroconf", "Multicast DNS",
"DNS Service Discovery" and "Stuart's Printer".
Note that nslookup escapes spaces as "\032" for display purposes,
but a graphical DNS-SD browser should not.
14.2 Question: What printer-configuration web pages are there?
nslookup -q=ptr _printer._sub._http._tcp.dns-sd.org
_printer._sub._http._tcp.dns-sd.org
name = Stuart's\032Printer._http._tcp.dns-sd.org
Answer: "Stuart's Printer" is the web configuration UI of a network
printer.
Expires 25th April 2011 Cheshire & Krochmal [Page 28]
Internet Draft DNS-Based Service Discovery 25th October 2010
14.3 Question: How do I access the "DNS Service Discovery" web page?
nslookup -q=any "DNS\032Service\032Discovery._http._tcp.dns-sd.org."
DNS\032Service\032Discovery._http._tcp.dns-sd.org
priority = 0, weight = 0, port = 80, host = dns-sd.org
DNS\032Service\032Discovery._http._tcp.dns-sd.org
text = "path=/"
dns-sd.org nameserver = ns1.bolo.net
dns-sd.org internet address = 64.142.82.154
ns1.bolo.net internet address = 64.142.82.152
Answer: You need to connect to dns-sd.org port 80, path "/".
The address for dns-sd.org is also given (64.142.82.154).
15. User Interface Considerations
DNS-Based Service Discovery was designed by first giving careful
consideration to what constitutes a good user experience for service
discovery, and then designing a protocol with the features necessary
to facilitate providing that good user experience. This section
covers two issues in particular: Choice of factory-default names
(and automatic renaming behavior) for devices advertising services,
and the "continuous live update" user-experience model for clients
browsing to discover services.
15.1 Service Advertising User-Interface Considerations
When a DNS-SD service is advertised using Multicast DNS [mDNS],
automatic name conflict and resolution will occur if there is already
another service of the same type advertising with the same name.
As described in the Multicast DNS specification [mDNS], upon a
conflict, the service should:
1. Automatically select a new name (typically by appending
or incrementing a digit at the end of the name),
2. Try advertising with the new name, and
3. Upon success, record the new name in persistent storage.
This renaming behavior is very important, because it is the key
to providing user-friendly service names in the out-of-the-box
factory-default configuration. Some product developers may not
have realized this, because there are some products today where
the factory-default name is distinctly unfriendly, containing
random-looking strings of characters, like 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
Expires 25th April 2011 Cheshire & Krochmal [Page 29]
Internet Draft DNS-Based Service Discovery 25th October 2010
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:
Brother 5070N
Canon W2200
HP LaserJet 4600
Lexmark W840
Okidata C5300
Ricoh Aficio CL7100
Xerox Phaser 6200DX
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.
(a) In the case where the user has only one network printer, a simple
name like (to use a vendor-neutral example) "Printer" is more
user-friendly than an ugly name like "Printer 0001E68C74FB".
Appending ugly hexadecimal goop to the end of the name to make
sure the name is unique is irrelevant to a user who only has one
printer anyway.
(b) In the case where the user gets a second network printer,
having it detect that the name "Printer" is already in use
and automatically instead name itself "Printer (2)" provides a
good user experience. For most users, remembering that the old
printer is "Printer" and the new one is "Printer (2)" is easy
and intuitive. Seeing two printers called "Printer 0001E68C74FB"
and "Printer 00306EC3FD1C" is a lot less helpful.
(c) In the case of a network with ten network printers, seeing a
list of ten names all of the form "Printer xxxxxxxxxxxx" has
effectively taken what was supposed to be a list of user-friendly
rich-text names (supporting mixed case, spaces, punctuation,
non-Roman characters and other symbols) and turned it into
just about the worst user-interface imaginable: a list of
incomprehensible random-looking strings of letters and digits.
In a network with a lot of printers, it would be desirable for
the people setting up the printers to take a moment to give each
one a descriptive name, but in the event they don't, presenting
the users with a list of sequentially-numbered printers is a much
more desirable default user experience than showing a list of raw
Ethernet addresses.
Expires 25th April 2011 Cheshire & Krochmal [Page 30]
Internet Draft DNS-Based Service Discovery 25th October 2010
15.2 Client Browsing User-Interface Considerations
Of particular concern in the design of DNS-SD, particularly when
used in conjunction with ad hoc Multicast DNS, was 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:
(a) client software calls the service discovery code
(b) service discovery code instantly gets list of discovered
instances at a particular moment in time, and then
(c) client software displays list for user to select from
Superficially this usage model seems reasonable, but the problem is
that it's too optimistic. It only considers the success case, where
the user immediately finds the service instance they're looking for.
In the case where the user is looking for (say) a particular printer,
and that printer's 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. A fairly typical user experience is:
(a) display an empty window,
(b) display some animation like a searchlight
sweeping back and forth for ten seconds, and then
(c) at the end of the ten-second search, display
a static list showing what was discovered.
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, the moment it's
displayed on the screen it's already beginning to get stale and
out-of-date.
The service discovery user experience that the DNS-SD designers had
in mind has some rather different properties:
1. Displaying the initial list of discovered services should be
effectively instantaneous -- i.e. typically 0.1 seconds, not
10 seconds.
2. The list of discovered services should not be getting stale
and out-of-date from the moment it's displayed. The list
should be 'live' and should continue to update as new services
are discovered. Because of the delays, packet losses, and
retransmissions inherent in networking, it is to be expected
that sometimes, after the initial list is displayed showing
Expires 25th April 2011 Cheshire & Krochmal [Page 31]
Internet Draft DNS-Based Service Discovery 25th October 2010
the majority of discovered services, a few remaining stragglers
may continue to trickle in during the subsequent few seconds.
Even after this stable list has been built and displayed, it
should remain 'live' and should continue to update. At any future
time, be it minutes, hours, or even days later, if a new service
of the desired type is discovered, it should be displayed in the
list automatically, without the user having to click a "refresh"
button or take any other explicit action to update the display.
3. With users getting to be in the habit of leaving service discovery
windows open, and coming to expect to be able to rely on them to
show a continuous 'live' view of current network reality, this
gives us an additional requirement: deletion of stale services.
When a service discovery list shows just a static snapshot at a
moment in time, then the situation is simple: either a service was
discovered and appears in the list, or it was not, and does not.
However, when our list is live and updates continuously with the
discovery of new services, then this implies the corollary: when
a service goes away, it needs to *disappear* from the service
discovery list. Otherwise, the service discovery list would simply
grow monotonically over time, accreting stale data, and would
require a periodic "refresh" (or complete dismissal and
recreation) to restore correct display.
4. With users getting to be in the habit of leaving service discovery
windows open, these windows need to update not only in response
to services coming and going, but also in response to changes
in configuration and connectivity of the client machine itself.
For example, if a user opens a service discovery window when no
Ethernet cable is connected to the client machine, and the window
appears empty with no discovered services, then when the user
connects the cable the window should automatically populate with
discovered services without requiring any explicit user action.
If the user disconnects the Ethernet cable, all the services
discovered via that network interface should automatically
disappear. If the user switches from one 802.11 [IEEE W] wireless
base station to another, the service discovery window should
automatically update to remove all the services discovered via the
old wireless base station, and add all the services discovered via
the new one.
Expires 25th April 2011 Cheshire & Krochmal [Page 32]
Internet Draft DNS-Based Service Discovery 25th October 2010
16. IPv6 Considerations
IPv6 has no significant differences, except that 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.
17. Security Considerations
DNSSEC [RFC 2535] should be used where the authenticity of
information is important. Since DNS-SD is just a naming and usage
convention for 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.
18. IANA Considerations
IMPORTANT NOTE: Once draft-ietf-tsvwg-iana-ports is published, most
of this IANA Considerations section can be deleted.
This protocol builds on DNS SRV records [RFC 2782], and similarly
requires IANA to assign unique application protocol names.
Unfortunately, the "IANA Considerations" section of RFC 2782 says
simply, "The IANA has assigned RR type value 33 to the SRV RR.
No other IANA services are required by this document."
Due to this oversight, IANA is currently prevented from carrying
out the necessary function of assigning these unique identifiers.
This document specifies the following IANA allocation policy for
unique application protocol names:
Allowable names:
* Must be no more than fifteen characters long
* Must consist only of:
- lower-case letters 'a' - 'z'
- digits '0' - '9'
- the hyphen character '-'
* Must begin and end with a lower-case letter or digit.
* Must contain at least one lower-case letter 'a' - 'z'
* Must not already be assigned to some other protocol in the
existing IANA "list of assigned application protocol names
and port numbers" [ports].
These identifiers are allocated on a First Come First Served basis.
In the event of abuse (e.g. automated mass registrations, etc.),
the policy may be changed without notice to Expert Review [RFC 2434].
The textual nature of service/protocol names means that there are
almost infinitely many more of them available than the finite set of
65535 possible port numbers. This means that developers can produce
experimental implementations using unregistered service names with
little chance of accidental collision, providing service names are
Expires 25th April 2011 Cheshire & Krochmal [Page 33]
Internet Draft DNS-Based Service Discovery 25th October 2010
chosen with appropriate care. However, this document strongly
advocates that on or before the date a product ships, developers
should properly register their service names.
Some developers have expressed concern that publicly registering
their service names (and port numbers today) with IANA before a
product ships may give away clues about that product to competitors.
For this reason, IANA should consider allowing service name
applications to remain secret for some period of time, much as US
patent applications remain secret for two years after the date of
filing.
This proposed IANA allocation policy is not in effect until this
document is published as an RFC. In the meantime, unique application
protocol names may be registered according to the instructions at
<http://www.dns-sd.org/ServiceTypes.html>. As of August 2008, there
are over 400 application protocols in currently shipping products
that have been so registered as using DNS-SD for service discovery.
19. Acknowledgments
The concepts described in this document have been explored, developed
and implemented with help from Richard Brown, Erik Guttman, Paul
Vixie, and Bill Woodcock.
Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher,
Rory McGuire, Roger Pantos and Kiren Sekar for their significant
contributions.
20. Copyright Notice
Copyright (c) 2010 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.
Expires 25th April 2011 Cheshire & Krochmal [Page 34]
Internet Draft DNS-Based Service Discovery 25th October 2010
21. Normative References
[RFC 1033] Lottor, M., "Domain Administrators Operations Guide",
RFC 1033, November 1987.
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2782, February 2000.
[RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003.
[UAX15] "Unicode Normalization Forms"
http://www.unicode.org/reports/tr15/
22. Informative References
[AFP] Apple Filing Protocol <http://developer.apple.com/
documentation/Networking/Conceptual/AFP/>
[B4W] Bonjour for Windows <http://www.apple.com/bonjour/>
[BJP] Bonjour Printing Specification <http://developer.
apple.com/networking/bonjour/bonjourprinting.pdf>
[DNS-RA] J. Jeong, et al., "IPv6 Router Advertisement Options for
DNS Configuration", Internet-Draft (work in progress),
draft-ietf-6man-dns-options-bis-08.txt, September 2010.
[IEEE W] <http://standards.ieee.org/wireless/>
[mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS",
Internet-Draft (work in progress),
draft-cheshire-dnsext-multicastdns-12.txt, October 2010.
[NBP] Cheshire, S., and M. Krochmal,
"Requirements for a Protocol to Replace AppleTalk NBP",
Internet-Draft (work in progress),
draft-cheshire-dnsext-nbp-09.txt, October 2010.
[ports] IANA list of assigned application protocol names and port
numbers <http://www.iana.org/assignments/port-numbers>
Expires 25th April 2011 Cheshire & Krochmal [Page 35]
Internet Draft DNS-Based Service Discovery 25th October 2010
[RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
[RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
System (DNS UPDATE)", RFC 2136, April 1997.
[RFC 2181] Elz, R., and Bush, R., "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 2434,
October 1998.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000.
[RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration
Protocol (DHCP) Domain Search Option", RFC 3397, November
2002.
[RFC 4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006
[SOAP] Nilo Mitra, "SOAP Version 1.2 Part 0: Primer",
W3C Proposed Recommendation, 24 June 2003
http://www.w3.org/TR/2003/REC-soap12-part0-20030624
Appendix A. Ordering of Service Instance Name Components
There have been questions about why services are named using DNS
Service Instance Names of the form:
Service Instance Name = <Instance> . <Service> . <Domain>
instead of:
Service Instance Name = <Service> . <Instance> . <Domain>
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:
Expires 25th April 2011 Cheshire & Krochmal [Page 36]
Internet Draft DNS-Based Service Discovery 25th October 2010
A.1. Semantic Structure
The facility being provided by browsing ("Service Instance
Enumeration") is effectively enumerating the leaves of a tree
structure. A given domain offers zero or more services. For each
of those service types, there may be zero or more instances of
that service.
The user knows what type of service they are seeking. (If they are
running an FTP client, they are looking for FTP servers. If they have
a document to print, they are looking for entities that speak some
known printing protocol.) The user knows in which organizational or
geographical domain they wish to search. (The user does not want a
single flat list of every single printer on the planet, even if such
a thing were possible.) What the user does not know in advance is
whether the service they seek is offered in the given domain, or if
so, how many instances are offered, and the names of those instances.
Hence having the instance names be the leaves of the tree is
consistent with this semantic model.
Having the service types be the terminal leaves of the tree would
imply that the user knows the domain name, and already knows the
name of the service instance, but doesn't have any idea what the
service does. We would argue that this is a less useful model.
A.2. Network Efficiency
When a DNS response contains multiple answers, name compression works
more effectively if all the names contain a common suffix. If many
answers in the packet have the same <Service> and <Domain>, then each
occurrence of a Service Instance Name can be expressed using only
the <Instance> part followed by a two-byte compression pointer
referencing a previous appearance of "<Service>.<Domain>". This
efficiency would not be possible if the <Service> component appeared
first in each name.
A.3. Operational Flexibility
This name structure allows subdomains to be delegated along logical
service boundaries. For example, the network administrator at Example
Co. could choose to delegate the "_tcp.example.com." subdomain to a
different machine, so that the machine handling service discovery
doesn't have to be the machine that handles other day-to-day
DNS operations. (It *can* be the same machine if the administrator
so chooses, but the administrator is free to make that choice.)
Furthermore, if the network administrator wishes to delegate all
information related to IPP printers to a machine dedicated to
that specific task, this is easily done by delegating the
"_ipp._tcp.example.com." subdomain to the desired machine. It is
Expires 25th April 2011 Cheshire & Krochmal [Page 37]
Internet Draft DNS-Based Service Discovery 25th October 2010
also convenient to set security policies on a per-zone/per-subdomain
basis. For example, the administrator may choose to enable DNS
Dynamic Update [RFC 2136] [RFC 3007] for printers registering
in the "_ipp._tcp.example.com." subdomain, but not for other
zones/subdomains. This easy flexibility would not exist if the
<Service> component appeared first in each name.
Appendix B. Comparison with Alternative Service Discovery Protocols
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 [mDNS] 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 [RFC 2136]. 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
Expires 25th April 2011 Cheshire & Krochmal [Page 38]
Internet Draft DNS-Based Service Discovery 25th October 2010
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 [RFC 2535].
In summary:
Service discovery requires a central aggregation server.
DNS already has one: It's called a DNS server.
Service discovery requires a service registration protocol.
DNS already has one: It's called DNS Dynamic Update.
Service discovery requires a query protocol.
DNS already has one: It's called DNS.
Service discovery requires security mechanisms.
DNS already has security mechanisms: DNSSEC.
Service discovery requires a multicast mode for ad hoc networks.
Using DNS-SD in conjunction with Multicast DNS provides this,
using peer-to-peer multicast instead of a DNS server.
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.
Appendix C. Deployment History
Multicast DNS and DNS-Based Service Discovery software 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 and DNS-Based Service Discovery 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) [B4W].
Expires 25th April 2011 Cheshire & Krochmal [Page 39]
Internet Draft DNS-Based Service Discovery 25th October 2010
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 and DNS-Based Service Discovery are
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 and DNS-Based Service Discovery,
some in C like Apple's mDNSResponder daemon, and others in a variety
of different languages including Java, Python, Perl, and C#/Mono.
Authors' Addresses
Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino
California 95014
USA
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Marc Krochmal
Apple Inc.
1 Infinite Loop
Cupertino
California 95014
USA
Phone: +1 408 974 4368
EMail: marc@apple.com
Expires 25th April 2011 Cheshire & Krochmal [Page 40]
