Vol VIII Book 00 — Federal Compliance — Volume VIII Overview: Multi-Cloud DDI Landing-Zone Automation
The InfoBlox DDI landing-zone kit, merged into the series as a named volume — one authoritative naming plane across Azure, AWS, GCP, OCI, and VMware
0.1 Draft Proposal — Subject to Review
This document is a draft proposal developed by the CSI Team (Cloud Services Infrastructure). It has not been reviewed or approved by the Agency CIO Office, the Office of Information Security (OIS), or organizational leadership.
Date Code: 2026-07-19 16:20 ET
Series Context — This is the Volume VIII overview of the Federal Compliance series. Volume VIII is the multi-cloud DDI (DNS, DHCP, IPAM) landing-zone automation kit — the deep, per-platform implementation of the naming plane that Vol I Book 01 (Cloud Landing Zone, IPAM/DDI) establishes at the architecture level. Its chapter content is the repo-root infoblox-ddi-book/ kit, an independently distributable book; this volume binds it into the series through the compliance spine, this overview, and cross-references — the series’ “one program, one spine, named volumes” model.
0.2 Scope note — this volume is intentionally multi-CSP
The rest of this task narrows to FedRAMP Moderate + Microsoft GCC Moderate (Vol VII). Volume VIII is the one deliberate breadth exception, by author direction (2026-07-12): it spans Azure, AWS, Google Cloud, OCI, and VMware. DDI is a foundation service every landing zone needs regardless of CSP, and the kit’s value is precisely the cross-cloud comparison — so it is merged whole rather than trimmed to Azure. The GCC-Moderate governance boundary still applies to the ServiceNow orchestration chapter (its §7.4), which is where federal control closure is operated; the per-CSP chapters are the mechanism build-out beneath it.
1 What This Volume Addresses
The architecture volumes name the naming plane as a truth plane: authoritative DNS, DHCP, and IP address management are the source of truth every other plane depends on to find, address, and inventory what it governs (SC-20/21/22, CM-8). Vol I Book 01 argues why that plane is required and why no scanner can author it. This volume is the deployable realization of that plane, worked one CSP at a time — a platform engineer can take any chapter from a blank landing zone to a production-grade Infoblox DDI and DNS-security layer inside it, then read the ServiceNow chapter to put a governed, audited front door on the whole thing.
The strategic argument for unified DDI — why per-CSP DNS sync fails, the AD DNS departure, the certificate-DNS surface, and the Cisco Catalyst SD-WAN interception problem — is developed in the companion whitepaper Next Generation DNS; this volume is the per-platform build-out beneath that argument.
Because DDI is the join key the rest of the series reconciles to — the CMDB (Vol VII Book 01), the multi-CSP patch queue (Vol III Book 03), and the evidence fabric (Vol III Book 07) all key on the authoritative asset identity IPAM owns — this volume is upstream of much of the program. It is placed last in reading order only because it is the deepest implementation detail; in dependency order it is near the root.
2 Books in This Volume
Each book below is a chapter of the infoblox-ddi-book/ kit; the volume overview (this book) is the series front door to it. Chapter files are referenced by path, not relocated, so the kit stays independently distributable and its existing cross-references and CI coverage are undisturbed.
| Book | Chapter (in infoblox-ddi-book/) |
Role |
|---|---|---|
| Vol VIII Book 00 | (this overview) | Series front door; scope note; the volume’s control-closure roll-up |
| Vol VIII Book 01 | 01-azure.md |
DDI on Microsoft Azure (Azure DNS/DHCP; IPAM automation) |
| Vol VIII Book 02 | 02-aws.md |
DDI on Amazon Web Services (Route 53; VPC IPAM) |
| Vol VIII Book 03 | 03-gcp.md |
DDI on Google Cloud (Cloud DNS; IPAM) |
| Vol VIII Book 04 | 04-oci.md |
DDI on Oracle Cloud Infrastructure (OCI DNS; IPAM) |
| Vol VIII Book 05 | 05-vmware.md |
DDI on VMware (VCF / vSphere / NSX-T) |
| Vol VIII Book 06 | 06-cross-platform-operations.md |
Cross-platform operations & multi-cloud governance (the naming-plane roll-up) |
| Vol VIII Book 07 | 07-servicenow-orchestration.md |
ServiceNow orchestration — the governed, GCC-Moderate front door (§7.4 control mapping) |
| Vol VIII Book 08 | 08-servicenow-led-implementation.md |
ServiceNow-led implementation strategy |
| Vol VIII Appendix A | appendix-A-sizing-cost-ipv6-dhcp.md |
Sizing, cost, IPv6/dual-stack, and DHCP guidance |
3 How This Volume Fits the Program
Volume VIII is the deployable realization of Vol I Book 01’s naming plane and the multi-cloud build-out of the DDI/IPAM necessity the series anchors there. It is depended on by:
- Vol VII Book 01 (CMDB Reconciliation) — the ServiceNow CMDB reconciles every M365/Azure CI to the authoritative IPAM/DDI identity this volume stands up (the CM-8 join key).
- Vol VII Book 05 (The ServiceNow Compliance App) — generalizes this volume’s ServiceNow orchestration pattern (Book VIII-07: catalog → approval/SoD → apply → validation gate → CMDB close) from DDI provisioning to control-compliance work.
- Vol III Book 03 / Book 07 — the multi-CSP patch queue and evidence fabric key on the same authoritative asset identity.
Truth is separated from enforcement, as everywhere in the series: the DDI/IPAM plane this volume builds is a truth plane (depended on, not re-platformed casually); the per-cloud provisioning pipelines and the ServiceNow front door are enforcement/coordination planes on top of it.
4 Governance Boundary
The per-CSP chapters are the mechanism build-out and are CSP-agnostic by design. Federal control closure is operated at the ServiceNow front door (Book VIII-07 §7.4), which coordinates the GCC-Moderate boundary: the ServiceNow Government Cloud platform holds FedRAMP High authorization and coordinates a Moderate boundary — the High-on-Moderate boundary treatment (High conservatively encompasses the Moderate baseline; the CMDB reconciles to IPAM/DDI, never replaces it) is stated once in Vol VII Book 00 §“Authorization Boundary Treatment — ServiceNow High-on-Moderate” and inherited here without restatement. The instance runs a MID Server in-boundary so credentials and Terraform execution never leave the ATO boundary, and the Universal DDI SaaS path is gated by an explicit boundary acknowledgment. The catalog approval, the change record, the validation-gate verdict, and the CMDB reconcile are the audit evidence — the same coordination discipline Volume VII applies to M365 and Azure compliance.
6 Cross-References
infoblox-ddi-book/— the chapter content of this volume (independently distributable kit).- Vol I Book 01 (Cloud Landing Zone, IPAM/DDI, FedRAMP) — the architecture-level naming-plane necessity this volume realizes.
- Vol VII Book 01 / Book 05 — the CMDB reconcile and the ServiceNow compliance app that build on this volume’s IPAM/DDI identity and orchestration pattern.
federal-compliance-compliance-spine.yml— the SSOT registering this volume (vol-8) and its control closures.
7 Provenance
This overview merges the InfoBlox DDI landing-zone kit into the Federal Compliance series as Volume VIII, by author direction. The chapter content is not relocated — it remains the repo-root infoblox-ddi-book/ kit and keeps its own conventions and figures; this volume binds it to the series via the spine, this overview, and cross-references. The multi-CSP breadth is a deliberate, author-directed exception to the task’s GCC-Moderate scope. Vendor claims in the chapters cite vendor documentation per the kit’s own references. The volume map above is authored as committed house-style SVG (rasterized to PNG).
8 Where This Volume’s Evidence Lands — Volume X (Optional)
Where the closures and evidence this volume produces bind to the governance substrate — the conformance layer, the surface slots, and the evidence contract — is documented once, for the whole series, in Vol X Book 00 — Governance-Substrate Integration. The binding is optional and separable: this volume, and the series it belongs to, stands complete at FedRAMP Moderate with no substrate engagement at all; adopting the substrate adds machine-checked scoring and drift-gating on top of what is already closed, and can be adopted later — or never — without rework.