# Compaq TCP/IP Services for OpenVMS
Management

Previous | Contents | Index

## 4.4.3 Extending Routing

To use extended routing, define pseudointerfaces. A pseudointerface is a data structure that extends routing. Like an interface, the name of an internet pseudointerface is three alphabetic characters, followed by the pseudointerface unit number in the range of 0 through 255.

The first two characters are the same as the two characters in the internet interface name (interface type and interface class). See Section 2.3.1 for more information about interface names.

The third character identifies the controller letter that corresponds to the OpenVMS hardware controller.

For example, for an OpenVMS Alpha system with two Ethernet controllers, EZA0 and EZB0, you can define the following internet interfaces and pseudointerfaces:

- Internet interfaces:
  - ZE0
  - ZE1
- Internet pseudointerfaces, each with its own IP address, network mask, and broadcast mask:
  - SEA
  - SEA0
  - SEA1
    .
    .
    .
  - SEA254
  - SEB255

To extend routing, follow these steps:

1. Define the pseudointerfaces using the SET INTERFACE and SET CONFIGURATION INTERFACE commands:

       TCPIP> SET NOINTERFACE interface

       TCPIP> SET INTERFACE interface /HOST=host -
       _TCPIP> /NETWORK_MASK=mask /BROADCAST_MASK=b_mask

       TCPIP> SET CONFIGURATION INTERFACE interface /HOST=host -
       _TCPIP> /NETWORK_MASK=mask /BROADCAST_MASK=b_mask

   For example, to specify the pseudointerface FFA0 on host KESTREL, with network mask 255.255.0.0 and broadcast mask to 128.30.0.0, enter:

       TCPIP> SET NOINTERFACE FFA0

       TCPIP> SET INTERFACE FFA0 /HOST=KESTREL /NETWORK_MASK=255.255.0.0 -
       _TCPIP> /BROADCAST_MASK=128.30.0.0

2. Enter the same information into the configuration database to set up the interfaces at startup. For example:

       TCPIP> SET CONFIGURATION INTERFACE FFA0 /HOST=KESTREL -
       _TCPIP> /NETWORK_MASK=255.255.0.0 /BROADCAST_MASK=128.30.0.0

   To display information about the network interfaces, use the SHOW INTERFACE command. To remove the interface from the configuration database, use the SET CONFIGURATION NOINTERFACE command.

## 4.4.4 Interface Routes

If you have a configuration in which multiple networks share the same physical LAN, you can communicate directly with hosts in other networks without the need of a pseudointerface for each network.

You can use a broadcast address to designate an interface route, also called a metric 0 route.

To create interface routes, follow these steps:

1. As the gateway for the route, enter either one of the host's own addresses or the broadcast address associated with an interface.
   TCP/IP Services recognizes this route as an interface route.
2. Configure the hosts in the other network to recognize that your network is present on their LAN.

For example, network 99.0.0.0 is on the same cable as network 192.199.199.0. On host 99.1.2.3, specify network 192.199.199.0 as directly reachable:

    TCPIP> SET ROUTE 192.199.199.0 /NETWORK /GATEWAY=99.1.2.3

On the hosts in network 192.199.199.0, enter:

    TCPIP> SET ROUTE 99.0.0.0 /NETWORK /GATEWAY=192.199.199.255

## 4.4.5 Manually Configuring a Hardware Address

Network hosts require manual configuration of a hardware address for a remote IP address under the following conditions:

- The remote host does not support the Address Resolution Protocol (ARP). You need static mapping of IP addresses to hardware addresses.
- The remote host is running ARP, but a change was made to the internet interface on that host.
  To notify your system about the change, flush the address mapping tables. Use the SET NOARP command to do this.

For example, to map the Ethernet address AA-02-04-05-06-07 of host ROOK, add the hardware address to the ARP table by entering the following command:

    TCPIP> SET ARP AA-02-04-05-06-07 ROOK

# Part 2
BIND

Part 2 provides information on configuring and managing the TCP/IP Services name server and includes the following chapters:

- Chapter 5, Configuring and Managing BIND, describes how to configure and manage the TCP/IP Services implementation of the Berkeley Internet Name Domain (BIND) software.
- Chapter 6, Using DNS to Balance Work Load, describes how to use BIND's round-robin scheduling or the load broker for cluster load balancing.

