DNS Lookup
Resolve A, AAAA, MX, TXT, NS, SOA, CNAME, PTR, CAA, SRV records for any domain.
No result yet
Enter the inputs above and press Run. Results appear here in a moment.
Monitor this 24/7 — get alerts on the first failure.
Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.
What is DNS Lookup?
DNS lookup is the silent step every connection makes before anything else happens. Your browser asks "what's the IP for example.com?", a resolver answers, and only then does the actual HTTP request start. When the lookup is wrong — wrong IP, expired record, missing TXT — the failure shows up far away from DNS. Email bounces three days later. A new region returns 404s only for users in São Paulo. Cert renewal fails because Let's Encrypt can't read the DNS-01 challenge you swore you'd added.
This tool resolves any DNS record (A, AAAA, MX, TXT, NS, SOA, CNAME, PTR, CAA, SRV, TLSA, HTTPS, SVCB) against the resolver of your choice and shows you exactly what it got back — the same view your application would have if it ran the lookup right now. No browser-cached results, no stale public DNS resolver lying about TTLs, no opaque "DNS error" message that doesn't tell you whether the record is wrong or just slow to propagate.
How it works
Every query you submit goes through the same path a real DNS client would take:
- 1Encode the query — as a UDP packet (or TCP if the response is large) following RFC 1035 — question section with the QNAME, QTYPE, QCLASS=IN, recursion-desired flag set.
- 2Send to the chosen resolver — By default we use a regional public resolver (Cloudflare
1.1.1.1, Google8.8.8.8, Quad99.9.9.9). You can override with any IP — your own internal resolver, a customer's, a specific authoritative nameserver. - 3Parse the response — Status code (RCODE:
NOERROR,NXDOMAIN,SERVFAIL,REFUSED), answer section with the actual records, authority and additional sections when relevant. - 4Report it back unmodified — You see the raw rdata, the TTL the resolver returned (which is the resolver's remaining TTL, not the authoritative one — important distinction), the elapsed query time, and which resolver gave the answer.
We don't transform or "helpfully normalise" anything — if the resolver returned 1.2.3.4 with TTL 47, that's what you see. Reading TTL as 47 instead of 300 tells you the resolver answered from cache and the record has 47 seconds left before it'll re-fetch from authoritative.
When you'd use it
Post-deploy verification
You just changed an A record from the old origin to the new CDN. The deploy pipeline says "✓ DNS updated." Run the lookup against three or four different resolvers — your own, 1.1.1.1, 8.8.8.8 — and confirm they all see the new value. They almost certainly don't yet. Now you know how long to wait before flipping traffic.
Email deliverability triage
A customer says "your emails aren't arriving." Look up their domain's MX, SPF (in the TXT record), DMARC (_dmarc.example.com TXT), DKIM (selector._domainkey.example.com TXT). One of those is almost always missing or malformed — wrong selector, syntax error in SPF, p=none DMARC.
Certificate issuance
Let's Encrypt's DNS-01 challenge requires a TXT record at _acme-challenge.example.com. If issuance fails, the actual error is usually "we couldn't find the TXT record." Look it up here against several resolvers — if your own resolver sees it but 1.1.1.1 doesn't, you have a propagation problem, not a record problem.
Mysterious 404s for some users
New region, new origin, traffic mostly works — except a handful of users get 404s. PTR lookup their IPs to see which ISP they're on, A lookup your domain against that ISP's known resolver, confirm whether they're seeing the old or new value.
Domain audit before transfer
Moving a domain between registrars. NS lookup current authoritative servers, SOA to verify the serial number you expect, MX to make sure nothing weird is delegated. Catches the records someone added five years ago that you forgot existed.
Reading the result
Status (RCODE)
NOERROR means the lookup succeeded — but doesn't mean there's data. A successful lookup for MX example.com with zero answers is NOERROR with empty answer section. NXDOMAIN means the name doesn't exist anywhere in DNS (not "doesn't exist for this record type"). SERVFAIL means the resolver couldn't get a clean answer from authoritative — DNSSEC validation failure, broken zone, upstream timeout. REFUSED means the resolver won't answer (your IP isn't allowed, or you queried a stub resolver for a recursive lookup).
Answer records
Each record has a name, type, TTL, and rdata. TTL is in seconds and represents how long the resolver will continue serving this cached answer. A short TTL on a freshly-cached record (say 47s on an A record where the authoritative TTL is 300s) means most of the cached lifetime has elapsed — most other resolvers worldwide are about to re-fetch. A long TTL (close to the authoritative max) means this record was just refreshed.
Lookup duration
Sub-50ms typically means the answer came from the resolver's cache — it didn't have to walk the DNS hierarchy. 200-500ms means cold cache, full recursive resolution. >1s usually means an unhealthy authoritative nameserver, or a DNSSEC validation chain that timed out somewhere.
Multiple answers for one query
A records for popular sites usually return multiple IPs for load balancing — clients pick one at random. MX records always come with priority numbers; lower number = higher priority. TXT records can be split into multiple strings of up to 255 chars each that the application concatenates — when you see "v=spf1 ..." "include:..." as separate strings, that's one logical SPF record.
Common pitfalls
"My record isn't updating"
Look at the resolver's TTL. If it's 47 seconds, the cached entry will refresh in 47 seconds — not the moment you updated the authoritative record. There's no way to force a public resolver to evict a specific cache entry. The only way to verify "did my change actually deploy" is to query the authoritative nameservers directly (use NS lookup to find them, then point the resolver field at one).
Looking up TXT and getting a CNAME
Some DNS providers serve CNAME records that point elsewhere for what looks like a direct TXT lookup. Your TXT will be at the CNAME target, not the original name. Chase the CNAME chain — that's usually 5-10 ms of additional resolution and the answer reveals itself.
PTR records that don't reverse cleanly
PTR lookups expect IPs in reverse format (4.3.2.1.in-addr.arpa for IPv4 1.2.3.4) — most tools transform this automatically. The thing to know is that PTR records live in the ISP's reverse DNS zone, not your zone. You can't add a PTR record for a public IP without your ISP/cloud provider's cooperation.
Resolvers that lie
Some ISP resolvers inject ads, redirect NXDOMAIN to a search page, or "helpfully" filter records they don't like. If your result looks weird, try the same query against 1.1.1.1 and 8.8.8.8. If those agree and the ISP resolver disagrees, the ISP resolver is the problem.
Run DNS Lookup on every change, not just once.
Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.
Start freeFrequently asked questions
How is this different from dig or nslookup?
dig +short A example.com @1.1.1.1 does the same thing. The tool's value is when you want to share the result with a colleague or rerun the same query later without remembering the syntax.Why does my TTL keep changing every time I run the query?
Can I check what the authoritative nameservers return, not the resolver?
NS lookup to find the authoritative servers for the domain, then run your real query with one of those NS IPs in the resolver field. That bypasses all caching and gives you the canonical answer.