7. Host Tables and DNS

This chapter describes host tables and the Internet Domain Name System (DNS). Both host tables and DNS provide a way of associating host IP addresses with host names.

The chapter also describes how to use DNS load balancing for TCP-based services on cluster nodes. Load balancing helps to provide uninterrupted services if an individual server crashes or cannot handle the number of users trying to access it simultaneously.

Methods of Associating IP Addresses and Host Names

The three methods of associating IP addresses and host names are:

· Host tables, which offer a simplified method of translating a host name into an Internet address, can become unmanageable if there are many hosts on your network.

· DNS, which is more complicated to configure, offers the advantages of a distributed database.

· Multicast name resolution, which requires little configuration and is designed for small networks operating on a single logical LAN.

If you are connected to the Internet, DNS gives you access to the Internet DNS.

When you install MultiNet, you are asked if you want to use host tables or DNS. You can change your decision after installation using the instructions in this chapter.

DNS and the host table service are completely separate entities. If DNS is enabled, MultiNet only accesses host tables if a DNS query fails. DNS, however, never contacts the host table service, and no data is shared between these two services.

In addition to the administrative commands provided for configuring host tables and DNS, MultiNet provides C language library routines that can access either host tables or DNS. (See the MultiNet Programmer's Reference for more details.)

Note: For illustrative purposes ONLY, the section on host tables in this chapter assumes that you are not connected to the Internet, and the section on DNS assumes that you are connected to the Internet.

Host Table

A host table is a file that describes network protocols, services, and host information accessed by utilities such as TELNET, RLOGIN, and TCPDUMP. To create a host table:

1. Build or retrieve the host table in one of the following ways:

· Add site-specific information to the HOSTS.LOCAL file to describe protocol, service, network, and host characteristics. This method is described in the Configuring the Host Table section.

· If you have a UNIX-style /etc/hosts file, convert it as described in the Converting a UNIX /etc/hosts File section.

2. Compile the host table file as described in the Compiling the Host Table section. The next time MultiNet starts, it installs the compiled host table as a global section.

3. To use the new, compiled host table, install it as a global section (see the Installing a Compiled Host Table as a Global Section section).

Once you install the compiled host table, MultiNet uses it to convert host names to IP addresses and vice versa. MultiNet's resolution of host names and addresses is invisible to users.

Creating the Host Table Source Files

The first step in creating a host table is to gather the appropriate source files. There are three ways to obtain source files:

· Modify existing source files.

· Convert source files from other systems.

· Write completely new files.

Host Table Source Files

The compiled form of the MultiNet host table is stored in the binary file MULTINET:NETWORK_DATABASE. The following list describes the source files from which the host table is compiled.

File name	Description
MULTINET:HOSTS.LOCAL	Contains any locally defined hosts, protocols, and services. Add custom host table entries to this file. For details on the source file format, see Configuring the Host Table.
MULTINET:HOSTS.SERVICES	Contains standard information necessary for the operation of MultiNet and is subject to change when you upgrade MultiNet. Do not modify this file.

All host table source files contain text in the form described by RFC-952, "DoD Internet Host Table Specification," with extensions provided to allow information not anticipated by the designers of RFC-952. For details, see the Configuring the Host Table section.

Configuring the Host Table

The MultiNet host table contains more than just host name and address information. The below table shows the information stored in the MultiNet host tables and how to access the information.

The protocol and service definitions in the HOSTS.LOCAL file supplied with MultiNet are usually adequate. However, if you have an application that requires additional protocol or service information, you can add definitions for them. See Adding Protocol Sections and Adding Service Definitions later in this section.

You must add information about your network and hosts to the host table. See Adding Network Definitions and Adding Host Definitions later in this section.

The information stored in MultiNet host tables is:

Information

Keys

C Access Routine

IP Protocol Types

Name (for example, TCP, UDP)

IP Protocol Number

getprotobyname()

getprotobynumber()

Services

Name (for example, TCP/TELNET)

Port Number

getservbyname()

getservbyport()

Networks

Name (for example, EXAMPLE-NET)

IP Network Number

getnetbyname()

getnetbyaddr()

Hosts

Name (for example, EXAMPLE.COM)

IP Host Address

gethostbyname()

gethostbyaddr()

Adding Protocol Definitions

Protocol definitions in the MultiNet HOSTS.LOCAL file describe the protocols that can run on top of IP. A protocol definition contains the reserved word PROTOCOL, a protocol number used in the IP protocol field (for example, 6 for TCP), and the name of the protocol (for example, TCP). Enter each protocol definition as a single line without carriage returns or continuation characters.

The valid numbers and the protocol name values are defined in RFC-1060, "Assigned Numbers." Protocol numbers are 8-bit values ranging from 0 to 255. The protocol name can be up to 40 characters in length, and consists of uppercase letters, digits, and, optionally, a hyphen. Spaces and other special characters are not permitted in the protocol name. The format of a protocol definition is:

PROTOCOL : number : name :

For example:

PROTOCOL : 6 : TCP :
PROTOCOL : 17 : UDP :

Adding Service Definitions

Service definitions in the HOSTS.LOCAL file describe the various protocol services that may be invoked, and the protocol and service port to contact for these services. A service definition consists of the reserved word SERVICE, the protocol name (for example, TCP), the port number (for example, 23 for TCP/TELNET), and the service name (for example, TELNET).

When specifying the service name, you may use a comma-separated list of names. The first name in the list is the official name of the service; the other names are aliases. Enter each service definition as a single line without carriage returns or continuation characters. Valid port number and service names are defined in RFC-1060, "Assigned Numbers." The format of a service definition is:

SERVICE : protocol : port : names :

For example:

SERVICE : TCP : 23 : TELNET :
SERVICE : TCP : 25 : SMTP,MAIL :

Adding Network Definitions

Network definitions in the HOSTS.LOCAL file correlate network names to network numbers. A network definition consists of the reserved word NET, the network number, and the network name. Network numbers are host IP addresses with the host part of the address set to zero. Enter each network definition as a single line without carriage returns or continuation characters. The format of the network definition is:

NET : network-number : name :

For example:

NET : 0.0.0.0 : DEFAULT-GATEWAY:
NET : 192.16.100.0 : LOOPBACK-NET:
NET : 192.41.228.0 : ABC-NET:

Adding Host Definitions

Host definitions in the HOSTS.LOCAL file map IP addresses to host names. A host definition consists of the following:

· The reserved word HOST

· A comma-separated list of IP addresses by which the host may be contacted

· A comma-separated list of host names. The first host name is the official host name; any other names are aliases.

· The computer CPU type (used only as an informative message for users)

· The operating system (used only as an informative message for users)

· A comma-separated list of services provided by the host (currently ignored by all programs)

Enter each host definition as a single line without carriage returns or continuation characters. The format of a host definition is:

HOST : addresses : host names : CPU type : operating system : services :

For example:

HOST : 10.0.0.1 : EXAMPLE.COM,BIGBOOTE : VAX-11/780 : VMS : TCP/TELNET,
TCP/FTP,TCP/SMTP :

Do not embed spaces in the CPU type, operating system, and offered-services fields. For example, "IBM-PC" is a valid CPU type and "IBM PC" is not a valid CPU type. Spaces are permitted before or after the colon separator character, but not within the field value. You may also leave these fields blank, as in the following entry:

HOST : 192.116.0.1 : LOCALHOST : : : :

Host Name Conformance

Host names (A records) are now restricted to the following characters only:

Restricted	Excluded
A through Z (uppercase letters A through Z)	_ (underscore)
a through z (lowercase letters a through z)	/ (slash)
0 through 9 (the numbers zero through nine)
. (dot or period)
- (hyphen or dash)

If there are any records in a zone file that do not meet these new guidelines, attempts for name resolution in that zone will fail. Other zones may begin to fail resolving your host names if your zone files are not in compliance with the relevant RFCs. RFC-952 (DoD Internet Host Table Specification, October 1985) and RFC-1123 (Requirements for Internet Hosts - Application and Support, October 1989) contain full descriptions of permitted host name specifications.

As a security measure, the current releases of the BIND nameserver enforce RFC-952 host name conformance (as modified by RFC-1123). As a result of this change, those host names that do not conform to the new rules will be unreachable from sites running the new nameserver. MultiNet properly responds to IGMP request messages because it is compliant with RFC 1112 “Host Extensions for IP Multicasting.”

Converting a UNIX /etc/hosts File

MultiNet provides a utility for converting a UNIX-format /etc/hosts host table file into a HOSTS.TXT file. Use the command procedure MULTINET:CONVERT_UNIX_HOST_TABLE.COM to make the conversion. This command has the following syntax:

$ @MULTINET:CONVERT_UNIX_HOST_TABLE infile outfile

· infile defaults to HOSTS.

· outfile defaults to the HOSTS.TXT file.

The outfile is converted to a file compliant with RFC-952, the DoD Internet Host Table Specification used by MultiNet. If outfile already exists, the command procedure replaces it with a new host table source file. During the conversion:

· Any comments in the input file that begin in the first column are preserved in the output file.

· Extra spaces are compressed.

· Blank lines are removed.

· Characters are converted to uppercase.

· If the host address or name cannot be found, an error is displayed and the output file is deleted.

· Host definitions are created with the host address, official name, and any aliases.

When the conversion completes, you may want to add the CPU type and operating system to each host entry, as described in Adding Host Definitions earlier in this section.

Compiling the Host Table

After generating, modifying, or retrieving a MultiNet host table, compile it into binary form with the following command:

$ MULTINET HOST_TABLE COMPILE

The command shown, the simplest form of the MultiNet host table compilation command, should suffice for most compilations. Additional qualifiers to this command are described in the HOST_TABLE COMPILE command page listed in the MultiNet Administrator's Reference. The command qualifiers are:

Qualifier	Purpose	Default
/HOST_TABLE_FILE	Binary output file name	MULTINET:NETWORK_DATABASE
/SILENTLY	Suppress compilation messages	NOSILENTLY
/STARTING_HASH_VALUE	Initial hash size	Best value^{^[1]}
/TBLUK_FILE	Host-completion database	MULTINET:HOSTTBLUK.DAT
/UNIX_HOST_FILE	Produce UNIX-style hosts file	NOUNIX_HOST_FILE

Note: If you are running MultiNet on a VMScluster, you only need to run the MULTINET COMPILE command on one node of the cluster.

Installing a Compiled Host Table as a Global Section

When MultiNet starts, it installs the compiled host table MULTINET:NETWORK_DATABASE as a global section. The compiled host table is organized as a "perfect hash" lookup system, allowing MultiNet to answer any query in one lookup. Because the host table is installed as an OpenVMS global section, access to host table information is extremely fast. To install the compiled host table as a global section without restarting MultiNet:

1. After recompiling a host table, reinstall it by rebooting or invoking @MULTINET:INSTALL_DATABASES.

2. If you want the new host table to be noticed by the servers that run as part of the MULTINET_SERVER process, restart that process with @MULTINET:START_SERVER.

3. If you want the new host table to be noticed by the SMTP symbiont(s), restart them with the command @MULTINET:START_SMTP. For more information about configuring SMTP queues, see Chapter 15.

Note: You must run the @MULTINET:INSTALL_DATABASES, @MULTINET:START_SERVER, and @MULTINET:START_SMTP commands on every VMScluster node running MultiNet.

Using the Domain Name System (DNS)

DNS (Domain Name System) is the preferred method of maintaining host name and address information. DNS provides a fully distributed database of host names, Internet addresses, host information, and mail forwarding information.

When using DNS, a host has access to the full database, yet local information can be maintained locally and exported to the rest of the Domain Name System. DNS is fully documented in several RFCs published by the Defense Data Network Network Information Center (DDN NIC). The following RFCs describe DNS:

RFC-1032	Domain Administrators Operations Guide
RFC-1033	Domain Administrators Guide
RFC-1034	Domain Names - Concepts and Facilities
RFC-1035	Domain Names - Implementation and Specification

The Defense Data Network Information Center (DDN NIC) publishes a softbound manual containing all RFCs pertaining to DNS. This chapter cannot describe all of the intricacies of the Domain Name System. For complete information, Process Software recommends the book DNS and BIND, Fourth Edition (ISBN 0-596-00158-4). This book provides a thorough description of DNS concepts and applications, although the emphasis is on UNIX-based DNS implementations. In particular, you should read this book if you are using MultiNet to set up an authoritative, or master, name server for your domain or part of your domain.

DNS Resolvers and Servers

MultiNet provides both DNS server and resolver (client) support. The server communicates with the rest of the Internet DNS and participates in distributing DNS data. The resolver receives requests from applications and queries a DNS server for the information.

The DNS Resolver (Client)

The DNS resolver (client) is used by applications to access the DNS database. The DNS resolver is accessed via the MULTINET_SOCKET_LIBRARY.

The MultiNet DNS resolver is enabled when you use the NET-CONFIG SET DOMAIN-NAMESERVERS command. This command defines the domain name servers that your system queries to satisfy host-name-to-address translation, and is normally set to the local host. MultiNet is initially configured to provide a caching-only name server, which works with the resolver. When the resolver fetches a mapping, it is "cached" by the name server and stored for other applications that need the information.

The resolver is almost always invisible to an applications programmer. When using the MultiNet socket library, the normal host table access routines, such as gethostbyname() and gethostbyaddr(), automatically call the DNS resolver routines and only use host table access when a DNS resolver fails. For the MultiNet OpenVMS/ULTRIX Connection (UCX) $QIO Driver, the $QIO functions for translating host names and addresses are referred to as the MultiNet MULTINET_SERVER process, which then uses the DNS resolver routines to satisfy the UCX name translation query.

The MultiNet SMTP symbiont queries the Internet DNS for mail forwarding information and calls the DNS resolver routines directly to query the DNS for Mail Exchanger (MX) resource records.

DNS Server

The MultiNet DNS server is based on the ISC BIND 9 Nameserver. The MULTINET_SERVER process starts the NAMED_SERVER process if the nameserver process is not running. The DNS server processes queries from resolvers, then responds to the queries, or queries other DNS servers to obtain information from other parts of the DNS database.

MultiNet is shipped with DNS configured to operate as a caching-only server in the Internet environment.

The MultiNet DNS server uses the MULTINET:NAMED.CONF file for configuration information. The configuration file is the equivalent of the /etc/named.conf file used by UNIX-based BIND implementations.

The configuration file typically contains references to other files that contain definitions for the server's contribution to the DNS database. These other files contain text in standard "resource record" format, as described in RFC-1035, "Domain Names - Implementation and Specification."

The ISC BIND 9 distributed HTML documents are on the CD-ROM in the directory named [BIND9-DOC]. Refer to the file named INDEX.HTML for a list of BIND documents.

Enabling a Caching-Only Name Server

A caching-only name server queries other nameservers to resolve host names to IP addresses. The answers received from the inquiry are retained and used in subsequent name resolver requests without querying the remote name server. The default DNS configuration files are shipped as a caching-only server; you only need to enable DNS.

Note: Master, or authoritative, name servers also cache responses to their queries.

Use a caching-only name server if your OpenVMS system is not the authoritative name server for any domain.

To determine whether DNS is enabled on your system, check the MULTINET_NAMESERVERS logical name:

$ SHOW LOGICAL MULTINET_NAMESERVERS

If DNS is enabled, your system is already set up to use DNS to resolve host names and addresses. If the logical is set to 127.0.0.1, your system also acts as its own name server.

If DNS is not enabled, you can enable it to take effect when the system is rebooted or to take effect immediately.

To enable the caching-only name server to take effect when the system reboots:

$ MULTINET CONFIGURE
MultiNet Network Configuration Utility 5.6(nnn)
[Reading in MAXIMUM configuration from MULTINET:MULTINET.EXE]
[Reading in configuration from MULTINET:NETWORK_DEVICES.CONFIGURATION]
NET-CONFIG>SET DOMAIN-NAMESERVERS 127.0.0.1
NET-CONFIG>SET HOST-NAME fully-qualified-domain-name

Also ensure the fully qualified domain name (FQDN) is included in your host table. The easiest way to do this is to modify the HOST line that describes your system in MULTINET:HOSTS.LOCAL to be of this form:

HOST : address(s) : FQDN,short_name : [CPU] : [OS] : [services] :

See Adding Host Definitions earlier in this section for more information. If you change the MULTINET:HOSTS.LOCAL file to include your FQDN, you must also recompile the table and install it as a global section, as shown in this example:

$ MULTINET HOST_TABLE COMPILE
$ @MULTINET:INSTALL_DATABASES

To make the change take effect without rebooting:

1. Define the logical name MULTINET_NAMESERVERS as 127.0.0.1 to take advantage of your local name server's cache:

$ DEFINE/SYSTEM/EXECUTIVE MULTINET_NAMESERVERS "127.0.0.1"

2. Define the official, fully qualified domain name:

$ DEFINE/SYSTEM/EXECUTIVE_MODE MULTINET_HOST_NAME "fqdn"
$ DEFINE/SYSTEM/EXECUTIVE_MODE ARPANET_HOST_NAME "fqdn"
$ DEFINE/SYSTEM/EXECUTIVE_MODE UCX$INET_HOST "name"
$ DEFINE/SYSTEM/EXECUTIVE_MODE TCPIP$INET_HOST "name"
$ DEFINE/SYSTEM/EXECUTIVE_MODE UCX$INET_DOMAIN "domain"
$ DEFINE/SYSTEM/EXECUTIVE_MODE TCPIP$INET_DOMAIN "domain"

3. Define the UCX equivalents:

$ DEFINE/SYSTEM/EXECUTIVE_MODE UCX$BIND_DOMAIN "domain-name"
$ DEFINE/SYSTEM/EXECUTIVE_MODE UCX$BIND_SERVER000 "127.0.0.1"
$ DEFINE/SYSTEM/EXECUTIVE_MODE TCPIP$BIND_DOMAIN "domain-name"
$ DEFINE/SYSTEM/EXECUTIVE_MODE TCPIP$BIND_SERVER000 "127.0.0.1"

4. Restart the MULTINET_SERVER process:

$ @MULTINET:START_SERVER

5. Restart the SMTP symbiont(s):

$ @MULTINET:START_SMTP

Caching-Only Name Server Configuration with Forwarders

A caching-only name server usually sends queries directly to the name server that contains the answer. A forwarders option can be used to redirect these queries to a central name server that accepts recursive queries from other servers and functions as a second-level cache. The central name server then queries the name server that contains the answer, and caches a copy.

Configure caching-only name servers with forwarders in a network with multiple caching servers to:

· Reduce load on your connection to the Internet.

· Improve DNS response to repeated queries.

Note: Although adding forwarders statements improves DNS response times, DNS does not require it.

If the DNS server configuration file specifies one or more forwarders, the server sends all queries for data not in the cache to the forwarders.

Use a text editor to add a forwarders statement to the options {}; section of the NAMED.CONF file to forward for all zones. Forwarding can also be specified on a per-zone basis, or turned off on a per-zone basis using forwarders { };.

For example, to add two servers with these IP addresses 192.1.1.98 and 192.1.1.99, the forwarders statement would be:

forwarders { 192.1.1.98; 192.1.1.99;};

There is also a forward option that tells the server how to use the forwarders. The forward option is only meaningful if the forwarders list is not empty. There are two values to use with the forward option.

Value	Description
forward first; (default)	The server queries the forwarders first. If the forwarders fail to find an answer, the server queries the root servers.
forward only;	The server queries the forwarders only. If the forwarders fail to find an answer, the server does not query the root domain servers.

For example, to use the forwarders only:

options {
forward only;
forwarders { 192.1.1.98; 192.1.1.99;};
};

After adding the forwarders and forward lines, restart the nameserver.

$ REPLY/ENABLE=NETWORK/TEMPORARY
$ MULTINET NETCONTROL DOMAIN RESTART

Using a Search List to Resolve Host Names

When you specify a simple host name, the DNS resolver expands automatically the simple name by appending the local host's domain to it. For example, if your host is bos1.example.com and you enter this command: $ TELNET sfo1 the DNS resolver expands sfo1 automatically into sfo1.example.com and attempts to translate that name into an address.

To have a different domain appended to host names, or to search multiple domains, define the MULTINET_SEARCHDOMAINS logical. If you specify multiple domains, separate them with blanks. For example, to have the resolver search for simple names in the domains sub1.example.com and sub2.example.com instead of the local domain, use the following logical name definition:

$ DEFINE MULTINET_SEARCHDOMAINS "sub1.example.com sub2.example.com"

This logical can be defined by individual users or as a system-wide logical (with the /SYSTEM qualifier). The search list can be up to 511 bytes in length. To search the local domain in addition to other domains, include the local domain in the MULTINET_SEARCHDOMAINS list. The maximum number of domains to search is 6.

Setting Up a Master Name Server

The following procedure sets up a master, or authoritative, name server. This type of name server gets data for its zone from files on the host where it runs. A zone is the domain, or portion of a domain, for which the master server has complete information. To set up a master server:

1. Determine whether DNS is enabled on your system by checking the logical name MULTINET_NAMESERVERS:

$ SHOW LOGICAL MULTINET_NAMESERVERS

If MULTINET_NAMESERVERS is defined, your system uses DNS to resolve host names and addresses. If MULTINET_NAMESERVERS is 127.0.0.1, your system also acts as its own DNS server.

2. If it is not already enabled, enable DNS by specifying one or more DNS servers with NET-CONFIG using the SET DOMAIN-NAMESERVERS command.

Note: The name server list can include up to three IP addresses.

3. Make sure the official host name configured in MULTINET CONFIGURE is the fully qualified domain name of the name server. If not, define it without rebooting using the following command:

$ DEFINE/SYSTEM/EXECUTIVE_MODE MULTINET_HOST_NAME "fully qualified domain name"

4. To specify the time between DNS name server requests to a nonresponding server and the number of attempts to make to re-establish communications, use the NET-CONFIG SET NAMESERVER-RETRANSMISSION command.

5. Update the DNS configuration file, MULTINET:NAMED.CONF, to add information about your site, as described in the MULTINET:NAMED.CONF section.

6. For each zone of type master, add a zone file to describe the zone characteristics. A zone is a range of authority that includes one or more fully qualified domains or part of a domain. A zone file describes the contents of a zone. Configuring a zone information file is described in the DNS Zone Information Files section.

7. Reload the DNS server (see the Reloading the Name Server section).

To prevent log files from being truncated when they are closed, use the logical MULTINET_SERVER_DONT_TRUNCATE_LOG. Note that the default allocation quantity for the log files is 80 blocks, so they could have a moderate amount of empty space.

Domain Name versus Host Name

Your domain name should not also be the primary name of a host on your network. This is because of a possible conflict between the host name LOCALHOST and a registered Internet domain.

For example, if your domain name is example.com, and you want to have a host with the same name, give the host a different primary name, such as main.example.com. Create an appropriate A (address) and record and PTR (inverse lookup) entry with the name main.example.com. Then, add an A record for example.com that also points to the address for main.example.com.

If you already have a host with the same name as your domain name and the host is running MultiNet, configure a local domain for the MultiNet resolver on that system. For example:

$ MULTINET CONFIGURE
NET-CONFIG>SET LOCAL-DOMAIN example.com
NET-CONFIG>EXIT

The MULTINET:NAMED.CONF File

The main DNS configuration file, from which the name server gets its initial data, is MULTINET:NAMED.CONF. The equivalent of this file in UNIX-based BIND implementations is /etc/named.conf. Use this file to add information about your site when setting up a master DNS server. An example configuration file follows.

/*
** Sample Configuration File for DNS server
*/

options {
    directory "SYS$SYSROOT:[MULTINET]";
// forward only;
    forwarders { 128.0.1.1; 128.0.2.10; };
};

zone "example.com" in {
    type master;
    file "domain-name-service.bos";
};

zone "0.128.in-addr.arpa" in {
    type master;
    file "domain-name-service.bos-net";
};

zone "sfo.example.com" in {
    type slave;
    masters { 128.0.1.1; };
    file "domain-name-service.sfo";
};

zone "1.0.128.in-addr.arpa" in {
    type slave;
    masters { 128.0.1.1; };
    file "domain-name-service.cc-net";
};

zone "0.0.127.in-addr.arpa" in {
      type master;
      file "domain-name-service.local";
};

zone "localhost" in {
      type master;
      file "domain-name-service.localhost";
};

zone "." in {
      type hint;
      file "domain-name-service.cache";
};

The following sections describe the zone, options, and logging sections.

Zone

A zone is that part of a name server that contains complete information about the domain name space. You specify a zone in the following way:

zone “domainname” [class] {
type type;
[other statements...]
};

NAMED.CONF zone fields defines the NAMED.CONF zone fields.

Field

Description

class

The class to which this zone applies. If the class is not specified, the type IN is used by default. The syntax is [ ( in | hs | hesiod | chaos ) ]:

· in (default) - Used for objects connected to the Internet. This is the only supported type.

· hs or hesiod - Confined mostly to MIT.
hs is the abbreviation for hesiod.

· chaos - An historic network. Not used today.

“domain name”

The name of the domain for which this zone is authoritative.

Zone statements:

Statement	Description
file "filename";	Specifies the name of the zone file.
masters [ port ip_port ] {ip_addr; [ip_addr; ... ]};	Specifies the IP address(es) and port from where the server is to transfer the zone data. This statement is meaningful only for slave or stub zones.
type (master \| slave \| stub \| hint \| forward);	See the Zone Types table for a description of these zones.

Optional Zone Statements:

Statement	Description
allow-query { address_match_list; }; allow-transfer { address_match_list; };	Overrides the allow-query and the allow-transfer statements in the global options section for this zone. See NAMED.CONF Options.
allow-update { address_match_list; };	Specifies the addresses of hosts that are allowed to modify the zone with dynamic updates. Defaults to none.
also-notify {ip_addr; [ip_addr; ...] };	Overrides the “also-notify” statement in the global options section for this zone. See NAMED.CONF Options.
check-names (warn \| fail \| ignore);	Overrides the default name checking specified in the global options section. See the check-names statement in NAMED.CONF Options for more details.
forward (only \| first); forwarders {[ip_addr;...]};	Overrides the forward and forwarders statements in the global options section for this zone. See NAMED.CONF Options.
ixfr-base path_name;	Specifies the file name used for the IXFR transaction log file.
notify [(yes \| no); ]	Specifies if zone change notifications should be sent to the slave servers for the zone. This overrides the notify statement in the global options section. See the notify statement in NAMED.CONF Options for more details.
pubkey flags protocol algorithm key;	Represents a public key for this zone. The key is needed when this is the top level authoritative zone served by this server and there is no chain of trust to a trusted key. The key is considered secure, so data it signs will be considered secure. The DNSSEC flags (number), protocol (number), and algorithm (number) are specified, as well as a base-64 encoded string representing the key.
transfer-source ip_addr;	Overrides the transfer-source statement in the global options section for this zone. See NAMED.CONF Options.

Zone Types:

Type	Description
forward	A forward zone is use to direct all queries in it to other servers. The specification of the options in such a zone overrides any global options declared in the options statement. If a forwarders statement is not present in the zone or an empty list for forwarders is given, forwarding is not done for the zone, cancelling the effects of any forwarders in the options statement. Thus, if you want to use this type of zone to change the behavior of the global forward option, and not the servers used, you need to re-specify the global forwarders.
hint	The MULTINET:NAMED.CONF file example specifies that data in the DOMAIN-NAME-SERVICE.CACHE file, which is in standard resource record format, should be placed in the bootstrap cache. The hint zone definition is used to specify locations of root domain servers. An up-to-date list of root name servers is obtained automatically and stored in memory without replacing the cache file.
master	Specifies data for the zone and the domain. The first master zone definition in the example states that the file DOMAIN-NAME-SERVICE.BOS contains authoritative data for the EXAMPLE.COM zone, in standard resource record format. The second master zone definition in the example states that the file DOMAIN-NAME-SERVICE.BOS-NET contains authoritative data for the domain 0.128.IN-ADDR.ARPA, which is used in translating addresses in network 128.0.0.0 to host names. Each zone master file should begin with an SOA (Start Of Authority) resource record for the zone, as shown in the DNS section.
slave	Specifies the zones for which this DNS server acts as a secondary name server. After this name server receives a "zone transfer," it becomes authoritative for the specified zone. The first slave zone definition in the example on page 10-13 specifies that all authoritative data under CC.FLOWERS.COM is to be transferred from the name server at 128.0.1.1. The file statement in this section is the file name in which to back up the transferred zone. When it boots, the name server loads the zone from this backup file, if it exists, providing a complete copy even if the master DNS server is unreachable. This file is updated whenever a new copy of the domain is received by automatic zone transfer from one of the master servers. The file statement is optional, but recommended to speed up server startup and eliminates needless bandwidth. The second slave zone definition in the example states that the address-to-hostname mapping for the subnet 128.0.1.0 should be obtained from the same list of master servers as the previous zone.
stub	Works like a slave zone, except it only transfers the nameserver records for the master zone rather than the full zone information.

Options

The options statement sets up global options to be used by BIND. Use this statement only once in a configuration file. If it is used more than once, the first occurrence determines what options to use, and a warning is generated. If no options statement is present, an options block is used setting each option to its default value. You specify options in the following way:

options {
options statements
};

Note: The following table shows some of the more commonly used option statements. For a full listing of the option commands that can be specified, please consult a detailed text such as O’Reilly’s “DNS and BIND”, or else consult the BIND RFC.

This table defines the NAMED.CONF options:

Option

Description

allow-query {address_match_list; };

See the Address_match_list section.

Specifies the addresses of hosts that are allowed to query the server for information. It defaults to all.

allow-recursion {address_match_list;};

See the Address_match_list section.

Specifies which hosts are allowed to make recursive queries through this server. If not specified, recursive queries from all hosts are allowed (default).

allow-transfer {address_match_list;};

See the Address_match_list section.

Specifies the addresses of hosts that are allowed to perform zone transfers from the server. It defaults to all.

also-notify
{ip_addr; [ip_addr; ...]};

Defines a global list of IP addresses that get sent NOTIFY messages whenever a fresh copy of the zone is loaded. This ensures that copies of the zones converge quickly on “stealth” servers. If an also-notify list is given in a zone statement, it overrides the options also-notify statement. When a zone notify statement is set to NO, the IP addresses in the global also-notify list are not sent NOTIFY messages for that zone. The default is the empty list (no global notification list).

blackhole {address_match_list;};

See the Address_match_list section.

Specifies a list of addresses the server will not accept queries from or use to resolve a query. Queries from these addresses will not be responded to.

check-names (master | slave | response)
(warn | fail | ignore);

The server checks names in three areas:

· Master zone files.

· Slave zone files.

· Responds to queries the server has initiated.

The server assumes the following defaults:

options {
   check-names master fail;
   check-names slave warn;
   check-names response ignore;
};

ignore - No checking is done.

warn - Names are checked against their expected client contexts. Invalid names are logged, but processing continues normally.

fail - Names are checked against their expected client contexts. Invalid names are logged, and the offending data is rejected.

If check-names response fail has been specified, and answering the client’s question requires sending an invalid name to the client, the server sends a REFUSED response code to the client instead.

directory "path";

Causes the server to change its default directory to the specified directory. This can be important for the correct processing of $INCLUDE files in primary zone files, or file statements in zone definitions.

fake-iquery ( yes | no );

BIND 9 does not do IQUERY simulation. Obsolete.

fetch-glue ( yes | no );

Obsolete for BIND 9.

forward ( only | first );

This statement is meaningful only if there is a non-empty forwarders statement.

When first (default) is used, the server queries the forwarders first before consulting the root domain servers.

When only is used, the server queries the forwarders only. If the forwarders fail to find an answer, the server does not query the root domain servers. For example:

options {
forward only;
forwarders
{ 192.1.1.98; 192.1.1.99;};
};

forwarders
{ip_addr; [ip_addr; ... ]};

Specifies the addresses of site-wide servers that accept recursive queries from other servers. If the DNS server configuration file specifies one or more forwarders, the server sends all queries for data not in the cache to the forwarders.

Central name servers designated to handle forwarded requests can then develop a cache of answers to external queries. The central cache reduces the number of requests sent to root name servers and improves DNS performance.

listen-on [port ip_port]
{address_match_list; };

also see listen-on-v6

See the Address_match_list section.

Specifies what port on what interface to listen on. The default is:

listen-on port 53 { any };

For example:

options {
   // listen on port 53 for
   // external interfaces.
   listen-on { 10.0.0.0;};
   // listen on port 43 for
   // internal interfaces.
   listen-on port 43
     { 127.0.0.1; 10.0.0.0; };
};

provide-ixfr (yes | no );

If yes, a transaction log is kept for incremental zone transfer of each zone. The default is yes.

max-ixfr-log-size number;

Obsolete for BIND 9.

max-transfer-time-in number

Terminates the inbound zone transfers (named-xfer processes) running longer than the minutes specified. The default is 120 minutes (2 hours).

min-roots number;

Obsolete for BIND 9.

notify ( yes | no );

If yes (default), the server notifies slave servers if there are any changes to a domain for which the server is master or slave. The server determines the slave servers by the nameserver records contained in the zones data file.

For more information, see the also-notify statement.

query-source [address ( ip_addr | * )]
[port ( ip_port | * )] ;

Address_match_list

The following can be address match lists:

· An IP address (in dotted-decimal notation)

· Another address match list

· An IP prefix (in /- notation)

· An address match list defined with the acl statement

· A key ID, as defined by the key statement

The following Access Control Lists (ACLs) are predefined and are not case-sensitive:

· any

· none

· localhost

· localnets

Place the ! character in front of elements you want to negate.

Remember that address match lists follow the standard named.conf syntax and require a semi-colon (;) after each element. For example:

allow-update { !192.168.0.1; 192.168.0.0/16; };

When an IP address or prefix is compared to an address match list, the list is examined and the first match (regardless of its negated state) is used. The interpretation of a match depends on the conditions defined in the following table.

When a list is being used...

A non-negated match...

A negated match...

as an access control list

allows access.

denies access.

with the listen-on option

causes the DNS server to listen on matching interfaces.

causes the DNS server to NOT listen on matching interfaces.

with the topology clause

returns a distance based on its position on the list; the closer the match to the start of the list, the shorter the distance between it and the server.

is assigned the maximum distance from the server.

Note: If there is no match, the address gets a distance that is further than any non-negated list element, and closer than any negated element.

Since the address match list uses a first-match algorithm, care must be taken when using negation. In general, if an element is a subset of another element, the subset should be present in the list before the broader element.

For example, 10.0.0/24; !10.0.0.1 will never negate to the 10.0.0.1 address because a 10.0.0.1 address will match with the 10.0.0/24 element and not traverse any farther. So the 10.0.0.1 address will be accepted in the match list.

Using !10.0.0.1; 10.0.0/24 will elicit the desired effect. The 10.0.0.1 will be matched against the first, negated, element. All other 10.0.0.* addresses will pass by the 10.0.0.1 element and be matched against the 10.0.0/24 subnet element.

Logging

The logging section configures a wide variety of logging options for the nameserver. Its channel phrase associates output methods, format options and severity levels with a name that can be used with the category phrase to select how various classes of messages are logged. The basic logging syntax is as follows:

logging {
    channel channel_name {
         file name [versions number] [size bytes];
       | syslog daemon;
       | null;
       severity type;
       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 section is used to define as many channels and categories as you want. If there are multiple logging sections in a configuration, the first one defined determines the logging, and warnings are issued for the others. If there is no logging section, the default 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; };
};

The following is an example:

logging {
    channel xfers {
        file “MULTINET:XFERS.LOG”;
        severity info;
        print-severity yes;
        print-time yes;
    };
    category xfer-in {
        xfers;
    };
};

This table describes the logging options.

Options	Description
channel	Specifies where the logging data goes: to syslog (OPCOM), to a file, to stderr (SYS$ERROR), or to null (discarded).
category	Specifies what data is logged. You can send a category to one channel or to many channels. These are the valid categories: cname lame-servers packet security config load panic statistics db maintenance parser update default ncache queries xfer-in eventlib notify response-checks xfer-out insist os
file	Specifies the path name of the file you want the message to go to, and if you want to have multiple versions of the file, and if you want to limit the size of the file.
syslog daemon	Specifies that the message goes to syslog (OPCOM) instead of to a file.
severity	Specifies the severity level for this channel. The severity choices are: critical, error, warning, notice, info, debug [level], and dynamic.
print-category print-severity print-time	Specifies whether to print the category, severity level, and time stamp of the messages. The default is NO for each item.

Resource Record Sorting

When returning multiple resource records (RRs), the nameserver returns them by default in round robin order, that is, after each request the first RR is placed at the end of the list. You can specify in the NAMED.CONF file that the nameserver should sort the RRs based on the client's address using the sortlist option, or you can use a default other than round-robin using the rrset-order option.

The sortlist option sorts the RRs based upon the address_match_list. Each top level statement in the address match list must be an address match list with one or two elements. The first element of each address match list is checked against the client's address until a match is found. When a match is found:

If the top level statement contains...	Then...
only one element	that network is moved to the front of the list.
two elements	the second element is treated like the address match list in the topology option (see NAMED.CONF Options).

Use the following sortlist statement to have the nameserver behave like the BIND 4.9.x nameserver.

Responses to...
queries from the local host	prefers any of the directly connected networks
queries from any other hosts on a directly connected network	prefers addresses on that same network
other queries	are not sorted

sortlist {
{ localhost; localnets; };
{ localnets; };
};

The rrset-order option permits configuration of the ordering for the records in a multiple record response. An order_spec is defined as follows:

[ class class-name ] [ type type-name ] [ name "fqdn" ] order ordering;

The legal values for ordering are:

fixed	records are returned in the order they are defined in the zone file
random	records are returned in some random order
cyclic	records are returned in round-robin order (default)

The following example specifies that only A, NS, and MX records are round-robined. This provides the same behavior as the MultiNet 4.2 nameserver.

rrset-order {
   class IN type A name "*" order cyclic;
   class IN type NS name "*" order cyclic;
   class IN type MX name "*" order cyclic;
   order fixed;
};

Incremental Zone Transfer

BIND 9.7.2-p3 contains an implementation of incremental zone transfer (IXFR) - it is on by default. If you need to turn it off for a particular slave server, use the provide-ixfr server substatement, which defaults to yes:

server ip_addr {
provide-ixfr ( yes | no );
};

DNS Zone Information Files

The DNS server configuration file contains references to DNS zone information files, that contain control information and a list of resource records for objects in the zone. The file format of a zone information file is:

$INCLUDE filename [domain]
$ORIGIN domain
$TTL default-ttl
$GENERATE range lhs type rhs
domain [ttl] [class] record-type resource_data

If the domain is specified as ".", the domain is the ROOT domain. If the domain is specified as an at sign (@), the domain is the current origin. Anything else is taken as a standard domain name, that if terminated by a dot (.) is used verbatim; otherwise, the current origin is appended to the specified domain name.

The optional domain field in a $INCLUDE line is used to define an origin for the data in an included file. It is equivalent to placing a $ORIGIN statement before the first line of the included file. The field is optional. Neither the optional domain field in the $INCLUDE line nor $ORIGIN statements in the included file modify the current origin for this file.

The $TTL statement sets the default time-to-live for records that do not have explicit ttl fields. If the zone file does not have a $TTL statement, the DNS server prints a warning on your computer screen and uses the minimum value from the SOA record.

The optional ttl field is an integer value to specify in the time-to-live field in the following ways:

Each of these is equivalent to one week.

· 604800

· 1w

· 7d

· 168h

· 10080m

· or any combination

For example: sigma 2h46m40s IN A 192.1.1.97

Loads the TTL as: ttl = 10000 (2 hours 46 mins 40 secs)

The default is to use the value specified in the $TTL directive or SOA resource record for the zone. The optional class field is the object address type; currently only one type (IN, for objects connected to the Internet) is supported.

The record-type field is also known as "resource record types." The below table shows the most commonly used DNS resource record types and their uses (the data expected in the resource_data field is shown in brackets [ ]).

DNS Resource Record Types:

Record Type	Use
A	A host address [IP-address]
CNAME	The canonical name for an alias [domain-name]
HINFO	Host information [CPU-type OS-type]
KEY	The public key associated with a domain name [flags protocol algorithm key]
MB	A mailbox domain name [domain-name]
MG	A mail group member [domain-name]
MINFO	Mailbox or mail list information [request-domain error-domain]^b
MR	A mail rename domain name [domain-name]
MX	A mail exchanger [preference domain-name]
NS	An authoritative name server [domain-name]
NULL	A null resource record [none]
NXT	Used for secure negative responses. Tells a querier which record is lexicographically next in the zone [next-domain-name type-bitmap]
PTR	A domain name pointer [domain-name]
SIG	A security signature for an RRset [type algorithm labels ttl expiration inception tag name signature]
SOA	The start of a zone of authority [domain of originating host, domain address of maintainer, a serial number and the following parameters in seconds: refresh, retry, expire, and minimum time-to-live] (see RFC-1035)
SRV	Specifies the location of services [priority weight port target]
TXT	Arbitrary text [text-string]
WKS	A well-known service description [address protocol service-list]

Resource records are usually single-line entries, but SOA records may be continued across lines by surrounding the resource record statements with open and close parentheses. Comments begin with semicolons and continue to the end of the line. Each zone information file should begin with an SOA resource record for the zone. An example SOA resource record follows.

@    IN   SOA VMSITE.EXAMPLE.COM.    system.EMAIL.EXAMPLE.COM. (
                         2000022101     ; serial number as yyyymmddnn
                         7200           ; refresh every 2 hours
                         7200           ; retry every 2 hours
                         12096000       ; expire in twenty weeks
                         86400 )        ; minimum time-to-live

The SOA resource record lists a serial number that DNS administrators should increase each time they modify the master file. Secondary servers check the serial number at intervals specified by the refresh time. If the serial number has increased since the last zone transfer, the secondary name server requests a new zone transfer and then loads the new zone data.

In the preceding example, VMSITE is a host in the EXAMPLE.COM domain. This should be the primary DNS server for this zone.

“system.EMAIL.EXAMPLE.COM" is the email address of the DNS zone administrator on the EMAIL host in the EXAMPLE.COM domain.

Note: Although the DNS zone administrator's email address is specified without an at sign (@), the effective email address requires changing the first period to @. For example, the email address of the DNS zone administrator in the preceding example is system@EMAIL.EXAMPLE.COM.

If you configure your name server as a secondary name server, it contacts the primary name server for a new zone transfer after the refresh interval expires. If the server does not receive a response after the "retry" interval, it tries repeatedly to contact the primary name server until it succeeds. If the secondary server fails to contact the primary name server before the expire interval elapses, it discards all data from the zone.

The minimum value is the time-to-live value used by records in the file with no explicit value if there is no $TTL statement. It is used also as the time-to-live value for negative caching.

Set the expire time to a value long enough to accommodate the retry and refresh intervals. If the refresh interval exceeds the expiration time, the data on your secondary server will expire before new data can be loaded. The following example shows a zone information file for the zone EXAMPLE.COM.

;
;       Authoritative data for EXAMPLE.COM
;
$TTL 86400
@    IN   SOA VMSITE.EXAMPLE.COM. system.EMAIL.EXAMPLE.COM. (
                         2000022107 ; serial number as yyyymmddss, where
                                       ; ss is the zone change sequence count
                          7200      ; refresh every 2 hours
                          7200      ; retry every 2 hours
                          12096000 ; expire in twenty weeks
                          86400 )   ; minimum time-to-live
                IN      NS      VMSITE.EXAMPLE.COM.
                IN      NS      SPACELY.EXAMPLE.COM.
;
;   Information about the host EXAMPLE.COM
;
EXAMPLE.COM.    IN      MX      0       EXAMPLE.COM.
                IN      A       192.0.0.1
                IN      HINFO   VAXSTATION-9440 VMS
;
;   The loopback address and host
;
LOCALHOST.      IN      A       192.0.0.1
                IN      HINFO   LOOPBACK-HOST LOOPBACK
;
;   The remaining hosts
;
AARDVARK        IN      A       192.0.0.2
                IN      MX      0       AARDVARK
                IN      HINFO   VAXSTATION-3200 VMS
John            IN      A       192.0.0.3
                IN      MX      0       John.EXAMPLE.COM.
                IN      HINFO   VAXSTATION-3100 VMS

The SOA resource record indicates the start of authority for the zone EXAMPLE.COM. The NS resource records indicate which DNS name servers are authoritative for the zone. The remainder of the file lists each host and information about it. VMSITE is a system in the EXAMPLE.COM domain. The system.EMAIL.EXAMPLE.COM is the email address on the EMAIL host in the EXAMPLE.COM domain.

An example of a zone information file for the zone 0.128.IN-ADDR.ARPA follows. This file contains the information needed to map IP addresses in the network 128.0.0.0 into host names. This file contains an example of the PTR record type.

;
;       Authoritative data for 0.128.IN-ADDR.ARPA
;
$TTL 86400
@    IN   SOA VMSITE.EXAMPLE.COM.    system.EMAIL.EXAMPLE.COM. (
                          2000022101   ; serial number as yyyymmddnn
                          7200         ; refresh every 2 hours
                          7200         ; retry every 2 hours
                          12096000     ; expire in twenty weeks
                          86400 )      ; minimum time-to-live
                IN      NS      VMSITE.EXAMPLE.COM.
                IN      NS      SPACELY.EXAMPLE.COM.
;
; Network database
;
1.0             IN      PTR     EXAMPLE.COM.
2.0             IN      PTR     AARDVARK.EXAMPLE.COM.
3.0             IN      PTR     JOHN.EXAMPLE.COM.

Reloading the Name Server

To reload the running server:

$ MULTINET NETCONTROL DOMAIN RELOAD

To restart the name server:

$ MULTINET NETCONTROL DOMAIN RESTART

Note: The master server must be restarted before the nameserver restarts to load in any net-config or server-config changes @multinet:start_server.

Controlling the MultiNet DNS Server

You can use the MultiNet NETCONTROL server to request that the DNS server perform specific actions. The name to specify to NETCONTROL for the DNS server is DOMAINNAME.

Refer to the NETCONTROL DOMAINNAME table of commands in the MultiNet Administrator’s Reference.

When the server is busy, NETCONTROL sends a message stating that your request has been queued, and it will be acted upon when it is the next one in the queue to be serviced. When the server is not busy, it performs your request while NETCONTROL waits (except for the case of RELOAD). For example,

DOMAINNAME>stat
<Dumping Nameserver Statistics
<Domain-Name-Server Busy, Request Queued

Using NSLOOKUP and DIG to Debug DNS

The MultiNet NSLOOKUP and DIG utilities send test queries to a DNS Name Server to test the configuration. NSLOOKUP enters interactive mode when invoked without arguments. The table below describes the valid interactive commands. For information about DIG and more information about NSLOOKUP, see Chapter 1 of the MultiNet Administrator’s Reference.

Command	Description
name	Prints information about name using the default server.
name server	Prints information about name using server.
exit	Exits NSLOOKUP.
finger [user]	Finger the optional user at the current default host.
help or ?	Prints help information.
set all	Prints the current status of all options.
set class=class	Sets the query class to one of these: IN, CHAOS, HESIOD, or ANY.
set [no]debug	Prints debugging information.
set [no]d2	Prints exhaustive debugging information.
set [no]defname	Appends the domain name to each query.
set [no]recurse	Asks for a recursive answer to query.
set [no]vc	Always uses a virtual circuit (TCP instead of UDP).
set domain=name	Sets the default domain name to name.
set port=port	Sets the port number on which to send a query.
set root=name	Sets the root name server to name.
set retry=n	Sets the number of retries to n.
set srchlist=name1 [/name2/.../name6]	Sets the domain to name1 and the search list to name1 through name6.
set timeout=n	Sets the timeout interval to n.
set querytype=type or set type=type	Sets the resource record (RR) type to query for.
server name	Sets the default server to name, using the current default server.
lserver name	Sets the default server to name, using the original default server.
root	Sets the current default server to the root.
ls [option] name [> file]	Lists the domain name, with output optionally going to file. option is one of the following: -a List canonical names and aliases -h List HINFO (CPU type and operating system) -s List well-known services -d List all records -t type List records of the given type (such as A, CNAME, and MX)

DNS Load Balancing

The MultiNet domain name server provides a feature called DNS load balancing, which is modeled after the service names available with HP's LAT terminal server support for VMScluster systems. The domain name server maintains a load rating for each node offering a particular service name and, when queried for the addresses records for that name, it orders them based on the load rating. This allows TCP-based services such as TELNET and FTP to be offered cluster-wide in a load-balanced fashion. To configure DNS load balancing on each cluster node that will offer the service:

1. Set up cluster services offered by this node with NET-CONFIG (see the Setting Up a Cluster Service section).

2. If your host is multi-homed (one that has more than one IP network interface), specify the IP address associated with the cluster services with NET-CONFIG (see the Advertised Cluster Service Addresses on Multi-Homed Hosts section).

3. Configure service ratings for advertised services (see the Setting Service Ratings section).

4. Add the new service names to your domain's DNS zone file (see the Adding Cluster Services to Your Domain's DNS Zone File section).

