HP OpenVMS Systems Documentation

Compaq TCP/IP Services for OpenVMS
Release Notes

Access to the dynamic update facility should be strictly limited. In earlier versions of BIND, the only way to do this was to include an IP address or network prefix in the allow-update zone option. This method is insecure because the source address of the update UDP packet is easily forged. Also, if the IP addresses allowed by the allow-update option include the address of a slave server that performs forwarding of dynamic updates, the master can be trivially attacked by sending the update to the slave, which will forward it to the master with its own source IP address. This causes the master to approve the update without question.

For these reasons, updates should be authenticated cryptographically by means of transaction signatures (TSIG). That is, the allow-update option should list only TSIG key names, not IP addresses or network prefixes. Alternatively, you can use the new update-policy option.

Some sites choose to keep all dynamically updated DNS data in a subdomain and to delegate that subdomain to a separate zone. This way, the top-level zone containing critical data, such as the IP addresses of public web and mail servers, need not allow dynamic updates at all.

For information about setting up dynamic updates, see Section C.5.7.

C.2.3 TSIG

This section describes how to set up Transaction Signatures (TSIG) transaction security in BIND. It describes changes to the configuration file as well as the changes that are required for different features, including the process of creating transaction keys and how to use transaction signatures with BIND.

BIND primarily supports TSIG for server-to-server communication. This includes zone transfer, notify, and recursive query messages.

TSIG is useful for dynamic updating. A primary server for a dynamic zone should use access control to control updates, but IP-based access control is insufficient. Key-based access control is far superior. To use TSIG with the nsupdate utility, specify either the -k or -y option on the NSUPDATE command line. For more information about using the nsupdate utility, see Section C.5.7.3.

Use the following procedure to implement TSIG:

1. Generate shared keys for each pair of hosts.
   You can generate shared keys automatically, or you can specify them manually. In the example that follows, a shared secret is generated to be shared between HOST1 and HOST2. The key name is host1-host2 . The key name must be the same on both hosts.
   Longer keys are better, but shorter keys are easier to read. The maximum key length is 512 bits; keys longer than that will be digested with MD5 to produce a 128-bit key. Use the dnssec-keygen utility to generate keys automatically.
   The following command generates a 128-bit (16-byte) HMAC-MD5 key:

   $ dnssec_keygen -a hmac-md5 -b 128 -n HOST host1-host2.

   
   In this example, the key is in the file KHOST1-HOST2.157-00000_PRIVATE. Nothing uses this file directly, but the base-64 encoded string following Key: can be extracted from the file and can be used as a shared secret. For example:

   Key: La/E5CjG9O+os1jq0a2jdA==

   
   The string La/E5CjG9O+os1jq0a2jdA== can be used as the shared secret.
   Keys can also be specified manually. The shared secret is a random sequence of bits, encoded in base-64. Most ASCII strings are valid base-64 strings (assuming the length is a multiple of 4 and that only valid characters are used).
2. Copy the shared secret to both hosts.
   Use a secure transport mechanism like a floppy disk, or a physically secure network, to copy the shared secret between hosts.
3. Inform the servers of the key's existence.
   In the following example, HOST1 and HOST2 are both servers. Add the following to each server's TCPIP$BIND.CONF file:

   key host1-host2. { algorithm hmac-md5; secret "La/E5CjG9O+os1jq0a2jdA=="; };

   
   The HMAC-MD5 algorithm is the only one supported by BIND. It is recommended that either TCPIP$BIND.CONF not be world readable, or that the key statement be added to a nonworld readable file that is included by TCPIP$BIND.CONF. For information about the key statement, see Section C.5.3.4.
   Once the configuration file is reloaded, the key is recognized. This means that if the server receives a message signed by this key, it can verify the signature. If the signature succeeds, the response is signed by the same key.
4. Instruct the server to use the key.
   Because keys are shared only between two hosts, the server must be told when keys are to be used. Add the following to the TCPIP$BIND.CONF file for HOST1. The IP address of HOST2 is 10.1.2.3.

   server 10.1.2.3 { keys { host1-host2. ;}; };

   
   Multiple keys can be present, but only the first is used. This statement does not contain any secrets, so you can include it in a world-readable file.
   If HOST1 sends a message that is a request to that address, the message will be signed with the specified key. HOST1 will expect any responses to signed messages to be signed with the same key.
   A similar statement must be present in HOST2's configuration file (with HOST1's address) for HOST2 to sign request messages to HOST1.
5. Implement TSIG key-based access control.
   You can specify TSIG keys in ACL definitions and in the following configuration options:
   • allow-query
   • allow-transfer
   • allow-update
   
   For the key named HOST1-HOST2., specify the following allow-update option:

   allow-update { key host1-host2. ;};

   
   This statement allows dynamic updates to succeed only if the request was signed by a key named HOST1-HOST2.
