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.