# Compaq TCP/IP Services for OpenVMS
Management

Previous | Contents | Index

## 5.8.5 Query Types

You can change the type of information you receive from a query. The default query type is A. Table 5-14 lists the different types of query information.

### 5.8.5.1 A Query Type

This is the default NSLOOKUP query type. It returns the name and IP address of a host. The following NSLOOKUP session shows a query for the host `apple` . The query to the server `condor.lgk.dec.com` is successful, and the server returns the IP address 16.99.208.10.

    $ NSLOOKUP
    Default Server:  condor.lgk.dec.com
    Address:  16.99.208.53

    > apple
    Server:  condor.lgk.dec.com
    Address:  16.99.208.53

    Name:    apple.lgk.dec.com
    Address:  16.99.208.10
    >

If you enter a domain name without a trailing period, NSLOOKUP appends the default domain to the name. You can change the default domain with the `set domain` or `set srchlist` commands.

To look up a host not in the current domain, append a period to the name, as shown in the following example:

    $ NSLOOKUP apple.koz.dec.com.

### 5.8.5.2 PTR Query Type

To obtain the host name for an IP address, change the query type to PTR and enter the IP address, as shown in the following example:

    > set type=ptr
    > 16.99.208.189
    Server:  condor.lgk.dec.com
    Address:  16.99.208.53

    Name:    dove.lgk.dec.com
    Address:  16.99.208.189

You can also use the PTR query type to obtain more information about a domain, as as shown in the following example:

    > lgk.dec.com
    Server:  condor.lgk.dec.com
    Address:  16.99.208.53

    lgk.dec.com
            origin = condor.lgk.dec.com
            mail addr = postmaster.lgk.dec.com
            serial = 1998101948
            refresh = 3600 (1H)
            retry   = 300 (5M)
            expire  = 604800 (1W)
            minimum ttl = 43200 (12H)
    >

### 5.8.5.3 MX Query Type

To obtain information about mail exchange records, set the query type to MX and enter a domain. The output tells you which hosts handle mail for the specified domain, as shown in the following example.

    > set type=mx
    > lgk.dec.com
    Server:  condor.lgk.dec.com
    Address:  16.99.208.53

    lgk.sea.com preference = 200, mail exchanger = crl.sea.com
    lgk.sea.com preference = 50, mail exchanger = collie.lgk.sea.com
    lgk.sea.com preference = 100, mail exchanger = mail13.digital.com
    lgk.sea.com preference = 100, mail exchanger = mail11.digital.com
    lgk.sea.com preference = 200, mail exchanger = mail2.digital.com
    lgk.sea.com nameserver = collie.lgk.sea.com
    lgk.sea.com nameserver = condor.lgk.sea.com
    lgk.sea.com nameserver = hageln.lgk.sea.com
    crl.sea.com     internet address = 192.58.206.2
    collie.lgk.sea.com  internet address = 16.99.208.100
    mail13.digital.com      internet address = 192.208.46.30
    mail2.digital.com       internet address = 204.123.2.56
    condor.lgk.sea.com  internet address = 16.99.208.53
    hageln.lgk.sea.com  internet address = 16.99.208.10

### 5.8.5.4 SOA Query Type

This query type returns the domain's start-of-authority information.

    > set type=soa
    > microsoft.com
    Server:  condor.lgk.sea.com
    Address:  16.99.208.53

    microsoft.com
            origin = dns1.microsoft.com
            mail addr = msnhst.microsoft.com
            serial = 1998101204
            refresh = 7200 (2H)
            retry   = 1800 (30M)
            expire  = 2592000 (4w2d)
            minimum ttl = 86400 (1D)
    microsoft.com   nameserver = dns3.nwnet.net
    microsoft.com   nameserver = dns4.nwnet.net
    microsoft.com   nameserver = dns1.microsoft.com
    microsoft.com   nameserver = dns2.microsoft.com
    microsoft.com   nameserver = dns1.moswest.msn.net
    microsoft.com   nameserver = dns2.moswest.msn.net
    dns3.nwnet.net  internet address = 192.220.250.7
    dns4.nwnet.net  internet address = 192.220.251.7
    dns1.microsoft.com      internet address = 131.107.1.7
    dns2.microsoft.com      internet address = 131.107.1.240

