vCenter 6.7U3 Dynamic DNS issue with vCenter HA (VCHA) - duplicate DNS records creating connectivity issues

[Bill_Oyler]

Now that vCenter 6.7U3 enables Dynamic DNS updates by default, it seems there is a bug that causes the vCenter HA (VCHA) IP address (on the 2nd NIC) to be registered to DNS as a second IP address for the vCenter server.  This causes connectivity issues because end-users trying to connect to the vCenter interface via FQDN end up with 2 IP addresses, one of which most likely is not going to work (i.e. the VCHA IP address on the 2nd NIC, which likely does not have a default gateway).  I was able to reproduce this bug in several different environments.  One work-around is to disable vCenter HA entirely.  This is not a very good work-around for customers that wish to have vCenter high availability.  Does anyone know any other work-arounds, such as disabling dynamic DNS on the VCHA NIC, or disabling Dynamic DNS globally on the vCenter server?  Also, does anyone from VMware know whether this bug will be fixed soon?

[ryanrpatel]

Do you have a diagram or something showing your setup? Specifically, the NICs & Switch assignments, IP addressing, GW and such.

[Bill_Oyler]

Sure, it's a very basic VCSA / VCHA setup.  vCenter 6.7U3 appliance is configured as follows:

NIC 0 (default NIC):

IP = 10.201.30.111/24

Gateway = 10.201.30.1

NIC 1 (VCHA created NIC):

IP = 10.201.98.61/24

No Gateway (purposely; this is a private network for VCHA replication traffic only)

DNS name is "vc03.company.com".

Prior to VCSA 6.7U3, dynamic DNS was not supported so the corporate Microsoft DNS servers contained the following "A" record:

vc03.company.com: 10.201.30.111

After updating to VCSA 6.7U3, dynamic DNS was enabled by default and VCSA automatically registered a second IP address on the Microsoft DNS server:

vc03.company.com: 10.201.30.111,10.201.98.61

Therefore, when someone tries to access vCenter by FQDN (vc03.company.com), their DNS lookup will resolve to the above two IP addresses rather than the single IP address as in the past.  Depending on the user/browser/OS, there will either be a lengthy delay (because the user's browser tries to access 10.201.98.61, which is the private VCHA IP address), or the connection will fail.  Also, vCenter Enhanced Linked Mode failed intermittently because the other (2) vCenter servers were intermittently unable to connect to the vCenter by FQDN, presumably due to the second IP address which is not a routable IP address and not meant to be published to the world (it is only used for VCHA internal replication traffic).

Destroying vCenter HA solves the problem, but that's not a very good solution.  I am hoping there is a more elegant solution.

[a_p_]

I'd suggest that you open a support ticket for this to get an official answer?

Maybe it's already a known bug, and VMware has a fix/workaround already available.

André

[ryanrpatel]

Does sound like a strange issue (bug). I would open a case with GSS, and perhaps in the meantime you could remove the DNS server completely and manually create the DNS record for the single IP. I'll be waiting to hear what VMware says.

[Bill_Oyler]

Removing the DNS server from vCenter is a non-option because that breaks name resolution for all vCenter services.  We will open a ticket with VMware Support.

[johncol]

Would you mind pm'ing me the sr # when you do, thanks

[NathanosBlightc]

Regardless of it's a bug or not, try following methods to avoid misleading of VCSA FQDN:

1. Edit /etc/hosts file for each host and add the VCSA FQDN to its content.

or

2. Remove the 2nd registered record and add it again as a CNAME (Alias) record.

[Vijay2027]

Can you open an SR for this, there is a potential fix available.

[maussem]

same problem here.

2nd NIC, isolated HA network, register in DNS and backup fails because of second DNS entry.

Edit local host file and set DNS to accessible IP address of the first network card but from 100 VMs to back up every day, 4-5 are not backed up because of DNS.

The workarounf does not work 100%.

I'd like to know how to prevent the NIC from registering in DNS.

Any new information?

[Vijay2027]

What is the output of below command??

/opt/likewise/bin/lw-update-dns

[maussem]

Hello Vijay2027,

NIC0: 192.168.31.10

NIC1: 192.168.32.10 (HA)

root@srv-31-010 [ ~ ]# /opt/likewise/bin/lw-update-dns

A record successfully updated in DNS

Unable to register reverse PTR record address 192.168.32.10 with hostname srv-31-010.pep.local

PTR records successfully updated in DNS

Thank you

[Vijay2027]

On DNS server for vCSA record can you verify if "Allow any authenticated user to update DNS records with the same owner name" is checked.

If the above option is checked, un-check the option and remove secondary DNS record.

[maussem]

Option is not checked but for nic0 I delete an recreated the DNS record.

Delete secondary DNS record and run shell command.

NIC1 register in DNS again.

[berndweyand]

Same problem here since 6.7U3.

Workaround for me:

modified /etc/cron.d/dns_update.cron - changed the line to /opt/likewise/bin/lw-update-dns --ipadress <primary ip> --fqdn  <fqdn of vcsa>

Interesting observation: there are about 30 running processes of lw-update-dns - seems like they are hanging

[maussem]

Hello bernweyand,

workaround seems to work. HA NIC has not registered in the DNS since the change.

Thanks

[berndweyand]

Vmware just released a patch for this:6.7.0.42000-15132721-patch-FP.iso (6.7U3b)

before applying this patch you should cleanup: VMware Knowledge Base