HP TCP/IP Services for OpenVMS
Management

The zone name can optionally be followed by a class. If the class is not specified, class IN (for Internet) is assumed. This is correct for the vast majority of cases.

The hesiod class is named for an information service from MIT's Project Athena. It is used to share information about various systems databases, such as users, groups, printers, and so on. The keyword HS is a synonym for hesiod .

Another MIT development is CHAOSnet , a LAN protocol created in the mid-1970s. Zone data for CHAOSnet can be specified with the CH class.

6.5.3.11.3 Zone Options

Table 6-22 describes the options you can include in the zone statement.

Table 6-22 Zone Options

Option	Description
allow-notify	See the description of allow-notify in Section 6.5.3.7.4.
allow-query	See the description of allow-query in Section 6.5.3.7.4.
allow-transfer	See the description of allow-transfer in Section 6.5.3.7.4.
allow-update	Specifies which hosts are allowed to submit dynamic DNS updates for master zones. The default is to deny updates from all hosts. Note that allowing updates based on the requestor's IP address is insecure.
update-policy	Specifies an update policy, as described in Section 6.5.7.2.
allow-update-forwarding	See the description of allow-update-forwarding in Table 6-10.
also-notify	Meaningful only if notify is active for this zone. The set of machines that receives a NOTIFY message for this zone is made up of all the listed name servers (other than the primary master) for the zone, plus any IP addresses specified with the also-notify statement. A port can be specified with each also-notify address to send the notify messages to a port other than the default of 53. also-notify is not meaningful for stub zones. The default is the empty list.
check-names	This option is used to restrict the character set and syntax of certain domain names in master files and/or DNS responses received from the network. The default varies according to zone type. For master zones the default is fail. For slave zones the default is warn.
database	Specifies the type of database to be used for storing the zone data. The string following the database keyword is interpreted as a list of space-delimited words. The first word identifies the database type; any subsequent words are passed as arguments to the database to be interpreted in a way specific to the database type. The default is rbt , the native database used by BIND 9. This database does not take arguments.
dialup	See the description of the dialup option in Section 6.5.3.7.1.
delegation-only	The flag only applies to hint and stub zones. If set to yes then the zone will also be treated as if it is also a delegation-only type zone.
forward	Meaningful only if the zone has a forwarders list. The only keyword causes the lookup to fail after trying the forwarders and getting no answer. The first keyword allows attempts at normal lookups.
forwarders	Overrides the list of global forwarders. If the zone type is not forward , forwarding is not done for the zone, and the global options are not used.
ixfr-base	This option was used in BIND 8 to specify the name of the transaction log (journal) file for dynamic update and IXFR. BIND 9 ignores this option and constructs the name of the journal file by appending _JNL to the name of the zone file.
ixfr-tmp-file	An undocumented option in BIND 8. Ignored in BIND 9.
masters	Specifies one or more IP addresses of master servers that the slave contacts to update its copy of the zone. By default, transfers are made from port 53 on the servers; this can be changed for all servers by specifying a port number before the list of IP addresses, or on a per-server basis after the IP address. Authentication to the master can also be done with per-server TSIG keys. If a file is specified, then the replica is written to this file whenever the zone is changed and is reloaded from this file on a server restart. Use of a file is recommended because it often speeds server startup and eliminates a waste of bandwidth.
max-transfer-time-in	See the description of max-transfer-time-in in Section 6.5.3.7.7.
max-transfer-idle-in	See the description of max-transfer-idle-in in Section 6.5.3.7.7.
max-transfer-time-out	See the description of max-transfer-time-out in Section 6.5.3.7.7.
max-transfer-idle-out	See the description of max-transfer-idle-out in Section 6.5.3.7.7.
notify	See the description of notify in Section 6.5.3.7.
pubkey	In BIND Version 8, this option was used for specifying a public zone key for verification of signatures in DNSSEC-signed zones when they are loaded from disk. BIND Version 9 does not verify signatures on loading and ignores the option.
zone-statistics	If YES, the server keeps statistical information for this zone, which can be dumped to the statistics file defined in the server options. See Section 6.5.3.7.
sig-validity-interval	See the description of sig-validity-interval in Section 6.5.3.7.14.
transfer-source	See the description of transfer-source in Section 6.5.3.7.7.
transfer-source-v6	See the description of transfer-source-v6 in Section 6.5.3.7.7.
alt-transfer-source	See the description of alt-transfer-source in Table 6-13.
alt-transfer-source-v6	See the description of alt-transfer-source-v6 in Table 6-13.
use-alt-transfer-source	See the description of use-alt-transfer-source in Table 6-13.
notify-source	See the description of notify-source in Section 6.5.3.7.7.
notify-source-v6	See the description of notify-source-v6 in Section 6.5.3.7.7.
min-refresh-time max-refresh-time min-retry-time max-retry-time	See the descriptions of these options in Section 6.5.3.7.14.
ixfr-from-differences	See the description of ixfr-from-differences in Table 6-7.
key-directory	See the description of key-directory in Table 6-7.
multi-master	See the description of multi-master in Table 6-7.

