In the same OpenVMS Cluster, multiple BIND master servers can share a common database, thereby providing redundancy and a failover mechanism when one of the servers becomes unavailable.

To configure a DNS cluster failover and redundancy environment, perform the following steps on each node participating in the cluster.

1. Run the TCPIP$CONFIG command procedure, and from the Servers menu enable the BIND service.
2. Edit the BIND configuration file, SYS$SPECIFIC:[TCPIP$BIND]TCPIP$BIND.CONF.
   • Configure the node as a master server.
   • Add or edit the options statement. The directory substatement should be as follows:

     options { directory "TCPIP$BIND_COMMON"; };

     
     TCPIP$BIND_COMMON is a logical name defined in the TCPIP$BIND_COMMON_STARTUP.COM command procedure as a search list. The search list consists of the SYS$SPECIFIC:[TCPIP$BIND] directory and the common directory. You will be prompted by the setup command procedure in the next step to specify the device on which the common directory is to reside. If you do not specify a device, the default device and directory is common_device:[TCPIP$BIND_COMMON], where common_device is automatically generated in the following manner:

     • If the SYSUAF logical is defined, the common disk is determined from its definition.
     • If the SYSUAF logical is not defined, the system uses SYS$SYSDEVICE as the default device.
3. Run the SYS$COMMON:[SYSMGR]TCPIP$BIND_CLUSTER_SETUP.COM command procedure.
   This procedure creates two other command procedures that manage the startup and shutdown processes of the BIND component in a cluster environment:
   • SYS$COMMON:[SYSMGR]TCPIP$BIND_COMMON_STARTUP.COM
   • SYS$COMMON:[SYSMGR]TCPIP$BIND_COMMON_SHUTDOWN.COM
   
   These files define the BIND system logicals and accounting information. To remove the failover setup from your system, delete these two files.
4. Place any database files to be shared in the common directory.

   Note Be careful to remove from SYS$SPECIFIC:[BIND] any databases that are to be shared. Using the search list logical, BIND will find any SYS$SPECIFIC:[BIND] databases first and use those. This may not be the result you want.

5. Start up BIND by entering the following command:

   $ @SYS$COMMON:[SYSMGR]TCPIP$BIND_STARTUP.COM

If multiple master BIND servers are running in a cluster, and a change is made to the common BIND database, the database must be reloaded on each node running the master BIND server. To reload the BIND database on every node in the cluster where the master BIND server is running, enter the following command:

TCPIP> SET NAME_SERVICE /INITIALIZE /CLUSTER=dev:[directory]

The /CLUSTER qualifier takes the directory specification of the common BIND directory as a value. If you omit the device and directory, it defaults to:

common_device:[TCPIP$BIND_COMMON]

In this case, common_device is automatically generated in the following manner:

• If the SYSUAF logical is defined, the the common disk is determined from its definition.
• If SYSUAF logical is not defined, the system uses SYS$SYSDEVICE as the default device.

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

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

To populate the BIND server database by copying information from the hosts database and other database files, enter the CONVERT/UNIX 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 Exchange (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/UNIX BIND command includes: a , b.x.y.z , c.x.y.z.z but does not include d.x.y.h .
• 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:[TCPIP$BIND] and you have specified domain abc.def.com , the default output file is named SYS$SPECIFIC:[TCPIP$BIND]ABC_DEF_COM.DB.

Compaq suggests that you do not change the default directory name. 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. The following 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.

TCPIP> CONVERT/UNIX BIND /DOMAIN=UCX.ERN.SEA.COM TCPIP> CONVERT/UNIX BIND /DOMAIN=208.20.9.IN-ADDR.ARPA TCPIP> SET DEFAULT SYS$SPECIFIC:[TCPIP$BIND] $ DIRECTORY Directory SYS$SPECIFIC:[TCPIP$BIND] 127_0_0.DB;1 208_20_9_IN-ADDR_ARPA.DB;1 LOCALHOST.DB;1 LOGIN.COM;1 ROOT.HINT;1 TCPIP$BIND.CONF;1 TCPIP$BIND_CONF.TEMPLATE;1 TCPIP$BIND_RUN.LOG;4339 TCPIP$BIND_SERVER.PID;1 UCX_ERN_SEA_COM.DB;5

5.4.2 Manually Editing Zone Files

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

Table 5-11 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	Mail Exchange. Identifies where to deliver mail for a given domain.
CNAME	Canonical name. 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

In this format:

name	Specifies 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	Defines the length of time, in seconds, that the information in this resource record should be kept in cache. Usually, the time-to-live 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-11 for the record types you can specify.)
data	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.4.3 Saving Backup Copies of Zone Data

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

5.4.4 Sample Database Files

The following sections provide sample BIND database files.

5.4.4.1 Local Loopback: Forward and Reverse Translation Files

In the LOCALHOST.DB file, the local host address is usually 127.0.0.1. The following sample LOCALHOST.DB file shows the forward translation for the local loopback interface.

