Is your DHCP Server Authoritative?

Possibly the single most annoying misconfiguration of the ISC DHCP Server today is forgetting to set the 'authoritative;' directive, when doing so is appropriate.

When a DHCP server believes that a client is requesting an address that is not appropriate for the subnet to which it is attached, for example because a user's laptop received a lease from their home network the night prior, the server is expected to send a DHCPNAK in response to the client's DHCPREQUEST. This causes the client to immediately fall back to INIT state, forget its old lease, and start over from scratch as though it never had one. Out of the box, on a default configuration, ISC DHCP does not do this, and you are expected to configure 'authoritative;' on a line somewhere in your dhcpd.conf if you want this behaviour.

This means that the client will not start getting a lease until it gives up, on its own volition, on its old lease. Client implementations being different, there is nothing barring the client from trying to hold on to its old lease until it reaches its expiry time! Most clients however don't make you wait quite that long, and time out after several minutes.

If ISC DHCP's default configuration directive included this behaviour, than one of its chief uses, as a rogue DHCP server on college campuses, would cause extreme havoc and mayhem and possibly the deaths of several undergraduate students who don't realize the horror of attracting their operators' attentions.

So, if your DHCP server is the only one on the network, or the only one that SHOULD be on the network, or in general if you are in charge of the network to which it is attached and are therefore smart enough to not have more than one (or one failover pair) DHCP server, then you need to set 'authoritative'.

That said, it's still possible that ISC DHCP won't send a DHCPNAK in response to some queries. In particular, to requests for addresses that are within the DHCP server's subnet ranges, and are therefore reasonable for the network to which the client is attached, but do not appear in any pool statement, or host statement's fixed-address, or so forth. Quite often this ocurrs when DHCP pools are migrated, and the DHCP server is just trying to play nice in the event that another DHCP server is in charge of a different pool on the same subnet (and somehow your clients are configured to be smart enough to choose which lease to ask for).

You can tell that this is happening because ISC DHCPD will log a line indicating "Unknown lease."

To elicit DHCPNAKs from the server in this case, you need to configure a denial in the old pool's scope, as this example:

lease-file-name "/var/db/dhcpd.leases";

ddns-update-style none;
authoritative;

option domain-name "your.domain";
option domain-name-servers 10.0.0.2, 10.0.0.3;

default-lease-time 3100;	# 51 minutes.
max-lease-time 604800;		# 1 week


subnet 10.0.0.0 netmask 255.255.255.0 {
	option routers 10.0.0.1;
	option subnet-mask 255.255.255.0;
	option broadcast-address 10.0.0.255;

	# The latest input from layer-9 required us to shift the dynamic
	# range from the top half of the subnet down to the bottom half.
	# This pool clause will elicit NAKs for the old leases while the
	# clients migrate.  Remember to remove this once they've all booted
	# once or expired.
	pool {
		range 10.0.0.1 10.0.0.127;
		deny all clients;
	}
	pool {
		range 10.0.0.128 10.0.0.254;
	}
}