Integrating with Other Protocols

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:

• option netbios- name -servers server-addresses ” Traditionally, NetBIOS has relied upon name resolution systems that are independent of those used by most TCP/IP clients. NetBIOS computers can use a broadcast model, in which computers send broadcasts on the local network to locate clients, or they can use name servers independent of the DNS name servers used by TCP/IP. These independent name servers are known as NetBIOS Name Service (NBNS) servers or Windows Internet Name Service (WINS) servers. You can give Windows clients the names of these servers with the option netbios-name-servers parameter. You'll usually list just one server here, although DHCP can deliver multiple WINS server addresses.

• option netbios-node-type type-code ” This option is used in conjunction with the preceding one to tell clients whether to use broadcast name resolution or a WINS server. The type-code is a value that ranges from 1 to 8 . Values of 1 and 2 mean to use broadcasts or a WINS server, respectively. Values of 4 and 8 mean to use both, with 4 causing the client to try broadcasts first and fall back on the WINS server, and 8 to use WINS first and fall back on broadcasts. Most networks that have WINS servers should use a type-code of 8 , because this will reduce network broadcasts but provide the most reliable operation if the WINS server goes down or lacks data on a particular computer.

• option netbios-dd-server server-address ” This option sets one of the more obscure aspects of NetBIOS networking: the address of the NetBIOS Datagram Distribution (NBDD) server. This server relays broadcasts to clients that might not otherwise receive them. Chances are you won't need to set this option.

• option netbios-scope string ” NetBIOS scope refers to a group of computers across which a given NetBIOS name is known. Most NetBIOS systems leave their scopes unchanged, so any NetBIOS computer on a network can resolve the name of any other. If your network uses NetBIOS scopes, though, you may need to set this option (possibly in a group declaration).

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.

NOTE

Other update methods also exist, which are usually implemented by third-party packages. These tools monitor DHCP log files and then change the DNS server's configuration when the DHCP log files indicate important actions.

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.

WARNING

Both these methods of DNS updates rely upon the DNS server accepting the updates. This topic is covered in Chapter 18, Administering a Domain via DNS.

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:

1. If a host declaration contains a ddns-hostname option, the value of that option is used.

2. If the client passes a fully-qualified domain name (FQDN ”that is, a hostname complete with domain name portion), the DHCP server uses the hostname portion of the FQDN.

3. If the client passes a hostname without a domain name, the DHCP server uses it.

4. The name of the host declaration for the client may be used.

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.

Dynamic DNS Services

Some users of broadband Internet access, such as Digital Subscriber Line (DSL) and cable modems, receive dynamic IP addresses from their ISPs using DHCP or other protocols. If you're in this situation and want a fixed hostname for your computer, you probably won't be able to use the dynamic DNS features of DHCP and DNS on Linux, since what you really need to do is to interoperate with an Internet-accessible DNS server. The solution is to use one of many dynamic DNS services that are available for free or at low cost.

A dynamic DNS service operates its own DNS servers, which provide lookups on names on the Internet at large. Once you contract with such a service, you can use a client package on your computer to contact the provider's DNS server whenever your IP address changes. You can then have a fixed hostname (either within a domain owned by the dynamic DNS provider or within your own domain) that points to your dynamic IP address. Many dynamic DNS providers offer update software written in Perl or other common scripting languages, so most of them are Linux-compatible. You should check on this detail to be sure, though.

There are many dynamic DNS providers today. Indeed, there are a large number of lists of dynamic DNS providers. These include http://www.technopagan.org/dynamic/, http://www.geocities.com/kiore_nz/, and http://dns.highsynth.com. One of these lists should be able to point you to a dynamic DNS provider that suits your needs, if you don't operate your own externally accessible DNS server.