nslookup is actually a deprecated tool, and you should be using dig instead.
Let’s see nslookup in action, then I’ll show you how to fix it when it breaks.
$ nslookup google.com
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: google.com
Address: 142.250.190.142
Here, nslookup queried the DNS server at 192.168.1.1 (your local router, typically) to resolve google.com to an IP address. The "Non-authoritative answer" means the server 192.168.1.1 didn’t have the answer itself but got it from another DNS server, effectively acting as a client on your behalf.
The mental model for DNS resolution is a chain of trust and delegation. Your computer asks a local resolver (like your router, or a public DNS server like 8.8.8.8). That resolver, if it doesn’t know the answer, asks a root server. The root server tells it which TLD (Top-Level Domain, like .com) server to ask. The TLD server tells it which authoritative nameserver for google.com to ask. Finally, the authoritative nameserver for google.com gives the IP address.
nslookup lets you interact with this chain. You can specify which server to query:
$ nslookup google.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 142.250.190.142
This asks Google’s public DNS server directly. You can also query for different record types, like MX records for mail servers:
$ nslookup -type=mx google.com
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
google.com mail.google.com
Authoritative answers can be found from:
google.com 10 smtp.google.com.
google.com 20 smtp2.google.com.
This tells you that mail for google.com is handled by mail.google.com, with specific priorities.
The one thing most people don’t know is that nslookup has a "set debug" mode that shows you the raw DNS packets being sent and received, which is invaluable for understanding the protocol’s nuances.
$ nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> set debug
> google.com
Server: 8.8.8.8
Address: 8.8.8.8#53
------------
Send:
;; opcode: QUERY, status: NOERROR, id: 47749
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 299 IN A 142.250.190.142
------------
------------
Send:
;; opcode: QUERY, status: NOERROR, id: 47749
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 299 IN A 142.250.190.142
------------
Non-authoritative answer:
Name: google.com
Address: 142.250.190.142
> exit
The set debug output shows the query packet structure (QUESTION SECTION) and the response packet structure (ANSWER SECTION), including flags like rd (recursion desired) and ra (recursion available).
The next concept to explore is how DNS caching works and how to invalidate it.
FIX: nslookup: server can’t find domain.com: NXDOMAIN
The server can't find domain.com: NXDOMAIN error means the DNS server you queried does not have any record for domain.com and it’s not a temporary issue; the domain likely doesn’t exist or isn’t configured correctly. This is happening because the DNS resolver you’re talking to has given up trying to find the name, indicating a definitive "not found" response from the authoritative servers.
Here are the most common reasons and how to fix them:
-
Typo in the domain name: This is by far the most common culprit. You simply misspelled the domain you’re trying to resolve.
- Diagnosis: Carefully re-read the domain name you typed in the
nslookupcommand. Compare it character by character to the expected domain name. - Fix: Correct the typo. For example, if you meant
example.combut typedexmaple.com, change it tonslookup example.com. - Why it works: DNS is case-insensitive but extremely precise with spelling. A single incorrect character means you’re asking for a non-existent name.
- Diagnosis: Carefully re-read the domain name you typed in the
-
Domain has expired or was never registered: The domain name you’re trying to resolve might have expired and been removed from the DNS system, or it was never registered in the first place.
- Diagnosis: Use a WHOIS lookup tool (e.g.,
whois example.comon Linux/macOS, or an online WHOIS service) to check the registration status of the domain. - Fix: If the domain has expired, the owner needs to renew it with their registrar. If it was never registered, it needs to be registered.
- Why it works: A domain must be actively registered and managed by a registrar to have corresponding DNS records.
- Diagnosis: Use a WHOIS lookup tool (e.g.,
-
DNS propagation delay: If the domain was recently registered, transferred, or its DNS records were recently changed, it can take time for these changes to propagate across all DNS servers globally. The server you’re querying might not have received the updated information yet.
- Diagnosis: Try querying a different, reliable public DNS server (like Google’s
8.8.8.8or Cloudflare’s1.1.1.1) to see if they can resolve it. If they can, your local resolver is just behind.nslookup domain.com 8.8.8.8 - Fix: Wait for DNS propagation. This can take anywhere from a few minutes to 48 hours, though typically much faster for A records. You can also try flushing your local DNS cache (e.g.,
sudo systemctl restart systemd-resolvedon systemd-based Linux,ipconfig /flushdnson Windows,sudo killall -HUP mDNSResponder; sudo killall mDNSResponderHelperon macOS). - Why it works: DNS changes are distributed through a hierarchical system. Propagation ensures that all DNS servers eventually learn about the updated records. Flushing your local cache forces your machine to ask a remote server for the latest information.
- Diagnosis: Try querying a different, reliable public DNS server (like Google’s
-
Incorrect authoritative nameservers configured for the domain: The domain’s registrar settings might point to the wrong nameservers, or the nameservers themselves are misconfigured and not serving the correct records.
- Diagnosis: Use
whois domain.comto find the nameservers listed for the domain. Then, usenslookupto query those specific nameservers for the domain’s records.
Also, check the domain’s delegation using a tool likenslookup domain.com ns1.wrong-nameserver.comdigto see if the nameservers are correctly delegated by the TLD.
Look fordig +trace domain.comNXDOMAINresponses at the TLD or other delegation levels. - Fix: The domain owner must log into their registrar account and update the nameserver records to point to the correct, functional nameservers.
- Why it works: DNS resolution relies on the correct delegation of authority. If the nameservers listed are incorrect or unresponsive, the domain cannot be resolved.
- Diagnosis: Use
-
Firewall blocking DNS queries: A firewall, either on your local machine, your network, or even at the DNS server’s end, could be blocking DNS traffic (UDP/TCP port 53).
- Diagnosis: Temporarily disable any local firewalls and try again. If on a corporate network, consult your network administrator. Try resolving from a different network.
- Fix: Configure firewall rules to allow UDP and TCP traffic on port 53 to your DNS servers.
- Why it works: DNS relies on port 53 for communication. Blocking this port prevents queries from reaching their destination or responses from returning.
-
DNS server issues (resolver misconfiguration or failure): The DNS resolver you are using might be misconfigured, overloaded, or experiencing an outage, leading it to return
NXDOMAINeven if the domain exists.- Diagnosis: Try querying multiple different DNS servers. If only one server consistently fails while others succeed, that specific server is the problem.
nslookup domain.com 1.1.1.1 nslookup domain.com 9.9.9.9 - Fix: Change your system’s DNS settings to use a different, reliable DNS server (e.g.,
8.8.8.8,1.1.1.1,9.9.9.9). If you manage your own DNS server, check its logs and configuration for errors. - Why it works: The DNS resolver acts as a client to other DNS servers. If the resolver itself is faulty, it cannot perform its job of finding the correct IP address.
- Diagnosis: Try querying multiple different DNS servers. If only one server consistently fails while others succeed, that specific server is the problem.
The next error you might encounter after fixing NXDOMAIN is a timeout, indicating that while the domain might exist, the server is unreachable or not responding within the expected timeframe.