HP OpenVMS Systems Documentation

The Domain Name System (DNS) is a system that maintains and distributes information about Internet hosts. DNS consists of several databases that store host names and host IP addresses. With DNS, there is no central storage of data --- no one server knows everything about all the Internet domains.

In UNIX environments, DNS is implemented by the Berkeley Internet Name Domain (BIND) software. HP TCP/IP Services for OpenVMS implements a BIND server based on the Internet Software Consortium's (ISC) BIND 8.1.2.

BIND 8.1.2 provides the following features:

• DNS dynamic updates
• DNS change notification
• New configuration syntax
• Flexible, categorized logging system
• IP address-based access control for queries, zone transfers, and updates that can be specified on a zone-by-zone basis
• More efficient zone transfers
• Improved performance for servers with thousands of zones

This BIND implementation also includes round-robin scheduling. A more robust load-balancing mechanism is provided with the load broker, which uses standard DNS dynamic updates.

This chapter contains the following topics:

• A review of key BIND concepts ( Section D.1)
• How to migrate your existing BIND environment to BIND 8 ( Section D.2)
• How to configure BIND using the BIND configuration file ( Section D.3)
• How to configure dynamic updates ( Section D.3.6)
• How to configure a DNS cluster failover and redundancy environment ( Section D.3.7)
• How to populate the BIND server databases ( Section D.4)
• How to configure BIND using SET CONFIGURATION BIND commands ( Section D.6)
• How to configure the BIND resolver ( Section D.7)
• How to use NSLOOKUP to query a name server ( Section D.8)
• How to troubleshoot BIND server problems ( Section D.9)

This section serves as a review only and assumes you are acquainted with the InterNIC, that you applied for an IP address, and that you registered your domain name. You should also be familiar with BIND terminology, and you should have completed your preconfiguration planning before using this chapter to configure and manage the BIND software.

If you are not familiar with DNS and BIND, see the Compaq TCP/IP Services for OpenVMS Concepts and Planning guide. If you need more in-depth knowledge, see O'Reilly's DNS and BIND, Third Edition. For details on BIND 8 configuration, see the ISC BIND 8 documentation at http://www.isc.org/ .

D.1.1 How the Resolver and Name Server Work Together

BIND is conceptually divided into two components: a resolver and a name server. The resolver is software that queries a name server; the name server is the software process that responds to a resolver query.

Under BIND, all computers use resolver code but not all computers run the name server process.

The BIND name server runs as a distinct process called TCPIP$BIND. On UNIX systems, the name server is called named (pronounced name-dee). Name servers are typically classified as master (previously called primary), slave (previously called secondary), and caching-only servers, depending on their configurations.

D.1.2 Common BIND Configurations

You can configure BIND in several different ways. The most common configurations are resolver-only systems, master servers, slave servers, forwarder servers, and caching-only servers. A server can be any of these configurations or can combine elements of these configurations.

A group of database files containing BIND statements and resource records are used by servers. These files include:

• The forward translation file, domain_name.DB
  This file maps host names to IP addresses.
• The reverse translation file, address.DB
  This file maps the address back to the host names. This address name lookup is called reverse mapping. Each domain has its own reverse mapping file.
• Local loopback forward and reverse translation files, LOCALHOST.DB and 127_0_0.DB
  These local host databases provide forward and inverse translation for the widely used LOCALHOST name. The LOCALHOST name is always associated with the IP address 127.0.0.1 and is used for loopback traffic.
• The hint file, ROOT.HINT
  This file contains the list of root name servers.

A configuration file, TCPIP$BIND.CONF, contains statements that pull all of the database files together and governs the behavior of the BIND server.

D.1.2.1 Master Servers

A master server is the server from which all data about a domain is derived. Master servers are authoritative, meaning they have complete information about their domain and their responses are always accurate.

To provide central control of host name information, the master server loads the domain's information directly from a disk file created by the domain administrator. When a new system is added to the network, only the database located on the master server needs to be modified.

A master server requires a complete set of configuration files: zone, reverse domain, configuration file, hint file, and loopback files.

D.1.2.2 Slave Servers

Slave servers receive authority and their database from the master server.

