Most DNS confusion is one mistake: checking from your own computer and treating the answer as the truth. Your machine has a cache, your router may have one, and your provider's resolver certainly does.
These commands let you ask a specific server and see exactly what it says.
The basic query
dig example.com A
The section to read is ANSWER SECTION. It contains the name, the remaining TTL, the record type and the value.
That TTL is counting down from whatever the record was configured with. Two people checking the same record five minutes apart see different numbers, and neither is the configured value.
For a shorter output:
dig +short example.com A
Ask a specific server
This is the part that makes the tool useful.
dig @1.1.1.1 example.com A dig @8.8.8.8 example.com A
Public resolvers, showing what a visitor using them currently receives. If two disagree, a change is partway through expiring.
dig @ns1.ahosting.net example.com A
The authoritative server. No caching; this is the configured value. If it is wrong here, the record is wrong and nothing about waiting will help.
That distinction answers the question people actually have during a migration: is the record wrong, or right but not yet expired?
Finding the authoritative servers
dig example.com NS +short
And to see what the registrar is publishing, which can differ from what the zone says:
dig example.com NS @a.gtld-servers.net
A mismatch there is the specific fault where you changed nameservers, the zone looks correct, and nothing works, because the parent is still directing everyone elsewhere.
The record types worth checking
dig example.com MX +short dig example.com TXT +short dig example.com CNAME +short dig -x 203.0.113.10 +short
The last is a reverse lookup, which matters for mail. There is more in understanding PTR and reverse DNS.
For SPF and DKIM, the records are TXT and often long:
dig example.com TXT +short dig default._domainkey.example.com TXT +short
Understanding SPF, DKIM and DMARC deals with reading what comes back.
Trace the whole path
dig +trace example.com
This walks the chain from the root servers down, showing each delegation. It is verbose and it is the fastest way to find where a lookup is going wrong, particularly a delegation pointing at nameservers that no longer host the zone.
nslookup, when dig is not available
nslookup example.com nslookup example.com 1.1.1.1 nslookup -type=MX example.com
Available by default on Windows, where dig usually is not. It shows less and answers the same basic questions.
One thing to watch: nslookup labels answers as "non-authoritative" for anything from a cache, which is normal in place of a warning.
Checking from elsewhere
Your own results reflect one network. During a change, what matters is whether other places agree.
Querying several public resolvers approximates this well enough for most purposes. Consistent answers everywhere means the change has settled; disagreement means caches are still expiring, and the fix is waiting rather than changing anything else.
Changing a record repeatedly because it "has not propagated" is the most common way to turn a ten-minute wait into a genuinely confusing afternoon, understanding DNS propagation and TTL cover why.
Clearing your own cache
When everything checks out and your browser still goes to the old place, the remaining cache is local:
sudo dscacheutil -flushcache # macOS ipconfig /flushdns # Windows
Browsers cache separately, so a private window is a faster test than clearing anything.
Read the status line, not just the answer
Above the answer, dig reports what kind of result this is. Three values cover almost everything.
status: NOERROR. The query succeeded. Note that this includes the case where the name exists but has no record of the type you asked for, which shows as NOERROR with an empty answer section. That is a different situation from the name not existing, and confusing the two sends people looking for the wrong fault.
status: NXDOMAIN; the name does not exist at all. If you have just created it, this is the negative answer being cached rather than your record being missing.
status: SERVFAIL. The resolver could not get an answer. Usually a broken delegation or a DNSSEC validation failure, and it is the one status that indicates something genuinely wrong rather than merely absent.
Two flags are worth recognising. aa means the answer came from an authoritative server rather than a cache. ad means the answer was validated by DNSSEC. Understanding DNSSEC deals with when its absence matters.
When the answer is a chain
dig shop.example.com A
If shop is a CNAME, the answer section shows the CNAME first and then the address it eventually resolved to. That is normal and it is also how you spot an unintended chain; a CNAME pointing at another CNAME pointing at a third name.
Each link is a lookup, so long chains cost time on every visit. And a chain ending at a name that no longer resolves produces a failure whose cause is several steps from where you were looking. Understanding apex domains and CNAME limits explains where chains commonly come from.
Checking many names at once
for n in example.com www.example.com mail.example.com shop.example.com; do printf '%-28s %s\n' "$n" "$(dig +short "$n" A | tr '\n' ' ')" done
Useful after a migration, when the question is which of a domain's names moved and which were forgotten. A name returning nothing is either absent or pointing somewhere that no longer answers, and both are worth knowing before a customer finds them.
Add the record type to the loop to check MX or TXT across several domains in the same way; that is the fastest way to audit a portfolio you have inherited.
What dig does not tell you
It reports what DNS says, not whether the destination works. A perfect A record pointing at a server that is switched off looks exactly like a perfect A record.
So a DNS check is one half of a diagnosis. The other half is whether the address actually answers. Telling whether a slow site is the server or the site deals with that side, and keeping the two questions separate prevents a great deal of confusion.