Applies To:

Show Versions Show Versions

Archived Manual Chapter: 3-DNS Administrator Guide v1.0.6: BIND 8 Configuration Information
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

This article has been archived, and is no longer maintained.



E

BIND 8 Configuration Information



BIND 8 overview

Although you can use earlier versions of BIND (version 4.97 and later), F5 Networks recommends that you use BIND 8.1.2 or later with the 3DNS Controller.

For more information on BIND, refer to the Internet Software Consortium Web site at www.isc.org.

BIND 8 has the advantage of being more configurable than earlier versions of BIND. New areas of configuration, such as access control lists (ACLs) and categorized logging, are now available. You can selectively apply more options, rather than being required to apply options to all zones. To incorporate this new technology and provide for future enhancements, BIND 8 requires a new format for configuration files.

A BIND 8 configuration file consists of two types of information: statements and comments. Both of these are described in the following sections.

Statements

BIND statements end with a semicolon. Statements can contain blocks of sub-statements, which are also terminated with a semicolon.

The following statements are supported:

Statement Description
acl Defines a named IP address matching list, for access control and other uses.
include Includes a file.
key Specifies key information for use in authentication and authorization.
logging Specifies what the server logs, and where the log messages are sent. This statement may only be used once per configuration.
options Controls global server configuration options and sets defaults for other statements. This statement may only be used once per configuration.
server Sets certain configuration options on a per-server basis.
zone Defines a zone.

acl statement

The acl statement creates a named address match list. It gets its name from a primary use of address match lists: Access Control Lists (ACLs).

Note that an address match list's name must be defined with acl before it can be used elsewhere; no forward references are allowed.

The following ACLs are built in:

ACL Description
any Allows all hosts.
none Denies all hosts.
localhost Allows the IP addresses of all interfaces on the system.
localnets Allows any host on a network for which the system has an interface.

Syntax

   acl <name> {   

address_match_list

};

include statement

The include statement inserts the specified file at the point where the include statement is encountered. It cannot be used within another statement, though, so a line such as the following is not allowed:

   acl internal_hosts {"include internal_hosts.acl"}   

Use include to break the configuration up into easily-managed chunks. For example, the following lines could be inserted at the top of a BIND configuration file in order to include ACL and key information:

      

include "/etc/security/keys.bind";

include "/etc/acls.bind";

Be careful not to type #include, as you would in a C program, because # is used to start a comment.

Syntax

   include <path_name>   

key statement

The key statement defines a key ID which can be used in a server statement to associate an authentication method with a particular name server.

The key statement is intended for future use by the server. It is checked for syntax but is otherwise ignored.

Syntax

  key <key_id>{   

algorithm <algorithm_id>;

secret <secret_string>;

};

logging statement

The logging statement configures a wide variety of logging options for the name server.

Syntax

  logging {   

[ channel <channel_name> {

( file <path_name>

[ versions ( number | unlimited ) ]

[ size <size_spec> ]

| syslog ( kern | user | mail | daemon |

auth | syslog | lpr |

news | uucp | cron | authpriv | ftp |

local0 | local1 | local2 | local3 |

local4 | local5 | local6 | local7 )

| null );

[ severity ( critical | error | warning|notice |

info | debug [ level ] | dynamic ); ]

[ print-category <yes | no>; ]

[ print-severity <yes | no>; ]

[ print-time <yes | no>; ]

}; ]

[ category <category_name> {

<channel_name>; [ <channel_name>; ... ]

}; ]

...

};

options statement

The options statement sets up global options to be used by BIND. This statement should appear only once in a configuration file; if BIND finds more than one occurrence, BIND honors the first. When this happens, BIND generates a warning alerting you that your configuration contains multiple options statements. If BIND does not find an options statement in the configuration file, BIND uses an options block, with each option set to its default.

