\subsection{Extensions to the Domain Name System}\label{sec:dns}

In a distributed context, it is often not feasible to rely on a central,
authoritative DNS server, and there is usually no easy way to discover services.
The first problem is addressed with \term{Multicast DNS}, and since DNS is
basically a key-value store, it can also be used for service discovery, which is
achieved using \term{DNS-Based Service Discovery}. Both techniques were first
developed by Apple as part of the \term{Bonjour}
project\footnote{\url{https://developer.apple.com/bonjour/}}, and are now
maintained by the IETF Zeroconf working
group\footnote{\url{http://zeroconf.org}}.

\subsubsection{Multicast DNS}

\term{Multicast DNS} (mDNS)~\cite{rfc6762} describes an extension to the Domain
Name System that allows DNS resource records to be distributed on multiple hosts
in a network, therefore avoiding central authorities and enabling every host to
publish its own entries. For that purpose, a special domain, usually
named \code{.local}, is used.

Software that supports mDNS listens on the reserved
link-local multicast address \code{224.0.0.251} (for IPv4 queries) or
\code{FF02::FB} (for IPv6 queries) on UDP port 5353 for incoming queries.
Queries sent to those multicast address and port are standard DNS queries.
If a host receives a query and knows about the queried resource, it responds to the
querying host with a standard DNS response. The querying host can then simply
finish and use the result, or wait until other hosts respond to its query. The
latter is typically the case when a record can have multiple values, as it is
the case with \code{SRV} and \code{PTR} records.

Another feature of Multicast DNS is the reduction of traffic through
\term{Known-Answer Suppression}. It allows a querying host to specify already
known resources in its query when querying resources that could exist on more
than one host (e.~g., SRV records). The hosts matching those resources then do
not generate a response, thus reducing the messages in the network and saving
bandwidth, which is usually a scarce resource in wireless networks.

\enlargethispage{2\baselineskip}
Finally, hosts may also send unsolicited responses. This can be used to notify
the network of new services available on a host.

\subsubsection{DNS-Based Service Discovery}\label{sec:dnssd}

As another recent extension for the Domain Name System, \term{DNS-Based Service
Discovery (DNS-SD)}~\cite{rfc6763} uses DNS records of types
SRV~\cite{rfc2782} and PTR in a way that allows hosts to browse
for services in a domain. This is a two-step process, consisting of
\term{Service Instance Enumeration} and \term{Service Instance Resolution}.

\paragraph{1. Service Instance Enumeration} At first, to enumerate the available
services in a domain for a given protocol, a DNS-SD-enabled client queries
PTR resources of the form \code{\_service.\_proto.domain}. The result of
this query is then a list of \term{instance names} of the form
\code{name.\_service.\_proto.domain} which point to the hosts providing the
service. For example, by querying for \code{\_ipp.\_tcp.\_example.org}, the
instance names for all printers supporting the IPP protocol in the domain
\code{example.org} are returned.

\paragraph{2. Service Instance Resolution} As a second step, the returned instance
names are resolved as SRV records to retrieve the actual host names and
port numbers of a service. For example, resolution of one instance name shows
that an IPP server is running at host \code{gutenberg.example.org} on port 5222.
Additionally, an optional TXT record with the same instance name can
contain further information about the service (e.~g. information about the
supported paper sizes).

Through the usage of SRV records, it is easily possible for a service to
inform clients about non-standard port numbers, and especially in connection
with Multicast DNS, this makes it easy to deploy decentralized systems for the
Internet of Things. \cite{Klauck:2012:BCC:2352852.2352881}

% vim: set ft=tex et ts=2 sw=2 :
