DNS Tools & Guides

A wrong MX record breaks email. A missing CAA record lets unauthorised CAs issue certificates for your domain. A TTL that's too high turns a five-minute config change into a six-hour outage. Most "the site is down" tickets that turn out not to be infrastructure problems are DNS problems — and the symptoms rarely point to DNS directly. What follows is the operator-level reference for understanding the system, plus the tool on this site for every check.

Test your DNS

One tool per check. Start with whichever issue you're investigating; each card explains what the tool does and when to reach for it.

How DNS resolution works

Every name lookup on the internet follows the same four-step dance. Your application calls the OS's resolver, which forwards to a recursive resolver — usually your ISP's, or a public one like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). The recursive resolver doesn't know the answer either, but it knows how to find it.

It starts at the root nameservers, which know which servers are authoritative for each top-level domain. For example.com the root returns the addresses of the .com TLD servers. The resolver asks the TLD servers next, and they return the nameservers responsible for example.com itself — the authoritative nameservers. The resolver asks those, gets the actual A record, caches it, and hands it back to your app. The whole exchange typically completes in under 50 ms on a warm cache, more like 200 ms on a cold one.

Every record carries a TTL (time-to-live) telling caches how long to hold it. A 300-second TTL means a five-minute cache; a 86 400-second TTL means a one-day cache. Lower TTL gives you faster propagation but more lookup overhead; higher TTL gives you better cache hit rate but slower change rollouts. There's no universally correct value — the right answer depends on how often you change the record.

Most modern resolution uses DNS over HTTPS (DoH) or DNS over TLS (DoT) for the recursive step. Both encrypt the query between your device and the resolver, hiding the lookup from anyone on the network in between — including your ISP. Cloudflare exposes both at 1.1.1.1, Google at 8.8.8.8; major browsers default to one of these now. Encrypted DNS doesn't change what the authoritative server returns, only who can see the question — but that's a meaningful privacy win.

The record types you'll actually see

DNS hosts dozens of record types but the working set is small. The DNS Records Lookup queries every type below in parallel against Cloudflare DoH.

Why DNS changes take time to propagate

"DNS propagation" isn't really a thing — there's no system pushing updates outward. What's actually happening is that caches expire. When you change a record, the new value is live immediately on your authoritative nameserver, but every recursive resolver on the internet is still holding the old answer for as long as its remaining TTL says to.

Worse, some recursive resolvers ignore the TTL and apply their own minimum (Comcast and Verizon are historically the worst offenders, often holding records for hours regardless of declared TTL). And some clients have OS-level or browser-level caches on top of that. So a five-minute TTL can practically mean five minutes for most users and forty-five minutes for some.

The right way to manage a planned change is to lower the TTL well in advance — at least double the current TTL before the cutover, ideally more — wait for the old, higher TTL to expire everywhere, then make the change. The DNS Propagation tool queries the name from a dozen public resolvers worldwide simultaneously so you can see exactly which regions have picked up the update and which are still cached.