5. Monitor and test the status of your cluster service names with the MULTINET NETCONTROL DOMAINNAME SHOW command (see the Monitoring Cluster Service Names section).

Setting Up a Cluster Service

To configure a cluster service name with NET-CONFIG:

$ MULTINET CONFIGURE
NET-CONFIG>SET CLUSTER-SERVICE-NAMES name[,...]

Note: Don't confuse the DNS load balancing feature and the CLUSTER-SERVICE-NAMES parameter with the cluster alias feature and IP-CLUSTER-ALIAS parameter described in Chapter 11.

Each cluster service name must be a name not already in use on your network. Specify each name in its fully qualified form (for example, CLUSTER.EXAMPLE.COM). If you configure more than one name, separate the names with commas when you specify them. To activate your cluster service names on the running system, use the command:

$ DEFINE/SYSTEM/EXEC MULTINET_CLUSTER_SERVICE_NAMES "name"

If you are setting up multiple service names, enclose each name in quotation marks and separate the quoted names with commas. Once the logical name has been defined, restart the nameserver:

$ MULTINET NETCONTROL DOMAINNAME RESTART

Advertised Cluster Service Addresses on Multi-Homed Hosts

For a multi-homed host, you can control the address advertised for a cluster service with the NET-CONFIG SET CLUSTER-SERVICE-ADDRESS command:

