The fastest way to check a DNS record is dig +short cliai.tech A, which prints just the values and skips the header noise. Everything else in dig is about answering the question people actually ask after a DNS change: did it happen, or did it just not reach me yet? The answer is never "wait a bit longer" — it's compare two resolvers and read the TTL.
1. Just the answer, no noise
$ clai show the ip address of cliai.tech→ dig +short cliai.tech A104.21.58.232172.67.209.250+short strips everything except the record values. The full dig output is for debugging and scripts; for a quick look, this is what you want.
2. Ask a specific resolver
$ clai what does google's public resolver say about cliai.tech→ dig +short @8.8.8.8 cliai.tech172.67.209.250104.21.58.232@ bypasses your local resolver and its cache entirely. This is how you check whether a record has updated "in the world," not just on your machine.
3. Compare two resolvers — that's what checking propagation actually means
$ clai compare what google and cloudflare answer for cliai.tech→ for r in 8.8.8.8 1.1.1.1; do printf '%-10s %s\n' "$r" "$(dig +short @$r cliai.tech | tail -1)"; done8.8.8.8 172.67.209.2501.1.1.1 172.67.209.250Matching answers mean the record has propagated. A mismatch means an old value is still cached somewhere, and you wait out its TTL. No third-party propagation checker does anything more than this.
4. Mail and text records
$ clai show the mx and txt records for cliai.tech→ dig +short cliai.tech MX && dig +short cliai.tech TXT36 route3.mx.cloudflare.net.64 route1.mx.cloudflare.net.85 route2.mx.cloudflare.net."v=spf1 include:_spf.mx.cloudflare.net ~all"The record type is the last argument. In an MX line the leading number is priority — lower wins. TXT is usually where SPF and domain-ownership proofs live.
5. How much longer the cache will live
$ clai show the record's ttl so I know how long to wait→ dig cliai.tech A +noall +answerThe second number in the answer line is the TTL in seconds — how long a resolver holds the value before asking again. If you're about to change a record, lower the TTL a day ahead of time.
6. Find where it broke
$ clai trace the full delegation chain for cliai.tech→ dig +trace cliai.tech+trace walks down from the root servers and shows who delegates the zone to whom. It's how you catch the case where the registrar has one set of nameservers listed and you're editing records on another.
Gotchas
digwithout@asks your local resolver. On most systems that's a caching127.0.0.53, and it can serve a stale value. Always name the resolver explicitly when checking a change.- The TTL in a cached answer is counting down. The number shown is what's left, not the original value. To see the real TTL, ask the zone's authoritative server.
- "DNS propagation" isn't a process — it's cache expiry. Nothing is being broadcast anywhere. The change becomes visible exactly when each resolver's TTL runs out.
Related questions
Why do I see an old IP while a coworker sees the new one? Different resolvers with different amounts of TTL left. Check both with @ and wait out the slower one.
Why is dig better than nslookup? It shows response sections and flags more precisely, and supports +trace and +short. nslookup is considered deprecated.
How do I find a domain's authoritative servers? dig +short cliai.tech NS — then query records directly against them, skipping every cache in between.
See also
- Network triage in plain English: connections, ports, DNS
- Check if a port is open on a remote server
- Check SSL certificate expiry
Stop hand-writing dig flags — describe what you need to check and CliAI writes the command. Install it in one line.