#11 Support Discovery of Browsing and Registration Domains (Doma
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.