Assigning Dynamic Addresses

The simplest configuration for a DHCP server is to assign dynamic IP addresses. In this case, the DHCP server provides whatever IP address is convenient to a computer when that computer connects. No IP addresses are reserved for particular computers, so any given client might receive one IP address one day and another address the next day. A client may request a specific address, and most clients request the last address they received, but the server may ignore this request. In practice, computers are likely to receive the same addresses time after time if they're seldom turned off or if they're powered down only for short periods, but this isn't guaranteed . Dynamic configurations may be useful if your network sports a large number of clients, but it has a drawback: Because client IP addresses may change at unpredictable times, it's difficult to tie them to specific hostnames, because the DNS servers that tie hostnames to IP addresses are typically configured with static IP address mappings. This makes running servers on dynamic DHCP clients problematic . The "Communicating with a DNS Server" section later in this chapter describes one way around this problem, but another is to assign fixed IP addresses to servers, as described in the section "Assigning Fixed Addresses."

Setting Global Options

Listing 5.1 shows a complete dhcpd.conf file that can assign dynamic IP addresses. This file is fairly simple, but it may be suitable for a small network, and it illustrates the basic structure of the file.

Listing 5.1 A sample dhcpd.conf file

 default-lease-time 7200; max-lease-time 10800; option subnet-mask 255.255.255.0; option routers 192.168.1.1; option domain-name-servers 192.168.1.1, 172.17.102.200; option domain-name "threeroomco.com"; subnet 192.168.1.0 netmask 255.255.255.0 {    range 192.168.1.50 192.168.1.150; } 

The first six lines of Listing 5.1 define the global options. These are parameters that define critical aspects of the network or of the server's configuration, and that apply to all the clients served by dhcpd , unless the global option is overridden in a more specific declaration. Specifically , the first two items ( default-lease-time and max-lease-time ) set the length of leases in seconds. Like a tenant and landlord negotiating the lease to an apartment, the DHCP client and server must negotiate an appropriate lease time for an IP address. The default-lease-time value sets the lease time that the DHCP server prefers. In Listing 5.1, this is 7,200 seconds, or 120 minutes. If the client asks for a longer lease, the max-lease-time value sets the maximum that dhcpd will permit ”10,800 seconds (180 minutes) in the case of Listing 5.1. You can adjust these values up or down as you see fit. Setting lease times low increases network bandwidth consumption, as clients must renew their leases regularly, and makes it more likely that the network will be disrupted if the DHCP server crashes. Setting lease times too high makes it more likely that you'll run out of IP addresses if computers connect briefly and then disconnect, because these systems will still have leases on IP addresses they're no longer using. If you want to test a DHCP server, you might set lease times quite low ”say, to 60 seconds ”so that you can make changes and observe the effect of these changes without undue delay. If a network sees a lot of changes (say, laptops being connected and disconnected regularly), you might set leases at a moderately low value, such as those in Listing 5.1 or a bit lower. On a network dominated by systems that remain connected for days at a time, you might set leases in the hundreds of thousands of seconds (that is, a period of days).

The next four lines in Listing 5.1 set global parameters that are passed on to DHCP clients ”specifically, the network's netmask, gateway/router address, DNS server addresses, and domain name. These are the same values you'd enter when configuring a computer to use a static IP address, as described in Chapter 2. Although Listing 5.1 shows IP addresses, you may specify hostnames if name resolution works correctly on the DHCP server. If you do this, dhcpd resolves the hostnames you provide and passes IP addresses on to the clients. The DHCP server or client automatically derives or uses defaults for some values not shown in Listing 5.1, but you can override these defaults. When setting any of these parameters, you must including a trailing semicolon ( ; ) on the line, as shown in Listing 5.1. Some of the values you might want to set include the following:

• filename " filename " ” The dhcpd server can function as a boot server for computers that boot from an OS stored on a network server. When so configured, the DHCP server must be able to provide the name of an initial boot file for the client, and this is done through the filename parameter. The client will then retrieve this file with some other file transfer protocol.

• next-server " hostname " ” This parameter sets the name of the computer on which the boot file (specified by filename ) can be found. If you don't include this parameter, the default is the DHCP server itself.

