Symptoms:
Dig and nslookup fails from the supervisor control plane nodes to hostnames ending in .local

VMware vCenter Server 7.0.x

This is not unique to vSphere with Tanzu. This is expected behavior from the systemd-resolved service.

https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
 

• Multi-label names with the domain suffix ".local" are resolved using MulticastDNS on all local interfaces where MulticastDNS is enabled. As with LLMNR, IPv4 address lookups are sent via IPv4 and IPv6 address lookups are sent via IPv6.

• Queries for multi-label names are routed via unicast DNS on local interfaces that have a DNS server configured, plus the globally configured DNS servers if there are any. Which interfaces are used is determined by the routing logic based on search and route-only domains, described below. Note that by default, lookups for domains with the ".local" suffix are not routed to DNS servers, unless the domain is specified explicitly as routing or search domain for the DNS server and interface. This means that on networks where the ".local" domain is defined in a site-specific DNS server, explicit search or routing domains need to be configured to make lookups work within this DNS domain. Note that these days, it's generally recommended to avoid defining ".local" in a DNS server, as RFC6762 reserves this domain for exclusive MulticastDNS use.

In order to workaround this issue for proof of concept and lab environment's only, you will need to access the dcli  and run the following. 

First you need to get the cluster domain name. 

root@vcsa-01a [ ~ ]# dcli com vmware vcenter namespacemanagement clusters list
|---------|------------|---------------------------------------------------------------------------------|-----------------|-------------|
|cluster  |cluster_name|stats                                                                            |kubernetes_status|config_status|
|---------|------------|---------------------------------------------------------------------------------|-----------------|-------------|
|domain-c8|            ||--------|----------------|-----------|------------|---------------|------------||WARNING          |RUNNING      |
|         |            ||cpu_used|storage_capacity|memory_used|cpu_capacity|memory_capacity|storage_used||                 |             |
|         |            ||--------|----------------|-----------|------------|---------------|------------||                 |             |
|         |            ||0       |0               |0          |0           |0              |2048        ||                 |             |
|         |            ||--------|----------------|-----------|------------|---------------|------------||                 |             |
|---------|------------|---------------------------------------------------------------------------------|-----------------|-------------|
root@vcsa-01a [ ~ ]#

Then run a get command to grab the current search domain using the domain name you got from  the previous step.

root@vcsa-01a [ ~ ]# dcli com vmware vcenter namespacemanagement clusters get --cluster domain-c8 | grep -A 1 master_DNS_search_domains
master_DNS_search_domains:
   - corp.tanzu
root@vcsa-01a [ ~ ]#

Run the update command with the .local search domain you require (In this example I am using test.local) Then run another get command to validate the change has been made.
 

root@vcsa-01a [ ~ ]# dcli com vmware vcenter namespacemanagement clusters update --cluster domain-c8 --master-dns-search-domains test.local
root@vcsa-01a [ ~ ]# dcli com vmware vcenter namespacemanagement clusters get --cluster domain-c8 | grep -A 1 master_DNS_search_domains
master_DNS_search_domains:
   - test.local

Impact/Risks:
The .local hostname is reserved for use in mDNS per RFC6762  therefore trying to resolve it against a DNS server violates RFC6762. As such VMware does not recommend any deployment which uses .local for any components. (this includes vCenter, esxi, nsx manager, nsx edge nodes, and any endpoint TKGS uses like harbor).

The workaround for this is STRICTLY for proof of concept and lab use. Implementing this workaround in your production environment could result in unexpected scenarios as our Quality Assurance Team has not validated/tested this configuration and does not plan to validate in the future.