Syntax

   options {   

[ directory <path_name>; ]

[ named-xfer <path_name>; ]

[ dump-file <path_name>; ]

[ memstatistics-file <path_name>; ]

[ pid-file <path_name>; ]

[ statistics-file <path_name>; ]

[ auth-nxdomain <yes | no>; ]

[ deallocate-on-exit <yes | no>; ]

[ fake-iquery <yes | no>; ]

[ fetch-glue <yes | no>; ]

[ host-statistics <yes | no>; ]

[ multiple-cnames <yes | no>; ]

[ notify <yes | no>; ]

[ recursion <yes | no>; ]

[ forward ( only | first ); ]

[ forwarders { [<in_addr>;[<in_addr>;...]]};]

[ check-names (master | slave | response )

( warn | fail | ignore); ]

[ allow-query { <address_match_list> }; ]

[ allow-transfer { <address_match_list> }; ]

[ listen-on [ port <ip_port> ]

{ <address_match_list> }; ]

[ query-source [ address ( <ip_addr> | * ) ]

[ port ( <ip_port> | * ) ] ; ]

[ max-transfer-time-in <number>; ]

[ transfer-format (one-answer|many-answers);]

[ transfers-in <number>; ]

[ transfers-out <number>; ]

[ transfers-per-ns <number>; ]

[ coresize <size_spec> ; ]

[ datasize <size_spec> ; ]

[ files <size_spec> ; ]

[ stacksize <size_spec> ; ]

[ cleaning-interval <number>; ]

[ interface-interval <number>; ]

[ statistics-interval <number>; ]

[ topology { <address_match_list> }; ]

};

server statement

The server statement defines the characteristics associated with a remote name server.

Syntax

   server <ip_addr> {   

[ bogus <yes | no>; ]

[ transfers <number>; ]

[ transfer-format (one-answer|many-answers);]

[ keys { <key_id> [key_id ... ] }; ]

};

zone statement

The zone statement defines a zone.

Syntax

  zone <domain_name> [ ( in|hs|hesiod|chaos )]{   

type master;

file <path_name>;

[ check-names ( warn | fail | ignore ); ]

[ allow-update { <address_match_list> }; ]

[ allow-query { <address_match_list> }; ]

[ allow-transfer { <address_match_list> }; ]

[ notify <yes | no>; ]

[ also-notify { <ip_addr>; [ <ip_addr>;...]};

};

zone <domain_name> [ ( in|hs|hesiod|chaos) ] {

type ( slave | stub );

[ file <path_name>; ]

masters { <ip_addr>; [ <ip_addr>; ... ] };

[ check-names ( warn | fail | ignore ); ]

[ allow-update { <address_match_list> }; ]

[ allow-query { <address_match_list> }; ]

[ allow-transfer { <address_match_list> }; ]

[ max-transfer-time-in <number>; ]

[ notify <yes | no>; ]

[ also-notify { <ip_addr>; [ <ip_addr>;...]};

};

zone "." [ ( in | hs | hesiod | chaos ) ] {

type hint;

file <path_name>;

[ check-names ( warn | fail | ignore ); ]

};

Comments

BIND 8 comments follow syntax rules that are similar to the 3DNS Controller comments syntax rules.

You can insert comments anywhere you would otherwise see white space in a BIND configuration file.

Syntax

Note that the comment syntax depends on the environment in which you use the configuration file. For example:

  /* This is a BIND comment as in C */   

// This is a BIND comment as in C++

# This is a BIND comment as in common Unix shells and Perl

Definition and usage

The format for comments varies by programming language; each format is described below.

C style comments

C style comments start with the slash character, followed by the asterisk character (/*), and end with the asterisk character, followed with the slash character (*/). Because the comment is completely delimited with these characters, a comment can span multiple lines.

Note that C style comments cannot be nested. For example, the following is not valid because the entire comment ends with the first */:

   /* This is the start of a comment.   

This is still part of the comment.

/* This is an incorrect attempt to nest a comment. */

This is no longer in any comment. */

C++ style comments

C++ style comments start with two slash characters (//) and are no longer than one line in length. To have one logical comment span multiple lines, each line must start with the // pair.

For example:

   // This is the start of a comment. The next line   

// is a new comment line, even though it is

// logically part of the previous comment.

Shell style comments

Shell style (also known as Perl style) comments start with the "#" character and are no longer than one line in length.

For example:

  # This is the start of a comment. The next line   

# is a new comment line, even though it is logically

# part of the previous comment.

Warning: You cannot use the semicolon (;) character to start a comment such as you would in a zone file. The semicolon indicates the end of a configuration statement. Text following a semicolon is interpreted as the start of the next statement.

Converting older configuration files to BIND 8 format

You can convert BIND 4.9.x configuration files to the BIND 8 format using src/bin/named/named-bootconf.pl, a Perl script that is part of the BIND 8.1 source kit.

Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)