DNS server not responding: Causes, diagnosis and fixes

The hidden risk of secondary DNS servers

Many organizations configure secondary DNS servers for redundancy but rarely verify whether failover is actually working as expected. When the primary DNS server fails, the secondary server may continue answering queries using outdated zone records because zone transfers have been failing silently in the background.

This creates a difficult troubleshooting scenario. DNS appears functional because DNS queries still receive responses, but users are directed to stale or incorrect IP addresses. Applications fail intermittently, services connect to the wrong systems, and administrators often spend hours investigating network or application layers before discovering the real issue is stale DNS data.

This is why enterprise DNS management should include DNS server availability, along with zone synchronization status, DNS response consistency, replication health, and resolver performance across sites and subnets.

Why these DNS errors matter during troubleshooting

Not all DNS failures mean the server is offline.

A TIMEOUT error is the only error code that implies the DNS server did not respond. In this case, the issue usually points to network connectivity problems, firewall filtering, unreachable resolvers, or DNS services that have stopped running.

Errors such as SERVFAIL and REFUSED are different. They are valid DNS responses, which means the DNS server is reachable and actively replying. The failure is happening elsewhere in the DNS resolution process.

For example:

• A SERVFAIL response often indicates upstream resolution problems, DNSSEC failures, or broken delegations.
• A REFUSED response typically points to access control lists (ACLs), recursive query restrictions, or firewall policies blocking the client.

In enterprise environments, analyzing DNS error codes alongside resolver logs, packet captures, and DNS query performance metrics provides much faster root-cause identification than relying on generic “DNS server not responding” messages alone.

Read more:DNS troubleshooting guide

1. DNS service stopped on the server

One of the most direct causes is the DNS service stopping unexpectedly. On Linux systems, this could involve BIND or named, while Windows environments rely on the DNS Server service. Crashes, failed updates, memory exhaustion, or manual changes can cause the service to stop listening on port 53.

In this scenario, the server may still respond to pings and appear online, but DNS queries receive no response because the DNS process is no longer running.

Common indicators:

• DNS queries time out.
• Port 53 is not listening.
• All clients using the resolver lose name resolution simultaneously.
• Server remains reachable by IP address.

Typically affects: All clients using that resolver.

2. Firewall blocking port 53 (UDP or TCP)

DNS depends on port 53 over both UDP and TCP. UDP handles most standard DNS lookups, while TCP is used for larger DNS responses, DNSSEC-related traffic, and zone transfers.

If a firewall rule blocks DNS traffic between clients and the resolver, queries silently fail. From the client’s perspective, the DNS server appears unresponsive even though the resolver itself may be fully operational.

This is a frequent cause of DNS outages after firewall changes or security policy updates.

Common indicators:

• DNS queries consistently time out.
• Resolver remains healthy internally.
• Packet captures show dropped or blocked port 53 traffic.
• Outage starts immediately after firewall or ACL changes.

Typically affects: Clients behind the affected firewall rule.

3. Incorrect DNS resolver IP assigned through DHCP

In enterprise networks, DHCP option 006 distributes DNS server addresses to clients automatically. If the configured resolver IP is outdated, mistyped, decommissioned, or unreachable from a specific VLAN, devices begin using invalid DNS servers.

This often creates inconsistent behavior across the network because devices with older DHCP leases continue working temporarily, while newly connected or recently renewed devices fail immediately.

Common indicators:

• Some devices resolve DNS normally while others fail.
• Failures increase gradually as DHCP leases renew.
• Incorrect DNS server IP visible in client network settings.
• Problem isolated to a specific subnet or VLAN.

Typically affects: Newly joined devices or systems after DHCP lease renewal.

4. Resolver overloaded or timing out under heavy query load

A recursive DNS resolver under excessive load may begin queuing requests faster than it can process them. Once the queue exceeds capacity, DNS requests start timing out before they are answered.

This can happen during traffic spikes, infrastructure scaling events, malware outbreaks, or DNS flood attacks. Unlike a full outage, overloaded resolvers often produce intermittent failures that worsen during peak business hours.

Common indicators:

• DNS latency increases before failures occur.
• Intermittent query timeouts.
• High CPU or memory usage on DNS servers.
• Performance degradation during traffic spikes.

Typically affects: Multiple clients intermittently during high load periods.

5. Authoritative server unreachable causing SERVFAIL responses

Sometimes the recursive resolver is healthy, but the authoritative nameserver for a domain becomes unavailable. The resolver attempts the full DNS lookup process but cannot obtain a valid response from the authoritative server.

After retry attempts fail, the recursive resolver returns a SERVFAIL response to the client. This issue is often limited to specific domains or DNS zones.

Common indicators:

