Skip to content

DNS Resolution Failure

Fix DNS resolution failures that prevent proper record retrieval

Informational
DNS Resolution
Network Connectivity

DNS Resolution Issue

DNS resolution failures occur when DNS records cannot be properly retrieved during scanning. This is typically a temporary connectivity issue rather than a security vulnerability.

Understanding DNS Resolution Failures

DNS resolution failures represent some of the most disruptive issues you can encounter with domain management. Unlike simple configuration errors where records might be missing or misconfigured, resolution failures indicate a complete breakdown in the communication chain between DNS clients and your authoritative DNS servers.

The Anatomy of a Resolution Failure

When a DNS resolution failure occurs, it means the fundamental infrastructure that makes your domain name work has stopped functioning. Think of it like having a phone number that no longer connects to any phone—the number might look correct, but the underlying system that routes calls has failed.

Resolution failures happen at different layers of the DNS hierarchy. Your domain exists in a chain of DNS servers, starting from root servers that know about top-level domains (.com, .org), down to your specific authoritative nameservers that hold your actual records. A failure at any level can cascade upward, making your entire domain unreachable.

What makes resolution failures particularly challenging is that they often affect different parts of the world differently. Your domain might work perfectly for users in one geographic region while being completely inaccessible to users in another, depending on which DNS infrastructure components have failed.

Different Types of Resolution Failures

Complete Resolution Failure (NXDOMAIN): Your domain doesn't exist in DNS at all. This usually happens when domain registration has expired, nameserver delegation is broken, or there's a fundamental configuration error at the registrar level. When this occurs, it's as if your domain name was never registered.

Server Failure (SERVFAIL): DNS servers exist and respond, but they're experiencing internal errors that prevent them from providing answers. This often indicates DNS server software problems, corrupted zone files, or security policy violations that block query processing.

Network-Level Timeouts: DNS servers exist but are unreachable due to network connectivity problems. This includes server downtime, network routing issues, firewall blocks, or DDoS attacks that overwhelm the DNS infrastructure.

Delegation Errors: Your domain exists, but the nameserver information pointing to your DNS servers is incorrect or outdated. This creates a broken chain where clients know your domain exists but can't find the servers that actually hold your records.

Query-Specific Failures: Some record types resolve correctly while others fail, often due to DNS server misconfigurations, rate limiting policies, or incomplete zone data that affects only certain query types.

Why Resolution Failures Are So Disruptive

Resolution failures create cascading problems throughout your entire online presence. When DNS resolution fails, it doesn't just affect email or websites—it impacts every service that depends on your domain name. Email delivery stops completely, websites become unreachable, API endpoints fail, and any service discovery mechanisms that rely on DNS cease to function.

The business impact extends beyond immediate technical failures. Resolution failures often persist in DNS caches worldwide for hours or days, meaning that even after you fix the underlying problem, many users continue experiencing issues until their local DNS caches expire and refresh.

This persistent caching effect makes resolution failures particularly damaging compared to other technical issues. A web server outage affects only web traffic and can be fixed immediately, but a DNS resolution failure affects all services and continues impacting users long after repairs are complete.

Recognizing Resolution Failure Symptoms

Resolution failures typically present with these characteristic error patterns:

  • "Failed to retrieve A records" - Basic IP address lookup for your domain completely failed
  • "Failed to retrieve NS records" - Can't determine which servers handle your domain's DNS
  • "DNS query timeout" - DNS servers exist but don't respond within reasonable time limits
  • "No response from DNS server" - Complete communication failure with your DNS infrastructure
  • "Server failure (SERVFAIL)" - DNS servers respond but indicate internal processing errors
  • "Name does not exist (NXDOMAIN)" - Your domain isn't registered in the DNS hierarchy

Systematic DNS Resolution Troubleshooting

Diagnosing DNS resolution failures requires a methodical approach that tests each layer of the DNS infrastructure. The key is starting with the most fundamental checks and working your way up through increasingly specific diagnostics until you isolate the exact failure point.

Step 1: Verify Domain Registration and Delegation

Before diving into server-specific diagnostics, confirm that your domain is properly registered and that the DNS delegation chain is intact. Many resolution failures occur because the fundamental domain registration or nameserver delegation has broken.

Global DNS Hierarchy Check

