[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here HP TCP/IP Services for OpenVMS

HP TCP/IP Services for OpenVMS
Management


Previous Contents Index

5.3.5 Guidelines for Configuring failSAFE IP

This section describes guidelines that can help avoid common pitfalls in configuring failSAFE IP.

5.3.5.1 Validating failSAFE IP

Most contemporary networks are highly stable and rarely suffer from the problems that require failSAFE IP. Consequently, on the few occasions where failSAFE IP is required, it is critical that the service be validated in the environment where it is being deployed. Failure to do this can result in unexpected problems at the critical moment.

Since real failures are rare and sometimes difficult to simulate, the logical name TCPIP$FAILSAFE_FAILED_ifname is provided. After configuring failSAFE IP addresses and starting the failSAFE IP service, validate the configuration using the following procedure:

  1. Establish connections and generate IP traffic.
    Using TELNET or FTP, create incoming and outgoing TCP connections to the multihomed host from inside and outside the subnet. Verify that these connections are established by using the following commands:


    $ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM
    $ ifconfig -a  ! Check the interface addresses
    $ netstat -nr  ! Check the routing table
    $ netstat -n   ! identify which interfaces are being used
    
  2. Simulate a failure and observe.
    Simulate a failure and observe OPCOM and log file messages. Use the following command to simulate a failure:


    $ DEFINE/SYSTEM TCPIP$FAILSAFE_FAILED_ifname 1  ! or disconnect the cable
    

    Wait long enough for failover to occur, which is signaled by OPCOM messages. Then observe the effects of failover and verify that TCP connections are still established and can transfer data. For example, TELNET sessions should respond to keyboard input.
    Use the following commands to see how IP addresses and routing have changed:


    $ ifconfig -a  ! Observe how the addresses have migrated
    $ netstat -nr  ! Observe how the routing table has changed
    
  3. Recover from the simulated failure and observe the OPCOM messages.


    $ DEASSIGN/SYSTEM TCPIP$FAILSAFE_FAILED_ifname  ! or reconnect the cable
    $ ifconfig -a ! Observe how the addresses have migrated
    $ netstat -nr ! Observe how the routing table has changed
    

    Again, ensure that TCP connections are still established and can transfer data.

Note

Simulating a failure with the logical name TCPIP$FAILSAFE_FAILED_ifname does not disrupt physical connections and therefore is not an accurate indicator of whether the services will survive a real failover situation. Consequently, this procedure should be repeated by physically removing a network cable from one or more of the interfaces. Since this action might be disruptive to network services, it should be scheduled during a maintenance period, when disruption can be tolerated.

5.3.5.2 Configuring Failover Time

The key concern for configuring the failSAFE IP service is the time it takes to detect a failure and for the standby IP address to become active. One goal of a failSAFE IP configuration is to avoid disrupting existing connections, so the failover time must be within the connection timeout.

The minimum failover time is calculated as:


INFO_POLL + (WARN_POLL * RETRY)

The maximum failover time is calculated as:


(2 * INFO_POLL) + (WARN_POLL * RETRY)

For explanations of the variables, see Table 5-2. The default values (INFO_POLL=3, WARN_POLL=2, RETRY=1) result in a failover range of 5 to 8 seconds. Note that this does not take into account the system load.

The recovery time will be less than the ERROR_POLL period, which is, by default, 30 seconds.

5.3.5.3 Avoiding Phantom Failures

The health of a NIC is determined by monitoring the NIC's Bytes Received counter. This provides a protocol-independent view of the NIC counters. However, in a quiet network, there may be insufficient traffic to keep the Bytes Received counter changing within the failover detection time, thus causing a phantom failure. To counteract this, the failSAFE service attempts to generate MAC-layer broadcast messages, which are received on every interface on the LAN except for the sending interface.

Consequently, in a quiet network with only two interfaces being monitored by the failSAFE IP service, a single NIC failure can also result in a phantom failure of the other NIC, since the surviving NIC is not able to increase its own Bytes Received counter.

You can reduce phantom failures in a quiet network by configuring the failSAFE IP service for at least three interfaces on the LAN. If one interface fails, the surviving interfaces continue to maintain one another's Bytes Received counters.

5.3.5.4 Creating IP Addresses with Home Interfaces

By default, the interface on which a primary IP address is created is its home interface, whereas an IP alias address is created without a home interface. To create an alias address with a home interface, use the ifconfig command, which should be added to the SYS$STARTUP:TCPIP$SYSTARTUP.COM procedure. For example, use the following command to create an alias address of 10.10.10.3 on interface IE0 and to designate IE0 as its home interface:


$ ifconfig ie0 home alias 10.10.10.3/24

5.3.5.5 Private Addresses Should Not Have Clusterwide Standby Interfaces

Private addresses are those that are used for network administration and are not published as well-known addresses for well-known services. A standby interface for a private address should be configured on the same node as the home interface. This avoids a situation in which a node cannot assign any addresses to its interfaces if they have active connections on another node in the cluster.

If you want to associate the list of private addresses with a public DNS alias name, you should use the load broker to provide high availability of the DNS alias. The load broker is described in Chapter 7.


Part 2
BIND

Part 2 provides information on configuring and managing the TCP/IP Services name server and includes the following chapters:


Chapter 6
Configuring and Managing BIND Version 9

The Domain Name System (DNS) maintains and distributes information about Internet hosts. DNS consists of a heirarchical database containing the names of entities on the Internet, the rules for delegating authority over names, and mail routing information; and the system implementation that maps the names to Internet addresses.

In OpenVMS environments, DNS is implemented by the Berkeley Internet Name Domain (BIND) software. HP TCP/IP Services for OpenVMS implements a BIND server based on the Internet Software Consortium's (ISC) BIND Version 9.

Note

The BIND Version 9 server is not supported on VAX systems. For information about the BIND Version 8 server, which runs on both VAX and Alpha systems, see Appendix D.

This chapter contains the following topics:

  • How to migrate your existing BIND 4 environment to BIND 9 ( Section 6.3)
  • How to configure BIND using the BIND configuration file ( Section 6.5), including:
  • How to populate the BIND server databases ( Section 6.6)
  • How to examine name server statistics ( Section 6.7)
  • How to configure BIND using SET CONFIGURATION BIND commands ( Section 6.8)
  • How to configure the BIND resolver ( Section 6.9)
  • How to use the BIND server administrative tools ( Section 6.10)
  • How to troubleshoot BIND server problems ( Section 6.11)

6.1 Key Concepts

This section serves as a review only and assumes you are acquainted with the InterNIC, that you applied for an IP address, and that you registered your domain name. You should also be familiar with BIND terminology, and you should have completed your preconfiguration planning before using this chapter to configure and manage the BIND software.

If you are not familiar with DNS and BIND, see the Compaq TCP/IP Services for OpenVMS Concepts and Planning guide. If you need more in-depth knowledge, see O'Reilly's DNS and BIND, Fourth Edition. You can find the BIND 9 Adminstrator Reference Manual at http://www.isc.org/ .

6.1.1 How the Resolver and Name Server Work Together

BIND is divided conceptually into two components: a resolver and a name server. The resolver is software that queries a name server; the name server is the software process that responds to a resolver query.

Under BIND, all computers use resolver code, but not all computers run the name server process.

The BIND name server runs as a distinct process called TCPIP$BIND. On UNIX systems, the name server is called named (pronounced name-dee). Name servers are typically classified as master (previously called primary), slave (previously called secondary), and caching-only servers, depending on their configurations.

6.1.2 Common BIND Configurations

You can configure BIND in several different ways. The most common configurations are resolver-only systems, master servers, slave servers, forwarder servers, and caching-only servers. A server can be any of these configurations or can combine elements of these configurations.

Servers use a group of database files containing BIND statements and resource records. These files include:

  • The forward translation file, domain_name.DB
    This file maps host names to IP addresses.
  • The reverse translation file, address.DB
    This file maps the address back to the host names. This address name lookup is called reverse mapping. Each domain has its own reverse mapping file.
  • Local loopback forward and reverse translation files, LOCALHOST.DB, 127_0_0.DB, and 0_0_0_0_0_0_IP6.ARPA (for IPv6).
    These local host databases provide forward and reverse translation for the widely used LOCALHOST name. The LOCALHOST name is always associated with IPv4 address 127.0.0.1 and IPv6 address ::1, and is used for loopback traffic.
  • The hint file, ROOT.HINT
    This file contains the list of root name servers.

A configuration file, TCPIP$BIND.CONF, contains statements that pull all the database files together and governs the behavior of the BIND server.

6.1.2.1 Master Servers

A master server is the server from which all data about a domain is derived. Master servers are authoritative, which means they have complete information about their domain and that their responses are always accurate.

To provide central control of host name information, the master server loads the domain's information directly from a disk file created by the domain administrator. When a new system is added to the network, only the database on the master server needs to be modified.

A master server requires a complete set of configuration files: forward translation, reverse translation, configuration, hint, and loopback files.

6.1.2.2 Slave Servers

Slave servers receive authority and their database from the master server.

A particular domain's database file is called a zone file; copying this file to a slave server is called a zone file transfer . A slave server assures that it has current information about a domain by periodically transferring the domain's zone file from the master. Slave servers are also authoritative for their domains.

Configuring a slave server is similar to configuring a master server. The only difference is that, for the slave server, you need to provide the name of the master server from which to transfer zone data.

Note

If you create a master, slave, or forwarder server for the same domain on which your local host resides, you should reconfigure your BIND resolver so that it uses this system (LOCALHOST) as its name server.

Slave servers require a configuration file, a hint file, and loopback files.

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:

  • Access control lists allow you to control access to the name server. See Section 6.2.1 for more information.
  • Dynamic Update Security controls access to the dynamic update facility. See Section 6.2.2 for more information.
  • Transaction Signatures (TSIG) provide key-based access to the dynamic update facility. See Section 6.2.3 for more information.
  • TKEY automatically generates a shared secret between two hosts. See Section 6.2.4 for more information.
  • SIG(0) is another method for signing transactions. See Section 6.2.5 for more information.
  • DNSSEC provides cryptographic authentication of DNS information. See Section 6.2.6 for more information.

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:

  • allow-notify
  • allow-query
  • allow-recursion
  • blackhole
  • allow-transfer

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


Previous Next Contents Index