HP OpenVMS Systems Documentation

The .DDNSKEYS file describes each DNS domain and the DNS name server that is to receive Host/IP address update information when DHCP distributes an address to a DHCP client in the domain. The information in this file consists of the domain to be updated and the IP address of the DNS server to which DHCP sends the updates. A third field for secure dynamic updates is reserved for future use. TCP/IP Services does not support secure dynamic updates.

This file is required for DHCP to perform DNS dynamic updates.

The following example shows the contents of a typical .DDNSKEYS file:

$ TYPE PINE$DKB0:[DHCP_CONFIG].DDNSKEYS
compaq.com           10.10.2.14
10.10.in-addr.arpa   10.10.2.14

Table 7-4 describes the command files used by the DHCP server.

By establishing logical names, you can modify the following server characteristics:

• The directory in which the DHCP configuration files and databases are placed during TCPIP$CONFIG
• Error logging and diagnostics

Table 7-5 lists the DHCP logical names and describes their function.

You define system wide TCPIP$DHCP logical names in the SYS$STARTUP:TCPIP$DHCP_SYSTARTUP.COM file. After making changes to the file, enter the following commands:

$ @SYS$STARTUP:TCPIP$DHCP_SHUTDOWN.COM
$ @SYS$STARTUP:TCPIP$DHCP_STARTUP.COM

Alternatively, you can follow these steps:

1. Manually define the system logical names.
2. Use DHCPSIGHUP to signal the DHCP server.

The DHCP server creates a log file named TCPIP$DHCP_RUN.LOG in the directory SYS$SYSDEVICE:[TCPIP$DHCP].

7.3 DHCP Server Startup and Shutdown

The DHCP server can be shut down and started independently of TCP/IP Services. This is useful when you change parameters or logical names that require the service to be restarted.

The following files are provided:

• SYS$STARTUP:TCPIP$DHCP_STARTUP.COM allows you to start up the DHCP service.
• SYS$STARTUP:TCPIP$DHCP_SHUTDOWN.COM allows you to shut down the DHCP 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$DHCP_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when DHCP is started.
• SYS$STARTUP:TCPIP$DHCP_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when DHCP is shut down.

If you specified automatic startup during the TCP/IP Services configuration procedure (TCPIP$CONFIG), the DHCP server process starts automatically when the DHCP service is started (TCPIP$DHCP_STARTUP.COM).

If you want to stop the DHCP server process, enter the following utility command as defined in SYS$MANAGER:TCPIP$DHCP_SETUPCOMMANDS.COM:

$ DHCPSIGTERM

Be aware that a new DHCP server process starts automatically as soon as the old process exits unless you disable the DHCP service before entering a DHCPSIGTERM command. As an alternative method, you can shut down DHCP by executing the following command:

$ @SYS$STARTUP:TCPIP$DHCP_SHUTDOWN

Because the DHCP server has several binary databases open (updates to which might not have been flushed to the disk), do not stop a running DHCP process using the DCL command STOP/ID=entry_number. Instead, stop the DHCP process by entering the DHCPSIGTERM command.

7.4 Configuring the DHCP Server

To enable DHCP initially, run the TCPIP$CONFIG procedure by entering the following command and then choose DHCP from the Server Components menu:

$ SYS$STARTUP:@TCPIP$CONFIG

The configuration procedure asks if you want to convert existing BOOTP entries to DHCP database:

Do you want to rollover old-style BOOTP entries into the DHCP
database? [Y]

• If you answer Yes, the TCPIP$DHCP_BOOTPTODHCP.COM procedure tries to locate the existing BOOTP database. Once it locates a file, the configuration procedure asks you to confirm its selection or make a new selection:

  Name of file to use for old-style BOOTP: SYS$SYSTEM:TCPIP$BOOTP.DAT Press return or enter new file name:

  
  The configuration procedure does the following to the file:
  • Converts any existing BOOTP information to the appropriate DHCP format in the new DHCPCAP. configuration file.
  • Sets up the DHCP server to support BOOTP clients.
  • Sets up permanent leases for existing BOOTP clients.
  
  During TCPIP$CONFIG, all DHCP-related files are placed in the SYS$SYSDEVICE:[TCPIP$DHCP] directory unless you define the system logical name TCPIP$DHCP_CONFIG (see Table 7-5).
• If you answer No, the new DHCP configuration file DHCPCAP. remains empty, and your BOOTP clients will not be served.
  TCPIP$CONFIG invokes the command procedure SYS$MANAGER:TCPIP$DHCP_SETUPCOMMANDS.COM, which defines the GUI Server Management Console and DHCP utilities as OpenVMS foreign commands.

  Important Compaq recommends calling the TCPIP$DHCP_SETUPCOMMANDS.COM procedure as part of the login process for all users who are authorized to manage the DHCP server.