# Chapter 5
Configuring and Managing BIND

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. Compaq 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 5.1)
- How to migrate your existing BIND environment to BIND 8 ( Section 5.2)
- How to configure BIND using the BIND configuration file ( Section 5.3)
- How to configure dynamic updates ( Section 5.3.6)
- How to configure a DNS cluster failover and redundancy environment ( Section 5.3.7)
- How to populate the BIND server databases ( Section 5.4)
- How to configure BIND using SET CONFIGURATION BIND commands ( Section 5.6)
- How to configure the BIND resolver ( Section 5.7)
- How to use NSLOOKUP to query a name server ( Section 5.8)
- How to troubleshoot BIND server problems ( Section 5.9)

# 5.1 Key Concepts

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 DIGITAL 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/` .

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

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

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

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

Note If you create a master, slave, or forwarder server for the same domain on which your local host resides, you should reconfigure your BIND resolver so that it uses this system (LOCALHOST) as its name server.

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

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

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

# 5.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 5.2.1 for more information).

You can continue to use the SET CONFIGURATION BIND commands to make changes to your configuration (see Section 5.6), or you can make changes by editing the text file TCPIP$BIND.CONF (see Section 5.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.

## 5.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 5.3. Compaq 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 5-1 describes the previous configuration method even though this method is still valid in the current release.

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

Table 5-1 UCX BIND and BIND 8.1 Differences
Database/File Names | UCX BIND | BIND 8.1
--- | --- | ---
Configuration information | UCX$CONFIGURATION.DAT | TCPIP$BIND.CONF
Local loopback files | NAMED.LOCAL | LOCALHOST.DB, 127_0_0.DB
Forward lookup file | domain_name.DB | domain_name.DB
Reverse lookup file | address.DB | address.DB
Cache file | NAMED.CA | ROOT.HINT

Important You must be consistent when making changes to your BIND environment. If you make changes by editing the configuration file, you should continue to make changes in that manner. If you revert to the UCX BIND configuration method (SET CONFIGURATION BIND and CONVERT/CONFIGURATION BIND commands), any changes you made to the configuration file (TCPIP$BIND.CONF) are lost. If you continue to use the SET CONFIGURATION BIND commands, you must always enter the CONVERT/CONFIGURATION BIND command in order for your changes to take effect.

# 5.3 Configuring the BIND Server (BIND 8.1)

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 5-2 describes the valid configuration statements. For detailed descriptions of these statements, see the BIND 8 documentation at

    www.isc.org/

Table 5-2 BIND Name Server Configuration Statements
Statement | Description
--- | ---
`acl` name | Defines an address match list used for access control and other uses. The following ACLs are built in:
`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.
See Section 5.3.5 for more information about these options.
`include` path_name | Inserts a file. Use this statement to break the configuration file into manageable sections. The following lines, for example, could be placed at the top of a BIND configuration file so that it includes any ACL or key information.
     include "SYS$SPECIFIC:[TCPIP$BIND]KEYS.BIND";

     include "SYS$SPECIFIC:[TCPIP$BIND]ACLS.BIND";
`logging` | Configures logging options for the name server. Options include output methods, format options, and severity levels that you associate with a name that can then be used with the category phrase to select how various classes of messages are logged. Use one logging statement to define as many channels and categories as you want. See Section 5.3.1 for more information about these options.
`options` | Sets up global server configuration options and sets defaults for other statements. This statement is used only once in a configuration file. Options statements include path names, Boolean options, forwarding information, name checking, access control, interfaces, query addresses, zone transfers, resource limits, periodic task intervals, and topology. See Section 5.3.2 for more information about these options.
`server` ip_address | Defines the characteristics associated with a remote name server. The server supports the following zone transfer methods:
`one-answer` | Uses one DNS message per resource record transferred.
`many-answers` | Packs as many resource records as possible into a message. This method is more efficient but is only understood by BIND 8.1.2.
You can specify which method to use for a server with the `transfer-format` option. If `transfer-format` is not specified, the `transfer-format` specified by the options statement is used.
`zone` domain_name | Defines a zone. Valid types include master, slave, stub, and hint.

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

Important In a zone file, comments start with a semicolon (;). Do not use the semicolon as a comment character in your configuration file. The semicolon indicates the end of a configuration statement, so whatever follows is interpreted as the start of the next statement.

Previous | Next | Contents | Index