What Is Nslookup? 🔍 How to Use It on Linux, Mac & Windows

What Is the nslookup Command?

nslookup stands for "Name Server Lookup." It's a command-line tool that asks DNS servers what they know about a domain name or IP address. That's it. You type a hostname, it returns the IP. You type an IP, it tries to give you back a hostname. You can also ask for specific record types — MX for mail, NS for nameservers, TXT for things like SPF — and you can point it at any DNS server you want. Available on Windows, macOS, and Linux, it's one of the most essential tools for DNS troubleshooting and network diagnostics.

I use it almost daily when troubleshooting. Site won't load? nslookup. Email bouncing? nslookup. Customer swears DNS isn't propagating? You guessed it. Encountering connectivity woes or curious about a domain's IP address? Simply wield the nslookup command in your command prompt or terminal and witness its magic unfold.

One quick example before we go deeper:

nslookup google.com

That returns Google's A record (an IPv4 address) using whatever DNS resolver your system is configured to use. Simple as that.

What nslookup can and can't tell you

It can confirm what a DNS server is currently answering. It can show you mail routing, nameserver delegation, and reverse DNS. What it can't do is tell you whether a website is actually online, whether ports are open, or whether your local network is the problem. For that, you'll want ping, traceroute, or a port check.

How DNS Lookup Works (Quick Refresher)

When you type a domain into a browser, your machine doesn't magically know where to go. It asks a recursive resolver — usually your ISP's, or something like 1.1.1.1 or 8.8.8.8. That resolver walks the chain: root servers, TLD servers (like .com), then the authoritative nameserver for the domain. The answer gets cached along the way, which is why how DNS works can feel inconsistent — different resolvers see different cached values at different times. This is also why nslookup against 8.8.8.8 might return a different IP than your local resolver. Caching, propagation, geo-routing — all normal.

nslookup Syntax and Basic Command Format

The basic shape of the command is:

nslookup [options] [name | IP] [dns-server]

Most of the time you'll only use the middle bit. Here are the four patterns you'll use 95% of the time.

Query a domain name

nslookup example.com

Returns the A (and sometimes AAAA) record using your default resolver.

Query an IP address (reverse lookup)

nslookup 8.8.8.8

This asks for the PTR record — the hostname associated with that IP. Useful for verifying mail server identity.

Query a specific DNS server

nslookup example.com 1.1.1.1

The second argument tells nslookup to bypass your local resolver and ask Cloudflare directly. Handy when you suspect your ISP's resolver is stale.

Set a record type

On Windows you use -type=, on Linux/macOS either -type= or -query= works:

nslookup -type=mx example.com
nslookup -type=txt example.com
nslookup -type=ns example.com

Interactive vs non-interactive mode

Everything above is non-interactive — one command, one answer, done. But nslookup also has an interactive mode. Just type nslookup with no arguments and you'll get a > prompt.

nslookup
> server 8.8.8.8
> set type=mx
> example.com
> set type=a
> google.com
> exit

This is genuinely useful when you're hammering a bunch of queries against one resolver. I use interactive mode when debugging a customer's nameservers and need to compare 10 records back-to-back. Other useful interactive commands:

• set debug — shows the full query and response
• set d2 — even more verbose debug output
• set timeout=10 — bump the wait if a server is slow
• set retry=2 — retry attempts on failure

Common DNS Record Types You Can Query

Here's the cheat sheet I wish someone had handed me on day one.

You'll mostly live in A, MX, NS, and PTR. The others come up when something's weird.

How to Use nslookup: Common Examples

Find the IP address of a domain

nslookup 1gbits.com

Returns the resolver you queried plus the IP. If you see two answers (IPv4 and IPv6), the domain has both A and AAAA records.

Perform a reverse DNS lookup

nslookup 142.250.80.46

This returns the PTR record — the hostname registered to that IP. If you get "** server can't find ...: NXDOMAIN", there's just no PTR set. Not always a bug. Many residential IPs have no PTR at all.

Check MX records

nslookup -type=mx gmail.com

You'll see multiple entries, each with a preference number. Lower preference = higher priority. This is the first thing I check when someone says "my email isn't arriving."

Check nameservers

nslookup -type=ns example.com

Confirms which authoritative nameservers handle the domain. Useful right after a registrar change.

Check TXT records

nslookup -type=txt example.com

SPF, DKIM selectors, and domain ownership tokens all live in TXT.

Use a specific DNS server

nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1
nslookup example.com 208.67.222.222

