dns-sd.org Open in urlscan Pro
96.76.212.165  Public Scan

Form analysis
0 forms found in the DOM

Text Content

DNS SERVICE DISCOVERY (DNS-SD)



DNS Service Discovery is a way of using standard DNS programming interfaces,
servers, and packet formats to browse the network for services.

If you think the picture below looks a lot like the old Macintosh AppleTalk
“Chooser”, that’s no coincidence. As we move away from AppleTalk to an all-IP
world, we don’t want to have to give up the convenience and ease of use that
made AppleTalk popular, and made AppleTalk continue to be popular long after it
should rightfully have been retired.

DNS Service Discovery is compatible with, but not dependent on, Multicast DNS.




DOCUMENTS

 * RFC 6760 Requirements for a Protocol to Replace the AppleTalk Name Binding
   Protocol describes how AppleTalk Name Binding Protocol works, and what is
   needed in an IP-based replacement.

 * RFC 6763 DNS-Based Service Discovery describes how to perform network
   browsing and service discovery using only standard DNS packets and record
   types. DNS-SD is not dependent on Multicast DNS (it works with unicast as
   well); DNS-SD and mDNS are complementary technologies that can be used
   together.

 * RFC 6887 Port Control Protocol (PCP) describes a protocol for asking a home
   NAT gateway for its “public” address, so that a host behind a NAT gateway can
   create a DNS Dynamic Update using that public address, rather than its less
   useful private address, and similarly for asking a home NAT gateway to assign
   a public port number and an inbound port maping, so that a host behind a NAT
   gateway can create DNS SRV records using that public port number rather than
   its less useful private internal port number.

 * Hybrid Unicast/Multicast DNS-Based Service Discovery
   (draft-cheshire-mdnsext-hybrid) describes a way to provide wide-area service
   discovery for devices that only advertise their services using link-local
   Multicast DNS.

 * DNS Long-Lived Queries (draft-sekar-dns-llq) describes a protocol for setting
   up long-lived DNS queries with change notification, as a more efficient
   alternative to rapidly polling the server.

 * Dynamic DNS Update Leases (draft-sekar-dns-ul) describes a protocol for
   performing DNS Dynamic Updates with an attached lease time, that are
   automatically deleted unless renewed before the lease expires, much like a
   DHCP address lease.


SETTING UP DNS FOR ZERO-CONFIGURATION WIDE-AREA SERVICE DISCOVERY BY CLIENTS

One of easiest applications of Wide-Area DNS-SD is simply to add a few records
to your domain’s authoritative DNS server(s), to automatically advertise
selected services to clients, with zero configuration on the client side.

When clients get a response packet from the local network’s DHCP server, there’s
a domain in that packet, and clients running Mac OS X 10.4 (Tiger) or later, or
iOS, or Bonjour for Windows, automatically query that domain for advertised
services. Therefore, as long as you have administrative access to that domain’s
authoritative DNS server(s), you can easily add the necessary records so the
clients will discover web pages, printers, and other network services of your
choosing. If you don’t have have administrative access to the domain currently
being returned by your DHCP server, but you do control the DHCP server, then you
can change the DHCP server to return a different domain — one that you do have
control over. In many cases people set their home gateway’s DHCP server to
return their ISP’s domain name in the DHCP packet, without giving it much
thought. There’s really no reason to do this, since you have no control over
your ISP’s domain. It makes a lot more sense and is a lot more useful to set the
domain to be one that you do have control over.

A common misperception is that the service discovery records need to be created
on a DNS server that the service discovery client is configured to use. Or,
conversely, that the client needs to be configured to use the DNS server where
the service discovery records exist. This is not correct. To look up the address
of “www.amazon.com” you don’t need to first configure your client to use
Amazon’s DNS servers. To look up the address of “www.google.com” you don’t need
to first configure your client to use Google’s DNS servers. Just like looking up
addresses, to discover services advertised in a given domain you don’t need to
first configure your client to use that domain’s DNS servers. This is the beauty
of DNS. The answer to a DNS question depends (generally speaking) only on what
the question is, not which server you ask. You can send your DNS question to any
DNS server in the world, and (generally speaking) always get the same answer for
your question. This common misperception about DNS-SD stems from the fact that
the term “DNS server” is used to refer to two very different things.
Historically this is because “named” (the name dæmon software) could could
perform both functions, and when they used the term “DNS server” experienced DNS
operators instinctively knew which function they were talking about. The
distinction has been less clear to people who are not experienced DNS operators.
The first function of the “named” software is to be an authoritative name server
for a domain. This is the ultimate repository where DNS information about a
domain resides. The authoritative name server function may be replicated for
reliability — i.e., there may be several authoritative name servers for a given
domain, all with the same DNS record data. Typical clients never communicate
directly with authoritative name servers. The second function of the “named”
software is to be a recursive resolver. Typical clients send their queries to
their configured recursive resolver. That recursive resolver may return answers
it had previously cached (hence its other common name, “caching resolver”) or
may communicate with one or more authoritative name servers on the client’s
behalf. This may require multiple round-trips to multiple authoritative name
servers to determine which authoritative name server, somewhere on the planet,
holds the answers the client seeks. Once the recursive resolver has retrieved
the requested answers, it sends them to the client.

