tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6763

 
 
 

DNS-Based Service Discovery

Part 2 of 3, p. 19 to 33
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 19 
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      Up      ToC       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      Up      ToC       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      Up      ToC       Page 22 
   "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

Top      Up      ToC       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      Up      ToC       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
   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.

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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
   "_ipp._tcp.example.com." subdomain to the printer manager device.

Top      Up      ToC       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      Up      ToC       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 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.

Top      Up      ToC       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      Up      ToC       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 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.

Top      Up      ToC       Page 32 
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

Top      Up      ToC       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 RFC Part