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:

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:

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

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:

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:

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:

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.

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