In the ever-evolving landscape of private cloud, technical debt often hides in the most fundamental places, like your DNS naming convention. For many years, .local was the go-to Top-Level Domain (TLD) for internal Active Directory environments.

However, as per RFC 6762, .local is now officially reserved for Multicast DNS (mDNS) and is no longer recommended for unicast DNS in enterprise environments. As we evolve VMware Cloud Foundation (VCF), we are implementing stricter guardrails to align with these global standards, encouraging a shift toward valid, routable, or non-conflicting TLDs.

The Challenge: The Hardening of VCF

-5As part of our commitment to platform security and stability, we have begun “hardening” the VCF stack. This means that several modern components are losing support for .local TLDs to prevent resolution conflicts and security vulnerabilities.z

Where .local is no longer supported:

• VCF Identity Broker (VIDB): The modern authentication backbone for VCF 9.x.
• VCF Automation: Modern cloud management capabilities
• vSphere Supervisor: Essential for Kubernetes consumption and modern application delivery

Where .local is still supported (for now):

To provide a transition window, core infrastructure components still allow .local configuration:

• VCF Operations
• vCenter Server
• VCF Networking (NSX)
• SDDC Manager

Design Scenario: The Transition Strategy

We understand that migrating an entire enterprise’s DNS infrastructure is not an overnight task. If your core VCF components (vCenter, NSX, SDDC Manager) are already tied to a .local domain and you aren’t ready for a full-scale rename, you need a hybrid DNS design to consume modern VCF services.

The Recommended Design Pattern

To bridge the gap, we recommend a “Transition Zone” approach. While your core management components stay on .local, you must introduce a standard-compliant TLD (e.g., corp.vcf.com or vcf.internal or Green.NET) for the modern services you wish to deploy.

The proposed design addresses the challenge of modernizing a VMware Cloud Foundation (VCF) environment that still relies on a legacy .local Top-Level Domain (TLD). Because modern components are increasingly “hardened” against the use of .local due to RFC standards, this design implements a split-domain architecture to bridge the gap between legacy core infrastructure and modern consumption services.

Split-Domain Architecture

The design divides the environment into two distinct logical zones based on their technical requirements and supportability:

• Legacy Infrastructure Zone (Blue.LOCAL): This zone serves the core VCF infrastructure components that still support .local for backward compatibility.
  • vCenter Server: vCenter.Blue.local
  • VCF Operations: ops.Blue.local
  • NSX Manager: nsx.Blue.local
• Modern Consumption Zone (Green.NET): This zone utilizes an RFC-compliant TLD for newer services where .local is strictly unsupported.
  • VCF Automation (VCFA): VCFA.green.net
  • Supervisor / VMware vSphere Kubernetes Service (VKS): sup.green.net or vks.green.net
  • VCF Identity Broker (VIDB): vidb.green.net

Implementation Options for Interoperability

To allow these two zones to communicate and function as a unified platform, the design proposes two primary integration methods:

Feature	Option 1: Forest Trust	Option 2: Distinct Domains
Connectivity	Establishes a Two-Way Forest Trust between Blue.LOCAL and Green.NET.	Maintains domains as completely Distinct Entities.
DNS Strategy	Shared identity and DNS records across the forest.	Utilizes DNS Forwarding to resolve queries between the two domains.

Critical Configuration Requirements

To ensure successful deployment and Single Sign-On (SSO) functionality, the following configuration guardrails must be followed:

• Identity Provider (IdP) Alignment: The SSO configuration must recognize both Green.NET and Blue.local as valid Identity Providers to allow users from either domain to access the platform.
• Search Domains: While deploying components, it is mandatory to configure both Green.NET and Blue.LOCAL in the DNS search domain list. This ensures that services in the modern zone can correctly locate and communicate with the legacy core infrastructure.

Implementation Steps

1. Maintain the Core: Keep your existing VCF Operations, vCenter, NSX and SDDC Manager on the .local domain to avoid disruptive renames.
2. Establish a New Domain: Create a new, RFC-compliant DNS domain (such as .net or .internal) in your environment.
3. Deploy Modern Services to the New Zone: When deploying VIDB, VCF Automation or vSphere Supervisor, use the new FQDNs.
4. Cross-Zone Resolution: Ensure that your DNS servers can resolve both the legacy .local zone and the new modern zone to allow inter-component communication.

For this hybrid design to function correctly, two specific configuration steps are mandatory during deployment:

1. Dual Search Domains: When deploying any component (especially in the Green.NET zone), you must configure BOTH Green.NET and Blue.LOCAL in the DNS search domain list. This ensures that a modern service like VKS can find the legacy vCenter it depends on.
2. Unified SSO Identity: The Identity Provider (IdP) must be configured to recognize both the Green.NET and Blue.local domains. This allows users from both domains to authenticate into each component.

This split-domain design offers a strategic pathway for VCF customers to adopt new capabilities and features without the immediate, costly burden of a full-scale .local domain migration. By leveraging a dual-zone architecture and essential cross-domain configuration, enterprises can ensure platform stability, security compliance, and access to all next-generation VCF capabilities today.