| Previous | Contents | Index |
If you have a configuration in which multiple networks or subnetworks share the same physical LAN, you can communicate directly with hosts in other networks without the need of a pseudo-interface 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:
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 |
Chapter 5 describes how to configure and manage the DIGITAL TCPIP Services for OpenVMS implementation of the Berkeley Internet Name Domain (BIND) software. Topics include:
Chapter 6 describes how to use BIND's round-robin scheduling or the load broker for cluster load balancing.
The Domain Name Service (DNS) is an Internet service 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. DIGITAL TCP/IP Services for OpenVMS implements a BIND server based on the Internet Software Consortium's (ISC) BIND 8.1.2. The BIND 8.1.2 implementation provides new configuration syntax and a new format for configuring the BIND name server.
BIND 8.1.2 provides the following features:
This BIND implementation also includes round-robin scheduling. A more robust load balancing mechanism is now provided with the Load Broker component, using standard DNS dynamic updates.
This chapter contains the following topics:
This section serves as a review only and assumes you are acquainted with the InterNIC, you applied for an IP address, and you registered your domain name. You should also be familiar with BIND terminology and 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/bind8/.
5.1.1 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. (In UCX V4.x, this configuration
information was stored in the configuration database
UCX$CONFIGURATION.DAT.)
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. There should only be one master server for a domain.
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, hints 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.
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 hints 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 non-authoritative, meaning that their information is secondhand and may be incomplete.
Caching-only servers require a hints 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 don't have access to the Internet.)
Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache file.
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 zone(s) of authority will be
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 TCPIP$CONFIGURATION.DAT and creates the BIND 8.1 configuration file TCPIP$BIND.CONF. It renames your BIND databases, where necessary (see Section 5.3 for more information.)
You can continue to use SET CONFIGURATION BIND commands to make changes
to your configuration (see Section 5.7), or you can make changes by
editing the ASCII file TCPIP$BIND.CONF (see Section 5.4). If you
continue to use SET CONFIGURATION BIND commands, you must also enter
the CONVERT/CONFIGURATION BIND command, or your changes will not take
effect.
5.3 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 an ASCII configuration file. The use of this file is described in Section 5.4. For TCP/IP Services Version 5.0, Compaq recommends, but does not require, that you use the ASCII configuration file to set up BIND. You can continue using TCPIP$CONFIG and SET CONFIGURATION BIND commands to set up your BIND environment as you did with previous releases of this product. The term "UCX BIND" is used below to describe this 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.
| 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 |
You must be consistent when making changes to your BIND environment. If you make changes by editing the ASCII 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 ASCII file (TCPIP$BIND.CONF) will be lost. If you continue to use the SET CONFIGURATION BIND commands, you must always enter the CONVERT/CONFIGURATION BIND command, or your changes will not take effect. |
This section describes how to configure the BIND name server on your local host.
BIND 8.1 stores configuration information in an ASCII 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 also terminated with a semicolon. Table 5-2 describes the valid configuration statements. For detailed descriptions of these statements, see the ISC BIND 8 documentation at URL WWW.ISC.ORG/BIND8/INDEX.HTML.
| Statement | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| acl name |
Defines an address match list used for access control and other uses.
The following ACLs are built-in:
|
||||||||
| include path_name |
Inserts a file. Use this statement to break the configuration file up
into manageable sections. The following lines, for example, could be
placed at the top of a BIND configuration file in order to include any
ACL or key information.
include "SYS$SPECIFIC:[TCPIP$BIND]KEYS.BIND" |
||||||||
| logging | Configures logging options for the name server. Options include 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. Only one logging statement is used to define as many channels and categories as you want. See Section 5.4.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.4.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:
|
||||||||
| 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.)
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 will be interpreted as the start of the next statement. |
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.
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, 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 will be:
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.
5.4.1.1 The 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, to a particular syslog facility, or are discarded. Optionally, it can also limit the message severity level that will be accepted by the channel (default is "info"), and whether to include a name server-generated timestamp, the category name and/or 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.
The file clause can include limitations both on how large the file is allowed to become, and how many versions of the file will be saved each time the file is opened.
The size option for files is simply a hard ceiling on log growth. If the file ever exceeds the size, then the BIND server just does not write anything more to it until the file is reopened; exceeding the size does not automatically trigger a reopen. The default behavior is to not limit the size of the file.
If you use the version logfile option, then the BIND server will retain that many backup versions of the file by renaming them when opening. For example, if you choose to keep 3 old versions of the file "lamers.log" then just before it is opened lamers.log.1 is renamed to lames.log.2, lamers.log.0 is renamed to lamers.log.1, and lamers.log is renamed to lamers.log.0. No rolled versions are kept by default. The unlimited keyword is synonymous with 99 in current BIND releases.
The severity clause works like syslog's "priorities", except that they can also be used if you are writing straight to a file rather than using syslog. Messages which are not at least of the severity level given will not be selected for the channel; messages of higher severity levels will be accepted.
The server can supply extensive debugging information when it is in debugging mode. If the server's global debug level is greater than zero, then debugging mode will be active. The global debug level is set either by starting the server with the "-d" flag followed by a positive integer, or by sending the server the SIGUSR1 signal (For example, by entering SYS$SYSTEM:TCPIP$BIND_SERVER_CONTROL.EXE TRACE). The global debug level can be set to zero, and 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 debug level, and higher debug levels give more more detailed output. Channels that specify a specific debug 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 print. The following shows such an example:
channel specific_debug_level {
file "foo";
severity debug 3;
};
|
If print-time has been turned on, then the date and time will be logged. print-time may be specified for a syslog channel, but is usually pointless since syslog also prints the date and time. If print-category is requested, then the category of the message will be logged as well. Finally, if print-severity is on, then the severity level of the message will be logged. The print- options may be used in any combination, and will always be printed in the following order: time, category, severity. Here is an example where 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 follows. How they are used used is described in the next section, The Category Phrase.
channel default_syslog {
syslog daemon; # send to syslog's daemon facility
severity info; # only send priority info and higher
};
channel default_debug {
file "named.run"; # write to named.run in the working directory
# Note: stderr is used instead of "named.run"
# if the server is started with the "-f" option.
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.
| Previous | Next | Contents | Index |