dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd"

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington [<!ENTITY mdash "&#8212;">]>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington<book xmlns:xi="http://www.w3.org/2001/XInclude">

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <title>BIND 9 Administrator Reference Manual</title>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <bookinfo>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <copyright>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <year>2004</year>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <year>2005</year>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <holder>Internet Systems Consortium, Inc. ("ISC")</holder>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington </copyright>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <copyright>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <year>2000</year>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <year>2001</year>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <year>2002</year>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <year>2003</year>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <holder>Internet Software Consortium.</holder>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington </copyright>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <xi:include href="releaseinfo.xml"/>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <releaseinfo>$Revision: 1.275 $</releaseinfo>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington </bookinfo>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <chapter id="Bv9ARM.ch01">

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <title>Introduction</title>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington <para>

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington The Internet Domain Name System (<acronym>DNS</acronym>)

dcc6bde0a3c6580514675c59f8ffa499cee8f7c5Brian Wellington 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

domain name server for a number of operating systems. This

document provides basic information about the installation and

care of the Internet Systems Consortium (<acronym>ISC</acronym>)

<acronym>BIND</acronym> version 9 software package for

system administrators.

</para>

<para>

This version of the manual corresponds to BIND version 9.4.

</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. <emphasis>Section 5</emphasis>

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>

<tgroup cols="2">

<colspec colname="1" colnum="1" colwidth="3.000in"/>

<colspec colname="2" colnum="2" colwidth="2.625in"/>

<tbody>

<row>

<entry colname="1">

<para>

<emphasis>To describe:</emphasis>

</para>

</entry>

<entry colname="2">

<para>

<emphasis>We use the style:</emphasis>

</para>

</entry>

</row>

<row>

<entry colname="1">

<para>

a pathname, filename, URL, hostname,

mailing list name, or new term or concept

</para>

</entry>

<entry colname="2">

<para>

<filename>Fixed width</filename>

</para>

</entry>

</row>

<row>

<entry colname="1">

<para>

literal user

input

</para>

</entry>

<entry colname="2">

<para>

<userinput>Fixed Width Bold</userinput>

</para>

</entry>

</row>

<row>

<entry colname="1">

<para>

program output

</para>

</entry>

<entry colname="2">

<para>

<computeroutput>Fixed Width</computeroutput>

</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>Fixed Width</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>Fixed Width</varname>

</para>

</entry>

</row>

<row rowsep="0">

<entry colname="1" colsep="1">

<para>

Optional input

</para>

</entry>

<entry colname="2">

<para>

<optional>Text is enclosed in square brackets</optional>

</para>

</entry>

</row>

</tbody>

</tgroup>

</informaltable>

</para>

</sect1>

<sect1>

<title>The Domain Name System (<acronym>DNS</acronym>)</title>

<para>

The purpose of this document is to explain the installation

and upkeep of the <acronym>BIND</acronym> software

package, and we

begin by reviewing the fundamentals of the Domain Name System

(<acronym>DNS</acronym>) as they relate to <acronym>BIND</acronym>.

</para>

<sect2>

<title>DNS Fundamentals</title>

<para>

The Domain Name System (DNS) is a hierarchical, distributed

database. It stores information for mapping Internet host names to

IP

addresses and vice versa, mail routing information, and other data

used by Internet applications.

</para>

<para>

Clients look up information in the DNS by calling a

<emphasis>resolver</emphasis> library, which sends queries to one or

more <emphasis>name servers</emphasis> and interprets the responses.

The <acronym>BIND</acronym> 9 software distribution

contains a

name server, <command>named</command>, and two resolver

libraries, <command>liblwres</command> and <command>libbind</command>.

</para>

</sect2><sect2>

<title>Domains and Domain Names</title>

<para>

The data stored in the DNS is identified by <emphasis>domain names</emphasis> that are organized as a tree according to

organizational or administrative boundaries. Each node of the tree,

called a <emphasis>domain</emphasis>, is given a label. The domain

name of the

node is the concatenation of all the labels on the path from the

node to the <emphasis>root</emphasis> node. 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 parent

domain.

</para>

<para>

For example, a domain name for a host at the

