How to Use Dig, Nslookup, and Whois to Troubleshoot Domain Problems

Overview

If you work with deployments, DNS automation, or domain configuration, you will eventually run into a familiar set of questions: Is the record correct? Are the nameservers right? Is my local resolver stale? Did the registrar update? Is this even a DNS problem at all?

The three tools in this article answer different parts of that puzzle:

• whois helps you inspect domain registration details and often the delegated nameservers.
• dig helps you query DNS records directly and with precision.
• nslookup offers a simpler interactive way to ask DNS questions, especially when you want quick checks from a shell on almost any system.

Used together, they give you a repeatable workflow for domain debugging:

1. Check registrar and delegation with whois.
2. Query authoritative or public resolvers with dig.
3. Cross-check from another resolver or interactive prompt with nslookup.
4. Interpret the response in context: nameserver issue, record issue, caching issue, or application issue.

This matters because many domain problems are not failures in one place. A deployment can be healthy while DNS still points elsewhere. A record can be correct at the authoritative nameserver while a local resolver is serving a cached answer. An SSL error can appear to be a certificate problem when the real issue is that the hostname resolves to an old server. If you need a broader primer on pointing domains correctly, see How to Point a Domain to a Server: A Record, CNAME, Nameservers, and TTL Explained.

Core framework

Here is the simplest mental model: domain troubleshooting has three layers. First is the registrar layer, where the domain exists and delegates to nameservers. Second is the authoritative DNS layer, where the actual records live. Third is the resolver layer, where public DNS services and local caches return answers to users and applications.

Each tool maps neatly to one or more of those layers.

Start with whois: who controls the domain and where is it delegated?

whois example.com is the fastest way to answer basic ownership and delegation questions. Depending on the TLD and registrar, the output may include registrar information, registration status, expiration dates, and delegated nameservers.

Useful checks:

• Does the domain exist and appear registered?
• Do the nameservers match the provider you expect?
• Was a recent nameserver change actually applied at the registrar?

If the nameservers in whois do not match your DNS provider, changing records in Cloudflare, Route 53, or another platform will not affect live traffic. That is a common cause of “everything looks right in the dashboard, but the internet still sees the old site.” If you are comparing providers or planning a migration, Best DNS Providers for Developers can help frame those tradeoffs.

Use dig for precise DNS queries

dig is usually the most useful troubleshooting tool because it shows you exactly what was asked, who answered, and what record data came back.

Common patterns:

dig example.com

dig example.com A

dig www.example.com CNAME

dig example.com MX

dig example.com TXT

Important parts of a typical response:

• ANSWER SECTION: the actual records returned.
• AUTHORITY SECTION: useful when no direct answer exists or when delegation details matter.
• Query time: not crucial for correctness, but helpful when comparing resolvers.
• SERVER: which resolver answered your query.
• TTL: how long the record may be cached.

Two especially valuable dig habits:

1. Specify the record type instead of relying on defaults.
2. Query a known resolver directly when you want to bypass your local setup.

dig @1.1.1.1 example.com A

dig @8.8.8.8 example.com A

This lets you compare answers from different public resolvers and quickly spot propagation or caching differences.

Query nameservers directly when authority matters

If you suspect a mismatch between your DNS provider and public resolvers, ask the authoritative nameserver directly. First, find the NS records:

dig example.com NS

Then query one of those nameservers for the record you care about:

dig @ns1.provider-dns.example www.example.com A

This is one of the most useful techniques in DNS troubleshooting. If the authoritative server returns the correct record but public resolvers do not, the issue is likely propagation or caching. If the authoritative server itself returns the wrong record, the problem is in the DNS zone configuration.

Use +short when you want fast, script-friendly output

The default dig output is detailed, but sometimes you only want the answer value.

dig +short example.com A

dig +short www.example.com CNAME

dig +short example.com MX

This is useful in shell scripts, deployment health checks, or CI jobs where you want a simple value instead of the full response. Teams that manage records as code may also combine this with infrastructure workflows; for that approach, see Terraform DNS Records Guide: Manage Cloudflare and Route 53 as Code.

Where nslookup still helps

nslookup is older and less expressive than dig, but it is still practical because it is widely available and easy to use interactively.

nslookup example.com
nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com

You can also specify a resolver:

nslookup example.com 1.1.1.1

Or open interactive mode:

nslookup
> server 8.8.8.8
> set type=TXT
> example.com

For quick ad hoc checks, especially on systems where dig is not installed, nslookup remains useful. Think of it as a lightweight fallback rather than your primary diagnostic tool.

How to read the results without overcomplicating them

In practice, most domain problems fall into one of these buckets:

• Delegation problem: whois shows the wrong nameservers.
• Zone problem: authoritative nameserver returns the wrong record or no record.
• Propagation or cache problem: authoritative server is correct, but public resolvers disagree.
• Hostname mismatch: root domain and www are configured differently.
• Application problem: DNS resolves correctly, but the web server, reverse proxy, SSL, or app is misconfigured.

That last category matters because DNS often gets blamed for issues that live elsewhere. If the domain resolves to the correct IP but the site still fails, the next place to look might be your reverse proxy, container setup, or certificate configuration. Related guides include Nginx Reverse Proxy Setup Guide, Docker Deployment Tutorial for Small Production Apps, and How to Fix ERR_SSL_PROTOCOL_ERROR After DNS or Hosting Changes.