NET-CONFIG>SET CLUSTER-SERVICE-ADDRESS address

If you do not configure a cluster service address for a host with multiple interfaces, the address advertised for the cluster service will be selected at random.

Setting Service Ratings

The load-rating algorithm used by the DNS server for cluster service names is similar to the algorithm used by LAT. It is based on the system load, the number of interactive processes on the system, and the amount of free physical memory on the system. If your VMScluster system contains CPUs of vastly different speeds and/or memory configurations, you may find that the algorithm always favors a faster or larger-memory system over a slower or smaller-memory system.

In an unbalanced cluster configuration, you may need to set either a static load rating or weight the rating computation by setting a CPU rating on each node:

· Static Ratings - A static rating is set by defining a logical name:

$ DEFINE/SYSTEM/EXEC MULTINET_CLUSTER_SERVICE_STATIC_RATING n

n is a decimal number ranging from 1 to 255.

When defined, this rating will be used in all cluster service advertisements, bypassing the dynamic load rating computations. The higher the number you set, the more "available" (or less loaded) the system will be.

· CPU Ratings - A CPU rating is also set by defining a logical name:

$ DEFINE/SYSTEM/EXEC MULTINET_CLUSTER_SERVICE_CPU_RATING n

n is a decimal number ranging from 1 to 100.

