\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.
+publish its own entries. For that purpose, a special top-level domain, is used,
+usually named \code{.local}, which contains those entries.
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.
+\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.
+the case with \code{SRV} and \code{PTR} records (which will be discussed in the
+next section).
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
+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.
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
+SRV~\cite{rfc2782} and PTR~\cite{rfc1035} in a way that allows hosts to browse
+for services in a domain. While SRV records specify the location of services on
+a host, PTR records hold a reverse mapping from IP address to host name.
+DNS-SD now relies on a two-step process, consisting of
\term{Service Instance Enumeration} and \term{Service Instance Resolution}.
-%\todo{XMPP is a probably not the best example here, use IPP instead}
-%\begin{subfigure} \end{subfigure} \begin{figure}[top] \centering
-%\includegraphics[width=0.9\textwidth]{fig-dnssd-mock.jpg} \caption{DNS-SD:
-%Service Instance Enumeration and Resolution} \label{fig:dnssd} \end{figure}
\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
projects / skm-ma-ws1314.git / blobdiff