2218 lines
46 KiB
HTML
2218 lines
46 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Running named</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"><LINK
|
|
REL="HOME"
|
|
TITLE="Linux Network Administrators Guide"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Name Service and Resolver Configuration"
|
|
HREF="x-087-2-resolv.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="How DNS Works"
|
|
HREF="x-087-2-resolv.howdnsworks.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Serial Line IP"
|
|
HREF="x-087-2-slip.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Linux Network Administrators Guide</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x-087-2-resolv.howdnsworks.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 6. Name Service and Resolver Configuration</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x-087-2-slip.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="X-087-2-RESOLV.NAMED"
|
|
>6.3. Running named</A
|
|
></H1
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> (pronounced <I
|
|
CLASS="EMPHASIS"
|
|
>name-dee</I
|
|
>)
|
|
provides DNS on most Unix machines. It is a server program
|
|
originally developed for BSD to provide name service to clients, and
|
|
possibly to other name servers. BIND Version 4 was around for some
|
|
time and appeared in most Linux distributions. The new release,
|
|
Version 8, has been introduced in most Linux distributions, and is a
|
|
big change from previous versions.<A
|
|
NAME="X-087-2-FNDN01"
|
|
HREF="#FTN.X-087-2-FNDN01"
|
|
>[1]</A
|
|
>
|
|
It has many new features, such as support for DNS dynamic updates, DNS
|
|
change notifications, much improved performance, and a new
|
|
configuration file syntax. Please check the documentation contained
|
|
in the source distribution for details.</P
|
|
><P
|
|
>This section requires some understanding of the way DNS works. If the
|
|
following discussion is all Greek to you, you may want to reread the
|
|
section <A
|
|
HREF="x-087-2-resolv.howdnsworks.html"
|
|
>Section 6.2</A
|
|
>."</P
|
|
><P
|
|
> <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> is usually
|
|
started at system boot time and runs until the machine goes down
|
|
again. Implementations of BIND prior to Version 8 take their
|
|
information from a configuration file called
|
|
<B
|
|
CLASS="COMMAND"
|
|
>/etc/named.boot</B
|
|
> and various files that map domain
|
|
names to addresses. The latter are called <I
|
|
CLASS="EMPHASIS"
|
|
>zone
|
|
files</I
|
|
>. Versions of BIND from Version 8 onwards use
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/named.conf</TT
|
|
> in place of
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/named.boot</TT
|
|
>.</P
|
|
><P
|
|
>To run <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> at the prompt, enter:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>/usr/sbin/named</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
> </P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> will come up and read the <B
|
|
CLASS="COMMAND"
|
|
>named.boot</B
|
|
>
|
|
file and any zone files specified therein. It writes its process ID to
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/var/run/named.pid</TT
|
|
> in ASCII, downloads any zone files
|
|
from primary servers, if necessary, and starts listening on port 53 for DNS
|
|
queries.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN5298"
|
|
>6.3.1. The named.boot File</A
|
|
></H2
|
|
><P
|
|
> The
|
|
BIND configuration file prior to Version 8 was very simple in
|
|
structure. BIND Version 8 has a very different configuration file
|
|
syntax to deal with many of the new features introduced. The name of
|
|
the configuration file changed from
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/named.boot</TT
|
|
>, in older versions of BIND, to
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/named.conf</TT
|
|
> in BIND Version 8. We'll focus
|
|
on configuring the older version because it is probably what most
|
|
distributions are still using, but we'll present an equivalent
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>named.conf</TT
|
|
> to illustrate the differences, and
|
|
we'll talk about how to convert the old format into the new one.</P
|
|
><P
|
|
>The <B
|
|
CLASS="COMMAND"
|
|
>named.boot</B
|
|
> file is generally small and contains
|
|
little but pointers to master files containing zone information and
|
|
pointers to other name servers. Comments in the boot file start with the
|
|
(#) or (;) characters and extend to the next newline. Before we discuss
|
|
the format of <TT
|
|
CLASS="FILENAME"
|
|
>named.boot</TT
|
|
> in more detail, we will take a
|
|
look at the sample file for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
>
|
|
given in <A
|
|
HREF="x-087-2-resolv.named.html#X-087-2-RESOLV.FIG.NAMED.BOOT"
|
|
>Example 6-8</A
|
|
>.</P
|
|
><DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="X-087-2-RESOLV.FIG.NAMED.BOOT"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 6-8. The named.boot File for vlager</B
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>;
|
|
; /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 16.172.in-addr.arpa named.rev</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>Let's look at each statement individually. The
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>directory</SPAN
|
|
> keyword tells
|
|
<B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> that all filenames referred to later in this file,
|
|
zone files for example, are located in the <TT
|
|
CLASS="FILENAME"
|
|
>/var/named</TT
|
|
>
|
|
directory. This saves a little typing.</P
|
|
><P
|
|
>The <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>primary</SPAN
|
|
> keyword shown in
|
|
this example loads information into <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
>. This
|
|
information is taken from the master files specified as the last of
|
|
the parameters. These files represent DNS resource records, which we
|
|
will look at next.</P
|
|
><P
|
|
>In this example, we configured <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> as the primary
|
|
name server for three domains, as indicated by the three <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>primary</SPAN
|
|
> statements. The first of these
|
|
statements instructs <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> to act as a primary
|
|
server for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vbrew.com</SPAN
|
|
>, taking
|
|
the zone data from the file <TT
|
|
CLASS="FILENAME"
|
|
>named.hosts</TT
|
|
>.</P
|
|
><P
|
|
>The <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>cache</SPAN
|
|
> keyword is very special and
|
|
should be present on virtually all machines running a name server. It
|
|
instructs <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> to enable its cache and to load
|
|
the <I
|
|
CLASS="EMPHASIS"
|
|
>root name server hints</I
|
|
> from the cache file specified
|
|
(<TT
|
|
CLASS="FILENAME"
|
|
>named.ca</TT
|
|
> in our example). We will come back to the name
|
|
server hints in the following list.</P
|
|
><P
|
|
>Here's a list of the most important options you can use in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>named.boot</TT
|
|
> :
|
|
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
><SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>directory</SPAN
|
|
></DT
|
|
><DD
|
|
><P
|
|
> This
|
|
option specifies a directory in which zone files reside. Names of
|
|
files in other options may be given relative to this
|
|
directory. Several directories may be specified by repeatedly using
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>directory</SPAN
|
|
>. The Linux file
|
|
system standard suggests this should be
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/var/named</TT
|
|
>.</P
|
|
></DD
|
|
><DT
|
|
><SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>primary</SPAN
|
|
></DT
|
|
><DD
|
|
><P
|
|
>
|
|
This option takes a domain name and filename as an argument, declaring the local
|
|
server authoritative for the named domain. As a primary server,
|
|
<B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> loads the zone information from the given master file.</P
|
|
><P
|
|
>There will always be at least one <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>primary</SPAN
|
|
>
|
|
entry in every boot file used for reverse mapping of network
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>127.0.0.0</SPAN
|
|
>, which is the local
|
|
loopback network.</P
|
|
></DD
|
|
><DT
|
|
><SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>secondary</SPAN
|
|
></DT
|
|
><DD
|
|
><P
|
|
> This
|
|
statement takes a domain name, an address list, and a filename as an
|
|
argument. It declares the local server a secondary master server for
|
|
the specified domain.</P
|
|
><P
|
|
>A secondary server holds authoritative data on the domain, too, but it
|
|
doesn't gather it from files; instead, it tries to download it from
|
|
the primary server. The IP address of at least one primary server thus
|
|
must be given to <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> in the address list. The
|
|
local server contacts 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.</P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> then attempts to refresh the zone data at
|
|
regular intervals. This process is explained later in connection with
|
|
the SOA resource record type.</P
|
|
></DD
|
|
><DT
|
|
><SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>cache</SPAN
|
|
></DT
|
|
><DD
|
|
><P
|
|
> This option
|
|
takes a domain name and filename as arguments. This file contains
|
|
the root server hints, which is a list of records pointing to the root
|
|
name servers. Only NS and A records will be recognized. The
|
|
<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>domain</I
|
|
></TT
|
|
> should be the root domain name, a
|
|
simple period (.).</P
|
|
><P
|
|
>This information is absolutely crucial to <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
>; if
|
|
the <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>cache</SPAN
|
|
> statement does not
|
|
occur in the boot file, <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> will not develop a
|
|
local cache at all. This situation/lack of development will severely
|
|
degrade performance and increase network load if the next server
|
|
queried is not on the local net. Moreover, <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
>
|
|
will not be able to reach any root name servers, and thus won't
|
|
resolve any addresses except those it is authoritative for. An
|
|
exception from this rule involves forwarding servers (see the
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>forwarders</SPAN
|
|
> option that
|
|
follows).</P
|
|
></DD
|
|
><DT
|
|
><SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>forwarders</SPAN
|
|
></DT
|
|
><DD
|
|
><P
|
|
> This
|
|
statement takes a whitespace-separated list of addresses as an
|
|
argument. The IP addresses in this list specify a list of name
|
|
servers that <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
> 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. Typically, you would use the name server of
|
|
your network provider or another well-known server as a forwarder.</P
|
|
></DD
|
|
><DT
|
|
><SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>slave</SPAN
|
|
></DT
|
|
><DD
|
|
><P
|
|
> This
|
|
statement makes the name server a <I
|
|
CLASS="EMPHASIS"
|
|
>slave</I
|
|
>
|
|
server. It never performs recursive queries itself, but only forwards
|
|
them to servers specified in the <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>forwarders</SPAN
|
|
> statement. </P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
|
|
There are two options that we will not describe here: <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>sortlist</SPAN
|
|
> and <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>domain</SPAN
|
|
>. Two other directives may also be
|
|
used inside these database files: <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>$INCLUDE</SPAN
|
|
> and <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>$ORIGIN</SPAN
|
|
>. Since they are rarely
|
|
needed, we will not describe them here, either.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN5408"
|
|
>6.3.2. The BIND 8 host.conf File</A
|
|
></H2
|
|
><P
|
|
>BIND Version 8 introduced a range of new features, and with these came
|
|
a new configuration file syntax. The <TT
|
|
CLASS="FILENAME"
|
|
>named.boot</TT
|
|
>,
|
|
with its simple single line statements, was replaced by the
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>named.conf</TT
|
|
> file, with a syntax like that of
|
|
<B
|
|
CLASS="COMMAND"
|
|
>gated</B
|
|
> and resembling C source syntax.</P
|
|
><P
|
|
>The new syntax is more complex, but fortunately a tool has been
|
|
provided that automates conversion from the old syntax to the new
|
|
syntax. In the BIND 8 source package, a
|
|
<B
|
|
CLASS="COMMAND"
|
|
>perl</B
|
|
> program called
|
|
<B
|
|
CLASS="COMMAND"
|
|
>named-bootconf.pl</B
|
|
> is provided that will read your
|
|
existing <TT
|
|
CLASS="FILENAME"
|
|
>named.boot</TT
|
|
> file from
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>stdin</TT
|
|
> and convert it into the equivalent
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>named.conf</TT
|
|
> format on
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>stdout</TT
|
|
>. To use it, you must have the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>perl</B
|
|
> interpreter installed.</P
|
|
><P
|
|
>You should use the script somewhat like this:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>cd /etc</B
|
|
></TT
|
|
>
|
|
# <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>named-bootconf.pl <named.boot >named.conf</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
The script then produces a <TT
|
|
CLASS="FILENAME"
|
|
>named.conf</TT
|
|
> that looks
|
|
like that shown in <A
|
|
HREF="x-087-2-resolv.named.html#X-087-2-RESOLV.FIG.NAMED.CONF"
|
|
>Example 6-9</A
|
|
>. We've cleaned out a few of
|
|
the helpful comments the script includes to help show the almost
|
|
direct relationship between the old and the new syntax.</P
|
|
><DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="X-087-2-RESOLV.FIG.NAMED.CONF"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 6-9. The BIND 8 equivalent named.conf File for vlager</B
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>//
|
|
// /etc/named.boot file for vlager.vbrew.com
|
|
options {
|
|
directory "/var/named";
|
|
};
|
|
|
|
zone "." {
|
|
type hint;
|
|
file "named.ca";
|
|
};
|
|
|
|
zone "vbrew.com" {
|
|
type master;
|
|
file "named.hosts";
|
|
};
|
|
|
|
zone "0.0.127.in-addr.arpa" {
|
|
type master;
|
|
file "named.local";
|
|
};
|
|
|
|
zone "16.172.in-addr.arpa" {
|
|
type master;
|
|
file "named.rev";
|
|
};</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>If you take a close look, you will see that each of the one-line statements in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>named.boot</TT
|
|
> has been converted into a C-like statement
|
|
enclosed within { } characters in the
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>named.conf</TT
|
|
> file.</P
|
|
><P
|
|
>The comments, which in the <TT
|
|
CLASS="FILENAME"
|
|
>named.boot</TT
|
|
> file were
|
|
indicated by a semicolon (;), are now indicated by two
|
|
forward slashes ( // ).</P
|
|
><P
|
|
>The <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>directory</SPAN
|
|
> statement has been
|
|
translated into an <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>options</SPAN
|
|
> paragraph
|
|
with a <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>directory</SPAN
|
|
> clause.</P
|
|
><P
|
|
>The <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>cache</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>primary</SPAN
|
|
> statements have been converted
|
|
into <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>zone</SPAN
|
|
> paragraphs with
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>type</SPAN
|
|
> clauses of
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>hint</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>master</SPAN
|
|
>, respectively.</P
|
|
><P
|
|
>The zone files do not need to be modified in any way; their syntax remains
|
|
unchanged.</P
|
|
><P
|
|
>The new configuration syntax allows for many new options that we
|
|
haven't covered here. If you'd like information on the new options,
|
|
the best source of information is the documentation supplied with the
|
|
BIND Version 8 source package.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN5453"
|
|
>6.3.3. The DNS Database Files</A
|
|
></H2
|
|
><P
|
|
> Master
|
|
files included with <B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
>, like
|
|
<B
|
|
CLASS="COMMAND"
|
|
>named.hosts</B
|
|
>, always have a domain associated with
|
|
them, which is called the <I
|
|
CLASS="EMPHASIS"
|
|
>origin</I
|
|
>. This is the
|
|
domain name specified with the <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>cache</SPAN
|
|
> and <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>primary</SPAN
|
|
> options. 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
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>absolute</I
|
|
> if it ends in a single dot, otherwise it
|
|
is considered relative to the origin. The origin by itself may be
|
|
referred to using (<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>@</SPAN
|
|
>).</P
|
|
><P
|
|
>
|
|
The
|
|
data contained in a master file is split up in <I
|
|
CLASS="EMPHASIS"
|
|
>resource
|
|
records</I
|
|
> (RRs). RRs are the smallest units 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. To see an
|
|
example, look at <A
|
|
HREF="x-087-2-resolv.named.html#X-087-2-RESOLV.FIG.NAMED.HOSTS"
|
|
>Example 6-11</A
|
|
>, which shows the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>named.hosts</B
|
|
> master file for the Virtual Brewery.</P
|
|
><P
|
|
>Resource record representations in master files share a
|
|
common format:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>[<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>domain</I
|
|
></TT
|
|
>] [<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>ttl</I
|
|
></TT
|
|
>] [<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>class</I
|
|
></TT
|
|
>] <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>type</I
|
|
></TT
|
|
> <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>rdata</I
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>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. A description of the format terms follows:</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>domain</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
>This term 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.</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>ttl</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
> In order to force resolvers to discard information after a certain time, each
|
|
RR is associated a time to live (<I
|
|
CLASS="EMPHASIS"
|
|
>ttl</I
|
|
> ). The
|
|
ttl field specifies the time in seconds that the
|
|
information is valid after it has been retrieved from the server. It is a
|
|
decimal number with at most eight digits.</P
|
|
><P
|
|
>If no ttl value is given, the field value defaults to that of the
|
|
<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>minimum</I
|
|
></TT
|
|
> field of the preceding SOA record.</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>class</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
>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 specify IN.</P
|
|
><P
|
|
>If no class field is given, the class of the preceding RR is assumed.</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>type</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
>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 RRs.</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>rdata</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
>This holds the data associated with the RR. The format of this field
|
|
depends on the type of RR. In the following discussion, it will be
|
|
described for each RR separately.</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><P
|
|
>The following is partial list of RRs to be used in DNS master files. There
|
|
are a couple more of them that we will not explain; they are experimental
|
|
and of little use, generally.</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
><I
|
|
CLASS="EMPHASIS"
|
|
>SOA</I
|
|
></DT
|
|
><DD
|
|
><P
|
|
>
|
|
|
|
This RR 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
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>primary</SPAN
|
|
> statement must contain an SOA
|
|
record for this zone. The resource data contains the following fields:
|
|
|
|
<P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>origin</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
>This field is the canonical hostname of the primary name server for this domain.
|
|
It is usually given as an absolute name.</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>contact</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
>This field is the email address of the person responsible for maintaining the
|
|
domain, with the "<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>@</SPAN
|
|
>" sign replaced
|
|
by a dot. For instance, if the responsible person at the Virtual Brewery
|
|
were <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>janet</SPAN
|
|
>, this field would
|
|
contain <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>janet.vbrew.com</SPAN
|
|
>.</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>serial</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
>This field 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. A common convention is to use a number that reflects the date
|
|
of the last update, with a version number appended to it to cover the case
|
|
of multiple updates occurring on a single day, e.g., 2000012600 being update 00
|
|
that occurred on January 26, 2000.</P
|
|
><P
|
|
>The serial number is used by secondary name servers to recognize zone
|
|
information changes. 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 transfer the whole zone database from
|
|
the primary server.</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>refresh</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
>This field 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.</P
|
|
><P
|
|
>Generally, the network topology doesn't change too often, so this number
|
|
should specify an interval of roughly a day for larger networks, and even
|
|
more for smaller ones.</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>retry</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
>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 a temporary failure of the server or a network problem
|
|
could cause the secondary server to waste network resources. One hour, or
|
|
perhaps one-half hour, might be a good choice.</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>expire</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
>This field specifies the time in seconds after which a secondary server should
|
|
finally discard all zone data if it hasn't been able to contact the primary
|
|
server. You should normally set this field to at least a week (604,800 seconds), but
|
|
increasing it to a month or more is also reasonable.</P
|
|
></DD
|
|
><DT
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>minimum</I
|
|
></TT
|
|
></DT
|
|
><DD
|
|
><P
|
|
>This field is the default <I
|
|
CLASS="EMPHASIS"
|
|
>ttl</I
|
|
> value for resource records that
|
|
do not explicitly contain one. The ttl value specifies
|
|
the maximum amount of time other name servers may keep the RR in their cache. This time applies only to normal lookups, and has nothing to do with the time after
|
|
which a secondary server should try to update the zone information.</P
|
|
><P
|
|
>If the topology of your network does not change frequently, a week or even
|
|
more is probably a good choice. If single RRs change more frequently, you could
|
|
still assign them smaller ttls individually. If your network changes frequently, you may want to set
|
|
<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>minimum</I
|
|
></TT
|
|
> to one day (86,400 seconds).</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
> </P
|
|
></DD
|
|
><DT
|
|
>A</DT
|
|
><DD
|
|
><P
|
|
>
|
|
This record associates an IP address with a hostname. The resource data field
|
|
contains the address in dotted quad notation.</P
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
For each hostname, there must be only one A record. The hostname used in
|
|
this A record is considered the official or <I
|
|
CLASS="EMPHASIS"
|
|
>canonical</I
|
|
>
|
|
hostname. All other hostnames are aliases and must be mapped onto the
|
|
canonical hostname using a CNAME record. If the canonical name of
|
|
our host were <I
|
|
CLASS="EMPHASIS"
|
|
>vlager</I
|
|
>, we'd have
|
|
an A record that associated that hostname with its IP address. Since we may
|
|
also want another name associated with that address, say
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>news</SPAN
|
|
>, we'd create a
|
|
CNAME record that associates this alternate name with the canonical name.
|
|
We'll talk more about CNAME records shortly.</P
|
|
></DD
|
|
><DT
|
|
>NS</DT
|
|
><DD
|
|
><P
|
|
>NS records are used to specify a zone's primary server and all its secondary
|
|
servers. An NS record points to a master name server of the given zone, with
|
|
the resource data field containing the hostname of the name server.</P
|
|
><P
|
|
>You will meet NS records in two situations: The first situation is when you delegate
|
|
authority to a subordinate zone; the second is within the master zone database
|
|
of the subordinate zone itself. The sets of servers specified in both the
|
|
parent and delegated zones should match.</P
|
|
><P
|
|
>The NS record specifies the name of the primary and secondary name
|
|
servers for a zone. These names must be resolved to an address so they
|
|
can be used. Sometimes the servers belong to the domain they are
|
|
serving, which causes a “chicken and egg” problem; we
|
|
can't resolve the address until the name server is reachable, but we
|
|
can't reach the name server until we resolve its address. To solve
|
|
this dilemma, we can configure special A records directly into the
|
|
name server of the parent zone. The A records allow the name servers
|
|
of the parent domain to resolve the IP address of the delegated
|
|
zone name servers. These records are commonly called <I
|
|
CLASS="EMPHASIS"
|
|
>glue
|
|
records</I
|
|
> because they provide the “glue” that
|
|
binds a delegated zone to its parent.</P
|
|
></DD
|
|
><DT
|
|
>CNAME</DT
|
|
><DD
|
|
><P
|
|
>This record associates an alias with a host's <I
|
|
CLASS="EMPHASIS"
|
|
>canonical
|
|
hostname</I
|
|
>. It provides an alternate name by which
|
|
users can refer to the host whose canonical name is supplied as a
|
|
parameter. 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.</P
|
|
></DD
|
|
><DT
|
|
>PTR</DT
|
|
><DD
|
|
><P
|
|
> This type of record is used to associate names in the
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>in-addr.arpa</SPAN
|
|
> domain with hostnames.
|
|
It is used for reverse mapping of IP addresses to hostnames. The hostname
|
|
given must be the canonical hostname.</P
|
|
></DD
|
|
><DT
|
|
>MX</DT
|
|
><DD
|
|
><P
|
|
> This RR announces a <I
|
|
CLASS="EMPHASIS"
|
|
>mail exchanger</I
|
|
> for a domain.
|
|
Mail exchangers are discussed in
|
|
<A
|
|
HREF="x-087-2-mail.routing.html#X-087-2-MAIL.ROUTING.INTERNET"
|
|
>Section 17.4.1</A
|
|
>.” The syntax of an MX record is:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="90%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>[<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>domain</I
|
|
></TT
|
|
>] [<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>ttl</I
|
|
></TT
|
|
>] [<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>class</I
|
|
></TT
|
|
>] MX <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>preference</I
|
|
></TT
|
|
> <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>host</I
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
><TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>host</I
|
|
></TT
|
|
> names the mail exchanger for
|
|
<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>domain</I
|
|
></TT
|
|
>. Every mail exchanger has an integer
|
|
<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>preference</I
|
|
></TT
|
|
> associated with it. A mail transport
|
|
agent that wants to deliver mail to <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>domain</I
|
|
></TT
|
|
>
|
|
tries 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.</P
|
|
></DD
|
|
><DT
|
|
>HINFO</DT
|
|
><DD
|
|
><P
|
|
>This record provides information on the system's hardware and software.
|
|
Its syntax is:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="90%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>[<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>domain</I
|
|
></TT
|
|
>] [<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>ttl</I
|
|
></TT
|
|
>] [<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>class</I
|
|
></TT
|
|
>] HINFO <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>hardware software</I
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>The <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>hardware</I
|
|
></TT
|
|
> field identifies the hardware used by
|
|
this host. Special conventions are used to specify this. A list of valid
|
|
“machine names” is given in the Assigned Numbers RFC (RFC-1700).
|
|
If the field contains any blanks, it must be enclosed in double quotes. The
|
|
<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>software</I
|
|
></TT
|
|
> field names the operating system software
|
|
used by the system. Again, a valid name from the Assigned Numbers RFC should
|
|
be chosen.</P
|
|
><P
|
|
>An <TT
|
|
CLASS="LITERAL"
|
|
>HINFO</TT
|
|
> record to describe an Intel-based Linux machine
|
|
should look something like:
|
|
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="90%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>tao 36500 IN HINFO IBM-PC LINUX2.2</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
and <TT
|
|
CLASS="LITERAL"
|
|
>HINFO</TT
|
|
> records for Linux running on Motorola 68000-based
|
|
machines might look like:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="90%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>cevad 36500 IN HINFO ATARI-104ST LINUX2.0
|
|
jedd 36500 IN HINFO AMIGA-3000 LINUX2.0</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
> </P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-RESOLV.NAMED-CACHINGONLY"
|
|
>6.3.4. Caching-only named Configuration</A
|
|
></H2
|
|
><P
|
|
>There is a special type of <TT
|
|
CLASS="FILENAME"
|
|
>named</TT
|
|
> configuration
|
|
that we'll talk about before we explain how to build a full name
|
|
server configuration. It is called a
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>caching-only</I
|
|
> configuration. It doesn't really
|
|
serve a domain, but acts as a relay for all DNS queries produced on
|
|
your host. The advantage of this scheme is that it builds up a cache
|
|
so only the first query for a particular host is actually sent to the
|
|
name servers on the Internet. Any repeated request will be answered
|
|
directly from the cache in your local name server. This may not seem
|
|
useful yet, but it will when you are dialing in to the Internet, as
|
|
described in <A
|
|
HREF="x-087-2-slip.html"
|
|
>Chapter 7</A
|
|
> and <A
|
|
HREF="x-087-2-ppp.html"
|
|
>Chapter 8</A
|
|
>.</P
|
|
><P
|
|
>A <TT
|
|
CLASS="FILENAME"
|
|
>named.boot</TT
|
|
> file for a caching-only server looks like
|
|
this:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>; named.boot file for caching-only server
|
|
directory /var/named
|
|
primary 0.0.127.in-addr.arpa named.local ; localhost network
|
|
cache . named.ca ; root servers</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>In addition to this <TT
|
|
CLASS="FILENAME"
|
|
>named.boot</TT
|
|
> file, you must set
|
|
up the <TT
|
|
CLASS="FILENAME"
|
|
>named.ca</TT
|
|
> file with a valid list of root
|
|
name servers. You could copy and use <A
|
|
HREF="x-087-2-resolv.named.html#X-087-2-RESOLV.FIG.NAMED.CACHE"
|
|
>Example 6-10</A
|
|
> for this purpose. No other
|
|
files are needed for a caching-only server configuration.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN5685"
|
|
>6.3.5. Writing the Master Files</A
|
|
></H2
|
|
><P
|
|
><A
|
|
HREF="x-087-2-resolv.named.html#X-087-2-RESOLV.FIG.NAMED.CACHE"
|
|
>Example 6-10</A
|
|
>,
|
|
<A
|
|
HREF="x-087-2-resolv.named.html#X-087-2-RESOLV.FIG.NAMED.HOSTS"
|
|
>Example 6-11</A
|
|
>,
|
|
<A
|
|
HREF="x-087-2-resolv.named.html#X-087-2-RESOLV.FIG.NAMED.LOCAL"
|
|
>Example 6-12</A
|
|
>, and
|
|
<A
|
|
HREF="x-087-2-resolv.named.html#X-087-2-RESOLV.FIG.NAMED.REV"
|
|
>Example 6-13</A
|
|
> give sample files for a name
|
|
server at the brewery, located on
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
>. Due to the nature of the
|
|
network discussed (a single LAN), the example is pretty straightforward.</P
|
|
><P
|
|
>
|
|
The <TT
|
|
CLASS="FILENAME"
|
|
>named.ca</TT
|
|
> cache file shown in
|
|
<A
|
|
HREF="x-087-2-resolv.named.html#X-087-2-RESOLV.FIG.NAMED.CACHE"
|
|
>Example 6-10</A
|
|
> shows sample hint records for
|
|
a root name server. A typical cache file usually describes about a dozen name servers. You can obtain the current list of name servers for the root
|
|
domain using the <B
|
|
CLASS="COMMAND"
|
|
>nslookup</B
|
|
> tool described in the next
|
|
section.<A
|
|
NAME="X-087-2-FNDN03"
|
|
HREF="#FTN.X-087-2-FNDN03"
|
|
>[2]</A
|
|
> </P
|
|
><DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="X-087-2-RESOLV.FIG.NAMED.CACHE"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 6-10. The named.ca File</B
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>;
|
|
; /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.
|
|
;
|
|
;. 3600000 IN NS A.ROOT-SERVERS.NET.
|
|
;A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
|
|
;. 3600000 NS B.ROOT-SERVERS.NET.
|
|
;B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
|
|
;. 3600000 NS C.ROOT-SERVERS.NET.
|
|
;C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
|
|
;. 3600000 NS D.ROOT-SERVERS.NET.
|
|
;D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
|
|
;. 3600000 NS E.ROOT-SERVERS.NET.
|
|
;E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
|
|
;. 3600000 NS F.ROOT-SERVERS.NET.
|
|
;F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
|
|
;. 3600000 NS G.ROOT-SERVERS.NET.
|
|
;G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
|
|
;. 3600000 NS H.ROOT-SERVERS.NET.
|
|
;H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
|
|
;. 3600000 NS I.ROOT-SERVERS.NET.
|
|
;I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
|
|
;. 3600000 NS J.ROOT-SERVERS.NET.
|
|
;J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10
|
|
;. 3600000 NS K.ROOT-SERVERS.NET.
|
|
;K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
|
|
;. 3600000 NS L.ROOT-SERVERS.NET.
|
|
;L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
|
|
;. 3600000 NS M.ROOT-SERVERS.NET.
|
|
;M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
|
|
;</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="X-087-2-RESOLV.FIG.NAMED.HOSTS"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 6-11. The named.hosts File</B
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>;
|
|
; /var/named/named.hosts Local hosts at the brewery
|
|
; Origin is vbrew.com
|
|
;
|
|
@ IN SOA vlager.vbrew.com. janet.vbrew.com. (
|
|
2000012601 ; 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
|
|
;
|
|
; Virtual Brewery Ethernet
|
|
vlager IN A 172.16.1.1
|
|
vlager-if1 IN CNAME vlager
|
|
; vlager is also news server
|
|
news IN CNAME vlager
|
|
vstout IN A 172.16.1.2
|
|
vale IN A 172.16.1.3
|
|
;
|
|
; Virtual Winery Ethernet
|
|
vlager-if2 IN A 172.16.2.1
|
|
vbardolino IN A 172.16.2.2
|
|
vchianti IN A 172.16.2.3
|
|
vbeaujolais IN A 172.16.2.4
|
|
;
|
|
; Virtual Spirits (subsidiary) Ethernet
|
|
vbourbon IN A 172.16.3.1
|
|
vbourbon-if1 IN CNAME vbourbon</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="X-087-2-RESOLV.FIG.NAMED.LOCAL"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 6-12. The named.local File</B
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>;
|
|
; /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.</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><DIV
|
|
CLASS="EXAMPLE"
|
|
><A
|
|
NAME="X-087-2-RESOLV.FIG.NAMED.REV"
|
|
></A
|
|
><P
|
|
><B
|
|
>Example 6-13. The named.rev File</B
|
|
></P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>;
|
|
; /var/named/named.rev Reverse mapping of our IP addresses
|
|
; Origin is 16.172.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-if2.vbrew.com.
|
|
2.2 IN PTR vbardolino.vbrew.com.
|
|
3.2 IN PTR vchianti.vbrew.com.
|
|
4.2 IN PTR vbeaujolais.vbrew.com.</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-RESOLV.NSLOOKUP"
|
|
>6.3.6. Verifying the Name Server Setup</A
|
|
></H2
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>nslookup</B
|
|
> is a great tool for checking the operation
|
|
of your name server setup. It can be used both interactively with
|
|
prompts and as a single command with immediate output. In the latter
|
|
case, you simply invoke it as:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>$ <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>nslookup</B
|
|
></TT
|
|
>
|
|
<TT
|
|
CLASS="LITERAL"
|
|
><I
|
|
CLASS="EMPHASIS"
|
|
>hostname</I
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>nslookup</B
|
|
> queries the name server specified in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>resolv.conf</TT
|
|
> for <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>hostname</I
|
|
></TT
|
|
>.
|
|
(If this file names more than one server, <B
|
|
CLASS="COMMAND"
|
|
>nslookup</B
|
|
> chooses
|
|
one at random.)</P
|
|
><P
|
|
>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.</P
|
|
><P
|
|
>When invoked without an argument, <B
|
|
CLASS="COMMAND"
|
|
>nslookup</B
|
|
> displays the name
|
|
server it uses and enters interactive mode. At the <B
|
|
CLASS="COMMAND"
|
|
>></B
|
|
> prompt,
|
|
you may type any domain name you want to query. By default, it asks
|
|
for class A records, those containing the IP address relating to the
|
|
domain name.</P
|
|
><P
|
|
>You can look for record types by issuing:</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>> <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>set type=</B
|
|
></TT
|
|
><TT
|
|
CLASS="LITERAL"
|
|
>type</TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
>in which <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>type</I
|
|
></TT
|
|
> is one of the resource record names described
|
|
earlier, or ANY.</P
|
|
><P
|
|
>You might have the following <B
|
|
CLASS="COMMAND"
|
|
>nslookup</B
|
|
> session:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>$ <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>nslookup</B
|
|
></TT
|
|
>
|
|
Default Server: tao.linux.org.au
|
|
Address: 203.41.101.121
|
|
|
|
> <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>metalab.unc.edu</B
|
|
></TT
|
|
>
|
|
Server: tao.linux.org.au
|
|
Address: 203.41.101.121
|
|
|
|
Name: metalab.unc.edu
|
|
Address: 152.2.254.81
|
|
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>The output first displays the DNS server being queried, and then the result
|
|
of the query.</P
|
|
><P
|
|
>If you try to query for a name that has no IP address associated with it,
|
|
but other records were found in the DNS database, <B
|
|
CLASS="COMMAND"
|
|
>nslookup</B
|
|
>
|
|
returns with an error message saying
|
|
“<TT
|
|
CLASS="LITERAL"
|
|
>No type A records found</TT
|
|
>.” However, you can
|
|
make it query for records other than type A by issuing the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>set type</B
|
|
> command. To get the SOA record of
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>unc.edu</SPAN
|
|
>, you would issue:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>> <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>unc.edu</B
|
|
></TT
|
|
>
|
|
Server: tao.linux.org.au
|
|
Address: 203.41.101.121
|
|
|
|
*** No address (A) records available for unc.edu
|
|
> <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>set type=SOA</B
|
|
></TT
|
|
>
|
|
> <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>unc.edu</B
|
|
></TT
|
|
>
|
|
Server: tao.linux.org.au
|
|
Address: 203.41.101.121
|
|
|
|
unc.edu
|
|
origin = ns.unc.edu
|
|
mail addr = host-reg.ns.unc.edu
|
|
serial = 1998111011
|
|
refresh = 14400 (4H)
|
|
retry = 3600 (1H)
|
|
expire = 1209600 (2W)
|
|
minimum ttl = 86400 (1D)
|
|
unc.edu name server = ns2.unc.edu
|
|
unc.edu name server = ncnoc.ncren.net
|
|
unc.edu name server = ns.unc.edu
|
|
ns2.unc.edu internet address = 152.2.253.100
|
|
ncnoc.ncren.net internet address = 192.101.21.1
|
|
ncnoc.ncren.net internet address = 128.109.193.1
|
|
ns.unc.edu internet address = 152.2.21.1</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>In a similar fashion, you can query for MX records:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>> <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>set type=MX</B
|
|
></TT
|
|
>
|
|
> <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>unc.edu</B
|
|
></TT
|
|
>
|
|
Server: tao.linux.org.au
|
|
Address: 203.41.101.121
|
|
|
|
unc.edu preference = 0, mail exchanger = conga.oit.unc.edu
|
|
unc.edu preference = 10, mail exchanger = imsety.oit.unc.edu
|
|
unc.edu name server = ns.unc.edu
|
|
unc.edu name server = ns2.unc.edu
|
|
unc.edu name server = ncnoc.ncren.net
|
|
conga.oit.unc.edu internet address = 152.2.22.21
|
|
imsety.oit.unc.edu internet address = 152.2.21.99
|
|
ns.unc.edu internet address = 152.2.21.1
|
|
ns2.unc.edu internet address = 152.2.253.100
|
|
ncnoc.ncren.net internet address = 192.101.21.1
|
|
ncnoc.ncren.net internet address = 128.109.193.1</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Using a type of ANY returns all resource records associated with a given name.</P
|
|
><P
|
|
>
|
|
A practical application of <B
|
|
CLASS="COMMAND"
|
|
>nslookup</B
|
|
>, besides debugging, is
|
|
to obtain the current list of root name servers. You can obtain this list by querying
|
|
for all NS records associated with the root domain:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>> <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>set type=NS</B
|
|
></TT
|
|
>
|
|
> <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>.</B
|
|
></TT
|
|
>
|
|
Server: tao.linux.org.au
|
|
Address: 203.41.101.121
|
|
|
|
Non-authoritative answer:
|
|
(root) name server = A.ROOT-SERVERS.NET
|
|
(root) name server = H.ROOT-SERVERS.NET
|
|
(root) name server = B.ROOT-SERVERS.NET
|
|
(root) name server = C.ROOT-SERVERS.NET
|
|
(root) name server = D.ROOT-SERVERS.NET
|
|
(root) name server = E.ROOT-SERVERS.NET
|
|
(root) name server = I.ROOT-SERVERS.NET
|
|
(root) name server = F.ROOT-SERVERS.NET
|
|
(root) name server = G.ROOT-SERVERS.NET
|
|
(root) name server = J.ROOT-SERVERS.NET
|
|
(root) name server = K.ROOT-SERVERS.NET
|
|
(root) name server = L.ROOT-SERVERS.NET
|
|
(root) name server = M.ROOT-SERVERS.NET
|
|
|
|
Authoritative answers can be found from:
|
|
A.ROOT-SERVERS.NET internet address = 198.41.0.4
|
|
H.ROOT-SERVERS.NET internet address = 128.63.2.53
|
|
B.ROOT-SERVERS.NET internet address = 128.9.0.107
|
|
C.ROOT-SERVERS.NET internet address = 192.33.4.12
|
|
D.ROOT-SERVERS.NET internet address = 128.8.10.90
|
|
E.ROOT-SERVERS.NET internet address = 192.203.230.10
|
|
I.ROOT-SERVERS.NET internet address = 192.36.148.17
|
|
F.ROOT-SERVERS.NET internet address = 192.5.5.241
|
|
G.ROOT-SERVERS.NET internet address = 192.112.36.4
|
|
J.ROOT-SERVERS.NET internet address = 198.41.0.10
|
|
K.ROOT-SERVERS.NET internet address = 193.0.14.129
|
|
L.ROOT-SERVERS.NET internet address = 198.32.64.12
|
|
M.ROOT-SERVERS.NET internet address = 202.12.27.33</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>To see the complete set of available commands, use the <B
|
|
CLASS="COMMAND"
|
|
>help</B
|
|
>
|
|
command in <B
|
|
CLASS="COMMAND"
|
|
>nslookup</B
|
|
>.</P
|
|
><P
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN5795"
|
|
>6.3.7. Other Useful Tools</A
|
|
></H2
|
|
><P
|
|
>There are a few tools that can help you with your tasks as a BIND
|
|
administrator. We will briefly describe two of them here. Please refer to
|
|
the documentation that comes with these tools for more information on how
|
|
to use them.</P
|
|
><P
|
|
> <B
|
|
CLASS="COMMAND"
|
|
>hostcvt</B
|
|
> helps you
|
|
with your initial BIND configuration by converting your
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/hosts</TT
|
|
> file into master files for
|
|
<B
|
|
CLASS="COMMAND"
|
|
>named</B
|
|
>. It generates both the forward (A) and
|
|
reverse mapping (PTR) entries, and takes care of aliases. 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 example, or add MX
|
|
records. Still, it may help you save a few
|
|
aspirins. <B
|
|
CLASS="COMMAND"
|
|
>hostcvt</B
|
|
> is part of the BIND source, but
|
|
can also be found as a standalone package on a few Linux FTP servers.</P
|
|
><P
|
|
>
|
|
After setting up your name server,
|
|
you may want to test your configuration. Some good tools
|
|
that make this job much simpler: the first is called
|
|
<B
|
|
CLASS="COMMAND"
|
|
>dnswalk</B
|
|
>, which is a Perl-based package. The second
|
|
is called <B
|
|
CLASS="COMMAND"
|
|
>nslint</B
|
|
>. They both walk your DNS database
|
|
looking for common mistakes and verify that the information they find
|
|
is consistent. Two other useful tools are <B
|
|
CLASS="COMMAND"
|
|
>host</B
|
|
> and
|
|
<B
|
|
CLASS="COMMAND"
|
|
>dig</B
|
|
>, which are general purpose DNS database query
|
|
tools. You can use these tools to manually inspect and diagnose DNS
|
|
database entries.</P
|
|
><P
|
|
>These tools are likely to be available in prepackaged form.
|
|
<B
|
|
CLASS="COMMAND"
|
|
>dnswalk</B
|
|
> and <B
|
|
CLASS="COMMAND"
|
|
>nslint</B
|
|
> are available
|
|
in source from <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>http://www.visi.com/~barr/dnswalk/</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>ftp://ftp.ee.lbl.gov/nslint.tar.Z</SPAN
|
|
>. The
|
|
<B
|
|
CLASS="COMMAND"
|
|
>host</B
|
|
> and <B
|
|
CLASS="COMMAND"
|
|
>dig</B
|
|
> source codes can be
|
|
found at <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>ftp://ftp.nikhef.nl/pub/network/</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>ftp://ftp.is.co.za/networking/ip/dns/dig/</SPAN
|
|
>.</P
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><H3
|
|
CLASS="FOOTNOTES"
|
|
>Notes</H3
|
|
><TABLE
|
|
BORDER="0"
|
|
CLASS="FOOTNOTES"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNDN01"
|
|
HREF="x-087-2-resolv.named.html#X-087-2-FNDN01"
|
|
>[1]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
>BIND 4.9 was developed by Paul Vixie,
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>paul@vix.com</SPAN
|
|
>,
|
|
but BIND is now maintained by the Internet Software Consortium,
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>bind-bugs@isc.org</SPAN
|
|
>.</P
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNDN03"
|
|
HREF="x-087-2-resolv.named.html#X-087-2-FNDN03"
|
|
>[2]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
>Note that you can't query your name server for the root servers if you don't
|
|
have any root server hints installed. To escape this dilemma, you can either
|
|
make <B
|
|
CLASS="COMMAND"
|
|
>nslookup</B
|
|
> use a different name server, or use
|
|
the sample file in <A
|
|
HREF="x-087-2-resolv.named.html#X-087-2-RESOLV.FIG.NAMED.CACHE"
|
|
>Example 6-10</A
|
|
> as a
|
|
starting point, and then obtain the full list of valid servers.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-resolv.howdnsworks.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-slip.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>How DNS Works</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-resolv.html"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Serial Line IP</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |