## TCPware V5.7 Management Guide

- Introduction
- Domain Name System (DNS) Concepts
- DNS Client
- Domain Name Server
  - Starting and Stopping
  - The TCPWARE_NAMED_ROOT:NAMED.CONF File
  - Zone
  - Options
    - Address_match_list
  - Logging
  - Caching Data in Memory
- Editing Database Files
  - Special Characters
  - Special Commands
- Resource Records
  - Configuration Requirements
  - Load Balancing Process
  - Cluster Names
    - Straightforward Clusters
    - Overlapping Clusters
    - Subzone Clusters
  - Load Request Protocol

Chapter 3

Domain Name Services

# Introduction

This chapter describes TCPware's Domain Names Services and how it relates to the Domain Name System (DNS). Specific sections describe:

• The different types of DNS servers, the DNS client, and what they do.

• The syntax, special commands, and fields used in each type of database record.

• TCP/IP cluster load balancing.

Domain Name Services allows local hosts to obtain information about other hosts by accessing a distributed DNS database. This database supplies Internet addresses and hostnames throughout the network. Any upper-layer protocol, such as FTP or SMTP, can use DNS when it needs host information.

Domain Name Services also provides the services for cluster load balancing.

# Domain Name System (DNS) Concepts

For a full description of the concepts behind the Domain Name System (DNS) that forms the basis of the Domain Name Services, see DNS Defined: A Practical Guide to TCP/IP Domain Name System and Services. DNS Defined is one of the volumes in Process Software's useful TCP/IP Reference Library.

# DNS Client

A DNS client (also called a resolver) communicates with a DNS server to resolve a host name and internet address. The client does not maintain a database. The client only sends queries and provides the received answers to applications.

You can configure your local host to support a DNS client when you run the TCPware configuration. The host can support a DNS client only, or both a client and name server.

The configuration procedure (CNFNET) prompts you to specify the internet addresses of up to three name servers the client can query. The client reads this information from two logicals you set through CNFNET:

• TCPWARE_ DOMAINNAME

• TCPWARE_ NAMESERVERS

The client also allows you to set up to six domains in a search list, as well as the minimum number of dots to recognize in a host name to make it fully qualified. The client reads this information from two logicals you set through CNFNET:

• TCPWARE_ DOMAINLIST

• TCPWARE_ RES_OPTIONS "ndots: ndots"

The configuration procedure (CNFNET) allows you to specify a resolver timeout setting that the client reads from two logicals you set through CNFNET:

• TCPWARE_RES_RETRANS_MIN (specifies minimum retransmit time value in seconds)

• TCPWARE_RES_RETRIES (specifies retry count)

See the Installation & Configuration Guide, Chapter 4, Configuring the TCP/IP Services, the Configure the DNS Resolver section.

When an application needs to resolve a host name or internet address, the client queries the first name server the TCPWARE_NAMESERVERS logical defines. The client continues to query the other name servers on its list until it receives an answer or the list is exhausted. The amount of time varies for what is needed to send a query and receive a response.

The TCPware resolver queries domain names in the following sequence:

1 The resolver queries the fully qualified domain name if the domain name contains ndots number of dots (see the TCPWARE_RES_OPTIONS logical syntax); the default is 1.

2 If the first step fails or the domain name contains less than ndots, the resolver queries name.default-domain or the list established by the TCPWARE_DOMAINLIST logical.

3 If the second step fails, the resolver queries for name only.

You can restart the resolver process (TCPware_DNS) if it goes down (or the NETCU STOP/DNS command was used) by specifying @TCPWARE:STARTUP_RESOLVER DETACH on the command line.

# Domain Name Server

To set up a domain name server on your local host, perform these steps:

1 Determine whether the names on the local host will be authoritative for a zone or will be just a caching server.

2 Run the CNFNET configuration procedure described in the Installation & Configuration Guide, Chapter 4. When you set up a server and (there is no existing NAMED.CONF file), CNFNET converts the existing TCPWARE_NAMED_ROOT:NAMED.BOOT file to a TCPWARE_NAMED_ROOT:NAMED.CONF file. If there is no NAMED.BOOT file, CNFNET creates a default NAMED.CONF file set up as a caching server.

3 If the host is to be authoritative, add zone statements in the NAMED.CONF file (see Zone) for each zone.

4 Gather the information you need for the database files so that the server can resolve queries. The information is in the Resource Records section of this chapter.

5 Enter the information in the database files using a text editor. (See Editing Database Files.)

## Starting and Stopping

The name server starts up when you execute the STARTNET.COM procedure and shuts down with the SHUTNET.COM procedure.

1 Log in as the system manager.

2 Stop the name server process: $ @TCPWARE:SHUTNET DNS

3 Start the name server process: $ @TCPWARE:STARTNET DNS

When you start the name server, it creates a log file, TCPWARE:NAMESERVER.LOG. This file contains information about any problems uncovered when loading the database or during name server operation.

If the name server is already active and you edited the database files, you can restart the name server or you can reload it using the NETCU RELOAD NAMED command. See Chapter 2 of the Network Control Utility (NETCU) Command Reference.

You can investigate this file after updating the database or if the name server exits immediately after startup. Syntax errors in the database files are the most common source of errors. If there is an error in one of the database files, Domain Name Services records the error type and relevant database file in the log file.

