# DIGITAL TCP/IP Services for OpenVMS
Management

Previous | Contents

## 5.3.1 Setting Up BIND Servers

You configure primary and secondary servers with the UCX$BINDSETUP.COM or with SET CONFIGURATION BIND commands. To see your current BIND configuration, issue:

    UCX> SHOW CONFIGURATION BIND

    Primary
      Domain:     0.0.127.IN-ADDR.ARPA          File: NAMED.LOCAL

    Secondary
      Domain:     208.20.9.IN-ADDR.ARPA        File: 208_20_9_IN-ADDR_ARPA.DB
      Host:       9.20.208.53

    Cache
      Domain:     .                             File: NAMED.CA

The following sections describe how to manually set up BIND servers.

### 5.3.1.1 Setting Up a Primary Name Server

To instruct the primary name server to read the appropriate database files using UCX$CONFIGURATION.DAT, issue SET CONFIGURATION BIND commands. Use the command SHOW CONFIGURATION BIND to display BIND information from the UCX configuration database (UCX$CONFIGURATION.DAT).

Example:
The following command tells the name server to read the appropriate files.

    UCX> SET CONFIGURATION BIND /CACHE

    UCX> SET CONFIGURATION BIND -
    _UCX> /PRIMARY=(DOMAIN:0.0.127.IN-ADDR.ARPA, FILE:NAMED.LOCAL)

    UCX> SET CONFIGURATION BIND -
    _UCX> /PRIMARY=(DOMAIN:UCX.ERN.SEA.COM, FILE:UCX_ERN_SEA_COM.DB)

    UCX> SET CONFIGURATION BIND -
    _UCX> /PRIMARY=(DOMAIN:208.20.9.IN-ADDR.ARPA, FILE:208_20_9_IN-ADDR_ARPA.DB)

To view these settings, issue the SHOW CONFIGURATION BIND command, for example:

    UCX> SHOW CONFIGURATION BIND

> Note

> You can configure only one primary name server per OpenVMS Cluster system.

### 5.3.1.2 Setting Up a Secondary Name Server

Configure a secondary server to populate itself by copying the DNS database files from the primary server.

To configure a secondary server, issue:

    UCX> SET CONFIGURATION BIND /CACHE

    UCX> SET CONFIGURATION BIND -
    _UCX> /PRIMARY=(DOMAIN:0.0.127.IN-ADDR.ARPA, FILE:NAMED.LOCAL)

    UCX> SET CONFIGURATION BIND -
    _UCX> /SECONDARY=(DOMAIN:UCX.ERN.SEA.COM,FILE:UCX_ERN_SEA_COM.DB,HOST=DOMAIN:UCX.ERN.SEA.COM)

    UCX> SET CONFIGURATION BIND /SECONDARY=(DOMAIN:208.20.9.IN-ADDR.ARPA,
                                          FILE:208_20_9_IN-ADDR_ARPA.DB,
                                          HOST:OWL.UCX.ERN.SEA.COM)

> Note

> You can configure only one secondary name server per OpenVMS Cluster system.

### 5.3.1.3 Setting Up a Cache-only Server

To configure a cache-only server, issue:

    SET CONFIGURATION BIND /CACHE

This command points the server to the file NAMED.CA.

### 5.3.1.4 Setting Up a Forwarder Name Server

Use forwarders to limit off-site DNS traffic. If your site has five or six name servers, they can all potentially send off-site queries to the off-site servers.

Instead, you can designate a server as a forwarder. This way, the forwarder will build a rich cache of information on the off-site queries. It is likely that such a setup will reduce the off-site traffic dramatically.

It is possible to configure an existing primary or secondary server as a forwarder. That way, if the name server receives a query in the zone for which it is authoritative, or is in its cache, it will use its data cache or send a recursive query to the forwarder. To configure a forwarder, issue:

    UCX> SET CONFIGURATION BIND /FORWARDER=host

> Note

> You cannot set up a server to be both a forwarder and caching server.

