7. Service Names
The <Service> portion of a Service Instance Name consists of a pair
of DNS labels, following the convention already established for SRV
The first label of the pair is an underscore character followed by
the Service Name [RFC6335]. The Service Name identifies what the
service does and what application protocol it uses to do it.
For applications using TCP, the second label is "_tcp".
For applications using any transport protocol other than TCP, the
second label is "_udp". This applies to all other transport
protocols, including User Datagram Protocol (UDP), Stream Control
Transmission Protocol (SCTP) [RFC4960], Datagram Congestion Control
Protocol (DCCP) [RFC4340], Adobe's Real Time Media Flow Protocol
(RTMFP), etc. In retrospect, perhaps the SRV specification should
not have used the "_tcp" and "_udp" labels at all, and instead should
have used a single label "_srv" to carve off a subdomain of DNS
namespace for this use, but that specification is already published
and deployed. At this point there is no benefit in changing
established practice. While "_srv" might be aesthetically nicer than
"_udp", it is not a user-visible string, and all that is required
protocol-wise is (i) that it be a label that can form a DNS
delegation point, and (ii) that it be short so that it does not take
up too much space in the packet, and in this respect either "_udp" or
"_srv" is equally good. Thus, it makes sense to use "_tcp" for TCP-
based services and "_udp" for all other transport protocols -- which
are in fact, in today's world, often encapsulated over UDP -- rather
than defining a new subdomain for every new transport protocol.
Note that this usage of the "_udp" label for all protocols other than
TCP applies exclusively to DNS-SD service advertising, i.e., services
advertised using the PTR+SRV+TXT convention specified in this
document. It is not a requirement of SRV records in general. Other
specifications that are independent of DNS-SD and not intended to
interoperate with DNS-SD records are not in any way constrained by
how DNS-SD works just because they also use the DNS SRV record
datatype [RFC2782]; they are free to specify their own naming
conventions as appropriate.
The rules for Service Names [RFC6335] state that they may be no more
than fifteen characters long (not counting the mandatory underscore),
consisting of only letters, digits, and hyphens, must begin and end
with a letter or digit, must not contain consecutive hyphens, and
must contain at least one letter. The requirement to contain at
least one letter is to disallow Service Names such as "80" or
"6000-6063", which could be misinterpreted as port numbers or port
number ranges. While both uppercase and lowercase letters may be
used for mnemonic clarity, case is ignored for comparison purposes,
so the strings "HTTP" and "http" refer to the same service.
Wise selection of a Service Name is important, and the choice is not
always as obvious as it may appear.
In many cases, the Service Name merely names and refers to the on-
the-wire message format and semantics being used. FTP is "ftp", IPP
printing is "ipp", and so on.
However, it is common to "borrow" an existing protocol and repurpose
it for a new task. This is entirely sensible and sound engineering
practice, but that doesn't mean that the new protocol is providing
the same semantic service as the old one, even if it borrows the same
message formats. For example, the network music sharing protocol
implemented by iTunes on Macintosh and Windows is built upon "HTTP
GET" commands. However, that does *not* mean that it is sensible or
useful to try to access one of these music servers by connecting to
it with a standard web browser. Consequently, the DNS-SD service
advertised (and browsed for) by iTunes is "_daap._tcp" (Digital Audio
Access Protocol), not "_http._tcp".
If iTunes were to advertise that it offered "_http._tcp" service,
that would cause iTunes servers to appear in conventional web
browsers (Safari, Camino, OmniWeb, Internet Explorer, Firefox,
Chrome, etc.), which is of little use since an iTunes music library
offers no HTML pages containing human-readable content that a web
browser could display.
Equally, if iTunes were to browse for "_http._tcp" service, that
would cause it to discover generic web servers, such as the embedded
web servers in devices like printers, which is of little use since
printers generally don't have much music to offer.
Analogously, Sun Microsystems's Network File System (NFS) is built on
top of Sun Microsystems's Remote Procedure Call (Sun RPC) mechanism,
but that doesn't mean it makes sense for an NFS server to advertise
that it provides "Sun RPC" service. Likewise, Microsoft's Server
Message Block (SMB) file service is built on top of Netbios running
over IP, but that doesn't mean it makes sense for an SMB file server
to advertise that it provides "Netbios-over-IP" service. The DNS-SD
name of a service needs to encapsulate both the "what" (semantics)
and the "how" (protocol implementation) of the service, since
knowledge of both is necessary for a client to use the service
meaningfully. Merely advertising that a service was built on top of
Sun RPC is no use if the client has no idea what the service does.
Another common question is whether the service type advertised by
iTunes should be "_daap._http._tcp." This would also be incorrect.
Similarly, a protocol designer implementing a network service that
happens to use the Simple Object Access Protocol [SOAP] should not
feel compelled to have "_soap" appear somewhere in the Service Name.
Part of the confusion here is that the presence of "_tcp" or "_udp"
in the <Service> portion of a Service Instance Name has led people to
assume that the visible structure of the <Service> should reflect
the private internal structure of how the protocol was implemented.
This is not correct. All that is required is that the service be
identified by some unique opaque Service Name. Making the Service
Name be English text that is at least marginally descriptive of what
the service does may be convenient, but it is by no means essential.
7.1. Selective Instance Enumeration (Subtypes)
This document does not attempt to define a sophisticated (e.g.,
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 set
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 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 is good accommodate this.
In this case, we define the "_printer" subtype of "_http._tcp", and
to discover only the subset of pages advertised as having that
subtype property, the web browser issues a query for
The Safari web browser on Mac OS X 10.5 "Leopard" and later uses
subtypes in this way. If an "_http._tcp" service is discovered both
via "_printer._sub._http._tcp" browsing and via "_http._tcp" browsing
then it is displayed in the "Printers" section of Safari's UI. If a
service is discovered only via "_http._tcp" browsing then it is
displayed in the "Webpages" section of Safari's UI. This can be seen
by using the commands below on Mac OS X 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 100
dns-sd -R "A printer's web page" _http._tcp,_printer local 101
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.", and the advertised web page is
still discoverable using a standard browsing query for services of
type "_http._tcp". 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 allow clients to query for
a narrower set of results, not to create more namespace.
Using DNS zone file syntax, the service instance "A web page" is
advertised using one PTR record, while the instance "A printer's web
page" is advertised using two: the primary service type and the
additional subtype. Even though the "A printer's web page" service
is advertised two different ways, both PTR records refer to the name
of the same SRV+TXT record pair:
; One PTR record advertises "A web page"
_http._tcp.local. PTR A\032web\032page._http._tcp.local.
; Two different PTR records advertise "A printer's web page"
_http._tcp.local. PTR A\032printer's\032web\032page._http._tcp.local.
Subtypes are appropriate when it is desirable for different kinds of
client 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
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 Service 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."
Subtype strings are not required to begin with an underscore, though
they often do. As with the TXT record key/value pairs, the list of
possible subtypes, if any (including whether some or all begin with
an underscore) are defined and specified separately for each basic
Subtype strings (e.g., "_printer" in the example above) may be
constructed using arbitrary 8-bit data values. In many cases these
data values may be UTF-8 [RFC3629] representations of text, or even
(as in the example above) plain ASCII [RFC20], 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, Service Names are allowed to be no more than
fifteen characters long. The reason for this limit is to conserve
bytes in the domain name for use both by the network administrator
(choosing service domain names) and by the end user (choosing
A fully qualified 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:
<sn>._tcp . <servicedomain> . <parentdomain>.
<Instance> . <sn>._tcp . <servicedomain> . <parentdomain>.
<sub>._sub . <sn>._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 Service Name <sn> 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.
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.
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.
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
Because of this constraint, we choose to limit Service 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 64 kB. 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 using maximum-sized <Instance> names, up to 839
instances of a given service type can be discovered in a given
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
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.
8. Flagship Naming
In some cases, there may be several network protocols available that
all perform roughly the same logical function. For example, the
printing world has the lineprinter (LPR) protocol [RFC1179] and the
Internet Printing Protocol (IPP) [RFC2910], both of which cause
printed sheets to be emitted from printers in much the same way. In
addition, many printer vendors send their own proprietary page
description language (PDL) data over a TCP connection to TCP port
9100, herein referred to generically as the "pdl-datastream"
protocol. In an ideal world, we would have only one network printing
protocol, and it would be sufficiently good that no one felt a
compelling need to invent a different one. However, in practice,
multiple legacy protocols do exist, and a service discovery protocol
has to accommodate that.
Many printers implement all three printing protocols: LPR, IPP, and
pdl-datastream. For the benefit of clients that may speak only one
of those protocols, all three are advertised.
However, some clients may implement two, or all three of those
printing protocols. When a client looks for all three service types
on the network, it will find three distinct services -- an LPR
service, an IPP service, and a pdl-datastream service -- all of which
cause printed sheets to be emitted from the same physical printer.
In a case like this, where multiple protocols all perform effectively
the same function, a client may browse for all the service types it
supports and display all the discovered instance names in a single
aggregated list. Where the same instance name is discovered more
than once because that entity supports more than one service type
(e.g. a single printer which implements multiple printing protocols)
the duplicates should be suppressed and the name should appear only
once in the list. When the user indicates their desire to print on a
given named printer, the printing client is responsible for choosing
which of the available protocols will best achieve the desired
effect, without, for example, requiring the user to make a manual
choice between LPR and IPP.
As described so far, this all works very well. However, consider the
case of: some future printer that only supports IPP printing, and
some other future printer that only supports pdl-datastream printing.
The namespaces for different service types are intentionally disjoint
(it is acceptable and desirable to be able to have both a file server
called "Sales Department" and a printer called "Sales Department").
However, it is not desirable, in the common case, to allow two
different printers both to be called "Sales Department" merely
because those two printers implement different printing protocols.
To help guard against this, when there are two or more network
protocols that perform roughly the same logical function, one of the
protocols is declared the "flagship" of the fleet of related
protocols. Typically the flagship protocol is the oldest and/or
best-known protocol of the set.
If a device does not implement the flagship protocol, then it instead
creates a placeholder SRV record (priority=0, weight=0, port=0,
target host = host name of device) with that name. If, when it
attempts to create this SRV record, it finds that a record with the
same name already exists, then it knows that this name is already
taken by some other entity implementing at least one of the protocols
from the fleet, and it must choose another. If no SRV record already
exists, then the act of creating it stakes a claim to that name so
that future devices in the same protocol fleet will detect a conflict
when they try to use it.
Note: When used with Multicast DNS [RFC6762], the target host field
of the placeholder SRV record MUST NOT be the empty root label. The
SRV record needs to contain a real target host name in order for the
Multicast DNS conflict detection rules to operate. If two different
devices were to create placeholder SRV records both using a null
target host name (just the root label), then the two SRV records
would be seen to be in agreement, and no conflict would be detected.
By defining a common well-known flagship protocol for the class,
future devices that may not even know about each other's protocols
establish a common ground where they can coordinate to verify
uniqueness of names.
No PTR record is created advertising the presence of empty flagship
SRV records, since they do not represent a real service being
advertised, and hence are not (and should not be) discoverable via
Service Instance Enumeration (browsing).
9. Service Type Enumeration
In general, a normal client is not interested in finding *every*
service on the network, just the services that the client knows how
However, for problem diagnosis and network management tools, it may
be useful for network administrators to find the list of advertised
service types on the network, even if those Service Names are just
opaque identifiers and not particularly informative in isolation.
For this purpose, a special meta-query is defined. A DNS query for
PTR records with the name "_services._dns-sd._udp.<Domain>" yields a
set of PTR records, where the rdata of each PTR record is the two-
label <Service> name, plus the same domain, e.g.,
"_http._tcp.<Domain>". Including the domain in the PTR rdata allows
for slightly better name compression in Unicast DNS responses, but
only the first two labels are relevant for the purposes of service
type enumeration. These two-label service types can then be used to
construct subsequent Service Instance Enumeration PTR queries, in
this <Domain> or others, to discover instances of that service type.
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 IP-only clients that implement DNS-SD but not AppleTalk NBP.
A printer manager device that has knowledge of printers on the
network through some other management protocol could also output a
zone file or use DNS Update [RFC2136] [RFC3007].
Alternatively, a printer manager device could implement enough of the
DNS protocol that it is able to answer DNS queries directly, and
Example Co.'s main DNS server could delegate the
"_ipp._tcp.example.com." subdomain to the printer manager device.
IP printers could use Dynamic DNS Update [RFC2136] [RFC3007] to
automatically register their own PTR, SRV, and TXT records with the
Zeroconf printers answer Multicast DNS queries on the local link for
their own PTR, SRV, and TXT names ending with ".local." [RFC6762].
11. Discovery of Browsing and Registration Domains (Domain Enumeration)
One of the motivations for DNS-based Service Discovery is to enable a
visiting client (e.g., a Wi-Fi-equipped [IEEEW] laptop computer,
tablet, or mobile telephone) arriving on a new network to discover
what services are available on that network, without any manual
configuration. The logic that discovering services without manual
configuration is a good idea also dictates that discovering
recommended registration and browsing domains without manual
configuration is a similarly good idea.
This discovery is performed using DNS queries, using Unicast or
Multicast DNS. Five special RR names are reserved for this purpose:
By performing PTR queries for these names, a client can learn,
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
o A single recommended default domain for registering services.
o The "legacy browsing" or "automatic browsing" domain(s).
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 domains are purely advisory. The client or user is free to
register services and/or browse in any domains. The purpose of these
special queries is to allow software to create a user interface that
displays a useful list of suggested choices to the user, from which
the user may make an informed selection, or ignore the offered
suggestions and manually enter their own choice.
The <domain> part of the Domain Enumeration query name may be
"local." (meaning "perform the query using link-local multicast") or
it may be learned through some other mechanism, such as the DHCP
"Domain" option (option code 15) [RFC2132], the DHCP "Domain Search"
option (option code 119) [RFC3397], or IPv6 Router Advertisement
The <domain> part of the query name may also be derived a different
way, from the host's IP address. The host takes its IP address and
calculates the logical AND of that address and its subnet mask, to
derive the 'base' address of the subnet (the 'network address' of
that subnet, or, equivalently, the IP address of the 'all-zero' host
address on that subnet). It then constructs the conventional DNS
"reverse mapping" name corresponding to that base address, and uses
that as the <domain> part of the name for the queries described
above. For example, if a host has the address 192.168.12.34, with
the subnet mask 255.255.0.0, then the 'base' address of the subnet is
192.168.0.0, and to discover the recommended automatic browsing
domain(s) for devices on this subnet, the host issues a DNS PTR query
for the name "lb._dns-sd._udp.0.0.168.192.in-addr.arpa."
Equivalent address-derived Domain Enumeration queries should also be
done for the host's IPv6 address(es).
Address-derived Domain Enumeration queries SHOULD NOT be done for
IPv4 link-local addresses [RFC3927] or IPv6 link-local addresses
Sophisticated clients may perform Domain Enumeration queries both in
"local." and in one or more unicast domains, using both name-derived
and address-derived queries, and then present the user with an
combined result, aggregating the information received from all
12. 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
Note that while servers SHOULD add these additional records for
efficiency purposes, as with all DNS additional records, it is the
client's responsibility to determine whether or not to trust them.
Generally speaking, stub resolvers that talk to a single recursive
name server for all their queries will trust all records they receive
from that recursive name server (whom else would they ask?).
Recursive name servers that talk to multiple authoritative name
servers should verify that any records they receive from a given
authoritative name server are "in bailiwick" for that server, and
ignore them if not.
Clients MUST be capable of functioning correctly with DNS servers
(and Multicast DNS Responders) that fail to generate these additional
records automatically, by issuing subsequent queries for any further
record(s) they require. The additional-record generation rules in
this section are RECOMMENDED for improving network efficiency, but
are not required for correctness.
12.1. PTR Records
When including a DNS-SD Service Instance Enumeration or Selective
Instance Enumeration (subtype) 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.
12.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.
12.3. TXT Records
When including a TXT record in a response packet, no additional
records are required.
12.4. Other Record Types
In response to address queries, or other record types, no new
additional records are recommended by this document.
13. 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. However, if you wish, you can try these examples for yourself
as you read along, using the nslookup command already available on
most Unix machines.
13.1. What web pages are being advertised from dns-sd.org?
nslookup -q=ptr _http._tcp.dns-sd.org.
name = Zeroconf._http._tcp.dns-sd.org
name = Multicast\032DNS._http._tcp.dns-sd.org
name = Service\032Discovery._http._tcp.dns-sd.org
name = Stuart's\032Printer._http._tcp.dns-sd.org
Answer: There are four, called "Zeroconf", "Multicast 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.
13.2. What printer-configuration web pages are there?
nslookup -q=ptr _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
13.3. How do I access the web page called "Service Discovery"?
nslookup -q=any "Service\032Discovery._http._tcp.dns-sd.org."
priority = 0, weight = 0, port = 80, host = dns-sd.org
text = "txtvers=1" "path=/"
dns-sd.org nameserver = ns1.dns-sd.org
dns-sd.org internet address = 126.96.36.199
ns1.dns-sd.org internet address = 188.8.131.52
Answer: You need to connect to dns-sd.org port 80, path "/".
The address for dns-sd.org is also given (184.108.40.206).
14. IPv6 Considerations
IPv6 has only minor differences from IPv4.
The address of the SRV record's target host is given by the
appropriate IPv6 "AAAA" address records instead of (or in addition
to) IPv4 "A" records.
Address-based Domain Enumeration queries are performed using names
under the IPv6 reverse-mapping tree, which is different from the IPv4
reverse-mapping tree and has longer names in it.
15. Security Considerations
Since DNS-SD is just a specification for how to name and use records
in the existing DNS system, it has no specific additional security
requirements over and above those that already apply to DNS queries
and DNS updates.
For DNS queries, DNS Security Extensions (DNSSEC) [RFC4033] should be
used where the authenticity of information is important.
For DNS updates, secure updates [RFC2136] [RFC3007] should generally
be used to control which clients have permission to update DNS
16. IANA Considerations
IANA manages the namespace of unique Service Names [RFC6335].
When a protocol service advertising specification includes subtypes,
these should be documented in the protocol specification in question
and/or in the "notes" field of the registration request sent to IANA.
In the event that a new subtype becomes relevant after a protocol
specification has been published, this can be recorded by requesting
that IANA add it to the "notes" field. For example, vendors of
network printers advertise their embedded web servers using the
subtype _printer. This allows printer management clients to browse
for only printer-related web servers by browsing for the _printer
subtype. While the existence of the _printer subtype of _http._tcp
is not directly relevant to the HTTP protocol specification, it is
useful to record this usage in the IANA registry to help avoid
another community of developers inadvertently using the same subtype
string for a different purpose. The namespace of possible subtypes
is separate for each different service type. For example, the
existence of the _printer subtype of _http._tcp does not imply that
the _printer subtype is defined or has any meaning for any other
When IANA records a Service Name registration, if the new application
protocol is one that conceptually duplicates existing functionality
of an older protocol, and the implementers desire the Flagship Naming
behavior described in Section 8, then the registrant should request
that IANA record the name of the flagship protocol in the "notes"
field of the new registration. For example, the registrations for
"ipp" and "pdl-datastream" both reference "printer" as the flagship
name for this family of printing-related protocols.
The concepts described in this document have been explored,
developed, and implemented with help from Ran Atkinson, Richard
Brown, Freek Dijkstra, Ralph Droms, Erik Guttman, Pasi Sarolahti,
Pekka Savola, Mark Townsley, Paul Vixie, Bill Woodcock, and others.
Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher,
Rory McGuire, Roger Pantos, and Kiren Sekar for their significant