Practical examples

The easiest way to build confidence with these tools is to apply them to common failure patterns. The examples below are less about memorizing commands and more about learning the sequence of checks.

Example 1: The site still points to the old server after a DNS change

Goal: determine whether the record is wrong or simply not fully propagated.

1. Check delegation with whois example.com. Confirm the nameservers match the DNS provider where you made the change.
2. Query the authoritative nameserver directly with dig. If it returns the new IP, your zone is likely correct.
3. Query multiple public resolvers, such as @1.1.1.1 and @8.8.8.8. If one returns the old IP, you are likely seeing propagation or caching.
4. Check TTL values to estimate how long caches may persist.

If you need a broader workflow for propagation-related issues, pair this with How to Fix DNS_PROBE_FINISHED_NXDOMAIN.

Example 2: Email delivery breaks after changing DNS

Goal: verify that mail-related records still exist and point to the intended provider.

dig example.com MX

dig example.com TXT

Check for:

• Correct MX targets
• SPF records in TXT output
• Any provider-specific TXT entries needed for verification

Email setups often break because a zone migration copied A and CNAME records but missed MX or TXT records. If you are working through mail routing or email authentication, see How to Set Up MX Records for Custom Email Domains.

Example 3: The apex domain works, but www does not

Goal: compare the root and subdomain records directly.

dig +short example.com A

dig +short www.example.com A

dig +short www.example.com CNAME

This quickly shows whether www is missing, pointing to a stale target, or using a CNAME that no longer resolves. A common deployment mistake is updating the root domain record but forgetting the www alias.

Example 4: The domain resolves, but the application still fails

Goal: confirm whether DNS is healthy before debugging the app stack.

Use dig or nslookup to verify that the hostname resolves to the intended IP or provider target. If it does, DNS may be fine. The issue may instead be:

• Nginx or another reverse proxy routing to the wrong upstream
• A container that is not listening on the expected port
• A TLS certificate that does not cover the hostname
• A platform deployment that was not actually promoted to production

This is especially common in frontend platform workflows and CI/CD pipelines. If you are narrowing down deployment-side issues, related reading includes GitHub Actions Deployment Guide and Vercel vs Netlify vs Cloudflare Pages.

Example 5: You are not sure whether a nameserver migration completed

Goal: distinguish registrar delegation from zone content.

1. Run whois example.com and note the listed nameservers.
2. Run dig example.com NS and compare what resolvers return.
3. If the registrar and resolver outputs disagree briefly, you may be in the middle of a nameserver transition.

During migrations, one of the most expensive mistakes is updating records in the new provider before the domain actually delegates there, or deleting the old zone too early.

Common mistakes

Most wasted DNS debugging time comes from a small number of repeat mistakes. Knowing them in advance saves a surprising amount of effort.

Checking only one resolver

If you ask only your local machine, you may mistake a cache issue for a global DNS problem. Always compare at least one public resolver and, when needed, the authoritative nameserver.

Forgetting that nameservers and records are separate changes

Changing the nameserver delegation at the registrar is not the same as changing records inside the DNS zone. whois helps you confirm which provider is actually authoritative.

Assuming DNS is broken when the web server is broken

If dig returns the correct address, do not stay stuck in DNS too long. Move on to HTTP, TLS, reverse proxy, or application checks.

Ignoring TTL during active changes

TTL does not guarantee when every user will see a change, but it does help explain why some clients still receive older answers. When planning migrations, lower TTL ahead of time if your provider and workflow allow it.

Querying the wrong hostname

example.com, www.example.com, api.example.com, and mail-related hosts may all be configured differently. Troubleshoot the exact hostname that is failing.

Missing record type context

A successful A lookup does not tell you whether MX, TXT, AAAA, or CNAME records are correct. Ask for the specific record type related to the symptom.

Stopping at one tool

No single command answers every question. whois tells you about delegation. dig tells you what DNS returns. nslookup can validate quickly from another environment. The combination is what makes the workflow reliable.

When to revisit

This is a guide worth returning to whenever the underlying inputs change: new hosting provider, nameserver migration, email provider switch, CI/CD rollout, or SSL changes after a deployment. Even if your commands stay the same, the interpretation changes with the architecture around the domain.

Revisit this workflow when:

• You move DNS providers or registrars
• You point a domain to a new server, load balancer, or frontend platform
• You add email authentication or change MX routing
• You automate DNS with APIs or infrastructure as code
• You see browser or API errors after a deployment and need to rule DNS in or out quickly

A practical action plan for future incidents:

1. Save a short command checklist. Keep a small text file or shell script with the few lookups you run most often: whois, dig NS, dig A, dig CNAME, dig MX, and a public resolver query.
2. Document your expected answers. Record the correct nameservers, canonical targets, and mail provider hosts for each production domain.
3. Check authoritative first during incidents. It is the quickest way to separate configuration errors from propagation delays.
4. Use concise output in automation. dig +short is often enough for deployment checks and lightweight scripts.
5. Escalate beyond DNS when resolution is correct. Once the hostname points where it should, move immediately to web server, SSL, and application diagnostics.

If you keep that sequence in mind, domain troubleshooting becomes much less guesswork-heavy. whois tells you who is authoritative, dig tells you what DNS actually says, and nslookup gives you a simple cross-check from almost anywhere. That combination is enough to diagnose most domain problems quickly and with confidence.