HP OpenVMS Systems Documentation

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.

6.2.5 SIG(0)

BIND Version 9 partially supports DNSSEC SIG(0) transaction signatures (as specified in RFC 2535).

SIG(0) uses public and private keys to authenticate messages. Access control is performed in the same manner as TSIG keys; privileges can be granted or denied based on the key name. When a SIG(0) signed message is received, it is verified only if the key is known and trusted by the server; the server does not attempt to locate and validate the key.

SIG(0) signing of multiple-message TCP streams is not supported. BIND Version 9 does not include any tools that generate SIG(0) signed messages.

6.2.6 DNSSEC

Cryptographic authentication of DNS information is implemented using the DNS Security (DNSSEC) extensions (defined in RFC 2535). This section describes how to create and use DNSSEC signed zones.

BIND Version 9 provides several tools that are used in the process of creating and using DNSSEC signed zones. These tools include:

• The dnssec_keygen utility, which generates keys for DNSSEC (secure DNS) and TSIG (transaction signatures).
• The dnssec_makekeyset utility, which generates a key set.
• The dnssec_signkey utility, which signs a key set.
• The dnssec_signzone utility, which signs a zone.

For detailed information about these utilities, see Section 6.10. In all cases, the -h option displays a full list of parameters. Note that the DNSSEC tools require the keyset and signedkey files to be in the working directory.

Administrators of the parent and child zones must agree on keys and signatures. A zone's security status must be indicated by the parent zone for a DNSSEC-capable resolver to trust its data.

For other servers to trust data in this zone, they must be statically configured either with this zone's zone key or with the zone key of another zone above this one in the DNS tree.

Use the following procedure to set up DNSSEC secure zones:

1. Generate keys.
   To generate keys, use the dnssec_keygen program.
   A secure zone must contain one or more zone keys. The zone keys sign all other records in the zone, as well as the zone keys of any secure delegated zones. Zone keys must have the same name as the zone, must have a name type of ZONE, and must be usable for authentication.
   The following command generates a 768-bit DSA key for the child.example zone:

   $ dnssec_keygen -a DSA -b 768 -n ZONE child.example.

   
   Two output files are produced: KCHILD_EXAMPLE.003-12345_KEY and KCHILD_EXAMPLE.003-12345_PRIVATE (where 12345 is the key tag). The key file names contain the key name ( child_example. ), the algorithm (3 is DSA, 1 is RSA), and the key tag (12345, in this case). The private key (in the _PRIVATE file) is used to generate signatures, and the public key (in the _KEY file) is used verify signatures.
   To generate another key with the same properties (but with a different key tag), repeat the preceding command.
   Insert the public keys into the zone file using $INCLUDE statements that specify the _KEY files.
2. Create a key set.
   To create a key set from one or more keys, use the dnssec_makekeyset utility.
   After the zone keys are generated, a key set must be built for transmission to the administrator of the parent zone, so that the parent zone can sign the keys with its own zone key and indicate correctly the security status of this zone. When building a key set, the list of keys to be included and the TTL value of the set must be specified; the desired signature validity period of the parent's signature can also be specified.
   The list of keys to be inserted into the key set can also include nonzone keys present at the top of the zone.
   The following command generates a key set containing the key generated in the preceding example and another key similarly generated, with a TTL of 3600 and a signature validity period of 10 days starting from now:

   $ dnssec_makekeyset -t 3600 -e +864000 KCHILD_EXAMPLE.003-12345 - _$ KCHILD_EXAMPLE.003-23456

   
   One output file is produced: KEYSET-CHILD_EXAMPLE.DAT. This file should be transmitted to the parent to be signed. It includes the keys as well as signatures covering keys. The signatures prove that you have the private key that corresponds to the public key. The signatures also have the validity period encoded in them.
