How to Troubleshoot DNS Issues: Complete Guide

Your website stops loading. Email bounces back. Users can't access your application. The culprit? A DNS failure that's invisible to most monitoring tools but devastating to your operations. When DNS breaks, every service that depends on it (from web traffic to API calls) grinds to a halt.

The challenge isn't just that DNS issues are critical. It's that they're notoriously difficult to diagnose. A problem could stem from corrupted cache data, misconfigured zone transfers with mismatched serial numbers, broken delegations missing proper A records, or DNSSEC validation failures blocking legitimate queries. Network teams often waste hours chasing symptoms while the root cause remains hidden in the resolution chain.

You'll learn the systematic diagnostic steps that pinpoint DNS problems fast. You'll discover how to use command-line tools like nslookup and dig +trace to reveal the complete resolution path, when to test alternative resolvers like 8.8.8.8 or 1.1.1.1 to isolate client-side issues, and how to verify everything from IP configuration to root hints. Whether you're troubleshooting Windows Server, BIND, or client connectivity problems, you'll have a clear methodology to resolve DNS issues before they impact your users.

What are DNS issues?

DNS issues prevent domain names from resolving correctly to their corresponding IP addresses, disrupting website access and network services. These problems range from simple configuration errors to complex server-side failures.

The DNS issues are listed below.

• Cache corruption: Your DNS cache stores previous lookup results to speed up future requests, but this cached data can become outdated or corrupted. When corruption occurs, you'll get incorrect IP addresses or stale records even after DNS changes have been made. Flushing the cache forces your system to perform fresh lookups instead of relying on potentially bad data.
• Zone transfer failures: Secondary DNS servers need to sync data from primary servers through zone transfers, which rely on matching serial numbers. If serial numbers aren't properly synchronized between primary and secondary servers, the transfer fails and secondary servers serve outdated records. This creates inconsistent DNS responses depending on which server handles the query.
• Broken delegation: NS (nameserver) records point to authoritative servers for a domain, but those servers also need corresponding A records with valid IP addresses. When NS records exist without matching A records, the delegation breaks and queries can't reach the authoritative server. This completely blocks resolution for the affected domain.
• DNSSEC validation failures: DNSSEC adds cryptographic signatures to DNS records for security, but signature mismatches or expired keys cause validation to fail. When validation fails, resolvers block the response entirely to prevent potential security threats. You can test if DNSSEC is the culprit by temporarily disabling validation and seeing if resolution works.
• Root hints misconfiguration: DNS servers performing recursive queries need correct root hints to find authoritative servers for domains outside their zones. If root hints are missing or incorrect, your DNS server can't complete the resolution chain. The server must be able to ping root servers by IP address for recursive queries to work.
• Hosts file overrides: The hosts file on your local machine maps hostnames directly to IP addresses, bypassing normal DNS resolution entirely. Entries in this file take precedence over DNS lookups, so incorrect mappings send traffic to the wrong destination. This often causes confusion because DNS appears broken when it's actually being overridden locally.
• Server overload or paused zones: DNS servers can become overloaded from excessive queries or have specific zones paused for maintenance. When this happens, you'll see "Server failure" or "Query refused" responses from nslookup commands. These responses indicate the server received your query but couldn't or wouldn't process it.
• Network connectivity problems: DNS queries travel over the network just like any other traffic, so firewall blocks, routing issues, or network outages prevent queries from reaching resolvers. Timeout responses typically mean the DNS service isn't running or your client can't reach it across the network. Testing with alternative DNS providers like 8.8.8.8 or 1.1.1.1 helps isolate whether the problem is your primary DNS or broader network connectivity.
• High TTL values: Time To Live settings control how long resolvers cache DNS records before checking for updates. When TTL values are set too high, DNS changes take hours or days to propagate through all resolvers. This delays updates and causes different users to see different IP addresses during the transition period.
• Missing glue records: Glue records provide IP addresses for nameservers that are within the domain they're authoritative for, breaking circular dependencies. Without proper glue records in your zone file, resolvers can't find your nameservers to query them. This creates a chicken-and-egg problem that blocks all resolution for the domain.