Editing Database Files can help you find the cause of these errors.

## The TCPWARE_NAMED_ROOT:NAMED.CONF File

The main DNS configuration file, from which the name server gets its initial data, is TCPWARE_NAMED_ROOT: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 "TCPWARE_ROOT:[TCPWARE.NAMED]";
// forward only;
forwarders { 128.0.1.1; 128.0.2.10; };
};
zone "flowers.com" in {
type master;
file "domain-name-service.iris";
};
zone "0.128.in-addr.arpa" in {
type master;
file "domain-name-service.iris-net";
};
zone "cc.flowers.com" in {
type slave;
masters { 128.0.1.1; };
file "domain-name-service.cc";
};
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 "." 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 is the following way:

zone "<domain name>" [<class>] {
type <type>;
};

Table 3-1 defines the NAMED.CONF zone fields.

Table 3-1 NAMED.CONF Zone Fields (Continued)

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 hesiodConfined mostly to MIT.hs is the abbreviation for hesiod. • chaosAn historic network. Not used today.
"<domain name>" | The name of the domain for which this zone is authoritative.
file "<filename>"; | Specifies the name of the file.
masters { ip_addr; [ip_addr; ... ]}; | Specifies the IP addresses 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); | See Table3-3 for a description of these zones.

Table 3-2 Optional Zone Statements (Continued)

Statement | Description
allow-query { <address_match_list> };allow-transfer { <address_match_list> }; | Overrides the respective statement in the global options section for this zone. See Table3-5.
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; ... ] }; | Lists the servers to send zone change notifications to as well as to the slave servers specified via the NS records for the zone.
check-names (warn | fail | ignore); | Overrides the default name checking specified in the global options section. See the check-names statement in Table3-4 for more details.
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 Table3-4 for more details.

Table 3-3 Zone Types (Continued)

Type | Description
hint | 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 automatically obtained and stored in memory without replacing the cache file.
master | Specifies data for the zone and the domain. The first master zone definition states that the file DOMAIN-NAME-SERVICE.IRIS contains authoritative data for the FLOWERS.COM zone, in standard resource record format. The second master zone definition states that the file DOMAIN-NAME-SERVICE.IRIS-NET contains authoritative data for the domain 0.128.IN-ARPA.ARPA, which is used in translating addresses in network 128.0.0.0 to host names. Be sure each zone master file begins with an SOA (Start Of Authority) resource record for the zone, as shown in the DNS Zone Information Files 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 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 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 transfers only 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 NAMED. 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>
};

Table 3-4 defines the NAMED.CONF options.

Table 3-4 NAMED.CONF Options (Continued)

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-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.
check-names (master | slave | response) (warn | fail | ignore); | The server checks names in three areas: • Master zone files. • Slave zone files. • Responses 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;}; • ignoreNo checking is done. • warnNames are checked against their expected client contexts. Invalid names are logged, but processing continues normally. • failNames 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.
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 ); | If yes, the server responds to the obsolete IQUERY query type. The default is no.
fetch-glue ( yes | no ); | If yes (default), the server queries for the resource records it needs to complete the additional section of a response. To prevent the server’s cache from growing, use fetch-glue no; in combination with recursion no;.
forward ( only | first ); | This statement is meaningful only if there is a 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. 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 }; | See the Address_match_list section. Specifies what port on what interface to listen on. The default is: listen-on port 53 { any }; Example: options { // listen on port 53 for // external interfaces. listen-on { 192.168.1.0;}; // listen on port 43 for // internal interfaces. listen-on port 43 { 127.0.0.1; 10.0.0.0; };};
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).
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. The server determines the slave servers by the nameserver records contained in the zones data file. For more information, see the also-notify statement in Table3-4.
recursion ( yes | no ); | If yes (default), the server attempts to do all the work required to answer a query that has requested recursion. Turning this off results in the server responding to the client with referrals. To prevent the server’s cache from growing, use recursion no; in combination with fetch-glue no;.
topology { address_match_list; } | Specifies the servers network topology in order to determine what server to query when recursively following a referral. Each element is given a rating based on the position in the list, based on descending preference. Addresses that match up with listed networks are queried first, followed by addresses that match up with unlisted networks, followed by addresses that match up with negated networks. Example: topology { !10.10/16; 10/8; 127.0.0/24; }; Addresses in 10.*.*.* will be preferred most of all, with the exception of 10.10.*.* addresses. Addresses in the 127.0.0.* will be preferred next. All other addresses will be preferred over any 10.10.*.* addresses.
transfer-format <number> | The server supports two 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. many-answers is more efficient, but is only known to be understood by BIND 8.1 and patched versions of BIND 4.9.5. The default is one-answer. transfer-format may be overridden on a per-server basis by using the server statement.
transfers-in <number> | The maximum number of inbound zone transfers that can be running concurrently. The default value is 10. Increasing transfers-in may speed up the convergence of slave zones, but it also may increase the load on the local system.
transfers-per-ns <number> | The maximum number of inbound zone transfers (named-xfer processes) that can be concurrently transferred from a given remote nameserver. The default value is 2. Increasing transfers-per-ns may speed up the convergence of slave zones, but it also may increase the load on the remote nameserver. transfers-per-ns may be overridden on a per-server basis by using the transfers phrase of the server statement.

