Commit 3827c16d authored by Eric Luce's avatar Eric Luce

This is the initial addition of the XML version of the BIND v9 ARM.

These files are based on the BIND v9 ARM in FrameMaker. After these
files are edited they will become the master source for the BIND v9 ARM.

Still need to include style sheets and the actual XML DocBook DTD
for those who do not have it.
parent af8cb354
<chapter>
<title>Introduction </title>
<para>The Internet Domain Name System (<acronym>DNS</acronym>) consists of the syntax
to specify the names of entities in the Internet in a hierarchical
manner, the rules used for delegating authority over names, and the
system implementation that actually maps names to Internet
addresses. <acronym>DNS</acronym> data is maintained in a group of distributed
hierarchical databases.</para>
<sect1>
<title>Scope of Document</title>
<para>The Berkeley Internet Name Domain (<acronym>BIND</acronym>) implements an
Internet nameserver for a number of operating systems. This
document provides basic information about the installation and
care of the Internet Software Consortium (<acronym>ISC</acronym>) <acronym>BIND</acronym> version 9
software package for system administrators.</para>
</sect1>
<sect1><title>Organization of This Document</title>
<para>In this document, <emphasis>Section 1</emphasis> introduces
the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Section 2</emphasis>
describes resource requirements for running <acronym>BIND</acronym> in various
environments. Information in <emphasis>Section 3</emphasis> is
<emphasis>task-oriented</emphasis> in its presentation and is
organized functionally, to aid in the process of installing the
<acronym>BIND</acronym> 9 software. The task-oriented section is followed by
<emphasis>Section 4</emphasis>, which contains more advanced
concepts that the system administrator may need for implementing
certain options. Section 5 describes the <acronym>BIND</acronym> 9 lightweight
resolver. The contents of <emphasis>Section 6</emphasis> are
organized as in a reference manual to aid in the ongoing
maintenance of the software. <emphasis>Section 7
</emphasis>addresses security considerations, and
<emphasis>Section 8</emphasis> contains troubleshooting help. The
main body of the document is followed by several
<emphasis>Appendices</emphasis> which contain useful reference
information, such as a <emphasis>Bibliography</emphasis> and
historic information related to <acronym>BIND</acronym> and the Domain Name
System.</para>
</sect1>
<sect1><title>Conventions Used in This Document</title>
<para>In this document, we use the following general typographic
conventions:</para>
<informaltable colsep = "0" frame = "all" rowsep = "0">
<tgroup cols = "2" colsep = "0" rowsep = "0"
tgroupstyle = "2Level-table">
<colspec colname = "1" colnum = "1" colsep = "0"
colwidth = "3.000in"/>
<colspec colname = "2" colnum = "2" colsep = "0"
colwidth = "2.625in"/>
<tbody>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1">
<para><emphasis>To
describe:</emphasis></para></entry>
<entry colname = "2" rowsep = "1">
<para><emphasis>We use the style:</emphasis></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1">
<para>a pathname, filename, URL, hostname,
mailing list name, or new term or concept</para></entry>
<entry colname = "2" rowsep = "1"><para><filename>Italic</filename></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1"><para>literal user
input</para></entry>
<entry colname = "2" rowsep = "1"><para><userinput>Fixed Width Bold</userinput></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1"><para>variable user
input</para></entry>
<entry colname = "2" rowsep = "1"><para><optional>Fixed Width Italic</optional></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1"><para>program output</para></entry>
<entry colname = "2"><para><command>Fixed Width Bold</command></para></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>The following conventions are used in descriptions of the
<acronym>BIND</acronym> configuration file:<informaltable colsep = "0" frame = "all" rowsep = "0">
<tgroup cols = "2" colsep = "0" rowsep = "0"
tgroupstyle = "2Level-table">
<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "3.000in"/>
<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "2.625in"/>
<tbody>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1"><para><emphasis>To
describe:</emphasis></para></entry>
<entry colname = "2" rowsep = "1"><para><emphasis>We use the style:</emphasis></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1"><para>keywords</para></entry>
<entry colname = "2" rowsep = "1"><para><literal>Sans Serif Bold</literal></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1"><para>variables</para></entry>
<entry colname = "2" rowsep = "1"><para><varname>Sans Serif Italic</varname></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1"><para>"meta-syntactic"
information (within brackets when optional)</para></entry>
<entry colname = "2" rowsep = "1"><para><optional>Fixed Width Italic</optional></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1"><para>Command line
input</para></entry>
<entry colname = "2" rowsep = "1"><para><userinput>Fixed Width Bold</userinput></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1" rowsep = "1"><para>Program output</para></entry>
<entry colname = "2" rowsep = "1"><para><command>Fixed Width</command></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1" colsep = "1"><para>Optional input</para></entry>
<entry colname = "2"><para>Text is enclosed in square brackets</para></entry>
</row>
</tbody>
</tgroup></informaltable></para></sect1>
<sect1><title>Discussion of Domain Name System (<acronym>DNS</acronym>) Basics and
<acronym>BIND</acronym></title>
<para>The purpose of this document is to explain the installation
and basic upkeep of the <acronym>BIND</acronym> software package, and we begin by reviewing
the fundamentals of the domain naming system as they relate to <acronym>BIND</acronym>.
<acronym>BIND</acronym> consists of a <emphasis>nameserver</emphasis> (or "daemon")
called <command>named</command> and a <command>resolver</command> library.
The <acronym>BIND</acronym> server runs in the background, servicing queries on a well
known network port. The standard port for the User Datagram Protocol
(UDP) and Transmission Control Protocol (TCP), usually port 53,
is specified in<command> </command><filename>/etc/services</filename>.
The <emphasis>resolver</emphasis> is a set of routines residing
in a system library that provides the interface that programs can
use to access the domain name services.</para>
<sect2><title>Nameservers</title>
<para>A nameserver (NS) is a program that stores information about
named resources and responds to queries from programs called <emphasis>resolvers</emphasis> which
act as client processes. The basic function of an NS is to provide
information about network objects by answering queries.</para>
<para>With the nameserver, the network can be broken into a hierarchy
of domains. The name space is organized as a tree according to organizational
or administrative boundaries. Each node of the tree, called a domain,
is given a label. The name of the domain is the concatenation of
all the labels of the domains from the root to the current domain.
This is represented in written form as a string of labels listed
from right to left and separated by dots. A label need only be unique
within its domain. The whole name space is partitioned into areas
called <emphasis>zones</emphasis>, each starting at a domain and
extending down to the leaf domains or to domains where other zones
start. Zones usually represent administrative boundaries. For example,
a domain name for a host at the company <emphasis>Example, Inc.</emphasis> would
be:</para>
<para><systemitem class="systemname">ourhost.example.com</systemitem></para>
<para>where <systemitem class="systemname">com</systemitem> is the top level domain to which <systemitem class="systemname">ourhost.example.com</systemitem> belongs, <systemitem class="systemname">example</systemitem> is
a subdomain of <systemitem class="systemname">com</systemitem>, and <systemitem class="systemname">ourhost</systemitem> is the
name of the host.</para>
<para>The specifications for the domain nameserver are defined in
the RFC 1034, RFC 1035 and RFC 974. These documents can be found
in
<filename>/usr/src/etc/named/doc</filename> in 4.4BSD or are available
via File Transfer Protocol (FTP) from
<ulink
url="ftp://www.isi.edu/in-notes/">ftp://www.isi.edu/in-notes/</ulink> or via the Web at <ulink url="http://www.ietf.org/rfc/">http://www.ietf.org/rfc/</ulink>.
(See Appendix C for complete information on finding and retrieving
RFCs.) It is also recommended that you read the related man pages: <command>named</command> and <command>resolver</command>.</para></sect2>
<sect2><title>Types of Zones</title>
<para>As we stated previously, a zone is a point of delegation in
the <acronym>DNS</acronym> tree. A zone consists of those contiguous parts of the domain
tree for which a domain server has complete information and over which
it has authority. It contains all domain names from a certain point
downward in the domain tree except those which are delegated to
other zones. A delegation point has one or more NS records in the
parent zone, which should be matched by equivalent NS records at
the root of the delegated zone.</para>
<para>To properly operate a nameserver, it is important to understand
the difference between a <emphasis>zone</emphasis> and a <emphasis>domain</emphasis>.</para>
<para>For instance, consider the <systemitem class="systemname">example.com</systemitem> domain
which includes names such as <systemitem class="systemname">host.aaa.example.com </systemitem>and <systemitem class="systemname">host.bbb.example.com</systemitem> even
though the <systemitem class="systemname">example.com</systemitem> zone includes only delegations
for the <systemitem class="systemname">aaa.example.com</systemitem> and <systemitem class="systemname">bbb.example.com</systemitem> zones.
A zone can map exactly to a single domain, but could also include
only part of a domain, the rest of which could be delegated to other
nameservers. Every name in the <acronym>DNS</acronym> tree is a <emphasis>domain</emphasis>,
even if it is <emphasis>terminal</emphasis>, that is, has no <emphasis>subdomains</emphasis>.
Every subdomain is a domain and every domain except the root is
also a subdomain. The terminology is not intuitive and we suggest
that you read RFCs 1033, 1034 and 1035 to gain a complete understanding
of this difficult and subtle topic.</para>
<para>Though <acronym>BIND</acronym> is a Domain Nameserver, it deals primarily in
terms of zones. The master and slave declarations in the <filename>named.conf</filename> file
specify zones, not domains. When you ask some other site if it is willing
to be a slave server for your <emphasis>domain</emphasis>, you are
actually asking for slave service for some collection of zones.</para>
<para>Each zone will have one <emphasis>primary master</emphasis> (also
called <emphasis>primary</emphasis>) server which loads the zone
contents from some local file edited by humans or perhaps generated
mechanically from some other local file which is edited by humans.
There there will be some number of <emphasis>slave</emphasis> (also
called <emphasis>secondary) </emphasis>servers, which load the zone
contents using the <acronym>DNS</acronym> protocol (that is, the secondary servers
will contact the primary and fetch the zone data using TCP). This
set of servers-the primary and all of its secondaries-should be
listed in the NS records in the parent zone and will constitute a <emphasis>delegation</emphasis>.
This set of servers must also be listed in the zone file itself,
usually under the <command>@</command> name which indicates the <emphasis>top
level</emphasis> or <emphasis>root</emphasis> of the current zone.
You can list servers in the zone's top-level <command>@</command> NS
records that are not in the parent's NS delegation, but you cannot
list servers in the parent's delegation that are not present in
the zone's <command>@</command>.</para>
<para>Any servers listed in the NS records must be configured as <emphasis>authoritative</emphasis> for
the zone. A server is authoritative for a zone when it has been
configured to answer questions for that zone with authority, which
it does by setting the "authoritative answer" (AA) bit in reply
packets. A server may be authoritative for more than one zone. The
authoritative data for a zone is composed of all of the Resource
Records (RRs)-the data associated with names in a tree-structured
name space-attached to all of the nodes from the top node of the
zone down to leaf nodes or nodes above cuts around the bottom edge
of the zone.</para>
<para>Adding a zone as a type master or type slave will tell the
server to answer questions for the zone authoritatively. If the
server is able to load the zone into memory without any errors it
will set the AA bit when it replies to queries for the zone. See
RFCs 1034 and 1035 for more information about the AA bit.</para></sect2>
<sect2><title>Servers</title>
<para>A <acronym>DNS</acronym> server can be master for some zones and slave for others
or can be only a master, or only a slave, or can serve no zones
and just answer queries via its <emphasis>cache</emphasis>. Master
servers are often also called <emphasis>primaries</emphasis> and
slave servers are often also called <emphasis>secondaries</emphasis>.
Both master/primary and slave/secondary servers are authoritative
for a zone.</para>
<para>All servers keep data in their cache until the data expires,
based on a Time To Live (TTL) field which is maintained for all
resource records.</para>
<sect3><title>Master Server</title>
<para>The <emphasis>primary master server</emphasis> is the ultimate
source of information about a domain. The primary master is an authoritative
server configured to be the source of zone transfer for one or more
secondary servers. The primary master server obtains data for the
zone from a file on disk.</para></sect3>
<sect3><title>Slave Server </title>
<para>A <emphasis>slave server</emphasis>, also called a <emphasis>secondary
server</emphasis>, is an authoritative server that uses zone transfers from
the primary master server to retrieve the zone data. Optionally,
the slave server obtains zone data from a cache on disk. Slave servers
provide necessary redundancy. All secondary/slave servers are named
in the NS RRs for the zone.</para></sect3>
<sect3><title>Caching Only Server</title>
<para>Some servers are <emphasis>caching only servers</emphasis>.
This means that the server caches the information that it receives
and uses it until the data expires. A caching only server is a server
that is not authoritative for any zone. This server services queries
and asks other servers, who have the authority, for the information
it needs.</para></sect3>
<sect3><title>Forwarding Server</title>
<para>Instead of interacting with the nameservers for the root and
other domains, a <emphasis>forwarding server</emphasis> always forwards
queries it cannot satisfy from its authoritative data or cache to
a fixed list of other servers. The forwarded queries are also known
as <emphasis>recursive queries</emphasis>, the same type as a client would
send to a server. There may be one or more servers forwarded to,
and they are queried in turn until the list is exhausted or an answer
is found. A forwarding server is typically used when you do not
wish all the servers at a given site to interact with the rest of
the Internet servers. A typical scenario would involve a number
of internal <acronym>DNS</acronym> servers and an Internet firewall. Servers unable
to pass packets through the firewall would forward to the server
that can do it, and that server would query the Internet <acronym>DNS</acronym> servers
on the internal server's behalf. An added benefit of using the forwarding
feature is that the central machine develops a much more complete
cache of information that all the workstations can take advantage
of.</para>
<para>There is no prohibition against declaring a server to be a
forwarder even though it has master and/or slave zones as well;
the effect will still be that anything in the local server's cache
or zones will be answered, and anything else will be forwarded using
the forwarders list.</para></sect3>
<sect3><title>Stealth Server</title>
<para>A <emphasis>stealth server</emphasis> is a server that answers
authoritatively for a zone, but is not listed in that zone's NS
records. Stealth servers can be used as a way to centralize distribution
of a zone, without having to edit the zone on a remote nameserver.
Where the master file for a zone resides on a stealth server in
this way, it is often referred to as a "hidden primary" configuration.
Stealth servers can also be a way to keep a local copy of a zone
for rapid access to the zone's records, even if all "official" nameservers
for the zone are inaccessible.</para>
</sect3>
</sect2>
</sect1>
</chapter>
<chapter><title><acronym>BIND</acronym> Resource Requirements</title>
<sect1><title>Hardware requirements</title>
<para><acronym>DNS</acronym> hardware requirements have traditionally been quite modest.
For many installations, servers that have been pensioned off from
active duty have performed admirably as <acronym>DNS</acronym> servers.</para>
<para>The DNSSEC and IPv6 features of <acronym>BIND</acronym> 9 may prove to be quite
CPU intensive however, so organizations that make heavy use of these
features may wish to consider larger systems for these applications.
<acronym>BIND</acronym> 9 is now fully multithreaded, allowing full utilization of
multiprocessor systems for installations that need it.</para></sect1>
<sect1><title>CPU Requirements</title>
<para>CPU requirements for <acronym>BIND</acronym> 9 range from i486-class machines
for serving of static zones without caching, to enterprise-class
machines if you intend to process many dynamic updates and DNSSEC
signed zones, serving many thousands of queries per second.</para></sect1>
<sect1><title>Memory Requirements </title>
<para>The memory of the server has to be large enough to fit the
cache and zones loaded off disk. Future releases of <acronym>BIND</acronym> 9 will
provide methods to limit the amount of memory used by the cache,
at the expense of reducing cache hit rates and causing more <acronym>DNS</acronym>
traffic. It is still good practice to have enough memory to load
all zone and cache data into memory-unfortunately, the best way
to determine this for a given installation is to watch the nameserver
in operation. After a few weeks the server process should reach
a relatively stable size where entries are expiring from the cache as
fast as they are being inserted. Ideally, the resource limits should
be set higher than this stable size.</para></sect1>
<sect1><title>Nameserver Intensive Environment Issues</title>
<para>For nameserver intensive environments, there are two alternative
configurations that may be used. The first is where clients and
any second-level internal nameservers query a main nameserver, which
has enough memory to build a large cache. This approach minimizes
the bandwidth used by external name lookups. The second alternative
is to set up second-level internal nameservers to make queries independently.
In this configuration, none of the individual machines needs to
have as much memory or CPU power as in the first alternative, but
this has the disadvantage of making many more external queries,
as none of the nameservers share their cached data.</para></sect1>
<sect1><title>Supported Operating Systems</title>
<para>ISC <acronym>BIND</acronym> 9 compiles and runs on the following operating
systems:</para>
<itemizedlist>
<listitem>
<simpara>IBM AIX 4.3</simpara>
</listitem>
<listitem>
<simpara>Compaq Digital/Tru64 UNIX 4.0D</simpara>
</listitem>
<listitem>
<simpara>HP HP-UX 11</simpara>
</listitem>
<listitem>
<simpara>IRIX64 6.5</simpara>
</listitem>
<listitem>
<simpara>Red Hat Linux 6.0, 6.1</simpara>
</listitem>
<listitem>
<simpara>Sun Solaris 2.6, 7, 8 (beta)</simpara>
</listitem>
<listitem>
<simpara>FreeBSD 3.4-STABLE</simpara>
</listitem>
<listitem>
<simpara>NetBSD-current with "unproven" pthreads</simpara>
</listitem>
</itemizedlist>
</sect1>
</chapter>
\ No newline at end of file
<chapter>
<title>Nameserver Configuration</title>
<para>In this section we provide some suggested configurations along
with guidelines for their use. We also address the topic of reasonable
option setting.</para>
<sect1>
<title id="sample_configuration">Sample Configurations</title>
<sect2>
<title>A Caching-only Nameserver</title>
<para>The following sample configuration is appropriate for a caching-only
name server for use by clients internal to a corporation. All queries
from outside clients are refused.</para>
<programlisting>
// Two corporate subnets we wish to allow queries from.
acl "corpnets" { 192.168.4.0/24; 192.168.7.0/24; };
options {
directory "/etc/namedb"; // Working directory
pid-file "named.pid"; // Put pid file in working dir
allow-query { "corpnets"; };
};
// Root server hints
zone "." { type hint; file "root.hint"; };
// Provide a reverse mapping for the loopback address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
notify no;
};
</programlisting>
</sect2>
<sect2>
<title>An Authoritative-only Nameserver</title>
<para>This sample configuration is for an authoritative-only server
that is the master server for "<filename>example.com</filename>"
and a slave for the subdomain "<filename>eng.example.com</filename>".</para>
<programlisting>
options {
directory "/etc/namedb"; // Working directory
pid-file "named.pid"; // Put pid file in working dir
allow-query { any; }; // This is the default
recursion no; // Do not provide recursive service
};
// Root server hints
zone "." { type hint; file "root.hint"; };
// Provide a reverse mapping for the loopback address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
notify no;
};
// We are the master server for example.com
zone "example.com" {
type master;
file "example.com.db";
// IP addresses of slave servers allowed to transfer example.com
allow-transfer {
192.168.4.14;
192.168.5.53;
};
};
// We are a slave server for eng.example.com
zone "eng.example.com" {
type slave;
file "eng.example.com.bk";
// IP address of eng.example.com master server
masters { 192.168.4.12; };
};
</programlisting>
</sect2>
</sect1>
<sect1>
<title>Load Balancing</title>
<para>Primitive load balancing can be achieved in <acronym>DNS</acronym> using multiple
A records for one name.</para>
<para>For example, if you have three WWW servers with network addresses
of 10.0.0.1, 10.0.0.2 and 10.0.0.3, a set of records such as the
following means that clients will connect to each machine one third
of the time:</para>
<informaltable colsep = "0" rowsep = "0">
<tgroup cols = "5" colsep = "0" rowsep = "0"
tgroupstyle = "2Level-table">
<colspec colname = "1" colnum = "1" colsep = "0" colwidth = "0.875in"/>
<colspec colname = "2" colnum = "2" colsep = "0" colwidth = "0.500in"/>
<colspec colname = "3" colnum = "3" colsep = "0" colwidth = "0.750in"/>
<colspec colname = "4" colnum = "4" colsep = "0" colwidth = "0.750in"/>
<colspec colname = "5" colnum = "5" colsep = "0" colwidth = "2.028in"/>
<tbody>
<row rowsep = "0">
<entry colname = "1"><para>Name</para></entry>
<entry colname = "2"><para>TTL</para></entry>
<entry colname = "3"><para>CLASS</para></entry>
<entry colname = "4"><para>TYPE</para></entry>
<entry colname = "5"><para>Resource Record (RR) Data</para></entry>
</row>
<row rowsep = "0">
<entry colname = "1"><para><literal>www</literal></para></entry>
<entry colname = "2"><para><literal>600</literal></para></entry>
<entry colname = "3"><para><literal>IN</literal></para></entry>
<entry colname = "4"><para><literal>A</literal></para></entry>
<entry colname = "5"><para><literal>10.0.0.1</literal></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1"><para></para></entry>
<entry colname = "2"><para><literal>600</literal></para></entry>
<entry colname = "3"><para><literal>IN</literal></para></entry>
<entry colname = "4"><para><literal>A</literal></para></entry>
<entry colname = "5"><para><literal>10.0.0.2</literal></para></entry>
</row>
<row rowsep = "0">
<entry colname = "1"><para></para></entry>
<entry colname = "2"><para><literal>600</literal></para></entry>
<entry colname = "3"><para><literal>IN</literal></para></entry>
<entry colname = "4"><para><literal>A</literal></para></entry>
<entry colname = "5"><para><literal>10.0.0.3</literal></para></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>When a resolver queries for these records, <acronym>BIND</acronym> will rotate
them and respond to the query with the records in a different
order. In the example above, clients will randomly receive
records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients
will use the first record returned and discard the rest.</para>
<para>For more detail on ordering responses, check the
<command>rrset-order</command> substatement in the
<command>options</command> statement, <xref
linkend="rrset_ordering"/>. This substatement is not supported in
<acronym>BIND</acronym> 9, and only the ordering scheme described above is
available.</para>
</sect1>
<sect1>
<title id="notify">Notify</title>
<para><acronym>DNS</acronym> Notify is a mechanism that allows master nameservers to
notify their slave servers of changes to a zone's data. In
response to a <command>NOTIFY</command> from a master server, the
slave will check to see that its version of the zone is the
current version and, if not, initiate a transfer.</para> <para><acronym>DNS</acronym>
Notify is fully documented in RFC 1996. See also the description
of the zone option <command>also-notify</command>, <xref
linkend="zone_transfers"/>. For more information about
<command>notify</command>, <xref
linkend="boolean_options"/>.</para>
</sect1>
<sect1>
<title>Nameserver Operations</title>
<sect2>
<title>Tools for Use With the Nameserver Daemon</title>
<para>There are several indispensable diagnostic, administrative
and monitoring tools available to the system administrator for controlling
and debugging the nameserver daemon. We describe several in this
section </para>
<sect3>
<title>Diagnostic Tools</title>
<variablelist>
<varlistentry>
<term><command>dig</command></term>
<listitem>
<para>The domain information groper (<command>dig</command>) is
a command line tool that can be used to gather information from
the Domain Name System servers. Dig has two modes: simple interactive
mode for a single query, and batch mode which executes a query for
each in a list of several query lines. All query options are accessible
from the command line.</para>
<cmdsynopsis label="Usage">
<command>dig</command>
<arg>@<replaceable>server</replaceable></arg>
<arg choice="plain"><replaceable>domain</replaceable></arg>
<arg><replaceable>query-type</replaceable></arg>
<arg><replaceable>query-class</replaceable></arg>
<arg>+<replaceable>query-option</replaceable></arg>
<arg>-<replaceable>dig-option</replaceable></arg>
<arg>%<replaceable>comment</replaceable></arg>
<!-- one of (SBR GROUP ARG COMMAND) -->
</cmdsynopsis>
<para>The usual simple use of dig will take the form</para>
<simpara><command>dig @server domain query-type query-class</command></simpara>
<para>For more information and a list of available commands and
options, see the <command>dig</command> man page.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><command>host</command></term>
<listitem>
<para>The <command>host</command> utility
provides a simple <acronym>DNS</acronym> lookup using a command-line interface for
looking up Internet hostnames. By default, the utility converts
between host names and Internet addresses, but its functionality
can be extended with the use of options.</para>
<cmdsynopsis label="Usage">
<!-- one of (SBR GROUP ARG COMMAND) -->
<command>host</command>
<arg>-aCdlrTwv</arg>
<arg>-c <replaceable>class</replaceable></arg>
<arg>-N <replaceable>ndots</replaceable></arg>
<arg>-t <replaceable>type</replaceable></arg>
<arg>-W <replaceable>timeout</replaceable></arg>
<arg>-R <replaceable>retries</replaceable></arg>
<arg choice="plain"><replaceable>hostname</replaceable></arg>
<arg><replaceable>server</replaceable></arg>
</cmdsynopsis>
<para>For more information and a list of available commands and
options, see the <command>host</command> man page.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><command>nslookup</command></term>
<listitem>
<para><command>nslookup</command> is a program used to query Internet
domain nameservers. <command>nslookup</command> has two modes: interactive
and non-interactive. Interactive mode allows the user to query nameservers
for information about various hosts and domains or to print a list
of hosts in a domain. Non-interactive mode is used to print just
the name and requested information for a host or domain.</para>
<cmdsynopsis label="Usage">
<command>nslookup</command>
<arg rep="repeat">-option</arg>
<group>
<arg><replaceable>host-to-find</replaceable></arg>
<arg>- <arg>server</arg></arg>
</group>
</cmdsynopsis>
<para>Interactive mode is entered when no arguments are given (the
default nameserver will be used) or when the first argument is a
hyphen (`-') and the second argument is the host name or Internet address
of a nameserver.</para>
<para>Non-interactive mode is used when the name or Internet address
of the host to be looked up is given as the first argument. The
optional second argument specifies the host name or address of a nameserver.</para>
<para>Due to its arcane user interface and frequently inconsistent
behavior, we do not recommend the use of <command>nslookup</command>.
Use <command>dig</command> instead.</para>
</listitem>
</varlistentry>
</variablelist>
</sect3>
<sect3>
<title>Administrative Tools</title>
<para>Administrative tools play an integral part in the management
of a server.</para>
<variablelist>
<varlistentry>
<term><command id="rndc">rndc</command></term>
<listitem>
<para>The remote name daemon control
(<command>rndc</command>) program allows the system
administrator to control the operation of a nameserver.
If you run <command>rndc</command> without any options
it will display a usage message as follows:</para>
<cmdsynopsis label="Usage">
<command>rndc</command>
<arg>-c <replaceable>config</replaceable></arg>
<arg>-s <replaceable>server</replaceable></arg>
<arg>-p <replaceable>port</replaceable></arg>
<arg>-y <replaceable>key</replaceable></arg>
<arg choice="plain"><replaceable>command</replaceable></arg>
<arg rep="repeat"><replaceable>command</replaceable></arg>
</cmdsynopsis>
<para><command>command</command> is one of the following
for <command>named</command>:</para>
<informaltable colsep = "0" rowsep = "0">
<tgroup cols = "2"
colsep = "0" rowsep = "0" tgroupstyle = "4Level-table">
<colspec colname = "1" colnum = "1"
colsep = "0" colwidth = "1.500in"/>
<colspec colname = "2" colnum = "2" colsep = "0"
colwidth = "3.000in"/>
<tbody>
<row rowsep = "0">
<entry colname = "1">
<para><userinput>status</userinput><footnote id="nyi1">
<para>not yet implemented</para>
</footnote></para></entry>
<entry colname = "2"><para>Display ps(1) status of named.</para></entry>
</row>
<row rowsep = "0">
<entry colname = "1"><para><userinput>dumpdb</userinput><footnoteref linkend="nyi1"/></para></entry>
<entry colname = "2"><para>Dump database and cache to /var/tmp/named_dump.db.</para></entry>
</row>
<row rowsep = "0">
<entry colname = "1"><para><userinput>reload</userinput></para></entry>
<entry colname = "2"><para>Reload configuration file and zones.</para></entry>