Explainer · In review
Who Names the Device After AD?
A plain-language explainer: what names client PCs, Macs, Linux machines, servers and cloud VMs once Active Directory is gone, what registers their DNS records, and what an agency must do to keep name resolution working
Status — In review
This page is under review and is not yet part of the workbook's production guidance. Its claims are sourced, but its analysis and any recommendation are the program's working view; they may change before review is complete, and they are not endorsed by any federal agency. Last reviewed 2026-10-22.
While a device is joined to Active Directory, AD quietly does two jobs at once: the device takes its name from the domain, and it registers its own DNS record with a Kerberos-signed update to AD-integrated DNS. When AD retires, both jobs need a new owner. This explainer, written for architects still learning the area, shows who takes each one, what breaks if nobody does, and what an agency must do before, during and after the cutover.
Watch or download
Jump to a slide (13)
| Edition | File |
|---|---|
| Deck, presented live (about 17 minutes) | Research_Device_Naming.pptx |
| Narrated, self-running (about 10 minutes, captions) | Research_Device_Naming_Narrated.pptx |
| Narration script and caption track | Script · Captions |
The answer in brief
- The name comes from provisioning, not the directory. Windows PCs are named by an Autopilot template (classic Autopilot: 15 characters; Autopilot device preparation: up to 63, but only for devices bound through device association) or renamed in Intune. Macs have no enrollment-time naming template in Intune and are renamed after enrollment. Linux takes its name from cloud-init or a static hostname, servers from the build pipeline, and cloud VMs from their deployment. Azure Arc keeps the hostname a server already has.
- The DNS record should come from DHCP or the pipeline, not the device. Without Kerberos, a device can’t sign its own update to a secure-only zone, and Windows tries an unsigned update first, so the zone should accept updates only from the DHCP servers and the provisioning pipeline. DHCP registers the device’s name for the life of its lease (DHCPv4 option 81; DHCPv6 option 39) and removes the records when the lease ends; servers get records from the same pipeline run that builds them.
- Three gaps catch agencies out. IPv6 addresses a device assigns itself (SLAAC and temporary “privacy” addresses) never reach a DHCP server, so endpoints get no AAAA records by design. Remote and VPN clients are resolved through services such as Microsoft’s Global Secure Access but aren’t documented as registered. And on migration, Infoblox’s default ownership-record mode doesn’t recognize records Microsoft DHCP created, so updates fail until the mode and the existing records are reconciled; rotating Wi-Fi addresses on Macs break the same ownership check.
- Names still matter after AD, for help desk tools, Kerberos islands, certificates with DNS names, and as the join key in the workbook’s evidence contract (Book 12), so the checklist keeps them unique, registered and clean.
Status and review
In review. Every claim was checked against primary sources (Microsoft Learn, Apple, the IETF RFCs, systemd and cloud-init, AWS and Infoblox documentation) on October 22, 2026; inferences are labeled as inferences, and what couldn’t be verified (including macOS dynamic DNS behavior and Windows registration of temporary IPv6 addresses) is listed in the deck’s backup section. This research also corrected Book 05, Chapter 04 for Autopilot device association. Comments and corrections are welcome as issues on GitHub.
Related: Book 05 — Devices & Endpoints, Book 08 — DNS, DHCP & IPAM, and the research items Trinzic Alone, or Trinzic Plus Cloud DDI? and DNS for HR-Driven Identity Across Clouds.