Stackvora.tech

Troubleshooting DNS Resolution Issues

In-depth guide to troubleshooting DNS resolution issues, covering client-side checks, server diagnostics, delegation paths, common pitfalls, and resolution strategies.

DNS (Domain Name System) is a foundational service for nearly all network communication. When DNS fails, applications and services become unreachable, even if underlying network connectivity is sound. This guide details systematic approaches to diagnose and resolve common DNS resolution problems, from client-side misconfigurations to complex server-side and delegation path issues.

Client-Side DNS Diagnostics

The first step in troubleshooting is to ascertain if the problem is local to the client or further upstream. This involves checking the client's configured DNS resolvers and its local cache.

Verifying Resolver Configuration

Ensure the client is configured to use the correct DNS servers. Incorrectly configured resolvers are a frequent cause of resolution failures.

  • Windows: Open Network and Sharing Center > Change adapter settings. Right-click the active adapter, select Properties > Internet Protocol Version 4 (TCP/IPv4) > Properties. Verify the 'Obtain DNS server address automatically' or 'Use the following DNS server addresses' settings. Command-line users can use ipconfig /all. Look for 'DNS Servers' under the relevant adapter.
  • Linux: The primary configuration file is typically /etc/resolv.conf. It lists DNS servers with the nameserver keyword, e.g., nameserver 8.8.8.8. On systems using systemd-resolved (e.g., Ubuntu 18.04+, RHEL 8+), /etc/resolv.conf is often a symlink to /run/systemd/resolve/stub-resolv.conf or /usr/lib/systemd/resolv.conf, and settings are managed via /etc/systemd/resolved.conf or network manager. Use resolvectl status to see current resolvers.
  • macOS: System Preferences > Network. Select your active connection, click Advanced > DNS tab.

Flushing DNS Cache

Client-side DNS caches can store stale or incorrect records, leading to resolution failures even if upstream DNS is fixed. Flushing this cache forces the client to perform a new lookup.

# Windows (as Administrator)
ipconfig /flushdns

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

# Linux (older distributions, or specific DNS caches like dnsmasq)
# For dnsmasq, restart the service:
sudo systemctl restart dnsmasq
# If no explicit caching daemon, no command to flush OS-level cache.

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Testing with Specific Resolvers

Use nslookup or dig to test resolution against specific DNS servers, bypassing the client's default configuration. This helps isolate whether the issue is with the default resolver or a broader DNS problem.

# Test example.com using the default resolver
nslookup example.com

# Test example.com using Google's Public DNS (8.8.8.8)
nslookup example.com 8.8.8.8

# dig provides more detailed output and is preferred by many network engineers.
# Test example.com using the default resolver
dig example.com

# Test example.com using Cloudflare's Public DNS (1.1.1.1)
dig @1.1.1.1 example.com

If nslookup example.com 8.8.8.8 works but nslookup example.com fails, the problem lies with your configured primary DNS server.

Server-Side DNS Diagnostics

If client-side checks point to a problem with the configured DNS resolver, the next step is to investigate the DNS server itself.

Checking DNS Server Reachability and Service Status

Ensure the DNS server is reachable and its service is running.

  • Ping: ping [DNS_SERVER_IP] to check basic network connectivity.
  • Port Check: DNS primarily uses UDP port 53 for queries and TCP port 53 for zone transfers. Use nmap or nc (netcat) to verify the port is open and listening. 
    # Check UDP 53
# nmap -sU -p 53 [DNS_SERVER_IP]
# nc -uz [DNS_SERVER_IP] 53

# Check TCP 53
# nmap -p 53 [DNS_SERVER_IP]
# nc -vz [DNS_SERVER_IP] 53
  • Service Status: On Linux, use sudo systemctl status bind9 (for BIND) or sudo systemctl status unbound. On Windows Server, check the 'DNS Server' service in the Services console.

Inspecting DNS Server Logs

