HP OpenVMS Systems Documentation

Table D-9 describes the periodic task options.

If other settings are the same, when the server chooses a name server to query from a list of name servers, it chooses the one that is topologically closest to itself. The topology statement takes an address_match_list and interprets it in a special way. Each top-level list element is assigned a distance. Non-negated elements get a distance based on their position in the list; the closer the match is to the start of the list, the shorter the distance is between the match 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.

In the following example, the server prefers servers on network 10 the most, followed by hosts on network 1.2.0.0 (netmask 255.255.0.0) and network 3, with the exception of hosts on network 1.2.3 (netmask 255.255.255.0), which is preferred least of all.

    topology {
        10/8;
        !1.2.3/24;
        { 1.2/16; 3/8; };
    };

The default topology is as follows:

    topology { localhost; localnets; };

Zone transfers can put a heavy load on network traffic and on a BIND server. If you have a large network with many BIND servers, keeping each server up-to-date can put a strain on the master server and its memory requirements. You can use the server statement to control the number of zone transfers that can occur and the duration of the zone transfer.

The server statement defines characteristics to be associated with a remote name server. The statement has the following syntax:

server ip_address {
          [ bogus yes_or_no; ]
          [ transfers number; ]
          [ transfer-format ( one-answer | many-answers
) ; ]
          [ keys { key_id [key_id ... ] }; ]
};

You can limit the number of zones your name server requests from a single remote name server by including a transfers substatement on the server statement. The default limit is two active zone transfers per name server. When your name server completely receives one of the two zone transfers, if another request is needed, the request will be sent after waiting a period of time.

Example D-7 shows how to code the server statement to limit the number of transfer requests to name server 16.168.1.2 to three at a time.

   server 16.168.1.2 {
           transfers 3
   };

The BIND 8 transfer-format subcommand specifies how your name server transfers zone data to its slaves. The server can transfer one resource record in each DNS message ( one-answer ) or it can transfer as many records as possible into a single DNS message ( many-answers ). Using the many-answers method takes less bandwidth to transfer the same amount of data as the one-answer method and also uses less CPU time to decouple the DNS messages.

Example D-8 shows how to code the server statement to send more than one record in the same DNS message to name server 16.168.1.2.

   server 16.168.1.2 {
           transfer-format many-answers;
   };

The zone statement defines zones maintained by the name server. The statement has the following syntax:

