organization="Internet Engineering Task Force",
year=1997,
month=mar,
- note="Updated by RFCs 3396, 4361, 5494, 6842",
url="http://www.ietf.org/rfc/rfc2131.txt",
}
+
+@misc{rfc1035,
+ author="P.V. Mockapetris",
+ title="{Domain names - implementation and specification}",
+ series="Request for Comments",
+ number="1035",
+ howpublished="RFC 1035 (INTERNET STANDARD)",
+ publisher="IETF",
+ organization="Internet Engineering Task Force",
+ year=1987,
+ month=nov,
+ url="http://www.ietf.org/rfc/rfc1035.txt",
+}
+
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
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}.
\paragraph{1. Service Instance Enumeration} At first, to enumerate the available