6. Reload the configuration file.
   Changes to the configuration file will not take effect until the configuration file is reloaded. You can use one of several methods to reload the configuration file:
   • The rndc utility
   • The TCP/IP management command SET NAME/INITIALIZE
   • Stopping and restarting the BIND server
7. Handle any errors.
   The processing of TSIG-signed messages can result in several types of errors. If a signed message is sent to a non-TSIG aware server, an error is returned because the server will not understand the record. This is a result of misconfiguration; the server must be configured explicitly to send a TSIG-signed message to a specific server.
   If a TSIG-aware server receives a message signed by an unknown key, the response is unsigned and an error is returned.
   If a TSIG-aware server receives a message with a signature that is not validated, the response is unsigned and an error is returned.
   If a TSIG aware server receives a message with a time outside of the allowed range, the response is signed, an error is returned, and the time values are adjusted so that the response can be successfully verified.

TKEY is a mechanism for automatically generating a shared secret between two hosts. There are several modes of TKEY that specify how the key is generated or assigned. BIND implements only the Diffie-Hellman key exchange. Both hosts are required to have a Diffie-Hellman KEY record (although this record is not required to be present in a zone). The TKEY process must use messages signed either by TSIG or SIG(0). The result of TKEY is a shared secret that can be used to sign messages with TSIG. TKEY can also be used to delete shared secrets that it had previously generated.

The TKEY process is initiated by a client or server by sending a signed TKEY query (including any appropriate KEYs) to a TKEY-aware server. The server response, if it indicates success, contains a TKEY record and any appropriate keys. After this exchange, both participants have enough information to determine the shared secret. When Diffie-Hellman keys are exchanged, the shared secret is derived by both participants.

C.2.5 SIG(0)

BIND Vers >C.3 Migrating from BIND Version 4 to BIND Version 9

If you set up your BIND environment using an old version of the TCP/IP Services product, you must convert the UCX databases and configuration information to the BIND Version 9 format.

To convert your BIND configuration, enter the following command:

TCPIP> CONVERT/CONFIGURATION BIND 

This command extracts the BIND-specific configuration information from UCX$CONFIGURATION.DAT and creates the BIND Version 9 configuration file TCPIP$BIND.CONF. It renames your BIND databases, where necessary.

You can continue to use the SET CONFIGURATION BIND commands to make changes to your configuration (see Section C.8), or you can make changes by editing the text file TCPIP$BIND.CONF (see Section C.5). If you continue to use the SET CONFIGURATION BIND commands, you must also enter the CONVERT/CONFIGURATION BIND command in order for your changes to take effect.

C.3.1 Navigating Two Different BIND Environments

This section summarizes the differences between the UCX BIND implementation and BIND Version 9.

Remember that, in BIND Version 9, name servers are configured by editing a text configuration file. The use of this file is described in Section C.5. Compaq recommends, but does not require, that you use the configuration file to set up BIND. You can continue using the TCPIP$CONFIG and the SET CONFIGURATION BIND commands to set up your BIND environment, as you did with previous releases of this product. The term UCX BIND in Table C-1 describes the previous configuration method even though this method is still valid in the current release.

Table C-1 describes changes to the database and configuration file names.

The BIND service can be shut down and started independently of TCP/IP Services. The following files are provided for this purpose:

• SYS$STARTUP:TCPIP$BIND_STARTUP.COM allows you to start the BIND service.
• SYS$STARTUP:TCPIP$BIND_SHUTDOWN.COM allows you to shut down the BIND service.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services.

• SYS$STARTUP:TCPIP$BIND_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the BIND service is started.
• SYS$STARTUP:TCPIP$BIND_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the BIND service is shut down.

This section describes how to configure the BIND name server on your local host.

BIND Version 9 configuration is broadly similar to BIND Version 8; however, there are a few new areas of configuration, such as views. BIND Version 8 configuration files should work with few alterations in BIND Version 9, although you should review more complex configurations to see whether they can be implemented more efficiently using the new features in BIND Version 9.

BIND Version 9 stores configuration information in a text file called TCPIP$BIND.CONF. The TCP/IP Services product provides a template for this file located in the SYS$SPECIFIC:[TCPIP$BIND] directory. Edit this template to reflect your site-specific configuration requirements before running BIND.

C.5.1 Configuration File Elements

Table C-2 lists the elements used throughout the BIND Version 9 configuration file documentation.

"my.test.domain"

"SYS$SPECIFIC:[TCPIP$BIND]"