DHCP uses the following methods to assign a host name:

• By hardware address
  When you specify this method, DHCP uses the host name suggested by a client when the client sends out its initial boot request.
  This method requires that both the DHCP and BIND servers are capable of and configured for performing dynamic DNS updates.
  To configure host name assignment using this method, see Section 7.4.2.1.
• By IP address
  If you specify this method to assign host names, DHCP performs a BIND IP address lookup to obtain a host name associated with the IP address. If the lookup is successful, DHCP uses the host name returned by BIND. If the lookup fails, DHCP creates a name from the NAMEPOOL. file.
  This method requires that you manually assign an IP address to each host and add A and PTR records to your DNS/BIND database.
  To configure host name assignment using this method, see Section 7.4.2.2.

To configure DHCP to assign a host name dynamically, perform the following steps:

1. Change the SERVER.PCY file (either manually or with the DHCP GUI) to include the following statements:

   name_service_updateable
   assign_name_by_hwaddr
   accept_client_name
   dns_tracks_dhcp_lease

2. Configure a DNS/BIND server to accept dynamic updates from your DHCP server. If you are running the DHCP server on multiple nodes, configure the DNS/BIND server to accept dynamic updates from each of the nodes. Refer to Section 5.3.6 for a discussion on how to configure DNS/BIND to accept dynamic updates from DHCP.
3. Edit the DHCPCAP. file to add a domain name for all subnet entries for which DHCP will perform dynamic DNS updates. To use the DHCP GUI to add dynamic DNS updates for a domain, do the following:
   1. Start the DHCP GUI as described in Section 7.5
   2. Select the Subnets tab.
   3. Select DHCP parameters from the drop down list
   4. Add the domain name to the DNS Domain Name parameter.
4. Create a .DDNSKEYS file with an entries for the DNS/BIND server that is to receive dynamic updates. You will most likely want to create an entry for A and PTR records by defining a forward and reverse translation entry.
5. Create a NAMEPOOL. file to supply a pool of names to use for nodes on the particular network. DHCP uses this pool of names to generate a host name only when other methods are unsuccessful.

To configure DHCP to use host names defined in a DNS/BIND server database, perform the following steps:

• Change the SERVER.PCY file (either manually or with the DHCP GUI) to include the following statement:

  assign_name_by_ipaddr

  
  Exclude the following statements:

  accept_client_name
  dns_tracks_dhcp_lease
  name_service_updateable

  
  See Section 7.2.2.1.
• Edit the DNS/BIND forward translation (domain_name.DB) file to include an A record for each IP address in the range of IP addresses that your DHCP server may allocate. It is common practice to assign IP addresses and names systematically. For example, if IP address 10.10.2.100 obtains the name dhcp1.xyz.com , then IP address 10.10.2.101 obtains the name dhcp2.xyz.com (see Section 5.4.4.3).
• Edit the DNS/BIND reverse translation (address.DB) file to include a PTR record for each host name (see Section 5.4.4.4).

One of the DHCP utilities that is defined in TCPIP$DHCP_SETUPCOMMANDS.COM is the TCPIP$DHCP_SIGNAL utility, which provides interprocess signaling in a manner similar to the UNIX kill signal delivery utility. PRMMBX and SYSNAM privileges are required to run TCPIP$DHCP_SIGNAL.EXE.

The following table shows the commands available with the TCPIP$DHCP_SIGNAL utility:

You can return to a BOOTP-only configuration at any time. Further, you can use the previous TCPIP$BOOTP.DAT database file and the client entries it contains. If you deleted the TCPIP$BOOTP.DAT file, you can create a new one and populate it with entries (see Section 9.5).

To enable BOOTP after you have configured your host for DHCP, run TCPIP$CONFIG and enable the BOOTP component from the Server Components menu. Your existing DHCP files will remain for future use.

7.4.5 Setting Up a DHCP Cluster Failover Environment

You can set up an OpenVMS Cluster environment for DHCP server failover. In this environment, a standby system becomes the DHCP server if the active DHCP server process fails or is stopped, or the system on which it is running fails or shuts down.

With cluster failover, the DHCP server uses the OpenVMS lock manager during process initialization to acquire a system-level, exclusive-mode lock on a resource called TCPIP$DHCP_SERVER. The first server started on the cluster obtains the lock on TCPIP$DHCP_SERVER and becomes the active DHCP server. The other DHCP servers wait to obtain the lock and become the standby servers.