A particular domain's database file is called a zone file and copying this file to a slave server is called a zone file transfer. A slave server assures that it has current information about a domain by periodically transferring the domain's zone file. Slave servers are also authoritative for their domain.

Configuring a slave server is similar to configuring a master server. The only difference is that you need to provide the name of the master server from which to transfer zone data.

Slave servers require a configuration file, a hint file, and loopback files.

D.1.2.3 Caching-Only Servers

Caching-only servers get the answers to all name service queries from other name servers. Once a caching server receives an answer to a query, it saves the information and uses it in the future to answer queries itself. Most name servers cache answers and use them in this way but a caching-only server depends on this for all its server information. It does not keep name server database files as other servers do. Caching-only servers are nonauthoritative, meaning that their information is secondhand and can be incomplete.

Caching-only servers require a hint file and loopback files.

D.1.2.4 Forwarder Servers

The forwarding facility can be used to create a large sitewide cache on a few servers, reducing traffic over links to external name servers. Forwarder servers process requests that slave servers cannot resolve locally (for example, because they do not have access to the Internet).

Forwarding occurs on only those queries for which the server is not authoritative and does not have the answer in its cache.

A master or slave server specifies a particular host to which requests outside the local zone are sent. This is a form of Internet courtesy so that only a limited number of hosts actually communicate with the root servers listed in the file ROOT.HINT.

If you configure a forwarder server, you must provide the name of the host to which requests outside your zones of authority are forwarded.

D.2 Migrating to BIND 8.1

If you set up your BIND environment using a previous version of the TCP/IP Services product, you must convert the UCX databases and configuration information to the new BIND 8.1 format.

To convert your BIND configuration, enter the following command:

TCPIP> CONVERT/CONFIGURATION BIND

This command extracts the BIND-specific configuration information from UCX$CONFIGURATION.DAT and creates the BIND 8.1 configuration file TCPIP$BIND.CONF. It renames your BIND databases, where necessary (see Section D.2.1 for more information).

You can continue to use the SET CONFIGURATION BIND commands to make changes to your configuration (see Section D.6), or you can make changes by editing the text file TCPIP$BIND.CONF (see Section D.3). If you continue to use the SET CONFIGURATION BIND commands, you must also enter the CONVERT/CONFIGURATION BIND command in order for your changes to take effect.

D.2.1 Navigating Two Different BIND Environments

This section summarizes the differences between the UCX BIND implementation and BIND 8.1.

It is important to remember that in BIND 8.1, name servers are configured by editing a text configuration file. The use of this file is described in Section D.3. HP recommends, but does not require, that you use the configuration file to set up BIND. You can continue using the TCPIP$CONFIG and the SET CONFIGURATION BIND commands to set up your BIND environment as you did with previous releases of this product. The term UCX BIND in Table D-1 describes the previous configuration method even though this method is still valid in the current release.

Table D-1 describes changes to the database and configuration file names.

This section describes how to configure the BIND name server on your local host.

BIND 8.1 stores configuration information in a text file called TCPIP$BIND.CONF. The TCP/IP Services product provides a template for this file located in the SYS$SPECIFIC:[TCPIP$BIND] directory. Edit this template to reflect your site-specific configuration requirements before running BIND.

A BIND 8.1 configuration file consists of statements and comments. Statements end with a semicolon. Many statements contain a block of substatements that also end with a semicolon. Table D-2 describes the valid configuration statements. For detailed descriptions of these statements, see the BIND 8 documentation at

www.isc.org/

 include "SYS$SPECIFIC:[TCPIP$BIND]KEYS.BIND";

 include "SYS$SPECIFIC:[TCPIP$BIND]ACLS.BIND";

The following sample is a configuration file for a master server:

options {
        directory "SYS$SPECIFIC:[TCPIP$BIND]";
};

zone "FRED.PARROT.BIRD.COM" in {
        type master;
        file "FRED_PARROT_BIRD_COM.DB";
};


zone "0.0.127.IN-ADDR.ARPA" in {
        type master;
        file "127_0_0.DB";
};

zone "LOCALHOST" in {
        type master;
        file "LOCALHOST.DB";
};