### 5.8.5.5 NS Query Type

To obtain information about the name servers for a particular zone, set the query type to NS and then enter the zone you want. The following example shows the name servers for the microsoft.com zone.

    > set type=ns
    > microsoft.com
    Server:  condor.lgk.sea.com
    Address:  16.99.208.53

    Non-authoritative answer:
    microsoft.com   nameserver = dns2.microsoft.com
    microsoft.com   nameserver = dns1.moswest.msn.net
    microsoft.com   nameserver = dns2.moswest.msn.net
    microsoft.com   nameserver = dns3.nwnet.net
    microsoft.com   nameserver = dns4.nwnet.net
    microsoft.com   nameserver = dns1.microsoft.com

    Authoritative answers can be found from:
    dns2.microsoft.com      internet address = 131.107.1.240
    dns3.nwnet.net  internet address = 192.220.250.7
    dns4.nwnet.net  internet address = 192.220.251.7
    dns1.microsoft.com      internet address = 131.107.1.7
    >

## 5.8.6 Changing the Default Server

If you want to use another name server as your default server, use the `server` command.

    $ NSLOOKUP
    Default Server:  condor.klg.sea.com
    Address:  16.99.208.53

    > server ns01.koz.sea.com
    Default Server:  ns01.koz.sea.com
    Address:  16.99.9.20

If for some reason the default server is not responding, you can always use the `lserver` command to change the default server. The `lserver` command uses the initial default name server to look up the IP address of the new server.

    > lserver collie.klg.sea.com
    Default Server:  collie.klg.sea.com
    Address:  16.99.208.10

Or, if you already know the IP address of the new server, you can use the `server` command to reset the default server.

    >server 16.99.208.10

    > server 16.99.99.226
    Default Server:  beagel.zok.sea.com
    Address:  16.99.99.226

## 5.8.7 Listing Domain Information

The `ls` command lists information about a domain. This command is useful for:

- Determining the number of hosts within a domain
- Host names and their IP addresses
- Troubleshooting DNS problems

Table 5-15 describes options to the `ls` command.

Table 5-15 Options to the NSLOOKUP `ls` Command
Option | Function
--- | ---
`-a` | Lists aliases of hosts in the domain (CNAME entries).
`-d` | Lists all the entries in the domain.
`-h` | Lists CPU and operating system information for the domain (HINFO entries).
`-m` | Lists mail exchange (MX) entries in the domain.
`-s` | Lists well-known services (WKS) in the domain.
`-t` | Lists a specified entry type.

The following example shows the use of the `ls` command to obtain address records for all hosts within a zone.

    > ls -t a lgk.sea.com
    [condor.lgk.sea.com]
    @                       12H IN A        16.99.208.208
    dhcp-253                12H IN A        16.99.208.253
    ucxv4a                  12H IN A        16.99.208.129
    beavis                  12H IN A        16.99.208.90
    boxmor                  12H IN A        16.99.208.30
    kempo                   12H IN A        16.99.208.47
    pacnet                  12H IN A        16.99.208.84
    kwai                    12H IN A        16.99.208.63
    alxica                  12H IN A        16.99.9.37
    ppponvms                12H IN A        16.99.208.104
    a71kt                   12H IN A        16.99.208.142
    peteathome              12H IN A        16.99.208.101
    larisa                  12H IN A        16.99.208.49
    pigdog                  12H IN A        16.99.208.140
    ntruder                 12H IN A        16.99.208.110

In the following example, the `ls` command displays alias records for hosts within the `lgk.sea.com` domain.

    > ls -a lgk.sea.com
    [condor.lgk.sea.com]
    $ORIGIN LGK.SEA.COM.
    celics                  12H IN CNAME    celtics
    news                    12H IN CNAME    nntpd.KLG.SEA.COM.
    tiger                   12H IN CNAME    ntruder
    console                 12H IN CNAME    bblts.KLG.SEA.COM.
    deebug                  12H IN CNAME    dot
    ayla                    12H IN CNAME    ayla.KLG.SEA.COM.
    cscibm                  12H IN CNAME    cscibm.KLG.SEA.COM.
    >