## 5.3.2 Populating the BIND Server Databases

The BIND server stores its configuration information in the UCX configuration database. This information includes the zone files the server will use to obtain your local domain information.

To populate the BIND server database, use one of the following methods:

- Convert an existing host database with the CONVERT/ULTRIX BIND command.
- Manually edit the ZONE.DB files.

### 5.3.2.1 Using Existing Databases

To populate the BIND server database by copying information from the hosts database and other UCX database files, issue the CONVERT/ULTRIX BIND command. This command:

- Creates a BIND server database (if needed).
- Extracts data from the hosts database. (The BIND server uses UNIX-style formatted files.)
- Extracts mail exchanger (MX) information from the routes database.
- Populates the BIND server database with the host and MX records.
- Creates a forward translation file with the following characteristics:
  - It has address, canonical name, and MX entries.
  - If a file with the same name as the output file already exists, the serial number from that file's start-of-authority (SOA) entry increments and becomes the serial number of the new output file.
  - If no previous version of the output file exists, the serial number for the new file is 1.
  When you specify forward translation (by omitting the /DOMAIN qualifier), any host in the hosts database that is not qualified with a domain is included in the target domain. For example, if the local domain is x.y.z., the CONVERT/ULTRIX BIND command includes:

  a | Yes
  b.x.y.z | Yes
  c.x.y.z.z | Yes
  d.x.y.h | No

- Creates a reverse translation file if you specify /DOMAIN=(domain.name) and the end of domain.name is IN-ADDR.arpa.
  The created reverse translation file has the following characteristics:
  - Only records applicable to the domain you specify are placed into the output file.
  - The output file has domain name pointer entries.
  - If a file with the same name as the output file already exists, the serial number from that file's SOA entry increments and becomes the serial number of the new output file.
  - If no previous version of the output file exists, the serial number for the new file is 1.
  - Selects hosts with IP addresses that match the partial IP address from domain.name. For example, /DOMAIN=16.99.in-addr.arpa does a reverse translation and selects hosts whose addresses begin with 99.16.

If the BIND server's directory is SYS$SPECIFIC:[UCX$BIND] and you have specified domain abc.def.com, the default output file is named:

SYS$SPECIFIC:[UCX$BIND]ABC_DEF_COM.DB

DIGITAL suggests that you do not change the default directory. If you do, the file is created in your current directory.

On the command line, specify the full OpenVMS file specification. Do not specify a version number, and do not use wildcards.

Example:
This example uses the domain ucx.ern.sea.com, creates a UCX_ERN_SEA_COM.DB file, creates a 208_20_9_IN-ADDR_ARPA.DB file, and checks the results by displaying directory listings with the new file.

    UCX> CONVERT/ULTRIX BIND /DOMAIN=UCX.ERN.SEA.COM
    UCX> CONVERT/ULTRIX BIND /DOMAIN=208.20.9.IN-ADDR.ARPA
    NAMED.LOCAL and NAMED.CA "local and cache files exists/can be
       retrieved from internet hosts".

    $ SET DEFAULT SYS$SPECIFIC:[UCX$BIND]
    $ DIRECTORY
    Directory SYS$SPECIFIC:[UCX$BIND]

    208_20_9_IN-ADDR_ARPA.DB;1     NAMED.CA;1
    NAMED.LOCAL;1                   UCX_ERN_SEA_COM.DB;1
    UCX$BIND_STARTUP.COM;1          UCX$BIND_STARTUP.LOG;1

    $ DIRECTORY UCX$HOST
    Directory SYS$COMMON:[SYSEXE]

    UCX$HOST.DAT;1

    $ DIRECTORY UCX$CONFIGURATION
    Directory SYS$COMMON:[SYSEXE]

    UCX$CONFIGURATION.DAT;1

### 5.3.2.2 Manually Editing Zone Files

All name server zone files use the same type of records to define domain database information. DIGITAL recommends that you review these resource records before editing any BIND files. The standard resource records (RR) are summarized in Table 5-2.

