The DHCP server on some VCE's hands out option 119 with values that interfere with clients that need to reach resources via short DNS names.
The environment in which the issue is seen:
For edges with DHCP setting enabled under a VLAN or routed interface with an explicit DNS Search Path (DHCP option 119) not been defined, when the edge or client in the LAN tries to resolve a hostname an unqualified (for example: hostname) or partially qualified (for example: hostname.corp) DNS name, the Edge incorrectly tries to look up that name under .nyansa.com, which will always return the address app.nyansa.com, which is incorrect for this case.
The nyansa hostname is associated with VMware SASE's Edge Network Intelligence application.
Corresponding logs:
testedge#ping "hostname"
PING app.nyansa.com (52.26.148.183): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
^C
--- app.nyansa.com ping statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss
testedge#ping "hostname.subdoman.domain.com"
PING hostname.subdoman.domain.com (10.1.1.2): 56 data bytes
64 bytes from 10.1.1.2: seq_seg=0 ttl=249 time=22.3 ms
64 bytes from 10.1.1.2: seq_seg=1 ttl=249 time=21.4 ms
There's a simple workaround, define an explicit DNS Search Path (option 119) for each enabled DHCP server (on a VLAN or a routed interface) on the impacted edge. This will take out the naynsa defaults.
Issue was fixed in software 5.0.0.0 and the later versions.