• Only certain domains fail to resolve.
• External DNS lookups may work while internal zones fail.
• Resolver logs show repeated upstream lookup failures.
• Clients receive SERVFAIL instead of timeout errors.

Typically affects: Queries targeting specific zones or domains.

6. DNSSEC validation failure

When DNSSEC validation is enabled, recursive resolvers verify digital signatures attached to DNS records. If a signature check fails due to expired keys, incorrect DS records, or broken key rollovers, the resolver rejects the response.

The DNS infrastructure itself may still be online and reachable, but validation failures cause the resolver to return SERVFAIL responses instead of potentially untrusted answers.

Common indicators:

• DNSSEC-enabled domains fail while unsigned domains resolve normally.
• Resolver logs show validation or signature errors.
• SERVFAIL responses appear despite healthy connectivity.
• Failures begin after DNSSEC key changes or rollovers.
  

Typically affects: DNSSEC-signed zones with invalid or mismatched signatures.

7. Single-device DNS misconfiguration

If the issue impacts only one system, the problem is usually local to that device rather than the DNS infrastructure itself.

Common causes include manually configured DNS settings, stopped DNS client services, corrupted local DNS cache, VPN software overriding DNS behavior, or conflicting entries in the local hosts file.

Common indicators:

• Only one device experiences failures.
• Other systems on the same subnet work normally.
• Device uses a static or incorrect DNS server IP.
• VPN or endpoint security software modifies DNS resolution behavior.
  

Typically affects: One device only.

Why identifying the root cause matters

Many DNS failures produce the same user-facing symptom, but the underlying fixes are completely different. Restarting a resolver service will not solve a firewall issue. Changing DNS settings will not fix a DNSSEC validation failure.

The fastest way to troubleshoot a DNS server not responding error is to first determine:

• The scope of impact.
• Whether queries are timing out or returning responses.
• Which layer of the DNS resolution chain is failing.
  

This approach reduces unnecessary troubleshooting steps and helps isolate DNS outages much faster in enterprise environments.

1. Confirm the problem is DNS and not general network connectivity

Before troubleshooting DNS, verify that the device still has basic network access. If a direct IP ping succeeds but hostname resolution fails, the network is working and the issue is specifically related to DNS resolution.

# Test basic network connectivity
ping 8.8.8.8

If the ping succeeds, test DNS resolution:

# Windows
nslookup manageengine.com

# Linux/macOS
dig manageengine.com

For dig, pay attention to:

• status: field
• Query time
• Timeout messages
• SERVFAIL or REFUSED responses

If IP connectivity works but DNS queries time out or fail, the issue is isolated to DNS infrastructure.

3. Test the resolver directly and compare against a known-good resolver

Once you know which resolver the client is using, query it directly. Then compare the results with a public DNS resolver such as Google DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1).

If public DNS works but the internal resolver fails, the issue is with your DNS infrastructure rather than the queried domain.

Query internal DNS resolver
nslookup manageengine.com 10.1.1.10

Compare with public DNS
nslookup manageengine.com 8.8.8.8

Using dig for detailed output
dig manageengine.com @10.1.1.10

This helps identify:

• Query timeouts
• SERVFAIL responses
• REFUSED errors
• Slow DNS response times
• Incorrect DNS records
  

4. Verify port 53 connectivity

DNS requires port 53 over both UDP and TCP. If the resolver is reachable by ping but DNS queries fail, a firewall or ACL may be blocking DNS traffic.

Windows
Test-NetConnection 10.1.1.10 -Port 53

Linux UDP test
nc -u -zv 10.1.1.10 53

Also verify the DNS service is listening on the server itself:

netstat -an | grep ":53"

If port 53 is blocked:

• DNS queries time out.
• The resolver appears offline from the client perspective.
• Packet captures may show dropped DNS traffic.
• Firewall changes are one of the most common causes of sudden enterprise DNS outages.
  

5. Check whether the DNS service is running

If the resolver server is reachable but not answering queries, verify the DNS service itself is operational.

Windows Server
Get-Service DNS

If stopped:

• Start-Service DNS
• Check recent DNS-related events:
• Get-EventLog -LogName System -Source DNS -Newest 20
  

Linux (BIND)
systemctl status named

Start the service if necessary:
systemctl start named

Common causes of DNS service failure include:

• Failed updates
• Memory exhaustion
• Corrupted zone files
• Misconfigured DNSSEC
• Unexpected service crashes
  

6. Investigate SERVFAIL responses and DNSSEC issues

A SERVFAIL response means the resolver is reachable, but the lookup process failed somewhere upstream.

One of the most common enterprise causes is DNSSEC validation failure.

Test the query again with DNSSEC checking disabled:
dig manageengine.com +cd

If the query succeeds only when validation is disabled:

• DNSSEC signatures may be invalid
• DS records may not match
• Zone signing keys may have expired
• Key rollover may have failed