company <emphasis>Example, Inc.</emphasis> could be

<literal>ourhost.example.com</literal>,

where <literal>com</literal> is the

top level domain to which

<literal>ourhost.example.com</literal> belongs,

<literal>example</literal> is

a subdomain of <literal>com</literal>, and

<literal>ourhost</literal> is the

name of the host.

</para>

<para>

For administrative purposes, the name space is partitioned into

areas called <emphasis>zones</emphasis>, each starting at a node and

extending down to the leaf nodes or to nodes where other zones

start.

The data for each zone is stored in a <emphasis>name server</emphasis>, which answers queries about the zone using the

<emphasis>DNS protocol</emphasis>.

</para>

<para>

The data associated with each domain name is stored in the

form of <emphasis>resource records</emphasis> (<acronym>RR</acronym>s).

Some of the supported resource record types are described in

<xref linkend="types_of_resource_records_and_when_to_use_them"/>.

</para>

<para>

For more detailed information about the design of the DNS and

the DNS protocol, please refer to the standards documents listed in

<xref linkend="rfcs"/>.

</para>

</sect2>

<sect2>

<title>Zones</title>

<para>

To properly operate a name server, it is important to understand

the difference between a <emphasis>zone</emphasis>

and a <emphasis>domain</emphasis>.

</para>

<para>

As 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 name 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 is marked by one or more

<emphasis>NS records</emphasis> in the

parent zone, which should be matched by equivalent NS records at

the root of the delegated zone.

</para>

<para>

For instance, consider the <literal>example.com</literal>

domain which includes names

such as <literal>host.aaa.example.com</literal> and

<literal>host.bbb.example.com</literal> even though

the <literal>example.com</literal> zone includes

only delegations for the <literal>aaa.example.com</literal> and

<literal>bbb.example.com</literal> 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

name servers. 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 called a "domain name

server",

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>

</sect2>

<sect2>

<title>Authoritative Name Servers</title>

<para>

Each zone is served by at least

one <emphasis>authoritative name server</emphasis>,

which contains the complete data for the zone.

To make the DNS tolerant of server and network failures,

most zones have two or more authoritative servers, on

different networks.

</para>

<para>

Responses from authoritative servers have the "authoritative

answer" (AA) bit set in the response packets. This makes them

easy to identify when debugging DNS configurations using tools like

<command>dig</command> (<xref linkend="diagnostic_tools"/>).

</para>

<sect3>

<title>The Primary Master</title>

<para>

The authoritative server where the master copy of the zone

data is maintained is called the

<emphasis>primary master</emphasis> server, or simply the

<emphasis>primary</emphasis>. Typically it 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. This file is called the

<emphasis>zone file</emphasis> or

<emphasis>master file</emphasis>.

</para>

<para>

In some cases, however, the master file may not be edited

by humans at all, but may instead be the result of

<emphasis>dynamic update</emphasis> operations.

</para>

</sect3>

<sect3>

<title>Slave Servers</title>

<para>

The other authoritative servers, the <emphasis>slave</emphasis>

servers (also known as <emphasis>secondary</emphasis> servers)

load

the zone contents from another server using a replication process

known as a <emphasis>zone transfer</emphasis>. Typically the data

are

transferred directly from the primary master, but it is also

possible

to transfer it from another slave. In other words, a slave server

may itself act as a master to a subordinate slave server.

</para>

</sect3>

<sect3>

<title>Stealth Servers</title>

<para>

Usually all of the zone's authoritative servers are listed in

NS records in the parent zone. These NS records constitute

a <emphasis>delegation</emphasis> of the zone from the parent.

The authoritative servers are also listed in the zone file itself,

at the <emphasis>top level</emphasis> or <emphasis>apex</emphasis>

of the zone. You can list servers in the zone's top-level 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 at

the zone's top level.

</para>

<para>

A <emphasis>stealth server</emphasis> is a server that is

authoritative for a zone but is not listed in that zone's NS

records. Stealth servers can be used for keeping a local copy of

a

zone to speed up access to the zone's records or to make sure that

the

zone is available even if all the "official" servers for the zone

are

inaccessible.

</para>

<para>

A configuration where the primary master server itself is a

