Is your DHCP Server Authoritative?
Possibly the single most annoying misconfiguration of the ISC DHCPServer today is forgetting to set the 'authoritative;' directive, whendoing so is appropriate.
When a DHCP server believes that a client is requesting an addressthat is not appropriate for the subnet to which it is attached, forexample because a user's laptop received a lease from their home networkthe night prior, the server is expected to send a DHCPNAK in responseto the client's DHCPREQUEST. This causes the client to immediately fallback to INIT state, forget its old lease, and start over from scratch asthough it never had one. Out of the box, on a default configuration, ISCDHCP 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 itgives up, on its own volition, on its old lease. Client implementationsbeing different, there is nothing barring the client from trying to holdon to its old lease until it reaches its expiry time! Most clientshowever don't make you wait quite that long, and time out after severalminutes.
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 severalundergraduate students who don't realize the horror of attracting theiroperators' attentions.
So, if your DHCP server is the only one on the network, or the only onethat SHOULD be on the network, or in general if you are in charge of thenetwork to which it is attached and are therefore smart enough to not havemore 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 inresponse to some queries. In particular, to requests for addresses thatare within the DHCP server's subnet ranges, and are therefore reasonablefor the network to which the client is attached, but do not appear inany pool statement, or host statement's fixed-address, or so forth. Quiteoften this ocurrs when DHCP pools are migrated, and the DHCP server isjust trying to play nice in the event that another DHCP server is incharge of a different pool on the same subnet (and somehow your clientsare 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 lineindicating "Unknown lease."
To elicit DHCPNAKs from the server in this case, you need to configurea 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 weeksubnet 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;}}