To trace the entire lookup path and identify where resolution breaks:

dig manageengine.com +trace

This command shows:

• Root server responses
• TLD delegation
• Authoritative server responses
• Which server in the chain fails
  

Why structured DNS troubleshooting matters

Most “DNS server not responding” incidents are not caused by a single issue. The same symptom can result from:

• Firewall blocks
• DHCP misconfiguration
• Resolver overload
• DNSSEC failures
• Stopped DNS services
• Broken authoritative zones

A structured troubleshooting process helps eliminate guesswork and quickly identifies whether the problem is:

• Local
• Network-related
• Resolver-related
• Upstream DNS-related
• Security or DNSSEC-related

In enterprise networks, combining DNS query testing, resolver health monitoring, DHCP validation, and DNS traffic analysis provides much faster root-cause identification than relying only on end-user error messages.

Always configure a secondary DNS resolver

Every client subnet should have both a primary and secondary DNS resolver configured through DHCP. Relying on a single DNS server creates a single point of failure, and eventually that resolver will become unavailable due to maintenance, crashes, network issues, or overload.

For true resilience, the secondary resolver should not depend on the same infrastructure as the primary. Ideally, it should use:

• Separate hardware or virtual hosts
• A different network path
• A different physical site
• Independent upstream connectivity

Some organizations also use a trusted external resolver as an emergency fallback for internet resolution.

Without secondary DNS redundancy, even a short resolver outage can disrupt authentication, application access, cloud connectivity, and internet browsing across the organization.

Monitor primary and secondary DNS servers independently

A common enterprise mistake is monitoring only the primary resolver while assuming the secondary is healthy.

In many DNS outages, the secondary resolver has already been failing silently for days or weeks. Problems such as stale zone transfers, replication failures, or unreachable services often remain unnoticed until the primary resolver fails and traffic shifts to the secondary.

DNS monitoring should continuously validate:

• Resolver reachability
• Query response time
• DNS response accuracy
• Zone transfer status
• Forward and reverse lookup consistency
• Replication freshness between primary and secondary servers

Independent monitoring ensures redundancy actually works when failover occurs.

Alert on SERVFAIL and TIMEOUT spikes

DNS failures rarely appear instantly. Most outages begin with increasing query delays, intermittent SERVFAIL responses, or rising timeout rates before users report visible issues.

Monitoring DNS error patterns provides early warning of problems such as:

• Resolver overload
• DNSSEC validation failures
• Authoritative server instability
• Packet loss
• Firewall filtering
• Upstream DNS degradation

Set threshold-based alerts for:

• SERVFAIL rate increases
• DNS query timeout spikes
• Sudden DNS latency growth
• Failed recursive queries
• Unresponsive resolvers

Catching these indicators early allows teams to resolve DNS issues before they become full-scale outages.

Verify DNS after every infrastructure change

DNS dependencies are involved in nearly every infrastructure change, yet DNS validation is often skipped during post-change testing.

Common change-related DNS failures include:

• Firewall rules blocking port 53
• DHCP scopes distributing incorrect resolver IPs
• VLAN or routing changes breaking resolver reachability
• DNS server migrations with outdated records
• Reverse lookup mismatches after IP changes

After any infrastructure modification, validate:

• Forward DNS lookups
• Reverse DNS lookups
• Resolver reachability
• Zone transfer status
• Internal and external resolution paths

Adding DNS verification into change management procedures significantly reduces preventable outages.

Monitor DNSSEC key expiration proactively

DNSSEC failures are highly predictable because every DNSSEC key has a defined expiration date. Despite this, expired signatures remain one of the most common causes of unexpected SERVFAIL responses.

If a DNSSEC key expires without renewal:

• DNSSEC-validating resolvers reject responses.
• Entire domains become unreachable.
• Clients receive SERVFAIL errors even though servers remain online.

To prevent DNSSEC-related outages:

• Monitor DNSSEC key expiration dates continuously.
• Configure automated renewal alerts.
• Validate DS record synchronization after key rollovers.
• Test DNSSEC validation after signing changes.

DNSSEC failures frequently occur during weekends or maintenance windows when monitoring is insufficient, making proactive alerting especially important.

Continuously monitor DNS health across the network

Reactive troubleshooting is slow because DNS problems often surface only after users experience outages. Continuous DNS monitoring helps identify failures much earlier.

ManageEngine OpUtils provides continuous DNS resolution monitoring across enterprise networks by checking:

• DNS server availability
• Resolver response time
• Forward and reverse DNS consistency
• Failed lookups
• Incorrect DNS responses

Instead of waiting for users to report “DNS server not responding” errors, network teams can detect degraded DNS performance, stale records, or failing resolvers before the issue impacts business services.