Manual Chapter : 3-DNS Administrator Guide v2.0: BIND 8 Information

Applies To:

Show Versions Show Versions

3-DNS Controller versions 1.x - 4.x

  • 2.0.1 PTF-01, 2.0.1, 2.0.0
Manual Chapter


C

BIND 8 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. This appendix also describes the relationship between BIND and 3DNS Controller wide IP definitions.

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:

BIND statements
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:

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

};

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 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 /etc/named-bootconf.pl, a Perl script that is part of the BIND 8.1 source kit.

Relating BIND information to 3DNS Controller wide IP definitions

We recommend that you use NameSurfer, which is included with the 3DNS Controller, to configure BIND. However, if you want to manually configure BIND and understand how BIND relates to wide IP definitions, read on. This section provides an example procedure for adding a wide IP when BIND is manually configured.

Note: The following information assumes you have read O'Reilly & Associates' book DNS and BIND (third edition). You can purchase this book from a technical bookstore.

Before defining a wide IP

Before configuring a wide IP, gather your 3DNS Controller, BIG/ip Controller, host, and virtual server information.

The following information includes sample wide IP statements that derive from the sample configuration file that starts on page A -50 . The sample wide IP statement configures a wide IP for the domain.com domain, where the IP addresses assigned to the 3DNS Controller interfaces are shown in the table below.

3DNS Controller addresses
3DNS Controller IP address
New York 192.168.101.2
Los Angeles 192.168.102.2

Gather your BIG/ip Controller and host configuration information so that you can easily see which virtual servers have the replicated content.

For example, create tables like the following. In the first table, list each server.

Server addresses
Server IP address Server type
New York 192.168.101.40 BIG/ip Controller
Los Angeles 192.168.102.40 BIG/ip Controller
Tokyo 192.168.103.40 BIG/ip Controller
Tokyo 192.168.104.40 Host
Los Angeles 192.168.105.40 Host

Next, create a table that lists the virtual servers managed by each BIG/ip Controller (include only those that host content for the domain you are load balancing). For example, each virtual server in the following table is owned by a different BIG/ip Controller, yet each contains identical content.

Virtual servers owned by BIG/ip Controllers
BIG/ip Controller Virtual server Virtual port
New York 192.168.101.50 80
Los Angeles 192.168.102.50 80
Tokyo 192.168.103.50 80

You configure virtual servers as part of the BIG/ip Controller configuration process. See the BIG/ip Controller Administrator Guide. List the other host machines and the IP addresses of the virtual servers that contain the same content.

Virtual servers owned by host machines
Host Virtual server Virtual port
Tokyo 192.168.104.50 80
Los Angeles 192.168.105.50 80

Defining a wide IP

The following procedure shows how to manually add a wide IP.

To add a wide IP and manually configure BIND

  1. Find or create the top level domain configuration file. This file is usually found in the /etc directory.

    · For BIND 4, enter the following line in the named.boot file:

primary domain.com db.domain.com

· For BIND 8, enter the following in the named.conf file:

zone "domain.com" IN { type master; file "db.domain.com"; };

To specify a type other than master, see the syntax for the zone statement on page C -7 .

  1. If your network's master DNS is not a 3DNS Controller, create a new subdomain to be controlled by the 3DNS Controller.

    For example, to create a subdomain called wip.domain.com, do one of the following:

    · Add the new subdomain to the named.conf file with the following lines:

     zone "wip.domain.com" IN {    
    type master;
    file "db.wip.domain.com";
    };

    · If the 3DNS Controller does not manage the top level domain, the subdomain must be delegated to each 3DNS Controller on your network. To delegate the domain to each 3DNS Controller in your network, add lines like the following to the top level domain database file (db.domain.com in this example):

     wip IN NS 3dns.newyork    
    IN NS 3dns.losangeles
    3dns.newyork IN A 192.168.101.2
    3dns.losangeles IN A 192.168.102.2
  2. If your network's master DNS is not a 3DNS Controller, change (or add) the target domain name to an alias.

    For example, you might find the target domain as an A record in your name server's DNS database as follows:

www IN A 192.168.101.50