The opposite problem matters too: negative caching. When a resolver gets back NXDOMAIN (the name doesn't exist), it caches that too — for as long as the SOA's minimum field says. If you create a record on a name that was previously queried as non-existent, the negative cache can linger longer than you expect. The SOA's minimum field is often set to several hours by default; the DNS Records tool shows the SOA so you can see what you're up against.

Three common scenarios make propagation visible: domain migration (changing NS records, where the old delegation lingers because TLD-cache TTLs are large), email-provider switching (changing MX records, with end-user mail clients caching aggressively), and CDN onboarding (changing A or CNAME records that previously had long TTLs). In each case the playbook is the same: lower the TTL early, watch propagation, then make the cutover.

Securing DNS

DNSSEC — signing the answers

DNS as originally designed has no authentication. An attacker who controls the network between you and your resolver — or an attacker who poisons a resolver's cache — can return whatever IP they want for yourbank.com, and your browser will happily connect. DNSSEC closes the gap by attaching cryptographic signatures to every record.

The chain of trust starts at the root, which has a public key shipped with every DNSSEC-aware resolver. The root signs the DS (delegation signer) record for each TLD, which in turn signs the DS records for each domain inside that TLD, which finally sign the actual records inside your zone using DNSKEY + RRSIG records. A resolver that validates DNSSEC walks the chain from root downward; if any signature is missing, expired, or mis-signed, the resolver returns SERVFAIL and the lookup fails.

DNSSEC adoption is rising but still incomplete — many zones don't sign at all, and a few bad rollouts have made operators cautious. Validate yours, or anyone else's, with the DNSSEC Validator. The tool walks the chain root → TLD → domain and reports which step breaks if any does.

The reason adoption stalled is operational risk. A DNSSEC-signed zone with a misconfigured key or expired signature stops resolving everywhere that validates — and most public resolvers do. Compare to a non-signed zone, where the worst case is a man-in-the-middle hijacking a single response. Many operators decide the risk of self-inflicted outage outweighs the privacy benefit, particularly for zones that don't carry high-value records. The reasonable middle ground is to sign apex and important subdomains while monitoring expiry timestamps tightly.

CAA records — who's allowed to issue your certs

Before CAA existed, any publicly trusted certificate authority could issue a certificate for any domain — and many did, occasionally by mistake. Certificate Authority Authorization (RFC 8659) is a DNS record that names the CAs you authorise to issue for your domain. Every modern CA must check the CAA record before issuing and refuse if it's not listed.

A CAA record looks like 0 issue "letsencrypt.org". The issue tag covers standard certs, issuewild separately covers wildcards, and iodef declares where misissuance attempts should be reported. CAA also walks up the DNS tree — if app.example.com doesn't have a CAA record, the CA checks example.com, and so on to the apex. That means publishing one record at the apex covers the whole tree. Check yours with the CAA Record Lookup.

Certificate Transparency — public logs of every cert issued

Every publicly trusted certificate issued in the last several years has been logged to one or more public Certificate Transparency logs. Browsers refuse to trust certs that aren't logged. The upside for domain owners: you can search the logs to find every certificate ever issued for your domain — including any you didn't authorise, plus a complete map of every subdomain a CA has seen.

That makes CT a powerful misissuance detector and a surprisingly good reconnaissance tool. If a certificate appears for internal-staging.yourdomain.com that nobody on your team requested, something's wrong. Search the logs with the CT Log Search.

Testing for DNS leaks behind a VPN? That moved to the Privacy & Detection hub, alongside WebRTC leak testing, VPN/proxy detection, and browser fingerprinting — the cluster of tools concerned with what your connection exposes rather than how DNS is configured.

Domain ownership and WHOIS

Behind every domain is a registration record — registrar, creation date, expiry date, nameservers, and (sometimes) the registrant organisation. Historically you queried this with the whois command-line tool, which spoke a 30-year-old plaintext protocol with no structure or consistency. Modern lookups use RDAP (Registration Data Access Protocol, RFC 7480) — same data, served as JSON over HTTPS, with consistent fields and proper authorisation. RDAP is now the canonical interface; WHOIS is being phased out.

What you actually get back depends on the TLD and the registrar. GDPR has redacted most registrant contact details on European-affiliated domains since 2018; the registrar's contact is shown instead. The non-personal fields — creation/expiry dates, nameservers, registrar identity — are still public everywhere. The WHOIS & reverse DNS tool uses RDAP when available, falls back to legacy WHOIS otherwise, and surfaces the dates and nameservers up front.

The same tool also handles reverse DNS. PTR records map an IP back to a hostname (8.8.8.8 → dns.google), which mail-receiving servers use as a basic sanity check on sending hosts. If a sending IP has no PTR — or its PTR doesn't forward-resolve back to the same IP — many receivers downgrade the reputation of the message. Reverse zones are also how bot operators (Google, Bing) verify themselves: take a claimed bot IP, do a PTR lookup, check the result is in the expected domain, then forward-resolve the hostname and confirm it points back to the same IP.

Common DNS problems and fixes

"DNS_PROBE_FINISHED_NXDOMAIN"

The domain didn't resolve. Check, in order: is the domain actually registered (or did the registration lapse — expired domains can stop resolving overnight)? Are the NS records at the TLD pointing to the right authoritative servers? Are those servers actually responding with the zone? Use the DNS Records tool to query the NS records and walk the delegation, and WHOIS to confirm the registration is current.

"MX record not found" — email is bouncing

Either there's no MX record at the domain (some receivers fall back to the A record but most don't), or the MX record points to a hostname that doesn't resolve, or the priorities are inverted. The DNS Records tool queries MX and shows every record with its priority. Pair it with the Email Security hub for the broader picture.

"DNS propagation is slow"

Almost always: the previous TTL was too high. A 24-hour TTL means a 24-hour change. The DNS Propagation tool shows which resolvers are still cached; those will return the old answer until their cache expires. Plan ahead next time by lowering the TTL well before any change.

"CAA record preventing certificate issuance"

Let's Encrypt (or any other CA) refuses to issue because the CAA record doesn't list it. Either add the CA to the CAA record (0 issue "letsencrypt.org"), or — if the record was published recently — wait for the eight-hour CAA cache at the CA to expire. Check the current record with the CAA Record Lookup.

"DNSSEC validation failure"

Validators are returning SERVFAIL. The most common cause is an expired RRSIG (signatures are time-bounded and need periodic refresh — most operators automate this, but the automation occasionally fails). The second most common is a DS-record mismatch after a key rotation: the registrar still holds the old DS while the zone has rotated to a new DNSKEY. The DNSSEC Validator reports which step in the chain breaks and what the expected vs actual values are.

"DNS query timeout"

Resolution is silently failing or hanging. Usually one of: the recursive resolver is unreachable (network or firewall issue), the authoritative nameservers aren't responding (DDoS, misconfiguration, or the zone's NS records are pointing at hosts that no longer run a DNS server), or a middlebox along the path is intercepting and corrupting DNS traffic. Test the resolver directly with the DNS Records tool — if it works there but not in your environment, the problem is local. If it doesn't work anywhere, the authoritative side has a problem.

"DNSSEC working today, broken tomorrow"

The most common cause is RRSIG expiry — signatures are valid for a finite window (typically 14-30 days) and need re-signing on a schedule. If your provider's automation pauses, signatures eventually expire and validation breaks all at once across every record in the zone. Set up monitoring on the next-expiry-date and alert before the deadline. The DNSSEC tool reports the soonest expiring signature.

Learn more

The deep-dive posts below cover the protocol details, history, and the operational gotchas that surface in real deployments.