What are the main causes of DNS issues?

DNS issues stem from configuration errors, network problems, and system-level conflicts that prevent domain names from resolving to their correct IP addresses. The main causes are listed below.

• Misconfigured DNS records: Incorrect A, CNAME, MX, or NS records in zone files prevent proper domain resolution. A missing A record means the domain can't point to its server IP address, while incorrect NS records break the delegation chain between parent and child zones.
• DNS cache corruption: Stale or incorrect data stored in local DNS caches causes systems to return outdated IP addresses instead of current ones. Corrupted cache entries persist until you manually flush the cache, forcing fresh lookups from authoritative servers.
• Zone transfer failures: Secondary DNS servers can't replicate data from primary servers when serial numbers aren't properly synchronized. This creates inconsistent responses across your DNS infrastructure, with different servers returning different answers for the same query.
• Broken delegation: NS records that lack corresponding A records with valid IP addresses disrupt the resolution chain. When a parent zone delegates authority to nameservers without providing their IP addresses through glue records, queries fail to reach the authoritative servers.
• Network connectivity problems: Firewall rules, routing issues, or network outages prevent DNS queries from reaching resolvers. If your DNS server can't communicate with root servers or upstream resolvers, it can't perform recursive queries for domains outside its authoritative zones.
• DNSSEC validation errors: Failed cryptographic signature verification blocks resolution even when the underlying DNS data is correct. DNSSEC misconfigurations like expired signatures, broken trust chains, or missing DNSKEY records cause validators to reject otherwise valid responses.
• Hosts file overrides: Local hosts file entries bypass normal DNS resolution by mapping hostnames directly to IP addresses. These static mappings take precedence over DNS queries, causing unexpected routing when entries become outdated or incorrect.
• Server overload or service failures: DNS servers that are paused, crashed, or overwhelmed with traffic return "Server failure" or timeout responses. Resource exhaustion from excessive queries or insufficient server capacity prevents the DNS service from processing legitimate requests.
• High TTL settings: Time To Live values that are too long delay propagation of DNS record updates across the internet. Resolvers continue serving cached data for the full TTL duration, meaning changes to your DNS records won't reach users until the cache expires.

How to diagnose DNS problems?

You diagnose DNS problems by methodically testing each component of the resolution process, starting with basic connectivity checks and progressing to detailed query analysis using command-line tools.

1. Verify your network configuration first. Run ipconfig /all on Windows or ifconfig on Linux to confirm your IP address, subnet mask, and default gateway are correct. If these basics are wrong, DNS queries won't even reach your resolver.
2. Test DNS resolution with nslookup to isolate the problem. Query a known domain like google.com using your default DNS server first, then test against a public resolver like 8.8.8.8 with the command nslookup google.com 8.8.8.8. If the public resolver works but your default doesn't, the issue is with your primary DNS configuration.
3. Check for cache corruption by flushing your DNS cache. Stale or incorrect cached data causes systems to return outdated answers. Use ipconfig /flushdns on Windows, systemd-resolve --flush-caches on Linux, or dscacheutil -flushcache on macOS to force fresh lookups.
4. Query authoritative servers directly to verify zone data accuracy. Use nslookup -type=SOA yourdomain.com to check serial numbers across name servers. Different serial numbers mean synchronization problems between primary and secondary servers that your DNS operator needs to fix.
5. Trace the complete resolution path with dig. The command dig +trace yourdomain.com reveals every server involved in the lookup process, showing exactly where resolution breaks down. This helps identify whether the problem is with root servers, TLD servers, or your authoritative name servers.
6. Verify DNSSEC validation if queries fail unexpectedly. Temporarily disable DNSSEC validation to determine if signature validation errors are blocking resolution. Tools like dnsviz.net show specific DNSSEC chain issues that might be causing failures.
7. Inspect your hosts file for local overrides. The hosts file maps hostnames to IP addresses before DNS queries happen, so incorrect entries here bypass normal resolution entirely. Check /etc/hosts on Linux/macOS or C:\\Windows\\System32\\drivers\\etc\\hosts on Windows.
8. Look for specific error responses that indicate server-side problems. "Server failure" means the DNS zone is paused or the server is overloaded, while "Query refused" suggests access control issues. Timeout errors typically mean the DNS service isn't running or network blocking prevents queries from reaching the resolver.