stealth server is often referred to as a "hidden primary"

configuration. One use for this configuration is when the primary

master

is behind a firewall and therefore unable to communicate directly

with the outside world.

</para>

</sect3>

</sect2>

<sect2>

<title>Caching Name Servers</title>

<!--

<para>

The resolver libraries provided by most operating systems are

<emphasis>stub resolvers</emphasis>, meaning that they are not

capable of

performing the full DNS resolution process by themselves by talking

directly to the authoritative servers. Instead, they rely on a

local

name server to perform the resolution on their behalf. Such a

server

is called a <emphasis>recursive</emphasis> name server; it performs

<emphasis>recursive lookups</emphasis> for local clients.

</para>

<para>

To improve performance, recursive servers cache the results of

the lookups they perform. Since the processes of recursion and

caching are intimately connected, the terms

<emphasis>recursive server</emphasis> and

<emphasis>caching server</emphasis> are often used synonymously.

</para>

<para>

The length of time for which a record may be retained in

in the cache of a caching name server is controlled by the

Time To Live (TTL) field associated with each resource record.

</para>

<sect3>

<title>Forwarding</title>

<para>

Even a caching name server does not necessarily perform

the complete recursive lookup itself. Instead, it can

<emphasis>forward</emphasis> some or all of the queries

that it cannot satisfy from its cache to another caching name

server,

commonly referred to as a <emphasis>forwarder</emphasis>.

</para>

<para>

There may be one or more forwarders,

and they are queried in turn until the list is exhausted or an

answer

is found. Forwarders are typically used when you do not

wish all the servers at a given site to interact directly 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.

</para>

</sect3>

</sect2>

<sect2>

<title>Name Servers in Multiple Roles</title>

<para>

The <acronym>BIND</acronym> name server can

simultaneously act as

a master for some zones, a slave for other zones, and as a caching

(recursive) server for a set of local clients.

</para>

<para>

However, since the functions of authoritative name service

and caching/recursive name service are logically separate, it is

often advantageous to run them on separate server machines.

A server that only provides authoritative name service

(an <emphasis>authoritative-only</emphasis> server) can run with

recursion disabled, improving reliability and security.

A server that is not authoritative for any zones and only provides

recursive service to local

clients (a <emphasis>caching-only</emphasis> server)

does not need to be reachable from the Internet at large and can

be placed inside a firewall.

</para>

</sect2>

</sect1>

</chapter>

<chapter id="Bv9ARM.ch02">

<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 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 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. The <command>max-cache-size</command>

option can be used 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.

Additionally, if additional section caching

(<xref linkend="acache"/>) is enabled,

the <command>max-acache-size</command> can be used to

limit the amount

of memory used by the mechanism.

It is still good practice to have enough memory to load

all zone and cache data into memory &mdash; unfortunately, the best

way

to determine this for a given installation is to watch the name server

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.

</para>

<!--

</sect1>

<sect1>

<title>Name Server Intensive Environment Issues</title>

<para>

For name server intensive environments, there are two alternative

configurations that may be used. The first is where clients and

any second-level internal name servers query a main name server, 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 name servers 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 name servers share their cached data.

</para>

</sect1>

<sect1>

<title>Supported Operating Systems</title>

<para>

ISC <acronym>BIND</acronym> 9 compiles and runs on a large

number

of Unix-like operating system and on NT-derived versions of

Microsoft Windows such as Windows 2000 and Windows XP. For an

up-to-date

list of supported systems, see the README file in the top level

directory

of the BIND 9 source distribution.

</para>

</sect1>

</chapter>

<chapter id="Bv9ARM.ch03">

<title>Name Server Configuration</title>

<para>

In this section we provide some suggested configurations along

with guidelines for their use. We suggest reasonable values for

certain option settings.

</para>

<sect1 id="sample_configuration">

<title>Sample Configurations</title>

<sect2>

<title>A Caching-only Name Server</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 using the <command>allow-query</command>

option. Alternatively, the same effect could be achieved using

suitable

firewall rules.

</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

allow-query { corpnets; };

};

// 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 Name Server</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

allow-query-cache { none; }; // Do not allow access to cache