This is the weight value factored into the load rating calculation. To bias load ratings so that faster CPUs service more users, set a lower CPU rating value on your slower CPUs and a higher CPU rating on your faster CPUs.

After setting ratings, restart the nameserver:

$ MULTINET NETCONTROL DOMAINNAME RESTART

Adding Cluster Services to Your Domain's DNS Zone File

Once you have configured a cluster service name on your cluster, update your domain's primary name server DNS zone file to delegate authority over the cluster service name to the participating cluster nodes. To do this, add NS records that map each cluster service name to the participating nodes. For example, to add the cluster service name CLUSTER.EXAMPLE.COM, add the following lines to the configuration files on EXAMPLE.COM's primary name server:

CLUSTER.EXAMPLE.COM. IN NS NODE1.EXAMPLE.COM.
CLUSTER.EXAMPLE.COM. IN NS NODE2.EXAMPLE.COM.

The name on the left side is the cluster service name; the name on the right side is the domain name of a node offering the cluster service.

Monitoring Cluster Service Names

To check the status of your cluster service names, use the following NETCONTROL command:

$ MULTINET NETCONTROL DOMAINNAME SHOW

For each cluster service name, a listing of the nodes offering the service and their load ratings is displayed. For example:

$ MULTINET NETCONTROL DOMAINNAME SHOW