Here's the key thing: work from simple to complex. Most DNS issues come from misconfigured IP settings, corrupted caches, or zone transfer problems that basic tools reveal quickly.

How to troubleshoot DNS issues on Windows?

You troubleshoot DNS issues on Windows by using built-in diagnostic commands to verify configuration, test resolution, and isolate the source of the problem.

1. Check your IP configuration first. Open Command Prompt and run ipconfig /all to verify your IP address, subnet mask, default gateway, and assigned DNS servers are correct. If the DNS server addresses look wrong or point to unreachable servers, that's likely your problem.
2. Test DNS resolution with nslookup. Run nslookup example.com to see if your DNS server resolves domain names. If you get a "Server failure" response, your DNS server might be paused or overloaded. Check the DNS console. A timeout means the DNS service isn't running or can't be reached from your computer.
3. Flush your DNS cache to clear corrupted entries. Run ipconfig /flushdns in Command Prompt to force Windows to perform fresh DNS lookups instead of using potentially stale cached data. This fixes issues where you're getting outdated IP addresses for domains.
4. Query a specific DNS server to isolate the issue. Use nslookup example.com 8.8.8.8 to test against Google Public DNS or another alternative resolver. If this works but your default DNS fails, the problem is with your primary DNS configuration, not your network connection.
5. Verify your hosts file isn't overriding DNS. Open C:\\Windows\\System32\\drivers\\etc\\hosts in Notepad and check for entries mapping hostnames to IP addresses. The hosts file takes precedence over DNS resolution and can cause incorrect routing if misconfigured.
6. Check for zone transfer problems if you're running a DNS server. Query the SOA record with nslookup -type=soa yourdomain.com on both primary and secondary servers. Different serial numbers mean synchronization failed, and you'll need to fix data replication between your authoritative servers.

If basic commands don't reveal the issue, verify that your DNS server can reach root servers by pinging them directly. Root hints must be properly configured for recursive queries to work outside your authoritative zones.

How to resolve DNS problems on Linux and Mac?

You resolve DNS problems on Linux and Mac by methodically checking your network configuration, testing DNS resolution with command-line tools, and clearing corrupted cache data.

1. Check your current DNS configuration. On Linux, run cat /etc/resolv.conf to see which DNS servers your system uses. On macOS, open System Preferences > Network, select your connection, click Advanced, then check the DNS tab. This shows whether you're using your ISP's DNS servers, custom resolvers, or if the configuration is missing entirely.
2. Test DNS resolution with the dig command. Run dig example.com to query your default DNS server, or dig @8.8.8.8 example.com to test against a specific resolver like Google's public DNS. The response shows whether the query succeeded, timed out, or returned incorrect data. If queries work with 8.8.8.8 but fail with your default server, your primary DNS configuration is the problem.
3. Flush your DNS cache to eliminate stale records. On Linux systems using systemd, run sudo systemd-resolve --flush-caches. On macOS Catalina and later, execute sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder. This forces your system to perform fresh lookups instead of relying on potentially corrupted cached data.
4. Verify network connectivity to DNS servers. Ping your configured DNS server by IP address (for example, ping 8.8.8.8). If the ping fails, you've got a network connectivity issue blocking DNS queries, not a DNS configuration problem. Check your firewall settings and network routes.
5. Use dig +trace to see the complete resolution path. This command shows every server involved in resolving a domain name, revealing where the lookup fails. If the trace stops at a specific nameserver, that server either isn't responding or has incorrect zone data.
6. Check your hosts file for overrides. Run cat /etc/hosts to see if any manual hostname-to-IP mappings are interfering with normal DNS resolution. The hosts file takes precedence over DNS, so incorrect entries here will override correct DNS records and route traffic to wrong addresses.
7. Test with an alternative DNS provider to isolate the issue. Temporarily switch to 1.1.1.1 or 8.8.8.8 in your network settings. If DNS suddenly works, the problem lies with your original DNS provider. Either their servers are down, overloaded, or blocking certain queries.

