DNS Lookup

A DNS lookup is the first move in half of all infrastructure debugging: is the record there, what does it say, and how long will caches hold it. This tool runs the same query dig would, from your browser over DNS-over-HTTPS, against a public resolver you pick. This page explains what the answers mean, how the tool maps to dig and nslookup, and where lookups usually mislead people.

What this lookup queries

You type a name, pick a record type and a resolver, and press Enter. The browser sends one DNS-over-HTTPS request straight to that resolver, the same protocol Firefox and Chrome use for their own secure DNS. There is no backend relaying the query, so nothing you look up passes through a devholster server, and the response time shown is measured from your connection, not from a data center somewhere else.

Nine record types are covered: A, AAAA, CNAME, MX, TXT, NS, SOA, CAA and PTR. That last one has a small convenience built in: paste an IP address instead of a domain and the tool builds the reverse name (4.4.8.8.in-addr.arpa for 8.8.8.8) and queries PTR automatically. For the full reverse-DNS treatment, including the forward-confirmation check, use the reverse DNS lookup.

Internationalised names work as you would type them: bücher.example is converted to its punycode form (xn--bcher-kva.example) before the query, and the note under the input shows exactly what was asked. A pasted URL is stripped down to its hostname, so copying an address bar straight in is fine.

Reading the answer

Every record in the answer gets one row: the type, the value, and the TTL twice, once human-readable and once raw in seconds, because "2h" is easier to reason about and "7189" is what you paste into a ticket. The TTL you see is the remaining cache lifetime at this resolver, not necessarily the value configured in the zone.

That difference powers the cache hint in the findings. A TTL of 300 on the dot is usually a record the resolver just fetched from the authoritative server, so the answer is as current as it gets. A TTL of 287 is mid-countdown: the resolver cached the record 13 seconds ago, or 4 minutes and 47 seconds before the zone value expires, depending on how you look at it. Run the same query twice and a cached answer visibly counts down. The tool labels this a hint rather than a fact, because a zone TTL can land on an odd number and a cached answer can be caught at a round one, but in practice it answers the common question of whether you are looking at fresh data.

Under the records, the findings apply the checks worth automating: NXDOMAIN against NODATA (they look similar and mean different things, see the FAQ), CNAME chains resolved hop by hop, round-robin address sets, and the zone serial when you query SOA. The stats bar keeps the measured response time, the record count, the RCODE and the answering resolver in view.

The URL updates with every query, so the address bar always holds a link that reruns exactly this lookup, record type and resolver included. The copy-link button puts it on the clipboard for handing to a teammate.

The record types

Conspicuously absent: ANY. It used to be the lazy way to see everything at once, and it never really was that, because a recursive resolver only returns what it happens to have cached. Since RFC 8482 servers may answer ANY with a minimal reply, and the big providers do. Query the types individually; it is the only way to get a truthful picture.

The same query in dig and nslookup

Every lookup here shows its terminal twin next to the input, ready to copy. That is deliberate: an online lookup is the fast first check, but the moment you script something or SSH into a box, you want the command form. The mapping is mechanical:

The flags worth knowing: +noall +answer silences everything except the answer section, +short prints bare values for scripting, and +trace walks the delegation from the root down, which is the dig feature no browser tool can replicate, since it needs raw port-53 access. On Windows without the BIND tools, PowerShell's Resolve-DnsName is the closest thing to dig and returns objects you can filter.

One honest limitation of any in-browser lookup: a browser cannot open port 53, so classic DNS servers without DNS-over-HTTPS, including your ISP's resolver and most corporate ones, are out of reach. What your local network resolves to can differ from what a public resolver says, and comparing the two (this tool for the public view, dig without @ for the local one) is itself a useful debugging move.

CNAME chains, hop by hop

Query A or AAAA for a name that is an alias and the resolver follows the CNAME for you, returning the whole chain in one answer. Most lookup tools flatten that away and show only the final address, which hides the part you usually need to see. This one lists every hop in the findings: www.example.com → example.cdn-provider.net → lb-4.cdn-provider.net, ending in the address records the final name carries.

Chains matter in three situations. During a migration, the chain shows which alias still points at the old target. When a CDN is involved, the chain is where their machinery becomes visible, and a missing final A record means the CDN hostname itself is broken, not your DNS. And when the chain gets long, every hop is one more lookup on a cold cache and one more thing that can fail; the tool flags four or more hops. Our experience: two hops is the normal CDN setup, three happens after an acquisition, and anything beyond that is usually an accident nobody remembers making.

A related trap is querying CNAME directly and reading an empty answer as "no alias": a NODATA response to a CNAME query just means the name is not an alias, it says nothing about whether A records exist. Query the type you actually care about and let the chain reporting do its work.

Whose answer you are seeing

The resolver picker is not decoration. A recursive resolver answers from its cache when it can, so two resolvers can legitimately disagree while a change spreads: Cloudflare may already serve your new address while DNS.SB still holds the old one for another TTL's worth of seconds. Flipping the resolver on the same query is the quickest way to see whether a "wrong" answer is a zone problem or just a cache that has not expired.

Six networks are available: Cloudflare, Google, DNS.SB, AliDNS, Control D and IIJ. Four answer over the DoH JSON API, two over RFC 8484 wireformat, decoded in this tab. AliDNS is the interesting outlier, because it shows how a name resolves from within China's networks, which for some domains is a materially different answer. Running the same query against two or three of them in a row is the poor man's propagation check: as long as they disagree, someone is still serving a cached copy of the old record.

One resolver quirk surfaces often enough to name: a SERVFAIL from one resolver while another answers fine frequently means DNSSEC validation failed at the strict one, since Cloudflare and Google both validate. The lookup cannot tell you which signature is broken, but the cross-resolver disagreement is the classic symptom worth knowing.

Lookup questions