Fix DNS SERVFAIL: Server Failed to Respond (2026)

The DNS resolver your client is talking to is failing to get a valid answer from an upstream DNS server, and it’s giving up.

This usually means there’s a problem somewhere between your client and the authoritative DNS servers for the domain you’re trying to reach, or the authoritative servers themselves are having issues.

1. Network Connectivity to Upstream DNS Servers

Diagnosis: From the client experiencing the SERVFAIL, try pinging the upstream DNS server IP address. If you’re using a public DNS server like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1, this is straightforward. For a local resolver, identify its upstream servers using resolvectl status (on systemd-based systems) or by checking /etc/resolv.conf.
```
ping 8.8.8.8
```
Fix: If ping fails, there’s a network issue. Check firewall rules on the client, any intermediate firewalls, or network routing. Ensure UDP/53 and TCP/53 traffic is allowed to the upstream DNS servers. For example, on an iptables firewall:
```
sudo iptables -A OUTPUT -p udp --dport 53 -d 8.8.8.8 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 53 -d 8.8.8.8 -j ACCEPT
```
This explicitly allows outgoing DNS traffic to 8.8.8.8.

2. Upstream DNS Server Unreachable or Down

Diagnosis: Use dig to query a known-good domain against the specific upstream server that might be failing. If you suspect a particular upstream server (e.g., 192.168.1.1 on your local network), query it directly.
```
dig @192.168.1.1 google.com
```
If this query times out or returns SERVFAIL itself, the upstream server is the problem.
Fix: If your upstream DNS server is a local router or a dedicated DNS server, restart it. If it’s a public DNS server like 8.8.8.8 and it’s consistently failing, switch to an alternative public DNS provider (e.g., 1.1.1.1, 9.9.9.9) in your client’s network settings or router configuration. For example, on Linux, edit /etc/resolv.conf:
```
nameserver 1.1.1.1
nameserver 8.8.4.4
```
This tells the system to try Cloudflare’s DNS first, then Google’s secondary.

3. DNSSEC Validation Errors

Diagnosis: DNSSEC can cause SERVFAIL if the client’s resolver is configured to validate DNSSEC signatures but encounters a broken chain of trust or invalid signatures for the domain being queried. Use dig +dnssec to see the DNSSEC records.
```
dig +dnssec google.com A
```
Look for status: SERVFAIL and check the flags for ad (authenticated data). If it’s missing or !<ad>, validation might be failing.
Fix: The most common fix is to disable DNSSEC validation on the client or local resolver if you don’t strictly need it and are experiencing persistent SERVFAILs for specific domains. On systemd-resolved, this is done by editing /etc/systemd/resolved.conf:
```
[Resolve]
DNSSEC=no
```
Then restart systemd-resolved: sudo systemctl restart systemd-resolved. This tells the resolver to stop performing DNSSEC checks.

4. Local Resolver Configuration Issues (e.g., dnsmasq, unbound)

Diagnosis: If you run your own DNS resolver (like dnsmasq or unbound), check its logs for errors. For dnsmasq, logs are often found in /var/log/syslog or /var/log/messages. For unbound, check its specific log file as configured. Also, check the configuration file for syntax errors or incorrect upstream server settings.
```
sudo grep -i 'error\|fail' /var/log/syslog | grep dnsmasq
```
Fix: Correct any syntax errors in the configuration file (e.g., /etc/dnsmasq.conf or /etc/unbound/unbound.conf). Ensure the server= directives point to valid, reachable upstream DNS servers. After correcting, restart the service:
```
sudo systemctl restart dnsmasq
```
This reloads the configuration and applies the fixes.

5. Incorrect DNS Records on Authoritative Server

Diagnosis: The issue might not be with your client or intermediary servers, but with the authoritative DNS servers for the domain itself. Use dig to query the authoritative servers directly for the domain in question. You can find the authoritative servers using a dig NS query for the domain.
```
dig google.com NS
dig @ns1.google.com google.com A
```
If the authoritative server returns SERVFAIL or an incomplete answer, the problem is there.
Fix: This requires access to the DNS management console for the domain. You’ll need to contact the domain administrator to check and correct the DNS records (e.g., A, AAAA, MX, CNAME) for the domain. Ensure all necessary records are present and correctly formatted, and that the glue records for the NS records are also correct.

6. Firewall Blocking Outgoing DNS Queries from the Resolver

Diagnosis: If your client is configured to use a local DNS resolver (e.g., your router or a server on your network), that resolver itself might be blocked from reaching its upstream DNS servers. Test connectivity from the resolver machine itself.
```
# On the resolver machine
ping 8.8.8.8
dig @8.8.8.8 google.com
```
Fix: Examine the firewall rules on the DNS resolver machine or network device. Ensure it can make outbound UDP/53 and TCP/53 requests to its configured upstream DNS servers. For example, on a Linux server acting as a resolver:
```
sudo ufw allow out 53/udp
sudo ufw allow out 53/tcp
```
This opens outbound DNS ports on the firewall.

The next error you’ll likely hit after fixing SERVFAIL is NXDOMAIN if the DNS records themselves were malformed or missing, or a timeout if the underlying network issue persists.