If you're still seeing failures after these steps, the issue likely involves DNSSEC validation errors or problems with the authoritative nameservers themselves, which require querying the domain's SOA records directly.

What are the advanced DNS troubleshooting techniques?

Advanced DNS troubleshooting techniques are diagnostic methods that go beyond basic connectivity checks to identify complex resolution failures, DNSSEC validation errors, and zone configuration problems. The advanced DNS troubleshooting techniques are listed below.

• DNS trace analysis: The dig +trace command reveals the complete resolution path by showing each server involved in the query process. This helps identify exactly where resolution breaks down, whether at root servers, TLD nameservers, or authoritative servers. You'll see each step of the delegation chain and can pinpoint misconfigured NS records or broken delegations.
• Direct authoritative queries: Querying authoritative nameservers directly bypasses recursive resolvers and shows whether problems originate from primary or secondary servers. Use nslookup or dig with the @server syntax to target specific nameservers. This isolates whether issues stem from your DNS infrastructure or intermediate resolvers.
• SOA record verification: Checking SOA records reveals zone serial numbers across all authoritative nameservers. Mismatched serial numbers indicate zone transfer failures between primary and secondary servers. When serial numbers don't match, data synchronization has broken down and requires investigation of transfer logs and permissions.
• DNSSEC validation testing: Temporarily disabling DNSSEC validation determines whether resolution failures stem from signature problems or actual nameserver issues. Tools like dnsviz.net and VeriSign Labs DNSSEC debugger show specific validation errors. If queries succeed with validation disabled, you're dealing with broken DNSSEC chains or expired signatures.
• Root hints verification: DNS servers performing recursive queries must reach root servers to resolve external domains. Test by pinging root server IP addresses directly. If these fail, your server can't perform recursion. Root hints files need updating when root server addresses change, though this happens rarely.
• Zone transfer debugging: Failed zone transfers between primary and secondary servers prevent proper replication. Check that secondary servers are listed in allowed transfer lists and that network connectivity permits TCP port 53 traffic. Serial number increments on the primary must trigger transfers to secondaries.
• Glue record validation: Missing glue records in zone files cause resolution failures when nameservers are within the domain they're authoritative for. The parent zone must include A records for nameservers alongside NS records. Without these, resolvers can't find the IP addresses needed to query your nameservers.
• Alternative resolver testing: Switching to public resolvers like 8.8.8.8 or 1.1.1.1 isolates whether problems are specific to your primary DNS configuration. If queries succeed through alternative resolvers but fail through your configured servers, the issue lies in your DNS infrastructure or ISP. This quickly separates client-side from server-side problems.

How to prevent DNS issues from occurring?

You prevent DNS issues by using proactive monitoring, maintaining proper configurations, and following DNS management best practices that catch problems before they affect users.

