Some types of DHCP options require that some other package exchange data with the DHCP server. Frequently, this is a matter of the DHCP client accepting and using additional information from the DHCP server. Other times, some other server must consult the DHCP server to help with its configuration. The preceding discussion has included an example in which the DHCP server uses another server to obtain information: The get-lease-hostnames parameter allows the DHCP server to set clients ' hostnames based on a DNS server lookup of the IP address being assigned.
Including NetBIOS Information
NetBIOS, which serves as the underpinning for the Server Message Block (SMB)/Common Internet Filesystem (CIFS) file- and printer-sharing protocols described in Chapter 7, uses a series of structures and tools atop TCP/IP to do its job. You can configure a DHCP server to deliver information on some of these structures to Windows clients to help these systems operate most efficiently . Specifically, you can set the following dhcpd.conf parameters:
It's often beneficial to set the first two of these options globally on a DHCP server that delivers IP addresses to Windows clients. (Linux's Samba package doesn't use the values delivered by DHCP, but its Windows clients may.) For instance, you might include the following two lines near the top of the dhcpd.conf file:
option netbios-name-servers 192.168.1.1; option netbios-node-type 8;
To be sure that the Windows computers use this information, you should check the Use DHCP for WINS Resolution option in the TCP/IP Properties dialog box in Windows, as shown in Figure 5.3. If you select Disable WINS Resolution, the system won't use WINS at all, and if you select Enable WINS Resolution, you must manually enter the IP address of your WINS server.
Figure 5.3. You must explicitly configure Windows clients to use NetBIOS-specific options provided by a DHCP server.
Communicating with a DNS Server
If you want to be able to directly address a DHCP client from random systems, you have two choices: You can configure the DHCP server to give the client a fixed IP address, as described earlier in this chapter; or you can configure the DHCP server and the DNS server to communicate with one another, in order to update the DNS server's records to reflect the DHCP client's current address. This latter approach works best when the DHCP clients' addresses don't change very often, and when you're interested primarily in accessing the DHCP client from other systems on your local network. When Internet access is needed, a changing IP address may take some time to propagate through the Internet's DNS server collection, so there may be attempts to reach the computer at its old address for some time after that address has changed.
Prior to version 3.0, dhcpd included no explicit support for DNS updates. Version 3, though, implements two preliminary methods of DNS updates. Another is on track to become an Internet standard, and will be implemented in a future version of dhcpd , once the standard is finalized. The two methods that are currently implemented are the ad-hoc method and the interim method.
Dynamic DNS updates are enabled through the ddns-update-style parameter, which takes one of three values: ad-hoc , interim , or none (the last of these is the default). To use dynamic DNS, enable one of the first two values in the global section of the dhcpd.conf file ”it won't work if you try to enable it for just some clients.
Using the Ad-Hoc Update Method
The ad-hoc method obtains a hostname for a client in one of four ways, in the following priority:
In all these cases, only the local hostname portion is used. If none of these methods yields a hostname, the DHCP server does not attempt to perform a DNS update for the client. If the DHCP server can find a hostname, the server combines the hostname with the value of the ddns-domainname option, if it's present, or with the domain-name option if there's no ddns-domainname option.
The DHCP server uses the FQDN it's derived to update the DNS server. It first updates the A record ”the record that controls forward lookups, in which a user enters a hostname and obtains an IP address from that. If the A record change was successful, the DHCP server then updates the PTR record, which is used for reverse lookups, in which a user enters an IP address to obtain a hostname.
Using the Interim Update Method
The interim update method works much like the ad-hoc method in many ways, but it provides support for allowing the client to update the DNS server's A record, if the client makes this request. You may include the allow client-updates or ignore client-updates statements in the dhcpd. conf file to tell DHCP to allow clients to do this job themselves , or to ignore such requests , respectively. The default is to honor client requests on this matter.
If the DHCP server is configured to honor client DNS updates, then the DHCP server uses the FQDN provided by the client to perform PTR updates. If the DHCP server disallows this option, then the DHCP server constructs an FQDN from the client's hostname and the domain name set in dhcpd.conf , and uses this name to update both the A and PTR records.
When configured to disallow client-initiated DNS changes, the interim method creates results that are similar to those of the ad-hoc method. When the interim method permits client-initiated DNS changes, though, there's a difference: The client might specify a domain name that's something other than what the DHCP server is configured to use. For instance, suppose the DHCP server hands out hostnames in the threeroomco.com domain. Using the ad-hoc method, all clients that receive DNS updates will receive them in this domain, even if the client presents an FQDN in another domain. With the interim method configured to permit client updates, the client could claim a hostname of, say, dino. pangaea .edu . Assuming that this domain's DNS servers accept the update, the client could then be reached by this name. If your own DHCP and DNS servers interoperate fully, the PTR record for reverse lookups would also then return the name dino.pangaea.edu when asked about the name associated with the dynamically granted IP address for the client. Such a configuration isn't possible with the ad-hoc method. Whether or not it's a desirable configuration is something you'll have to decide for yourself. If your network connections are tightly controlled and your users are likely to need hostnames in foreign domains, such a configuration might be desirable. You might prefer to prevent such configurations if your network is relatively easy to access physically, though, because a reverse lookup of one of your IP addresses linked to a foreign domain might cause confusion or help a cracker mask illegal activities.