Put the server after the name: nslookup example.com 1.1.1.1. That single argument is the whole feature, and it is the difference between asking your laptop what it remembers and asking a specific resolver what it currently knows.
This matters most during a DNS change. You point a domain at a new host, the change looks live from your machine and dead from a colleague’s, and somebody says the word propagation as though it explains anything. It does not. What is happening is that different resolvers are holding different cached answers with different remaining lifetimes, and the only way to see that clearly is to ask them one at a time.
Table of contents
- The one-line form
- Interactive mode, and when it earns its keep
- Reading the non-authoritative answer line
- Comparing resolvers during a propagation window
- dig, and why most people switch to it
- The failures worth recognising on sight
- How this fits the rest of the stack
- FAQ
The one-line form
Non-interactive mode takes the name first and the server second. This works identically on Windows, macOS, and Linux.
nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8
nslookup example.com 9.9.9.9
# a specific record type
nslookup -type=MX example.com 1.1.1.1
nslookup -type=TXT example.com 8.8.8.8
nslookup -type=NS example.comWith no server argument, nslookup uses whatever your system resolver is configured to use — the DHCP-assigned resolver on most networks, which on a home connection means your ISP. That is a perfectly valid thing to query. It is just rarely the thing you meant to query when you are debugging a change you made ten minutes ago.
The type flag goes before the name. nslookup -type=MX example.com 1.1.1.1 is right; putting the flag at the end is a common typo that produces a confusing error rather than a helpful one.
Interactive mode, and when it earns its keep
Running nslookup with no arguments drops you into a prompt where server changes the target for subsequent queries. This is worth using when you are checking many names against one resolver, or one name against many.
$ nslookup
> server 1.1.1.1
Default server: 1.1.1.1
Address: 1.1.1.1#53
> example.com
> www.example.com
> set type=MX
> example.com
> exitset type= inside the session does what -type= does on the command line and persists until you change it, which is the actual advantage — you set it once and then throw names at it.
set debug and set d2 turn on progressively more verbose output, showing the full response including TTLs and the authority section. That TTL number is the useful part during a change window: it tells you how many more seconds this resolver intends to keep serving the answer it has.
Reading the non-authoritative answer line
Almost every nslookup response you will ever see starts with Non-authoritative answer:, and it worries people the first time. It should not. It means the resolver you asked is not the authoritative nameserver for that zone — it is a recursive resolver serving a cached copy. That is normal and correct.
An authoritative answer only comes back when you query the zone’s own nameservers directly. Which you can do, in two steps:
# find the authoritative nameservers
nslookup -type=NS example.com
# then ask one of them directly
nslookup example.com ns1.example-dns.comThis two-step is the single most useful DNS debugging move there is. The authoritative answer is ground truth — it is what the zone actually says right now, with no cache in the way. If the authoritative server returns the new IP and a public resolver returns the old one, the change is correct and you are waiting on a TTL. If the authoritative server returns the old IP, the change did not save, and no amount of waiting will help.
Comparing resolvers during a propagation window
Once you accept that propagation is really just many independent caches expiring at different times, the workflow becomes concrete: query several resolvers and compare.
for s in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
echo "--- $s"
nslookup example.com $s | tail -n 3
doneA resolver that still has the old record is not broken and cannot be fixed from your side. It is honouring the TTL that was published when it looked the record up. The lesson lands before the change, not after: drop the TTL on the record to something short — 300 seconds is common — a day or two before you plan to move it, then raise it again once the new value is stable. Doing that costs one extra edit and removes the entire waiting problem.
Also check your own machine before blaming anything upstream. Operating systems and browsers cache separately from the resolver, so a stale answer can be local. Flushing that cache is a per-platform command, and it is worth doing before you conclude the internet is at fault.
dig, and why most people switch to it
nslookup is everywhere, which is its main virtue. dig is better at nearly everything else, and the syntax for choosing a server is even shorter.
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com MX
dig +short @1.1.1.1 example.com
dig +trace example.com+short prints just the answer, which makes it usable in scripts without parsing. +trace walks the delegation from the root servers down, showing each referral — it is the clearest way to see a broken delegation, where the parent zone points at nameservers that do not have the zone.
On Windows, Resolve-DnsName in PowerShell is the native equivalent and takes a -Server parameter. It returns objects rather than text, which makes it pleasant to filter.
Resolve-DnsName example.com -Server 1.1.1.1
Resolve-DnsName example.com -Type MX -Server 8.8.8.8Use whichever is installed. The mental model is identical: pick a resolver deliberately, ask it one question, and read the TTL as well as the answer.
The failures worth recognising on sight
- NXDOMAIN — the name does not exist in the zone. A typo, a missing record, or a subdomain nobody created. It is not a network problem.
- SERVFAIL — the resolver tried and failed. Frequently a DNSSEC validation failure or an authoritative server that is not answering. Query the authoritative server directly to split the two apart.
- REFUSED — the server you asked will not answer for that zone, usually because it is authoritative-only and you sent it a recursive query.
- Timeout — no answer at all. Check that outbound port 53 is not being blocked, which is common on corporate and hotel networks and produces a very confusing failure.
One more: an answer that is correct but points at the wrong thing. A CNAME chain that resolves to a parked page, or an A record left over from a host you decommissioned. nslookup will report that cheerfully because it is a valid answer. Only you know it is wrong, which is why reading the record you got back matters more than checking whether the command succeeded.
How this fits the rest of the stack
Almost every DNS session like this ends the same way — the record was right, the TTL was long, and the change window was longer than it needed to be. Lowering the TTL in advance is the fix, and doing certificate issuance and domain verification on the same platform that serves the site removes a second class of surprise. Custom domains on RunxBuild handle the certificate side once the record points at us; custom domains and certificates on RunxBuild walks through what to add and in what order. If the domain move is part of a larger migration, the RunxBuild hosting calculator shows the static site, the backend service, the database, and the bandwidth as separate numbers, which is a more honest way to plan a cutover than a single monthly figure.
Useful related references:
- Does Microsoft Edge Use Its Own DNS Server? What Secure DNS Actually Changes
- DNS Server Unavailable: A Fix-It Order That Starts With the Cheapest Cause
- DNS Server Not Responding: A Fix List That Goes Fastest Path First
- Custom domains and certificates on RunxBuild
FAQ
How do I query a specific DNS server with nslookup?
Put the server address after the name: nslookup example.com 1.1.1.1. In interactive mode, type server 1.1.1.1 first and every following query goes to that resolver. Record type flags like -type=MX go before the name, not after.
What does non-authoritative answer mean in nslookup?
It means the resolver that answered is not the authoritative nameserver for the zone — it served a cached copy. This is normal for public resolvers. To get an authoritative answer, look up the zone’s NS records first, then query one of those nameservers directly.
Why do different DNS servers return different results?
Each recursive resolver caches records independently for the length of the TTL published when it looked them up. After a change, resolvers hold the old value until their individual cache entries expire. Lowering the TTL before a planned change is what shortens that window.
Is dig better than nslookup?
For debugging, generally yes — dig @1.1.1.1 example.com is more direct, +short is script-friendly, and +trace shows the full delegation path from the root. nslookup’s advantage is that it is installed nearly everywhere, including default Windows installs, so it is the tool you can always count on.
What does SERVFAIL mean when I run nslookup?
The resolver attempted the lookup and could not complete it. The usual causes are a DNSSEC validation failure or an authoritative nameserver that is not responding. Query the zone’s authoritative nameservers directly to work out which side the problem is on.