Trace the complete DNS resolution path from root servers to verify your domain exists in the global DNS hierarchy.

# Check if your domain exists in the global DNS hierarchy
dig yourdomain.com +trace

What this reveals: The +trace option follows the complete DNS resolution path from root servers through TLD servers to your authoritative servers. If the trace fails early, your domain registration or delegation is broken.

Nameserver Delegation Verification

Check that nameserver delegation is properly configured and matches your expectations.

# Verify nameserver delegation from the parent zone
dig yourdomain.com NS +short

# Check nameserver records from the root perspective
dig @a.root-servers.net yourdomain.com NS

Delegation analysis: These commands verify that your domain's NS records exist and that they're consistent between your DNS provider and the authoritative root servers. Mismatches indicate delegation problems.

Domain Registration Status

Verify that your domain registration is current and hasn't expired, which would cause complete DNS resolution failure.

# Verify domain registration status (look for registrar info)
whois yourdomain.com | grep -i "expiry|expiration|expires"

Registration importance: An expired domain registration immediately breaks all DNS resolution. The whois command shows registration dates and registrar information to confirm your domain is active.

Step 2: Test Each Authoritative Nameserver

Once you've confirmed proper delegation, test each of your authoritative nameservers individually. This helps identify whether the problem affects all servers (indicating a broader infrastructure issue) or just specific servers (pointing to individual server problems).

Nameserver Discovery

First, identify all nameservers responsible for your domain to test each one individually.

# Get list of all your nameservers
NAMESERVERS=$(dig +short yourdomain.com NS)
echo "Your nameservers: $NAMESERVERS"

Purpose: This discovers all authoritative nameservers for your domain. Testing each server individually helps identify whether problems affect all servers or just specific ones.

Individual Server Testing

Test basic connectivity and response capability for each nameserver with timeout controls.

# Test each nameserver individually with detailed output
for ns in $NAMESERVERS; do
    echo "======== Testing $ns ========"
    
    # Basic connectivity test
    dig @$ns yourdomain.com SOA +timeout=10 +retry=2
done

SOA testing: The SOA (Start of Authority) record test verifies basic server functionality. Timeouts and retries help distinguish between slow responses and complete failures.

Record Type Response Testing

Test different record types to identify if servers have complete zone data or only partial information.

    # Check if server responds to different record types
    dig @$ns yourdomain.com A +short
    dig @$ns yourdomain.com NS +short
    dig @$ns yourdomain.com MX +short

Multi-record validation: Testing A, NS, and MX records ensures the server has complete zone data. Partial responses indicate incomplete zone transfers or configuration issues.

Performance Analysis

Measure query processing time to identify performance issues that might cause timeouts.

    # Test query processing time
    time dig @$ns yourdomain.com A > /dev/null
    
    echo ""
done

Interpreting results: If all nameservers fail identically, you likely have a zone configuration problem. If some work while others fail, you have individual server issues. If all respond but return different answers, you have synchronization problems between servers.

Step 3: Analyze Network Connectivity Patterns

Network connectivity issues can cause DNS resolution failures even when your servers are configured correctly. This step helps identify whether problems stem from network infrastructure, routing issues, or accessibility barriers.

Basic Connectivity Testing

Test fundamental network connectivity to each nameserver using multiple protocols.

# Test basic network connectivity to each nameserver
for ns in $(dig +short yourdomain.com NS); do
    echo "Testing connectivity to $ns:"
    
    # Test ICMP reachability (may be blocked by firewalls)
    ping -c 3 $ns
done

ICMP testing: Ping tests basic network reachability, though some firewalls block ICMP while allowing DNS traffic through.

DNS Port Connectivity

Test both UDP and TCP connectivity on port 53 to identify protocol-specific issues.

    # Test DNS port specifically (UDP 53)
    nc -u -z -v $ns 53
    
    # Test DNS over TCP (port 53) - used for large responses
    nc -z -v $ns 53

Protocol analysis: UDP is used for most DNS queries, but TCP is required for large responses. If UDP fails but TCP works, firewall rules may be blocking UDP DNS traffic.

Network Path Analysis

Trace the network path to identify routing issues or network infrastructure problems.

    # Show network path to the server
    traceroute $ns | head -10
    
    echo "---"
