Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 6763

DNS-Based Service Discovery

Pages: 49
Proposed Standard
Updated by:  8553
Part 2 of 3 – Pages 19 to 33
First   Prev   Next

Top   ToC   RFC6763 - Page 19   prevText

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
Top   ToC   RFC6763 - Page 20
   "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.
Top   ToC   RFC6763 - Page 21
   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
Top   ToC   RFC6763 - Page 22
   "The", 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.
                     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
Top   ToC   RFC6763 - Page 23
   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.
Top   ToC   RFC6763 - Page 24
   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
Top   ToC   RFC6763 - Page 25
   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.
Top   ToC   RFC6763 - Page 26
   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).
Top   ToC   RFC6763 - Page 27

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 "" subdomain to the printer manager device.
Top   ToC   RFC6763 - Page 28
   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
Top   ToC   RFC6763 - Page 29
      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, with
   the subnet mask, then the 'base' address of the subnet is, and to discover the recommended automatic browsing
   domain(s) for devices on this subnet, the host issues a DNS PTR query
   for the name ""

   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
Top   ToC   RFC6763 - Page 30

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.
Top   ToC   RFC6763 - Page 31

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

nslookup -q=ptr name = name = Multicast\ name = Service\ name = Stuart's\ 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 name = Stuart's\ Answer: "Stuart's Printer" is the web configuration UI of a network printer.
Top   ToC   RFC6763 - Page 32

13.3. How do I access the web page called "Service Discovery"?

nslookup -q=any "Service\" Service\ priority = 0, weight = 0, port = 80, host = Service\ text = "txtvers=1" "path=/" nameserver = internet address = internet address = Answer: You need to connect to port 80, path "/". The address for is also given (

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
Top   ToC   RFC6763 - Page 33
   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)

Next Section