6.5.4 IPv6 Support in BIND Version 9

BIND supports all forms of IPv6 name-to-address and address-to-name lookups. It also uses IPv6 addresses to make queries when running on an IPv6-capable system. For information about configuring the BIND server for IPv6, see the HP TCP/IP Services for OpenVMS Guide to IPv6.

For forward lookups, BIND 9 supports only AAAA records. The use of A6 records is deprecated by RFC 3363, and the support for forward lookups in BIND 9 is removed accordingly. However, authoritative BIND 9 name servers still load zone files containing A6 records correctly, answer queries for A6 records, and accept zone transfer for a zone containing A6 records.

For IPv6 reverse lookups, BIND 9 supports the traditional "nibble" format used in the ip6.arpa domain, as well as the older, deprecated ip6.int domain. BIND 9 formerly supported the "binary label" (also known as "bitstring") format. The support of binary labels, however, is now completely removed according to the changes in RFC 3363. Any applications in BIND 9 do not understand the format any more, and will return an error if given. In particular, an authoritative BIND 9 name server rejects to load a zone file containing binary labels.

6.5.4.1 Address Lookups Using AAAA Records

The AAAA record is a parallel to the IPv4 A record. It specifies the entire address in a single record. For example:

$ORIGIN example.com. host 3600 IN AAAA 3ffe:8050:201:1860:42::1

6.5.4.2 Address-to-Name Lookups Using Nibble Format

As in IPv4, when looking up an address in nibble format, the address components are simply reversed and ip6.arpa. is appended to the resulting name. For example, the following provides reverse name lookup for a host with address 3ffe:8050:201:1860:42::1:

$ORIGIN 0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.arpa. 1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0 14400 IN PTR host.example.com.

6.5.5 DNS Notify

DNS Notify allows master name servers to notify their slave servers of changes to a zone's data. In response to a NOTIFY message from a master server, the slave checks to see whether its version of the zone is the current version. If it is not, the slave initiates a transfer. For more information, see the description of the notify option in Table 6-7.

6.5.6 Incremental Zone Transfers (IXFR)

The incremental zone transfer (IXFR) protocol is a way for slave servers to transfer only changed data instead of having to transfer the entire zone. The IXFR protocol is documented in RFC 1995.

When acting as a master, BIND Version 9 supports IXFR for those zones in which the necessary change history information is available. These include master zones maintained by dynamic update and slave zones whose data was obtained by IXFR. For manually maintained master zones, and for slave zones obtained by performing a full zone transfer (AXFR), IXFR is supported only if the option ixfr-from-differences is set to yes.

When acting as a slave, BIND attempts to use IXFR unless it is explicitly disabled. For more information about disabling IXFR, see the description of the request-ixfr clause of the server statement in Section 6.5.3.8.

6.5.7 Dynamic Updates

With dynamic updates, the BIND server can add, modify, or delete records or RRsets in the master zone files.

Dynamic updating is enabled on a zone-by-zone basis by including an allow-update or update-policy clause in the zone statement. Dynamic updating is described in RFC 2136.

Updating of secure zones (zones using DNSSEC) is presented in RFC 3007. RRSIG and NSEC records affected by updates are automatically regenerated by the server using an online zone key. Update authorization is based on transaction signatures and an explicit server policy.

6.5.7.1 The Journal File

All changes made to a zone using dynamic update are stored in the zone's journal file. This file is automatically created by the server when the first dynamic update takes place. The name of the journal file is formed by appending _JNL to the name of the corresponding zone file. The journal file is in a binary format and should not be edited manually.

The server also occasionally writes (or "dumps") the complete contents of the updated zone to its zone file. This is not done immediately after each dynamic update; that would be too slow when a large zone is updated frequently. Instead, the dump is delayed by up to 15 minutes, allowing additional updates to take place.

When a server is restarted after a shutdown or failure, it replays the journal file to incorporate into the zone any updates that took place after the last zone dump. Changes that result from incoming incremental zone transfers are journaled in a similar way.

The zone files of dynamic zones should not be edited because they are not guaranteed to contain the most recent dynamic changes---those are only in the journal file.

If you have to make changes to a dynamic zone manually, use the following procedure:

1. Disable dynamic updates to the zone using the following command:

   $ rndc freeze zone

   
   This will also remove the zone's .jnl file and update the master file.

2. Edit the zone file.
3. Reload the changed zone and re-enable dynamic updates using the following command:

   $ rndc unfreeze zone

Removing the _JNL file is necessary because the manual edits are not present in the journal, rendering it inconsistent with the contents of the zone file.