### Address_match_list

The following can be address match lists:

• an IP address (in dotted-decimal notation)

• an IP address match list

• an IP prefix (in /- notation)

• an address match list defined with the acl statement

The following ACLs are predefined:

any | none | localhost | localnets

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

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. You can use the listen-on clause to define local addresses not normally used to accept nameserver connections.
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. | A negated match 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 <pathname>;
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:

channel xfers {
file "TCPWARE:XFERS.LOG";
severity info;
print-severity yes;
print-time yes;
};
category xfer-in {
xfers;
};

Table 3-5 describes the logging options.

Table 3-5 Logging Options (Continued)

Options | Description
channel | Specifies where the logging data goes: to syslog, to a file, to stderr, or to null.
category | Specifies what data is logged. You can send a category to one channel or to many channels. These are the valid categories: default update notify panic packetconfig ncache cname load maintenanceparser xfer-in security eventlib statisticsqueries xfer-out os insist dblame-servers
file | Specifies the path name of the file you want the message to go to.
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-categoryprint-severityprint-time | Specifies the category, severity level, and time stamp of the messages. The default is NO for each item.

## Caching Data in Memory

The TCPware_NAMED process caches a certain amount of DNS data in memory. By default, it limits the maximum time-to-live (TTL) on a resource record placed in memory cache to one week. If the TTL is set to more than a week, it only caches it for a week. This value may be too high for some systems with heavily used name servers and limited memory.

When NAMED starts up, it checks the SYSTEM EXECUTIVE logical table for the TCPWARE_NAMED_MAX_CACHE_TTL logical value and sets the maximum cache time (in seconds) to be that value. You can use this logical to override the default one week (604800 seconds) to a maximum cache time more appropriate for your system. For example:

$ DEFINE/SYSTEM/EXEC TCPWARE_NAMED_MAX_CACHE_TTL 86400

This logical is read the next time the server starts. If you do not want to wait for the server to start, you can make the change to the running server by using the NETCU SET NAMED MAX_TTL <ttl> command. See Chapter 2 of the Network Control Utility (NETCU) Command Reference. Any data now written to the cache remains there for 86400 seconds (one day).

# Editing Database Files

The CNFNET configuration procedure creates templates of the database files. Some of the templates are only examples of the database records necessary for configuration. You must enter information specific to your configuration for the server to function properly. The type of server you configure determines which database file you need to edit.

Note! If you edit the database files, stop and restart the Domain Name Services software so that the name server can update its database. See Starting and Stopping.

## Special Characters

The characters listed in Table 3-6 have special uses in the database files.

Table 3-6 Special Characters

The character... | Is used...
char | To quote a single character, char, that otherwise has special meaning. For example, use to place a dollar sign in the text.
( ) | To group data that exceeds a line boundary. The SOA record requires parentheses. See the Start of Authority (SOA) resource record.
; | To start a comment. TCPware ignores the remaining characters in the line.
* | As a wildcard. For example, the domain name *.FLOWER.COM refers to any host within the FLOWER.COM domain.

Use a period (.) to end a domain name. If the domain name does not end with a period, Domain Name Services appends the current domain name to it. The NAMED.CONF file defines the current domain name, or you can use the $origin command to redefine it.

## Special Commands

You can use two special commands in database files:

• $origin

• $include

These commands are described on the following pages.

$origin

Indicates that all the records following the command belong to a different domain than the previous records. The name server has authority over all records listed. This command gives you a shorthand way of expressing the domain name of the host.

Format

$origin domain-name

Parameter

domain-name

Domain name to which the records belong.

Example

This example defines the DAISY.FLOWER.COM, IRIS.FLOWER.COM, SPARROW.BIRD.COM, DOVE.BIRD.COM, MAPLE.TREE.COM, and ACORN.TREE.COM domains.

;the default domain is flower.com.
daisy in a 192.168.62.1
iris in a 192.168.62.2
$origin bird.com.
sparrow in a 192.168.95.1
dove in a 192.168.95.3
$origin tree.com.
maple in a 192.168.74.1
acorn in a 192.168.74.2

$include

Includes an external file in a DNS database file. Useful for organizing different types of information into separate files.

Format

$include file [origin]

Parameter

file

File you want to include in the database.

origin

(Optional) Origin of the include file (see the $origin command on the previous page).

Examples

1 This command includes the file TCPWARE:MAILLIST.TXT in the database file.

$ include tcpware_named_root:maillist.txt

2 These commands include the file TCPWARE:BIRD.TXT in a series of definitions, using the BIRD.COM domain as origin (see the $origin command) for the include file.

$ origin flower.com.
daisy
iris
$ include tcpware_named_root:bird.txt bird.com.
rose

If the BIRD.TXT file includes records for SPARROW and DOVE, the extended version of the above definition would be:

daisy.flower.com
iris.flower.com
sparrow.bird.com
dove.bird.com
rose.flower.com

Note that the include file origin definition is for the include file only and does not affect the "external" origin.

# Resource Records

All database files contain entries called resource records. TCPware for OpenVMS supports the resource record types listed in Table 3-5 under the type record field.

This section provides the following information for each DNS resource record:

• Purpose

• Format

• Field definitions

• Example of usage