done

Path diagnosis: Traceroute reveals network routing problems, including loops, timeouts, or unreachable segments that prevent DNS queries from reaching your nameservers.

External Resolver Testing

Test DNS resolution through different public resolvers to identify regional or provider-specific issues.

# Test from different network perspectives
echo "Testing via different public DNS resolvers:"
for resolver in 8.8.8.8 1.1.1.1 208.67.222.222; do
    echo "Via $resolver:"
    dig @$resolver yourdomain.com A +short +timeout=5
done

Network diagnosis insights: If some public resolvers work while others fail, you have regional connectivity issues. Consistent failures across all resolvers indicate problems with your DNS infrastructure.

Step 4: Examine DNS Server Response Details

DNS servers can respond but still indicate problems through response codes, flags, and content. This step analyzes the technical details of DNS responses to identify server-side configuration issues.

Comprehensive Response Analysis

Get detailed information about DNS responses including all sections and server statistics.

# Get detailed DNS response information
dig @ns1.yourdomain.com yourdomain.com ANY +noall +answer +authority +additional +stats

Complete response data: The ANY query with all sections reveals comprehensive response details including authority information, additional records, and query statistics.

Response Code and Flag Analysis

Examine DNS response codes, flags, and comments to identify server-side processing issues.

# Check response codes and flags
dig @ns1.yourdomain.com yourdomain.com A +noall +answer +stats +comments

Status indicators: Response codes like SERVFAIL indicate server configuration errors, while NXDOMAIN means the domain doesn't exist in the zone data.

DNSSEC Validation Testing

Test DNSSEC validation if your domain uses cryptographic signing for enhanced security.

# Test DNSSEC validation if enabled
dig @ns1.yourdomain.com yourdomain.com A +dnssec +noall +answer +authority

DNSSEC analysis: DNSSEC validation failures can cause resolution problems. This test reveals cryptographic validation issues that might block legitimate queries.

Zone Authority and Transfer Testing

Verify SOA records and test zone transfer capabilities to understand server configuration.

# Check for proper SOA record configuration
dig @ns1.yourdomain.com yourdomain.com SOA +noall +answer +authority

# Test zone transfer capability (should usually be restricted)
dig @ns1.yourdomain.com yourdomain.com AXFR

Authority verification: SOA records define zone authority and parameters. Zone transfer tests (AXFR) should typically be restricted, but the response reveals server security configuration.

Step 5: Investigate DNS Server Logs and Configuration

If you have access to your DNS server infrastructure, examining server logs and configuration files reveals internal problems that aren't visible from external DNS queries. This step requires administrative access to your DNS servers.

DNS Server Log Analysis

Examine DNS server logs to identify internal errors and domain-specific issues.

# Check DNS server logs for errors (BIND example)
tail -50 /var/log/named/named.log | grep -i error
tail -50 /var/log/named/named.log | grep yourdomain.com

Log analysis: Server logs reveal configuration errors, zone loading failures, and domain-specific processing issues that aren't visible from external queries.

Configuration Validation

Validate zone file syntax and overall server configuration to identify structural problems.

# Validate zone file syntax
named-checkzone yourdomain.com /etc/bind/zones/db.yourdomain.com

# Check overall DNS server configuration
named-checkconf /etc/bind/named.conf

Syntax validation: Zone file syntax errors cause SERVFAIL responses. Configuration validation catches structural problems that prevent proper server operation.

Security and Performance Analysis

Check for security blocks, rate limiting, and resource exhaustion that might affect DNS resolution.

# Look for security-related blocks or rate limiting
grep -i "denied|blocked|rate.limit" /var/log/named/security.log

# Check server resource usage and performance
systemctl status named
journalctl -u named -n 50

System health: Security policies may block legitimate queries, resource exhaustion causes timeouts, and service status reveals server operational state.

Alternative DNS Server Commands

Commands for other popular DNS server implementations beyond BIND.

# For other DNS servers (examples):
# PowerDNS: pdns_control show * | grep yourdomain
# Unbound: unbound-control status

Multi-platform support: Different DNS server software requires different diagnostic commands, but the principles of log analysis and configuration validation remain consistent.

Step 6: Test Resolution from Multiple Geographic Locations

