DNS PTR records update in production during recovery plan test in vSphere Live Site Recovery

Products

• VMware Site Recovery Manager

Issue/Introduction

During a vSphere Live Site Recovery (formerly Site Recovery Manager) test, virtual machines (VMs) in the isolated "bubble" environment may update their DNS PTR records. If a Domain Controller is part of the test recovery, these changes can replicate back to the production environment via native Active Directory replication, causing production name resolution issues.

Symptoms

• VMs in the SRM test network cannot ping the recovered Domain Controller or the gateway.
• Production DNS PTR records for live VMs are unexpectedly updated to the IP addresses of the test VMs.
• Network Location Awareness (NLA) service hangs on the recovered Domain Controller, showing the network profile as "Public" or "Unidentified."
• Specific errors such as java.net.ConnectException may be observed.
• Production servers may become "unstable" and network switches may report "duplicate MAC addresses" if isolation fails.

Environment

• VMware Live Recovery 9.x
• VMware Site Recovery Manager 8.x
• Microsoft Windows Server (Domain Controller)

Cause

1. VLAN Mismatch: The test network portgroup is configured with a VLAN tag that does not match the underlying physical or virtual topology.
2. NLA Service Failure: The NLA service on the recovered DC fails to identify the domain environment after recovery, blocking inbound ICMP traffic.
3. Active Directory Replication: If the recovered DC has a functional network path to the production DCs (or if replication is not correctly isolated), native OS replication propagates DNS changes made in the test bubble back to the production forest.
4. Network Configuration: This issue frequently occurs when using "User Defined" network mappings instead of auto-generated "Isolated" networks.

Resolution

To resolve connectivity and prevent production DNS impact, follow these steps:

1. Isolate the Domain Controller:
   • Remove the Domain Controller from the SRM Protection Group and Recovery Plan.
   • Rely on native Active Directory replication to a pre-existing DC at the DR site rather than recovering a production DC into the test bubble.
2. Correct Network Mapping:
   • Navigate to SRM > Network Mappings.
   • Ensure the Test Network VLAN matches the production network tagging (e.g., if production is untagged, ensure the test portgroup is also untagged).
3. Restore NLA Service:
   • Reboot the recovered Domain Controller. This forces the NLA service to re-evaluate the network connection and correctly identify the "Domain" profile.
4. Verify ICMP Rules:
   • Ensure Windows Defender Firewall allows "File and Printer Sharing (Echo Request - ICMPv4-In)."

Additional Information

For general SRM networking guidance, see Contact Support.