Table 5-2 Standard Resource Record Types
Record Type | Description
--- | ---
SOA | Start of Authority. Marks the beginning of a zone's data and defines parameters that affect the entire zone.
NS | Name Server. Identifies a domain's name server.
A | Address. Maps a host name to an address.
PTR | Pointer. Maps an address to a host name.
MX | Identifies where to deliver mail for a given domain.
CNAME | Defines an alias host name.
HINFO | Host Information. Describes a host's hardware and operating system.
WKS | Well Known Service. Advertises network services.

The format of DNS records is as follows:

[name] [ttl] IN type data

Here,

name | The name of the domain object referenced by a resource record. The string entered for name is the current domain unless it ends with a dot. If the name field is blank, the record applies to the domain object last named.
ttl | Time-to-live defines the length of time, in seconds, that the information in this resource record should be kept in cache. Usually, this field is left blank and the default ttl, set for the entire zone SOA record is used.
IN | Identifies the record as an Internet DNS resource record.
type | Identifies what kind of resource record this is. (See Table 5-2 for the available record types you can specify.)
data | The information specific to this type of resource record. For example, in an A record, this is the field that contains the actual IP address.

### 5.3.2.3 Saving Backup Copies of Zone Data

The name server saves backup copies of the zone data in SYS$SPECIFIC:[UCX$BIND]. Do not delete your backup copies. When the primary server is down and the secondary server is started, the secondary server cannot perform a zone transfer until the primary server is up. However, with backup copies, the secondary server has some data, though possibly out of date, to perform its basic tasks.

## 5.3.3 Sample Database Files

The following sections provide sample BIND database files.

### 5.3.3.1 NAMED.LOCAL

The following example shows a NAMED.LOCAL file. In NAMED.LOCAL, the network address is usually 127.0.0, and the local host address is usually 127.0.0.1.

    ;
    ; BIND data file for local loopback interface.
    ;
    ; Provided for DIGITAL TCP/IP Services for OpenVMS."
    ;
    @          IN  SOA     owl.ucx.ern.sea.com. postmaster.owl.ucx.ern.sea.com. (
                           1       ; Serial
                           36000   ; Refresh
                           300     ; Retry
                           3600000 ; Expire
                           3600 )  ; TTL Minimum
               IN  NS      owl.ucx.ern.sea.com.
    1          IN  PTR     localhost.
    localhost. IN  A       127.0.0.1

This file is used to convert the loopback address into the name localhost. Here, the SOA record identifies owl.ucx.ern.sea.com as the server originating this zone. The email address postmaster.owl.ucx.ern.sea.com is the point of contact for any questions about the zone.

To create the NAMED.LOCAL file, run the UCX configuration procedure, select the Server Components Menu, and select the BIND server. The procedure creates NAMED.LOCAL.

### 5.3.3.2 NAMED.CA

