Tools like nslookup and dig act like an X-ray for DNS, exposing hidden issues that ordinary checks miss. They help you diagnose domain not resolving errors more precisely than browser messages ever could.
Stale or Delayed Records: Cached entries may linger after a change, or propagation may take hours to spread worldwide. By comparing results from different resolvers with nslookup or dig @8.8.8.8, you can tell whether a record is still outdated somewhere in the chain.
Resolver Mismatches: Sometimes a resolver gives different answers than the authoritative server. Querying the authoritative nameserver directly reveals if your local DNS is out of sync, helping you separate temporary cache issues from real misconfigurations.
Misconfigured or Missing Records: An A record pointing to the wrong IP, or a missing MX/TXT record, can silently break websites or email. Running targeted lookups with these tools makes it easy to confirm whether the necessary entries are in place.
Nameserver or Delegation Errors: If a domain is pointing to the wrong nameserver or a delegation chain is broken, your site may become unreachable. Using dig +trace shows exactly where the resolution path fails.
Resolution Failures – When you see messages like “no servers could be reached”, the problem could be local or upstream. Testing against public DNS servers such as Google (8.8.8.8) or Cloudflare (1.1.1.1) helps narrow down whether the issue lies with your computer, your ISP, or the authoritative server.
How to Use nslookup for Troubleshooting DNS Issues
nslookup is often the first stop when DNS issues arise because it’s quick and built into most systems. Here’s how to make the most of it:
1. Simple Lookup: Check if a domain resolves correctly:
nslookup example.com
If the result doesn’t show the expected IP, the problem may be with the A record. This is the fastest way to confirm basic DNS resolution.
2. Checking Specific Record Types: Go beyond A records to inspect other DNS entries:
nslookup -type=MX example.com
reveals mail exchange (MX) records for troubleshooting email delivery, while:
nslookup -type=TXT example.com
shows TXT records used for SPF, DKIM, and domain verification.
3. Querying a Specific DNS Server: By default, nslookup uses your system’s DNS resolver. You can test another server for comparison:
nslookup example.com 8.8.8.8
This forces the query through Google’s public DNS. If the results differ from your default resolver, the issue may be related to caching or propagation.
4. Interactive Mode: Typing nslookup alone opens an interactive shell where you can run multiple queries without retyping the command each time:
> nslookup
> set type=MX
> example.com
This is useful for deeper testing when you need to check several record types in a row.
nslookup is useful for quickly confirming that a domain resolves, verifying email-related records such as MX or TXT, and comparing results across servers to distinguish local from global issues. While it’s fast and convenient, nslookup is limited to basic answers; for deeper diagnostics like tracing resolution paths or analyzing TTL values, dig provides far more detail.
How to Use dig for Troubleshooting DNS Issues
While nslookup works well for quick checks, dig provides deeper insights into DNS behavior. Its detailed output and advanced options make it the tool of choice when you need more than surface-level confirmation.
1. Basic Lookup: Check the A record for a domain:
dig example.com
This returns the IP address along with query time, TTL (time-to-live), and details about the nameserver that responded. It’s a straightforward way to confirm whether DNS is resolving correctly.
2. Querying Specific Record Types You can request any record type explicitly:
dig example.com MX
retrieves mail exchange (MX) records for email troubleshooting, while:
dig example.com TXT
shows TXT records, often used for SPF, DKIM, or domain verification.
3. Using Alternate DNS Servers: Send queries through a different resolver for comparison:
dig @8.8.8.8 example.com
This queries Google’s DNS instead of your default resolver. If Google’s response differs, the issue is likely due to caching or incomplete propagation on your provider’s side.
4. Tracing the DNS Resolution Path: To follow how a query travels through the DNS hierarchy:
dig +trace example.com
This command displays each step of the resolution, from root servers to authoritative nameservers. It’s especially helpful for diagnosing broken delegations or misconfigured nameservers.
5. Filtering Output for Clarity: dig’s default output can be verbose. Options like:
dig example.com +noall +answer
focus on just the key record data, while +stats highlights query time and response details. This makes it easier to analyze results quickly without sifting through unnecessary information.
When investigating complex DNS failures or propagation delays, dig provides the depth needed to uncover issues. It allows you to inspect detailed record information such as TTL and authoritative responses, while also tracing how a domain resolves through the full DNS chain. Thanks to its precision and flexibility, dig has become the go-to tool for network administrators and hosting professionals who require a deeper view of DNS resolution.
nslookup vs dig: Key Differences
Both nslookup and dig are valuable DNS troubleshooting tools, but they serve slightly different purposes. nslookup is simple and built into most systems, while dig offers more detailed information and greater flexibility.
Feature | nslookup | dig |
Availability | Preinstalled on Windows, macOS, and Linux | Default on Linux/Unix; installable on Windows/macOS |
Ease of Use | Beginner-friendly, quick A, MX, or TXT lookups | More technical, structured output takes practice |
Record Detail | Basic answers (IP, MX, TXT, CNAME) | Full details, including TTL, flags, query time, and authoritative servers |
Advanced Options | Limited (record type and DNS server choice) | Rich options like +trace, +stats, and debugging flags |
Best Use Case | Quick confirmation that a domain resolves or checking specific records | In-depth analysis, propagation checks, server mismatches, or complex troubleshooting |
Example Command | nslookup example.com → Quick IP lookup | dig example.com → Full DNS query with timing and detail |
Use nslookup when you need a quick check, such as confirming that a site resolves or verifying whether an MX record exists, while dig is better suited for full visibility diagnosing propagation delays, verifying authoritative responses, or tracing the entire resolution path.
Best Practices When Using nslookup and dig
To get the most out of nslookup and dig, it helps to follow some consistent troubleshooting habits:
Always query multiple DNS servers
Don’t rely on just your ISP’s resolver. Compare results from public DNS servers like Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). If responses differ, you’ll know whether the problem is local or more widespread.
Verify TTL values to understand caching delays
The Time-to-Live (TTL) tells you how long a DNS record remains cached before refreshing. If you’ve updated a record but still see the old result, the TTL often explains why. Checking it prevents unnecessary changes or wasted troubleshooting.
Document outputs for escalation
Save screenshots or logs of your queries. Clear evidence from nslookup or dig results makes it easier for hosting providers, registrars, or DNS administrators to replicate and resolve issues.
Use both tools strategically
Start with nslookup for quick confirmations like checking if a site resolves or if an MX record exists. Switch to dig when you need detailed analysis of authoritative servers, propagation paths, TTLs, or DNSSEC.
Cross-check with online tools
Pair your command-line checks with global lookup services such as WhatsMyDNS or DNSChecker. These reveal how records are resolving worldwide, helping you identify whether an issue is regional or global.
Check beyond A records
Don’t stop at confirming IP addresses. Problems with MX, TXT, or NS records can cause email failures, domain verification errors, or broken delegation. Make it a habit to review these as well.
By making these practices part of your workflow, you’ll spot hidden DNS issues faster, escalate problems with confidence, and reduce downtime for websites and email systems.