Connected to NETCONTROL server on "NODE1"
< Node1.Example.COM Network Control V5.6(10) at Mon 13-Mar-2020 4:35PM-EST
< Service CLUSTER.EXAMPLE.COM:
<   Nodename      Address      Rating
<   -------- --------------- ------
<   NODE1     10.41.228.101       75
<   NODE2     10.41.228.102       83
< End of line

You should also test a cluster service name using NSLOOKUP:

$ MULTINET NSLOOKUP CLUSTER.EXAMPLE.COM

Server: LOCALHOST
Address: 10.0.0.1
Name: CLUSTER.EXAMPLE.COM
Addresses:10.44.128.102, 10.44.128.101

NSLOOKUP should return the addresses from highest to lowest rating, although DNS caching can cause address ordering to lag behind rating changes for short periods of time.

DNS Security

BIND 9 includes an implementation of DNS Security (DNSSEC). A complete description of DNSSEC and its use is beyond the scope of this chapter. DNSSEC is described in RFC 2065 "Domain Name System Security Extensions" and various internet drafts.

MultiNet includes the following BIND tools related to DNS Security:

· DNSKEYGEN – Used for generating and maintaining keys.

· DNSSIGNER - Used for signing zones.

For more information on these tools, see the MultiNet Administrator’s Reference.

