3. Domain Name Services

Introduction

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.

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 "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.

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;
        };

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 | hs | hesiod) ]

 

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

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

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};
allow-transfer {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.

 

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
         };

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)
(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;
};

 

·         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 {
  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 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.

 

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.

 

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; };
     };

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
dnssec   lame-servers   network   notify     queries
resolver security       update    xfer-in    xfer-out
lame-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-category
print-severity
print-time

Specifies the category, severity level, and time stamp of the messages.
The default is NO for each item.

 

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, restart the DNS software so that the name server can update its database.

 

 

Special Characters

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.

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.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

 

 

 

 


 

$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: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.

 

 

 

 


 

Resource Records

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.

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.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.

 

 

 

 


 

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

 

 

 

 

 

 


 

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.

 

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.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.

 

 

 

 

 


 

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 contain space characters.

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

 

 

 

 

 


 

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.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.

 

 

 

 

 


 

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.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.

 

 

 

 


 

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.example.com.
4                  IN       PTR     lilac.example.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.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).

 

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.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.

 

 

 

 


 

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.

 

 

 

 


 

 

Troubleshooting Domain Name Services

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.

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 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.

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

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.

Overlapping Clusters

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

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 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.

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 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).