DNS Resolution Failures

DNS Resolution Failures

DNS resolution failures are among the most disruptive network issues because they make correctly functioning services appear broken. An application that times out connecting to api.example.com looks like a network or application failure, but is often a DNS failure. DNS issues are also easy to diagnose once you know what to check. The key insight: always test by IP to confirm the network works before blaming DNS.

Common DNS errors

Diagnosing DNS failures

# Step 1: distinguish DNS failure from network failure:
ping 8.8.8.8     # Success = network works, DNS may be broken
ping google.com  # Failure = DNS failing

# Step 2: test with specific DNS server (bypass local resolver):
dig @8.8.8.8 google.com           # Query Google's DNS directly
dig @127.0.0.53 google.com        # Query systemd-resolved (Ubuntu default)
nslookup google.com 8.8.8.8       # Same, different tool

dig output — comparing resolvers

# dig @8.8.8.8 google.com works:
;; ANSWER SECTION:
google.com.    299  IN  A  142.250.80.46
;; Query time: 12 msec

# dig @127.0.0.53 google.com fails:
;; ANSWER SECTION: (empty)
;; status: SERVFAIL
# → Local resolver (systemd-resolved) is broken, Google DNS works
# Fix: restore local resolver to use working upstream DNS

# Step 3: check which DNS server is configured:
cat /etc/resolv.conf

/etc/resolv.conf output

nameserver 127.0.0.53     # Ubuntu: points to systemd-resolved stub
options edns0 trust-ad
search example.com        # Domain search suffix

# Check systemd-resolved status and upstream servers:
sudo systemd-resolve --status | head -30
resolvectl status    # Modern alternative

systemd-resolved issues

# systemd-resolved is the default resolver on Ubuntu 18.04+

# Restart resolved:
sudo systemctl restart systemd-resolved

# Flush DNS cache:
sudo resolvectl flush-caches
sudo systemd-resolve --flush-caches    # Older command

# Check current cache statistics:
sudo resolvectl statistics

# systemd-resolved configuration:
sudo nano /etc/systemd/resolved.conf

/etc/systemd/resolved.conf

[Resolve]
DNS=8.8.8.8 8.8.4.4    # Upstream DNS servers
FallbackDNS=1.1.1.1    # Fallback if primary fails
Domains=~.              # Use for all domains
DNSSEC=no               # Disable if causing SERVFAIL on some zones

sudo systemctl restart systemd-resolved
resolvectl status    # Verify new settings took effect

Fixing DNS configuration

# Emergency fix: bypass systemd-resolved and use direct DNS:
sudo tee /etc/resolv.conf > /dev/null << 'EOF'
nameserver 8.8.8.8
nameserver 8.8.4.4
EOF

# WARNING: /etc/resolv.conf on Ubuntu is normally a symlink managed by
# systemd-resolved. Replacing it breaks the integration:
ls -la /etc/resolv.conf    # Check if it is a symlink

# Better approach: configure DNS via Netplan (Ubuntu 18.04+):
sudo nano /etc/netplan/01-netcfg.yaml

/etc/netplan/01-netcfg.yaml — DNS configuration

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]
        search: [example.com]

sudo netplan apply

Conclusion

On Ubuntu, /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf — never replace it directly (the replacement will be overwritten on network restart). Configure DNS through Netplan or /etc/systemd/resolved.conf. If you see intermittent DNS failures, check for DNSSEC issues: set DNSSEC=no in resolved.conf and test — some internal DNS zones are not DNSSEC-signed, and systemd-resolved with DNSSEC enabled will fail to resolve them.