DNS Lookup

What it does

Type a domain, pick a record type or leave it on “all”, and get back what the resolver holds: the records themselves, their TTLs, and the DNSSEC AD bit. In “all” mode it fans out across A, AAAA, CNAME, MX, TXT, NS, SOA and CAA in parallel, and adds a TXT query for _dmarc.<domain> because the policy record lives on a different name than the one you typed.

Below the table the tool reads four things back in plain English. MX records are sorted by priority and the null MX form from RFC 7505 is called out rather than shown as a broken host. SPF is checked against the ten-lookup ceiling and its all qualifier is translated, so ~all is named as softfail rather than left as syntax. DMARC reports the policy, the subdomain policy, the sampling percentage and whether aggregate reports go anywhere. CAA lists which authorities may issue, distinguishes issuewild, and flags the critical bit.

How it works

The browser has no DNS API, so the query runs server-side at /api/dns. That edge function speaks to Cloudflare’s resolver using the JSON flavour of DNS-over-HTTPS described in RFC 8484. The reason for the hop is privacy rather than capability: calling a public resolver straight from the page would hand a third party the visitor’s IP address alongside every domain typed into the box. Going through the edge means the resolver sees the function, not the visitor.

Two response quirks are normalised before the answer reaches the page. Resolvers return CAA in the unknown-record presentation form from RFC 3597 — a length followed by hex bytes — so the endpoint decodes the flags byte, the tag length, the tag and the value into the 0 issue "letsencrypt.org" shape that dig prints. TXT arrives quoted and, past 255 bytes, split into several quoted strings that are meant to be concatenated; long DKIM keys and SPF records both hit this. The endpoint joins them so what you see is the string the record actually encodes.

A NXDOMAIN or SERVFAIL reply is a successful query with a bad answer, so those come back as 200 with the RCODE named and any SOA record from the authority section shown — that record is what tells you how long the negative answer will be cached.

Reading the AD bit honestly

The AD flag is the most misread field on this page. It means the resolver validated a DNSSEC signature chain from the root to this answer, per RFC 4035, and that the data matches what the zone owner signed. It does not mean the answer is correct, only that it was not tampered with in transit or forged by a cache.

Its absence is much weaker evidence than people assume. Most zones are still unsigned, and for an unsigned zone the resolver has nothing to validate, so no AD bit is the expected and correct outcome. A missing AD bit is only worth investigating when you know the parent zone publishes a DS record for the domain — then it points at a broken chain, usually a key rollover where the DS was never updated, which will make validating resolvers refuse the answer outright rather than fall back.

One caveat on provenance: the bit reflects Cloudflare’s validation, delivered over the TLS channel DoH gives you. That is not the same as validating locally.

When to reach for it

The common case is a change you just made: confirming that a new A record has propagated to a public resolver, or that a CNAME points where the vendor’s setup guide said it should. The TTL column is the part worth reading, since it tells you how long the previous value can still be served to somebody else.

Before a certificate issuance, check CAA. An empty CAA set means any authority may issue; a populated one that omits your ACME provider is the reason issuance fails with an unhelpful error. Before a mail change, check SPF and DMARC together — a p=reject policy with an SPF record that quietly exceeds ten lookups is a deliverability outage waiting for the next include to grow.

Related tools

• CT log lookup to see which certificates exist for the names you just resolved.
• TLS certificate inspector for the certificate served at the address in the A record.
• Nginx and Caddy config generator when the record points at a proxy you still have to configure.
• Kubernetes YAML linter for the Ingress that claims the hostname.
• HTTP header inspector for what the host returns once DNS is pointing at it.