1. Monitor your DNS infrastructure continuously. Set up automated monitoring that checks DNS resolution times, queries authoritative servers directly, and alerts you when response times exceed 100 ms or queries fail. This catches issues like server overload, network connectivity problems, or zone transfer failures before users notice degraded performance.
2. Deploy redundant DNS servers across different networks. Configure at least two authoritative nameservers on separate networks with different IP ranges. If one server fails or becomes unreachable, the secondary server continues handling queries without interruption.
3. Keep DNS software and security patches current. Update BIND, Microsoft DNS Server, or your DNS platform regularly to fix known vulnerabilities and bugs that cause resolution failures. Outdated DNS software can introduce security risks and compatibility issues with newer DNS features like DNSSEC.
4. Set appropriate TTL values for different record types. Use shorter TTL values (300 to 600 seconds) for records you change frequently, and longer values (3,600 to 86,400 seconds) for stable records. This balances the need for quick updates against reducing query load on your DNS servers.
5. Validate DNSSEC configurations before deployment. Test DNSSEC signatures using tools like dnsviz.net or the VeriSign Labs DNSSEC debugger to ensure your zone signing keys work correctly. DNSSEC validation failures block resolution entirely, so catching configuration errors in testing prevents widespread outages.
6. Document and version control your DNS zone files. Maintain a record of all DNS changes with timestamps and descriptions. When issues arise, you can quickly identify recent modifications that might have introduced problems and roll back to known-good configurations.
7. Verify glue records exist for all nameservers. Check that your zone files include A records for every nameserver listed in NS records. Missing glue records prevent resolvers from finding your nameservers' IP addresses, breaking the entire resolution chain.
8. Test DNS changes in staging environments first. Before updating production DNS records, apply changes to a test zone and verify resolution works correctly using nslookup or dig commands. This catches syntax errors, missing records, or incorrect IP addresses before they affect live traffic.

Regular DNS audits every quarter help you spot configuration drift, unused records, and potential security gaps before they cause problems.

How can Gcore help with DNS management and troubleshooting?

Gcore helps with DNS management and troubleshooting through Managed DNS that runs across 210+ global PoPs with built-in monitoring and automated failover. When DNS issues occur, the Gcore platform gives you real-time visibility into query performance, resolution paths, and configuration errors through a centralized dashboard, so you can identify problems faster than manual command-line diagnostics.

The anycast DNS architecture automatically routes queries to the nearest healthy server, which eliminates single points of failure that cause timeout errors. You'll also get DNSSEC validation built in, plus instant cache purging when you need to propagate record updates without waiting for TTL expiration.

Explore Gcore Managed DNS at gcore.com/dns.

Frequently asked questions

What's the difference between authoritative and recursive DNS servers?

Authoritative DNS servers store and provide the official DNS records for specific domains they manage, while recursive DNS servers query multiple authoritative servers on behalf of clients to resolve domain names they don't have cached. When you look up a website, your device contacts a recursive resolver that hunts down the answer from the appropriate authoritative server.

How long does DNS propagation take?

DNS propagation typically takes 24 to 48 hours globally, though changes often appear within a few hours at most resolvers. Lowering TTL values before making DNS changes can reduce propagation time to minutes instead of hours.

Why do DNS issues cause website downtime?

DNS issues cause website downtime because browsers can't translate domain names into IP addresses needed to locate web servers. When DNS resolution fails (whether from misconfigured records, unreachable nameservers, or DNSSEC validation errors), visitors see error messages instead of your site, even if your web server is running perfectly.

What are the most reliable public DNS servers?

Google Public DNS (8.8.8.8 and 8.8.4.4) and Cloudflare DNS (1.1.1.1 and 1.0.0.1) are the most widely recommended public resolvers for troubleshooting and testing DNS configurations. Both offer fast resolution speeds, built-in DNSSEC validation, and diagnostic tools to help identify whether issues originate from your primary DNS setup.

How often should DNS records be updated?

DNS records should be updated whenever infrastructure changes occur (such as switching hosting providers, adding servers, or modifying mail configurations) rather than on a fixed schedule. Set TTL values between 300 seconds (five minutes) and 3,600 seconds (one hour) to balance propagation speed with resolver cache effectiveness.

Is it safe to change DNS settings?

Yes, changing DNS settings is safe and reversible. You can always switch back to your original configuration if issues occur. Just verify you're using reputable DNS providers like your ISP's default servers or well-known public resolvers when testing configurations.

What tools are best for DNS monitoring?

Command-line tools like nslookup, dig, and host handle on-demand DNS queries, while monitoring platforms such as DNS Made Easy and Pingdom track uptime, resolution speed, and record propagation across global resolvers. For continuous visibility, you'll want dedicated DNS monitoring services that alert you to resolution failures, DNSSEC validation errors, and TTL misconfigurations before users notice problems.