HP OpenVMS Systems Documentation

Content starts here HP TCP/IP Services for OpenVMS

HP TCP/IP Services for OpenVMS
Management


Previous Contents Index

D.3.2.9 Periodic Task Intervals

Table D-9 describes the periodic task options.

Table D-9 BIND 8 - Periodic Task Options
Option Description
cleaning-interval The server removes expired resource records from the cache every cleaning-interval minutes. The default is 60 minutes. If set to 0, no periodic cleaning occurs.
interface-interval The server scans the network interface list every interface-interval minutes to see if interfaces have been added or deleted. The default is 60 minutes. If set to 0, only interface scanning occurs when the configuration file is loaded. After the scan, listeners are started on any new interfaces (provided they are allowed by the listen-on configuration). Listeners are deleted for any interface that has gone away.
statistics-interval Name-server statistics are logged every statistics-interval minutes. The default is 60. If set to 0, no statistics are logged.

D.3.2.10 Topology

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

D.3.3 BIND Configuration Server Statement

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

D.3.3.1 Limiting the Number of Transfers

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.

Example D-7 BIND 8 - Server Statement

   server 16.168.1.2 {
           transfers 3
   };

D.3.3.2 Efficient Zone Transfers

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.

Example D-8 BIND 8 - Server Statement

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

D.3.4 BIND Configuration Zone Statement

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

D.3.5 Address Match Lists and ACLs

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.

D.3.6.1 Preserving the Zone 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:

-d Specifies debug mode.
-v Specifies that NSUPDATE uses the TCP protocol instead of the UDP protocol.
file-name Specifies a file name containing update requests and entries.

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

Table D-10 NSUPDATE Commands
Command Description
prereq yxrset domain_name type [ rdata] Makes the presence of an RR set of type owned by domain_name a prerequisite to performing the update.
prereq nxrrset Makes the nonexistence of an RR set of type owned by domain_name a prerequisite to performing the update specified in successive update commands.
prereq yxdomain domain_name Makes the existence of the specified domain_name a prerequisite to performing the update.
prereq nxdomain Makes the nonexistence of the specified domain name a prerequisite to performing the update
update delete domain_name [ type] [ rdata] Deletes the specified domain name, or, if type is also specified, deletes the specified RR set, or, if rdata is also specified, deletes the record matching domain_name, type, and rdata.
update add domain_name ttl [ class] type rdata Adds the specified record to the zone. Note that the TTL, in addition to the type and resource-record-specific data, must be included but class is optional and defaults to IN.
quit Sends the accumulated commands as one dynamic DNS update request to the name server. Be sure to enter a blank line before you enter the quit command.

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:

category Is any one of the following opcodes: update , zone , prereq .
section Is any one of the following opcodes: add , delete , nxdomain , yxdomain , nxrrset , yxrrset .
name Is the name of the entry being added.
ttl Is time to live (in seconds) for this entry. After this time period, the name server will no longer serve the entry.
type Specifies the RR type (for example, A, CNAME, NS, MX, TXT).
rdata Specifies the data appropriate for the RR type being updated.

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

Note

When entering data in interactive mode, entering a blank line and then pressing Return (or Enter) signals the end of the input. NSUPDATE then processes all update entries in one operation.

D.3.7 Configuring Cluster Failover and Redundancy

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
    

Caution

The use of dynamic updates in conjunction with a master BIND server participating in cluster failover and redundancy is not supported and might cause serious problems.


Previous Next Contents Index