This section describes a simple scenario in which DNSKEYGEN and DNSSIGNER are used.

The simplest "normal" case is a zone which has no delegations, and is to be signed with a single zone key. Assume that the parent zone is secured and is able to sign the public zone key.

The first step in signing a zone is to generate a private-public key pair. This is done using DNSKEYGEN. This will generate a DNS zone master file version of the public key in a file with the suffix "key".

Example of key generation:

$ MULTINET DNSKEYGEN/DSA=768/ZONE/NOENCRYPT ZZ.TEST.

This results in the generation of two files, the names of which reflect the key owner, algorithm, and footprint. The names end in "key" and "private". The "key" file contains the DNS RR holding the public key, the "private" file has the data defining the private key. The latter file is set to be read/write only by the file's owner.

Example key file (key represented in base64 characters):

zz.test. IN KEY 16641 3 3 AQPIc...

Example private file:

Private-key-format: v1.1
Algorithm: 3 (DSA)
Prime(p): base 64 characters
Subprime(q): base 64 characters
Base(g): base 64 characters
Private_value(x): base 64 characters
Public_value(y): base 64 characters

Note: The two numeric fields in the key filenames will be different for each time dnskeygen is run. Also note that the "private" key's format will depend on the algorithm used to derive the key.

The next step is to run DNSSIGNER over the data. To make things simple, all files involved will be considered to be in the current default directory unless otherwise stated. In the directory where the file zone.1 resides there should be a "private" file for the key used for signing.