Using the `-m` option obtains the MX records for hosts within the `lgk.sea.com` domain, as shown in the following example.

    > ls -m lgk.sea.com
    brigit                  12H IN MX       10 brigit
                            12H IN MX       100 mail1.digital.com.
                            12H IN MX       100 mail2.digital.com.
                            12H IN MX       200 crl.SEA.com.
    piglet                  12H IN MX       10 piglet
                            12H IN MX       100 mail1.digital.com.
                            12H IN MX       100 mail2.digital.com.
                            12H IN MX       200 crl.SEA.com.
    tieta                   12H IN MX       10 tieta
                            12H IN MX       100 mail1.digital.com.
                            12H IN MX       100 mail2.digital.com.
                            12H IN MX       200 crl.SEA.com.
    sherry                  12H IN MX       10 sherry
                            12H IN MX       100 mail1.digital.com.
                            12H IN MX       100 mail2.digital.com.
                            12H IN MX       200 crl.SEA.com.

In the following example, using the `-s` option displays the well-known services for a domain.

    > ls -s lgk.sea.com
    [condor.lgk.sea.com]
    WKStesthave             12H IN WKS      16.99.208.255 21 ( )
    WKStesthavenot          12H IN WKS      16.99.208.255 255 ( )
    WKStestnumbers          12H IN WKS      16.99.208.255 255 ( 21 23 )

You can redirect the output from this command to a file. This method is helpful when the domain consists of a large number of hosts. Once the file is created, you can look at its contents with the DCL command TYPE. For example:

    > ls -t a klg.sea.com > systems.txt
    [condor.klg.sea.com]
    #############
    Received 932 answers (0 records).

    $ TYPE SYSTEMS.TXT
    > ls -t a klg.sea.com
    [condor.klg.sea.com]
    $ORIGIN KLG.SEA.COM.
    @                       12H IN A        16.99.208.208
    dhcp-253                12H IN A        16.99.208.253
    ucxv4a                  12H IN A        16.99.208.129
    beavis                  12H IN A        16.99.208.90
    boxmor                  12H IN A        16.99.208.30
    kempo                   12H IN A        16.99.208.47
    pacnet                  12H IN A        16.99.208.84
    kwai                    12H IN A        16.99.208.63
    alxica                  12H IN A        16.99.9.37
    ppponvms                12H IN A        16.99.208.104

# 5.9 Solving Bind Server Problems

To solve BIND server problems, refer to the following sections:

- Section 5.9.1, Server Not Responding
- Section 5.9.2, Serial Number Mismatch

## 5.9.1 Server Not Responding

A missing client name in the BIND server's database files results in lack of service to that client. If records that point to the name servers (NS records) in a domain are missing from your server's database files, you might see the following messages:

    %TCPIP-W-BIND_NOSERVNAM, Server with address 199.85.8.8 is not responding
    %TCPIP-E-BIND_NOSERVERS, Default servers are not available
    %TCPIP-W-NORECORD, Information not found
    -TCPIP-E-BIND_NOSERVERS, Default servers are not available

When the CONVERT/ULTRIX BIND /DOMAIN command creates the .DB files from the hosts database, it cannot detect the existence of or the names of name servers in a domain. Therefore, it does not add NS records for the name servers to the .DB files.

To solve the problem, follow these steps:

1. Stop the BIND server.
2. Manually add NS records for the missing names.
3. Update the start-of-authority (SOA) records by incrementing the serial number.
4. Restart the BIND server.

## 5.9.2 Serial Number Mismatch

The `serial number mismatch log=xxx, zone=xxx` message indicates that the BIND server was unsuccessful in an attempt to load a particular dynamic update from the update log file. This can occur because the update is old and no longer valid. The serial number for the zone has since been incremented and is no longer in synchronization with the serial number attached to the logged update.