The fields that are common to most resource records are: owner, ttl, class, and type. The remaining data fields are different for each record type. This section documents these data fields under the appropriate record type.

All resource records are case insensitive. However, TCPware preserves the case you enter.

Format

owner ttl class type data

Fields

owner

Domain name of the owner of the record.

The domain name can be absolute or relative. An absolute domain name lists all the labels of the name and ends with a period. For example, DAISY.FLOWER.COM. is an absolute domain name. A relative domain name does not end with a period. DNS assumes it belongs to the current domain. For example, DAISY is a relative domain name in the FLOWER.COM domain.

Acceptable characters are A through Z (upper or lower case), 0 through 9, and dash (-). The period (.) is a label separator.

The values listed in Table 3-7 have special meaning in the name field.

Table 3-7 Special Values for name

Value | Description
(all blank) | The resource record applies to the last explicitly stated domain name
. | Indicates the root (or top level) domain
@ | Indicates this is the current domain name

ttl

Time-to-live (TTL).

This is the length of time (in seconds) the record is valid after a requestor host receives it from a primary server. For example, a TTL of 86400 equals 24 hours.

You can specify in the time-to-live field in the following ways:

Note! 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)

If you leave this field blank, DNS uses the TTL designated in the SOA (start of authority) record minimum field. The minimum field value is the "default" TTL.

All resource records that have the same values in the name, class, and type fields should also have the same value in the ttl field.

class

Address class (should be IN for "internet").

type

Resource record type, as listed in Table 3-8 and described more fully on the following pages.

Table 3-8 Resource Record Types

Type | Description | Type | Description
A | Address | MX | Mail exchanger
ASFDB | AFS database | NS | Name server
CNAME | Canonical name | PTR | Pointer
HINFO | Host information | RP | Responsible person
ISDN | ISDN information | RT | Route through binding
MB | Mailbox | SOA | Start of authority
MG | Mail group | TXT | Descriptive text
MINFO | Mail information | WKS | Well known services
MR | Mailbox rename | X25 | X.25 information

data

Data specific to each entry.

This field varies with each type of resource record.

A

Address record, or internet address of a host. The name server uses this record when it responds to a query for an internet address.

Use this record in any of the database files.

Format

owner ttl class A address

Fields

A

The type, which must be A.

address

Internet address of the host specified in the name field.

Example

This example includes two A records for local hosts DAISY and LILAC.

;name ttl class type address
daisy IN A 192.168.95.3
lilac 99999999 IN A 192.168.95.4

AFSDB

AFS Database (AFSDB) record. The AFSDB record was added as of RFC 1183 for experimental purposes. AFS (which stands for the Andrew File System designed at Carnegie-Mellon University in Pennsylvania) is a network file system like the Network File System (NFS). The AFS database (AFSDB) is an authenticated name server for AFS filesystems.

The AFSDB record finds the location of the AFS name server.

Use this record in any of the database files.

Format

owner ttl class AFSDB subtype host

Fields

AFSDB

The type, which must be AFSDB.

subtype

Either 1, for an AFS cell database server, or 2, for a DCE-authenticated name server.

host

Domain name that specifies a host that has a server for the cell named by the resource record's owner.

Example

This example is an AFSDB record for host DAISY.

;owner ttl class type subtype host
daisy IN AFSDB 1 daisy.flower.com.

CNAME

Canonical Name (CNAME) record, or official name of the host. You can include a nickname, or if you rename the host, use the nickname field to give the old domain name.

Note! Do not use the nickname in any other resource records.

Format

nickname ttl class CNAME canonical-name

Fields

nickname

Nickname or alias for the host. If you rename the host, this is the old domain name.

CNAME

The type, which must be CNAME.

canonical-name

Official domain name for the host. This can be an absolute or relative name. If you rename the host, this is the new domain name.

Example

This example includes two CNAME records. These records define SPRING as a nickname for host LILAC.FLOWER.COM and SUMMER as a nickname for host DAISY.FLOWER.COM. Because no period (.) follows the nicknames, DNS assumes they are in the current domain.

;nickname ttl class type canonical-name
spring IN CNAME lilac.flower.com.
summer IN CNAME daisy.flower.com.

HINFO

Host Information (HINFO) record, or hardware type and operating system of a host. DNS uses this information to answer queries.

Each host in a domain can have just one HINFO record.

Format

owner ttl class HINFO hardware opsys

The hardware and opsys fields require a space between them. If you need to use a space within either field, enclose the field within quotation marks (" ").

Fields

HINFO

The type, which must be HINFO.

hardware

Type of CPU. See the latest Assigned Numbers RFC for a list of standard hardware types.

opsys

Host operating system.

Example

This example includes two records for hosts IRIS and LILAC in the current domain, and gives their hardware type and operating system. Some field entries include quotation marks because they contains space characters.

;owner ttl class type hardware opsys
iris IN HINFO "AlphaStation 8400" VMS
lilac IN HINFO "VAXStation 4000" "VMS V7.0"

ISDN

Integrated Service Digital Network (ISDN) record, or telephone number of a host.

Format

owner ttl class ISDN ISDN-address [sa]

Fields

ISDN

The type, which must be ISDN.

ISDN-address

Decimal ISDN number and direct dial-in (DDI), if necessary, of the owner field.

sa

Optional sub-address in hex digits.

