sync: dns introduction

diff --git a/dns-extensions.tex b/dns-extensions.tex
index bf8bdc8..527545f 100644 (file)
--- a/dns-extensions.tex
+++ b/dns-extensions.tex
@@ -1,20 +1,29 @@
-\subsection{Extensions to the DNS protocol}
+\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, and are now maintained
+by the IETF Zeroconf working group.
 
 \subsubsection{Multicast DNS}
 
-\term{Multicast DNS}~\cite{rfc6762} (mDNS) describes an extension of the Domain
+\term{Multicast DNS}~\cite{rfc6762} (mDNS) describes an extension to the Domain
 Name System that allows DNS resource records to be distributed on multiple hosts
-in a network, therefore avoiding the need of a central server.
+in a network, therefore avoiding central authorities and enabling every host to
+publish its own entries.
 
 Software that supports resolution of mDNS records 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, and
-if a host receiving a query knows about the queried resource, it responds to the
+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 querying for \code{SRV} records to obtain a
-list of services which are present in the network.
+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
@@ -29,8 +38,8 @@ the network of new services available on a host.
 
 \subsubsection{DNS-Based Service Discovery}\label{sec:dnssd}
 
-As a recent extension for the Domain Name System, \term{DNS-Based Service
-Discovery (DNS-SD)}~\cite{rfc6763} uses DNS records of type
+As another recent extension for the Domain Name System, \term{DNS-Based Service
+Discovery (DNS-SD)}~\cite{rfc6763} uses DNS records of types
 \code{SRV}~\cite{rfc2782} and \code{PTR} in a way that allows hosts to browse
 for services in a domain. As an example, Figure~\ref{fig:dnssd} shows the
 process of browsing for all XMPP clients in the domain \code{example.org}.
@@ -40,7 +49,8 @@ and \term{Service Instance Resolution}.
 \begin{figure}[htop]
   \centering
   \includegraphics[width=0.9\textwidth]{dnssd-mock.jpg}
-  \caption{DNS-SD: Service Instance Enumeration and Resolution}
+  \caption{DNS-SD: Service Instance Enumeration and Resolution
+    \todo[XMPP is a bad example here, use IPP]}
   \label{fig:dnssd}
 \end{figure}
 
@@ -49,14 +59,18 @@ services in a domain for a given protocol, a DNS-SD-enabled client queries
 resources of type \code{PTR} 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 provide the specified service. For
-example, in Figure~\ref{fig:dnssd}, all XMPP clients in the domain
-\code{example.org} are enumerated, and as a result, the instance names of three
-hosts are returned.
+example, in Figure~\ref{fig:dnssd}, by querying for
+\code{\_ipp.\_tcp.\_example.org}, all printers supporting the IPP protocol in the
+domain \code{example.org} are enumerated, and as a result, the instance names of
+three hosts are returned.
 
 \paragraph{Service Instance Resolution} As a second step, the returned instance
 names are resolved as \code{SRV} records to retrieve the actual host names and
 port numbers of a service. In the example, resolution of one instance name shows
-that an XMPP client is running at host \code{juliet.example.org} on port 5222.
+that an IPP server is running at host \code{gutenberg.example.org} on port 5222.
+Additionally, an optional \code{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 \code{SRV} records, it is easily possible for a service to
 inform clients about non-standard port numbers, and especially in connection

diff --git a/xmpp.tex b/xmpp.tex
index 44f16b0..c37175a 100644 (file)
--- a/xmpp.tex
+++ b/xmpp.tex
@@ -22,10 +22,10 @@ the resource is only needed for routing between client and server.
 \subsubsection{Architecture}
 \begin{wrapfigure}{r}{0.4\textwidth}
 %\begin{figure}[htop]
-  \label{fig:xmpparch}
   \centering
   \includegraphics[width=0.4\textwidth]{xmpp-architecture-mock.jpg}
   \caption{XMPP architecture}
+  \label{fig:xmpparch}
 %\end{figure}
 \end{wrapfigure}
 
@@ -68,7 +68,7 @@ other side then has the chance to send all outstanding stanzas and likewise
 closes its stream. If both streams are closed, the underlying TCP connection is
 terminated.
 
-\todo{Example stream}
+\todo[Example stream]
 
 \subsubsection{Multi-User Chats}