zone domain_name [ ( in | hs | hesiod | chaos ) ] {
                     type master;
                     file path_name;
                     [ check-names ( warn | fail | ignore ); ]
                     [ allow-update { address_match_list }; ]
                     [ allow-query { address_match_list }; ]
                     [ allow-transfer { address_match_list }; ]
                     [ notify yes_or_no; ]
                     [ forward ( only | first ); ]
                     [ also-notify { ip_addr; [ ip_addr; ... ] };

                   };

zone domain_name [ ( in | hs | hesiod | chaos ) ] {
                     type ( slave | stub );
                     [ file path_name; ]
                     masters [ port ip_port ] { ip_addr; [ ip_addr; ... ] };
                     [ check-names ( warn | fail | ignore ); ]
                     [ allow-update { address_match_list }; ]
                     [ allow-query { address_match_list }; ]
                     [ allow-transfer { address_match_list }; ]
                     [ max-transfer-time-in number; ]
                     [ notify yes_or_no; ]
                     [ also-notify { ip_addr; [ ip_addr; ... ] };

                   };


zone "." [ ( in | hs | hesiod | chaos ) ] {
                     type hint;
                     file path_name;
                     [ check-names ( warn | fail | ignore ); ]
                   };

BIND 8.1 uses address match lists for security. Address match lists are lists of elements that can include the following:

• An IP address (in dotted-decimal notation)
• An IP prefix (in the /-notation)
• The name of an address match list previously defined with the acl statement
• An IP address match list

The ACLs any , none , localhost , and localnets are predefined. Elements can be negated with a leading ! .

When a given IP address or prefix is compared to an address match list, the list is traversed in order, and the first match (regardless of negation) is used. The interpretation of a match depends on whether the list is being used for access control or as a topology.

When used as an access control list, a non-negated match allows access, and a negated match denies access. If there is no match, access is denied. The clauses allow-query , allow-transfer , and allow-update all use address match lists like this. Similarly, the listen-on clause can use negation to define local addresses that should not be used to accept name server connections.

When used with the topology clause, a non-negated match returns a distance based on its position on the list. (The closer the match is to the start of the list, the shorter the distance is between the match 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.

Because of the first-match aspect of the algorithm, an element that defines a subset of another element in the list should come before the broader element, regardless of whether either one is negated. For example, in 1.2.3/24; ! 1.2.3.13; the 1.2.3.13 element is useless because the algorithm matches any lookup for 1.2.3.13 to the 1.2.3/24 element. Using ! 1.2.3.13; 1.2.3/24 fixes that problem by having 1.2.3.13 blocked by the negation, but ignores all the other 1.2.3.* hosts.

D.3.6 Dynamic Updates

BIND 8.1 includes support for dynamic updates as specified in RFC 2136 (excluding support for the security mechanism described by RFC 2137). Any update requests received from hosts that are on the server's allowed list are honored. Dynamic updates allow the addition or deletion of resource records (RR) and RR sets from a specified zone.

By default, BIND 8.1 servers reject all dynamic update requests. This is a security mechanism that gives the zone administrator the ability to decide which hosts can submit dynamic updates. You specify the hosts from which a server will process requests by using the allow-update substatement. The allow-update substatement is applicable to a zone. You cannot specify this substatement as part of an options statement.

The syntax of the allow-update substatement is as follows:

allow-update { address_match_list } ;

The following example shows the use of the allow_update substatement:

zone "FRED.PARROT.BIRD.COM" in {
        type master;
        file "FRED_PARROT_BIRD_COM.DB";
        allow-update {
                      99.1.2.3;
                      99.4.5.6;
        }
}

IP addresses, IP prefixes, ACLs, and IP address match lists are all valid elements for the allow-update substatement.

When dynamic updates are sent to and accepted by a name server, the name server does the following:

• Adds the updates to (or deletes the updates from) the memory cache copy of the zone's resource records.
• Saves the updates to a transaction log file. The default name for this file is domain_name.DB_LOG.
• Scans the transaction log file once per hour and updates the domain_name.DB file with any transactions it finds by writing a new version of the domain_name.DB file to disk. This action does not preserve the formatting or comments that existed in the original domain_name.DB file. (See Section D.3.6.1 for solutions for preserving the formatting or comments in the original domain_name.DB file.)
• Renames the current transaction log file to domain_name.DB_LOG_BCK and then creates a new domain_name.DB_LOG file.

Typically, a system administrator adds comments to the domain_name.DB file to provide history and helpful information pertinent to the data in the file, and formats the file for easy reading. With DNS dynamic updates enabled, all comments, formatting, and ordering will be lost.

TCP/IP Services provides two methods to prevent this:

• You can use the DCL command DEFINE to define the logical TCPIP$BIND_DONT_MERGE_DYNAMIC_UPDATES. The presence of the logical turns off the merge of dynamic updates, and the server does not create new versions of the domain_name.DB.
• TCP/IP Services BIND server preserves the original domain_name.DB file that is read when the BIND server starts up. The server never deletes or purges the original database file.

The BIND server is able to detect a situation in which dynamic updates might be lost. When this happens, the server creates a new version of the domain_name.DB_LOG_BCK file containing the dynamic updates that would have been lost. The system administrator must review the transactions in the file and determine whether the updates are still valid and if so, manually apply the updates to the domain_name.DB file.

There is always at least one version of the domain_name.DB_LOG_BCK file when dynamic updates are enabled. Each time the BIND server detects lost updates, the server creates a new version of the domain_name.DB_LOG_BCK file. The existence of more than one of these files is a signal to the system administrator that manual merges might be necessary.

The server does not automatically purge the domain_name.DB_LOG_BCK files, but the system administrator can delete them after examining and applying their contents.

D.3.6.2 Manually Creating Updates

You can manually create updates to the domain database file using the command line utility NSUPDATE if the name server for the domain is configured to accept dynamic updates.

The format of the NSUPDATE command is:

NSUPDATE [ -d ] [ -v ] [ file-name ]

In this format:

Table D-10 shows the valid update commands for NSUPDATE .

NSUPDATE has two modes: interactive and noninteractive. In noninteractive mode, you supply the updates in a file. Data in the file must be in the following format:

category section name ttl type rdata

In this format:

The following example shows how to use NSUPDATE in the noninteractive mode.

$ TYPE NSUPD.TXT
update delete www.nads.zn.
update add www.nads.zn. 60 CNAME ivy18.nads.zn
$ NSUPDATE NSUPD.TXT

In interactive mode, you supply data in the format shown for noninteractive mode in response to each NSUPDATE prompt.

The following example shows how to use the NSUPDATE utility in interactive mode. The Resolver debug mode is enabled.

$ NSUPDATE
> UPDATE ADD WWW.NADS.ZN 60 IN CNAME IVY18.NADS.ZN
>
res_mkupdate: packet size = 49
;; res_send()
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 53349
;; flags:; ZONE: 1, PREREQUISITE: 0, UPDATE: 1, ADDITIONAL: 0
;;      nads.zn, type = SOA, class = IN
www.nads.zn.            1M IN CNAME     ivy18.nads.zn.
;; Querying server (# 1) address = 192.168.1.1
;; got answer:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 53349
;; flags: qr ra; ZONE: 0, PREREQUISITE: 0, UPDATE: 0, ADDITIONAL: 0

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 are 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 might not be the result you want.

5. Start up BIND by entering the following command:

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