Example zone file (zone.1):

$ORIGIN zz.test.
@       IN SOA a.test. a.a.test. 1 360 36 60480 12
            NS a.test.
            NS b.test.
one         A   10.10.10.10
two         A   10.10.10.100
            MX 10 one.zz.test.
a.test.     A   10.11.12.13
b.test.     A   10.13.12.11

The public key (from the key file) is sent two different ways. One copy of the public key is sent to the parent zone for signing with the parent's zone key. The public key is also copied (or even $INCLUDE’d) into the zone.1 file. Signing may begin prior to receiving a response from the parent zone (which contains, among other things, the signed public key).

Although the public key is going to arrive from the parent at some time packaged with the signature, the unsigned key must be placed into the unsigned zone master file. The presence of the public key record alerts DNSSIGNER to perform certain functions, such as generating NXT records and generating parent files for its delegation points.

Caution! Although DNSSIGNER is flexible enough to withstand missing private keys, and late arriving parent files, it cannot be expected to behave correctly if the data used to derive the zone master file changes during the execution of the signing process. In accordance with this, the public key should be added to the zone even though the key will also arrive from the parent later. DNSSIGNER will remove duplicate records.

Example of signing a zone:

$ MULTINET DNSSIGNER/ZONE=(INP=ZONE.1, out=ZONE.2) -
/SIG=KEY=(DOM=ZZ.TEST, ALG=3, KEY_ID=6750)