Three queries against three different public resolvers. If the answers differ, you're seeing propagation in action.

Enable debug mode

nslookup -debug example.com

Shows the raw question/answer sections, TTLs, flags. Bit overwhelming the first time you see it. You'll learn to love it when something weird is happening.

How to Read nslookup Output

This is the part most tutorials skip. Here's a typical response:

Server:    1.1.1.1
Address:   1.1.1.1#53

Non-authoritative answer:
Name:    example.com
Address: 93.184.216.34

Let me break that down line by line.

• Server — the DNS resolver that answered. In this case Cloudflare.
• Address — the IP and port of that resolver. #53 is the standard DNS port.
• Non-authoritative answer — the resolver gave you a cached result, not a fresh answer from the domain's authoritative nameservers. This is normal and almost always what you want. Authoritative answers only come back when you query the domain's actual NS directly.
• Name — the hostname you asked about.
• Address — the resolved IP.

For MX queries you'll see something like mail exchanger = 10 mail.example.com. The 10 is the preference value — lower numbers are tried first. SOA records will show serial, refresh, retry, expire, and minimum TTL values. Don't memorize them. Just know where to look when you need to.

nslookup on Windows

Open Command Prompt (or PowerShell — both work). Type nslookup and you're in. Windows ships with it preinstalled on every version since at least Windows 2000. No setup, no install. If you're managing DNS on a Windows VPS, nslookup comes preinstalled and ready to use alongside PowerShell's Resolve-DnsName.

C:\> nslookup microsoft.com
C:\> nslookup -type=mx microsoft.com
C:\> nslookup microsoft.com 1.1.1.1

Here's how to perform common queries on Windows:

• Getting the A record: Type nslookup, then set type=A, then enter the domain name. Nslookup will display the IP address associated with the domain. Example: Non-authoritative answer: Name: example.com Address: 93.184.216.34
• Checking NS records: Type set type=ns, then enter the domain. Nslookup displays the authoritative name servers for the specified domain.
• Finding MX records: Type set type=mx, then enter the domain. Nslookup displays MX records with priority and mail server information.
• Reverse DNS lookup: Simply type the IP address directly, e.g., 192.0.2.1, and Nslookup displays the associated domain name if available.
• Enabling debug mode: Type set debug and press Enter. This triggers debug mode, providing more detailed information during the DNS lookup process. To disable, type set nodebug.
• Changing timeout interval: Use set timeout=10 to change the timeout to 10 seconds.

Windows alternative: Resolve-DnsName

PowerShell has a more modern cmdlet that's honestly nicer for scripting:

Resolve-DnsName microsoft.com
Resolve-DnsName microsoft.com -Type MX
Resolve-DnsName microsoft.com -Server 8.8.8.8

Output is structured (objects, not text), which makes it easy to pipe into other PowerShell commands. For one-off checks I still reach for nslookup out of habit. For anything scripted, Resolve-DnsName wins.

nslookup on Linux

On most modern distros, nslookup isn't installed by default anymore. It got pulled out of the base install in favor of dig and host. So the first error you might hit is:

nslookup: command not found

Easy fix. The binary lives in the bind-utils or dnsutils package depending on your distro.

Install on Ubuntu/Debian

sudo apt update
sudo apt install dnsutils

Install on CentOS/RHEL/AlmaLinux/Rocky

sudo yum install bind-utils
# or on newer systems:
sudo dnf install bind-utils

After that, usage is largely identical to Windows. If you're running these commands on a Linux VPS, you already have full root access to configure and test your DNS settings directly.

nslookup example.com
nslookup -type=mx example.com
nslookup example.com 9.9.9.9

Common Linux-specific queries include:

• Getting the SOA record directly: nslookup -type=soa example.com
• Looking up AAAA record (IPv6): nslookup -type=aaaa example.com
• Reverse DNS lookup: nslookup 192.168.1.1
• Querying a specific DNS server: nslookup example.com 8.8.8.8
• Non-interactive MX query: nslookup -query=mx example.com

nslookup on macOS

macOS ships with nslookup preinstalled. Open Terminal (Cmd+Space, type "Terminal") and you're ready.

nslookup apple.com
nslookup -type=ns apple.com
nslookup apple.com 1.1.1.1

Worth knowing: Apple has officially deprecated nslookup in favor of dig and host, but they haven't removed it. It still works fine. To check for a PTR record, simply type the IP address: nslookup 192.168.1.1. To change the timeout interval, use: nslookup -timeout=10 example.com.

