Description Markus Kuppe 2010-06-07 08:44:14 EDT

Expires 8th September 2010         Cheshire & Krochmal         [Page 27]
Internet Draft         DNS-Based Service Discovery        8th March 2010

"One of the motivations for DNS-Based Service Discovery is so that
   when a visiting client (e.g. a laptop computer) arrives at a new
   network, it can discover what services are available on that network
   without manual configuration. This logic (discovering services
   without manual configuration) also applies to discovering the domains
   in which services are registered without requiring manual
   configuration.

   This discovery is performed recursively, using Unicast or Multicast
   DNS. Five special RR names are reserved for this purpose:

                      b._dns-sd._udp.<domain>.
                     db._dns-sd._udp.<domain>.
                      r._dns-sd._udp.<domain>.
                     dr._dns-sd._udp.<domain>.
                     lb._dns-sd._udp.<domain>.

   By performing PTR queries for these names, a client can learn,
   respectively:

    o A list of domains recommended for browsing

    o A single recommended default domain for browsing

    o A list of domains recommended for registering services using
      Dynamic Update

    o A single recommended default domain for registering services.

    o The final query shown yields the "legacy browsing" or "automatic
      browsing" domain. Sophisticated client applications that care to
      present choices of domain to the user, use the answers learned
      from the previous four queries to discover the domains to present.
      In contrast, many current applications browse without specifying
      an explicit domain, allowing the operating system to automatically
      select an appropriate domain on their behalf. It is for this class
      of application that the "automatic browsing" query is provided, to
      allow the network administrator to communicate to the client
      operating systems which domain(s) should be used automatically for
      these applications.

   These domains are purely advisory. The client or user is free to
   browse and/or register services in any domains. The purpose of these
   special queries is to allow software to create a user-interface that
   displays a useful list of suggested choices to the user, from which
   the user may make a suitable selection, or ignore the offered
   suggestions and manually enter their own choice.

   The <domain> part of the Domain Enumeration query name may be
   "local." (meaning "perform the query using link-local multicast) or
   it may be learned through some other mechanism, such as the DHCP
   "Domain" option (option code 15) [RFC 2132] or the DHCP "Domain
   Search" option (option code 119) [RFC 3397].

   The <domain> part of the name may also be derived from the host's IP
   address. The host takes its IP address, and calculates the logical
   AND of that address and its subnet mask, to derive the 'base' address
   of the subnet. It then constructs the conventional DNS "reverse
   mapping" name corresponding to that base address, and uses that
   as the <domain> part of the name for the queries described above.
   For example, if a host has address 192.168.12.34, with subnet mask
   255.255.0.0, then the 'base' address of the subnet is 192.168.0.0,
   and to discover the recommended automatic browsing domain for devices
   on this subnet, the host issues a DNS PTR query for the name
   "lb._dns-sd._udp.0.0.168.192.in-addr.arpa."

   Sophisticated clients may perform domain enumeration queries both in
   "local." and in one or more unicast domains, and then present the
   user with an aggregate result, combining the information received
   from all sources.
"

http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt