DNS troubleshooting involves identifying where DNS resolution is failing and determining whether the problem originates with the client, recursive resolver, DNS server, DNS records, or the network path between them. While a complete DNS outage is usually straightforward to identify, partial resolution failures can be harder to diagnose.
This DNS troubleshooting guide focuses on diagnosing these partial and intermittent failures, including NXDOMAIN, REFUSED, SERVFAIL, stale DNS responses, inconsistent resolution, and cases where DNS resolution succeeds but the application remains unreachable.
Determine the DNS failure scope first
Before running diagnostic commands, it's useful to determine the scope of the DNS problem. Ask three questions:
- Is the problem affecting one device or multiple devices?
- Does it affect one domain or multiple domains?
- Did the problem start after a DNS, network, application, or configuration change?
These answers help narrow down which layer to investigate. If only one device is affected while other devices resolve the same hostname normally, it's ideal to start with that device's DNS configuration, local DNS cache, network settings, VPN, and endpoint security software. If multiple devices across a network cannot resolve any domains, investigate the configured DNS resolver, DNS server availability, network connectivity, and firewall rules.
Selective DNS failures commonly fall into three patterns:
- One domain or hostname fails: A specific domain returns NXDOMAIN, SERVFAIL, or another DNS error while other domains resolve normally. To resolve this, check the domain's DNS records, delegation, authoritative name servers, and resolver cache.
- Only some users receive incorrect or inconsistent answers: DNS works for most users, but users on a different subnet, site, VPN, or network receive different responses. Check resolver configuration, split-horizon DNS, forwarding rules, and cached responses.
- A recently changed record still returns the old value: Some or all clients continue resolving the previous IP address after a DNS record change. Check the record's TTL, recursive resolver caches, and authoritative DNS response to determine whether the old value is still being served.
Identifying the failure pattern before changing DNS settings helps isolate the affected layer and prevents fixes from being applied to the wrong part of the DNS resolution path.
Troubleshooting NXDOMAIN errors
NXDOMAIN means the DNS system has determined that the queried domain name does not exist. However, an NXDOMAIN response does not always mean that a DNS record is simply missing.
A recursive resolver may still be serving a cached NXDOMAIN response, the client may be querying the wrong hostname because of its search-domain configuration, or the name may not exist on the authoritative DNS server.
Before changing DNS records, determine whether the NXDOMAIN response originates from the authoritative server or from a recursive resolver.
Verify the authoritative DNS response directly
Start by identifying the authoritative nameservers for the domain: dig NS example.com
Then query an authoritative nameserver directly: dig app.example.com @ns1.example.com
If the authoritative server returns the expected record but your normal DNS resolver returns NXDOMAIN, the resolver may be serving a cached negative response. If the authoritative server also returns NXDOMAIN, verify that the hostname is correctly configured in the zone and that you are querying the intended domain.
For a deeper check of the DNS delegation and resolution path, you can also use: dig +trace app.example.com
This follows the DNS hierarchy from the root servers through the TLD and delegation to the authoritative server, helping identify where the name stops resolving.
Check whether the client is constructing the wrong hostname
NXDOMAIN errors can also occur when a client queries a short hostname and automatically appends an incorrect DNS search domain. For example, a query for app may be expanded to app.corp.example.com. If the configured search domain is incorrect or the intended record uses a different suffix, the resulting fully qualified domain name may not exist.
Test the fully qualified domain name (FQDN) directly: nslookup app.corp.example.com.
dig app.corp.example.com.
The trailing dot tells the DNS client that the name is already fully qualified and prevents additional search-domain suffixes from being appended.
If the FQDN resolves but the short hostname does not, check the client's DNS search-domain configuration. On Windows, use: ipconfig /all
On Linux, check the resolver configuration and search domains using: cat /etc/resolv.conf
Search domains can be supplied through DHCP. DHCP option 15 provides a domain name, while option 119 can provide a domain search list. If an incorrect search domain is being distributed through DHCP, correct the DHCP configuration rather than changing the DNS zone.
For more information about client and server DNS settings, see our DNS configuration guide.
Check negative DNS caching
Recursive DNS resolvers cache negative responses such as NXDOMAIN, not just successful DNS records. This prevents repeated queries for names that do not exist. As a result, a resolver can continue returning a previously cached NXDOMAIN response even after the corresponding DNS record has been created.
The negative caching period is determined from the authoritative zone's SOA record. Check the SOA with: dig SOA example.com
The SOA response contains a MINIMUM field that can be used to determine the negative caching TTL, subject to the rules defined for negative caching. The SOA record's TTL also matters when determining how long a negative response can be cached.
For example, if a hostname was queried before its record was created, a recursive resolver may have cached the NXDOMAIN response. Creating the record on the authoritative server does not immediately invalidate that cached response. The resolver must either refresh the name after the negative TTL expires or have its cache cleared.
If you control the recursive resolver, flushing its cache can help confirm whether stale negative caching is responsible. On Windows Server DNS, for example: dnscmd /clearcache
On BIND, a specific cached name can be flushed with: rndc flushname app.example.com
If the authoritative server returns the correct record but clients continue receiving NXDOMAIN, compare the response from the authoritative server with the response from the recursive resolver before making further DNS changes.
Troubleshooting REFUSED responses: Access control, not a server failure
A REFUSED DNS response is fundamentally different from a timeout. A timeout means the client did not receive a response within the expected period. REFUSED means the DNS server received the query but declined to perform the requested operation. The server is reachable, but a server-side policy or configuration is preventing it from answering the query.
Two common causes of REFUSED responses are recursive query access controls and recursion policy.
Check recursive query access controls
Internal DNS resolvers often restrict which clients can use them for recursive queries. For example, an organization's DNS server may allow recursion only for clients on trusted internal networks. If a client IP falls outside the configured access control list (ACL), the resolver can return REFUSED instead of performing the recursive lookup.
This can occur after a device moves to a different VLAN, a new subnet is added, a cloud workload begins querying an on-premises resolver, or the resolver's ACL is not updated after a network change.
To isolate a client-specific access-control problem, run the same query against the same DNS server from an affected device and a known-good device: dig app.example.com @10.1.1.10
If the query succeeds from the known-good device but returns REFUSED from the affected network, compare the source IP addresses and subnet membership of the two clients. This can help identify an ACL or recursion-policy mismatch.
On BIND, check the allow-recursion configuration in named.conf and verify that the affected client's source network is permitted. On Windows Server DNS, review the server's recursion and query-related configuration, including the interfaces on which the DNS service is listening.
Check whether recursion is permitted
A REFUSED response can also occur when a client asks a DNS server to perform recursion but recursion is disabled or restricted for that server or client.
For example, an internal authoritative DNS server may intentionally refuse recursive queries because its role is limited to answering for the zones it hosts. In this case, the solution is not to open recursion indiscriminately. Instead, verify that clients are configured to use the organization's designated recursive resolver.
When troubleshooting, distinguish between these two questions:
- Can the client reach the DNS server? A successful response, including REFUSED, confirms that the server is reachable and responding.
- Is the DNS server permitted to perform the requested lookup for that client? A REFUSED response indicates that the requested operation was declined.
This distinction prevents a REFUSED response from being misdiagnosed as a DNS server outage or network connectivity failure.
Troubleshoot REFUSED zone transfers separately
A REFUSED response during a zone transfer is a different scenario. A secondary DNS server may request a full zone transfer using AXFR or an incremental transfer using IXFR, but the primary DNS server can refuse the request if the secondary's IP address is not authorized for zone transfers.
On BIND, check the primary server's allow-transfer configuration and verify that the secondary server's address is permitted. On other DNS platforms, review the equivalent zone transfer authorization settings.
A refused zone transfer can cause the secondary server's copy of the zone to become stale. Clients querying that secondary may then receive outdated DNS records, even though the secondary remains reachable and continues responding to queries.
If a secondary's records are outdated, check the zone's SOA serial number on both the primary and secondary servers, then verify whether the secondary can successfully complete its next AXFR or IXFR.
Troubleshooting DNS cache issues: Stale records, negative caching, and client-side cache
DNS cache issues commonly appear in two forms: a recursive resolver continues serving a previously cached DNS response after a record has changed, or it continues returning a cached NXDOMAIN response after a previously nonexistent record has been created. From the user's perspective, both can look like the DNS record has not updated.
Check cached records and TTL
If a hostname has recently moved to a new IP address and some clients continue receiving the old address, a recursive resolver may still have the previous response in its cache.
Query the hostname and inspect the TTL in the answer: dig app.example.com
The TTL shown in the answer indicates how many seconds the responding resolver can continue using that cached record before it needs to refresh it. The remaining TTL decreases as the cached entry ages.
For example, if the authoritative DNS record has a TTL of 3600 seconds and a resolver has already cached it for 20 minutes, a subsequent query may show approximately 2400 seconds remaining. Different recursive resolvers can therefore return different TTL values and, during a record change, may refresh the record at different times.
Changing the TTL on the authoritative record does not retroactively change copies that are already cached. If you control the recursive resolver, you can flush the affected cache entry rather than waiting for its TTL to expire. On BIND, for example: rndc flushname app.example.com
On Windows Server DNS, use the DNS Server cache-management commands appropriate to your Windows Server version to clear the cached response.
If clients continue receiving the old IP after the recursive resolver has refreshed its cache, check whether another caching layer such as a local operating system cache, browser cache, VPN resolver, or upstream DNS service is still returning the previous response.
Clear the client-side DNS cache
DNS caching does not stop at the recursive resolver. Operating systems can also cache DNS responses locally. This can cause a client to continue using an old DNS answer even after the upstream resolver has been updated.
Flush the local DNS cache according to the operating system:
- Windows: ipconfig /flushdns
- macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Linux with systemd-resolved: sudo resolvectl flush-caches
After clearing the local cache, query the hostname again and compare the result with the recursive resolver and authoritative DNS server. If the client still receives a different answer, verify which DNS server the client is actually using.
On Windows, ipconfig /all can show the configured DNS servers. On Linux, inspect the active resolver configuration rather than assuming that /etc/resolv.conf directly represents the complete resolver path.
Check browser and application-level DNS caching
A browser or application may maintain its own DNS-related cache in addition to the operating system cache. This can make a DNS problem appear to persist after the OS cache has been flushed.
If command-line tools return the new IP address but a browser continues connecting to the old address, test the hostname outside the browser first. If command-line resolution is correct, investigate browser-level caching, persistent connections, proxy settings, VPN software, or application-specific DNS behavior.
Do not confuse DNS cache clearing with clearing browser history. They are separate operations, and deleting browsing history does not necessarily remove DNS-related cached state.
The key to troubleshooting DNS cache issues is to compare the answer at each layer: authoritative server → recursive resolver → client operating system → application or browser. The first layer that returns the old or incorrect answer identifies where further investigation should focus.
When DNS works for some users but not others
When DNS works for some users but not others, compare the DNS configuration and resolution path of an affected client with a working one. Differences in DNS servers, network segments, DNS views, forwarding rules, or search domains are common causes.
Split-horizon misconfiguration
In split-horizon DNS, internal clients receive private IP addresses while external clients receive public IPs. If an internal client receives the public address, check whether the correct DNS view is being applied.
Query the internal resolver directly: dig app.example.com @10.1.1.10
Compare the response with a known-good internal client. On BIND, check the match-clients ACL for the relevant view. On Windows Server DNS, verify that the appropriate internal zone is available to clients on the affected subnet.
Conditional forwarder gaps
In hybrid environments, on-premises clients may fail to resolve a private cloud zone if the on-premises resolver has no conditional forwarder for that namespace.
Check that queries for the private zone are forwarded to a DNS server that can resolve it. For AWS, this may be the VPC DNS resolver (typically the VPC network range + 2, such as 10.0.0.2). In Azure, the DNS architecture may use 168.63.129.16, Azure DNS Private Resolver, or another configured DNS service.
Test the same hostname from the affected and working networks to identify where resolution differs.
Search domain differences
Different DHCP scopes can distribute different DNS search domains, causing the same short hostname to resolve differently between subnets.
For example, one subnet may resolve app as app.corp.example.com, while another tries app.example.com. Compare the DNS suffix and search list on working and affected clients: ipconfig /all
If the search domains differ, check the DHCP scope configuration. You can also test the fully qualified domain name directly: dig app.corp.example.com.
If the FQDN resolves correctly but the short hostname does not, the problem is likely with the client's search-domain configuration rather than the DNS record.
DNS resolves correctly but the application still fails
A successful DNS lookup does not guarantee that an application can connect. If nslookup or dig returns the expected IP address but the application still fails, check the connection path and any application-level DNS behavior.
Check IPv6 and dual-stack resolution
If DNS returns both A (IPv4) and AAAA (IPv6) records, a client may attempt an IPv6 connection. If IPv6 connectivity is broken or the AAAA record is incorrect, the application can experience connection delays or failures even though DNS resolution succeeds.
Check whether an AAAA record exists: dig AAAA app.example.com
If the application does not support IPv6 end-to-end, verify that the AAAA record is intentional and that the IPv6 route and firewall configuration are working.
Check application-level DNS caching
Some applications cache DNS responses independently of the operating system. Java applications, for example, can retain successful DNS lookups according to the JVM's DNS cache settings. After an IP address changes, an application may therefore continue using the previous address until its DNS cache expires or the process is restarted.
If command-line DNS queries return the new address but the application continues using the old one, check the application's DNS caching behavior before changing the DNS infrastructure.
Check reverse DNS for authentication-related failures
Some services perform reverse DNS lookups on connecting IP addresses. If the PTR record is missing or does not correspond to the expected hostname, authentication or connection checks can fail even when forward DNS resolution works.
Check both directions: dig A app.example.com and dig -x 10.1.2.34
The PTR record should point to the expected hostname, and that hostname should resolve back to the appropriate IP address. Reverse DNS mismatches are particularly common after IP address changes or server migrations.
DNS troubleshooting by symptom
| Symptom | Most likely cause | First check |
|---|---|---|
| All DNS fails on one device only | Incorrect DNS server, VPN overriding DNS, or local resolver configuration | ipconfig /all or cat /etc/resolv.conf |
| One domain returns NXDOMAIN | Missing record, negative cache, or incorrect hostname/search suffix | dig app.example.com @ns1.example.com |
| Query returns REFUSED | Client IP not permitted by ACL or recursion policy | Compare the query from an affected and known-good client |
| Updated record still returns the old IP | Resolver or client-side DNS cache has not expired | dig app.example.com; check the remaining TTL |
| DNS works for some users but not others | Split-horizon mismatch, missing conditional forwarder, or different search domains | Compare DNS configuration between working and affected clients |
| DNS resolves but the application fails | IPv6 connectivity, application-level DNS cache, or reverse DNS mismatch | dig AAAA app.example.com; dig -x <ip> |
Monitor and troubleshoot DNS with ManageEngine OpUtils
ManageEngine OpUtils helps network teams monitor and manage DNS across on-premises and cloud environments from a centralized console. With Microsoft DNS management, administrators can manage DNS zones and records, view SOA and name server details, monitor zone replication and transfer settings, and receive alerts for forward and reverse lookup failures or unexpected IP changes.
For cloud DNS, OpUtils integrates with AWS Route 53 to discover and manage public and private hosted zones and DNS records. Administrators can also configure Route 53 routing policies and associate health checks with DNS records, providing centralized visibility across on-premises DNS and AWS environments.
When troubleshooting DNS issues such as failed lookups, incorrect responses, or record inconsistencies, OpUtils helps network teams identify and manage the underlying DNS configuration from a single interface.
Download a free 30-day trial or schedule a personalized demo to explore DNS monitoring and management with OpUtils.
FAQs on DNS troubleshooting
What does NXDOMAIN mean and how do I fix it?
NXDOMAIN (Non-Existent Domain) means the queried DNS name does not exist. Common causes include a missing or incorrectly named record, a cached negative response, or an incorrect DNS search domain causing the client to query the wrong hostname. To troubleshoot, query the authoritative nameserver directly with dig hostname @authoritative-ns and compare the response with your recursive resolver.