Book 08 — DNS, DHCP & IPAM

Governing DNS, DHCP and IPAM as the hybrid multi-cloud control plane: why DNS is now the control plane, what has to change, who owns it, and how to migrate and run it

Book 08 of the Modernization Workbook: why DNS is now the control plane, split-brain DNS, federal requirements, the Active Directory DNS departure, edge interception and encrypted DNS, DNS identity and DNSSEC, cloud private endpoints and IPAM, the reference architecture and its five critical decisions, who owns DNS, DHCP and IPAM, the migration sequence, operating the control plane, and platform selection, cost and residual risk.

Book 08 — DNS, DHCP & IPAM: The Hybrid Multi-Cloud Control Plane

Status — draft book

This book brings together the workbook’s Next Generation DDI series, the Next Generation DNS whitepaper, the DNS Modernization Guide and the DNS record-type reference. Every external claim was checked against a primary source on October 20, 2026 and carries a footnote. The earlier pages are kept in the repository’s archive/b08-ddi/ folder, and their old addresses forward to the chapters that replaced them.

Download and present

b08-ddi-bundle.docx: the whole book as one Word document, regenerated on every site deploy.

15-minute presentation: the Why / What / Who / How deck and its narrated, self-running version are in the repository under presentations/b08-ddi/.

DNS was designed to answer one question: what is the address for this name? In a hybrid multi-cloud agency it now does far more. It publishes private endpoints, selects SaaS front doors, enforces security policy, anchors certificate validation and defines the application surface that Zero Trust policy is written against. Most agencies still run it as a commodity utility spread across independent platforms: Active Directory DNS or an on-premises DDI grid, AWS Route 53, Azure DNS, Google Cloud DNS and VMware NSX. The result is split-brain DNS that breaks private connectivity, certificate trust and Layer 7 policy at once, and that shows up as certificate errors and access denials rather than DNS errors. This book makes the case for one authoritative DDI policy plane, and walks through who owns it, how to get there and how to run it.

Why, what, who, how

Four cards left to right. Why, the problem, in red: Chapters 01 DNS is the control plane, 02 split-brain DNS and 03 federal requirements. What, the hard surfaces and the answer, in blue: Chapters 04 AD DNS departure, 05 edge interception, 06 DNS identity and DNSSEC, 07 private endpoints and IPAM, and 08 reference architecture. Who, the owners, in violet: Chapter 09 who owns DNS, DHCP and IPAM. How, running it, in green: Chapters 10 migration sequence, 11 operating the plane and 12 selection, cost and risk. — The book’s four questions and the chapters that answer each.

	Question	Chapters
Why	Why is DNS now the control plane, why does split-brain DNS follow, and what do federal requirements demand?	01, 02, 03
What	What the hard surfaces are, from AD DNS to cloud private endpoints, and what architecture answers them	04, 05, 06, 07, 08
Who	Who decides and who does the work for DNS, DHCP and IPAM	09
How	Migrate in six phases, operate and evidence the control plane, and choose a platform knowing the cost and residual risk	10, 11, 12

Appendices: A — DNS record types and ecosystem integrations · B — Requirements mapping and sources · C — Applicability

Start with Appendix C if you work in GCC High, DoD or an air-gapped environment. It sets out which statements in the chapters change at higher impact levels.

The canonical sequence

Every chapter aligns to one sequence. It is the order in which the work is done, and the order in which evidence accumulates:

Inventory → Coexist → Migrate authority → Federate clouds → Decommission AD DNS and DHCP → Harden and evidence

Five configuration decisions carry most of the risk along the way. Each is settled in Chapter 08 and checked in Chapter 11:

Decision	Settled in	Phase
1. redirect-dns targets a network-addressable agency resolver	Ch 05, Ch 08	Migrate authority
2. The agency resolver is the first hop; other resolvers are its forwarders	Ch 05, Ch 08	Migrate authority
3. The policy plane holds every per-cloud conditional forwarding rule	Ch 07, Ch 08	Federate clouds
4. AD DNS is inventoried and reprovisioned before any domain controller goes	Ch 04, Ch 10	Inventory, Decommission
5. OCSP and CRL endpoints resolve from every origin	Ch 06, Ch 08	Federate clouds, Harden

Reading paths

Executives (20 minutes): Chapters 01, 03, 08 and 09, or the 15-minute presentation.
Enterprise and network architects: Chapters 01, 02, 07, 08, then 10.
Identity architects: Chapters 04 and 06, then 10.
Network and security engineers: Chapters 05, 06, 07 and 10, with Appendix A at hand.
Program managers: Chapters 01, 09, 10 and 12.
GCC High, DoD or air-gapped readers: Appendix C, then Chapters 03, 05, 07 and 11.

Where this book sits in the workbook

This is Book 08 of the Modernization Workbook. Book 02 — Identity & Directory finds DNS, DHCP and IPAM among the hidden dependencies on Active Directory. Book 05 — Devices & Endpoints moves the clients whose resolver settings change here, and Book 07 — PKI & Certificates depends on the revocation endpoints this book keeps resolvable. For the implementation and control-closure detail, see the Federal Compliance volume on Multi-Cloud DDI automation and the landing zone and IPAM book; for the services view inside the wider program, see Client-Server to Hybrid-Cloud, Chapter 06.

