Complete DNS Resolution Failure

Step 1 — Confirm it is a DNS failure, not routing

Verify IP-level connectivity is healthy before blaming DNS:

# Linux / macOS
ping -c 4 8.8.8.8          # Google public resolver — should succeed
ping -c 4 1.1.1.1          # Cloudflare resolver — should succeed
ping -c 4 google.com       # Should fail if DNS is broken

# Windows
ping 8.8.8.8
ping google.com

If the IP pings succeed but the hostname ping fails, DNS is the problem.

Step 2 — Check the configured resolver

# Linux (systemd-resolved)
resolvectl status
cat /etc/resolv.conf

# macOS
scutil --dns | head -20
cat /etc/resolv.conf

# Windows (PowerShell)
Get-DnsClientServerAddress
ipconfig /all | findstr "DNS Servers"

Note the resolver IP(s). A common culprit is 127.0.0.53 (systemd-resolved stub) or a DHCP-assigned address that has become unreachable.

Step 3 — Query the resolver directly

# Test the configured resolver
dig @127.0.0.53 google.com         # systemd-resolved stub
dig @192.168.1.1 google.com        # DHCP-assigned resolver (adjust IP)
dig @8.8.8.8 google.com            # Bypass local resolver entirely

# Windows
nslookup google.com
nslookup google.com 8.8.8.8        # Bypass to known-good resolver

If dig @8.8.8.8 works but your local resolver fails, the local resolver is the problem.

Step 4 — Check systemd-resolved or local DNS daemon

# systemd-resolved (Ubuntu 18.04+, Debian 10+)
systemctl status systemd-resolved
journalctl -u systemd-resolved --no-pager -n 50

# Restart the resolver
sudo systemctl restart systemd-resolved

# macOS — flush and restart mDNSResponder
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Step 5 — Inspect /etc/resolv.conf

cat /etc/resolv.conf

Look for: - No nameserver lines (file is empty or only has comments) - A nameserver IP that is unreachable (e.g., a VPN DNS that is no longer connected) - A stale symlink (on systems using resolvconf or systemd-resolved)

Step 6 — Check firewall rules blocking UDP/TCP port 53

# Linux — check iptables / nftables
sudo iptables -L OUTPUT -n -v | grep 53
sudo nft list ruleset | grep 53

# Test raw UDP connectivity to resolver
nc -zvu 8.8.8.8 53       # UDP
nc -zv  8.8.8.8 53       # TCP (for DNS over TCP)

# Windows
Test-NetConnection -ComputerName 8.8.8.8 -Port 53

Fix 1 — Temporarily use a public resolver

# Linux — edit /etc/resolv.conf directly (temporary, survives until DHCP renews)
sudo bash -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'
sudo bash -c 'echo "nameserver 1.1.1.1" >> /etc/resolv.conf'

# Test immediately
dig google.com

Fix 2 — Restart the local resolver daemon

# systemd-resolved
sudo systemctl restart systemd-resolved

# macOS
sudo killall -HUP mDNSResponder

Fix 3 — Renew DHCP lease to get new DNS assignment

# Linux (NetworkManager)
nmcli connection down "Wired connection 1" && nmcli connection up "Wired connection 1"

# Linux (dhclient)
sudo dhclient -r && sudo dhclient

# macOS
sudo ipconfig set en0 DHCP

# Windows
ipconfig /release && ipconfig /renew

Fix 4 — Set a static resolver in NetworkManager

nmcli connection modify "Wired connection 1" ipv4.dns "8.8.8.8 1.1.1.1"
nmcli connection modify "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli connection up "Wired connection 1"

Fix 5 — Unblock port 53 in firewall (if blocked)

# iptables (Linux)
sudo iptables -I OUTPUT -p udp --dport 53 -j ACCEPT
sudo iptables -I OUTPUT -p tcp --dport 53 -j ACCEPT

• Configure at least two resolver IPs (primary and fallback) in all network profiles
• Use a monitoring check that alerts when dig @<resolver> healthcheck.example.com fails
• Avoid relying on VPN-provided DNS without a split-DNS fallback for public domains
• On cloud VMs, prefer using the VPC's internal resolver (e.g., 169.254.169.253 on AWS) rather than external resolvers that may be blocked by security groups
• Pin /etc/resolv.conf with chattr +i on servers where DHCP should not overwrite a known-good configuration