The following example shows a NAMED.CA file.

    ;       This file holds the information on root name servers needed to
    ;       initialize cache of Internet domain name servers
    ;       (e.g. reference this file in the "cache file"
    ;       configuration file of BIND domain name servers).
    ;
    ;       This file is made available by InterNIC registration services
    ;       under anonymous FTP as
    ;           file                /domain/named.root
    ;           on server           FTP.RS.INTERNIC.NET
    ;       -OR- under Gopher at    RS.INTERNIC.NET
    ;           under menu          InterNIC Registration Services (NSI)
    ;              submenu          InterNIC Registration Archives
    ;           file                named.root
    ;
    ;       last update:    Jan 22, 1997
    ;       related version of root zone:   1997012200
    ;
    ;
    ; formerly NS.INTERNIC.NET
    ;
    .                        3600000  IN  NS    A.ROOT-SERVERS.NET.
    A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
    ;
    ; formerly NS1.ISI.EDU
    ;
    .                        3600000      NS    B.ROOT-SERVERS.NET.
    B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
    ;
    ; formerly C.PSI.NET
    ;
    .                        3600000      NS    C.ROOT-SERVERS.NET.
    C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
    ;
    ; formerly TERP.UMD.EDU
    ;
    .                        3600000      NS    D.ROOT-SERVERS.NET.
    D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
    ;
    ; formerly NS.NASA.GOV
    ;
    .                        3600000      NS    E.ROOT-SERVERS.NET.
    E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
    ;
    ; formerly NS.ISC.ORG
    ;
    .                        3600000      NS    F.ROOT-SERVERS.NET.
    F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
    ;
    ; formerly NS.NIC.DDN.MIL
    ;
    .                        3600000      NS    G.ROOT-SERVERS.NET.
    G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
    ;
    ; formerly AOS.ARL.ARMY.MIL
    ;
    .                        3600000      NS    H.ROOT-SERVERS.NET.
    H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
    ;
    ; formerly NIC.NORDU.NET
    ;
    .                        3600000      NS    I.ROOT-SERVERS.NET.
    I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
    ;
    ; temporarily housed at NSI (InterNIC)
    ;
    .                        3600000      NS    J.ROOT-SERVERS.NET.
    J.ROOT-SERVERS.NET.      3600000      A     198.41.0.10
    ;
    ; temporarily housed at NSI (InterNIC)
    ;
    .                        3600000      NS    K.ROOT-SERVERS.NET.
    K.ROOT-SERVERS.NET.      3600000      A     198.41.0.11
    ; End of File

This cache initialization file contains NS records that name root servers and A records that provide the addresses of root servers.

To create the NAMED.CA file, run the UCX configuration procedure, select the Server Components Menu, and select the BIND server. The procedure creates NAMED.CA.

### 5.3.3.3 DOMAIN_NAME.DB

The DOMAIN_NAME.DB file stores host-name-to-address mapping. For example, for domain ROBIN.BIRD.COM, UCX creates the database file ROBIN_BIRD_COM.DB. The following example shows a DOMAIN_NAME.DB file.

    $ORIGIN ucx.ern.sea.com.
    @               IN      SOA     owl.ucx.ern.sea.com. pmaster.owl.ern.sea.com.
    (
                                    23      ; Serial
                                    600     ; Refresh
                                    300     ; Retry
                                    172800  ; Expire
                                    43200 ) ; Minimum
    ;
                    IN      NS      owl.ucx.ern.sea.com.
                    IN      NS      condor.ucx.ern.sea.com.
    ;
    thrush          IN      A       9.20.208.53
    condor          IN      A       9.20.208.10
    birdy           IN      A       9.20.208.47
                    IN      MX      10 birdy.ucx.ern.sea.com.
                    IN      MX      100 inet-gw-1.pa.emu.com.
                    IN      MX      100 mts-gw.pa.emu.com.
                    IN      MX      200 crl.emu.com.
                    IN      MX      300 nester.emu.com.
    seagull         IN      A       9.20.208.30
                    IN      MX      10 seagull.ucx.ern.sea.com.
                    IN      MX      100 inet-gw-1.pa.emu.com.
                    IN      MX      100 mts-gw.pa.emu.com.
                    IN      MX      200 crl.emu.com.
                    IN      MX      300 nester.emu.com.
    owl             IN      A       9.20.208.72
                    IN      MX      10 owl.ucx.ern.sea.com.
                    IN      MX      100 inet-gw-1.pa.emu.com.
                    IN      MX      100 mts-gw.pa.emu.com.
                    IN      MX      200 crl.emu.com.
                    IN      MX      300 nester.emu.com.
    peacock         IN      A       9.20.208.73
                    IN      MX      10 pultdown.ucx.ern.sea.com.
                    IN      MX      100 inet-gw-1.pa.emu.com.
                    IN      MX      100 mts-gw.pa.emu.com.
                    IN      MX      200 crl.emu.com.
                    IN      MX      300 nester.emu.com.
    redwing         IN      A       9.20.208.79
                    IN      MX      10 redwing.ucx.ern.sea.com.
                    IN      MX      100 inet-gw-1.pa.emu.com.
                    IN      MX      100 mts-gw.pa.emu.com.
                    IN      MX      200 crl.emu.com.
                    IN      MX      300 nester.emu.com.
    robin           IN      A       9.20.208.47
                    IN      A       9.20.208.30
                    IN      A       9.20.208.72

