%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Legal Notice                            %
%                                                               %
% This document is copyright (C) Olaf Kirch, okir@monad.swb.de  %
%                                                               %
% For copying conditions, please refer to the file COPYING.	%
%                                                               %
% The author is not liable for any damages, direct or indirect, %
% resulting from the use of information provided in this        %
% document.                                                     %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% When viewing this document with vi on an 80-columns screen,   %
% do a ':se nonumber' first.                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%               S T A R T   O F   C H A P T E R                 %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Name Service and Resolver Configuraton}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Configure named and resolver lib                              %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{resolv}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{resolv.intro}
\index{configuring!hostname resolution|(}
\index{hostname!resolution}

As discussed in chapter~\ref{tcpip}, TCP/IP networking may rely on
different schemes to convert names into addresses.  The simplest way,
which takes no advantage of the way the name space has been split up
into zones is a host table stored in \file{/etc/hosts}.  This is
useful only for small LANs that are run by one single administrator,
and otherwise have no IP~traffic with the outside world.  The format
of the \file{hosts} file has already been described in
chapter~\ref{iface}.


\index{Berkeley Internet Name Domain}
\index{BIND}
\index{named@\prog{named}}
Alternatively, you may use BIND~-- the Berkeley Internet Name Domain
Service~--  for resolving host names to IP~addresses.  Configuring BIND
may be a real chore, but once you've done it, changes in the network
topology are easily made. On \linux, as on many other \unix{}ish
systems, name service is provided through a program called \prog{named}.
At startup, it loads a set of  master files into its cache, and waits
for queries from remote or local user processes. There are different
ways to set up BIND, and not all require you to run a name server on
every host.


This chapter can do little more but give a rough sketch of how to
operate a name server. If you plan to use BIND in an enviroment with
more than just a small LAN and probably an Internet uplink, you should
get a good book on BIND, for instance Cricket Liu's ``DNS and BIND''
(see \cite{liu-dns}). For current information, you may also want to
check the release notes contained in the BIND sources. There's also a
newsgroup for DNS questions called \ngrp{comp.protocols.tcp-ip.domains}.


\section{The Resolver Library}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{resolv.library}
\index{resolver!library}

When talking of ``the resolver'', we do not mean any special
application, but rather refer to the \emph{resolver library}, a
collection of functions that can be found in the standard C library. The
central routines are \func{gethostbyname(2)} and \func{gethostbyaddr(2)}
which look up all IP addresses belonging to a host, and vice versa.
They may be configured to simply look up the information in
\file{hosts}, query a number of name servers, or use the \file{hosts}
database of NIS (Network Information Service).  Other applications, like
\prog{smail}, may include different drivers for any of these, and need
special care.


\subsection{The \file{host.conf} File}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{resolv.host-conf}
\index{resolver!using NIS}
\index{resolver!using a name server}
\index{resolver!configuring|(}
\index{host.conf@\file{host.conf}}

The central file that controls your resolver setup is \file{host.conf}.
It resides in \file{/etc} and tells the resolver which services
to use, and in what order.

Options in \file{host.conf} must occur on separate lines. Fields may be
separated by white space (spaces or tabs). A hash sign (\keyword{\#})
introduces a comment that extends to the next newline.

The following options are available:
\begin{dispitems}
\ditem[\keyword{order}]
        \index{NIS!and the resolver}
        \index{order of resolver services used}
        This determines the order in which the resolving services are
        tried. Valid options are \keyword{bind} for querying the name
        server, \file{hosts} for lookups in \file{/etc/hosts}, and
        \keyword{nis} for NIS lookups.  Any or all of them may be
        specified. The order in which they appear on the line detemines
        the order in which the respective services are tried.


\ditem[\keyword{multi}]
        Takes \keyword{on} or \keyword{off} as options. This detemines
        if a host in \file{/etc/hosts} is allowed to have several
        IP~addresses, which is usually referred to as being
        ``multi-homed''. This flag has no effect on DNS or NIS queries.

\ditem[\keyword{nospoof}]
        \index{security!false hostnames}
        \index{security!spoofing}
        \index{prevent spoofing}
        \index{spoofing}
        As explained in the previous chapter, DNS allows you to find the
        hostname belonging to an IP~address by using the
        \host{in-addr.arpa} domain. Attempts by name servers to supply a
        false hostname are called ``\emph{spoofing}''. To guard against
        this, the resolver may be configured to check if the original
        IP~address is in fact associated with the hostname obtained. If
        not, the name is rejected and an error returned. This behavior
        is turned on by setting \keyword{nospoof on}.

\ditem[\keyword{alert}]
        This option takes \keyword{on} or \keyword{off} as arguments.
        If it is turned on, any spoof attempts (see above) will cause
        the resolver to log a message to the \prog{syslog} facility.

\ditem[\keyword{trim}]
        This option takes a domain name as an argument, which will be
        removed from hostnames before lookup. This is useful for
        \file{hosts} entries, where you might only want to specify
        hostnames without local domain.  A lookup of a host with the
        local domain name appended will have this removed, thus allowing
        the lookup in \file{/etc/hosts} to succeed.

        \keyword{trim} options accumulate, making it possible to consider 
        your host as being local to several domains.
\end{dispitems}

A sample file for \host{vlager} is shown below:

\begin{tscreen}
\begin{verbatim}
# /etc/host.conf
# We have named running, but no NIS (yet)
order   bind hosts
# Allow multiple addrs
multi   on
# Guard against spoof attempts
nospoof on
# Trim local domain (not really necessary).
trim    vbrew.com.
\end{verbatim}
\end{tscreen}


\subsection{Resolver Environment Variables}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{resolv.environ}
\index{resolver!environment variables}

The settings from \file{host.conf} may be overridden using a number
of environment variables. These are

\begin{dispitems}
\ditem[\shellvar{RESOLV\_HOST\_CONF}]
        This specifies a file to be read instead of \file{/etc/host.conf}.

\ditem[\shellvar{RESOLV\_SERV\_ORDER}]
        Overrides the \keyword{order} option given in \file{host.conf}.
        Services are given as \keyword{hosts}, \keyword{bind}, and
        \keyword{nis}, separated by a space, comma, colon, or semicolon.

\ditem[\shellvar{RESOLV\_SPOOF\_CHECK}]
        Determines the measures taken against spoofing. It is completely
        disabled by \keyword{off}.  The values \keyword{warn} and
        \keyword{warn off} enable spoof checking, but turn logging on
        and off, respectively. A value of \keyword{*} turns on spoof
        checks, but leaves the logging facility as defined in
        \file{host.conf}.

\ditem[\shellvar{RESOLV\_MULTI}]
        A value of \keyword{on} or \keyword{off} may be used to override the \keyword{multi}
        options from {tt host.conf}.

\ditem[\shellvar{RESOLV\_OVERRIDE\_TRIM\_DOMAINS}]
        This environment specifies a list of trim domains which override
        those given in \file{host.conf}.

\ditem[\shellvar{RESOLV\_ADD\_TRIM\_DOMAINS}]
        This environment specifies a list of trim domains which are added
        to those given in \file{host.conf}.

\end{dispitems}


\subsection{Configuring Name Server Lookups~--- \file{resolv.conf}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{resolv.resolv}
\index{configuring!use of name server}
\index{resolv.conf@\file{resolv.conf}}

When configuring the resolver library to use the BIND name service for
host lookups, you also have to tell it which name servers to use.
There is a separate file for this, called \file{resolv.conf}.
If this file does not exist or is empty, the resolver assumes the
name server is on your local host.


If you run a name server on your local host, you have to set it up
separately, as will be explained in the following section.
If your are on a local network and have the opportunity to use an
existing nameserver, this should always be preferred.


The most important option in \file{resolv.conf} is \keyword{nameserver},
which gives the IP~address of a name server to use. If you specifiy
several name servers by giving the \keyword{nameserver} option several
times, they are tried in the order given. You should therefore put the
most reliable server first.  Currently, up to three name servers are
supported.


If no \keyword{nameserver} option is given, the resolver attempts
to connect to the name server on the local host.


\index{domain name!default}
\index{configuring!default domain}
Two other options, \keyword{domain} and \keyword{search} deal with default
domains that are tacked onto a hostname if BIND fails to resolve it
with the first query. The \keyword{search} option specifies a list of
domain names to be tried. The list items are separated by spaces
or tabs.


If no \keyword{search} option is given, a default search list is constructed
from the local domain name by using the domain name itself, plus all
parent domains up to the root. The local domain name may be given using
the \keyword{domain} statement; if none is given, the resolver obtains
it through the \func{getdomainname(2)} system call.


\noindent
If this sounds confusing to you, consider this sample \file{resolv.conf}
file for the Virtual Brewery:


\begin{tscreen}
\begin{verbatim}
# /etc/resolv.conf
# Our domain
domain         vbrew.com
#
# We use vlager as central nameserver:
nameserver     191.72.1.1
\end{verbatim}
\end{tscreen}


When resolving the name \host{vale}, the resolver would look up
\host{vale}, and failing this, \host{vale.vbrew.com}, and
\host{vale.com}.



\subsection{Resolver Robustness}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{resolv.robustness}
\index{resolver!robustness}

If you are running a LAN inside a larger network, you definitely should
use central name servers if they are available. The advantage of this is
that these will develop rich caches, since all queries are forwarded to
them. This scheme, however has a drawback: when a fire recently
destroyed the backbone cable at our university, no more work was
possible on our department's LAN, because the resolver couldn't reach
any of the name servers anymore. There was no logging in on X~terminals
anymore, no printing, etc.


Although it is not very common for campus backbones to go down in 
flames, one might want to take precautions against cases like these.


One option is to set up a local name server that resolves hostnames from
your local domain, and forwards all queries for other hostnames to the
main servers. Of course, this is applicable only if you are running
your own domain.


Alternatively, you can maintain a backup host table for your domain
or LAN in \file{/etc/hosts}. In \file{/etc/host.conf} you would then
include ``\keyword{order bind hosts}'' to make the resolver fall
back to the hosts file if the central name server is down.


\index{resolver!configuring|)}


\section{Running \prog{named}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{resolv.named}
\index{named@\prog{named}|(}
\index{name server!configuring|(}
\index{configuring!name server|(}
\index{DNS!configuring server|(}
\index{BIND|(}

The program that provides domain name service on most \unix{} machines is
usually called \prog{named} (pronounced \emph{name-dee}). This is a
server program originally developed for BSD providing name service to
clients, and possibly to other name servers. The version currently 
used on most \linux{} installations seems to be BIND-4.8.3. The new
version, BIND-4.9.3, is being Beta-tested at the moment, and should be
available on \linux{} soon.

This section requires some understanding of the way the Domain Name
System works. If the following discussion is all Greek to you, you may
want to re-read chapter~\ref{tcpip}, which has some more information
on the basics of DNS.


\index{named.boot@\file{named.boot}|(}
\prog{named} is usually started at system boot time, and runs until
the machine goes down again.  It takes its information from a
configuration file called \prog{/etc/named.boot}, and various files
that contain data mapping domain names to addresses and the like. The
latter are called \emph{zone files}.  The formats and semantics of
these files will be explained in the following section.


To run \prog{named}, simply enter 

\begin{tscreen}
\# /usr/sbin/named
\end{tscreen}


\noindent
at the prompt. \prog{named} will come up, read the \prog{named.boot}
file and any zone files specified therein. It writes its process id to
\file{/var/run/named.pid} in ASCII, downloads any zone files from primary
servers, if necessary, and starts listening on port 53 for DNS
queries.\footnote{
 There are various \prog{named} binaries floating around \linux{} FTP
 sites, each configured a little differently. Some have their pid file
 in \file{/etc}, some store it in \file{/tmp} or \file{/var/tmp}.
}



\subsection{The \file{named.boot} File}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The \prog{named.boot} file is generally very small and contains little
else but pointers to master files containing zone information, and
pointers to other name servers.  Comments in the boot file start with a
semicolon and extend to the next newline.
Before we discuss the format of \file{named.boot} in more detail, we
will take a look at the sample file for \host{vlager} given in
figure~\ref{resolv.fig.named.boot}.\footnote{
 Note that the domain names in this example are given \emph{without}
 trailing dot. Earlier versions of \prog{named} seem to treat trailing
 dots in \prog{named.boot} as an error, and silently discards the
 line. BIND-4.9.3 is said to fix this.
}


\begin{figure}[htbp]
\begin{tscreen}
\begin{verbatim}
;
; /etc/named.boot file for vlager.vbrew.com
;
directory     /var/named
;
;             domain                   file
;---------------------------------------------------
cache         .                        named.ca
primary       vbrew.com                named.hosts
primary       0.0.127.in-addr.arpa     named.local
primary       72.191.in-addr.arpa      named.rev
\end{verbatim}
\end{tscreen}
 \caption{
  \label{resolv.fig.named.boot}
  The \prog{named.boot} file for \file{vlager}.
 }
\end{figure}


The \keyword{cache} and \keyword{primary} commands shown in this
example load information into \prog{named}. This information is taken
from the master files specified in the second argument. They contain
textual representations of DNS resource records, which we will look at
below.


In this example, we configured \prog{named} as the primary name server
for three domains, as indicated by the \keyword{primary} statements
at the end of the file. The first of these lines, for instance, instructs
\prog{named} to act as a primary server for \host{vbrew.com}, taking the
zone data from the file \file{named.hosts}. The \keyword{directory}
keyword tells it that all zone files are located in \file{/var/named}.


The \keyword{cache} entry is very special and should be present on
virtually all machines running a name server. Its function is
two-fold: it instructs \prog{named} to enable its cache, and to load
the \emph{root name server hints} from the cache file specified
(\file{named.ca} in our example). We will come back to the name server
hints below.


Here's a list of the most important options you can use in
\file{named.boot}:

\begin{dispitems}
\ditem[\keyword{directory}] 
        This specifies a directory in which zone files reside.
        Names of files may be given relative to this directory.
        Several directories may be specified by repeatedly using
        \keyword{directory}. According to the \linux{} filesystem
        standard, this should be \file{/var/named}.

\ditem[\keyword{primary}]
        \index{primary (BIND option)@\keyword{primary} (BIND option)}
        \index{name server!primary}
        This takes a \var{domain name} and a \var{file name} as an
        argument, declaring the local server authoritative for the named
        domain. As a primary server, \prog{named} loads the zone
        information from the given master file.

        Generally, there will always be at least one \keyword{primary}
        entry in every boot file, namely for reverse mapping of network
        \host{127.0.0.0}, which is the local loopback network.

\ditem[\keyword{secondary}]
        \index{secondary (BIND option)@\keyword{secondary} (BIND option)}
        \index{name server!secondary}
        This statement takes a \var{domain name}, an \var{address
        list}, and a \var{file name} as an argument. It declares the
        local server a secondary master server for the domain specified.

        A secondary server holds authoritative data on the domain,
        too, but it doesn't gather it from files, but tries
        to download it from the primary server. The IP~address of
        at least one primary server must thus be given to
        \prog{named} in the address list. The local server will
        contact each of them in turn until it successfully transfers
        the zone database, which is then stored in the backup file
        given as the third argument.
        If none of the primary servers responds, the zone data is
        retrieved from the backup file instead.

        \prog{named} will then attempt to refresh the zone data
        at regular intervals. This is explained below along in
        connection with the SOA resource record type.

\ditem[\keyword{cache}]
        \index{cache (BIND option)@\keyword{cache} (BIND option)}
        \index{name server!cache}
        This takes a \var{domain} and a \var{file name} as arguments.
        This file contains the root server hints, that is a list of
        records pointing to the root name servers. Only NS and A
        records will be recognized. The \var{domain}
        argument is generally the root domain name ``\keyword{.}''.

	This information is absolutely crucial to \prog{named}:
        if the \keyword{cache} statement does not occur in the boot
        file, \prog{named} will not develop a local cache at all. This
        will severely degrade performance and increase network load if
        the next server queried is not on the local net. Moreover, 
        \prog{named} will not be able to reach any root name servers,
        and thus it won't resolve any addresses except those it is authoritative
        for. An exception from this rule is when using forwarding
        servers (cf. the \keyword{forwarders} option below).

\ditem[\keyword{forwarders}]
        This statement takes an \var{address list} as an argument.
        The IP~addresses in this list specify a list of name servers
        that \prog{named} may query if it fails to resolve a
        query from its local cache. They are tried in order until
        one of them responds to the query.

\ditem[\keyword{slave}]
        \index{name server!slave}
        This statement makes the name server a \emph{slave} server. That
        is, it will never perform recursive queries itself, but only
        forwards them to servers specified with the \keyword{forwarders}
        statement.

\end{dispitems}


There are two options which we will not describe here, being
\keyword{sortlist} and \keyword{domain}.  Additionally, there are two
directives that may be used inside the zone database files. These are
\keyword{\$INCLUDE} and \keyword{\$ORIGIN}.  Since they are rarely
needed, we will not describe them here, either.

% 
% The \keyword{\$ORIGIN} command may be used to alter the origin of
% the current file. Generally it is only used by \prog{named} itself
% when dumping its cache into a single file; you usually don't use it
% in the master files itself. Its format is
% \begin{screen}\st
% \$ORIGIN \sl domain
% \end{screen}
% where \var{domain} is an absolute domain name.
% 
% 
% The \keyword{\$INCLUDE} statement includes other files into
% the current file. Its syntax is
% \begin{screen}\st
% \$INCLUDE \var{file} [\var{domain}]
% \end{screen}
% where \var{file} is the name of the file to be included. File names
% without a leading slash (`\file{/}') are taken to be relative to one of
% the directories named in a \keyword{directory} statements in the boot file.
% The optional \var{domain} argument may be used to set the origin
% for the included file. It is equivalent to placing an \keyword{\$ORIGIN}
% directive in the first line of the included file. Note that
% \keyword{\$ORIGIN} statements inside the included file
% do not alter the origin of the including file.

\index{named.boot@\file{named.boot}|)}


\subsection{The DNS Database Files}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Master files included by \prog{named}, like \prog{named.hosts}, always
have a domain associated with them, which is called the \emph{origin}.
This is the domain name specified with the \keyword{cache} and
\keyword{primary} commands. Within a master file, you are allowed to
specify domain and host names relative to this domain.  A name given in
a configuration file is considered \emph{absolute} if it ends in a single
dot, otherwise it is considered relative to the origin.  The origin all
by itself may be referred to using ``\keyword{@}''.


\index{DNS!resource record}
All data contained in a master file is split up in \emph{resource
records}, or RRs for short. They make up the smallest unit of
information available through DNS. Each resource record has a type. A
records, for instance, map a hostname to an IP~address, and a CNAME
record associates an alias for a host with its official hostname. As
an example, take a look at figure~\ref{resolv.fig.named.hosts} on
page~\pageref{resolv.fig.named.hosts}, which shows the
\prog{named.hosts} master file for the virtual brewery.


Resource record representations in master files share a
common format, which is

\begin{screen}\st
[\var{domain}] [\var{ttl}\/] [\var{class}] \var{type} \var{rdata}
\end{screen}

Fields are separated by spaces or tabs. An entry may be continued
across several lines if an opening brace occurs before the first newline,
and the last field is followed by a closing brace. Anything
between a semicolon and a newline is ignored.


\begin{dispitems}
\ditem[\var{domain}]
        This is the domain name to which the entry applies. If no domain
        name is given, the RR is assumed to apply to the domain of the
        previous RR.

\ditem[\var{ttl}]
        \index{DNS!time to live}
        In order to force resolvers to discard information after a
        certain time, each RR is associated a ``\emph{time to live}'', or
        \emph{ttl} for short. The \var{ttl} field specifies the time in
        seconds the information is valid after it has been retrieved
        from the server. It is a decimal number with at most eight
        digits.

        If no \var{ttl} value is given, it defaults to the value of the
        \var{minimum} field of the preceding SOA record.

\ditem[\var{class}]
        This is an address class, like IN for IP~addresses, or HS for
        objects in the Hesiod class. For TCP/IP networking, you have to
        make this IN.

        If no \var{class} field is given, the class of the preceding RR
        is assumed.

\ditem[\var{type}]
        This describes the type of the RR. The most common types are A,
        SOA, PTR, and NS.  The following sections describe the various
        types of RR's.

\ditem[\var{rdata}]
        This holds the data associated with the RR. The format of this
        field depends on the type of the RR. Below, it will be described
        for each RR separately.

\end{dispitems}


\bigskip\noindent
The following is an incomplete list of RRs to be used in DNS master
files. There are a couple more of them, which we will not explain.
They are experimental, and of little use generally.

\begin{dispitems}
\ditem[SOA]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{authoritative name server}
\index{SOA (DNS record)}
\index{DNS!zone}

This describes a zone of authority (SOA means ``Start of
Authority''). It signals that the records following the SOA
RR contain authoritative information for the domain. Every master file
included by a \keyword{primary} statement must contain an SOA
record for this zone. The resource data contains the following fields:


\begin{dispitems}
\ditem[\var{origin}]
        This is the canonical hostname of the primary name server
        for this domain. It is usually given as an absolute name.

\ditem[\var{contact}]
        This is the email address of the person responsible for
        maintaining the domain, with the `\keyword{@}' character
        replaced by a dot. For instance, if the responsible person at
        the Virtual Brewery is \user{janet}, then this field would
        contain \keyword{janet.vbrew.com}.

\ditem[\var{serial}]
        This is the version number of the zone file, expressed as a
        single decimal number. Whenever data is changed in the zone
        file, this number should be incremented.

        The serial number is used by secondary name servers to recognize
        when zone information has changed. To stay up to date, secondary
        servers request the primary server's SOA record at certain
        intervals, and compare the serial number to that of the cached
        SOA record.  If the number has changed, the secondary servers
        transfers the whole zone database from the primary server.

\ditem[\var{refresh}]
        This specifies the interval in seconds that the secondary
        servers should wait between checking the SOA record of the
        primary server. Again, this is a decimal number with at most
        eight digits.

        Generally, the network topology doesn't change too often, so
        that this number should specify an interval of roughly a day for
        larger networks, and even more for smaller ones.

\ditem[\var{retry}]
        This number determines the intervals at which a secondary
        server should retry contacting the primary server if
        a request or a zone refresh fails. It must not be too low,
        or else a temporary failure of the server or a network problem
        may cause the secondary server to waste network resources.
        One hour, or perhaps one half hour, might be a good choice.

\ditem[\var{expire}]
        This specifies the time in seconds after which the server should
        finally discard all zone data if it hasn't been able to contact
        the primary server. It should normally be very large.  Craig
        Hunt (\cite{hunt-tcpip}) recommends 42~days.

\ditem[\var{minimum}]
        This is the default ttl value for resource records that do not
        explicitly specify one. This requires other name servers to
        discard the RR after a certain amount of time.  It has however
        nothing to do with the time after which a secondary server tries
        to update the zone information.

        \var{minimum} should be a large value, especially for LANs where
        the network topology almost never changes.  A value of around a
        week or a month is probably a good choice. In the case that
        single RRs may change more frequently, you can still assign them
        different ttl's.

\end{dispitems}


\ditem[A]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{A (DNS record)}
\index{address!DNS resource record}

This associates an IP~address with a hostname. The resource data field
contains the address in dotted quad notation.

\index{hostname!canonical}
\index{canonical hostname}
\index{CNAME (DNS record)}
\index{hostname!aliases}
\index{alias!hostname}
For each host, there must be only one A record. The hostname used in
this A record is considered the official or \emph{canonical} hostname.
All other hostnames are aliases and must be mapped onto the canonical
hostname using a CNAME record.



\ditem[NS]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

This points to a master name server of a subordinate zone. For an
explanation why one has to have NS records, see section~\ref{tcpip.dns}.
The resource data field contains the hostname of the name server. To
resolve the hostname, an additional A record is needed, the so-called
\emph{glue record} which gives the name server's IP~address.


\ditem[CNAME]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{CNAME (DNS record)}

This associates an alias for a host with its \emph{canonical hostname}.
The canonical hostname is the one the master file provides an A record
for; aliases are simply linked to that name by a CNAME record, but don't
have any other records of their own.


\ditem[PTR]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{PTR (DNS record)}

This type of record is used to associate names in the \host{in-addr.arpa}
domain with hostnames. This is used for reverse mapping of IP~addresses
to hostnames. The hostname given must be the canonical hostname.


\ditem[MX]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{MX (DNS record)}

This RR announces a \emph{mail exchanger} for a domain. The reasons to
have mail exchangers are discussed in section~\ref{mail.routing.internet}
in chapter~\ref{mail}.  The syntax of an MX record is


\begin{screen}\st
[\var{domain}] [\var{ttl}] [\var{class}] MX \var{preference} \var{host}
\end{screen}


\var{host} names the mail exchanger for \var{domain}. Every
mail exchanger has an integer \var{preference} associated with it.
A mail transport agent who desires to deliver mail to \var{domain}
will try all hosts who have an MX record for this domain
until it succeeds. The one with the lowest preference value is
tried first, then the others in order of increasing preference
value.


% \ditem[WKS]
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% This RR advertises \emph{well known services} offered by the host.
% The syntax is
% \begin{screen}\st
% [\var{domain}] [\var{ttl}] [\var{class}] WKS \var{address protocol services}
% \end{screen}
% 
% 
% \var{address} is the host's IP~address written in dotted quad notation.
% The protocol used by the services, which must either be TCP or UDP
% for the IN class,
% is named in the \var{protocol} field. There may be only one
% WKS record per protocol. Finally, \var{services} is a list of
% service names as found in the \file{/etc/services} file (see
% section~\ref{appl.services}). The service names are separated
% by blanks or tabs, and may be continued across newlines using
% braces.


\ditem[HINFO]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
This record provides information on the system's hardware
and software. Its syntax is


\begin{screen}\st
[\var{domain}] [\var{ttl}] [\var{class}] HINFO \var{hardware software}
\end{screen}


The \var{hardware} field identifies the hardware used by this host.
There are special conventions to specify this. A list of valid names is
given in the ``Assigned Numbers'' (RFC~1340). If the field contains any
blanks, it must be enclosed in double quotes.  The \var{software} field
names the operating system software used by the system. Again, a valid
name from the ``Assigned Numbers'' RFC should be chosen.
\end{dispitems}


\subsection{Writing the Master Files}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Figures~\ref{resolv.fig.named.cache}, \ref{resolv.fig.named.hosts},
\ref{resolv.fig.named.local}, and \ref{resolv.fig.named.rev} give sample
files for a name server at the brewery, located on \file{vlager}. Owing
to the nature of the network discussed (a single LAN), the example is
pretty straightforward.  If your requirements are more complex, and you
can't get \prog{named} going, get ``DNS and BIND'' by Cricket Liu and
Paul Albitz (\cite{liu-dns}).


\index{DNS!root name servers}
\index{name server!root}
The \file{named.ca} cache file shown in figure~\ref{resolv.fig.named.cache}
shows sample hint records for a root name server. A typical cache file
usually describes about a dozen name servers, or so. You can obtain the
current list of name servers for the root domain using the \prog{nslookup}
tool described toward the end of this chapter.\footnote{
 Note that you can't query your name server for the root servers if
 you don't have any root server hints installed: Catch~22! To escape
 this dilemma, you can either make \prog{nslookup} use a different name
 server, or you can use the sample file in
 figure~\ref{resolv.fig.named.cache} as a starting point, and then
 obtain the full list of valid servers.
}


\begin{figure}[htbp]
\begin{tscreen}
\begin{verbatim}
;
; /var/named/named.ca          Cache file for the brewery.
;                We're not on the Internet, so we don't need
;                any root servers. To activate these
;                records, remove the semicolons.
;
; .                99999999   IN    NS  NS.NIC.DDN.MIL
; NS.NIC.DDN.MIL   99999999   IN    A   26.3.0.103
; .                99999999   IN    NS  NS.NASA.GOV
; NS.NASA.GOV      99999999   IN    A   128.102.16.10
\end{verbatim}
\end{tscreen}
 \caption{
  \label{resolv.fig.named.cache}
  The \prog{named.ca} file.
 }
\end{figure}


\begin{figure}[htbp]
\begin{tscreen}
\begin{verbatim}
;
; /var/named/named.hosts       Local hosts at the brewery
;                               Origin is vbrew.com
;
@                   IN  SOA   vlager.vbrew.com. (
                              janet.vbrew.com.
                              16         ; serial
                              86400      ; refresh: once per day
                              3600       ; retry:   one hour
                              3600000    ; expire:  42 days
                              604800     ; minimum: 1 week
                              )
                    IN  NS    vlager.vbrew.com.
;
; local mail is distributed on vlager
                    IN  MX    10 vlager
;
; loopback address
localhost.          IN  A     127.0.0.1
; brewery Ethernet
vlager              IN  A     191.72.1.1
vlager-if1          IN  CNAME vlager
; vlager is also news server
news                IN  CNAME vlager
vstout              IN  A     191.72.1.2
vale                IN  A     191.72.1.3
; winery Ethernet
vlager-if2          IN  A     191.72.2.1
vbardolino          IN  A     191.72.2.2
vchianti            IN  A     191.72.2.3
vbeaujolais         IN  A     191.72.2.4
\end{verbatim}
\end{tscreen}
 \caption{
  \label{resolv.fig.named.hosts}
  The \prog{named.hosts} file.
 }
\end{figure}


\begin{figure}[htbp]
\begin{tscreen}
\begin{verbatim}
;
; /var/named/named.local       Reverse mapping of 127.0.0
;                               Origin is 0.0.127.in-addr.arpa.
;
@                   IN  SOA   vlager.vbrew.com. (
                              joe.vbrew.com.
                              1          ; serial
                              360000     ; refresh: 100 hrs
                              3600       ; retry:   one hour
                              3600000    ; expire:  42 days
                              360000     ; minimum: 100 hrs
                              )
                    IN  NS    vlager.vbrew.com.
1                   IN  PTR   localhost.
\end{verbatim}
\end{tscreen}
 \caption{
  \label{resolv.fig.named.local}
  The \prog{named.local} file.
 }
\end{figure}

\begin{figure}[htbp]
\begin{tscreen}
\begin{verbatim}
;
; /var/named/named.rev         Reverse mapping of our IP addresses
;                               Origin is 72.191.in-addr.arpa.
;
@                   IN  SOA   vlager.vbrew.com. (
                              joe.vbrew.com.
                              16         ; serial
                              86400      ; refresh: once per day
                              3600       ; retry:   one hour
                              3600000    ; expire:  42 days
                              604800     ; minimum: 1 week
                              )
                    IN  NS    vlager.vbrew.com.
; brewery
1.1                 IN  PTR   vlager.vbrew.com.
2.1                 IN  PTR   vstout.vbrew.com.
3.1                 IN  PTR   vale.vbrew.com.
; winery
1.2                 IN  PTR   vlager-if1.vbrew.com.
2.2                 IN  PTR   vbardolino.vbrew.com.
3.2                 IN  PTR   vchianti.vbrew.com.
4.2                 IN  PTR   vbeaujolais.vbrew.com.
\end{verbatim}
\end{tscreen}
 \caption{
  \label{resolv.fig.named.rev}
  The \prog{named.rev} file.
 }
\end{figure}


\subsection{Verifying the Name Server Setup}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{resolv.nslookup}
\index{name server!checking}
\index{checking!name server}
\index{nslookup@\prog{nslookup}|(}
\index{checking!host names}
\index{hostname!lookup}
\index{DNS!checking}

There's a fine tool for checking the operation of your name server
setup. It is called \prog{nslookup}, and may be used both interactively
and from the command line. In the latter case, you simply invoke it
as

\begin{tscreen}
 nslookup \var{hostname}
\end{tscreen}

\noindent
and it will query the name server specified in \file{resolv.conf} for
\var{hostname}.  (If this file names more than one server,
\prog{nslookup} will choose one at random).


The interactive mode, however, is much more exciting. Besides looking
up individual hosts, you may query for any type of DNS record, and
transfer the entire zone information for a domain.


When invoked without argument, \prog{nslookup} will display the name
server it uses, and enter interactive mode. At the `\term{>}' prompt,
you may type any domain name it should query for. By default, it asks
for class A records, those containing the IP~address relating to the
domain name.

You may change this type by issuing ``\term{set type=\sl type}'', where
\var{type} is one of the resource record names described above in
section~\ref{resolv.named}, or ANY.

For example, you might have the following dialogue with it:

\begin{tscreen}\small
\begin{verbatim}
$ nslookup
Default Name Server:  rs10.hrz.th-darmstadt.de
Address:  130.83.56.60

> sunsite.unc.edu
Name Server:  rs10.hrz.th-darmstadt.de
Address:  130.83.56.60

Non-authoritative answer:
Name:    sunsite.unc.edu
Address:  152.2.22.81
\end{verbatim}
\end{tscreen}


If you try to query for a name that has no IP~address associated, but
other records were found in the DNS database, \prog{nslookup} will come
back with an error message saying ``\term{No type A records found}''.
However, you can make it query for records other than type A by issuing
the ``\term{set type}'' command. For example, to get the SOA record of
\host{unc.edu}, you would issue:


\begin{tscreen}\small
\begin{verbatim}
> unc.edu
*** No address (A) records available for unc.edu
Name Server:  rs10.hrz.th-darmstadt.de
Address:  130.83.56.60

> set type=SOA
> unc.edu
Name Server:  rs10.hrz.th-darmstadt.de
Address:  130.83.56.60

Non-authoritative answer:
unc.edu
        origin = ns.unc.edu
        mail addr = shava.ns.unc.edu
        serial = 930408
        refresh = 28800 (8 hours)
        retry   = 3600 (1 hour)
        expire  = 1209600 (14 days)
        minimum ttl = 86400 (1 day)

Authoritative answers can be found from:
UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
SAMBA.ACS.UNC.EDU       internet address = 128.109.157.30
\end{verbatim}
\end{tscreen}


In a similar fashion you can query for MX records, etc.  Using a type of
ANY returns all resource records associated with a given name.


\begin{tscreen}\small
\begin{verbatim}
> set type=MX
> unc.edu
Non-authoritative answer:
unc.edu preference = 10, mail exchanger = lambada.oit.unc.edu
lambada.oit.unc.edu     internet address = 152.2.22.80

Authoritative answers can be found from:
UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
SAMBA.ACS.UNC.EDU       internet address = 128.109.157.30
\end{verbatim}
\end{tscreen}


\index{DNS!root name servers}
\index{name server!root}
A practical application of \prog{nslookup} beside debugging is
to obtain the current list of root name servers for the \file{named.ca}
file. You can do this by querying for all type NS records associated
with the root domain:

\begin{tscreen}\small
\begin{verbatim}
> set typ=NS
> .
Name Server:  fb0430.mathematik.th-darmstadt.de
Address:  130.83.2.30

Non-authoritative answer:
(root)  nameserver = NS.INTERNIC.NET
(root)  nameserver = AOS.ARL.ARMY.MIL
(root)  nameserver = C.NYSER.NET
(root)  nameserver = TERP.UMD.EDU
(root)  nameserver = NS.NASA.GOV
(root)  nameserver = NIC.NORDU.NET
(root)  nameserver = NS.NIC.DDN.MIL

Authoritative answers can be found from:
(root)  nameserver = NS.INTERNIC.NET
(root)  nameserver = AOS.ARL.ARMY.MIL
(root)  nameserver = C.NYSER.NET
(root)  nameserver = TERP.UMD.EDU
(root)  nameserver = NS.NASA.GOV
(root)  nameserver = NIC.NORDU.NET
(root)  nameserver = NS.NIC.DDN.MIL
NS.INTERNIC.NET internet address = 198.41.0.4
AOS.ARL.ARMY.MIL        internet address = 128.63.4.82
AOS.ARL.ARMY.MIL        internet address = 192.5.25.82
AOS.ARL.ARMY.MIL        internet address = 26.3.0.29
C.NYSER.NET     internet address = 192.33.4.12
TERP.UMD.EDU    internet address = 128.8.10.90
NS.NASA.GOV     internet address = 128.102.16.10
NS.NASA.GOV     internet address = 192.52.195.10
NS.NASA.GOV     internet address = 45.13.10.121
NIC.NORDU.NET   internet address = 192.36.148.17
NS.NIC.DDN.MIL  internet address = 192.112.36.4
\end{verbatim}
\end{tscreen}


The complete set of commands available with \prog{nslookup} may be
obtained by the \term{help} command from within \prog{nslookup}.

\index{nslookup@\prog{nslookup}|)}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% hostcvt, dnswalk, etc						%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Other Useful Tools}
\index{DNS!tools}

There are a few tools that can help you with your tasks as a BIND
administrator. I will briefly describe two of them here.
Please refer to the documentation that comes with these tools for
information on how to use them.

\index{DNS!converting /etc/hosts@converting \file{/etc/hosts}}
\index{hosts@\file{hosts}!converting to BIND master files}
\index{hostcvt@\prog{hostcvt}}
\prog{hostcvt} is a tool that helps you with your initial
BIND configuration by converting your \file{/etc/hosts} file
into master files for \prog{named}. It generates both the forward
(A) and reverse mapping (PTR) entries, and takes care of aliases
and the like. Of course, it won't do the whole job for you, as you may
still want to tune the timeout values in the SOA record, for instance,
or add MX records and the like. Still, it may help you save a few
aspirins. \prog{hostcvt} is part of the BIND source, but can also
be found as a standalone package on a few \linux{} FTP servers.

\index{DNS!debugging databases}
\index{dnswalk@\prog{dnswalk}}
\index{debugging!DNS databases}
After setting up your name server, you may want to test your
configuration.  The ideal (and, to my knowledge) only tool for
this is \prog{dnswalk}, a \prog{perl}-based package that 
walks your DNS database, looking for common mistakes and
verifying that the information is consistent. \prog{dnswalk}
has been released on \ngrp{comp.sources.misc} recently, and
should be available on all FTP sites that archive this group
(\host{ftp.uu.net} should be a safe bet if you don't know
of any such site near you).




\index{configuring!name server|)}
\index{name server!configuring|)}
\index{DNS!configuring server|)}
\index{BIND|)}
\index{named@\prog{named}|)}
\index{configuring!hostname resolution|)}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                E N D   O F   C H A P T E R                    %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