; ; BIND data file for local loopback interface (forward translation). ; ; Provided for Compaq TCP/IP Services for OpenVMS. ; $ORIGIN localhost. @ 1D IN SOA @ root ( 42 ;Serial 3H ;Refresh 15M ;Retry 1W ;Expiry 1D ) ;Minimum ; 1D IN NS @ 1D IN A 127.0.0.1

The following sample 127_0_0.DB file shows the reverse translation for the local loopback interface.

; ; BIND data file for local loopback interface (reverse translation). ; ; Provided for Compaq TCP/IP Services for OpenVMS. ; $ORIGIN 0.0.127.in-addr.arpa. @ 1D IN SOA localhost. root.localhost. ( 42 ;Serial 3H ;Refresh 15M ;Retry 1W ;Expiry 1D ) ;Minimum ; 1D IN NS localhost. 1 1D IN PTR localhost.

These local host databases provide forward and inverse translation for the widely used LOCALHOST name. The LOCALHOST name is always associated with the IP address 127.0.0.1 and is used for local loopback traffic.

5.4.4.2 Hint File

This file contains root name server hints. Any name server running on a host without direct Internet connectivity should list the internal roots in its hint file.

The following sample shows a ROOT.HINT file. In earlier releases, this file was called NAMED.CA.

; Data file for initial cache data for root domain servers. ; ; Provided for Compaq TCP/IP Services for OpenVMS. ; ; <<>> DiG 8.1 <<>> @192.5.5.241 ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUERY SECTION: ;; ., type = NS, class = IN ; ;; ANSWER SECTION: . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. . 6D IN NS A.ROOT-SERVERS.NET. ; ;; ADDITIONAL SECTION: H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 ; ;; Total query time: 608 msec ;; FROM: ucx.ern.sea.com to SERVER: 192.5.5.241 ;; WHEN: Mon May 18 15:26:19 1998 ;; MSG SIZE sent: 17 rcvd: 436

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

To create a ROOT.HINT file:

1. Run TCPIP$CONFIG.
2. Select the Server Components menu.
3. Select the BIND server.

This procedure creates the ROOT.HINT file and places the file in the SYS$SPECIFIC:[TCPIP$BIND] directory.

5.4.4.3 Forward Translation File

The forward translation file, domain_name.DB, stores host-name-to-address mapping. For example, for the domain ROBIN.BIRD.COM, the following database file is created: 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 master server. All other servers obtain this information from the master server. This file contains most of the domain information and has the following characteristics:

• 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.4.4.4 Reverse Translation File

The reverse translation file, address.DB, stores address-to-host-name mapping (reverse mapping) information. For example, for the same domain, a file with the name 208_20_9_IN-ADDR_ARPA.DB is created.

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 predominate in this file because they are used to translate addresses to host names.

5.5 Examining Name Server Statistics

The BIND server collects statistics that record server activity. To examine BIND statistics, use the SHOW NAME_SERVICE/STATISTICS command. This command logs statistics to the file TCPIP$BIND_SERVER_STATISTICS.LOG, located in SYS$SPECIFIC:[TCPIP$BIND].

The following sample shows a statistics log:

34250 time since boot (secs) 15670 time since reset (secs) 12 Unknown query types 20000 A queries 540 SOA queries 2399 MX queries 867 ANY queries 3 AXFR queries ++ Name Server Statistics ++ (Legend) RR RNXD RFwdR RDupR RFail RFErr RErr RAXFR RLame ROpts SSysQ SAns SFwdQ SDupQ SErr RQ RIQ RFwdQ RDupQ RTCP SFwdR SFail SFErr SNaAns SNXD (Global) 2 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 5 0 0 0 0 0 -- Name Server Statistics -- ++ Memory Statistics ++ 3: 9 gets, 2 rem 4: 7 gets, 0 rem (1 bl, 1022 5: 16 gets, 1 rem 6: 7 gets, 5 rem 7: 10 gets, 5 rem 8: 97 gets, 16 rem (1 bl, 485 ff) 13: 6 gets, 4 rem . . . 664: 5 gets, 1 rem (1 bl, 5 ff) 732: 2 gets, 0 rem (1 bl, 5 ff) 1040: 1 gets, 1 rem (1 bl, 2 ff) >= 1100: 23 gets, 9 rem -- Memory Statistics -- --- Statistics Dump --- (907337687) Fri Jan 7 10:14:47 2000

The log lists information about how long the server has been running and how long since the last reset, and provides a count of the number of queries processed for each available resource record type.

In the Memory Statistics section, statistics for each size are displayed showing, in the following order:

1. The total number of times that a buffer of that size was allocated (gets).
2. The number of buffers of that size which have not yet been freed and currently remain allocated (rem).
3. The number of blocks currently allocated. Note that buffers are allocated in large groups at a time, and these groups are called blocks (bl).
4. The number of buffers within those blocks that are currently free (ff, which stands for free fragments).