DNS Lookup
A, AAAA, MX, TXT, NS, CNAME and more, with response times and copy-ready records.
Queries run through the PacketNebula lookup service. We log nothing.
The lookup service is not reachable.
In local preproduction, start it with npm run api then . The rest of the site works without it.
The four lookups that solve most tickets
Mail not arriving? Check MX first: the records must point at your real
mail platform, with sane priorities, and the absence of an MX means mail falls back to
the A record, which is almost never what anyone wants. Site unreachable after a
migration? A and AAAA tell you what the world currently
resolves, and the TTL tells you how long stale answers can persist. Deliverability
problems? TXT holds SPF, DKIM selectors and DMARC policies; a missing
v=spf1 or a stray duplicate SPF record is found in ten seconds here.
Delegation doubts? NS shows who actually answers for the zone, which
after a registrar transfer is sometimes not who you think.
Reading responses like a resolver
The response time next to each record type is the live round-trip for that query from
our lookup service. Single-digit milliseconds usually means the answer came from cache;
tens to hundreds of milliseconds means a recursive walk to the authoritative servers.
CNAME results deserve a special mention: if www is a CNAME, every other
record type for that name is resolved through the target, and putting a CNAME at the
zone apex breaks the
DNS specification
(which is why providers invented ALIAS and ANAME workarounds).
Checking propagation without superstition
"Waiting for propagation" is mostly waiting for caches to expire. The authoritative servers answer with the new value immediately after you publish; everyone else serves the old value until its TTL runs out. So: query right after the change, confirm the new value is live, note the old TTL, and that is your worst-case wait. If a record still shows the old value past TTL expiry, suspect a second copy of the zone or a resolver that ignores TTLs, not magic.
Privacy note
Browsers cannot emit raw DNS packets, so this tool relays your query through the PacketNebula lookup service. The domain is queried and immediately discarded. We keep no history of what anyone looks up.
Frequently asked questions
Why do I see different IP addresses than my colleague?
Plenty of legitimate reasons: CDNs and load balancers answer with addresses close to the resolver asking, DNS round-robin rotates records, and caches at different ages serve different snapshots. If the difference persists across resolvers and TTL expiries, then you might be looking at split-horizon DNS or a hijack worth investigating.
What does TTL mean in the results?
Time to live, in seconds: how long resolvers may cache the record before asking again. A TTL of 300 means changes propagate within five minutes; 86400 means a day. Before migrating a service, lower the TTL a day in advance so the switch is fast, then raise it again.
Why does my domain show no AAAA record?
Because nobody published one, which simply means the site is not reachable over IPv6 directly. It is common and not an error, but with IPv6 adoption past 40% globally per Google's measurements, new deployments should publish both A and AAAA.
What is a CAA record and do I need one?
Certification Authority Authorization: it lists which certificate authorities may issue certificates for your domain. CAs are required to check it since 2017. One record like "0 issue letsencrypt.org" shuts the door on mis-issuance by every other CA, costs nothing, and takes two minutes to add.
Why does the tool need a server when other tools run in the browser?
Browsers cannot send raw DNS queries; pages are limited to HTTP requests. So this tool asks a small PacketNebula service to query the resolver and relay the answer. The domain you type is used for the lookup and discarded; we keep no query history.