DNS tools

DNS is a cache hierarchy, not a database

When you “change a DNS record” you edit one zone on one set of authoritative nameservers — and almost nobody reads that zone. Your users’ answers come from recursive resolvers (an ISP’s, 8.8.8.8, a corporate resolver, a browser’s own DoH endpoint), each holding a copy that expires on its own schedule. There is one authoritative answer and N cached approximations of it — plus your own laptop, whose OS cache and /etc/hosts override everything else.

Resolution starts at the root: a cold resolver asks a root server about www.example.com, is referred to the .com nameservers, then to the NS records the registrar published for example.com. Every link in that delegation chain is itself a cached record with its own TTL, and the NS set at the TLD is usually cached 1–2 days — which is why switching DNS providers behaves nothing like changing an A record.

“Propagation” is therefore a misnomer: nothing is pushed, old answers merely expire — including negative ones. NXDOMAIN is cached for the interval derived from the zone’s SOA (commonly 300–3600 s), so a name can look missing for minutes after you create it.

Record types you actually touch

TTL, cutovers, and rollback windows

Pick TTLs by how fast you might need to move: 60 for a record you may repoint within minutes, 300–900 through a migration, 3600 in steady state, 86400 for NS and MX you never touch. Short TTLs are not free — they multiply query volume and shrink the buffer protecting you if authoritative servers go unreachable.

Rollback matters as much as cutover: a cached TTL is a floor on recovery, so a 300 s TTL keeps the last resolvers pointing at a dead endpoint for five minutes after you publish. Two such events a month is ~10 minutes of downtime, and the SLA Uptime Calculator shows whether that fits — 99.99% allows 4.3 minutes per 30-day month. More budgeting on the SRE toolkit page.

What SPF, DKIM, and DMARC each prove

Of the three, only the apex SPF record is readable with the DNS Lookup Tool: its TXT tab shows the v=spf1 string you published, but the tool accepts hostname labels only, so underscore names such as _dmarc.example.com and selector._domainkey.example.com are rejected with Invalid domain format. Read those with dig TXT _dmarc.example.com or from your DNS provider’s zone editor. What a receiver concluded is a separate question, and Email Header Analyzer answers it from the Authentication-Results, Received-SPF, DKIM-Signature and ARC headers of a delivered message. Before adding an ip4: mechanism, confirm the address your traffic really leaves from with IP Address Checker rather than trusting a config file. If a DKIM record was reassembled from chunked strings, paste the p= value into Base64 Encode / Decode: it rejects stray characters and broken padding, catching a mangled key. More on authentication headers: the email hub.

Which tool for which job

Given a domain, the DNS Lookup Tool resolves A, AAAA, CNAME, MX, TXT and NS in one query, printing TYPE / NAME / VALUE / TTL with MX priority; the type tabs filter the fetched rows client-side, so switching between MX and TXT costs no extra query. CNAME has no tab of its own, so those rows — the ones that tell you a name is an alias rather than an address — show up in the ALL view. Read the status bar literally: SERVER is always api.sitekits.dev and LATENCY is the browser→API round trip, neither the recursive resolver that answered nor the DNS query time. Resolution runs server-side over Cloudflare DoH, which is what gives you a vantage point outside your own cache; to pin down which resolver replied, ask one directly with dig @8.8.8.8 example.com. Given a URL instead, URL Parser & Analyzer isolates hostname from host (which includes the port), locally, without fetching.

When the records are right but the wrong content is served, it is no longer DNS: HTTP Headers Checker fetches server-side and returns status, redirect chain and every response header — enough to separate “still the old IP” from “right IP, stale CDN cache”. It never retrieves the body and refuses private addresses.

DNS carries ASCII labels only, so IDN / Punycode Converter shows the xn-- form actually queried, which also unmasks homograph look-alikes. AAAA values that look different often are not: IPv6 Address Compressor normalises both spellings and expands the groups an ip6.arpa name needs. Snapshot a zone before a migration and diff before/after in Text Diff Checker.

Gotchas that cost hours

CNAME at the zone apex

example.com must hold SOA and NS, and CNAME cannot coexist with other records at a name — so apex CNAME is invalid whatever the control panel accepts. ALIAS/ANAME and flattening are provider features, not protocol ones.

Two SPF records instead of one

A second v=spf1 TXT record at the same name produces a permerror. Merge all mechanisms into one record, and count lookups: include:, a, mx, ptr, exists and redirect= each consume one of the 10 DNS lookups an evaluation is allowed (RFC 7208 §4.6.4) — a cap stacked vendor chains blow silently.

Relative names and missing trailing dots

In zone-file syntax a target without a trailing dot is relative, so www.example.com becomes www.example.com.example.com. — exactly what happens when you paste a fully qualified target into a UI that already appends the zone.

Dangling records pointing at reclaimed services

A CNAME still aimed at a decommissioned bucket, app platform or CDN hostname can be claimed by whoever registers that name next, handing an attacker a subdomain of yours — see the security toolkit.