1 \subsection{Extensions to the Domain Name System
}\label{sec:dns
}
3 In a distributed context, it is often not feasible to rely on a central,
4 authoritative DNS server, and there is usually no easy way to discover services.
5 The first problem is addressed with
\term{Multicast DNS
}, and since DNS is
6 basically a key-value store, it can also be used for service discovery, which is
7 achieved using
\term{DNS-Based Service Discovery
}. Both techniques were first
8 developed by Apple as part of the
\term{Bonjour
}
9 project
\footnote{\url{https://developer.apple.com/bonjour/
}}, and are now
10 maintained by the IETF Zeroconf working
11 group
\footnote{\url{http://zeroconf.org
}}.
13 \subsubsection{Multicast DNS
}
15 \term{Multicast DNS
} (mDNS)~
\cite{rfc6762
} describes an extension to the Domain
16 Name System that allows DNS resource records to be distributed on multiple hosts
17 in a network, therefore avoiding central authorities and enabling every host to
18 publish its own entries. For that purpose, a special domain, usually
19 named
\code{.local
}, is used.
21 Software that supports mDNS listens on the reserved
22 link-local multicast address
\code{224.0.0.251} (for IPv4 queries) or
23 \code{FF02::FB
} (for IPv6 queries) on UDP port
5353 for incoming queries.
24 Queries sent to those multicast address and port are standard DNS queries.
25 If a host receives a query and knows about the queried resource, it responds to the
26 querying host with a standard DNS response. The querying host can then simply
27 finish and use the result, or wait until other hosts respond to its query. The
28 latter is typically the case when a record can have multiple values, as it is
29 the case with
\code{SRV
} and
\code{PTR
} records (which will be discussed in the
32 Another feature of Multicast DNS is the reduction of traffic through
33 \term{Known-Answer Suppression
}. It allows a querying host to specify already
34 known resources in its query when querying resources that could exist on more
35 than one host (e.~g., SRV records). The hosts matching those resources then do
36 not generate a response, thus reducing the messages in the network and saving
37 bandwidth, which is usually a scarce resource in wireless networks.
39 \enlargethispage{2\baselineskip}
40 Finally, hosts may also send unsolicited responses. This can be used to notify
41 the network of new services available on a host.
43 \subsubsection{DNS-Based Service Discovery
}\label{sec:dnssd
}
45 As another recent extension for the Domain Name System,
\term{DNS-Based Service
46 Discovery (DNS-SD)
}~
\cite{rfc6763
} uses DNS records of types
47 SRV~
\cite{rfc2782
} and PTR~
\cite{rfc1035
} in a way that allows hosts to browse
48 for services in a domain. While SRV records specify the location of services on
49 a host, PTR records hold a reverse mapping from IP address to host name.
50 DNS-SD now relies on a two-step process, consisting of
51 \term{Service Instance Enumeration
} and
\term{Service Instance Resolution
}.
53 \paragraph{1. Service Instance Enumeration
} At first, to enumerate the available
54 services in a domain for a given protocol, a DNS-SD-enabled client queries
55 PTR resources of the form
\code{\_service.
\_proto.domain
}. The result of
56 this query is then a list of
\term{instance names
} of the form
57 \code{name.
\_service.
\_proto.domain
} which point to the hosts providing the
58 service. For example, by querying for
\code{\_ipp.
\_tcp.
\_example.org
}, the
59 instance names for all printers supporting the IPP protocol in the domain
60 \code{example.org
} are returned.
62 \paragraph{2. Service Instance Resolution
} As a second step, the returned instance
63 names are resolved as SRV records to retrieve the actual host names and
64 port numbers of a service. For example, resolution of one instance name shows
65 that an IPP server is running at host
\code{gutenberg.example.org
} on port
5222.
66 Additionally, an optional TXT record with the same instance name can
67 contain further information about the service (e.~g. information about the
68 supported paper sizes).
70 Through the usage of SRV records, it is easily possible for a service to
71 inform clients about non-standard port numbers, and especially in connection
72 with Multicast DNS, this makes it easy to deploy decentralized systems for the
73 Internet of Things.
\cite{Klauck:
2012:BCC:
2352852.2352881}
75 % vim: set ft=tex et ts=2 sw=2 :