RFC 6763
DNS-Based Service Discovery
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 records [RFC2782]. The first label of the pair is an underscore character followed by the Service Name [RFC6335]. The Service Name identifies what the service does and what application protocol it uses to do it. For applications using TCP, the second label is "_tcp". For applications using any transport protocol other than TCP, the second label is "_udp". This applies to all other transport protocols, including User Datagram Protocol (UDP), Stream Control Transmission Protocol (SCTP) [RFC4960], Datagram Congestion Control Protocol (DCCP) [RFC4340], Adobe's Real Time Media Flow Protocol (RTMFP), etc. In retrospect, perhaps the SRV specification should not have used the "_tcp" and "_udp" labels at all, and instead should have used a single label "_srv" to carve off a subdomain of DNS namespace for this use, but that specification is already published and deployed. At this point there is no benefit in changing established practice. While "_srv" might be aesthetically nicer than "_udp", it is not a user-visible string, and all that is required protocol-wise is (i) that it be a label that can form a DNS delegation point, and (ii) that it be short so that it does not take up too much space in the packet, and in this respect either "_udp" or "_srv" is equally good. Thus, it makes sense to use "_tcp" for TCP- based services and "_udp" for all other transport protocols -- which are in fact, in today's world, often encapsulated over UDP -- rather than defining a new subdomain for every new transport protocol. Note that this usage of the "_udp" label for all protocols other than TCP applies exclusively to DNS-SD service advertising, i.e., services advertised using the PTR+SRV+TXT convention specified in this document. It is not a requirement of SRV records in general. Other specifications that are independent of DNS-SD and not intended to interoperate with DNS-SD records are not in any way constrained by how DNS-SD works just because they also use the DNS SRV record datatype [RFC2782]; they are free to specify their own naming conventions as appropriate. The rules for Service Names [RFC6335] state that they may be no more than fifteen characters long (not counting the mandatory underscore), consisting of only letters, digits, and hyphens, must begin and end with a letter or digit, must not contain consecutive hyphens, and must contain at least one letter. The requirement to contain at least one letter is to disallow Service Names such as "80" or
"6000-6063", which could be misinterpreted as port numbers or port number ranges. While both uppercase and lowercase letters may be used for mnemonic clarity, case is ignored for comparison purposes, so the strings "HTTP" and "http" refer to the same service. Wise selection of a Service Name is important, and the choice is not always as obvious as it may appear. In many cases, the Service Name merely names and refers to the on- the-wire message format and semantics being used. FTP is "ftp", IPP printing is "ipp", and so on. However, it is common to "borrow" an existing protocol and repurpose it for a new task. This is entirely sensible and sound engineering practice, but that doesn't mean that the new protocol is providing the same semantic service as the old one, even if it borrows the same message formats. For example, the network music sharing protocol implemented by iTunes on Macintosh and Windows is built upon "HTTP GET" commands. However, that does *not* mean that it is sensible or useful to try to access one of these music servers by connecting to it with a standard web browser. Consequently, the DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp" (Digital Audio Access Protocol), not "_http._tcp". If iTunes were to advertise that it offered "_http._tcp" service, that would cause iTunes servers to appear in conventional web browsers (Safari, Camino, OmniWeb, Internet Explorer, Firefox, Chrome, etc.), which is of little use since an iTunes music library offers no HTML pages containing human-readable content that a web browser could display. Equally, if iTunes were to browse for "_http._tcp" service, that would cause it to discover generic web servers, such as the embedded web servers in devices like printers, which is of little use since printers generally don't have much music to offer. Analogously, Sun Microsystems's Network File System (NFS) is built on top of Sun Microsystems's Remote Procedure Call (Sun RPC) mechanism, but that doesn't mean it makes sense for an NFS server to advertise that it provides "Sun RPC" service. Likewise, Microsoft's Server Message Block (SMB) file service is built on top of Netbios running over IP, but that doesn't mean it makes sense for an SMB file server to advertise that it provides "Netbios-over-IP" service. The DNS-SD name of a service needs to encapsulate both the "what" (semantics) and the "how" (protocol implementation) of the service, since knowledge of both is necessary for a client to use the service meaningfully. Merely advertising that a service was built on top of Sun RPC is no use if the client has no idea what the service does.
Another common question is whether the service type advertised by iTunes should be "_daap._http._tcp." This would also be incorrect. Similarly, a protocol designer implementing a network service that happens to use the Simple Object Access Protocol [SOAP] should not feel compelled to have "_soap" appear somewhere in the Service Name. Part of the confusion here is that the presence of "_tcp" or "_udp" in the <Service> portion of a Service Instance Name has led people to assume that the visible structure of the <Service> should reflect the private internal structure of how the protocol was implemented. This is not correct. All that is required is that the service be identified by some unique opaque Service Name. Making the Service Name be English text that is at least marginally descriptive of what the service does may be convenient, but it is by no means essential.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 "_printer._sub._http._tcp.<Domain>". 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.
_printer._sub._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
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 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 service type. 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 instance names). 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 fail. 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 <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.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 to use. However, for problem diagnosis and network management tools, it may be useful for network administrators to find the list of advertised service types on the network, even if those Service Names are just opaque identifiers and not particularly informative in isolation. For this purpose, a special meta-query is defined. A DNS query for PTR records with the name "_services._dns-sd._udp.<Domain>" yields a set of PTR records, where the rdata of each PTR record is the two- label <Service> name, plus the same domain, e.g., "_http._tcp.<Domain>". Including the domain in the PTR rdata allows for slightly better name compression in Unicast DNS responses, but only the first two labels are relevant for the purposes of service type enumeration. These two-label service types can then be used to construct subsequent Service Instance Enumeration PTR queries, in this <Domain> or others, to discover instances of that service type.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 DNS server. 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: 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 "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 applications.
These domains are purely advisory. The client or user is free to
register services and/or browse in any domains. The purpose of these
special queries is to allow software to create a user interface that
displays a useful list of suggested choices to the user, from which
the user may make an informed selection, or ignore the offered
suggestions and manually enter their own choice.
The <domain> part of the Domain Enumeration query name may be
"local." (meaning "perform the query using link-local multicast") or
it may be learned through some other mechanism, such as the DHCP
"Domain" option (option code 15) [RFC2132], the DHCP "Domain Search"
option (option code 119) [RFC3397], or IPv6 Router Advertisement
Options [RFC6106].
The <domain> part of the query name may also be derived a different
way, from the host's IP address. The host takes its IP address and
calculates the logical AND of that address and its subnet mask, to
derive the 'base' address of the subnet (the 'network address' of
that subnet, or, equivalently, the IP address of the 'all-zero' host
address on that subnet). It then constructs the conventional DNS
"reverse mapping" name corresponding to that base address, and uses
that as the <domain> part of the name for the queries described
above. For example, if a host has the address 192.168.12.34, with
the subnet mask 255.255.0.0, then the 'base' address of the subnet is
192.168.0.0, and to discover the recommended automatic browsing
domain(s) for devices on this subnet, the host issues a DNS PTR query
for the name "lb._dns-sd._udp.0.0.168.192.in-addr.arpa."
Equivalent address-derived Domain Enumeration queries should also be
done for the host's IPv6 address(es).
Address-derived Domain Enumeration queries SHOULD NOT be done for
IPv4 link-local addresses [RFC3927] or IPv6 link-local addresses
[RFC4862].
Sophisticated clients may perform Domain Enumeration queries both in
"local." and in one or more unicast domains, using both name-derived
and address-derived queries, and then present the user with an
combined result, aggregating the information received from all
sources.
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 responses. Note that while servers SHOULD add these additional records for efficiency purposes, as with all DNS additional records, it is the client's responsibility to determine whether or not to trust them. Generally speaking, stub resolvers that talk to a single recursive name server for all their queries will trust all records they receive from that recursive name server (whom else would they ask?). Recursive name servers that talk to multiple authoritative name servers should verify that any records they receive from a given authoritative name server are "in bailiwick" for that server, and ignore them if not. Clients MUST be capable of functioning correctly with DNS servers (and Multicast DNS Responders) that fail to generate these additional records automatically, by issuing subsequent queries for any further record(s) they require. The additional-record generation rules in this section are RECOMMENDED for improving network efficiency, but are not required for correctness.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. _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 = Service\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", "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. _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.
13.3. How do I access the web page called "Service Discovery"?
nslookup -q=any "Service\032Discovery._http._tcp.dns-sd.org." Service\032Discovery._http._tcp.dns-sd.org priority = 0, weight = 0, port = 80, host = dns-sd.org Service\032Discovery._http._tcp.dns-sd.org text = "txtvers=1" "path=/" dns-sd.org nameserver = ns1.dns-sd.org dns-sd.org internet address = 64.142.82.154 ns1.dns-sd.org 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).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 records.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 service type. When IANA records a Service Name registration, if the new application protocol is one that conceptually duplicates existing functionality of an older protocol, and the implementers desire the Flagship Naming behavior described in Section 8, then the registrant should request that IANA record the name of the flagship protocol in the "notes" field of the new registration. For example, the registrations for "ipp" and "pdl-datastream" both reference "printer" as the flagship name for this family of printing-related protocols.17. Acknowledgments
The concepts described in this document have been explored, developed, and implemented with help from Ran Atkinson, Richard Brown, Freek Dijkstra, Ralph Droms, Erik Guttman, Pasi Sarolahti, Pekka Savola, Mark Townsley, Paul Vixie, Bill Woodcock, and others. Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, Rory McGuire, Roger Pantos, and Kiren Sekar for their significant contributions.
(page 33 continued on part 3)