DNS server logs provide invaluable information about queries received, responses sent, and any errors encountered. The location and verbosity of logs depend on the DNS software.

  • BIND (Linux): Logs are often found in /var/log/syslog, /var/log/messages, or a dedicated BIND log file (e.g., /var/log/named/named.log). Logging settings are configured in named.conf. Increase logging levels for more detail during troubleshooting.
  • Windows DNS Server: Event Viewer > Applications and Services Logs > DNS Server. Enable debug logging through the DNS Manager console (Right-click server > Properties > Debug Logging tab).

Validating Zone Files and Configuration

Incorrect entries in zone files or misconfigurations in the DNS server software can cause specific records or entire domains to fail resolution.

  • BIND: Use named-checkzone [zone_name] [zone_file_path] and named-checkconf to validate configuration and zone file syntax before reloading/restarting BIND.
  • Windows DNS Server: Use the DNS Manager to inspect zone records. Look for typos, missing records, or incorrect IP addresses. Ensure DNSSEC records are correctly configured if in use.

DNS Delegation Path Analysis

If your DNS server cannot resolve a domain, the problem might be in the delegation chain—the path from the root servers down to the authoritative server for the domain in question.

Tracing DNS Resolution Path with dig +trace

The dig +trace command is crucial for understanding how a DNS query is resolved, showing each step of the delegation from the root servers to the authoritative name server. This helps identify where a delegation breaks down.

dig +trace example.com

Examine the output carefully:

  • The first section shows the root servers.
  • Subsequent sections show the authoritative servers for TLDs (e.g., .com).
  • Finally, it shows the authoritative servers for the specific domain (e.g., example.com).
  • Look for errors like 'connection timed out', 'no response from server', or 'SERVFAIL' at any stage.

If the trace shows a break in the chain (e.g., the .com name servers don't correctly point to your domain's name servers), the issue is likely at the registrar or domain host's configuration for the NS records.

Checking Authoritative Name Servers

Ensure that the authoritative name servers listed for your domain at the registrar level (checked via WHOIS or dig +trace) are correctly configured and respond to queries.

# Query the NS records for your domain
dig NS example.com

# Query one of the authoritative NS servers directly
dig @ns1.example.com example.com

If the NS records are correct at the registrar but the authoritative servers aren't responding, investigate those servers' connectivity and DNS service status as described in the server-side diagnostics.

Common Pitfalls and Troubleshooting Tips

  • Firewall Blocks: Ensure firewalls (client, server, or network-level) allow UDP/TCP port 53 traffic between clients and resolvers, and between resolvers and upstream DNS servers.
  • Incorrect Search Domains/Suffixes: Clients might append incorrect search suffixes, leading to failed lookups for internal resources. Check DHCP settings or /etc/resolv.conf search directive.
  • Expired Domain Registration: An expired domain will result in its name servers being de-listed, causing resolution failures. Check domain registration status via WHOIS.
  • Network Connectivity Issues: Always rule out basic network connectivity issues (cabling, router problems, IP address conflicts) before diving deep into DNS.
  • Private vs. Public Zones: Be aware of split-horizon DNS setups where internal clients receive private IP addresses and external clients receive public IP addresses for the same domain. Misconfiguration can lead to internal clients resolving public IPs or vice-versa.
  • DNSSEC Validation Failures: If DNSSEC is enabled, validation failures can result in SERVFAIL responses. Check DNS server logs for messages like 'RRSIG failed to verify'. Use tools like dig +dnssec example.com or online DNSSEC validators.
  • TTL (Time To Live) Issues: Changes to DNS records take time to propagate due to TTL values. If you've recently updated records, allow sufficient time (e.g., 300 seconds for a 5-minute TTL) for caches to expire. Shorten TTLs before planned changes.
  • Root Hints File Outdated: While rare, an extremely old or corrupt root hints file on a caching-only or authoritative DNS server could prevent it from finding the root servers. This file is usually named.root for BIND and is generally self-updating or infrequently modified.

Back to the knowledge base · Ask the AI assistant