• server-name " hostname " ” This is another network-boot option. It's used to tell the client the name of the server that holds the boot files, aside from the initial boot file specified by filename and next-server .

• boot-unknown-clients flag ” Normally, flag defaults to true , which makes dhcpd issue an IP address to any computer that requests one. If flag is false , the server issues IP addresses only to computers that have explicit host declarations, as described in the section "Assigning Fixed Addresses."

• option broadcast-address ip-address ” If your network uses an unusual broadcast address, you can set it with this parameter. Normally, clients can compute this value correctly on their own.

• get-lease-hostnames flag ” If flag is set to true , dhcpd looks up a hostname via DNS before issuing an IP address, and passes the returned value to the client as its hostname. This results in clients whose hostnames match their IP addresses, which may be important if the clients run programs that incorporate their hostnames in outgoing network traffic (as do some mail servers, for instance). This parameter's default value is false .

• use-host-decl- names flag ” This parameter is similar to get-lease-hostnames , but if it's set to true , it causes dhcpd to pass the hostname as set in a host declaration (described shortly) to the client, rather than the hostname associated with the IP address obtained from a DNS lookup. The default value is false .

NOTE

The get-lease-hostnames and use-host-decl-names parameters both determine whether or how the DHCP server will set the client's hostname on the client. These options do not affect hostname lookups performed through DNS from other systems, although get-lease-hostnames sets the hostname on the client to match the DNS name for the IP address. If you want to reliably reach a DHCP client by hostname from other computers, consult the upcoming sections, "Assigning Fixed Addresses" and "Communicating with a DNS Server."

There are a wide variety of additional parameters, many of which are options (they use the option keyword followed by the name of the option). Many of these options set the locations of various servers on a network, such as X font servers, time servers, and print servers. Others set low-level network interface options like whether the client should enable IP forwarding. Consult the dhcpd.conf man page if you need to set any of these options. Many of these options require additional tools on the client to do any good; standard DHCP clients don't automatically reconfigure features such as X font servers.

For the most part, these parameters may be set globally at the start of the file; or as part of a definition for just one set of IP addresses, by placing the parameters within the declaration for an individual subnet or group as described shortly.

Defining a Subnet Range

Listing 5.1 demonstrates a very simple DHCP configuration, in which just one range of IP addresses is assigned. This is done through the subnet declaration in that listing:

 subnet 192.168.1.0 netmask 255.255.255.0 {    range 192.168.1.50 192.168.1.150; } 

This declaration specifies that the server operates on the 192.168.1.0/24 network. Consequently, the computer must have an active interface on that network. The DHCP server binds to that network interface and offers DHCP leases to clients that broadcast asking for an address on that network. The range declaration defines the range of IP addresses that the server will offer ”192.168.1.50 to 192.168.1.150 in this example. You may use other addresses within the 192.168.1.0/24 network but outside of the specified range for computers that require static IP addresses, including the DHCP server itself; do not include the DHCP server's IP address within the values specified by the range declaration.

A single dhcpd.conf file may contain multiple subnet declarations. You might do this if the server has two network interfaces, in which case you'd use one subnet declaration per interface. You might also do it if there were just one physical interface, but that interface linked to multiple logical subnets. Versions of dhcpd prior to 3.0 require a separate subnet declaration for each physical interface, whether or not the server is to operate on the interface. For instance, if the computer is to function as a DHCP server on the 192.168.1.0/24 network but not on the 172.20.30.0/24 network, you'd still need a subnet declaration for the latter interface. This declaration could be empty, thus:

 subnet 172.20.30.0 netmask 255.255.255.0 { } 

This empty declaration causes the server to not respond to DHCP requests on that interface. Version 3.0 of dhcpd allows you to omit this empty declaration to achieve the same end.

WARNING

If you're configuring a computer as a DHCP server on one network and another computer functions as the DHCP server on a second network to which the computer is connected, be positive you configure your server to not respond to DHCP requests on the second network. If not properly configured to work together, two DHCP servers on a single network can be a recipe for disaster. In fact, you may want to block incoming DHCP traffic on the second network interface using firewall rules, as discussed in Chapter 25, Configuring iptables. Better yet, move the DHCP server function to a computer that connects only to the first network.