IIRC that hostname is evaluated by the DHCP at restart time and then the resulting IP is used in the configuration.
Because that's a valid hostname in our DNS it would have just used that IP. So not sure how to "prevent" this.

My related work on T306661 would also remove completely the need to have that file hardcoded, it will be auto-generated from Netbox data, so probably not worth to invest too much in consistency checks.

That said, if we can have better DHCP logging I'm all for it.

I agree @jbond it would be useful to have more granular detail.

When we don't have a "match" on the dhcp snippet then we end up with a log like this:

DHCPDISCOVER from e4:3d:1a:54:10:30 via 10.64.143.1: network 10.64.143.0/24: no free leases

You can work out the source host from the MAC address, comparing it to the switch/host NIC, but it's not terribly straightforward. It would be nice if DHCPd could be made log the contents of the Option 82 data along with these. I had a brief look at some docs, and it does seem possible to tell DHCPd to include the Option 82 data in logs:

log-facility local0;
if exists agent.circuit-id
{
log ( option agent.circuit-id);
}

Or some people getting more exotic:

if exists agent.circuit-id
{
        set ClientMAC =  binary-to-ascii (16, 8, ":", substring
(hardware, 1, 6));
        set Vlan = binary-to-ascii (10, 16, "", substring( option
agent.circuit-id, 2, 2));
        set SwitchMac = binary-to-ascii(16, 8, ":", substring( option
agent.remote-id, 2, 6));
        set LeasedIP = binary-to-ascii (10, 8, ".", leased-address);
        set SwitchSlot = binary-to-ascii (10, 8, "", substring ( option
agent.circuit-id, 4,1));
        set SwitchPort = binary-to-ascii (10, 8, "", substring ( option
agent.circuit-id, 5,1));
 
        log ( info,
concat("BEGIN|",SwitchMac,"|",SwitchSlot,"|",SwitchPort,"|",Vlan,"|",Cli
entMac,"|",LeasedIP,"|END"));
}

But it unfortunately (as of 10+ years ago anyway), seems like this only works when the server returns an offer. It seems in a failure scenario it never logs the Option 82 info:

https://lists.isc.org/pipermail/dhcp-users/2010-March/011386.html

Thanks for looking at this @Volans @cmooney

Because that's a valid hostname in our DNS it would have just used that IP. So not sure how to "prevent" this.

Doh!

It seems in a failure scenario it never logs the Option 82 info:

that's frustrating, as its the failure that's most interesting :(. if responses are been sent we can always troubleshoot with tcpdump