Summary of "DHCP is NOT your inventory (and 3 better options to manage your DNS records)"

High-level thesis

DHCP is not a reliable inventory source for DNS. Modern clients randomize MACs/hostnames and use privacy features (especially with IPv6), so DHCP records are noisy, transient, and spoofable. Putting DHCP-supplied names directly into DNS produces garbage and creates race/conflict problems.

Problems (technical details)

DHCPv4 flow (observed in capture): Discover → Offer → Request → Ack.
- Clients send broadcasts with options, a client-id (often a randomized MAC), and a client hostname that is frequently generic (e.g., “MacBook Air”) or device-serial-like for IoT.
MAC randomization
- Per-SSID randomization and periodic rotation make MACs useless as stable hardware identifiers.
Client-provided hostnames
- Often generic, invalid for DNS (spaces, serials), or duplicated across devices → conflicts or overwrites in DNS.
Historical use of DHCP logs as “inventory”
- DHCP/DHCPv6 logs were commonly used for inventory but are inherently unreliable — broadcasts are spoofable and identifiers are transient.
IPv6 autoconfiguration
- Hosts pick addresses from router-advertised prefixes (RA). RAs provide prefixes but not an authoritative list of which hosts chose which addresses.
- Privacy addresses and EUI-64 behavior mean the network cannot rely on DHCP-like logs for a trustworthy inventory.

Three recommended alternatives

1) mDNS (multicast DNS + DNS-SD) — best for home / small LANs

Purpose: zero-configuration service & host discovery (hostname.local) without a centralized DNS server.
Demo notes: devices advertise host/service names (e.g., spaceship3.local) and corresponding IPv4/IPv6 addresses via mDNS.
How-to tips:
- On desktop Linux, install avahi-daemon.
- Edit nsswitch.conf to include mdns (on Debian, change mdns4 → mdns to support IPv6).
- Works well for phones, laptops, printers, home automation (AirPrint, AirPlay, Matter).
Limitations:
- mDNS is link-local multicast and breaks when networks are heavily segmented (VLANs).

2) Inventory-driven DNS / Automation — best for servers and managed environments

Principle: maintain a true authoritative inventory (NetBox, Active Directory, CMDB) and publish DNS entries from that source instead of relying on DHCP.
Options / workflows:
- Export inventory periodically to zone files or integrate via plugins (e.g., NetBox plugins for BIND zone generation or live queries).
- Integrate DNS updates into provisioning automation (Ansible, provisioning playbooks).
Demo workflow (example):
- Ansible playbook clones a Proxmox cloud template, reads VM config (including net0 MAC), computes IPv6 (EUI-64) from MAC, and posts hostname/IP to Technitium DNS via its API.
Benefits:
- Deterministic records for servers, resistant to DHCP spoofing, no reliance on transient client broadcasts.

3) Secure Dynamic DNS via RFC 2136 (nsupdate) with TSIG — best for client-managed dynamic updates

Overview: use the standard DNS UPDATE protocol (nsupdate) authenticated with TSIG keys (RFC 2136 + TSIG).
How-to (demo summary):
- Create a per-host TSIG key in the DNS server (e.g., Technitium DNS).
- Install bind9-utils (provides nsupdate) on the host and store the TSIG key (e.g., /etc/tsig.key).
- Script the dynamic update: delete old records, add A/AAAA for current addresses, and send the authenticated update.
- Configure the DNS server to allow dynamic updates for that key and restrict scope (ACL + limit to A/AAAA and the host’s own FQDN).
- Run updates on interface up or via a systemd timer for periodic refresh.
Security advice:
- Generate a unique TSIG per host so compromise is limited to that host’s DNS record.

Tools, products and protocols referenced

Tools: Wireshark (packet captures), avahi-daemon (mDNS), systemd-resolved, bind9-utils (nsupdate), Ansible, Proxmox, shell scripting.
DNS server used in demos: Technitium DNS.
Inventory/CMDB examples: NetBox, Active Directory.
Standards / protocols: DHCP / DHCPv6, IPv6 Router Solicitation (type 133) & Router Advertisement, RFC 2136 (DNS UPDATE), TSIG, mDNS / DNS-SD.

Practical recommendations / decision guidance

Home / small flat networks
- Use mDNS / DNS-SD for host and service discovery — it’s simple and what most consumer devices already use.
Servers / authoritative DNS for services
- Maintain an authoritative inventory and publish DNS via automation during provisioning (Ansible, NetBox integrations).
Hosts that must dynamically update their records
- Use RFC 2136 (nsupdate) with per-host TSIG keys and server-side ACLs limiting scope.
General rule
- Avoid relying on DHCP logs as your inventory — they are noisy, ephemeral, and easily spoofed. IPv6 privacy features do not change that core limitation.

Guides, tutorials and demos included

Wireshark DHCP capture showing Discover / Offer / Request / Ack and illustrating randomized MACs/hostnames.
mDNS capture and instructions for enabling Avahi on Debian/Proxmox (nsswitch.conf change).
Ansible playbook walkthrough: provisioning Proxmox VMs and pushing DNS records to Technitium via API (including computing IPv6 via EUI-64 from MAC).
Step-by-step nsupdate / TSIG setup: create a key in Technitium, place the key on the host, write a ddns script, configure zone ACLs, and run updates via systemd or network hooks.
Blog post referenced for full commands and scripts (presenter’s blog).

Sources / speakers

Video presenter (unnamed in subtitles) demonstrating captures, Ansible playbook, and nsupdate workflows; references his blog for scripts.
Tools/services cited: Technitium DNS, Proxmox, Ansible, NetBox, avahi-daemon, bind9-utils (nsupdate), Wireshark.
Standards/protocols reiterated: DHCP/DHCPv6, IPv6 Router Advertisements, mDNS/DNS-SD, RFC 2136 (nsupdate), TSIG.