cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"

0c27b3fe77ac1d5094ba3521e8142d9e7973133fMark Andrews "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"

40f53fa8d9c6a4fc38c0014495e7a42b08f52481David Lawrence [<!ENTITY mdash "&#8212;">]>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence

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

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <title>BIND 9 Administrator Reference Manual</title>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence

40f53fa8d9c6a4fc38c0014495e7a42b08f52481David Lawrence <bookinfo>

40f53fa8d9c6a4fc38c0014495e7a42b08f52481David Lawrence <copyright>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <year>2004</year>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <year>2005</year>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <year>2006</year>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <year>2007</year>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <year>2008</year>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <year>2009</year>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <year>2010</year>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <year>2011</year>

0c27b3fe77ac1d5094ba3521e8142d9e7973133fMark Andrews <holder>Internet Systems Consortium, Inc. ("ISC")</holder>

0c27b3fe77ac1d5094ba3521e8142d9e7973133fMark Andrews </copyright>

f05a4bf2bfac3aaff0462560b2793cd99a85a297Mark Andrews <copyright>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <year>2000</year>

f05a4bf2bfac3aaff0462560b2793cd99a85a297Mark Andrews <year>2001</year>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <year>2002</year>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <year>2003</year>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence <holder>Internet Software Consortium.</holder>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence </copyright>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence </bookinfo>

cb73e2bfacb60eed27a3e4940f6dbe0c0580fc18David Lawrence

<chapter id="Bv9ARM.ch01">

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

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

</para>

</sect1>

<sect1>

<title>Organization of This Document</title>

<para>

In this document, <emphasis>Chapter 1</emphasis> introduces

the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Chapter 2</emphasis>

describes resource requirements for running <acronym>BIND</acronym> in various

environments. Information in <emphasis>Chapter 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>Chapter 4</emphasis>, which contains more advanced

concepts that the system administrator may need for implementing

certain options. <emphasis>Chapter 5</emphasis>

describes the <acronym>BIND</acronym> 9 lightweight

resolver. The contents of <emphasis>Chapter 6</emphasis> are

organized as in a reference manual to aid in the ongoing

maintenance of the software. <emphasis>Chapter 7</emphasis> addresses

security considerations, and

<emphasis>Chapter 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> (Berkeley Internet

Name Domain) 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 a resolver

library, <command>liblwres</command>. The older

<command>libbind</command> resolver library is also available

from ISC as a separate download.

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

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> option 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 systems and on

Microsoft Windows Server 2003 and 2008, and Windows XP and Vista.

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

// Working directory

directory "/etc/namedb";

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 {

// Working directory

directory "/etc/namedb";

// Do not allow access to cache

allow-query-cache { none; };

// This is the default

allow-query { any; };

// Do not provide recursive service

recursion no;

};

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

(such as 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> sub-statement 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 <command>dig</command> 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>-aCdlnrsTwv</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>-m <replaceable>flag</replaceable></arg>

<arg>-4</arg>

<arg>-6</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 application">

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

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

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>The <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>sign <replaceable>zone</replaceable>

<optional><replaceable>class</replaceable>

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

<listitem>

<para>

Fetch all DNSSEC keys for the given zone

from the key directory (see

<command>key-directory</command> in

<xref linkend="options"/>). If they are within

their publication period, merge them into the

zone's DNSKEY RRset. If the DNSKEY RRset

is changed, then the zone is automatically

re-signed with the new key set.

</para>

<para>

This command requires that the

<command>auto-dnssec</command> zone option be set

to <literal>allow</literal> or

<literal>maintain</literal>,

and also requires the zone to be configured to

allow dynamic DNS.

See <xref linkend="dynamic_update_policies"/> for

more details.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>loadkeys <replaceable>zone</replaceable>

<optional><replaceable>class</replaceable>

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

<listitem>

<para>

Fetch all DNSSEC keys for the given zone

from the key directory (see

<command>key-directory</command> in

<xref linkend="options"/>). If they are within

their publication period, merge them into the

zone's DNSKEY RRset. Unlike <command>rndc

sign</command>, however, the zone is not

immediately re-signed by the new keys, but is

allowed to incrementally re-sign over time.

</para>

<para>

This command requires that the

<command>auto-dnssec</command> zone option

be set to <literal>maintain</literal>,

and also requires the zone to be configured to

allow dynamic DNS.

See <xref linkend="dynamic_update_policies"/> for

more details.

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

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

the zone has changed and the

<command>ixfr-from-differences</command> option is

in use, then the journal file will be updated to

reflect changes in the zone. Otherwise, if the

zone has changed, any existing journal file will be

removed.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>sync

<optional>-clean</optional>

<optional><replaceable>zone</replaceable>

<optional><replaceable>class</replaceable>

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

<listitem>

<para>

Sync changes in the journal file for a dynamic zone

to the master file. If the "-clean" option is

specified, the journal file is also removed. If

no zone is specified, then all zones are synced.

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

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

<listitem>

<para>

Dump the server's security roots to the secroots

file for the specified views. If no view is

specified, security roots for 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 <option>-p</option> is specified <command>named</command>'s process id is returned.

This allows an external process to determine when <command>named</command>

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 <option>-p</option> is specified <command>named</command>'s process id is returned.

This allows an external process to determine when <command>named</command>

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>

<optional><replaceable>view</replaceable></optional>

</term>

<listitem>

<para>

Flushes the given name from the server's DNS cache,

and from the server's nameserver address database

if applicable.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>flushtree</userinput>

<replaceable>name</replaceable>

<optional><replaceable>view</replaceable></optional>

</term>

<listitem>

<para>

Flushes the given name, and all of its subdomains,

from the server's DNS cache. (The server's

nameserver address database is not affected.)

</para>

</listitem>

</varlistentry>

<varlistentry>

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

<listitem>

<para>

Display status of the server.

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

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

hint zone if there is not an

explicit root zone configured.

</para>

</listitem>

</varlistentry>

<varlistentry>

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

<listitem>

<para>

Dump the list of queries <command>named</command> is currently recursing

on.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>validation

<optional>on|off</optional>

<optional><replaceable>view ...</replaceable></optional>

</userinput></term>

<listitem>

<para>

Enable or disable DNSSEC validation.

Note <command>dnssec-enable</command> also needs to be

set to <userinput>yes</userinput> to be effective.

It defaults to enabled.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>tsig-list</userinput></term>

<listitem>

<para>

List the names of all TSIG keys currently configured

for use by <command>named</command> in each view. The

list both statically configured keys and dynamic

TKEY-negotiated keys.

</para>

</listitem>

</varlistentry>

<varlistentry>

<term><userinput>tsig-delete</userinput>

<replaceable>keyname</replaceable>

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

<listitem>

<para>

Delete a given TKEY-negotated key from the server.

(This does not apply to statically configured TSIG

keys.)