zone "208.20.16.IN-ADDR.ARPA" in {
        type master;
        file "208_20_16_IN-ADDR_ARPA.DB";
};

zone "." in {
        type hint;
        file "ROOT.HINT";
};

The following comment styles are valid in a BIND configuration file. Comments can appear anywhere in the file.

• C-style comments that start with /* and end with */
• C++ style comments that start with // and continue to the end of the physical line
• Shell or Perl-style comments that start with # and continue to the end of the physical line

The logging statement configures a wide variety of logging options for the name server. Its channel phrase associates output methods, format options, and severity levels with a name that can then be used with the category phrase to select how various classes of messages are logged. The logging statement has the following 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_or_no; ]
   [ print-severity yes_or_no; ]
   [ print-time yes_or_no; ]
}; ]

   [ category category_name {
     channel_name; [ channel_name; ... ]
}; ]
  ...
};

Only one logging statement is used to define as many channels and categories as you want. If there are multiple logging statements in a configuration file, the first one that is defined determines the logging, and warnings are issued for the others. If there is no logging statement, the logging configuration is:

    logging {
        category default { default_syslog; default_debug; };
        category panic { default_syslog; default_stderr; };
        category packet { default_debug; };
        category eventlib { default_debug; };
    };

All logged statements channeled to syslog facilities are directed to the TCPIP$BIND_RUN.LOG file.

D.3.1.1 Channel Phrase

All log output goes to one or more channels. You can create as many channels as you want.

Every channel definition must include a clause that says whether messages selected for the channel go to a file or to a particular syslog facility, or are discarded. Optionally, it can also limit the message severity level that is accepted by the channel (default is info ), and whether to include a name server-generated timestamp, the category name, and severity level (default is not to include any).

The word null as the destination option for the channel causes all messages sent to it to be discarded; other options for the channel are meaningless.

There is a severity clause that allows you to specify the level of diagnostic messages to be logged.

The server can supply extensive debugging information when it is in debugging mode. If the server's global debugging level is greater than zero, then debugging mode is active. The global debugging level is set by one of the following:

• Starting the server with the "-d" flag, followed by a positive integer
• Sending the server the SIGUSR1 signal (for example, by entering SYS$SYSTEM:TCPIP$BIND_SERVER_CONTROL.EXE TRACE)

The global debugging level can be set to zero, and the debugging mode turned off, by sending the server the SIGUSR2 signal (by entering SYS$SYSTEM:TCPIP$BIND_SERVER_CONTROL.EXE NOTRACE). All debugging messages in the server have a debugging level; the higher debugging levels provide more detailed output. Channels that specify a particular debugging severity will get debugging output of level 3 or less any time the server is in debugging mode, regardless of the global debugging level. Channels with dynamic severity use the server's global level to determine what messages to display, as shown in the following example:

    channel specific_debug_level {
        file "foo";
        severity debug 3;
    };

If print-time is turned on, the date and time are logged. print-time can be specified for a syslog channel, but that is usually pointless since syslog also prints the date and time. If print-category is requested, then the category of the message is logged as well. Finally, if print-severity is on, then the severity level of the message is logged. The print- options can be used in any combination and are always displayed in the following order: time, category, severity. In the following example, all three print- options are on:

    28-Apr-1997 15:05:32.863 default: notice: Ready to answer queries.

There are four predefined channels that are used for the BIND server's default logging, as shown in the following example. Section D.3.1.2 describes how these channels are used.

channel default_syslog {
    syslog daemon;      # send to syslog's daemon facility
    severity info;      # only send priority info and higher
};
channel default_debug {
    file "TCPIP$BIND_RUN.LOG";   # write to TCPIP$BIND_RUN.LOG in the
                                 # working directory
    severity dynamic;            # log at the server's current debug level
};
channel default_stderr {# writes to stderr
    file "stderr";      # this is illustrative only; there's currently
                        # no way of specifying an internal file
                        # descriptor in the configuration language.
    severity info;      # only send priority info and higher
};

channel null {
    null;               # toss anything sent to this channel
};

Once a channel is defined, it cannot be redefined. Thus you cannot alter the built-in channels directly, but you can modify the default logging by pointing categories at channels you have defined.