The idea
On a closed equipment network, an unknown device getting an address is a problem, not a convenience. This dnsmasq setup only hands out leases to MAC addresses on an allowlist. Everything else is ignored.
How it works
dnsmasq tags each known device, then ignores any request without that tag. An illustrative config (documentation-range addresses, not a real network):
# Only answer on the equipment interface
interface=eth1
bind-interfaces
# Address pool for known devices
dhcp-range=set:av,198.51.100.50,198.51.100.199,12h
# Allowlist: one line per approved device
dhcp-host=aa:bb:cc:00:00:01,set:known,av-encoder-01,198.51.100.51
dhcp-host=aa:bb:cc:00:00:02,set:known,av-decoder-01,198.51.100.52
# Anything not on the list gets nothing
dhcp-ignore=tag:!knownAdding VLANs is another dhcp-range with its own tag on its own interface or sub-interface.
The onboarding SOP
The server is only as good as the process for adding devices. The Restricted DHCP Device Onboarding SOP went from v2 to v5, with the goal of making a new device a short, repeatable checklist instead of tribal knowledge.
Cleaning up a test without breaking production
To prove the multi-VLAN setup, I added a temporary second interface and address range. Taking it back out was harder than adding it. Some ranges were declared twice and a few config lines looked odd, so a blind delete could easily have broken the working setup. I made sure the known-good production path was intact first, then removed only what I understood.
One honest limit
An allowlist like this keeps unknown devices from getting an address. It doesn’t stop someone from setting a static address by hand. It’s a useful control, not a security boundary on its own.
Tutorial to come
A full walk-through of building this from scratch.