---
title: Free DNS Lookup
description: Resolve A, AAAA, MX, TXT, NS, SOA, CNAME, PTR, CAA, SRV records for any domain.
canonical: https://watchfor.io/dns-checker
---

[Back to all free tools](/free-tools)

# DNS Lookup

Resolve A, AAAA, MX, TXT, NS, SOA, CNAME, PTR, CAA, SRV records for any domain.

[How to use this tool](/blog/how-to-check-dns-records)

Result

No result yet

Fill in the form above and run it — the result appears here.

Monitor this 24/7 — get alerted when a failure is confirmed.

[Start free](/auth/sign-up)

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](/legal/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 ) from a probe on the public internet and shows the records that came back and how long the lookup took. Ask the probe's own resolver, a public resolver from the list, or any public IP you type — including a domain's authoritative nameserver, which shows a change before any cache has expired. For SOA , CAA , SRV , PTR , TLSA , HTTPS and SVCB each record also carries the TTL the resolver returned; A , AAAA , MX , TXT , NS and CNAME show the values only.

## How it works

Every query you submit goes through the same path a real DNS client would take:

- 1 Encode 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.
- 2 Send to the chosen resolver — By default (Auto) the probe's own recursive resolver answers. Pick a public resolver from the list (Cloudflare 1.1.1.1 , Google 8.8.8.8 , Quad9 9.9.9.9 and others), or type any public IP — a customer's resolver, a specific authoritative nameserver. Private and internal addresses are refused: the query runs from the public internet.
- 3 Parse the response — The records in the answer section, plus a status badge: NOERROR when the query got an answer, NXDOMAIN when an A , AAAA , MX , TXT , NS or CNAME lookup found nothing, TIMEOUT when the resolver didn't answer in time, ERROR for anything else. Authority and additional sections aren't shown.
- 4 Report it back unmodified — Each record's fields, the elapsed query time, and the resolver address when you picked one. For SOA, CAA, SRV, PTR, TLSA, HTTPS and SVCB every record also shows the TTL the resolver returned — the resolver's remaining TTL, not the authoritative one.

Nothing is filtered out; MX records are sorted by priority, and a TXT record made of several strings is shown joined. Where a TTL is shown, read it as cache time left: a CAA record at 47 when the zone sets 3600 means the resolver answered from cache and will re-fetch in 47 seconds.

## 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)

In real DNS, NXDOMAIN means the name doesn't exist at all, while a name that exists without the type you asked for is NOERROR with an empty answer. This tool can't always tell those apart yet. For A , AAAA , MX , TXT , NS and CNAME it shows NXDOMAIN for both, so NXDOMAIN on an AAAA lookup may just mean the name has no IPv6 address — run an A lookup on the same name to see whether it exists. For SOA, CAA, SRV, PTR, TLSA, HTTPS and SVCB any answer shows NOERROR , so zero records there can also mean the name doesn't exist. TIMEOUT means the resolver didn't answer in time; ERROR covers SERVFAIL , REFUSED and other failures; the message under the badge says which.

### Answer records

Each row shows the record type and its data. For SOA, CAA, SRV, PTR, TLSA, HTTPS and SVCB it also shows the TTL, in seconds: how long the resolver will continue serving this cached answer (for the other types, dig prints it). 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; this tool shows them already joined, so a long SPF record or DKIM key appears as one value. dig shows the original string boundaries.

## Common pitfalls

### "My record isn't updating"

Look at the resolver's TTL (shown here for SOA, CAA, SRV and PTR; for A, MX, TXT and the rest, dig <name> <type> @1.1.1.1 +noall +answer prints it). 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, look up the A record of one, and put that IP in the Custom IP field).

### Looking up TXT and getting a CNAME

If the name is a CNAME, the resolver follows it and returns the TXT records of the target, and this tool shows them without the alias. A TXT you can't find in your own zone may live at the CNAME target; a CNAME lookup on the same name shows where it points.

### 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 alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 monitors. No card.

[Start free](/auth/sign-up)

## Frequently asked questions

How is this different from dig or nslookup ? It's the same operation — UDP/TCP lookup over port 53 — just with a web UI and a shareable result link. If you're comfortable in a terminal, 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? For the record types that show a TTL here (SOA, CAA, SRV, PTR, TLSA, HTTPS, SVCB), the resolver returns its remaining cache TTL, which counts down. Run the query at T=0 and you might see TTL=300. Run it at T=47s and you'll see TTL=253. When TTL hits 0, the resolver re-fetches from authoritative on the next query and the cycle restarts.

Can I check what the authoritative nameservers return, not the resolver? Yes — first run an NS lookup to find the authoritative servers for the domain, look up the A record of one of them, then run your real query with that IP in the Custom IP resolver field. That bypasses all caching and gives you the canonical answer.

Why does my CAA lookup return no records? Because CAA is optional, and most domains don't have one. CAA tells certificate authorities which CAs are allowed to issue certs for your domain. No CAA record = any CA can issue. Adding one is a security hardening best practice but it's not common.

What's the difference between A, AAAA, and HTTPS records? A is the IPv4 address, AAAA is IPv6. HTTPS (record type 65) is a newer record type — RFC 9460 — that bundles connection hints (HTTPS-only signal, ALPN, IP hints, ECH config) into one lookup, saving roundtrips during TLS handshake. Most modern browsers query HTTPS records first; if absent, they fall back to A/AAAA.

Does this tool support DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT)? Not in the public version. The query runs as classic UDP/TCP DNS over port 53. If you need to verify DoH behavior specifically (for instance debugging Firefox DoH or NextDNS configuration), the underlying behavior is the same but the transport differs — most "is my DNS working" questions don't depend on transport.

Why am I seeing different IPs in different lookups for the same domain? Three usual suspects: multi-A round-robin (DNS server returns IPs in different order to spread load), GeoDNS (the authoritative nameserver returns different IPs depending on which resolver IP queried it — usually for CDNs), or anycast resolvers (your query landed on a different resolver instance with a different cache state).

How accurate is the lookup duration for tracking DNS performance? The duration we report is the round-trip from our prober to the resolver plus the resolver's own lookup time. It's a useful approximation but it's not what your end users will see — they query a closer resolver (their ISP's), with a different cache state, often over a different transport. Use it for trend monitoring, not for SLA reporting.

## Related dns tools

- [DNS PropagationCheck how a DNS record looks from every prober region simultaneously — spot stale anycast nodes and propagation gaps on a world map — plus an A+ to F DNS health grade for the zone: nameservers, delegation, DNSSEC and CAA.](/dns-propagation-checker)
- [Whois LookupModern RDAP-based domain registration lookup: registrar, expiry, nameservers, status flags.](/whois-lookup)
- [DNS Health CheckerGrade a domain's DNS A+ to F: how many nameservers it has and on which networks, lame delegation, whether the registry and the zone agree, SOA serials, DNSSEC and CAA, with the fix for every problem. Then see what every probe location answers, on a map.](/dns-health-checker)
- [A Record LookupFind the IPv4 address a domain resolves to — every A record, from the resolver of your choice. Spot a stale IP after a migration, a missing record behind a 'site can't be reached', or a round-robin set that is one address short.](/a-record-lookup)

---

Canonical page: https://watchfor.io/dns-checker · Site guide: https://watchfor.io/llms.txt