Example

This example gives the ISDN addresses for the specified hosts.

;owner ttl class type ISDN-address sa
Relay.Prime.COM. IN ISDN 150862028003217
sh.Prime.COM. IN ISDN 150862028003217 04

MB

Mailbox (MB) record, or Internet mailbox that is the subdomain of a domain. This record is usually no longer used.

Format

owner ttl class MB mailbox

Fields

MB

The type, which must be MB.

mailbox

Subdomain name of the host with the specified mailbox.

Example

This example gives the mailbox record for host TULIP.

;owner ttl class type mailbox
tulip IN MB mailbox.tulip.flower.com.

MG

Mailbox Group (MG) record, or Internet mailbox group (mailing list) that is the subdomain of a domain. This record is usually no longer used.

Format

owner ttl class MG mail-group

Fields

MG

The type, which must be MG.

mail-group

Subdomain name of the mailbox belonging to the mail group specified by the domain name.

Example

This example gives the mailbox group record for host TULIP.

;owner ttl class type mail-group
tulip IN MG mailbox.tulip.flower.com.

MINFO

Mail Information (MINFO) record, or Internet mailbox that is responsible for the mailbox or mailing list or that receives error messages related to the mailbox or mailing list.

Format

owner ttl class MINFO resp-mbox error-mbox

Fields

MINFO

The type, which must be MINFO.

resp-mbox

Domain name mailbox responsible for the mailbox or mailing list.

error-mbox

Domain name mailbox that receives error messages for the mailbox or mailing list specified by the owner of the MINFO record.

Example

This example gives the mail information record for host TULIP.

;owner ttl class type responsible errors
tulip IN MINFO mailer.tulip.flower.com. err.tulip.flower.com.

MR

Mailbox Rename (MR) record that renames an internet mailbox that is the subdomain of a domain. This record is usually no longer used.

Format

owner ttl class MR new-mailbox

Fields

MR

The type, which must be MR.

new-mailbox

New name of the domain name of the host with the specified mailbox.

Example

This example gives the mailbox rename record for host TULIP.

;owner ttl class type mailbox
tulip IN MR newbox.tulip.flower.com.

MX

Mail Exchanger (MX) record, or a host that can accept mail for another host. A host can have multiple MX records. Each record receives a preference value.

When a mailer tries to deliver mail to a host:

1 It reads all MX records defined for the destination host and sorts them by preference value.

2 It tries to deliver the mail to the host specified on the record with the highest preference. The record with the lowest value (beginning at 0) has the highest preference.

3 If the first attempt fails, it tries the host specified on the record with the next highest preference value.

4 It keeps trying until it delivers the mail, or until it tries the host specified on the record with the lowest preference.

If you assign the same preference value to multiple MX records for a host, the mailer tries the equally-preferenced records in random order.

See Chapter 17 , Managing Mail Services, the Completing SMTP/MR Configuration section for MX records used with the SMTP mail facility.

Format

system ttl class MX preference gateway

Fields

system

Domain name of the host the gateway host accepts. The host might not be connected directly to the network. Using wildcards in domain names is strongly discouraged if the hosts are Internet-connected (see section 2.7 of RFC 1912 for details).

MX

The type, which must be MX.

preference

Delivery order when a host has multiple MX records. The lower the number (starting at 0), the higher the preference.

gateway

Name of the host accepting mail for the host specified in the system field.

Example

This example gives three MX records for host TULIP (in the current domain). The mailer tries to deliver the mail to host TULIP.FLOWER.COM first, because that record has the lowest preference-value. If the attempt fails, it tries host IRIS.FLOWER.COM and then LILAC.FLOWER.COM.

;system ttl class type preference gateway
tulip IN MX 10 tulip.flower.com.
tulip IN MX 15 iris.flower.com.
tulip IN MX 20 lilac.flower.com.

NS

Name Server (NS) record that lists the domain name of a host that provides domain name services, and the name of the domain being served. Therefore, the specified host is an authoritative name server for the specified domain.

You can enter NS records in any database file.

Format

owner ttl class NS server

Fields

NS

The type, which must be NS.

server

Domain name of the host that serves the domain.

Example

This example gives the syntax of three NS records. DAISY.FLOWER.COM and IRIS.FLOWER.COM are both servers for the FLOWER.COM domain. The owner field is blank for IRIS.FLOWER.COM, indicating it serves the domain specified in the previous record. The owner field for NS.NASA.GOV server contains only a dot (.), indicating NS.NASA.GOV is a root server. IRIS.FLOWER.COM takes its time-to-live (TTL) value from the min field of the SOA record. The TTL for NS.NASA.GOV is 99999999 seconds (approximately three years).

;owner ttl class type server
flower.com. IN NS daisy.flower.com.
IN NS iris.flower.com.
. 99999999 IN NS ns.nasa.gov.

PTR

Domain Name Pointer (PTR) record that allows special names to point to another location in the domain. The most common use of PTR records is for reverse mapping: Domain Name Services finds a host domain name when given an internet address. The IN-ADDR.ARPA domain maintains reverse mapping information.

PTR records in the IN-ADDR.ARPA domain contain a host name that consists of the internet address specified in reverse order, combined with the IN-ADDR.ARPA domain name. This name points to the domain name of the host with that internet address.

