DNS Record Lookup

dig, nslookup, or a Browser Tab?

The traditional way to inspect a domain's records is a terminal: dig example.com MX or nslookup -type=TXT example.com. Both are capable tools, but they assume a terminal is open, the flag syntax is remembered, and the query runs from a machine whose local resolver can be trusted. This page trades some of that raw power for convenience — a query box that hits Cloudflare's public resolver directly, so the answer is identical whether it's run from a locked-down corporate laptop, a phone during an on-call page, or a shared machine where installing anything is out of the question.

The trade-off is real: dig exposes the full wire-format response, including the authority and additional sections, EDNS options, and query round-trip timing, none of which this tool surfaces. For anyone who already lives in a terminal, dig remains the more powerful instrument. This tool exists for the much more common case — "what does this record say right now" — without needing shell access at all.

Wiring a Lookup Into a Deploy Pipeline

The same Cloudflare DoH endpoint this page calls in the browser can be hit from any CI job with a single request: curl -H "accept: application/dns-json" "https://1.1.1.1/dns-query?name=example.com&type=A" returns the identical JSON structure this page renders as a table. Teams running a blue-green cutover or a DNS-based canary release script this as a pre-flight check — the pipeline polls the A record every few seconds until the new IP is visible publicly, rather than proceeding after a fixed sleep timer that might fire before propagation has actually finished. That turns "wait five minutes and hope" into a condition the pipeline can assert against and fail loudly if it's never met.

The same pattern applies before requesting a certificate through an ACME client: query for the CNAME or TXT challenge record the certificate authority expects, and only fire the issuance request once it resolves correctly. Skipping that check burns failed issuance attempts against the CA's rate limit for no benefit.

The Migration Nobody Audited

A common, entirely avoidable incident: a team migrates DNS hosting ahead of a maintenance window. They copy every record visible in the old provider's dashboard into the new one, cut the nameservers over, and move on. Two days later inbound mail starts bouncing. The root cause turns out to be a DKIM TXT record that had been added directly through an API by a marketing automation tool months earlier — it never showed up in anyone's manual migration checklist because nobody thought to look for records that weren't created through the dashboard. By the time it's noticed, the domain's sending reputation has already taken a multi-day hit from failed authentication checks.

The eventual fix is a full record-by-record audit of the old zone — every A, MX, TXT, NS, and CAA entry — cross-checked against what actually got copied to the new provider. Running that audit with a quick lookup tool before decommissioning the old nameservers, rather than after mail starts bouncing, is the five-minute check that would have caught the gap.

Where Engineers Get Tripped Up

• Checking a change the moment it's made: propagation is bound by the record's TTL — an 86400-second TTL can legitimately take up to 24 hours to be visible everywhere, even though Cloudflare's resolver may already show the new value.
• Mistaking a stale local cache for a propagation delay: if a record changed minutes ago and a laptop still shows the old IP, the culprit is usually local OS-level DNS caching, not the internet at large — flushing it (sudo dscacheutil -flushcache on macOS, ipconfig /flushdns on Windows) often resolves it instantly.
• Adding a TXT record to a name that already has a CNAME: a CNAME cannot coexist with any other record type on the same hostname — this is invalid DNS and gets silently rejected or produces unpredictable behaviour depending on the provider.
• Ignoring SPF's evaluation limits: DNS caps TXT strings at 255 characters per string and SPF evaluation caps itself at 10 total DNS lookups — a record with too many include: mechanisms fails validation even though it looks syntactically fine.

Frequently Asked Questions