# Chapter 6
Using DNS to Balance Work Load

This chapter describes how to use DNS to balance the network traffic on a multihomed host or on network servers when you have multiple systems providing the same network service.

TCP/IP Services provides two methods for balancing work load using DNS:

- Load sharing using the default DNS method of round-robin scheduling.
- Load balancing using the TCP/IP Services load broker. Load broker is a configurable, calculated, load-balancing mechanism for distributing the work load among DNS cluster members.

This chapter discusses how to use DNS to balance server work load and includes the following topics:

- DNS clusters ( Section 6.1)
- Round-robin scheduling ( Section 6.2)
- Load broker concepts ( Section 6.3)
- Load broker startup and shutdown ( Section 6.4)
- Configuring the load broker ( Section 6.5)
- Metric server startup and shutdown ( Section 6.6)
- Solving load broker problems ( Section 6.7)

# 6.1 DNS Clusters

TCP/IP Services defines the term DNS cluster to refer to several A resource records for a single host name. This could be the A resource records for a multihomed host or the A resource records for one or more servers which are to share a work load.

# 6.2 Round-Robin Scheduling

Round-robin scheduling is the default load-sharing method used by a DNS server. If multiple resource records satisfy a query, the BIND server returns them each time in a round-robin order. The round-robin scheme is a simple rotation where client requests are passed from one cluster member to the next. The round-robin scheme is also useful for MX records to share mail loads among multiple equivalent gateways of the same MX preference.

Unlike the traditional load-balancing method, round-robin does not take into account the current work load on the DNS cluster members and does not know whether these hosts are up or down.

The following example demonstrates how round-robin load sharing works.

In the example, the DNS cluster alias is defined as `robin` . When the DNS server receives queries for `robin` , it shuffles the A resource records in a round-robin manner.

    ;
    ; TCP/IP DNS cluster load sharing - round robin method
    ;    DNS cluster alias:   "robin"
    robin                           IN      A       9.20.208.47
                                    IN      A       9.20.208.30
                                    IN      A       9.20.208.72
    ;
    birdy                           IN      A       9.20.208.47
    seagull                         IN      A       9.20.208.30
    owl                             IN      A       9.20.208.72
    ;

A user enters the TELNET command, specifying the DNS cluster alias ROBIN. The first query to the DNS name server results in the following TELNET session:

    $ TELNET ROBIN
    %TELNET-I-TRYING, Trying ... 9.20.208.47
    %TELNET-I-SESSION, Session 01, host birdy, port 23
    -TELNET-I-ESCAPE, Escape character is ^]

The TELNET client connects to host `birdy` at IP address 9.20.208.47, the first resource record in the list.

The second query to the name server results in the following TELNET session:

    $ TELNET ROBIN
    %TELNET-I-TRYING, Trying ... 9.20.208.30
    %TELNET-I-SESSION, Session 01, host seagull, port 23
    -TELNET-I-ESCAPE, Escape character is ^]

The TELNET client connects to host `seagull` at IP address 9.20.208.30, the next resource record in the list.

The third query to the name server results in the following TELNET session:

    $ TELNET ROBIN
    %TELNET-I-TRYING, Trying ... 9.20.208.72
    %TELNET-I-SESSION, Session 01, host owl, port 23
    -TELNET-I-ESCAPE, Escape character is ^]

TELNET connects to host `owl` at IP address 9.20.208.72, the next resource record in the list.

The fourth query to the name server results in the following TELNET session:

    $ TELNET ROBIN
    %TELNET-I-TRYING, Trying ... 9.20.208.47
    %TELNET-I-SESSION, Session 01, host birdy, port 23
    -TELNET-I-ESCAPE, Escape character is ^]

TELNET again connects to host `birdy` at IP address 9.20.208.47. This is the start of the cycle repeating. The cycle repeats for the subsequent queries.