Enter PTR records in the NAMED.REV, NAMED.HOSTS, or NAMED.LOCAL files.

Format

rev-addr ttl class PTR realname

Fields

rev-addr

Combination reverse internet address and domain name IN-ADDR.ARPA. Each rev-addr should be unique to the zone.

PTR

The type, which must be PTR.

realname

Full domain name of the host. If the host is not in the current domain, this name must end in a period (.). Do not use a nickname.

Example

This example gives PTR records for two hosts. The internet addresses are in the current domain, 95.168.192.IN-ADDR.ARPA.

;rev-addr ttl class type realname
$origin 95.168.192.in-addr.arpa
2 IN PTR daisy.flower.com.
4 IN PTR lilac.flower.com.

RP

Responsible Person (RP) record for the name of the person responsible for a host or domain. You can specify multiple responsible persons for a domain name, but make sure that the ttl for the records are the same.

Format

owner ttl class RP mailbox txt-domain

Fields

RP

The type, which must be RP.

mailbox

Domain name of the mailbox for the responsible person.

txt-domain

Domain name where TXT records exist.

Example

This example gives RP records for two hosts.

;owner ttl class type mailbox txt-domain
flower 6666 IN RP honcho.flower.com. daisy.flower.com.
6666 RP kahuna.flower.com. iris.flower.com.

RT

Route Through (RT) record that provides a route-through binding for hosts that do not have a direct WAN address. Use this record in much the same way as the MX resource record.

Format

owner ttl class RT preference interm-host

Fields

RT

The type, which must be RT.

preference

Preference of the route, in a 16-bit integer. The smaller the number, the more preferred the route.

interm-host

Name of the intermediate host domain that serves as an intermediary in reaching the host specified by owner. The DNS resource records associated with interm-host must include at least one A, X25, or ISDN record.

Example

This example shows the route-through for two hosts. When a host looks up DNS records to try to route a datagram, it first looks for RT records for the destination host, which point to hosts with address records (A, X25, or ISDN) compatible with the WAN available to the host. If the host itself is in the set of RT records, it discards any RTs with preferences higher or equal to its own. If there are no remaining RTs, it can use address records of the destination itself.

;owner ttl class type preference interm-host
iris IN RT 2 marigold.flower.com.
daisy IN RT 10 pansy.flower.com.

SOA

Start of Authority (SOA) record that defines the start of a zone. There is one SOA record for each zone and it is on the primary server. If other servers in the zone have SOA records, these records must be identical to the one on the primary server. The SOA record is the first one listed in a database file.

You can enter this record in any database file. The NAMED.CA file can store an SOA record, but the record does not define the server as authoritative.

Format

owner ttl class SOA origin person ( serial refresh retry expire minimum )

The parentheses are required if continuing onto one or more subsequent lines. At least one space must separate the parentheses from the text within it.

Fields

SOA

The type, which must be SOA.

origin

Name of the host on which the primary server resides.

If the local host is not the primary server, the local host periodically obtains database information from the specified host. See the refresh, retry, and expire fields.

person

Mailbox address of the person responsible for the DNS software on the local domain. Replace the @ sign in the mailbox address with a period (.); for example: gardener@iris.flower.com becomes gardener.iris.flower.com..

serial

Version number of the database file. A 32-bit unsigned integer that can theoretically start at 0.

Increment this field by a certain interval each time you edit a database file (using the YYYYMMDDVV date syntax provides a "safe" interval). If serial on the primary server is "higher" (based on serial number arithmetic) than serial on the secondary server, the secondary server knows that the primary server contains new data and it performs a zone transfer to update its database. The serial number also tells the DNS software which of two file copies is the most recent.

refresh

Time interval (in seconds) after which the secondary server must request the SOA record from the primary server. A 32-bit unsigned integer, measured in seconds. For example, a refresh value of 86400 equals 24 hours. A value of 900 seconds (15 minutes) is the minimum value allowed.

retry

Time interval (in seconds) after which the secondary server should re-request the SOA record from the primary server after a refresh failure. A 32-bit unsigned integer, measured in seconds. 600 seconds (10 minutes) is a reasonable value.

expire

How long the secondary server can use its copy of the database file when it cannot obtain a refresh. A 32-bit unsigned integer, measured in seconds. A typical value is 3600000 seconds (approximately 41 days and 16 hours).

minimum

Minimum time to live (TTL) value, in seconds, for the records in the zone. DNS uses this value if you do not specify the ttl field for other resource records. A reasonable value is 86400 seconds (24 hours).

Example

This example shows a typical SOA record format. The values are described in the table.

;owner ttl class type origin person
@ IN SOA iris.flower.com. gardener.iris.flower.com.(
1 ; serial
3600 ; refresh (1 hour)
600 ; retry (10 minutes)
3600000 ; expire (1000 hours)
86400 ) ; minimum (24 hours)

Value | Description
@ | Current domain name
iris.flower.com. | Primary server host name
gardener.iris.flower.com. | "Owner" of the DNS software on the local domain (the mailbox address gardener@iris.flower.com becomes gardener.iris.flower.com.)
1 | Serial (version) number of the database file
3600 | Refresh time the secondary server requests an SOA record from the primary server every 3600 seconds (1 hour)
600 | Retry time the secondary server retries requests for the SOA record from the primary server every 600 seconds (10 minutes) if a refresh fails
3600000 | Expiration time the secondary server can use its copy of the database if all refreshes fail for a total of 360000 seconds (1,000 hours, or 41 days and 16 hours)
86400 | Minimum time-to-live of 86400 seconds (24 hours) for records in the zone

