When DNS fails to resolve an IP address, your website becomes unreachable despite your server being online. To fix this issue, start by flushing your DNS cache using commands like ipconfig /flushdns (Windows) or sudo dscacheutil -flushcache (macOS), verify your DNS server settings, check nameserver propagation, and ensure your DNS records are correctly configured in your hosting control panel or domain registrar.
DNS (Domain Name System) acts as the internet’s phonebook, translating human-readable domain names into machine-readable IP addresses. When you type a website address into your browser, DNS servers perform this translation in milliseconds. According to Cloudflare’s 2025 Internet Performance Report, DNS queries account for over 2.5 trillion daily requests globally, making DNS infrastructure critical for internet functionality.
DNS resolution failures occur when this translation process breaks down. Your browser cannot locate the correct IP address for the domain, resulting in error messages like “DNS_PROBE_FINISHED_NXDOMAIN” or “Server IP address could not be found.” These failures stem from various causes including misconfigured DNS records, expired cache, propagation delays, or server-side issues.
Your operating system and browser store DNS lookup results in a local cache to speed up subsequent visits to the same websites. When this cache becomes corrupted or contains outdated information, DNS resolution fails even when the actual DNS records are correct. This corruption commonly occurs after network changes, malware infections, or system updates.
The DNS cache stores Time-to-Live (TTL) values for each record, typically ranging from 300 seconds to 86,400 seconds (24 hours). If a website changes its IP address or DNS provider before the TTL expires, your system continues using the old, invalid information. Research from Google Cloud indicates that approximately 23% of DNS resolution errors stem from stale cache entries.
To flush your DNS cache on different operating systems:
Your device relies on DNS servers to perform domain name lookups. These servers are typically provided by your Internet Service Provider (ISP) or manually configured to use public DNS services. When DNS server settings are incorrect, misconfigured, or point to unresponsive servers, resolution fails completely.
Many WordPress hosting environments require specific DNS server configurations. If you’re managing a WordPress hosting setup, incorrect DNS settings can prevent your site from resolving even when your server is functioning perfectly. ISP-provided DNS servers can also experience outages or throttling during peak traffic periods.
To verify and update your DNS server settings on Windows, open Network Connections, right-click your active connection, select Properties, choose Internet Protocol Version 4 (TCP/IPv4), and ensure DNS servers are correctly configured. Popular public DNS options include Google DNS (8.8.8.8, 8.8.4.4), Cloudflare DNS (1.1.1.1, 1.0.0.1), and Quad9 (9.9.9.9).
DNS propagation refers to the time required for DNS record changes to spread across all DNS servers worldwide. When you modify nameservers, update A records, or change DNS providers, these changes don’t take effect instantly. Propagation typically completes within 24-48 hours, though some changes may propagate within minutes while others take longer.
During propagation, different users receive different DNS responses based on their geographic location and which DNS servers their ISP queries. According to DNS Made Easy’s 2025 infrastructure study, average global propagation time has decreased to 4.2 hours, but edge cases still experience delays exceeding 72 hours due to high TTL values or caching intermediaries.
You can monitor propagation status using tools like WhatsMyDNS.net or DNS Checker. These services query DNS servers from multiple geographic locations, showing whether your changes have propagated globally. If you’re experiencing resolution failures immediately after DNS changes, propagation delay is likely the cause rather than a configuration error.
DNS zones contain various record types that serve different purposes. The most critical for basic resolution is the A record, which maps a domain name directly to an IPv4 address. Misconfigurations in A records, missing records, or conflicts between record types cause resolution failures.
Common DNS record mistakes include:
Access your DNS management interface through your domain registrar or hosting control panel. Verify that A records exist for both your root domain (@) and www subdomain, both pointing to your server’s current IP address. For VPS or cloud server configurations, ensure the IP address matches your server’s public IP, not a private network address.
Firewalls and security software can block DNS queries on port 53 (UDP and TCP), preventing resolution even when DNS servers are correctly configured. Windows Firewall, third-party security suites, and router firewalls may inadvertently block DNS traffic after updates or configuration changes.
DNS uses UDP port 53 for standard queries and TCP port 53 for zone transfers and large responses. According to the SANS Internet Storm Center, approximately 8% of DNS resolution failures result from firewall rules blocking these ports. Enterprise networks and public Wi-Fi often implement restrictive firewall policies that interfere with DNS functionality.
To test if firewall rules are blocking DNS, temporarily disable your firewall and attempt to resolve the domain. If resolution succeeds with the firewall disabled, create specific allow rules for DNS traffic on port 53. On Windows Firewall, navigate to Advanced Settings, create a new Inbound Rule for UDP port 53, and ensure it applies to all profiles (Domain, Private, Public).
Domain nameservers are authoritative DNS servers designated by your domain registrar to handle DNS queries for your domain. When nameserver records at your registrar don’t match the actual DNS servers managing your domain, a delegation chain breaks, causing complete resolution failure.
This commonly occurs when migrating between hosting providers. You might update DNS records at your new host’s DNS control panel, but if you haven’t updated the nameserver delegation at your domain registrar, queries still route to the old DNS servers. The old servers either respond with outdated information or fail to respond entirely.
Login to your domain registrar’s control panel and verify the nameserver records match your hosting provider’s nameservers. Most WordPress hosting providers specify nameservers like ns1.hostingprovider.com and ns2.hostingprovider.com. After updating nameservers at the registrar level, allow 24-48 hours for propagation. You can verify correct delegation using the command nslookup -type=NS yourdomain.com or dig NS yourdomain.com.
Command-line diagnostic tools provide detailed information about DNS resolution paths, helping pinpoint exact failure points. These tools query DNS servers directly, bypassing local cache and revealing whether issues exist at the client, network, or server level.
The nslookup command works on Windows, macOS, and Linux. Run nslookup yourdomain.com to perform a basic DNS lookup. The output shows which DNS server responded and the IP address returned. If you receive “server can’t find yourdomain.com: NXDOMAIN,” the domain doesn’t exist in DNS or nameservers are incorrectly configured.
The dig command (available on macOS and Linux, installable on Windows) provides more detailed output. Execute dig yourdomain.com to see the complete query path, TTL values, and authoritative nameservers. Pay attention to the ANSWER section—if it’s empty or shows a SERVFAIL status, your DNS records are misconfigured or your nameservers are unresponsive.
For testing specific DNS servers, use nslookup yourdomain.com 8.8.8.8 or dig @8.8.8.8 yourdomain.com. This bypasses your configured DNS servers and queries Google’s public DNS directly, helping determine whether the issue is with your DNS server configuration or the actual DNS records.
Time-to-Live (TTL) values specify how long DNS resolvers should cache a DNS record before querying authoritative nameservers again. When planning DNS changes, TTL values directly impact how quickly changes propagate and how long resolution failures persist.
High TTL values (86400 seconds or 24 hours) reduce DNS query load but extend propagation time when changes occur. Low TTL values (300 seconds or 5 minutes) enable rapid changes but increase query volume. Best practice before migrating hosting or updating DNS records involves reducing TTL to 300-600 seconds at least 24-48 hours in advance, according to CloudFlare’s DNS management guidelines.
After completing DNS changes and verifying resolution works correctly worldwide, gradually increase TTL back to 3600-7200 seconds (1-2 hours) for optimal performance. This balance provides reasonable caching benefits while maintaining flexibility for future updates.
DNS changes typically propagate within 24-48 hours globally, though many changes appear within 4-6 hours. The exact time depends on TTL values of existing records, caching behavior of intermediate DNS servers, and geographic distribution of DNS infrastructure. You can accelerate propagation by lowering TTL values before making changes, but you cannot force immediate worldwide propagation due to the distributed nature of DNS.
Yes, configuring primary and secondary DNS servers provides redundancy if one server becomes unresponsive. Your operating system automatically queries the secondary DNS server if the primary fails to respond within timeout thresholds (typically 2-3 seconds). Configure at least two DNS servers from different providers—for example, combine Google DNS (8.8.8.8) as primary with Cloudflare DNS (1.1.1.1) as secondary for optimal reliability.
Different networks use different DNS servers, which may have cached different versions of your DNS records, especially during propagation periods. Some ISPs also implement DNS filtering or hijacking, redirecting certain domains or modifying DNS responses. Additionally, geographic DNS routing and CDN configurations can return different IP addresses based on client location, making resolution appear inconsistent across networks.
NXDOMAIN (Non-Existent Domain) indicates the domain name doesn’t exist in DNS—either it was never registered, registration expired, or DNS records are completely missing. SERVFAIL (Server Failure) means the DNS server encountered an error processing the query, typically due to misconfigured zone files, DNSSEC validation failures, or nameserver connectivity issues. NXDOMAIN suggests domain-level problems, while SERVFAIL indicates server-side DNS configuration errors.
Use online DNS lookup tools like MXToolbox, DNSChecker, or WhatsmyDNS to query your domain from multiple geographic locations. Verify that A records point to correct IP addresses, MX records specify proper mail servers, and nameserver (NS) records match your hosting provider’s specifications. Command-line tools like dig or nslookup provide authoritative results directly from nameservers, showing exactly what DNS servers return for your domain without caching interference.