The result of the run will be a new zone file. The file zone.2 will appear something like the following:

Example output of DNSSIGNER (zone.2):

$ORIGIN zz.test.
zz.test. 12    IN   SOA   a.test. a.a.test. 1 6M 36S 16h48m 12S
         SIG   SOA 1 12 19980223163147 19980123163147 6750 zz.test. (...)
zz.test. KEY   0x4101 3 1 (...)
zz.test. NS    a.test.
         NS    b.test.
         SIG   NS 1 12 19980223163147 19980123163147 6750 zz.test. (...)
zz.test. NXT   one.zz.test. NS SOA SIG KEY NXT
         SIG   NXT 1 12 19980223163147 19980123163147 6750 zz.test. (...)
one      A     10.10.10.10
         SIG   A 1 12 19980223163147 19980123163147 6750 zz.test. (...)
one      NXT   two.zz.test. A SIG NXT
         SIG   NXT 1 12 19980223163147 19980123163147 6750 zz.test. (...)
two      A     10.10.10.100
         SIG   A 1 12 19980223163147 19980123163147 6750 zz.test. (...)
two      MX    10 one.zz.test.
         SIG   MX 1 12 19980223163147 19980123163147 6750 zz.test. (...)
two      NXT   zz.test. A MX SIG NXT
         SIG   NXT 1 12 19980223163147 19980123163147 6750 zz.test. (...)
a.test. A     10.11.12.13
b.test. A     10.13.12.11

All of the "(...)" fields are base64 encoded values. This file is complete except for the missing signature by test. over the zz.test. KEY record. If this file is sent to a secured name server, the zone data will be rejected unless the zone key happens to have been configured.

Note: It is wise not to configure the zone key for a zone unless the parent will not be signing the zone key.

Eventually, the parent file will arrive. After obtaining the file, the DNSSIGNER needs to be run again to include the new data.

Example parent file (parent.1):

zz.test. NXT   zzz.test. NS SIG KEY NXT
zz.test. SIG   NXT 1 12 19980229163147 19980129163147 12345 test. (...)
zz.test. KEY   0x401 3 1 (...)
zz.test. SIG   KEY 1 12 19980229163147 19980129163147 12345 test. (...)

The final run of DNSSIGNER is:

$ MULTINET DNSSIGNER/ZONE=(IN=ZONE.2,OUT=ZONE.3)/PARENT=IN=PARENT.1

Note: The specification of the key is no longer needed. However, now that the records are signed, DNSSIGNER will verify all the existing signatures.

In the case that a signature fails during these checks, the action taken by DNSSIGNER depends on whether the key of the signature is specified on the DNSSIGNER command line during the run. In the example, failing signatures are just dropped. If the run command included

/SIG=KEY=(DOM=ZZ.TEST.,ALG=DSA,KEY_ID=6750)

then failing signatures would be replaced.

The result of the second run of DNSSIGNER is zone.3, which is the final zone file and would be used by the nameserver. zone.3 is a merger of zone.2 and parent.1, minus the records which appear in both files; that is, duplicates are removed.

Multicast Name Resolution

Multicast name resolution aims to eliminate the need to maintain HOSTS files or configure a name server on networks that are contained within a single logical LAN. Systems participate by sending out a multicast request to resolve a name and any system that recognize the name responds to the request. Systems that participate in multicast name resolution use one of two protocols: LLMNR (RFC 4795), or mDNS. Both protocols use packets that are very similar to standard DNS packets; they operate in different multicast groups and use different port numbers.

MultiNet offers a responder that participates in both protocols and the ability to configure the resolver to use one of the two protocols. Using a multicast group disables one of the resolver's checks for authenticity of the answers that it receives. The multicast name responder works for both IPv4 and IPv6 addresses. Zero configuration of systems is one of the goals for IPv6 on small networks, and multicast name resolution helps in meeting this goal. Configuring MultiNet to use multicast name resolution involves enabling the server (LLMNR) and setting the name server address and port with MULTINET CONFIGURE/NETWORK.

Configuring Multicast Name Resolution

$ multinet configure/server

SERVER-CONFIG>ENABLE LLMNR

SERVER-CONFIG>WRITE

SERVER-CONFIG>EXIT

$ multinet configure/network

NET-CONFIG>set multicast-name-resolution {LLMNR | mDNS}

NET-CONFIG>WRITE

NET-CONFIG>EXIT

LLMNR (port 5355 on 224.0.0.252 and FF02::1:3)

mDNS (port 5353 on 224.0.0.251 and FF02::FB)

$ define/system/exec/nolog multinet_nameservers 224.0.0.252

$ define/system/exec/nolog multinet_dns_port 5355

^{^[1]} The "best value" default is computed from the size of the data as the utility attempts to create 512-byte units. When you run HOST_TABLE COMPILE, the hash value is listed in the displayed messages. If you only added hosts and want to select a number for this qualifier, use the value from the previous compilation as a starting point.