DNS resolution problems often affect only certain geographic regions or network providers. Testing from multiple locations helps identify whether the issue is global or localized to specific infrastructure.

Regional Resolver Testing

Test DNS resolution from different geographic regions to identify location-specific issues.

# Test from different geographic DNS resolvers
echo "Testing from various global locations:"

# United States
dig @4.2.2.1 yourdomain.com A +short   # Level3/Lumen (US)
dig @8.8.8.8 yourdomain.com A +short   # Google (Global, US-based)

# Europe  
dig @213.73.91.35 yourdomain.com A +short   # UltraDNS (Europe)

# Asia Pacific
dig @202.12.27.33 yourdomain.com A +short   # University of Tokyo

Global testing: Different geographic regions may show different resolution results due to regional network issues, DNS cache pollution, or infrastructure problems.

Local and ISP Testing

Test with your local DNS resolver to identify ISP-specific or local network problems.

# Check with your ISP's DNS
dig yourdomain.com A +short

ISP analysis: Your ISP's DNS resolver may have different results due to local caching, filtering policies, or network connectivity specific to your provider.

Online Geographic Testing Tools

Use web-based tools for comprehensive global DNS testing from multiple worldwide locations.

# Use online tools for broader geographic testing
echo "Additional testing via online tools:"
echo "- https://www.whatsmydns.net/#A/yourdomain.com"
echo "- https://dnschecker.org/"  
echo "- https://www.dnswatch.info/"

Web tool benefits: These tools test from dozens of global locations simultaneously, revealing regional patterns that command-line testing might miss.

IPv6 Resolution Testing

Test IPv6 resolution to identify protocol-specific issues that might affect modern networks.

# Test IPv6 resolution if applicable
dig yourdomain.com AAAA +short

Geographic analysis: If some regions resolve successfully while others fail, you have regional network connectivity issues. If IPv4 works but IPv6 fails (or vice versa), you have protocol-specific configuration problems.

Step 7: Implement Resolution and Verify Recovery

After identifying the root cause, implement fixes and verify that resolution works consistently across different test scenarios. This step ensures that repairs are complete and monitors for any remaining issues.

Nameserver Verification

Verify that all nameservers respond correctly after implementing fixes.

# Test all nameservers respond correctly
for ns in $(dig +short yourdomain.com NS); do
    echo "Verifying $ns:"
    dig @$ns yourdomain.com SOA +short
    dig @$ns yourdomain.com A +short
done

Consistency check: All nameservers should return identical responses. Inconsistent answers indicate remaining synchronization issues.

DNS Cache Clearing

Clear local DNS caches to ensure testing reflects actual server responses rather than cached data.

# Clear local DNS caches to ensure fresh results
sudo systemctl flush-dns                    # Linux
sudo dscacheutil -flushcache               # macOS  
ipconfig /flushdns                          # Windows

Cache impact: DNS caches can hide ongoing problems by returning old data. Clearing caches ensures tests reflect current server state.

External Resolver Validation

Test resolution through multiple external resolvers to confirm global accessibility.

# Test from multiple external resolvers
for resolver in 8.8.8.8 1.1.1.1 208.67.222.222 9.9.9.9; do
    echo "Testing via $resolver:"
    dig @$resolver yourdomain.com A +short +timeout=10
done

Global validation: Testing through Google, Cloudflare, OpenDNS, and Quad9 resolvers ensures your domain works correctly from major global DNS providers.

Stability Monitoring

Monitor resolution consistency over time to ensure fixes remain stable.

# Monitor resolution consistency over time
for i in {1..10}; do
    dig yourdomain.com A +short
    sleep 30
done

Stability testing: Multiple tests over time reveal intermittent issues that single queries might miss. Consistent results indicate stable resolution.

Documentation and Logging

Document the resolution for future reference and troubleshooting.

# Document what was fixed for future reference
echo "Resolution fixed on $(date)" >> /var/log/dns-resolution-fixes.log
echo "Issue: [describe the problem]" >> /var/log/dns-resolution-fixes.log
echo "Solution: [describe what was changed]" >> /var/log/dns-resolution-fixes.log

Success validation: Document both the problem and solution for future troubleshooting reference. This helps with similar issues and provides an audit trail of DNS infrastructure changes.

Last updated: August 2, 2025