allow-query { any; }; // This is the default

recursion no; // Do not provide recursive service

};

// 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>

A primitive form of load balancing can be achieved in

the <acronym>DNS</acronym> by 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/>

</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/>

</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, see

<xref endterm="rrset_ordering_title" linkend="rrset_ordering"/>.

</para>

</sect1>

<sect1>

<title>Name Server Operations</title>

<sect2>

<title>Tools for Use With the Name Server Daemon</title>

<para>

This section describes several indispensable diagnostic,

administrative and monitoring tools available to the system

administrator for controlling and debugging the name server

daemon.

</para>

<sect3 id="diagnostic_tools">

<title>Diagnostic Tools</title>

<para>

The <command>dig</command>, <command>host</command>, and

<command>nslookup</command> programs are all command

line tools

for manually querying name servers. They differ in style and

output format.

</para>

<variablelist>

<varlistentry>

<term id="dig"><command>dig</command></term>

<listitem>

<para>

The domain information groper (<command>dig</command>)

is the most versatile and complete of these lookup tools.

It 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>

</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 emphasizes

simplicity

and ease of use. By default, it converts

between host names and Internet addresses, but its

functionality

can be extended with the use of options.

</para>

<cmdsynopsis label="Usage">

<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>

has two modes: interactive and

non-interactive. Interactive mode allows the user to

query name servers 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 name server will be used) or when the first argument

is a