Edit db.domain.com so that it contains following line:

www IN CNAME www.wip

In the above line, www.wip.domain.com is the domain name controlled by the 3DNS Controller.

  1. Next, you need to choose a wide IP key. Select one of the virtual servers in the group, and use its IP address as the wide IP key. In this example, 192.168.101.50 is the wide IP key for www.wip.domain.com.
  2. Configure the load balanced name on the 3DNS Controller.

    Locate or create a subdomain database file for wip.domain.com. Select one IP address from the set and add an A record for the www.wip domain. Use the IP address as the wide IP key. In the new A record, specify a low TTL value. (You can override the database's global TTL value for an individual name.)

    The following is an example of an entire zone file. The next to last line is the A record:

     wip.domain.com.   IN   SOA   3dns.newyork.domain.com.    
    postmaster.domain.com. (
    1998062914 ; Serial as YYYYMMDDXX
    3600 ; Refresh
    900 ; Retry
    3600000 ; Expire
    2 ) ; Minimum (default ttl for entire file)
    ; Domain DNS servers
    wip.domain.com. IN NS 3dns.newyork.domain.com.
    IN NS 3dns.losangeles.domain.com.
    ; Glue records
    3dns.newyork.domain.com. IN A 192.168.101.2
    3dns.losangeles.domain.com. IN A 192.168.102.2
    ; Mail servers
    domain.com. IN MX 10 mx.newyork.domain.com.
    domain.com. IN MX 20 mx.losangeles.domain.com.
    ; Regular Host
    otherbox IN A 192.168.101.20
    ; domain name TTL Wide IP key
    www 1 IN A 192.168.101.50
    ftp IN A 192.168.101.60

    Figure C.1 Sample zone file for wip.domain.com.

    The following example is provided for reference only. If you need help establishing reverse domains (address-to-name mappings), refer to the DNS and BIND book mentioned at the start of this procedure. The following sample screens show the reverse domain mapping files on the New York 3DNS Controller:

     101.168.192.in-addr.arpa. IN SOA 3dns.newyork.domain.com.    
    postmaster.domain.com. (
    1998062914 ; Serial as YYYYMMDDXX
    3600 ; Refresh
    900 ; Retry
    3600000 ; Expire
    14000 ) ; Minimum

    101.168.192.in-addr.arpa. IN NS 3dns.newyork.domain.com.
    IN NS 3dns.losangeles.domain.com.

    20 IN PTR otherbox.wip.domain.com.
    50 IN PTR www.wip.domain.com.
    60 IN PTR ftp.wip.domain.com.

    Figure C.2 Excerpt from db.192.168.101

Note: Because a virtual server is listed in each data center for a wide IP definition, you need to define an entry to mapping for each class C network that is included in the wide IP definition.

 102.168.192.in-addr.arpa. IN SOA 3dns.newyork.domain.com.    
postmaster.domain.com. (
1998062914 ; Serial as YYYYMMDDXX
3600 ; Refresh
900 ; Retry
3600000 ; Expire
14000 ) ; Minimum

102.168.192.in-addr.arpa. IN NS 3dns.newyork.domain.com.
IN NS 3dns.losangeles.domain.com.


50 IN PTR www.wip.domain.com.
60 IN PTR ftp.wip.domain.com.

Figure C.3 Excerpt from db.192.168.102

 103.168.192.in-addr.arpa. IN SOA 3dns.newyork.domain.com.    
postmaster.domain.com. (
1998062914 ; Serial as YYYYMMDDXX
3600 ; Refresh
900 ; Retry
3600000 ; Expire
14000 ) ; Minimum

103.168.192.in-addr.arpa. IN NS 3dns.newyork.domain.com.
IN NS 3dns.losangeles.domain.com.


50 IN PTR www.wip.domain.com.
60 IN PTR ftp.wip.domain.com.

Figure C.4 Excerpt from db.192.168.103

Instead of a typical one-to-one relationship, where one address maps to one name, the following addresses all map to www.wip:

192.168.101.50 192.168.102.50 192.168.103.50

  1. Add the www.wip.domain.com domain as a wide IP to your wideip.conf file. You can define which load balancing mode you want to use for the wide IP now or after you read Chapters 5 and 6 . List which virtual servers are to be available for load balancing this wide IP.

    Here is an example of a wideip statement to add to wideip.conf:

     wideip {    
    address 192.168.101.50
    service "http"
    name "www.wip.domain.com"
    ttl 60 // increase the domain default ttl
    pool {
    name "Pool_1"
    ratio 2 // applies to pool_lbmode == ratio
    preferred leastconn
    alternate ratio
    address 192.168.101.50 ratio 2
    address 192.168.102.50 ratio 1
    address 192.168.103.50 ratio 1
    }
    pool {
    name "Pool_2"
    type VSb
    ratio 1
    preferred rr
    address 192.168.102.60 ratio 2
    address 192.168.103.60 ratio 1
    }
    }

    Figure C.5 Sample wideip statement

    The wide IP is now in place and configured.

To add additional wide IPs by manually editing the configuration file

The following example describes how to add a wide IP named ftp.wip.domain.com:

  1. Select a set of geographically distributed virtual servers.
  2. Select the IP address of one of the virtual servers in the set to be the wide IP key (see Understanding the wideip key , on page 2-25 for details).
  3. Define the wide IP name and key within BIND by adding the following resource record to db.wip.domain.com:

ftp.wip IN A 192.168.102.60

  1. Define the virtual server list and the wide IP key within the 3DNS Controller by adding it to the wideip.conf file as follows:
     wideip {    
    address 192.168.102.60
    service "ftp"
    name "ftp.wip.domain.com"
    pool {
    name "main_pool"
    type VSb
    preferred leastconn
    alternate ratio
    address 192.168.101.60 ratio 2
    address 192.168.102.60 ratio 4
    address 192.168.103.60
    }
    }

    Figure C.6 Sample wideip statement

  2. Restart the 3DNS Controller by typing the following:

ndc restart

Understanding zone minimums

The zone file contains a Minimum field in the SOA (Start of Authority) section of the file. The Minimum value is the TTL for all resource records (RR) in the zone file. However, you can override the zone minimum for a given RR.

For example, if you do not want a DNS to cache the previously issued answer for a domain name, you can specify a very low value for the Minimum field.

Note: For wide IP domain names, specify the TTL in the wideip statement. See The wide IP statement , on page A -39 .

In the following zone file excerpt, the specified Minimum value is 30 seconds for every entry. The exception is the domain name www.wip, which is overridden and not saved in any DNS cache. The result is that a new query is made each time there is a name resolution request for www.wip. This allows the 3DNS Controller to respond with the most intelligent answer for each request.

 wip.domain.com. IN SOA 3dns.newyork.domain.com. postmaster.domain.com.(    
1998062914 ; Serial as YYYYMMDDXX
3600 ; Refresh
900 ; Retry
3600000 ; Expire
30 ) ; Minimum (default ttl for entire file)
www.wip 0 IN A 192.168.101.60

Figure C.7 Zone minimums

Replacing your DNS servers with 3DNS Controllers as master DNS servers for your domain

If you are replacing your master DNS with 3DNS Controllers, the method of importing your old zone files is dependent on which of the options you chose during your planning stage in converting existing BIND files.

If you skipped NameSurfer configuration in the First-Time Boot utility

The config_namesurfer script will convert your old zone files and configuration file. The BIND files must be in place before you configure the NameSurfer application.

To transfer and convert existing BIND files

  1. Manually transfer the zone files listed as master zones in /etc/named.conf on the existing BIND server to /var/namedb/* on the principal 3DNS Controller. On US 3DNS Controllers you can use scp to transfer files as well as rcp or ftp in passive mode. On international 3DNS Controllers you can use only rcp or ftp in passive mode.
  2. On the 3DNS Controller run the config_namesurfer script using the command below, and responding yes when asked if you want NameSurfer to be the master.

config_namesurfer

After the script completes and the NameSurfer application starts, the application automatically converts the transferred zone files from BIND format to NameSurfer format and converts the /etc/named.conf file to use the NameSurfer zone files.

The next step is dependent on whether you are using the advanced synchronization features of 3DNS and intend to use multiple master DNSs.

If you intend to use multiple master DNSs without synchronization

Repeat steps 1 and 2 listed in the previous section, To transfer and convert existing BIND files, on each subsequent 3DNS Controller.

Note: Any changes you make on one 3DNS Controller must be made on all the others.

If you intend to use multiple masters with synchronization

  1. Run the First-Time Boot utility on the remaining 3DNS Controllers in the network, but be certain to choose yes when asked if you want NameSurfer to run as a master.
  2. On all master 3DNS Controllers manually edit the /var/3dns/etc/sync_list.mandatory file and uncomment the line:
    fixed backup /etc/named.conf 3ndc reload
  3. Return to the principal 3DNS Controller and add the remaining 3DNS Controllers to the sync group.

    Once you finish setting up all of the 3DNS Controllers and adding each of them to the sync group, the NameSurfer application automatically broadcasts the master zone files to each 3DNS Controller in the group. All changes that are made with Namesurfer are automatically broadcast to all other 3DNS Controllers in your sync group. In addition, zone files changes may be made on any of the 3DNS Controllers.

If you intend to use one primary 3DNS Controller with one or more secondary 3DNS Controllers without synchronization

Run the First-Time Boot utility on the remaining 3DNS Controllers in the network, but be certain to choose no when asked if you want NameSurfer to run as a master.

Note: In this configuration you must perform all your zone edits only on the primary DNS server, which is now the 3DNS Controller.

If you intend to use one primary 3DNS Controller with one or more secondary 3DNS Controllers with synchronization

Run the First-Time Boot utility on the remaining 3DNS Controllers in the network, but be certain to choose yes when asked if you want NameSurfer to run as a master.

Note: In this configuration you can perform zone edits on your secondary DNS server, and these changes will be broadcast to the primary DNS server. Normal BIND zone transfers will occur. If your primary DNS server becomes unavailable, your zone edits will not be broadcast.

Running 3DNS Controllers as DNS masters only for wide IP sub-domains

3DNS Controllers must be the authority for the zone files associated with wide IP definitions. When you set up a configuration where the 3DNS Controllers are DNS master only for those sub-domains, you need to make a few changes to the zone files on the master DNS for your domain. Refer to the section Relating BIND information to 3DNS Controller wide IP definitions.

The next step is dependent on whether you are using the advanced synchronization features of 3DNS and intend to use multiple master DNSs.

If you intend to use multiple masters without synchronization

Run the First-Time Boot utility on the remaining 3DNS Controllers in the network, but be certain to choose yes when asked if you want NameSurfer to run as a master.

Note: Any changes you make on one 3DNS Controller must be made on all the others.

If you intend to use multiple masters with synchronization

  1. Run the First-Time Boot utility on the remaining 3DNS Controllers in the network, but be certain to choose yes when asked if you want NameSurfer to run as a master.
  2. On all master 3DNS Controllers manually edit the /var/3dns/etc/sync_list.mandatory file and uncomment the line:
    fixed backup /etc/named.conf 3ndc reload
  3. Return to the principal 3DNS Controller and add the remaining 3DNS Controllers to the sync group.

    Once you finish setting up all of the 3DNS Controllers and adding each of them to the sync group, the NameSurfer application automatically broadcasts the master zone files to each 3DNS Controller in the group.

If you intend to use one primary 3DNS Controller with one or more secondary 3DNS Controllers without synchronization

Run the First-Time Boot utility on the remaining 3DNS Controllers in the network, but be certain to choose no when asked if you want NameSurfer to run as a master.

Note: In this configuration you must perform all your zone edits only on the primary DNS server, which is now the 3DNS Controller.

If you intend to use one primary 3DNS Controller with one or more secondary 3DNS Controllers with synchronization

Run the First-Time Boot utility on the remaining 3DNS Controllers in the network, but be certain to choose yes when asked if you want NameSurfer to run as a master.

Note: In this configuration you can perform zone edits on your secondary DNS server, and these changes will be broadcast to the primary DNS server. Normal BIND zone transfers will occur. If your primary DNS server becomes unavailable, your zone edits will not be broadcast.