From e17c7afa722dc5b03118b4333cfbb5f692a527af Mon Sep 17 00:00:00 2001 From: Roland Hieber Date: Fri, 13 Dec 2013 20:37:06 +0100 Subject: [PATCH] sync: dns introduction --- dns-extensions.tex | 42 ++++++++++++++++++++++++++++-------------- xmpp.tex | 4 ++-- 2 files changed, 30 insertions(+), 16 deletions(-) diff --git a/dns-extensions.tex b/dns-extensions.tex index bf8bdc8..527545f 100644 --- 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 --- 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} -- 2.20.1