Avoid Using Dynamic DNS with DHCP

We’re unimpressed by DHCP systems that update dynamic DNS servers. This flashy feature adds unnecessary complexity and security risk.

In systems with dynamic DNS, a client host tells the DHCP server what its hostname should be, and the DHCP server sends updates to the DNS server. (The client host can also send updates directly to the DNS server.) No matter what network the machine is plugged in to, the DNS information for that host is consistent with the name of the host.

Hosts with static leases will always have the same name in DNS because they always receive the same IP address. When using dynamic leases, the host’s IP address is from a pool of addresses, each of which usually has a for- mulaic name, in DNS, such asdhcp-pool-10, dhcp-pool-11, dhcp-pool-12.

No matter which host receives the tenth address in the pool, its name in DNS will bedhcp-pool-10. This will most certainly be inconsistent with the

hostname stored in its local configuration.

This inconsistency is unimportant unless the machine is a server. That is, if a host isn’t running any services, nobody needs to refer to it by name, and it doesn’t matter what name is listed for it in DNS. If the host is running services, the machine should receive a permanent DHCP lease and always have the same fixed name. Services that are designed to talk directly to clients don’t use DNS to find the hosts. One such example is peer-to-peer services, which permit hosts to share files or communicate via voice or video. When joining the peer-to-peer service, each host registers its IP address with a central registry that uses a fixed name and/or IP address. H.323 communication tools, such as Microsoft Netmeeting, use this technique.

Letting a host determine its own hostname is a security risk. Hostnames should be controlled by a centralized authority, not the user of the host. What if someone configures a host to have the same name as a critical server? Which should the DNS/DHCP system believe is the real server? Most dynamic DNS/DHCP systems let you lock down names of critical servers, which means that the list of critical servers is a new namespace that must be maintained and audited (see Chapter 8, name spaces.) If you accidentally omit a new server, you have a disaster waiting to occur.

Avoid situations in which customers are put in a position that allows their simple mistakes to disrupt others. LAN architects learned this a long time ago with respect to letting customers configure their own IP addresses. We should not repeat this mistake by letting customers set their own hostnames. Before DHCP, customers would often take down a LAN by accidentally setting their host’s IP address to that of the router. Customers were handed a list of IP addresses to use to configure their PCs. “Was the first one for ‘default gate- way,’ or was it the second one? Aw, heck, I’ve got a 50/50 chance of getting

3.1 The Basics 63

it right.” If the customer guessed wrong, communication with the router essentially stopped.

The use of DHCP greatly reduces the chance of this happening. Permitting customers to pick their own hostnames sounds like a variation on this theme that is destined to have similar results. We fear a rash of new problems related to customers setting their host’s name to the name that was given to them to use as their email server or their domain name or another common string.

Another issue relates to how these DNS updates are authenticated. The secure protocols for doing these updates ensure that the host that inserted records into DNS is the same host that requests that they are deleted or replaced. The protocols do little to prevent the initial insertion of data and have little control over the format or lexicon of permitted names. We foresee situations in which people configure their PCs with misleading names in an attempt to confuse or defraud others—a scam that commonly happens on the Internet7_{—coming soon to an intranet near you.}

So many risks to gain one flashy feature! Advocates of such systems argue that all these risks can be managed or mitigated, often through additional features and controls that can be configured. We reply that adding layers of complicated databases to manage risk sounds like a lot of work that can be avoided by simply not using the feature.

Some would argue that this feature increases accountability, because logs will always reflect the same hostname. We, on the other hand, argue that there are other ways to gain better accountability. If you need to be able to trace illegal behavior of a host to a particular person, it is best to use a registration and tracking system (Section 3.1.3.3).

Dynamic DNS with DHCP creates a system that is more complicated, more difficult to manage, more prone to failure, and less secure in exchange for a small amount of aesthetic pleasantness. It’s not worth it.

Despite these drawbacks, OS vendors have started building systems that do not work as well unless dynamic DNS updates are enabled. Compa- nies are put in the difficult position of having to choose between adopting new technology or reducing their security standards. Luckily, the security industry has a useful concept: containment. Containment means limiting a security risk so that it can affect only a well-defined area. We recommend that dynamic DNS should be contained to particular network subdomains that

7. For many years, www.whitehouse.com was a porn site. This was quite a surprise to people who were looking for www.whitehouse.gov.

will be treated with less trust. For example, all hosts that use dynamic DNS might have such names as myhost.dhcp.corp.example.com. Hostnames in the dhcp.corp.example.com zone might have collisions and other problems, but those problems are isolated in that one zone. This technique can be extended to the entire range of dynamic DNS updates that are required by domain controllers in Microsoft ActiveDirectory. One creates many contained areas for DNS zones with funny-looking names, such as tcp.corp.example.com and udp.corp.example.com (Liu 2001).

3.1.4.1 Managing DHCP Lease Times

Lease times can be managed to aid in propagating updates. DHCP client hosts are given a set of parameters to use for a certain amount of time, after which they must renew their leases. Changes to the parameters are seen at renewal time.

Suppose that the lease time for a particular subnet is 2 weeks. Suppose that you are going to change the netmask for that subnet. Normally, one can expect a 2-week wait before all the hosts have this new netmask.

On the other hand, if you know that the change is coming, you can set the lease time to be short during the time leading up to the change. Once you change the netmask in the DHCP server’s configuration, the update will propagate quickly. When you have verified that the change has created no ill effects, you can increase the lease time to the original value (2 weeks). With this technique, you can roll out a change much more quickly.

DHCP for Moving Clients Away from Resources

At Bell Labs, Tom needed to change the IP address of the primary DNS server. Such a change would take only a moment but would take weeks to propagate to all clients via DHCP. Clients wouldn’t function properly until they had received their update. It could have been a major outage.

He temporarily configured the DHCP server to direct all clients to use a completely different DNS server. It wasn’t the optimal DNS server for those clients to use, but it was one that worked. Once the original DNS server had stopped receiving requests, he could renumber it and test it without worry. Later, he changed the DHCP server to direct clients to the new IP address of the primary DNS server.

Although hosts were using a slower DNS server for a while, they never felt the pain of a complete outage.

The optimal length for a default lease is a philosophical battle that is beyond the scope of this book. For discussions on the topic, we recommend

3.2 The Icing 65

The DHCP Handbook(Lemon and Droms 1999) and DHCP: A Guide to Dynamic TCP/IP Network Configuration(Kercheval 1999).

Case Study: Using the Bell Labs Laptop Net

The Computer Science Research group at Bell Labs has a subnet with a 5-minute lease in its famous UNIXRoom. Laptops can plug in to the subnet in this room for

short periods. The lease is only 5 minutes because the SAs observed that users require about 5 minutes to walk their laptops back to their offices from the UNIXRoom. By that time, the lease has expired. This technique is less important now that DHCP client implementations are better at dealing with rapid change.

3.2 The Icing

Up to this point, this chapter has dealt with technical details that are basic to getting workstation deployment right. These issues are so fundamental that doing them well will affect nearly every other possible task. This section helps you fine-tune things a bit.

Once you have the basics in place, keep an eye open for new technolo- gies that help to automate other aspects of workstation support (Miller and Donnini 2000a). Workstations are usually the most numerous machines in the company. Every small gain in reducing workstation support overhead has a massive impact.