TL;DR
A multicloud design is not resilient simply because workloads can run in more than one location. Its DNS resolution paths, zone ownership, address allocation, and recovery dependencies must survive the failures the architecture claims to tolerate.
The recommended model is centralized policy, explicitly delegated authority, and resolution services distributed across the failure domains they support. That does not require one DNS product or one global IPAM platform. It requires clear ownership of names and addresses, predictable forwarding, coordinated changes, and an operating plan for disconnected or degraded conditions.
Treat DNS and IP address management as shared platform services with their own service objectives, change controls, and recovery evidence. A recovered workload is not a recovered service until its consumers can find and use it.
Introduction
Consider a hypothetical recovery exercise. A workload moves from a private-cloud site into its recovery environment. Virtual machines start, storage is available, routing converges, and the application load balancer reports healthy backends. Yet users cannot complete a transaction.
The application still sends DNS queries through the failed site. Its identity service is discoverable only through a namespace the recovery environment cannot resolve. A private endpoint exists in the cloud, but the resolver serving the recovered workload cannot see the corresponding private zone.
The compute recovery succeeded. The service recovery did not.
That is the architectural gap this article addresses. A platform can have an independent execution environment while remaining dependent on another location for the services that make execution useful. Hybrid DNS and IPAM architecture must make those dependencies explicit across VMware Cloud Foundation, Azure Local, public cloud, and edge environments.
The question is not whether each platform has working DNS during normal operation. It is whether the enterprise has a coherent naming and addressing system when those platforms fail independently, lose connectivity, or recover in a different order.
Scope, Assumptions, and Decision Criteria
This is an architecture and operating-model guide, not a product deployment runbook. It assumes multiple independently administered environments, private namespaces, and a requirement to tolerate defined infrastructure or connectivity failures. Example names are illustrative; the recovery exercises describe evidence to collect, not results from a tested implementation.
Before selecting products or placing resolvers, establish the largest failure the service must tolerate, how long a disconnected location must operate, and which changes must remain possible during that interval. A site that only needs existing applications to continue has a different requirement from one that must provision new resources while isolated.
Ownership is equally important. Decide which team controls each namespace, which allocator controls each address pool, and which native platform remains authoritative for actual resource state. Those decisions determine where centralization is useful and where it becomes a recovery dependency.
A shared enterprise policy can coexist with several native implementations. The objective is coordinated authority, not a universal control plane that conceals platform differences.
Separate DNS Authority, Resolution, IPAM, and Allocation
Four responsibilities need to remain distinct, even when one product packages them together.
| Responsibility | What it does | What it does not establish |
|---|---|---|
| Authoritative DNS | Maintains and answers for records within an authoritative zone | Client reachability or application health |
| Recursive resolution and forwarding | Finds answers for clients and routes selected queries toward other DNS services | Ownership or replication of the destination zone |
| IPAM | Organizes address-space planning, reservations, allocations, and inventory | Proof that a discovered address is safe to allocate |
| DHCP and native platform allocation | Assigns addresses within an authorized scope and maintains the relevant allocation state | Enterprise-wide authority outside that scope |
RFC 1034 establishes the distinction between authoritative namespace data and resolution. Delegation identifies an authoritative namespace boundary. Conditional forwarding configures a query path. Forwarding a question does not create another authoritative copy of the answer.
AWS’s IPAM model makes another useful separation: scopes contain pools, and pools supply allocations. DHCP adds lease state and lifetime considerations, as defined in RFC 2131. An inventory entry marked available cannot override an active lease or a native platform binding.
My recommended operating rule is simple: every namespace needs an accountable owner, every allocatable pool needs defined authority, and every resolver path needs a documented destination and failure behavior.
Centralize Policy Without Centralizing Every Dependency
The following logical model separates the change path from the query path. It is an ownership model, not proof of a highly available physical topology.
Notice that IPAM is not inserted into every DNS lookup. The proposed design should preserve existing resolution when the address-management interface is unavailable, while separately controlling whether new allocation or record publication may continue.
Each query branch still needs an implementation-specific failure review. Two resolvers that depend on the same network path or upstream authority do not eliminate that shared dependency. Conversely, distributing services does not require every location to receive unrestricted authority over the enterprise namespace.
Establish Zone Ownership Before Connecting Namespaces
An enterprise namespace should express ownership, not just naming preference. The following model is illustrative rather than a vendor requirement.
| Namespace or resource | Accountable owner | Authorized change path |
|---|---|---|
ad.example.com | Identity team | Approved Active Directory DNS processes and secure updates |
mgmt.example.com | Platform engineering | Infrastructure provisioning and lifecycle workflows |
| Cloud-specific infrastructure subdomains | Respective cloud platform team | Approved cloud-native automation |
apps.example.com | Application service owner | Service publication and traffic-management workflow |
site17.edge.example.com | Delegated edge owner | Bounded local changes when disconnected operation requires them |
| Reverse zones and enterprise address pools | Network/IPAM service owner | Coordinated allocation, release, and supported PTR-record processes |
Location-specific infrastructure names do not require customer-facing service names to change when a workload moves. A stable application namespace can remain separate from the names used to manage its infrastructure.
Provider-defined private endpoint namespaces are another category. Follow the provider’s documented DNS integration model rather than substituting an enterprise naming scheme. Azure’s private endpoint guidance, for example, distinguishes the application’s public service suffix from the associated private-link zone.
One Authority Does Not Mean One Writable Server
The objective is coordinated ownership, not an arbitrary limit of one writable DNS server.
Microsoft documents that Active Directory-integrated DNS can accept updates on multiple domain controllers hosting the zone and distribute them through Active Directory replication. A conventional secondary zone is different: it is a read-only copy obtained from another DNS server.
Neither arrangement should be confused with independent systems competing to manage the same records without a shared consistency model. A deployment pipeline, cloud controller, and synchronization job can each believe they own a record set while repeatedly undoing one another’s changes.
Document the creator, updater, deleter, approval boundary, and reconciliation owner for each important record class. Several cooperating writers can be valid. Several uncoordinated owners are not a resilience strategy.
Make Conditional Forwarding Predictable
The preferred pattern is not to send every query to headquarters. Provide each environment with an appropriate resolver service, then define explicit paths for namespaces hosted elsewhere.
For every forwarding rule, record the suffix, destination endpoints, network path, expected DNS view, timeout behavior, and responsible team. Review the resulting forwarding graph for cycles.
Microsoft’s Azure DNS Private Resolver documentation describes a concrete loop hazard: a ruleset forwarding to an inbound endpoint must not be linked back to the virtual network hosting that endpoint in the documented scenario. Private DNS zone links and forwarding ruleset links also perform different functions. One establishes zone visibility; the other applies forwarding behavior.
Client configuration needs the same discipline. Microsoft’s Windows Server DNS guidance advises against using ISP DNS servers for Active Directory resolution. It also explains that an authoritative but incorrect response does not cause the client to try another configured DNS server.
A public resolver is therefore not an equivalent backup for a resolver that must answer private or Active Directory queries. Reachability alone is not enough; the alternate must provide the required namespace view.
Network policy must also support the protocol correctly. RFC 7766 requires DNS implementations to support TCP. For conventional DNS paths, validate both UDP and TCP port 53 rather than assuming a successful small UDP response proves the full path works.
Finally, separate name resolution from application reachability. A correct private address does not prove routing, firewall policy, authentication, or application readiness.
Preserve Platform-Specific DNS Contracts
The enterprise operating model should coordinate platforms without pretending their DNS behavior is identical.
VCF: Include DNS in Lifecycle and Recovery Validation
Broadcom’s VCF System Configuration APIs include operations to retrieve, update, and validate DNS configuration. Use the workflows supported by the deployed release rather than assuming that editing an individual appliance is a supported platform-wide change.
For a VCF design review, I would require a register of critical management names, the resolver paths used by management components, and the forward and reverse records required by the applicable deployment documentation.
Then test the recovery dependency: can management be restored when its usual DNS environment is unavailable? If restoring DNS requires the same unavailable management services, the recovery path has an unresolved circular dependency.
This is not a universal requirement to place every DNS server outside VCF. It is a requirement to avoid placing every viable recovery path inside the same failure boundary.
Azure Local: DNS Selection Is a Lifecycle Decision
Microsoft’s deployment prerequisites for hyperconverged Azure Local deployments state that the configured DNS service must resolve the Active Directory domain. They also state that DNS servers used by the nodes and Azure Arc resource bridge cannot be changed after deployment, and that the DNS server address cannot fall within specified reserved Kubernetes ranges.
Keep that statement scoped to the documented deployment model and applicable release. Do not turn it into an unsupported claim about every Azure Local configuration.
The practical implication is to review DNS before installation: endpoint stability, service lifetime, AD resolution, failure domains, and supported recovery procedures all matter. Do not assume that changing resolver settings during an incident will be an ordinary, supported recovery action.
Azure Local also should not be treated as merely another Azure virtual network. Evaluate its local node and management dependencies within the actual deployment architecture.
Azure: Connect Private-Zone Visibility to the Application’s Query
Azure DNS Private Resolver provides inbound endpoints for queries entering Azure and outbound forwarding for queries directed toward other namespaces. Inbound endpoints can resolve private zones linked to their hosting virtual network.
Private endpoints introduce a detail that is easy to miss. In Microsoft’s Azure SQL example, on-premises conditional forwarding uses database.windows.net, not only privatelink.database.windows.net. The latter remains the associated private DNS zone.
Test the name the application actually requests and verify the resulting private endpoint address. Querying only the private-link target can miss a problem earlier in the resolution path.
Microsoft also documents that private DNS zone groups manage records associated with private endpoints, including record deletion when the endpoint is removed. Account for that lifecycle ownership before adding independent record-management automation.
AWS: Use the Supported Hybrid Resolver Boundary
AWS documents inbound Resolver endpoints for queries entering a VPC and outbound endpoints with rules for selected queries leaving it. Its guidance explicitly states that forwarding private DNS queries from on-premises or other VPC DNS servers directly to a VPC CIDR-plus-two address is unsupported. Use the documented inbound endpoint path instead.
Private hosted zone behavior also matters. When a matching private zone lacks the requested record, Route 53 VPC Resolver can return NXDOMAIN rather than continue to public DNS. A forwarding rule for the same namespace can take precedence over a private hosted zone.
These are resolution semantics, not evidence that another configured resolver will automatically supply the intended answer. Test the view and rule precedence from the consuming VPC.
Google Cloud: Network Peering Is Not DNS Peering
Google Cloud distinguishes private zones, forwarding zones, inbound server policies, and DNS peering. Its best-practices guidance states that forwarding does not automatically synchronize on-premises records and that Cloud DNS does not support zone transfers for that synchronization.
The same guidance explicitly separates VPC Network Peering from DNS peering. Network peering enables connectivity but does not change name resolution; each VPC retains its resolution order unless the relevant DNS configuration changes.
The cross-cloud lesson is consistent: connectivity, resolver access, zone visibility, and record ownership are separate architecture decisions.
Make IPAM an Allocation Contract
An inventory can describe addresses without controlling their allocation. My recommended model assigns authority hierarchically: the enterprise address plan delegates bounded pools to cloud, platform, tenant, or site allocators. Those allocators operate within their delegation rather than independently selecting from the same enterprise range.
Native IPAM services can participate. AWS documents planning, allocation, monitoring, and address history. Azure Virtual Network Manager documents hierarchical pools, allocation permissions, and static CIDR allocations that can reserve space not currently used within Azure or not supported by its native allocation integration.
Neither capability removes the need to coordinate authority between independently operated systems.
For each pool, record the routing scope, address family, parent allocation, authorized allocator, owner, lifecycle state, and associated resource identifiers. Include infrastructure reservations, private endpoints, Kubernetes pod and service ranges, recovery capacity, and translated address space where relevant.
Address Reuse Requires an Isolation Boundary
Reusing a private prefix in deliberately unconnected networks is not inherently incorrect. AWS IPAM scopes explicitly accommodate address reuse across unconnected networks.
The risk changes when those networks must communicate. A merger, recovery design, or shared-service connection can create a requirement that the original address plan did not anticipate. Evaluate that connection against a renumbering or translation plan rather than assuming an inventory record proves compatibility.
The useful question is not simply whether a prefix appears twice. It is whether it appears twice inside an address space that must operate as one connected routing environment.
Coordinate Address and Record Lifecycles
For new infrastructure, I recommend the following controlled publication sequence:
Do not design the workflow as though separate provisioning, IPAM, and DNS interfaces automatically form one transaction. A timeout is not proof that provisioning failed, and deletion of a DNS record is not proof that the corresponding address is free.
Decommissioning needs an equally explicit reuse policy. Check native bindings, outstanding leases where applicable, DNS caches, and traffic withdrawal before returning an address to an allocatable pool.
During a central IPAM outage, existing services should continue according to their design. New allocation should stop unless an allocator has a valid predelegated pool from which it is authorized to continue. An emergency should not create a second, unofficial address authority.
Separate the Failures Hidden Inside DNS Failover
The phrase DNS failover can conceal four different requirements: resolver availability, authoritative-service availability, change and allocation availability, and application endpoint failover.
A resolver can remain reachable while its upstream authority is unavailable. Existing names can continue resolving while the change interface is down. A recovery address can be published before the application behind it is ready. Each condition needs its own acceptance criteria.
Redundant Resolvers Need Independent Dependencies
For every endpoint, identify its network, power, platform, routing, and upstream dependencies. Then compare them against the failure the service must tolerate.
Microsoft’s private-resolver failover tutorial combines resolvers in two regions, private-zone links to both resolver virtual networks, and redundant connectivity and forwarding targets. The useful pattern is the combination of independent paths and equivalent visibility, not merely another DNS address.
Apply the same review to private-cloud and edge resolver pairs. A second instance is helpful only to the extent that the relevant failure does not remove both paths.
TTL Is Not an Application Recovery Objective
RFC 1034 defines time to live as a caching control. Lowering a TTL during an incident does not retroactively shorten the life of answers already cached under the previous value.
RFC 2308 adds another operational consideration: negative answers can be cached. Creating a previously missing record therefore may not immediately make it visible through a resolver that cached its absence.
RFC 8767 describes serving stale data when fresh answers cannot be obtained. That can preserve availability, but it deliberately trades freshness for continuity. An old answer might keep a service reachable or continue directing clients toward an endpoint that should no longer receive traffic.
Set an acceptable freshness policy and test actual consumer behavior. Do not present a configured TTL as a complete recovery-time guarantee.
DNS Changes Do Not Prevent Application Split-Brain
Intentional split-view DNS is a legitimate pattern. AWS documents public and private views of the same namespace for different audiences. That is not the same as competing record owners, duplicate address allocation, or two application instances accepting writes when only one should.
For a single-writer application, my recommended recovery sequence is to prevent the former writer from continuing, promote and validate the recovery service, and only then publish the approved endpoint.
Changing DNS is a traffic-discovery action. It is not proof that the former application instance has stopped accepting writes.
Design Edge Autonomy for Cold State
Define the edge site’s autonomy interval: how long it must operate without central connectivity, and which existing or new operations must remain possible.
A warm-cache demonstration is insufficient. Cached answers have lifetimes, and stale-answer behavior requires an explicit policy. Conventional secondary zones also have refresh and expiry behavior; a local copy is not unlimited independent authority.
Where local continuity is required, I would define a bounded namespace, an exclusively delegated address pool, locally available resolution for required services, and specific rules for changes during isolation. Reconnection should reconcile authorized local changes without allowing the site to overwrite unrelated central state.
DHCP continuity requires separate validation. Microsoft documents that Windows DHCP failover partners share lease information, but scope configuration changes require replication. When both partners perform DNS dynamic updates, they must use the same DNS update credentials. Otherwise, the surviving server can fail to update records owned through the original credentials.
Keeping leases available is not enough if the surviving service cannot maintain the associated names.
Finally, local DNS does not prove that identity, certificates, applications, or cloud-connected management workflows support disconnected operation. Validate each dependency against the same autonomy requirement.
Test the Dependency Chain from the Consumer’s Location
The strongest acceptance test is not whether a DNS server responds. It is whether the correct client receives the intended answer, through the intended path, during the specified failure.
I would include these exercises in platform acceptance and recurring recovery testing:
| Exercise | Evidence required |
|---|---|
| Remove a resolver or its network path | Clients reach an equivalent DNS view within the agreed interruption limit |
| Isolate a site with cold caches | Required local names and services remain usable for the defined autonomy interval |
| Create a previously nonexistent record | Negative-cache behavior fits the publication objective |
| Break a private-zone link or forwarding rule | Monitoring identifies the affected namespace and consumer locations |
| Disable central IPAM | Unauthorized allocation stops; only approved delegated allocation continues |
| Recreate a private endpoint | Record lifecycle, application-name resolution, and intended access converge correctly |
| Recover management after a full-site outage | DNS, identity, credentials, and control-plane recovery have no unresolved circular dependency |
| Reconnect the former primary | Stale controllers and applications cannot resume unauthorized writes or overwrite accepted recovery state |
Run the exercises from representative management networks, application networks, clouds, and edge sites. Use the names applications actually request, including relevant service-discovery records and required reverse lookups.
Capture source location, query, response code, latency, expected view, and returned endpoint, with appropriate protection for sensitive query data. Record configuration changes against an actor or automation identity.
Measure consumer resolution separately from the ability to make safe changes. Existing queries succeeding does not prove that the team can publish a recovery endpoint or allocate its address during an outage.
Recover Shared Services Before Restarting Their Writers
Backing up records is necessary, but it is not a complete hybrid DNS recovery plan. Recoverable configuration should include delegations, forwarding rules, cloud associations and links, resolver configuration, access policies, address-pool state, and the identities used by automation.
Maintain a protected record of critical endpoint addresses and recovery credentials outside the failure boundary they are intended to recover.
Recovery order should follow the actual dependency graph. A practical starting pattern is foundational connectivity and time services, minimum viable DNS and identity, platform management, application services, and then normal automated reconciliation. Active Directory-integrated DNS and directory recovery have coupled dependencies, so supported product procedures govern the exact order.
The final stage deserves care. Do not immediately restart every deployment controller, DNS synchronization job, and infrastructure pipeline after restoring an older backup. First compare restored intent with current native resource state.
Otherwise, a restored controller may attempt to recreate a deleted endpoint, republish an obsolete address, or release an address still in use. Treat the old primary’s return as controlled re-entry, not automatic restoration of authority.
Conclusion
A hybrid DNS and IPAM strategy does not need to begin with a product replacement. Begin with a zone-ownership register, an address-allocation hierarchy, a resolution-path map, and a tested recovery contract.
Those artifacts expose decisions that platform diagrams can hide: who may change a shared namespace, which allocator may continue during isolation, which cloud links make an answer visible, and which dependencies must exist before management can recover.
Central policy and distributed execution can coexist, but only when authority and failure behavior are explicit. Native cloud DNS, enterprise DNS, IPAM, DHCP, and platform automation should cooperate through those boundaries rather than compete to define reality.
A second site or second cloud creates options. It does not automatically make shared services independent. The architecture is ready for a more useful test: when a location disappears, who can still resolve the name, who can safely allocate the address, and who has the authority to change either one?
External References
- Broadcom: System Configuration APIs
Canonical URL: https://developer.broadcom.com/xapis/vmware-cloud-foundation-api/latest/system-configuration/ - Microsoft: DNS zones
Canonical URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/zone-types - Microsoft: Best practices for DNS client settings in Windows Server
Canonical URL: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings - Microsoft: Review deployment prerequisites for Azure Local
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-local/deploy/deployment-prerequisites?view=azloc-2608 - Microsoft: Azure DNS Private Resolver endpoints and rulesets
Canonical URL: https://learn.microsoft.com/en-us/azure/dns/private-resolver-endpoints-rulesets - Microsoft: Azure Private Endpoint DNS integration Scenarios
Canonical URL: https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns-integration - Microsoft: Tutorial: Set up DNS failover using private resolvers
Canonical URL: https://learn.microsoft.com/en-us/azure/dns/tutorial-dns-private-resolver-failover - Microsoft: What is IP address management (IPAM) in Azure Virtual Network Manager?
Canonical URL: https://learn.microsoft.com/en-us/azure/virtual-network-manager/concept-ip-address-management - Microsoft: DHCP failover overview
Canonical URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-failover - AWS: Resolving DNS queries between VPCs and your network
Canonical URL: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html - AWS: Considerations when working with a private hosted zone
Canonical URL: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-considerations.html - AWS: How IPAM works
Canonical URL: https://docs.aws.amazon.com/vpc/latest/ipam/how-it-works-ipam.html - AWS: What is IPAM?
Canonical URL: https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html - Google Cloud: Best practices for Cloud DNS
Canonical URL: https://docs.cloud.google.com/dns/docs/best-practices - RFC Editor: RFC 1034: Domain Names – Concepts and Facilities
Canonical URL: https://www.rfc-editor.org/rfc/rfc1034.html - RFC Editor: RFC 2131: Dynamic Host Configuration Protocol
Canonical URL: https://www.rfc-editor.org/rfc/rfc2131.html - RFC Editor: RFC 7766: DNS Transport over TCP – Implementation Requirements
Canonical URL: https://www.rfc-editor.org/rfc/rfc7766.html - RFC Editor: RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)
Canonical URL: https://www.rfc-editor.org/rfc/rfc2308.html - RFC Editor: RFC 8767: Serving Stale Data to Improve DNS Resiliency
Canonical URL: https://www.rfc-editor.org/rfc/rfc8767.html
TL;DR The control-room image is a useful metaphor for VMware Cloud Foundation 9.1, but not because the platform predicts infinite futures or...