Explainer · In review
DNS for HR-Driven Identity Across Clouds
A plain-language explainer: what the HR-to-identity pipeline must resolve across Oracle, Azure, AWS, VMware and on-premises, when private DNS and forwarding are needed, and how it breaks
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.
Federal HR 2.0 puts an agency’s core HR records in Oracle Fusion Cloud HCM, a SaaS service, and Book 03 builds HR-driven identity on it: middleware reads changes from Oracle and posts them to Microsoft Entra ID’s API-driven inbound provisioning, which feeds Entra accounts, Lifecycle Workflows and, while it exists, Active Directory. This explainer asks what that pipeline needs from DNS when the agency also runs Azure, AWS (including the Amazon Connect contact center), VMware and its own data centers, and whether that three- to five-way estate can break it.
Watch or download
Jump to a slide (12)
| Edition | File |
|---|---|
| Deck, presented live (about 17 minutes) | Research_HR_Identity_DNS.pptx |
| Narrated, self-running (about 9 minutes, captions) | Research_HR_Identity_DNS_Narrated.pptx |
| Narration script and caption track | Script · Captions |
The answer in brief
- Almost every name in the pipeline is public and vendor-owned: the Oracle Fusion host, Microsoft Graph and Entra sign-in, the provisioning agent’s relay names, and Amazon Connect’s endpoints. The agency resolves them through public DNS and must never put them in a private zone. Private DNS and forwarding are needed only for the agency’s own names (domain controllers, internal APIs, VMware) and for cloud private endpoints.
- Oracle’s “private access” for Fusion is routing, not DNS. Traffic reaches Oracle’s public addresses through a private path; the Fusion name keeps its public answer, so no private zone is built for it. Because the middleware pulls Oracle’s change feeds and Oracle may purge feed data, a long DNS or network outage on the middleware can lose HR events; reconcile against full extracts.
- Government clouds use different names. Microsoft Graph and sign-in, and the provisioning agent’s endpoints, differ between the commercial, GCC High and higher government clouds, and the agent must not sit behind TLS inspection.
- The clouds disagree on precedence. When a private zone and a forwarding rule both cover a name, AWS follows the rule, Azure uses the private zone and ignores the rule, and Oracle checks its private views first. One owner per name, with forwarding to it, is the only design that behaves the same everywhere.
- Hub, not mesh. Pairwise forwarding between five environments means up to twenty one-way rule sets; a hub (a DDI grid or one resolver hub) means about five, with one place to log every query. The three- to five-way estate doesn’t break HR-driven identity as long as no one shadows a vendor’s domain and every private zone has one owner.
Status and review
In review. Every claim was checked against Oracle, Microsoft, AWS, Broadcom and Infoblox documentation and FedRAMP Marketplace data on October 22, 2026; facts taken from Microsoft Learn search excerpts are marked as such. Open checks, including which Oracle environment an agency’s Core HCM tenant uses, and Azure Government availability of DNS Private Resolver, are listed in the deck’s backup section. Microsoft Learn’s feature-availability page lists API-driven inbound provisioning, which the bulk upload endpoint serves, as available in Azure Government (read November 1, 2026, in the HR-driven identity guide), so that check is closed here; the deck’s backup list still carries it. Comments and corrections are welcome as issues on GitHub.
Related: Book 03 — HR-Driven Identity, Book 08 — DNS, DHCP & IPAM, and the research items Trinzic Alone, or Trinzic Plus Cloud DDI? and Who Names the Device After AD?.