Guidelines for Using .Local DNS Domains in VCF and VVF Deployments

Products

• VMware Cloud Foundation
• VMware vSphere Foundation

Issue/Introduction

All VMware Cloud Foundation (VCF) and VMware vSphere Foundation (VVF) deployments require properly configured forward (A) and reverse (PTR) DNS records. If your organization uses .local for internal enterprise DNS, review this guidance before planning your deployment or upgrade.

A Quick Clarification: Network DNS vs. vSphere SSO

This guidance applies strictly to network DNS domains used to resolve hostnames and IP addresses (e.g., corp.local). It does not affect the default vSphere Single Sign-On (SSO) domain (vsphere.local). Internal SSO logins do not query network DNS servers and will continue to work normally as-is.

VCF Identity Broker (VIDB) can point back to your existing .local Active Directory (e.g., corp.local) as an Identity Provider (IdP) source. VIDB is an authentication broker—it does not join the Active Directory domain; it simply establishes outbound unicast LDAP/LDAPS connections (TCP 389/636) to your Domain Controllers.

Issue

Why .local behaves differently in modern components

Under internet networking standards (RFC 6762), the .local top-level domain is officially reserved for Multicast DNS (mDNS) device discovery rather than corporate DNS servers.

While traditional operating systems still permit standard unicast DNS lookups for .local names, modern container runtimes and Kubernetes microservices adhere strictly to the RFC. When a containerized service tries to resolve a .local address, its internal resolver routes the request to multicast traffic (224.0.0.251:5353) instead of querying your corporate DNS server. Because container network overlays drop multicast packets by default, these lookups fail with timeouts.

Where .local is Operational (and where it isn't)

Operational depends on how each component is built:

• Traditional Virtual Appliances and ESX Hosts:
  Components running on traditional operating systems—including vCenter Server, NSX Manager, SDDC Manager, VCF Operations, and ESX hosts—use standard unicast DNS. They continue to allow the use of .local network domains out of the box for deployments, day-to-day operations, and lifecycle upgrades without manual workarounds.
• Containerized VCF Management Services (RFC-Compliant Domain Required):
  Services that run as cloud-native microservices inside Kubernetes—including VCF Management Services, VCF Automation, VCF Identity Broker (VIDB), and vSphere Supervisor—strictly enforce RFC 6762. These components cannot be deployed using a .local network domain. They require an RFC-compliant domain or subdomain (e.g., acme.com).

Environment

VMware Cloud Foundation, VMware vSphere Foundation

Resolution

Options for .local Environments

Option	How It Works	Active Directory & DNS Impact
1. DNS Forwarding	Core appliances remain on your existing .local domain (e.g., corp.local).   Modern VCF services deploy under an RFC-compliant corporate domain you already own (e.g., acme.com).	Zero AD Changes. Requires only bidirectional DNS conditional forwarders between the two domains.
2. Split-Domain via AD Forest Trust	Core appliances remain on (e.g., corp.local).   Modern services deploy in a new, dedicated Active Directory forest on an RFC-compliant domain (e.g., acme.com).	New AD Forest. Requires deploying new Domain Controllers and establishing a two-way Kerberos forest trust with (e.g., corp.local).
3. Full Domain Modernization	Retire (e.g., corp.local) across the entire enterprise data center.	Complete Infrastructure Overhaul. Re-domain and re-certificate all hosts, vCenters, and corporate workloads.