3. Sign the child's keyset.
   To sign one child's keyset, use the dnssec_signkey utility.
   If the child.example zone has any delegations which are secure (for example, grand.child.example ), the child.example administrator should receive keyset files for each secure subzone. These keys must be signed by this zone's zone keys.
   The following command signs the child's key set with the zone keys:

   $ dnssec_signkey KEYSET-GRAND_CHILD_EXAMPLE.DAT KCHILD_EXAMPLE.003-12345 - _$ KCHILD_EXAMPLE.003-23456

   
   One output file is produced: SIGNEDKEY-GRAND_CHILD_EXAMPLE.DAT. This file should be both transmitted back to the child and retained. It includes all keys (the child's keys) from the keyset file and signatures generated by this zone's zone keys.
4. Sign the zone.
   To sign a zone, use the dnssec_signzone utility.
   Any signed key files corresponding to secure subzones should be present, as well as a signed key file for this zone generated by the parent (if there is one). The zone signer generates NXT and SIG records for the zone, incorporates the zone key signature from the parent, and indicates the security status at all delegation points.
   Before signing the zone, add the KEY record to the zone database file using the $INCLUDE statement. For example:

   $INCLUDE KCHILD_EXAMPLE.003-12345_KEY

   
   The following command signs the zone, assuming it is in a file called ZONE_CHILD_EXAMPLE.DB. By default, all zone keys that have an available private key are used to generate signatures.

   $ dnssec_signzone -o child.example ZONE_CHILD_EXAMPLE.DB

   
   One output file is produced: ZONE_CHILD_EXAMPLE.DB_SIGNED. This file should be referenced by TCPIP$BIND.CONF as the input file for the zone.
5. Configure the servers.
   Unlike BIND Version 8, data is not verified when the BIND Version 9 software is loaded. Therefore, zone keys for authoritative zones do not need to be specified in the configuration file. The public key for any security root must be present in the configuration file's trusted-keys statement, as described in Section 6.5.

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 6.8), or you can make changes by editing the text file TCPIP$BIND.CONF (see Section 6.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.

6.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 6.5. HP 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 6-1 describes the previous configuration method even though this method is still valid in the current release.

Table 6-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 in the SYS$SPECIFIC:[TCPIP$BIND] directory. Before starting BIND, edit this template to reflect your site-specific configuration requirements.

6.5.1 Configuration File Elements

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

"my.test.domain"

"SYS$SPECIFIC:[TCPIP$BIND]"

Address match lists are used primarily to determine access control for server operations. They are also used to define priorities for querying other name servers and to set the addresses on which the BIND server listens for queries. The following example shows the syntax of the address match list:

address_match_list = address_match_list_element ;
  [ address_match_list_element; ... ]
address_match_list_element = [ ! ] (ip_address [/length] |
   key key_id | acl_name | { address_match_list } )

The elements that constitute an address match list can be any of the following:

• An IP address (IPv4 or IPv6)
• An IP prefix (in the / notation)
• A key ID, as defined by the key statement
• The name of an address match list previously defined with the acl statement
• A nested address match list enclosed in braces

Elements can be negated with a leading exclamation mark (!). The match list names any , none , localhost , and localnets are predefined. More information on those names can be found in the description of the acl statement (see Section 6.5.3.1).

When a given IP address or prefix is compared to an address match list, the list is traversed in order until an element matches. The interpretation of a match depends on whether the list is being used for access control, defining listen-on ports, or as a topology, and whether the element was negated. Specifically:

• 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 following options use address match lists for this purpose:
  • allow-notify
  • allow-query
  • allow-transfer
  • allow-update
  • blackhole
  
  The listen-on option causes the server not to accept queries on any of the machine's addresses that do not match the list.
• When used with the topology statement, a nonnegated 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 between it 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 nonnegated 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 is negated. For example, in 1.2.3/24; ! 1.2.3.13; , the 1.2.3.13 element is ignored, because the algorithm will match any lookup for 1.2.3.13 to the 1.2.3/24 element. Using ! 1.2.3.13; 1.2.3/24 corrects that problem by having 1.2.3.13 blocked by the negation, while all other 1.2.3.* hosts fall through.

6.5.3 Configuration File Format

A BIND configuration file consists of statements and comments. Statements end with a semicolon. Many statements contain a block of substatements that also end with a semicolon. Table 6-3 describes the configuration statements.

The following sample is a configuration file for a master server:

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

zone "FRED.PARROT.BIRD.COM" in {
        type master;
        file "FRED_PARROT_BIRD_COM.DB";
};


zone "0.0.127.IN-ADDR.ARPA" in {
        type master;
        file "127_0_0.DB";
};

zone "LOCALHOST" in {
        type master;
        file "LOCALHOST.DB";
};

zone "208.20.16.IN-ADDR.ARPA" in {
        type master;
        file "208_20_16_IN-ADDR_ARPA.DB";
};

zone "." in {
        type hint;
        file "ROOT.HINT";
};

The following comment styles are valid in a BIND configuration file. Comments can appear anywhere in the file.

• C-style comments that start with /* and end with */
• C++ style comments that start with // and continue to the end of the physical line
• Shell or Perl-style comments that start with # and continue to the end of the physical line