6.5.7.2 Dynamic Update Policies

BIND Version 9 supports two methods of granting clients the right to perform dynamic updates to a zone. You can configure them using either the allow-update option or the update-policy option.

The allow-update clause works the same way as in previous versions of BIND. It grants given clients the permission to update any record of any name in the zone.

The update-policy clause is new in BIND 9 and allows more fine-grained control over what updates are allowed. A set of rules is specified, where each rule either grants or denies permissions for one or more names to be updated by one or more identities. The rules apply to master zones only.

The update-policy statement only examines the signer of a message; the source address is not relevant. If the dynamic update request message is signed (that is, it includes either a TSIG or SIG(0) record), the identity of the signer can be determined.

If an allow-update statement appears when the update-policy statement is present, a configuration error occurs.

Use the following format to define rules:

( grant | deny ) identity nametype name [ types ]

Each rule grants or denies privileges. Once a message has successfully matched a rule, the operation is immediately granted or denied and no further rules are examined. A rule is matched when the signer matches the identity field, the name matches the name field in accordance with the nametype field, and the type matches the types specified in the type field.

The rule definition includes the following fields:

• grant or deny specifies whether to grant or deny privileges.
• identity specifies the signer of the message. Use a name or a wildcard in the identity field. Normally, this is the name of the TSIG or SIG(0) key used to sign the update request. When a TKEY exchange has been used to create a shared secret, the identity of the shared secret is the same as the identity of the key used to authenticate the TKEY exchange. When the identity field specifies a wildcard name, it is subject to DNS wildcard expansion, so the rule will apply to multiple identities. The identity field must contain a fully qualified domain name.
• name specifies the name to be updated.
• nametype specifies one of the following:
  • name, exact-match semantics. This rule matches when the name being updated is identical to the contents of the name field.
  • subdomain , which matches when the name being updated is a subdomain of, or identical to, the contents of the name field.
  • wildcard , the name field is subject to DNS wildcard expansion, and this rule matches when the name being updated name is a valid expansion of the wildcard.
  • self , which matches when the name being updated matches the contents of the identity field. The name field is ignored, but should be the same as the identity field. The self nametype is most useful when allowing using one key per name to update, where the key has the same name as the name to be updated. The identity would be specified as * in this case.
    In all cases, the name field must specify a fully qualified domain name.
  • types specifies the types of resource records.
  
  If no types are specified, the rule matches all types except RRSIG, NS, SOA, and NSEC. Types can be specified by name, including ANY. ANY matches all types except NXT, which can never be updated.

If the name server for the domain is configured to accept dynamic updates, you can manually create updates to the domain database file using the nsupdate utility.

You start the utility using the NSUPDATE command, which is defined when you run the TCPIP$DEFINE_COMMANDS.COM procedure.

You can enter commands to the nsupdate utility interactively, or you can specify a file that contains nsupdate commands.

Transaction signatures can be used to authenticate update requests, as described in Section 6.2.3. Signatures rely on a shared secret that should be known to only the nsupdate utility and the name server. TSIG uses the HMAC-MD5 encryption algorithm. It is important to specify the encryption algorithm because additional algorithms will be made available in the future. Use the appropriate configuration options in the server and key statements in TCPIP$BIND.CONF to ensure the name server associates the secret key and algorithm with the IP address of the client application that uses TSIG authentication. The nsupdate utility does not read the TCPIP$BIND.CONF file.

6.5.8 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 that acts as a BIND master server.

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.
   1. Configure the node as a master server.
   2. Add or edit the options statement. The directory substatement should be as follows:

      options { directory "TCPIP$BIND_COMMON:[TCPIP$BIND]"; };

   
   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. In the next step, the setup command procedure prompts you 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], where common_device is generated automatically 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$MANAGER: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$MANAGER:TCPIP$BIND_COMMON_STARTUP.COM
   • SYS$MANAGER:TCPIP$BIND_COMMON_SHUTDOWN.COM
   
   These files define the BIND system logicals and accounting information. To remove the failover setup from your system, first shut down the BIND server by using the TCPIP$BIND_SHUTDOWN.COM command procedure, then delete these two files.
4. Place any database files to be shared in the common directory.

   Note Remove from SYS$SPECIFIC:[TCPIP$BIND] any databases that are to be shared. Using the search list logical, BIND finds any SYS$SPECIFIC:[TCPIP$BIND] databases first and uses those. This might not be the result you want.

5. Start up BIND by entering the following command:

   $ @SYS$MANAGER:TCPIP$BIND_STARTUP.COM

6. Configure the resolver on clients to point to the DNS master servers. You can accomplish this by listing each one. For example, issue the following command:

   TCPIP> SET NAME /SYSTEM /SERVER=(master1, master2)

   
   For master1 and master2, you can specify a node name or an IP address. For further redundancy, master1 and master2 may be a failSAFE IP address.