The parentheses at the end of the second line indicate that one or more additional lines related to the record follow. The lines usually include the serial, refresh, retry, expire, and minimum field values and their commented out (;) descriptions. You must include a space between the parentheses and the text it encloses (such as by indenting the next line). You must also include a white between the last value (86400 in the example) and the closing parentheses.

TXT

Text (TXT) record. Holds descriptive text. The semantics of the text depend on the domain.

Format

owner ttl class TXT txt-data

Fields

TXT

The type, which must be TXT.

txt-data

One or more character strings of descriptive text.

WKS

Well Known Service (WKS) record. Lists the well known services a specified host provides on port numbers below 256. DNS uses this information to answer queries.

Enter WKS records in the NAMED.HOSTS file.

Format

owner ttl class WKS address protocol services

Fields

WKS

The type, which must be WKS.

address

IP address of the host. Define one WKS record for each protocol at each internet address.

protocol

Name of the generic protocol that supports the well known services. Must be UDP or TCP.

services

Well known services the protocol provides, such as FTP, TELNET, SMTP, or SUNRPC.

Example

This example gives protocol information for hosts IRIS and DAISY in the current domain.

;owner ttl class type address protocol services
iris IN WKS 192.168.95.1 tcp ftp telnet smtp
daisy IN WKS 192.168.95.3 udp sunrpc

X25

X.25 address of a host.

Format

owner ttl class X25 PSDN-address

Fields

X25

The type, which must be X25.

PSDN-address

Public Switched Data Network (PSDN) address (in decimal digits) in the X.121 numbering plan associated with the owner field. The string of digits begins with a four-digit Data Network Identification Code (DNIC). Do not use national prefixes in the address.

Example

This example gives the PSDN address of the specified host.

;owner ttl class type PSDN-address
lily.flower.com. IN X25 311061700956

Troubleshooting Domain Name Services

Access error messages help by entering HELP TCPWARE MESSAGES [identifier], or connect to web site http://www.process.com (select Customer Support followed by the Error Messages button).

When you start the name server, it creates a log file, TCPWARE:NAMESERVER.LOG . This file contains information about any problems uncovered when loading the database or during name server operation. TCPware sends system logging errors to this file. By default, TCPware logs all errors except Debug messages to the log file.

Dynamic TCP/IP Load Balancing

TCPware provides TCP/IP load balancing services for a TCP/IP cluster that are analogous to the load balancing services the LAT terminal service provides.

When a new TCP connection to a cluster name occurs, the TCPware Domain Name Services name server assigns the connection to one of a number of hosts. The host to which it assigns the connection depends on:

• The availability of the host.

• The observed load on the host.

TELNET most often uses TCP/IP cluster load balancing, although other TCP protocols do also. UDP-based protocols also work well with cluster load balancing, but only if:

• The server (such as DNS) does not retain state information.

• The client (such as TFTP) resolves the domain name only once at the start of a connection.

TCP/IP load balancing does NOT:

• Provide effective NFS server failover. Most clients do not resolve names again and remount filesystems when an NFS server fails to respond.

• Provide local preference to clients' selection of hosts.

• Actively re-balance the load: a failed and recovered host receives only new connections.

• Support non-TCPware hosts as part of the cluster.

In addition, the default metric is not very useful for RPC type services. It is oriented toward measurement of users.

## Configuration Requirements

All hosts in the TCP/IP cluster must run TCPware. Also, all DNS servers for the zone defined with the TCP/IP cluster name must be on systems running TCPware. Client systems do not have to run a particular TCP/IP implementation.

The term cluster here means a TCP/IP cluster. Hosts in a TCP/IP cluster do not have to be part of a VMScluster. They even do not have to be on the same bridged LAN.

In a TCP/IP cluster, the hosts can be at least one of the following:

• Independent systems with TCP/IP connectivity

• Located anywhere so long as there is TCP/IP connectivity

• Part of several VMSclusters with TCP/IP connectivity

You can define multiple cluster names describing subsets, or overlapping or separate clusters.

## Load Balancing Process

When a client wants to connect to a host within the cluster:

1 It sends the DNS server a name-to-address translation request for a host to which it wants to connect.

2 The DNS server looks in a cache that holds recent load information for the hosts in the cluster. If the name is a cluster name, a routine sorts the addresses by reported load. The server determines the load by exchanging UDP datagrams with each host in the cluster, which report their current load metrics. The server treats hosts that fail to respond as unavailable and does not offer them any new traffic. Specifically:

a The DNS server searches its resource record for host addresses and looks up each host in a private list of hosts. Different cluster names share this list. If a host appears in more than one cluster, the server requests its load metrics only once.

b The DNS server sends update requests to the hosts if there is no information or if there is outdated information in the cache.

c If a host fails to respond to the load information requests, it does not return its address to the server. In this case, the host could actually be down.

Alternatively, the host also could have been administratively shut down by removing the UDP service that responds to load requests. Removing this UDP service effectively removes the host from the cluster.

