7. 'named.conf' Parameters

This chapter describes the BIND 9.3.x named.conf file which controls the behaviour and functionality of BIND. named.conf is the only file which is used by BIND - confusingly there are still many references to boot.conf which was used by BIND 4 - ignore them.

BIND releases include a list of the latest statements and options supported. This list is available in /usr/share/docs/bind-version/misc/options (redhat) or /usr/src/contrib/bind/doc/ (FreeBSD) and if you are using the Windows version it ain't there! Supported list for BIND 9.3.0.

BIND allows a daunting list of configuration entities. You need a small subset to get operational. Read the first two sections to get a feel for the things you need, it identifies the MINIMAL values (depending on your requirement). Check the samples section for configuration specific examples.

Note: We got fed-up with inconsistent terminology so we use the term clause to describe the structure that group together a set of related statements. We don't call 'em options or substatements(!) or phrases - just clauses and statements. Period. If you want to read more about our reasons. Full list of statements.

named.conf format, structure and overview
named.conf required zone files

The clauses supported by BIND are:

acl Access Control Lists. Defines one of more access control lists, groups of hosts or users identified by keys, that may be referenced in view and other clauses or statements.
controls Describes and controls access to the control channel used by the remote administrator when using the rndc utility.
include Neither a statement nor a clause. Included here for no particularly good reason. include can appear anywhere in a named.conf file either inside or outside a clause. Allows inclusion of external files into named.conf for administrative convenience or security reasons.
key Defines shared keys used to control and authenticate operations such as Dynamic DNS (DDNS) and the remote control channel (the controls clause).
logging Configures the location, level and type of logging that BIND performs. Unless you are using syslog you need a logging statement for BIND.
lwres Defines the properties of BIND when running as a lightweight resolver.
options Groups statements that control generic or global behavior and that have scope for all zones and views unless overridden within a zone, views or other clause.
server Defines the properties or behavior this server will use when accessing or responding to a defined remote server
trusted-keys
view Controls BIND functionality and behaviour based on the host address(es).
zone Defines the specific zones that your name server will support. In addition there are a number of special zones that you may need to include.

Statements Classification

We have also classified all the statements into the following groups:

  1. Queries - statements controlling query behavior
  2. Transfer - statements controlling zone transfer and DDNS behavior
  3. Operations - statements controlling operational behavior
  4. Security - statements controlling security behavior
  5. Statistics - statements controlling statistical logging behavior

A full list of all statements is here.

named.conf format, structure and overview

A named.conf file can contain comments and will contain a number of clauses which group together related statements which control the functionality and security of the BIND server.

BIND provides a number of comment formats as follows:

/* C style comment format needs opening and closing markers
** but allows multiple lines or */
/* single lines */
// C++ style comnents single line format no closing required
# PERL/SHELL style comments single lines no closing required

The whole named.conf file is parsed for completeness and correctness before use - this is a major change from previous releases of BIND. Prior to the availability of (or in the absence of) a valid logging clause failures use syslogd and are (depending on your syslog.conf file) typically written to /var/log/messages thereafter failures are written to any file(s) defined in your logging clause. There are some rules defined for the clause order for BIND 9. The general clause layout of a named.conf file is usually:

 // acl clause if required 
 // defining first avoids forward name references
 acl "name" {...}; 
 logging {...};
 // usually requires at least a file statement
 // unless you are using the system log
 options {...};
 // other clauses/statements (as required)
 // zones clauses including 'required' zones
 zone {...};
 ....
 zone {...};

If you are using view clause the order changes significantly:

 // acl clauses if required 
 // defining first avoids forward name references
 acl "name" {...}; 
 logging {...}
 // usually requires at least a file statement
 // unless you are using the system log
 options {...};
 // other clauses/statements (as required)
 view "first" {
  options{...};
 	// zones clauses including 'required' zones
  zone {...};
  .....
  zone {...};
 };
 view "second" {
  options {...};
  // zones clauses including 'required' zones
  zone {...};
  .....
  zone {...};
 };