This file is created only for the primary server. All other servers obtain this information from the primary server. This file contains most of the domain information. Note, this file

- Begins with an SOA record and a few NS records that define the domain and its servers.
- Maps host names to IP addresses.
- Contains A, MX, CNAME, and other records.

MX records identify the servers in a domain that are used for forwarding mail. Use MX records and preference numbers to define the order in which mail servers are used. The lower the preference number, the more desirable the server.

### 5.3.3.4 ADDRESS.DB

The ADDRESS.DB file stores address-to-host-name mapping (reverse mapping) information. For example, for the same domain, UCX creates this file with the name 208_20_9_IN-ADDR_ARPA.DB.

The following example shows an ADDRESS.DB file.

    $ORIGIN 208.20.9.in-addr.arpa.
    @     IN   SOA   owl.ucx.ern.sea.com. pmaster.owl.ucx.ern.sea.com.
    (
                              1       ; Serial
                              600     ; Refresh
                              300     ; Retry
                              172800  ; Expire
                              43200 ) ; Minimum
    ;
          IN      NS      owl.ucx.ern.sea.com.
          IN      NS      condor.ucx.ern.sea.com.
    ;
    53              IN      PTR     thrush.ucx.ern.sea.com.
    10              IN      PTR     condor.ucx.ern.sea.com.
    47              IN      PTR     birdy.ucx.ern.sea.com.
    30              IN      PTR     seagull.ucx.ern.sea.com.
    72              IN      PTR     owl.ucx.ern.sea.com.
    73              IN      PTR     peacock.ucx.ern.sea.com.
    79              IN      PTR     redwing.ucx.ern.sea.com.

PTR records dominate this file because they are used translate addresses to host names.

# 5.4 Displaying Name Server Information

Several SHOW commands provide information to help you monitor the name server. The following example shows the kind of data displayed by the SHOW NAME_SERVICE /STATISTICS command.

    UCX> SHOW NAME_SERVICE /STATISTICS
                                  BIND Name Server Statistics

    Boot time:  2-DEC-1997 10:50:05.00      Reset time:  2-DEC-1997 10:50:05.00

    In packets:                          1208
    Out packets:                         1311

    Queries:                              844
    Iqueries:                               0
    Dup. queries:                           6
    Sys. queries:                          28

    Responses:                            369
    Duplicate response:                     0
    Respok:                               707
    Respfail:                             121
    Respformerr:                            0
    Bad responses:                          0

    Prime cache:                            1
    Check NS:                               1
    Martians:                               0
    UCX>

The fields in the display have the following meanings:

- In packets:
  Number of UDP datagrams that the local name server has received. The datagrams can be:
  - Queries from applications and remote name servers
  - Query responses from remote name servers
- Out packets:
  Number of UDP datagrams that the local name server has sent.
  This number can be larger than "In packets" because some queries made to remote servers might go unanswered, causing the local name server to send several queries per one response.
  The local name server can also send queries of its own. If the number of "Out packets" is significantly larger than the number of "In packets," it indicates the possibility of a break in network connectivity.
- Queries:
  Number of queries received by the local name server.
- Iqueries:
  Number of inverse queries received by the name server.
  Inverse queries are for reverse lookups. They map a resource to a domain name. For example, a standard query binds a domain name to an address, but the corresponding Iquery binds the host address to a domain name.
  Iqueries are obsolete. PTR resource records are now used to map host addresses to host names. For more information on resource records, see Table 5-2.
- Dup. queries:
  Number of duplicate (retransmitted) queries received by the local name server.
- Sys. queries:
  Number of system queries initiated by the local name server, not by applications.
