DNS Lookup Tool

DNS Lookup Tool

Query any DNS record type against any resolver you choose. Because you pick the resolver, this answers a question a normal lookup cannot: does the answer depend on who you ask?

That distinction matters constantly. A record that resolves correctly against one resolver and fails against another is a propagation, caching or filtering problem — not a problem with the record itself.

The record types and what they are for

  • A and AAAA — the IPv4 and IPv6 addresses a name points to. Most "the site will not load" problems end here.
  • CNAME — an alias pointing at another name. Common in front of CDNs, and a frequent source of confusion because the final answer comes from somewhere else entirely.
  • MX — where mail for the domain should be delivered. Check this first when mail bounces.
  • TXT — arbitrary text, in practice SPF, DKIM, DMARC and domain-ownership verification.
  • NS — the authoritative nameservers for the zone. Worth checking after any registrar or DNS provider change.
  • SOA — zone metadata including serial number and TTLs, useful for confirming a change actually reached the authoritative server.
  • PTR — the reverse mapping from address back to name, covered by the reverse DNS tool.

Why TTL is the field people ignore and shouldn't

Every record carries a time-to-live: how long resolvers may cache it. If you changed a record an hour ago and it still resolves to the old value, the TTL usually explains it — somewhere between you and the authoritative server, a cache is still inside its window.

This is why lowering TTL before a planned migration matters. Dropping it to 300 seconds a day ahead means the change propagates in five minutes rather than the previous TTL, which might have been a day. Doing it after the change is too late; the old long TTL is already cached.

Querying different resolvers, and why the answers differ

Comparing your ISP's resolver against a public one is a fast way to separate "the record is wrong" from "one cache is stale". If the authoritative nameserver returns the new value and your ISP still returns the old one, nothing is broken — you are waiting on a cache.

Answers can also differ legitimately. Many large sites use geographic or latency-based DNS to steer you to a nearby CDN edge, so the address returned genuinely depends on where the query came from. A resolver far from you can therefore land you on a distant node and make everything slightly slower, even though DNS itself resolved quickly.

When the lookup succeeds but the site still fails

DNS resolving correctly only proves the name maps to an address. It says nothing about whether that address is reachable, whether the service is listening, or whether something on the path is blocking it. If the record is right and the site still will not load, the problem is downstream — try a ping to the resolved address, then a traceroute if that fails.

If resolution is slow rather than wrong, or works intermittently, the DNS trace shows which step in the delegation chain is responsible.