Troubleshooting DNS Resolution Failures: Understanding and Resolving "NXDOMAIN" Errors

Products

• VMware NSX
• VMware vSphere ESXi
• VMware vSphere Foundation
• VMware vSphere Kubernetes Service

Issue/Introduction

Administrators may encounter the DNS error codeNXDOMAIN(Non-Existent Domain) when attempting to resolve Fully Qualified Domain Names (FQDNs) from Virtual Machines (VMs), ESXi hosts, or NSX management components.

•  Applications fail to connect to target endpoints by hostname.
• Error Message: Name or service not known, Host not found, or specifically status: NXDOMAIN in dig or nslookup output.
• This issue indicates a successful connection to a DNS server, but the server explicitly rejects the validity of the requested domain name
• Sometimes the networking commands fail with No route to host. Other times, it succeeds without issue.

CONCEPTUAL OVERVIEW

NXDOMAIN is a response code sent by a DNS server signifying that the domain name queried does not exist in the authoritative zone. Unlike a timeout or connection refusal, an NXDOMAIN response proves that the DNS infrastructure is reachable and functioning, but the specific record is missing or the request is being routed to the wrong authority.

 

Environment

VMware NSX
VMware vSphere
VMware Kubernetes Services

Cause

The NXDOMAIN error is typically caused by one of the following:

1. Typos/Input Error: The FQDN is misspelled or references a decommissioned server.
2. Missing DNS Record: The A (Host) or PTR (Reverse) record has not been created on the authoritative DNS server.
3. Incorrect DNS Suffix Search List: The client is appending the wrong suffix (e.g., searching server.corp.local instead of server.vmware.com).
4. Split-Horizon Misconfiguration: In NSX environments, the DNS Forwarder may be sending queries to a public DNS server (e.g., 8.8.8.8) that has no knowledge of internal private domains.

Resolution

1. Validate the Query (Client-Side)

Use nslookup or dig to confirm the specific error code and the server being queried.

• Command: dig @<dns-server-ip>
• Analysis:
• If status: NXDOMAIN is returned, the server is active but lacks the record.
• If status: SERVFAIL or connection time out occurs, troubleshoot network connectivity instead.
• There can be multiple DNS servers that can respond to the DNS query and all of them will need to be checked.

2. Verify DNS Suffixes

Ensure the client's /etc/resolv.conf (Linux) or Network Adapter settings (Windows) include the correct search domains.

• Example: If querying app01 results in NXDOMAIN, the system might be trying app01.#### when the record exists as app01.###.####.com.

3. Inspect NSX DNS Forwarder/Service

If the error originates from a workload using the NSX DNS Service:

• Check Forwarder Zones: Ensure a specific FQDN Zone exists for the internal domain.
• Verify Upstream Servers: If the default forwarder points to a public resolver (e.g., Google/Cloudflare), it will validly return NXDOMAIN for internal hostnames. You must configure a Conditional Forwarder or FQDN Zone pointing to your internal Active Directory/BIND servers for private domains.

4. Audit Authoritative Records

Log in to the DNS server identified in Step 1 and verify the record exists in the Zone file.

• Action: Create the missing A or AAAA record.
• TTL: If the record was recently created, flush the DNS cache on the client (ipconfig /flushdns or systemd-resolve --flush-caches) to remove the negative cache entry.