BIND is very picky about opening and closing brackets/braces, semicolons and all the other separators defined in the formal 'grammars' below, you will see in the literature various ways to layout statements. These variations are simply attempts to minimise the chance of errors, they have no other significance. Use the method you feel most comfortable with.

named.conf required zone files

Depending on your requirements BIND needs a number of zone files to allow it to function properly - these are in addition to any zones files that explicitly describe master or slave zones:

root.servers This file (called named.ca or named.root in most distributions but renamed root.servers in this guide) defines a list of name servers (a.root-servers.net - m.root-servers.net) where BIND can get a list of TLD servers for the particular TLD e.g. .com - perhaps that's why its called hint. When a name server cannot resolve a query it uses the name server list obtained to provide a referral (if its an Iterative query) or to find an answer (if its a Recursive query). The root server file is defined using a normal zone clause with type hint as in the example below:
zone "." in{
  type hint;
  file "root.servers";
};

The 'zone "."' is short for the root zone and means any zone for which there is no locally defined zone (slave or master) or cached answer.

By convention this file is usually included as the first zone statement but there is no good reason for this - it may be placed anywhere suitable. If you are running an internal name service on a closed network you do not need the root.servers file or 'hint' zone. Even if the hint zone is not defined BIND 9 has a internal list which it uses.

The file supplied with any distribution will get out of date and can be updated from a number of locations including ICANN. You see numerous commentators advise that this file be updated every three months or so. This is not essential. The first thing that BIND does when loaded with a 'hint' zone' is to update the root-server list from one of the locations in the root.server file. It will log any discrepancies from the supplied file but carry on using its retrieved list. Other than extra log messages there seems little advantage in updating the root.server file unless BIND load time is vital. If you are curious to see a sample root.server file.

localhost This zone allows resolution of the name 'localhost' to the loopback address 127.0.0.1 when using the DNS server. Any query for 'localhost' from any host using the name server will return 127.0.0.1. localhost is used by many applications. On its face this may seem a little strange and you can either continue to treat the process as magic or get some understanding of how resolvers work. The localhost zone is defined as shown below
zone "localhost" in{
  type master;
  file "master.localhost";
};

In many examples and even the files supplied with BIND 9 a zone specific option allow-update statement is shown as allow-update (none;);. Since this is BIND 9's default mode it is not required and has been omitted.

An example master.localhost.

reverse-map Reverse mapping describes the process of translating an IP address to a host name. This process uses a special domain called IN-ADDR.ARPA and, if it is to be supported, requires a corresponding zone file. Reverse Mapping and the required zone files are described in detail.
0.0.127.IN-ADDR.ARPA This special zone allows reverse mapping of the loopback address 127.0.0.1 to satisfy applications which do reverse or double lookups. Any request for the address 127.0.0.1 using this name server will return the name localhost. On its face this may seem a little strange and you can either continue to treat the process as magic or get some understanding of how resolvers work and the unpleasant issue of reverse mapping. The 0.0.127.IN-ADDR.ARPA zone is defined as shown below
zone "0.0.127.in-addr.arpa" in{
  type master;
  file "localhost.rev";
};

In many examples and even the files supplied with BIND 9 a zone specific option allow-update statement is shown as allow-update (none;);. Since this is BIND 9's default mode it is not required and has been omitted.

An example localhost.rev.


Pro DNS and BIND by Ron Aitchison

Contents

tech info
guides home
dns articles
intro
contents
1 objectives
big picture
2 concepts
3 reverse map
4 dns types
quickstart
5 install bind
6 samples
reference
7 named.conf
8 dns records
operations
9 howtos
10 tools
11 trouble
programming
12 bind api's
security
13 dns security
bits & bytes
15 messages
resources
notes & tips
registration FAQ
dns resources
dns rfc's
change log