DHCP addressing vs Static addressing for Servers

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.

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).

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).

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.

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.

You need to use DHCP reservation to reserve the assigned IPs for the servers and avoid assigning their IPs to other PCs.

You can get get best of both approaches: use DHCP for everything reserving a range for the workstations and fixing an IP to each server MAC address.