# Compaq TCP/IP Services for OpenVMS
Management

Previous | Contents | Index

### 5.3.2.5 Access Control

Access to the server can be restricted based on the IP address of the requesting system. Table 5-7 describes the access control options.

Table 5-7 Access Control Options
Option | Description
--- | ---
`allow-query` | Specifies which hosts are allowed to ask ordinary questions. The `allow-query` option can also be specified in the zone statement, in which case it overrides the option `allow-query` statement. If not specified, the default is to allow queries from all hosts.
`allow-transfer` | Specifies which hosts are allowed to receive zone transfers from the server. The `allow-transfer` option can also be specified in the zone statement, in which case it overrides the option `allow-transfer` statement. If not specified, the default is to allow transfers from all hosts.

Example 5-5 shows how to specify an `options` statement to control access to the server.

Example 5-5 Access Control Options

    options {
     allow-query { any; } ;
     allow-transfer {
           1.2.3/24;
          5.6.7.8;
     };
    };

### 5.3.2.6 Interfaces

The interfaces and ports from which the server answers queries can be specified using the `listen-on` option. The `listen-on` option takes an optional port and an `address_match_list` . The server listens on all interfaces allowed by the address match list. All queries must be directed to the interface and port number specified on the `listen-on` statement. If a port is not specified, the server uses port 53.

Multiple `listen-on` statements are allowed. For example,

        listen-on { 5.6.7.8; };
        listen-on port 1234 { !1.2.3.4; 1.2/16; };

If a `listen-on` option is not specified, the server listens on port 53 on all interfaces.

### 5.3.2.7 Query Address

If the server does not know the answer to a question, it queries other name servers. The `query-source` option specifies the source address and source port used for such queries. If the address is an asterisk (*) or is omitted, the server uses a wildcard IP address (INADDR_ANY). If the port is an asterisk (*) or is omitted, the server uses a random unprivileged port. The default `query-source` statement is as follows:

        query-source address * port *;

The `query-source` option currently applies only to UDP queries; TCP queries always use a wildcard IP address and a random unprivileged port.

### 5.3.2.8 Zone Transfers

Table 5-8 describes the zone transfer options.

Table 5-8 Zone Transfer Options
Option | Description
--- | ---
`max-transfer-time-in` | Inbound zone transfers (BIND_SERVER_XFER processes) running longer than this many minutes are terminated. The default is 120 minutes (2 hours).
`transfer-format` | The server supports two zone transfer methods. The `one-answer` method uses one DNS message per resource record transferred. The `many-answers` method packs as many resource records as possible into a message. The `many-answers` method is more efficient, but it is understood only by BIND 8.1 and patched versions of BIND 4.9.5. The default is `one-answer` . The `transfer-format` option can be overridden on a per-server basis by using the server statement.
`transfers-in` | The maximum number of inbound zone transfers that can be running concurrently. The default value is 10. Increasing `transfers-in` can speed the convergence of slave zones, but can also increase the load on the local system.
`transfers-per-ns` | The maximum number of inbound zone transfers (BIND_SERVER_XFER processes) that can be concurrently transferring from a given remote name server. The default value is 2. Increasing `transfers-per-ns` can speed the convergence of slave zones, but it can also increase the load on the remote name server. `transfers-per-ns` can be overridden on a per-server basis by using the transfers phrase of the `server` statement.

Example 5-6 shows how to specify an `options` statement to control zone transfers.

Example 5-6 Zone Transfer Options

    options {
     max-transfer-time-in 120;
     transfer-format  one-answer;
     transfers-in  10;
     transfers-per-ns 2;
    };

### 5.3.2.9 Periodic Task Intervals

Table 5-9 describes the periodic task options.

Table 5-9 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.

### 5.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; };

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

### 5.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 5-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 5-7 Server Statement

       server 16.168.1.2 {
               transfers 3
       };

### 5.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 5-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 5-8 Server Statement

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

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

## 5.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.

## 5.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 5.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.

### 5.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 may 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.

### 5.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 5-10 shows the valid update commands for `NSUPDATE` .

Table 5-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.

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:

    class section name ttl type rdata

In this format:

class | 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, pressing Return (or Enter) with no data assumes the end of the input. NSUPDATE then processes all update entries in one operation.

Previous | Next | Contents | Index