|
HP OpenVMS Systems Documentation |
|
HP TCP/IP Services for OpenVMS
|
| Previous | Contents | Index |
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:
$ @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 |
$ DEFINE/SYSTEM TCPIP$FAILSAFE_FAILED_ifname 1 ! or disconnect the cable |
$ ifconfig -a ! Observe how the addresses have migrated $ netstat -nr ! Observe how the routing table has changed |
$ 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 |
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. |
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 |
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 provides information on configuring and managing the TCP/IP Services name server and includes the following chapters:
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.
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:
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:
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.
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 (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. 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:
$ dnssec_keygen -a hmac-md5 -b 128 -n HOST host1-host2. |
Key: La/E5CjG9O+os1jq0a2jdA== |
key host1-host2. {
algorithm hmac-md5;
secret "La/E5CjG9O+os1jq0a2jdA==";
};
|
server 10.1.2.3 {
keys { host1-host2. ;};
};
|
allow-update { key host1-host2. ;};
|
| Previous | Next | Contents | Index |