What nslookup Is For
When a website isn't loading, or you've just updated DNS records after a migration or domain transfer, the question you need answered is always the same: what is DNS actually returning for this domain right now? nslookup is a command-line tool built into Windows, macOS, and Linux that queries DNS directly and shows you the raw answer — no browser caching, no CDN quirks, just what the DNS server says. It's the fastest way to confirm whether a domain is pointing where you expect before you start troubleshooting anything more complicated.
Basic Lookup: A Records
Open Command Prompt, PowerShell, or a terminal and run:
nslookup example.com
The output looks like this:
Server: UnKnown
Address: 192.168.1.1
Non-authoritative answer:
Name: example.com
Address: 93.184.216.34
The Server/Address at the top is the DNS resolver your query went through (usually your router or ISP). The Non-authoritative answer section is the actual result — the IP address the domain currently resolves to. "Non-authoritative" just means this answer came from a resolver's cache rather than directly from the domain's own nameserver; it's still accurate, just not a guaranteed live read.
Checking a Specific Record Type
By default nslookup returns A records (IPv4 addresses). Use the -type= flag to query other record types:
nslookup -type=MX example.com
nslookup -type=CNAME www.example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com
nslookup -type=AAAA example.com
- MX — mail exchange records, showing which servers handle email for the domain. Essential when troubleshooting email delivery.
- CNAME — alias records, common for subdomains like
wwwpointing to another hostname. - TXT — text records, used for domain verification and SPF/DKIM/DMARC email authentication policies.
- NS — the authoritative nameservers responsible for the domain.
- AAAA — IPv6 address records.
Querying an Authoritative Nameserver Directly
The most useful technique when you're troubleshooting DNS propagation after making a change: query the domain's own authoritative nameserver instead of your local resolver, bypassing any cached answers in between. First find the nameservers, then query one of them directly by appending it as the second argument:
nslookup -type=NS example.com
nslookup example.com ns1.example-dns.com
This tells you exactly what the domain's own DNS provider is currently serving — the ground truth — regardless of what stale answer your ISP's resolver might still be caching.
Comparing Against a Public Resolver
You can also point nslookup at any public DNS resolver to see how the record looks from a different vantage point on the internet, which is useful for spotting inconsistent or partially-propagated records:
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1
Google's resolver is 8.8.8.8 and Cloudflare's is 1.1.1.1. If your ISP's resolver, Google's, and Cloudflare's all show different answers for the same record, you're mid-propagation — DNS changes take time to spread as caches expire based on each record's TTL (time-to-live) value.
Interactive Mode
Running nslookup with no arguments drops you into an interactive prompt where you can run multiple queries and change settings without retyping the command each time:
nslookup
> server 8.8.8.8
> set type=MX
> example.com
> exit
Diagnosing Common Problems
- Domain not resolving at all: nslookup returns
*** UnKnown can't find example.com: Non-existent domain. Either the domain has no DNS records configured, or you have a typo. - Site shows old content after a server migration: check the A record — if it still shows the old IP, the change hasn't propagated yet, or you edited the record at the wrong DNS provider (common when a domain's registrar and DNS host are different companies).
- Email not arriving: check the MX record. If it's missing, pointing to the wrong provider, or has an unexpected priority value, mail routing will fail or misbehave.
- www works but the bare domain doesn't (or vice versa): check both the A record for the bare domain and the CNAME for
www— they're configured independently and one can be missing while the other works fine.
dig (available on macOS/Linux, and on Windows via WSL) is more powerful than nslookup. But for a quick "is this domain pointing where I expect" check, nslookup is faster to reach for since it's already installed everywhere.Wrap-Up
nslookup won't fix a DNS misconfiguration for you, but it tells you exactly what's wrong in seconds — wrong IP, missing record, stale propagation, or a typo in the hostname — which is most of the battle when a "the site won't load" ticket lands on your desk.
Discussion & Insights