DNS failures are one of the most common — and most confusing — networking problems. When your browser shows "DNS server not responding", your device can't translate domain names (like example.com) into IP addresses. That stops web, email, chat, and many apps.
This guide walks you through how to test, diagnose, and fix DNS issues on client devices and on DNS servers themselves (recursive and authoritative). You'll find OS-specific commands, network-level troubleshooting, server-level debugging for common DNS software, monitoring tips, and prevention best practices.
When users report "DNS server not responding", follow these quick checks first:
Reboot the device (computer, phone) and the router.
Test another device on the same network — same problem? If yes, likely network / router / ISP.
Try a known good resolver immediately: open terminal and ping 1.1.1.1 (Cloudflare). If IP ping works but domain names don't, it's DNS.
Temporarily switch to a public DNS (Cloudflare 1.1.1.1 / Google 8.8.8.8 / Quad9 9.9.9.9) and retest.
If you're on a VPN, disconnect and retest (or connect and see if DNS changes).
Result: If these fix it, read the relevant "fast fix" sections below. If not, continue with full diagnostics.
The DNS server your device queries (ISP or configured resolver).
The server that holds DNS records for a domain.
The tiny resolver in OS that forwards queries.
DNS uses UDP/TCP port 53, plus DoT (TCP 853) and DoH (HTTPS 443).
Understanding which piece is failing (your local resolver, the ISP's recursive resolver, the authoritative DNS) makes diagnosis far easier.
| Symptom | Likely Cause |
|---|---|
| "DNS server not responding" (browser) | Your stub resolver couldn't get a reply. Could be local, router, or ISP. |
| Intermittent name resolution | Maybe packet loss, overloaded resolver, or rate limiting. |
| Only some domains fail | Authoritative DNS problem or DNSSEC failure. |
| All domains fail but IPs work | DNS-only issue (network connectivity okay). |
| Slow name resolution | Overloaded/latency on resolver, or network congestion. |
Basic query:
Query specific resolver:
Trace full resolution:
Check DNSSEC:
Linux (systemd): systemd-resolve --status or resolvectl status
macOS: scutil --dns
Windows: ipconfig /all
1. Confirm DNS server addresses:
2. See which resolver responds:
3. Flush DNS cache:
4. Temporarily set DNS on adapter to 1.1.1.1 and 1.0.0.1 and retest.
5. Check firewall/antivirus (they sometimes block DNS or override settings).
1. Inspect resolver config:
2. Clear caches:
3. Test with dig:
1. Check resolver status:
Or check /etc/resolv.conf
2. Check systemd-resolved logs:
3. Test with specific resolver:
4. If resolv.conf is a symlink to systemd stub 127.0.0.53, ensure systemd-resolved is correctly configured.
Compare ISP DNS vs public DNS:
If ISP fails consistently, contact ISP or check ISP outage notifications (social, status pages).
1. Check service status:
2. Check logs:
3. Verify zone files (BIND):
4. Verify port reachability:
5. Test authoritative responses from outside:
Cause: Local DNS cache corrupted or stub resolver misconfigured.
Fix: Flush cache, restart resolver service, correct /etc/resolv.conf to expected nameservers.
Commands:
Cause: Router DNS override, faulty firmware, or ISP DNS cached bad results.
Fix: Reboot router, update firmware, set router DNS to Cloudflare/Google/Quad9, disable DNS hijacking features.
Cause: Firewall rules (local or upstream) block UDP/TCP 53.
Fix: Ensure rules allow DNS traffic. On Linux servers, check iptables/nftables rules and allow port 53.
Sample firewall allow (iptables):
Cause: System tries IPv6 resolver while VPN/ISP doesn't support IPv6.
Fix: Disable IPv6 temporarily or configure VPN/OS to prefer IPv4 for DNS. Better fix: enable IPv6 on VPN/resolve properly.
Cause: High query volume, DDoS, or misconfigured rate-limiting.
Fix: Add caching layer (Unbound/dnsmasq), scale with Anycast/resolvers, enable rate limiting protection (RPZ, rate-limit settings).
Cause: Bad zone file, syntax errors, expired domain, wrong glue records.
Fix: Run named-checkzone, named-checkconf; check registrar NS records and glue records; ensure SOA serial correct; test from multiple global resolvers.
Cause: Signature mismatch or missing DS records cause resolvers to drop responses.
Fix: Verify DNSSEC chain with dig +dnssec example.com and fix signatures or remove DNSSEC until fixed.
Cause: Some apps use DoH/DoT bypassing system resolver, which can conflict with VPN or local controls.
Fix: Align browser DoH settings with system/VPN policy, or centralize DoH at network edge.
If systemd manages resolv.conf, use:
(Assume VPN interface tun0. This blocks port 53 unless through tun0.)
Warning: Be careful — this can lock you out if incorrectly applied. Test in console with a way to revert.
Edit /etc/unbound/unbound.conf add:
Restart:
Query:
Check /etc/dnsmasq.conf:
Restart:
Common issues: syntax errors, ACLs, exhausted file descriptors, chroot problems.
Useful commands:
Logs: /var/log/named/ or journalctl -u named
Often used as local cache to reduce external queries. Good for privacy (supports TLS, DNS over TLS).
Debugging:
Logs: journalctl -u unbound
Common in home routers. Ensure listen-address and bind-interfaces configured correctly.
Config: /etc/dnsmasq.conf
Check backend DB (MySQL/Postgres) if authoritative data missing.
Recursor: check pdns_recursor logs.
Check Kubernetes Service/Endpoint config and health probes.
Logs:
Or capture to file:
Open dns.pcap in Wireshark and filter by 'dns'
Look for:
Shows each step from root → TLD → authoritative. Where it fails reveals the problematic zone or server.
Use online DNS checkers or run:
Also test from a public VPS (e.g., an external server you control).
Then query each NS directly.
Quick fix: Settings → Network & internet → Private DNS → set 1dot1dot1dot1.cloudflare-dns.com (DoH) or disable to use system DNS.
If using an app VPN, ensure app provides DNS leak protection.
Use VPN vendor app or configuration profile to set DNS.
iOS supports DNS-over-HTTPS / Private DNS through profiles or app-managed settings (some DNS apps like Cloudflare provide configuration).
Run a local caching resolver (Unbound or dnsmasq) on servers to reduce upstream queries.
Use Anycast + multiple POPs for public resolvers (for scale).
Enable monitoring: query latency, failure rate, served queries/sec (Prometheus + Grafana).
Alert on high SERVFAIL rates, high query failure rate, or backlog errors.
Log enough to diagnose but avoid logging full query payloads for privacy/volume reasons.
Periodically verify authoritative records, DNSSEC, and registrar settings (automation via scripts).
Encrypt DNS queries to prevent interception.
Via proper server and app settings.
And response-policy zones (RPZ) for blocking malware.
Don't forward client DNS to third-party resolvers without consent.
ping 1.1.1.1).nslookup example.com — note server shown.ipconfig /flushdns (Windows) / sudo systemd-resolve --flush-caches (Linux).dig @1.1.1.1 site.com — if the authoritative servers don't respond, check domain registrar and authoritative NS.ping 1.1.1.1
dig example.com
dig @1.1.1.1 example.com
tcpdump port 53
dig +dnssec
Yes — big public resolvers (Cloudflare, Google, Quad9) are widely used. Choose based on privacy policy.
Only as a temporary diagnosis step. Proper fix is to have IPv6 aware DNS/VPN or configure resolver properly.
Many home routers have buggy DNS forwards or stale caches that a reboot clears.
Reboot router, test with 1.1.1.1, flush DNS cache, try another device. See Quick Triage section.
Use dig @1.1.1.1 example.com and dig @<ISP-DNS> example.com. Compare results.
Use named-checkzone and named-checkconf and then rndc reload.
Test resolver:
Capture DNS:
Restart resolver:
Check listening:
Show DNS config:
Flush cache:
Test via dig:
Show DNS config:
Flush cache:
Test resolver:
Check config & zones:
Reload zone:
Learn the fundamentals of the Domain Name System
Understand DNS server types and functions
Clear your DNS cache to fix resolution issues
Check if your VPN is leaking DNS requests
Find secure and privacy-focused DNS providers
Test DNS records and resolution
Use our DNS lookup tool to diagnose issues, or explore our complete DNS guide library.
We may log anonymized request data for diagnostics. Read our Privacy Policy.
© 2025 DNS Lookup. All rights reserved. Proudly Hosted on MonoVM VPS Hosting
We use HTTPS, HSTS, and regular security reviews. Report issues at [email protected]
If you believe a tool is being misused, report it at [email protected]