When the active DHCP server process exits for any reason, the lock on TCPIP$DHCP_SERVER is released and one of the standby processes acquires the lock and becomes the active server.

To configure the DHCP server failover environment, do the following:

1. If the DHCP server is running on one of your systems, manually disable it by entering the following command on the server system:

   $ @SYS$STARTUP:TCPIP$DHCP_SHUTDOWN.COM

2. Create a directory for the DHCP configuration and binary database files that is visible to the DHCP cluster members. Specify TCPIP$DHCP as the directory's owner. For example:

   $ CREATE/DIRECTORY/OWNER=TCPIP$DHCP WORK1$:[DHCP_CONFIG]

3. If you have already been running DHCP server and want to start with the existing data files, then do the following:
   1. Copy the DHCP data files from the DHCP directory to TCPIP$DHCP_CONFIG:*.* by entering commands similar to the following:

      $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]DHCPCAP. TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]DHCPTAGS. TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]NAMEPOOL. TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]NETMASKS. TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]NETS. TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]SERVER.PCY TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP]DB%.%%% TCPIP$DHCP_CONFIG: $ COPY SYS$SYSDEVICE:[TCPIP$DHCP].DDNSKEYS TCPIP$DHCP_CONFIG:

   2. Delete the DHCP data files from the DHCP directory by renaming them to a temporary subdirectory. (You can delete the files after you are sure that the failover environment is set up correctly.) For example, enter the following commands:

      $ CREATE/DIR SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ PURGE SYS$SYSDEVICE:[TCPIP$DHCP] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]DHCPCAP.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]DHCPTAGS.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]NAMEPOOL.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]NETMASKS.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]NETS.;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]SERVER.PCY;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP]DB%.%%%;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE] $ RENAME SYS$SYSDEVICE:[TCPIP$DHCP].DDNSKEYS;* SYS$SYSDEVICE:[TCPIP$DHCP.SAVE]

4. On each cluster node that is to serve as a potential DHCP server, set up the TCPIP$DHCP_CONFIG logical name as follows:
   1. Define TCPIP$DHCP_CONFIG as a systemwide logical name. For example:

      $ DEFINE/SYSTEM TCPIP$DHCP_CONFIG WORK1$:[DHCP_CONFIG]

   2. Before you run the TCPIP$STARTUP.COM procedure, add the TCPIP$DHCP_CONFIG logical name definition to the TCPIP$DHCP_SYSTARTUP.COM file.
5. On each cluster node that you want to be a DHCP server, run TCPIP$CONFIG to enable the DHCP service (see Section 7.4.1).
   The TCPIP$CONFIG procedure creates the TCPIP$DHCP account and stores initial copies of the DHCP configuration data files in the directory pointed to by the logical name TCPIP$DHCP_CONFIG. If you choose to roll over your BOOTP database to DHCP, TCPIP$CONFIG creates your initial DHCP binary database files in the TCPIP$DHCP_CONFIG directory.
6. Make sure that the auto_sync_dbs parameter is set in the SERVER.PCY file.
   This parameter causes the DHCP server databases to be flushed after each update. You can set the parameter by editing the SERVER.PCY file or by setting the auto_sync_dbs parameter to True on the Server/Security tab in the DHCP GUI.
7. Ensure that the files in TCPIP$DHCP_CONFIG: and the directory itself are owned by TCPIP$DHCP and have owner-only protection (O:RWED). For example:

   $ DIRECTORY/SECURITY WORK1$:[DHCP_CONFIG] $ DIRECTORY/SECURITY WORK1$:[000000]DHCP_CONFIG.DIR

8. Edit the NETS. file and set the ownership of any existing IP address range to 0.0.0.0.
   With the DHCP cluster failover configured, you need to indicate that an address range is owned by other hosts. Therefore, you specify the null IP address of 0.0.0.0 in the second field of the NETS. file in each IP address range to be shared among the DHCP servers. For example, the following entry in the NETS. file is owned by IP address 17.18.208.100:

   17.18.0.0 17.18.208.100 17.18.208.10-17.18.208.50

   
   You would change the entry to the following:

   17.18.0.0 0.0.0.0 17.18.208.10-17.18.208.50

   
   If you prefer to use the DHCP GUI to configure the null address, choose the IP Ranges parameter on the Server/Security tab and set the parameter to True.
9. Shut down DHCP on each cluster member where DHCP is running by using the TCPIP$DHCP_CLUSTER_SHUTDOWN command procedure. When the command procedure is finished, restart DHCP on the cluster by using TCPIP$DHCP_CLUSTER_STARTUP.