HP TCP/IP Services for OpenVMS
Management
Previous Contents Index

6.1.2.3 Caching-Only Servers

Caching-only servers get the answers to all name service queries from other name servers. Once a caching server receives an answer to a query, it saves the information and uses it in the future to answer queries itself. Most name servers cache answers and use them in this way but a caching-only server depends on this for all its server information. It does not keep name server database files as other servers do. Caching-only servers are nonauthoritative, which means that their information is secondhand and can be incomplete.

Caching-only servers require a hint file and loopback files.

6.1.2.4 Forwarder Servers

The forwarding facility can be used to create a large, sitewide cache on a few servers, thereby reducing traffic over links to external name servers. Forwarder servers process requests that slave servers cannot resolve locally (for example, because they do not have access to the Internet).

Forwarding occurs on only those queries for which the server is not authoritative and for which it does not have the answer in its cache.

A master or slave server specifies a particular host to which requests outside the local zone are sent. This is a form of Internet courtesy that limits the number of hosts that actually communicate with the root servers listed in the ROOT.HINT file.

If you configure a forwarder server, you must provide the name of the host to which requests outside your zones of authority are forwarded.

6.2 Security Considerations

BIND Version 9 provides the following security enhancements:

6.2.1 Access Control Lists

Access control lists (ACLs) are address match lists that you can set up and name for use in configuring the following options:

Using ACLs, you can control who can access your name server without cluttering your configuration files with huge lists of IP addresses.

It is a good idea to use ACLs and to control access to your server. Limiting access to your server by outside parties can help prevent unwanted use of your server.

Here is an example of how to apply ACLs properly: 


// Set up an ACL named "bogusnets" that will block RFC1918 space, 
// which is commonly used in spoofing attacks. 
acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 
  224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; 
}; 
// Set up an ACL called our-nets. Replace this with the real IP numbers. 
acl our-nets { x.x.x.x/24; x.x.x.x/21; }; 
options { 
  ... 
  ... 
  allow-query { our-nets; }; 
  allow-recursion { our-nets; }; 
  ... 
  blackhole { bogusnets; }; 
  ... 
}; 
zone "example.com" { 
  type master; 
  file "example_com.db"; 
  allow-query { any; }; 
};

This example allows recursive queries of the server from the outside, unless recursion has been previously disabled. For more information about how to use ACLs to protect your server, see Section 6.5.2.

6.2.2 Dynamic Update Security

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 6.5.7.

6.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. The cryptographic access control provided by TSIG 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 6.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 6.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 is successfully verified, 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:
    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:
  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.

6.2.4 TKEY

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 9 partially supports DNSSEC SIG(0) transaction signatures as specified in RFC 2535 and RFC2931.

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. The only tool shipped with BIND Version 9 that generates SIG(0) signed messages is nsupdate.

6.2.6 DNSSEC

Cryptographic authentication of DNS information is implemented using the DNS Security (DNSSEC) extensions (defined in RFC's 4033, 4034, 4035).

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

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 files to be in the working directory.

Note
The tools shipped with TCP/IP Services V5.5 and earlier are not compatible with the current ones.

There must be communication with the administrators of the parent and/or child zone to transmit keys. A zone's security status must be indicated by the parent zone for a DNSSEC-capable resolver to trust its data. This is done through the presence or absence of a DS record at the delegation

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 RSAMD5, 5 is RSASHA1), 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 to verify signatures.
    To generate another key with the same properties (but with a different key tag), repeat the preceding command.
    It is good practice to use zone-signing keys (ZSK) as well as key-signing keys (KSK). The key-signing keys are usually the first keys from your zone that are used to build a chain of authority to the data that needs to be validated. Therefore, these keys are often called a secure entry point (SEP) key. These SEP keys are the ones that you should exchange with your parents or that verifying resolvers configure as their trust anchors. Create keys with the SEP bit set by specifying the -f KSK flag: 


    $dnssec_keygen -f KSK -a RSASHA1 -b 768 -n ZONE child.example

    Insert the public ZSK and KSK keys into the zone file using $INCLUDE statements that specify the _KEY files. For example, in the ZONE_CHILD_EXAMPLE.DB file add the following two lines: 


    $INCLUDE KCHILD_EXAMPLE.005-39677_KEY 
$INCULDE KCHILD_EXAMPLE.005-39678_KEY

    where
    KCHILD_EXAMPLE.005-39677_KEY is the public file containing the ZSK and KCHILD_EXAMPLE.005-39678_KEY is the public file containing the KSK.

  2. Sign the zone.
    To sign a zone, use the dnssec_signzone utility.
    Any keyset files corresponding to secure subzones should be present. The zone signer will generate NSEC and RRSIG records for the zone, as well as DS for the child zones if -d is specified. If -d is not specified then DS RRsets for the secure child zones need to be added manually.
    The following command signs the zone, assuming it is in a file called ZONE_CHILD_EXAMPLE.DB. 


    $ dnssec_signzone -o child.example -k KCHILD_EXAMPLE.005-39678_KEY 
ZONE_CHILD_EXAMPLE.DB KCHILD_EXAMPLE.005-39677_KEY

    Above, -o specifies the zone origin, -k specifies the file containing the KSK, followed by the name of the zone database, then the file containing the ZSK.
    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.
    dnssec_signzone will also produce a keyset and dsset files and optionally a dlvset file. These are used to provide the parent zone administrators with the DNSKEYs (or their corresponding DS records) that are the secure entry point to the zone.

  3. Configure the servers.
    Unlike BIND Version 8, signatures are 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 , as described in Section 6.5.

6.2.6.1 DNSSEC Restrictions

BIND Version 9 has the following restrictions when using DNSSEC:

6.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 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.

Previous Next Contents Index