🔍 DNS Record & Nameserver Inspector
Inspect live DNS records, mail exchangers (MX), SPF/TXT records, and nameservers for any domain using Cloudflare DNS-over-HTTPS. 100% free.
What DNS Record & Nameserver Inspector Does
This tool queries the public DNS resolver at Cloudflare over DNS-over-HTTPS and returns the records it holds for a domain — A, AAAA, MX, TXT, CNAME, NS and SOA — with the TTL on each.
It is a resolver view, not an authoritative one, and the distinction decides how you should read the result. An authoritative lookup asks the nameservers that own the domain and always reflects the current configuration. A resolver lookup asks a cache. What comes back is what that cache holds, and the TTL is how many seconds it will keep holding it.
That makes this the right tool for a specific question — what does the internet currently think your domain is — and the wrong one for confirming a change you made two minutes ago. If a record has just been edited, a resolver may keep serving the old value for as long as the previous TTL allows, and no amount of rechecking will change that.
How to Use DNS Record & Nameserver Inspector
- Choose record type (A, AAAA, MX, TXT, CNAME, NS)
- Enter the domain name
- Click Resolve DNS to view live records, TTL values, and IP addresses
Formula Used by DNS Record & Nameserver Inspector
What TTL actually counts
TTL returned = original TTL − seconds since the resolver cached this record
- original TTL
- The lifetime the domain owner set on the record, in seconds
- TTL returned
- Remaining seconds before this resolver discards its copy and asks again
Worked example
Three A-record queries for the same domain through the same resolver, twelve seconds apart.
- Query 1: TTL 134
- Query 2 (+12 s): TTL 12 — counting down toward expiry
- Query 3 (+12 s): TTL 70 — the cache expired and refetched, so the clock restarted
Result: A TTL that rises between two queries is the visible evidence of a cache refresh. It is not an error and not a change to the record; it is one resolver dropping its copy and fetching a new one.
How long a change can take to appear
worst-case visibility delay ≈ the OLD record's TTL
- old TTL
- The TTL in force before the change, because that is what resolvers cached
Worked example
A record with a 3,600-second TTL, edited at noon.
- A resolver that cached it at 11:59 holds the old value until 12:59
- A resolver that cached it at 12:01 gets the new value immediately
- Every resolver in between is somewhere along that hour
Result: Up to one hour of inconsistency, during which different users legitimately get different answers. Lowering the TTL *before* a planned change — to 300 seconds a day ahead — is what shortens this window. Lowering it afterwards does nothing, because the long TTL is already cached.
Record Types This Tool Queries
| Type | What it holds | Typical use |
|---|---|---|
| A | An IPv4 address | Points a name at a server |
| AAAA | An IPv6 address | The IPv6 equivalent, served alongside A |
| MX | Mail exchanger hostname and priority | Where email for the domain is delivered; lower priority number wins |
| TXT | Arbitrary text | SPF, DKIM and DMARC policies, plus domain-ownership verification strings |
| CNAME | An alias to another name | Points one name at another. Cannot coexist with other records at the same name |
| NS | Authoritative nameservers | Which servers are the source of truth for this domain |
| SOA | Start of authority | Zone serial number and the timers governing secondary transfers and negative caching |
Live Demonstration: the Same Query, Three Times
Three A-record lookups for example.com twelve seconds apart through Cloudflare's resolver, 11 September 2026. Two things move that people assume are fixed.
| Query | TTL returned | Address returned |
|---|---|---|
| 1 | 134 | 172.66.147.243 |
| 2 (+12 s) | 12 | 104.20.23.154 |
| 3 (+12 s) | 70 | 172.66.147.243 |
Resolver Lookup Against Authoritative Lookup
The two kinds of DNS answer, and which question each one answers.
| This tool (resolver, via DoH) | An authoritative lookup | |
|---|---|---|
| Who is asked | A public recursive resolver's cache | The domain's own nameservers |
| Reflects a change immediately? | No — bounded by the cached TTL | Yes |
| Shows a TTL countdown? | Yes, and it is meaningful | Returns the configured TTL, which does not count down |
| Answers "what do users see right now?" | Yes, for users of that resolver | No |
| Answers "is my zone configured correctly?" | Only once caches have caught up | Yes |
TTLs Vary Enormously by Record
From the same live session. NS records are deliberately long-lived because nameservers rarely change; address records are kept short so they can be moved.
| Record | Observed TTL | In human terms |
|---|---|---|
| A (example.com) | 134 s | About two minutes |
| NS (example.com) | 78,191 s | About 21.7 hours |
How to Read Your Result
One A record is a snapshot, not an address
The live table above returned two different IP addresses for the same name inside 24 seconds. Nothing was misconfigured. Large sites sit behind anycast and load balancers that hand out different addresses to different queries, sometimes rotating deliberately, sometimes varying by which edge node answered. Treating a single A-record result as "the server's IP" is the most common misreading of a DNS lookup, and it is why a result that differs from a colleague's is usually not evidence of a problem.
Different DNS checkers disagree, and both are right
Run the same domain through this tool and through an authoritative checker during a change window and you will get different answers. That is the system working as designed: DNS is eventually consistent by construction, with caching as the mechanism that makes it scale. The useful habit is knowing which kind of tool you are holding. Configuration problems need an authoritative query; "why do some users still land on the old site" needs a resolver query, and ideally several from different networks.
Lower the TTL before the change, not after
This is the single most useful operational fact about DNS and it is counterintuitive. Resolvers cached the record under its previous TTL, so reducing it at the moment of the change has no effect on anyone already holding a copy. The sequence that works is: drop the TTL to something short a full old-TTL period in advance, make the change, confirm, then raise the TTL again. Skipping the first step is why migrations spend a day half-visible.
A missing record is not always an error
Querying for a type a domain does not use returns nothing, and this tool reports that as "no records found". That is frequently correct rather than broken — plenty of domains have no AAAA record because they are not on IPv6, and a domain that does not send email may legitimately have no MX. The SOA record carries a separate negative-caching timer that governs how long resolvers remember the absence, which is why a newly added record can also take time to appear.
Limitations & Accuracy Notes
- Queries one public resolver, Cloudflare, over DNS-over-HTTPS. It does not query the domain's authoritative nameservers, so it cannot confirm a just-made change and will show stale values for as long as the previous TTL allows.
- One resolver means one vantage point. It cannot show global propagation, which needs the same query run against resolvers on many networks at once.
- Seven record types. No PTR (reverse DNS), SRV, CAA, DS or DNSKEY, and no DNSSEC validation status.
- No email diagnostics beyond raw MX and TXT records — SPF, DKIM and DMARC strings are returned as text but are not parsed or checked for validity.
- No blacklist checks, no SMTP connectivity testing, and no WHOIS or registration data.
- No query history and no comparison between two points in time — the TTL behavior described above has to be observed by running the lookup twice yourself.
- The tool strips a protocol and path from what you type, but it expects a domain. It cannot look up an IP address.
Frequently Asked Questions
What is a DNS Lookup?
What DNS record types are supported?
What is a TTL and why does it matter?
Why do I see a different result than someone else?
What is the difference between an A and a CNAME record?
What are MX records and what does the number mean?
What are TXT records used for?
Why does a lookup return nothing?
References & Further Reading
- RFC 1035 — Domain Names: Implementation and Specification — The core DNS specification: record types, the TTL field, and the caching model that everything above describes
- RFC 8484 — DNS Queries over HTTPS (DoH) — The transport this tool uses to query a resolver from the browser, which is what makes a client-side DNS lookup possible at all
- RFC 2308 — Negative Caching of DNS Queries — How resolvers cache the ABSENCE of a record, and the SOA timer that governs it — the reason a newly created record can take time to appear