DHCP addressing vs Static addressing for Servers

I'm having a "lively" debate with a work associate about the reasons for or against using DHCP on servers in a network environment. The network environment in particular is a relatively small network, but in my experience it's always better to have servers on static addresses, especially for things like remote management, etc.

I looked, and could find any specific reasons for or against dynamic addresses assigned on servers so I figured I'd ask the crowd here.

My work associate argues for DHCP assigned server addresses for ease of management, and states if the addresses ever change you don't have to change the server IP manually. I'm dubious about this response.

For management purposes, this network being small, it's no big deal to change the IP of static devices since there's so few.

Any suggestions, ideas or comments?

Solution 1:

While there are some server functions that must have locally defined IPs, I'm a huge fan of using DHCP for server addresses.

First, as others have noted, you can (and should) use DHCP to serve up static addresses. Assuming Linux, you want this in your dhcpd.conf:

host server {
        option host-name "server.example.com";
        hardware ethernet  xx:xx:xx:xx:xx:xx;
        fixed-address server.example.com;
}

And in your DNS zone file, assign an IP to server.example.com.

Pros:

• The DNS zone file is now the 'one source of truth' for all IP assignments. Makes it easy to look for errors (duplicate IPs, typos), and ensures that everyone can find the server's IP address without error
• Changes to network infrastructure can be propagated easily. Rolling out a backup DNS server? Just add it to the DHCP config file, and all systems will pick it up as they renew their leases.
• Changes to the machine's IP and the machine's DNS entry can't, by definition, get out of sync. Moving a machine to a new subnet? Change the IP in exactly one place, and you're all set.

Cons:

• You've added a significant point of failure. Mitigate that with backup DHCP server. Long lease times can also help.
• Spanning tree learning mode blocks DHCP requests, which can significantly lengthen machine boot times, and even cause DHCP timeouts. Use portfast to turn off spanning tree on select ports. Good idea for workstation, too, by the way.

Solution 2:

Why hasn't the combination of something like cfengine or puppet and static IP addresses been brought up? From a bird's-eye view, it's the best of both -- centralized configuration without the loss of a critical-path service to worry about. Does it provide a central way to screw things up? Yes, but so does DHCP.

In larger installations where I have worked, this was all accomplished with a combination of managed kickstarts and cfengine...and it worked beautifully. Additionally, most if not all VPS providers use a provisioning tool that calculates IP addresses and sets them statically in the created instance as well -- another example of configuration management + static IP addresses.

For a sufficiently large installation you should be using configuration management and close to fully automated deployment as-is, not to mention change control procedures that would have these procedures spelled out (ideally).

Solution 3:

The biggest issue I see with DHCP being used for servers is that if, for some reason, the DHCP service ever goes down your servers can lose their IP addresses. In addition to that, there's also the security risk of being able to Man-In-The-Middle the servers by controlling their DHCP leases (which controls the default gateway). And, as other posters have said, some servers/services require static IP addresses (domain controllers are a prime example).

Solution 4:

I don't agree with the idea of using DHCP for servers - though on very large networks I can imagine this might blur a little - but its a matter of preference rather than a hard and fast thing imho - you can reserve addresses for servers etc (though if you do that then why not just make 'em static which brings me back to why I don't agree with it...).

I think a few server applications either require static IP addresses explicitly, or don't behave at all nicely if their address does happen to change. For me those tend to point hard to it being a bad idea.

Solution 5:

You want to use STATIC ip addresses with servers that require public to private IP translations. For instance, an email or website server sitting behind a firewall that should be accessible from the internet. Anything that is providing domain services should also use STATIC. Most anything else can use DHCP but use with caution as it has its potential pitfalls as others have mentioned.