- Responses:
  Number of responses received by the local name server from remote name servers.
- Duplicate response:
  Number of duplicate responses received by the local name server from remote servers.
  After the first response is received from a remote name server, the next responses to the same query are each considered a duplicate response.
- Respok: (response OK)
  Valid responses issued by the local name server to the queries it receives from the remote name servers. The meaning can be that the name exists.
  A response is not "OK" when the return code in the response includes one of the following: server failure (SERVFAIL), no such domain (NXDOMAIN), format error (FORMERR), not implemented (NOTIMP), or refused (REFUSED).
- Respfail:
  Number of failed responses issued by the local name server. Failed answers could mean that the queried name does not exist. Failed responses include all types of server failures.
- Respformerr:
  Number of format errors issued by the local name server.
- Bad responses:
  Number of bad responses that the local name server receives from remote servers.
- Prime cache:
  Number of times the server uses the hints provided in NAMED.CA to find out the current root name server list.
- Check NS:
  Number of times the name server issues system queries to validate for the address of every root name server.
- Martians:
  Displays the responses received by the local name server for queries that it did not send.

# 5.5 Load Balancing with BIND

The BIND server provides two ways to balance system load:

- Simple round-robin scheduling (see Section 5.5.1)
- True, calculated cluster load balancing (see Section 5.5.2)

> Note

> This section uses the term "cluster" to refer to several A resource records for a single host name.

## 5.5.1 Round-Robin Scheduling

Round-robin scheduling is the default method used by the BIND server for load balancing clusters. If a multiple resource record satisfies a query, the BIND server returns it 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 server always passes the next incoming request to the last cluster member that received a request. The round-robin scheme is also useful for MX records to share mail loads among multiple equivalent gateways.

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

The following example demonstrates how round-robin balancing works.

The cluster alias is defined as ROBIN. In addition, host ROBIN is a member of the cluster. When the BIND server receives queries for ROBIN, it shuffles the records in a round-robin manner, as shown in the example.

    ;
    ; TCP/IP cluster load balancing - Round Robin Approach
    ; cluster name:   "robin"
    robin                           IN      A       9.20.208.47
                                    IN      A       9.20.208.30
                                    IN      A       9.20.208.72
    ;

A user issues the TELNET command, specifying the cluster alias ROBIN. The first query to the name server is the result of the following command:

    $ 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 RR in the list.

The second query to the name server is the result of the following command:

    $ 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 RR in the list.

The third query to the name server is the result of the following command:

    $ 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 RR in the list.

The fourth query to the name server is the result of the following command:

    $ 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 name server illustrates the shuffling effect in greater detail:

    UCX> SHOW HOST ROBIN
         BIND database

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

    Host address    Host name

    9.20.208.47 birdy.ucx.ern.sea.com
    9.20.208.30 seagull.ucx.ern.sea.com
    9.20.208.72 owl.ucx.ern.sea.com

    UCX>  SHOW HOST ROBIN
         BIND database

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

    Host address    Host name

    9.20.208.30 seagull.ucx.ern.sea.com
    9.20.208.72 owl.ucx.ern.sea.com
    9.20.208.47 birdy.ucx.ern.sea.com

    UCX>  SHOW HOST ROBIN
         BIND database

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

    Host address    Host name

    9.20.208.72 owl.ucx.ern.sea.com
    9.20.208.47 birdy.ucx.ern.sea.com
    9.20.208.30 seagull.ucx.ern.sea.com

    UCX>  SHOW HOST ROBIN
         BIND database

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

    Host address    Host name

    9.20.208.47 birdy.ucx.ern.sea.com
    9.20.208.30 seagull.ucx.ern.sea.com
    9.20.208.72 owl.ucx.ern.sea.com

Define the logical name UCX$BIND_ROUND_ROBIN_OFF to disable round-robind scheduling.

The BIND server automatically uses round-robin scheduling on clusters of multiple A resource records unless a load balancing cluster is defined in the UCX configuration database.

Previous | Next | Contents