DNS Not Resolving: Step-by-Step Fix

Common Causes of DNS Failures

DNS failure is one of the most frequent causes of "the internet is broken" reports, even when the underlying network connection is perfectly healthy. The symptoms are characteristic: you can ping 8.8.8.8 successfully, but opening a website shows an error like "Server not found" or "DNS_PROBE_FINISHED_NXDOMAIN."

Common root causes:

Flush DNS Cache

Operating systems cache DNS responses to speed up subsequent lookups. A stale or corrupt cache entry can cause resolution failures for specific domains.

# macOS (all versions)
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Ubuntu/Debian with systemd-resolved
sudo systemd-resolve --flush-caches
# Verify flush
sudo systemd-resolve --statistics | grep "Cache Entries"

# Ubuntu/Debian with nscd
sudo service nscd restart

# Windows
ipconfig /flushdns

# Verify the flush (Linux)
sudo systemd-resolve --statistics

After flushing, retry the failing domain. If it resolves once and then fails again immediately, the upstream authoritative server may be returning bad data.

Change DNS Servers

Your system's DNS resolver is configured either via DHCP (automatically from your router) or manually. Switching to a reliable public resolver is the fastest way to isolate whether the problem is with your ISP's DNS.

Linux — /etc/resolv.conf:

# View current DNS servers
cat /etc/resolv.conf

# Temporarily override (survives until next DHCP lease)
sudo bash -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'
sudo bash -c 'echo "nameserver 1.1.1.1" >> /etc/resolv.conf'

Linux with systemd-resolved (modern Ubuntu/Debian):

# Edit resolved configuration
sudo nano /etc/systemd/resolved.conf
# Set:
# [Resolve]
# DNS=8.8.8.8 1.1.1.1
# FallbackDNS=9.9.9.9

sudo systemctl restart systemd-resolved

macOS:

Go to System Settings → Network → select your interface → Details → DNS, and add 8.8.8.8 and 1.1.1.1.

Windows:

Control Panel → Network and Sharing Center → Change adapter settings
→ Right-click your connection → Properties → IPv4 Properties
→ Use the following DNS server addresses: 8.8.8.8 / 1.1.1.1

Recommended public DNS options:

Check /etc/resolv.conf

On Linux systems, /etc/resolv.conf controls DNS resolution. Misconfiguration here causes failures system-wide.

cat /etc/resolv.conf

A valid file looks like:

# Generated by NetworkManager
nameserver 192.168.1.1
nameserver 8.8.8.8
search home.local

Common problems:

• Empty file — No nameservers configured; all DNS queries fail immediately.
• 127.0.0.53 — systemd-resolved stub resolver. This is correct on modern Ubuntu. If DNS is failing with this, restart systemd-resolved: sudo systemctl restart systemd-resolved.
• Wrong IP — A stale entry pointing to a server that no longer exists.
• File is a regular file, not a symlink — On systemd systems, /etc/resolv.conf should be a symlink to /run/systemd/resolve/stub-resolv.conf. Check with ls -la /etc/resolv.conf.

Diagnose with nslookup and dig

nslookup and dig are the primary tools for hands-on DNS diagnostics.

# Basic lookup
nslookup google.com

# Query a specific DNS server
nslookup google.com 8.8.8.8

# Look up a specific record type
nslookup -type=MX gmail.com
nslookup -type=TXT google.com

# Using dig (more detailed output)
dig google.com
dig google.com @8.8.8.8
dig google.com @1.1.1.1

# Query MX records
dig MX gmail.com

# Reverse lookup (IP to hostname)
dig -x 8.8.8.8

# Trace the full resolution path
dig +trace google.com

# Show only the answer
dig +short google.com

Interpreting dig output:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345

DNSSEC Validation Failures

DNSSEC adds cryptographic signatures to DNS records. If a domain's DNSSEC records are misconfigured or expired, DNSSEC-validating resolvers return SERVFAIL even though the domain exists.

# Check if DNSSEC is causing the failure
# If this works but plain lookup fails, DNSSEC validation is the issue
dig google.com @8.8.8.8 +cd   # +cd = disable DNSSEC validation

# Check DNSSEC signatures
dig google.com @8.8.8.8 +dnssec

# Test with a non-validating resolver
dig google.com @1.0.0.1

If dig domain.com +cd resolves successfully but dig domain.com returns SERVFAIL, the domain has a DNSSEC configuration error. This is a problem for the domain owner (broken RRSIG or DS record), not something you can fix as an end user. Use +cd (disable checking) temporarily, or use a non-DNSSEC-validating resolver like 8.8.8.8 (Google) or 9.9.9.10 (Quad9 without blocking).

When to Contact Your ISP

Contact your ISP when:

1. All public DNS servers (8.8.8.8, 1.1.1.1, 9.9.9.9) fail to resolve.
2. dig google.com +trace fails at the root server query step.
3. Other devices on the same network have the same DNS failure.
4. The problem started after your ISP performed maintenance.

When calling, tell them: "I cannot resolve DNS queries even when using 8.8.8.8 directly. My router shows a valid WAN IP. Traceroute reaches your first gateway but DNS queries time out."