To deploy DNS-SD, clients do not need to be configured to use a different
recursive resolver, and no changes are required on the recursive resolver the
clients are using. The configuration the clients need is not who to ask, but
what to ask. The clients need to know in which domain to look for services, not
which recursive resolver to ask. Fortunately, in most cases, the necessary
configuration is already present. When clients get a response packet from the
local network’s DHCP server, there’s a “domain” parameter in that packet, and
it’s typically used as the client’s default DNS search domain. DNS-SD clients
also use it to discover their default DNS service discovery domain. So, in most
cases, all the required client configuration is already in place. What remains
is simply to add a few service discovery records to the authoritative name
server(s) for the domain given in the client’s DHCP configuration.

There are two ways to experiment with adding service discovery records to your
authoritative name server. If you have your own authoritative name server
already set up and running, you can just add the necessary records. A common use
of this is to facilitate Wide-Area AirPrint discovery. If you don’t already have
your own authoritative name server, or you do but don’t want to put the records
there just yet, then you can also set up a temporary test server to experiment
with the technology.

If you’re an end user and you don’t have access to a DNS server to experiment
with, you can still see Wide-Area Bonjour browsing in action just by entering an
appropriate DNS search domain.


SETTING UP DNS TO ALLOW CLIENTS TO ADVERTISE THEIR OWN WIDE-AREA SERVICES

After advertising static services to clients, the next step you can take, if you
choose, is to allow clients to advertise their own wide-area services.

Doing this is not zero configuration on the client side, for a couple of
security reasons. One is that users of client machines on your network may not
want their services advertised, potentially world-wide, without their knowledge
or consent. For this reason, advertising of services into the global DNS is an
option that has to be explicitly enabled by the client. In addition the client
needs to specify the domain into which they want their services advertised. On
the server side there’s also a security concern. On the world wide Internet, you
can’t allow just anyone to update your DNS server. This means that the clients
need to have cryptographic security credentials that establish their authority
to update the domain in question. This means that clients need three pieces of
configuration information:

 1. Whether or not dynamic update is enabled
 2. The name of the domain to update
 3. The security key to authorize those updates

Allowing clients to advertise services is a two-part task:

 1. You need to enable Dynamic Update on your DNS server.
 2. You need to install the Bonjour Preference Pane and configure the clients
    with the required information.


FURTHER INFORMATION

 * See the list of DNS SRV (RFC 2782) service types, and learn how to register a
   service type for your own protocol.

 * A Rendezvous with Java, Michael Brewer’s article about using DNS Service
   Discovery from Java code.

 * Wikiverse and Wikipedia entries.

 * DNS Service Discovery APIs for Ruby by Richard Kilmer and Chad Fowler.

 * Thomas Uram’s Bonjour interfaces for Python, which is actually a SWIG
   (Simplified Wrapper and Interface Generator) interface, so it supports a long
   list of languages.

 * Avahi is a fully LGPL framework for Multicast DNS Service Discovery on Linux.

 * Discovery (formerly Bonjour Browser) by Lily Ballard (TildeSoft).

 * Zero Configuration Networking: The Definitive Guide by Daniel Steinberg and
   Stuart Cheshire, published by O’Reilly Media.

 * What’s that Bonjour item in my Safari Collections?

 * Why is there a dot at the end of the hostname when I double-click a Bonjour
   Name in a web browser like Safari?

 * How can I find out more about how Sleep Proxy Service operates on the
   network?

 * Presto from Collobos Software is an AirPrint-compatible IPP print server that
   also implements enough of a DNS server to answer unicast DNS-SD queries for
   the print services it is offering, making it a Wide-Area AirPrint Server.
   This means that the printers it offers are visible to iOS AirPrint clients
   anywhere on a university or enterprise campus (and even remote clients
   connected via VPN), in contrast to conventional multicast-only AirPrint
   services, which are visible only to clients on the same local link.

--------------------------------------------------------------------------------

Page maintained by Stuart Cheshire