d TCPware moves the address record corresponding to the host with the lowest load metric to the front of the DNS information list.

3 The server responds to the client with a list of addresses in preferred order of use. Most clients use the first address, or if it fails, second or subsequent addresses.

4 When DNS returns its reply to the client, it:

• Rotates the first address down the list among hosts with similar load metrics. This means that DNS "round-robins" calls among similarly loaded hosts.

• Sets the time to live (TTL) to a fairly small value. This forces a new request for subsequent connections.

## Cluster Names

In DNS, you define each cluster name as an ordinary host name with an IP address and resource records for each host address used. There are straightforward, overlapping, and subzone clusters.

### Straightforward Clusters

Example 3-1 shows a cluster name defined as a DNS address (A) resource record as part of a zone file. The cluster is called perennials and is assigned IP address 192.168.3.50.

Example 3-1 Cluster Name in the Zone File

@ IN SOA rose.nene.com. system.rose.nene.com. (
1 ; Serial
3600 ; Refresh
600 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS rose.nene.com.
rose IN A 192.168.3.50
lilac IN A 192.168.3.51
petunia IN A 192.168.3.52
hydrangea IN A 192.168.3.53
perennials IN A 192.168.3.50
IN A 192.168.3.51
IN A 192.168.3.52
IN A 192.168.3.53

As the DNS server consults its cache, it matches the cluster name against a list. If the name is in the list, TCPware sorts the addresses in the list by reported load.

After setting up the cluster name in the zone file, make sure the cluster name is know to DNS by reconfiguring DNS using CNFNET. During the configuration of DNS, you are asked if you would like to configure a list of cluster names. Refer to the Installation and Configuration Guide, Example 4-10.

### Overlapping Clusters

Example 3-2 shows two clusters defined in a zone file. Note that the 192.168.100.2 address is common to both clusters.

Example 3-2 Overlapping Clusters in the Zone File

$ORIGIN nene.com
orders IN A 192.168.100.1
IN A 192.168.100.2
invoices IN A 192.168.100.2
IN A 192.168.100.4

### Subzone Clusters

In some cases, you may want to load balance your cluster using an external name server instead of a local one. Since the external server cannot actually configure an internal load balanced cluster, the primary server must delegate authority on a subdomain to the internal server. The internal server then becomes primary for the subzone, which becomes the actual address of the cluster.

The following set of examples show three systems in a cluster: 10.0.0.1, 10.0.0.2 and 10.0.0.3. The domain is flower.com. The first step is to set up a subdomain on the primary server by editing the zone file for the flower.com domain and adding the line to delegate the authority to the internal server, homerdns.flower.com (see Example 3-3).

Example 3-3 Delegating Authority to a Subzone for a Cluster

homer IN NS homerdns.flower.com.

The next step is to set up homerdns.flower.com as a primary name server for domain homer.flower.com.

The zonefile for homer.flower.com on homerdns.flower.com should include the lines in Example 3-4.

Example 3-4 NAMED.CLUSTER File

cluster IN A 10.0.0.1
IN A 10.0.0.2
IN A 10.0.0.3

There is now a load balanced cluster set up to be cluster.homer.flower.com that is accessible from both the primary server (by delegation) and the internal server.

Finally, map cluster.flower.com to the load balanced cluster. Add the following line to the NAMED.HOSTS equivalent file on the primary server:

cluster IN CNAME cluster.homer.flower.com.

The primary server now serves out the addresses in Example 3-4 in load balanced order.

## Load Request Protocol

When the DNS server finds that its load information for a host is out of date, it sends a UDP datagram to the host asking for load updates.

Each UDP request starts a timed sequence in the host. This causes the host to send updates to the DNS server at specified intervals over a set period of time. When the sequence ends, the DNS server considers the information stale and sends a new request. This procedure:

• Minimizes traffic when the DNS server is heavily loaded (for example, handling more than 100 requests per second from clients).

• Is quiet when there are no requests.

The procedure does not require hosts to maintain more than a transient state on the DNS servers, since if they fail, they simply cease to respond.

If a host is part of multiple clusters, the DNS server makes the load request once and not for each separate cluster.

The host normally provides the load reply service from within NETCP. However, you can do this through a configured UDP service using the definition:

NETCU> ADD SERVICE METRIC UDP /ROUTINE=REPORT_TCLB_METRIC

LAT looks at the number of processes in COM state and uses that information to calculate its metric. LAT determines the TCP/IP cluster load balancing metric from the number of active users on the system.

Part of the metric consists of a value that is set for each host. You set this value by defining the system logical TCPWARE_ TCLB_BIAS with a multiplier and an addend as two values of the logical. Both are real numbers. TCPware uses the values in computing the reported load.

You can also use these values to bias a load offered to the host. For example, the following command doubles the observed load and adds 1.5 users:

$ DEFINE/SYSTEM TCPWARE_TCLB_BIAS "2.0","1.5"

A cluster might consist of four hosts with one running other tasks. This host should not receive its full share. You can set the values to cause that host to report a higher load.

TCPware re-translates the TCPWARE_TCLB_BIAS logical before it sends each response. This means that some other process can change it dynamically or you can set it statically.

SET LOGIN/INTERACTIVE=0 forces TCPware Cluster Load Balancing to report the node as an extremely high load (2147483647).