The SHOW HOST display for this DNS name server shows the shuffling effect in greater detail. Notice that the output displays the cluster alias name for each host involved in round-robin scheduling.

    TCPIP> SHOW HOST ROBIN
         BIND database

    Server:   9.20.208.72 owl.ucx.ern.sea.com

    Host address    Host name

    9.20.208.47 robin.ucx.ern.sea.com
    9.20.208.30 robin.ucx.ern.sea.com
    9.20.208.72 robin.ucx.ern.sea.com

    TCPIP> SHOW HOST ROBIN
         BIND database

    Server:   9.20.208.72 owl.ucx.ern.sea.com

    Host address    Host name

    9.20.208.30 robin.ucx.ern.sea.com
    9.20.208.72 robin.ucx.ern.sea.com
    9.20.208.47 robin.ucx.ern.sea.com

    TCPIP>  SHOW HOST ROBIN
         BIND database

    Server:   9.20.208.72 owl.ucx.ern.sea.com

    Host address    Host name

    9.20.208.72 robin.ucx.ern.sea.com
    9.20.208.47 robin.ucx.ern.sea.com
    9.20.208.30 robin.ucx.ern.sea.com

    TCPIP> SHOW HOST ROBIN
         BIND database

    Server:   9.20.208.72 owl.ucx.ern.sea.com

    Host address    Host name

    9.20.208.47 robin.ucx.ern.sea.com
    9.20.208.30 robin.ucx.ern.sea.com
    9.20.208.72 robin.ucx.ern.sea.com

## 6.2.1 Disabling Round-Robin Scheduling

If you want to disable round-robin scheduling, use the DCL command DEFINE to define the following logical:

    $ DEFINE/SYSTEM TCPIP$BIND_ROUND_ROBIN_OFF

# 6.3 Load Broker Concepts

TCP/IP Services provides a configurable, calculated, load-balancing mechanism called the load broker for distributing the load across systems in a DNS cluster.

Unlike round-robin scheduling (the default method used by most DNS name servers), the load broker takes into account the load on all DNS cluster participants. The load broker polls DNS cluster members and updates the DNS namespace accordingly.

## 6.3.1 How the Load Broker Works

When the load broker starts, it reads its configuration file and starts polling DNS cluster members. The load broker exchanges messages with DNS cluster members that run the metric server. The metric server ( Section 6.3.2) calculates the current rating and reports it when polled by the load broker. Periodically, the load broker sorts the list of addresses based on metric rating reports, drops the systems that are not responding after being polled three times, and takes a subset of the list and compares it to the name server information. To do the comparison, the load broker sends a host lookup request to the specified name server. If the lists are the same, the load broker does not make any change. If the lists are different, the load broker updates the name server data by sending a dynamic update request to the specified name server.

The name server uses round-robin scheduling to further balance the load across the members of a DNS cluster. So every consecutive request for translating the DNS cluster name results in a list being returned, rotated by one.

The `dns-ttl` value stored in the load broker configuration file governs how long the record is to be cached by other name servers. If some intermediate name server caches the "A" resource records for a given DNS cluster name, it caches it for the period of time defined by the `dns-ttl` value. The default `dns-ttl` value is 45 seconds. If less time is required, you can set `dns-ttl` to a smaller value. To suppress any caching, you can set the `dns-ttl` to 0.

The `dns-refresh` time specifies how often the DNS information for a given DNS cluster is refreshed. The default is 30 seconds. If you want to quickly pick up changes in the system load (reported by metric servers), set `dns-refresh` to a smaller number.

If the load broker has not received a response from a metric server after three polling intervals, the load broker marks the address for removal from the DNS alias. This removal will occur at the next `dns-refresh` interval.

For earliest possible detection of this failure, the `polling-interval` should be set to a value that is less than one-third of the value specified as the `dns-refresh` period.

           polling-interval  < (dns-refresh) / 3

The `masters` list specifies the name server to use for dynamic updates. This must point to the master name server. The name server must be set up to allow dynamic updates from the system that runs the load broker. For how to configure dynamic updates, see Section 5.3.6.

TCP/IP Services supports dynamic updating of only one master server in a DNS cluster environment.

Previous | Next | Contents | Index