Platform-specific examples are illustrative; evaluate every option against the architectural requirement of a single authoritative policy plane. Footnotes cite primary sources (federal documents, IETF standards and the cloud providers’ own documentation) wherever one exists; the few third-party sources are labeled as such, and Appendix B lists both groups separately.

Chapters

Title	Description
Chapter 01 — DNS Is Now the Control Plane	Why DNS, DHCP and IPAM can no longer be run as a commodity utility: what DNS now does in a hybrid multi-cloud agency, how fragmented it has become, and the case for one authoritative DDI policy plane.
Chapter 02 — Split-Brain DNS: The Structural Problem	What split-brain DNS is, how it breaks private connectivity, SaaS endpoint selection and security policy without producing a DNS error, why process discipline can’t fix it, and what fragmented DDI costs.
Chapter 03 — Federal Requirements: NIST SP 800-81, FedRAMP and Zero Trust	What federal policy actually requires of the name layer: OMB M-22-09 encrypted DNS, CISA Protective DNS, M-21-31 DNS logging, DNSSEC, IPv6, TIC 3.0, NIST SP 800-81 Rev. 3, FedRAMP authorization of a cloud-delivered policy plane, and the SP 800-53 control mapping.
Chapter 04 — The Active Directory DNS Departure	What AD-integrated DNS and Windows DHCP actually do for a domain — zones stored in the directory, domain controller locator records, secure dynamic updates, conditional forwarders, GlobalNames and DNSSEC keys — why none of it moves to Microsoft Entra ID, and what must be found and reprovisioned before any domain controller is retired.
Chapter 05 — Edge Interception, Encrypted DNS and Rogue DHCP	The three ways a query escapes the governed resolver path: an SD-WAN edge that redirects DNS to the wrong place, encrypted DNS that terminates at an ungoverned resolver, and a rogue DHCP server or router advertisement that hands out an attacker’s resolver; with what Cisco Catalyst SD-WAN, Windows, the major browsers, CISA and NIST each document about controlling them.
Chapter 06 — DNS Identity, Certificates and DNSSEC	Why the name layer is the first link in the trust chain for certificates, FQDN-based policy and tokens: how the move from Kerberos to Entra ID tokens changes the DNS surface, how certificate split-brain presents as a PKI failure, how wildcards and name constraints scope trust, what DNSSEC does and doesn’t provide, what NIST SP 800-81r3 and SP 800-53 require of it, and how Windows Server, Azure DNS and Route 53 support it.
Chapter 07 — Cloud Private Endpoints, SDN and IPAM Consistency	How each cloud and VMware implements private DNS, how Azure private endpoints and the Azure DNS Private Resolver must be wired so every origin gets the private answer, the hybrid resolution patterns, and how enterprise IPAM stays the authority for address space across AWS, Azure, Google Cloud and VMware.
Chapter 08 — Reference Architecture and the Five Critical Decisions	The end-to-end governed resolution path, the five configuration decisions that carry almost all of its operational risk and how to check each one, the components of a DDI policy plane, the move from per-cloud syncs to one authoritative state, how the design changes across commercial and federal clouds, and the questions still open with vendors.
Chapter 09 — Who Owns DNS, DHCP and IPAM	Who decides, who does the work and who is consulted when DNS, DHCP and IPAM move from Active Directory and per-cloud silos to one policy plane, with a responsibility matrix, a record-change model and the roles each team needs in each system.
Chapter 10 — The Migration Sequence	The six-phase sequence from AD-integrated DNS and DHCP to a single authoritative policy plane: what to inventory, how coexistence works, how authority moves zone by zone with a rollback point at every step, how clients and DHCP scopes cut over, and the gates that must pass before AD DNS and DHCP are decommissioned.
Chapter 11 — Operating the Control Plane: Delegation, Automation and Evidence	What the single DDI policy plane must support once it is running: scoped delegation for divisions, API-first automation, ITSM and identity integration, ACME certificate automation, the logging and monitoring that M-21-31 and continuous monitoring require, drift and SRV checks, record hygiene, a troubleshooting reference and the evidence checklist.
Chapter 12 — Platform Selection, Cost and Residual Risk	How to choose a DDI platform model against evidence rather than a vendor list, what it costs to run, what to ask vendors before committing, and which risks remain after a single policy plane is in place.
Appendix A — DNS Record Types and Ecosystem Integrations	A practitioner catalog of the DNS record types that matter to federal hybrid multi-cloud security, certificate governance and service routing, with the standard behind each and how split-brain DNS affects it; a security-integration matrix; the integration surface a DDI platform needs; and a glossary.
Appendix B — Requirements Mapping and Sources	A compliance-enabling crosswalk, not a compliance claim: each federal requirement that touches DNS, DHCP and IPAM (OMB M-22-09, M-21-31, M-08-23 and M-21-07, CISA Protective DNS and BOD 18-01, TIC 3.0, NIST SP 800-81 Rev. 3, SP 800-53 Rev. 5 and FedRAMP), what it actually asks, where the book addresses it and the evidence it calls for, followed by every source the book cites.
Appendix C — Applicability	Which parts of the book apply as written in commercial cloud and GCC-Moderate at FedRAMP Moderate, and what changes in GCC High, Azure Government and AWS GovCloud, DoD impact levels 4 and 5, and air-gapped or classified networks. Platform facts are as of October 20, 2026.