This chapter describes TCPware's Domain Name 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:
· 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.
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 "example.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.example.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;
};
The below table defines the NAMED.CONF zone fields.
|
Field |
Description |
|
class |
The class to
which this zone applies. If the class is not specified, the type IN is used by default. The syntax is
· in (default) - Used for objects connected to the Internet. This is the only supported type. ·
hs or Hesiod
- Confined mostly to MIT. |
|
“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 the zone types table below for a description of these zones. |
Optional Zone Statements
|
Statement |
Description |
|
allow-query {address_match_list}; |
Overrides the respective statement in the global options section for this zone. See Logging Options. |
|
allow-update {address_match_list}; |
Specifies the addresses of hosts that are allowed to modify the zone with dynamic updates. Defaults to none. |
|
also-notify {ip_addr; [ip_addr; ...]}; |
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 NAMED.CONF Options 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 NAMED.CONF Options for more details. |
Zone Types
|
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 EXAMPLE.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.EXAMPLE.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. |
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
};
The below table defines the NAMED.CONF options.
|
Option |
Description |
|
allow-query {address_match_list}; |
See the Address_match_list section.
Specifies the addresses of hosts that are allowed to query the server for information. It defaults to all. |
|
allow-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) |
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 {
· ignore - No checking is done. · warn - Names are checked against their expected client contexts. Invalid names are logged, but processing continues normally. · fail - Names are checked against their expected client contexts. Invalid names are logged, and the offending data is rejected.
If check-names response fail has been specified, and answering the client’s question requires sending an invalid name to the client, the server sends a REFUSED response code to the client. |
|
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. |
|
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 { {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] |
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 { |
|
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 NAMED.CONF Options . |
|
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;. |
|
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. |
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.
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; };
};
The following is an example:
channel xfers {
file “TCPWARE:XFERS.LOG”;
severity info;
print-severity yes;
print-time yes;
};
category xfer-in {
xfers;
};
The below table describes the logging options.
|
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 general client
config database |
|
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-category |
Specifies the
category, severity level, and time stamp of the messages. |
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, restart the DNS software so that the name server can update its database.
|
The characters listed in the below table have special uses in the database files.
|
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 *.EXAMPLE.COM refers to any host within the EXAMPLE.COM domain. |
Use a period (.) to end a domain name. If the domain name does not end with a period, DNS 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.
$origin domain-name
domain-name
Domain name to which the records belong.
This example defines the DAISY.EXAMPLE.COM, IRIS.EXAMPLE.COM, SPARROW.EXAMPLE.ORG, DOVE.EXAMPLE.ORG, MAPLE.EXAMPLE.EDU, and ACORN.EXAMPLE.EDU domains.
;the default domain is example.com.
daisy in a 192.168.62.1
iris in a 192.168.62.2
$origin example.org.
sparrow in a 192.168.95.1
dove in a 192.168.95.3
$origin example.edu.
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.
$include file [origin]
file
File you want to include in the database.
origin
(Optional) Origin of the include file (see the $origin command on the previous page).
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:EXAMPLE.ORG in a series of definitions, using the EXAMPLE.ORG domain as origin (see the $origin command) for the include file.
$ origin example.com.
daisy
iris
$ include
tcpware_named_root:example.org example.org.
rose
If the EXAMPLE.ORG file includes records for SPARROW and DOVE, the extended version of the above definition would be:
daisy.example.com
iris.example.com
sparrow.example.org
dove.example.org
rose.example.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 (RRs). TCPware supports all of the resource record types supported by BIND. Some of the more commonly used resource records are detailed below.
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.
owner ttl class type data
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.EXAMPLE.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 EXAMPLE.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 below have special meaning in the name field.
|
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 (each of these is equivalent to one week):
· 604800
· 1w
· 7d
· 168h
· 10080m
· or any combination
For example:
sigma 2h46m40s IN A 10.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 (it should be IN for "internet").
type
Resource record type. Some of the most commonly used ones are listed below and described more fully on the following pages.
|
Type |
Description |
Type |
Description |
|
A |
IPv4 Address |
MX |
Mail exchange |
|
AAAA |
IPv6 Address |
NS |
Name server |
|
CNAME |
Canonical name |
PTR |
Pointer |
|
DHCID |
DHCP client ID |
SOA |
Start of authority |
|
DNSKEY |
DNSSEC key |
SPF |
SPF information |
|
HINFO |
Host information |
TSIG |
Transaction Signature |
|
IPSECKEY |
IPsec key |
TXT |
Descriptive text |
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.
owner ttl class A address
A
The type, which must be A.
address
Internet address of the host specified in the name field.
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
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.
nickname ttl class CNAME canonical-name
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.
This example includes two CNAME records. These records define SPRING as a nickname for host LILAC.EXAMPLE.COM and SUMMER as a nickname for host DAISY.EXAMPLE.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.example.com.
summer IN CNAME daisy.example.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.
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 (" ").
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.
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 contain space characters.
;owner ttl class type
hardware opsys
iris IN HINFO "AlphaStation 8400" VMS
lilac IN HINFO "VAXStation 4000" "VMS
V7.0"
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.
system ttl class MX preference gateway
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.
This example gives three MX records for host TULIP (in the current domain). The mailer tries to deliver the mail to host TULIP.EXAMPLE.COM first, because that record has the lowest preference-value. If the attempt fails, it tries host IRIS.EXAMPLE.COM and then LILAC.EXAMPLE.COM.
;system ttl class type
preference gateway
tulip IN MX 10 tulip.example.com.
tulip IN MX 15 iris.example.com.
tulip IN MX 20 lilac.example.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.
owner ttl class NS server
NS
The type, which must be NS.
server
Domain name of the host that serves the domain.
This example gives the syntax of three NS records. DAISY.EXAMPLE.COM and IRIS.EXAMPE.COM are both servers for the EXAMPLE.COM domain. The owner field is blank for IRIS.EXAMPLE.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.EXAMPLE.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
example.com. IN NS daisy.example.com.
IN NS iris.example.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.
rev-addr ttl class PTR realname
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.
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.example.com.
4 IN PTR lilac.example.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.
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.
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.example.com becomes gardener.iris.example.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. 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. 600 seconds (10 minutes) is a reasonable value.
expire
How long (in seconds) the secondary server can use its copy of the database file when it cannot obtain a refresh. 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).
This example shows a typical SOA record format. The values are described in the table.
;owner ttl class type
origin person
@ IN SOA iris.example.com. gardener.iris.example.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.example.com. |
Primary server host name |
|
gardener.iris.example.com. |
"Owner" of the DNS software on the local domain (the mailbox address gardener@iris.example.com becomes gardener.iris.example.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.
owner ttl class TXT txt-data
TXT
The type, which must be TXT.
txt-data
One or more character strings of descriptive text.
Access error messages help by entering HELP TCPWARE MESSAGES [identifier].
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 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 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.
The below example 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 an IP address of 192.168.3.50.
@ IN SOA rose.example.com.
system.rose.example.com. (
1 ; Serial
3600 ; Refresh
600 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS rose.example.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 known 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.
The below example shows two clusters defined in a zone file. Note that the 192.168.100.2 address is common to both clusters.
$ORIGIN example.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 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 example.com. The first step is to set up a subdomain on the primary server by editing the zone file for the example.com domain and adding the line to delegate the authority to the internal server, homerdns.example.com:
homer IN NS homerdns.example.com.
The next step is to set up homerdns.example.com as a primary name server for domain homer.example.com.
The zone file for homer.example.com on homerdns.example.com should include the lines below:
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.example.com that is accessible from both the primary server (by delegation) and the internal server.
Finally, map cluster.example.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.example.com.
The primary server now serves out the addresses from the zone file 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 time period. 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).