Chapter 3
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.
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.
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:
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_ 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.
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.)
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 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.
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)
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)
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.
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)
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).
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.
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.
You can use two special commands in database files:
• $origin
• $include
These commands are described on the following pages.
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
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.
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.
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
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.
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.
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"
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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).