nslookup vs dig vs host

Three tools, same general purpose, different personalities.

My honest take: if I'm sitting at a Linux box and need to see exactly what an authoritative server is returning, I reach for dig +trace. If I'm on a random Windows machine helping a customer, nslookup wins because it's already there. host is what I use when I just want a one-line answer and don't care about the rest.

Common nslookup Errors and Fixes

nslookup: command not found

You're on Linux and the package isn't installed. Run sudo apt install dnsutils (Debian/Ubuntu) or sudo yum install bind-utils (RHEL family). Done.

DNS request timed out

Three likely culprits:

• Your configured DNS server isn't reachable. Try nslookup example.com 1.1.1.1 to bypass it.
• A firewall or VPN is blocking outbound UDP 53. Common on corporate networks.
• The DNS server you're querying is genuinely down or rate-limiting you.

Bump the timeout in interactive mode: set timeout=10.

NXDOMAIN / Non-existent domain

The domain doesn't exist, or you typo'd it. Also happens when a domain has expired or hasn't propagated yet. Cross-check with a different resolver.

Server failed (SERVFAIL)

The resolver tried but couldn't get a valid answer. Often a DNSSEC validation failure or a misconfigured authoritative server. Try another resolver to confirm.

No PTR record found

Not always an error. Reverse DNS is optional. If you control the IP (say, on a dedicated server) and you need a PTR — mainly for sending mail — you'll set it via your hosting provider's control panel, not via DNS.

Wrong DNS server response

If nslookup shows a different IP than ping does, you're probably hitting different resolvers, or your local DNS cache is stale. Flush it.

Using nslookup for Real Troubleshooting

Website not resolving

1. nslookup yoursite.com — does it return an IP at all?
2. nslookup yoursite.com 8.8.8.8 — does an external resolver agree?
3. nslookup -type=ns yoursite.com — are the right nameservers delegated?
4. If results differ between resolvers, you're mid-propagation. Wait it out.

Email delivery problems

The classic workflow:

1. nslookup -type=mx yourdomain.com — confirm mail routing.
2. nslookup mail.yourdomain.com — make sure that MX hostname resolves to an IP.
3. nslookup <that IP> — verify PTR matches. Missing or mismatched PTR is the #1 reason mail lands in spam.
4. nslookup -type=txt yourdomain.com — check SPF.

Internal DNS and Active Directory

On a Windows domain network, AD relies heavily on SRV records to advertise services like domain controllers, Kerberos, and LDAP. Useful checks:

nslookup -type=srv _ldap._tcp.dc._msdcs.yourdomain.local
nslookup -type=srv _kerberos._tcp.yourdomain.local
nslookup -type=a dc01.yourdomain.local

If those queries fail from a client machine but succeed from the DC itself, you've got a split-horizon DNS or a misconfigured client resolver. I've debugged this exact issue more times than I'd like to admit — it's almost always DHCP handing out the wrong DNS server.

Best Public DNS Servers to Test With

When something looks wrong, the fastest sanity check is querying the same record against multiple resolvers. Here are the ones I rotate through:

• Cloudflare — 1.1.1.1 and 1.0.0.1. Fast, privacy-focused.
• Google Public DNS — 8.8.8.8 and 8.8.4.4. Reliable, globally distributed.
• Quad9 — 9.9.9.9. Blocks known malicious domains.
• OpenDNS — 208.67.222.222 and 208.67.220.220. Good for filtering options.

If two resolvers agree and one disagrees, the odd one out is probably caching an old value. If all three disagree with what your DNS provider should be serving, propagation hasn't completed yet. For a comprehensive list, check our list of the best public DNS servers that can significantly improve your browsing speed and security. For those running their own nameservers or hosting multiple domains, a reliable VPS server gives you the control to configure custom DNS zones and test them with the resolvers listed above.

Conclusion

nslookup isn't fancy, but it's one of the most reliable tools in any sysadmin's belt. Learn the four core patterns — plain query, reverse lookup, record type, specific server — and you can solve most DNS issues in under a minute. With its simplicity and versatility, nslookup empowers network administrators and users alike to diagnose and resolve DNS-related problems efficiently, thereby maintaining the reliability and performance of network services. For deeper debugging move up to dig; for Windows scripting, Resolve-DnsName. And when something looks broken, always test against multiple resolvers before assuming the worst. Whether you're troubleshooting from a local machine or a Cloud VPS, nslookup is the first tool to reach for.