hyphen (`-') and the second argument is the host name or

Internet address

of a name server.

</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 name server.

</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 id="admin_tools">

<title>Administrative Tools</title>

<para>

Administrative tools play an integral part in the management

of a server.

</para>

<variablelist>

<varlistentry id="named-checkconf" xreflabel="Named Configuration Checking application">

<term><command>named-checkconf</command></term>

<listitem>

<para>

The <command>named-checkconf</command> program

checks the syntax of a <filename>named.conf</filename> file.

</para>

<cmdsynopsis label="Usage">

<command>named-checkconf</command>

<arg>-jvz</arg>

<arg>-t <replaceable>directory</replaceable></arg>

<arg><replaceable>filename</replaceable></arg>

</cmdsynopsis>

</listitem>

</varlistentry>

<varlistentry id="named-checkzone" xreflabel="Zone Checking application">

<term><command>named-checkzone</command></term>

<listitem>

<para>

The <command>named-checkzone</command> program

checks a master file for

syntax and consistency.

</para>

<cmdsynopsis label="Usage">

<command>named-checkzone</command>

<arg>-djqvD</arg>

<arg>-c <replaceable>class</replaceable></arg>

<arg>-o <replaceable>output</replaceable></arg>

<arg>-t <replaceable>directory</replaceable></arg>

<arg>-w <replaceable>directory</replaceable></arg>

<arg>-k <replaceable>(ignore|warn|fail)</replaceable></arg>

<arg>-n <replaceable>(ignore|warn|fail)</replaceable></arg>

<arg>-W <replaceable>(ignore|warn)</replaceable></arg>

<arg choice="plain"><replaceable>zone</replaceable></arg>

<arg><replaceable>filename</replaceable></arg>

</cmdsynopsis>

</listitem>

</varlistentry>

<varlistentry id="named-compilezone" xreflabel="Zone Compilation aplication">

<term><command>named-compilezone</command></term>

<listitem>

<para>

Similar to <command>named-checkzone,</command> but

it always dumps the zone content to a specified file

(typically in a different format).

</para>

</listitem>

</varlistentry>

<varlistentry id="rndc" xreflabel="Remote Name Daemon Control application">

<term><command>rndc</command></term>

<listitem>

<para>

The remote name daemon control

(<command>rndc</command>) program allows the

system

administrator to control the operation of a name server.

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:

</para>

<variablelist>

<varlistentry>

<term><userinput>reload</userinput></term>

<listitem>

<para>

Reload configuration file and zones.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>reload <replaceable>zone</replaceable>

<optional><replaceable>class</replaceable>

<optional><replaceable>view</replaceable></optional></optional></userinput></term>

<listitem>

<para>

Reload the given zone.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>refresh <replaceable>zone</replaceable>

<optional><replaceable>class</replaceable>

<optional><replaceable>view</replaceable></optional></optional></userinput></term>

<listitem>

<para>

Schedule zone maintenance for the given zone.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>retransfer <replaceable>zone</replaceable>

<optional><replaceable>class</replaceable>

<optional><replaceable>view</replaceable></optional></optional></userinput></term>

<listitem>

<para>

Retransfer the given zone from the master.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>freeze

<optional><replaceable>zone</replaceable>

<optional><replaceable>class</replaceable>

<optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>

<listitem>

<para>

Suspend updates to a dynamic zone. If no zone is

specified

then all zones are suspended. This allows manual

edits to be made to a zone normally updated by dynamic

update. It

also causes changes in the journal file to be synced

into the master

and the journal file to be removed. All dynamic

update attempts will

be refused while the zone is frozen.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>thaw

<optional><replaceable>zone</replaceable>

<optional><replaceable>class</replaceable>

<optional><replaceable>view</replaceable></optional></optional></optional></userinput></term>

<listitem>

<para>

Enable updates to a frozen dynamic zone. If no zone

is

specified then all frozen zones are enabled. This

causes

the server to reload the zone from disk, and

re-enables dynamic updates

after the load has completed. After a zone is thawed,

dynamic updates

will no longer be refused.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>notify <replaceable>zone</replaceable>

<optional><replaceable>class</replaceable>

<optional><replaceable>view</replaceable></optional></optional></userinput></term>

<listitem>

<para>

Resend NOTIFY messages for the zone.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>reconfig</userinput></term>

<listitem>

<para>

Reload the configuration file and load new zones,

but do not reload existing zone files even if they

have changed.

This is faster than a full <command>reload</command> when there

is a large number of zones because it avoids the need

to examine the

modification times of the zones files.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>stats</userinput></term>

<listitem>

<para>

Write server statistics to the statistics file.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>querylog</userinput></term>

<listitem>

<para>

Toggle query logging. Query logging can also be enabled

by explicitly directing the <command>queries</command>

<command>category</command> to a

<command>channel</command> in the

<command>logging</command> section of

<filename>named.conf</filename> or by specifying

<command>querylog yes;</command> in the

<command>options</command> section of

<filename>named.conf</filename>.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>dumpdb

<optional>-all|-cache|-zone</optional>

<optional><replaceable>view ...</replaceable></optional></userinput></term>

<listitem>

<para>

Dump the server's caches (default) and / or zones to

the

dump file for the specified views. If no view is

specified all

views are dumped.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>stop <optional>-p</optional></userinput></term>

<listitem>

<para>

Stop the server, making sure any recent changes

made through dynamic update or IXFR are first saved to

the master files of the updated zones.

If -p is specified named's process id is returned.

This allows a external process to determine when named

had completed stopping.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>halt <optional>-p</optional></userinput></term>

<listitem>

<para>

Stop the server immediately. Recent changes

made through dynamic update or IXFR are not saved to

the master files, but will be rolled forward from the

journal files when the server is restarted.

If -p is specified named's process id is returned.

This allows a external process to determine when named

had completed halting.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>trace</userinput></term>

<listitem>

<para>

Increment the servers debugging level by one.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>trace <replaceable>level</replaceable></userinput></term>

<listitem>

<para>

Sets the server's debugging level to an explicit

value.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>notrace</userinput></term>

<listitem>

<para>

Sets the server's debugging level to 0.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>flush</userinput></term>

<listitem>

<para>

Flushes the server's cache.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>flushname</userinput> <replaceable>name</replaceable></term>

<listitem>

<para>

Flushes the given name from the server's cache.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>status</userinput></term>

<listitem>

<para>

Display status of the server.

Note the number of zones includes the internal <command>bind/CH</command> zone

and the default <command>/IN</command>

hint zone if there is not a

explicit root zone configured.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>recursing</userinput></term>

<listitem>

<para>

Dump the list of queries named is currently recursing

on.

</para>

</listitem>

</varlistentry>

</variablelist>

<para>

In <acronym>BIND</acronym> 9.2, <command>rndc</command>

supports all the commands of the BIND 8 <command>ndc</command>

utility except <command>ndc start</command> and

<command>ndc restart</command>, which were also

not supported in <command>ndc</command>'s

channel mode.

</para>

<para>

A configuration file is required, since all

communication with the server is authenticated with

digital signatures that rely on a shared secret, and

there is no way to provide that secret other than with a

configuration file. The default location for the

<command>rndc</command> configuration file is

<filename>/etc/rndc.conf</filename>, but an

alternate

location can be specified with the <option>-c</option>

option. If the configuration file is not found,

<command>rndc</command> will also look in

<filename>/etc/rndc.key</filename> (or whatever

<varname>sysconfdir</varname> was defined when

the <acronym>BIND</acronym> build was

configured).

The <filename>rndc.key</filename> file is

generated by

running <command>rndc-confgen -a</command> as

described in

<xref linkend="controls_statement_definition_and_usage"/>.

</para>

<para>

The format of the configuration file is similar to

that of <filename>named.conf</filename>, but

limited to

only four statements, the <command>options</command>,

<command>key</command>, <command>server</command> and

<command>include</command>

statements. These statements are what associate the

secret keys to the servers with which they are meant to

be shared. The order of statements is not

significant.

</para>

<para>

The <command>options</command> statement has

three clauses:

<command>default-server</command>, <command>default-key</command>,

and <command>default-port</command>.

<command>default-server</command> takes a

host name or address argument and represents the server

that will

be contacted if no <option>-s</option>

option is provided on the command line.

<command>default-key</command> takes

the name of a key as its argument, as defined by a <command>key</command> statement.

<command>default-port</command> specifies the

port to which

<command>rndc</command> should connect if no

port is given on the command line or in a

<command>server</command> statement.

</para>

<para>

The <command>key</command> statement defines an

key to be used

by <command>rndc</command> when authenticating

with

<command>named</command>. Its syntax is

identical to the

<command>key</command> statement in named.conf.

The keyword <userinput>key</userinput> is

followed by a key name, which must be a valid

domain name, though it need not actually be hierarchical;

thus,

a string like "<userinput>rndc_key</userinput>" is a valid

name.

The <command>key</command> statement has two

clauses:

<command>algorithm</command> and <command>secret</command>.

While the configuration parser will accept any string as the

argument

to algorithm, currently only the string "<userinput>hmac-md5</userinput>"

has any meaning. The secret is a base-64 encoded string

as specified in RFC 3548.

</para>

<para>

The <command>server</command> statement

associates a key

defined using the <command>key</command>

statement with a server.

The keyword <userinput>server</userinput> is followed by a

host name or address. The <command>server</command> statement

has two clauses: <command>key</command> and <command>port</command>.

The <command>key</command> clause specifies the

name of the key

to be used when communicating with this server, and the

<command>port</command> clause can be used to

specify the port <command>rndc</command> should

connect

to on the server.

</para>

<para>

A sample minimal configuration file is as follows:

</para>

<programlisting>

key rndc_key {

algorithm "hmac-md5";

secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";

};

options {

default-server 127.0.0.1;

default-key rndc_key;

};

</programlisting>

<para>

This file, if installed as <filename>/etc/rndc.conf</filename>,

would allow the command:

</para>

<para>

<prompt>$ </prompt><userinput>rndc reload</userinput>

</para>

<para>

to connect to 127.0.0.1 port 953 and cause the name server

to reload, if a name server on the local machine were

running with

following controls statements:

</para>

<programlisting>

controls {

inet 127.0.0.1 allow { localhost; } keys { rndc_key; };

};

</programlisting>

<para>

and it had an identical key statement for

<literal>rndc_key</literal>.

</para>

<para>

Running the <command>rndc-confgen</command>

program will

conveniently create a <filename>rndc.conf</filename>

file for you, and also display the

corresponding <command>controls</command>

statement that you need to

add to <filename>named.conf</filename>.

Alternatively,

you can run <command>rndc-confgen -a</command>

to set up

a <filename>rndc.key</filename> file and not

modify

<filename>named.conf</filename> at all.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><command>clients-per-query</command></term>

<term><command>max-clients-per-query</command></term>

<listitem>

<para><command>clients-per-query</command>