What does your DNS resolver tell strangers about you?
Every name you look up passes through a recursive resolver, and that resolver decides how much of it to repeat to the nameservers it asks. Some send only the label they need. Some send the whole thing to every server in the chain, including the root. You can find out which yours does, because the nameserver doing the watching is the one serving this domain.
Written by Ishan Karunaratne, who builds and runs DNS Checker. I am reviewing my own tools here, so treat the praise with the suspicion it deserves and the limitations as the part I had no reason to invent. Published 18 September 2026, and corrected the same day after an independent review found errors in it.
Ask your resolver what it tells strangers about you
Your browser fires a handful of lookups for names under a zone this site is authoritative for. Whatever recursive resolver turns up at that nameserver is, by definition, the one doing your DNS, and everything it discloses on the way in is recorded below. Nothing is stored for more than three minutes and nothing identifies you beyond the resolver addresses themselves.
QNAME minimisation
Every resolver that reached the nameserver, and what it volunteered.
Resolver
Client subnet
DNSSEC
EDNS buffer
Transport
The exact names it asked for
This is the record of what reached the authoritative server. A resolver that sends only the labels it needs at each step tells the nameserver less about you than one that sends the whole name every time.
Why the name of a test is usually a promise it cannot keep
Network diagnostics are named after the worry they address, not the measurement they perform. “Is my VPN leaking?” is a worry. “Which resolver addresses appeared at my authoritative nameserver within four seconds of the probe?” is a measurement. The first sells; the second is what actually happened.
The gap matters because a clean result gets read as a guarantee. A DNS leak test that returns nothing usually means the probe did not arrive, not that nothing leaks. A geolocation result is a routing and registration artefact, not a position report. A blocklist check that finds nothing tells you about the lists it queried and no others.
What follows is each tool paired with its boundary. The boundary is the interesting half.
The closest thing to dig in a browser, and the tool I use most. It resolves the exact name you ask about rather than collapsing it to the apex, which sounds obvious until you try to inspect _dmarc.example.com or a bare subdomain somewhere else and get the parent domain’s records back instead.
It answers from one vantage point, the resolver it happens to use. Someone in São Paulo can get a different answer for the next hour, and nothing here would know. Caches diverge, and anycast means two people querying “the same” nameserver reach different machines.
The answer to the previous tool’s limitation: query many resolvers in different networks at once and compare. Useful in exactly one situation, which is the hour after you change a record and want to know whether the old answer is still in circulation.
The word propagation is doing damage here. Nothing spreads outward; caches expire on whatever TTL each resolver was handed (RFC 2181 §8). And the resolver that matters to you, your own ISP’s, is almost certainly not in the sample.
Rebuilt in September 2026 to run the measurements it had previously only written about. It now performs a DNS leak test against a zone I am authoritative for, a WebRTC probe across four STUN operators, a dual-stack reachability check, and a comparison of your browser’s locale and time zone against the IP’s.
A matching resolver network does not prove your queries went through the tunnel. A VPN can legitimately forward DNS to a public resolver somewhere else, and a large ISP spans several AS numbers. Agreement here is consistent with a working tunnel; it is not evidence of one.
Built for the case where an address is in your logs and you need to decide what to do about it. Geolocation is the least interesting thing it returns. The useful parts are the RDAP registration, the abuse contacts broken out by category, and the reverse DNS checked in both directions, because a PTR with no matching forward record is a claim rather than a fact.
None of it tells you who was at the keyboard. Geolocation resolves to where a network is routed and registered, which for a mobile carrier is often a gateway two states away, and an address with no classification is an address nobody has classified yet.
Queries DNSBL and RBL zones for an address or domain. The thing worth understanding before you act on the result: these lists disagree with each other on purpose. They have different thresholds, different appeal processes, and different opinions about what deserves listing. Spamhaus DROP lists hijacked netblocks; FireHOL Level 1 aggregates attack sources. A listing on one says nothing about the other.
Worth knowing before you act on a clean result: most large mail providers weigh their own internal reputation far above any public list. Whether the server bouncing your mail consults these zones at all is a question this cannot answer.
Lists hostnames observed pointing at an address. Genuinely useful for shared hosting questions and for working out whether an address is a CDN edge.
Not every domain on the address, despite what tools in this category tend to claim. It is a sample from observed zone data over a scan window, and behind a CDN the answer describes the CDN rather than any relationship between the sites sharing it.
Whether your mail will arrive
Email authentication is three records that fail in different ways, which is why checking them separately is worth the clicks. SPF returns permerror once evaluation exceeds ten DNS-querying terms, and nested include and redirect lookups count toward that limit (RFC 7208 §4.6.4). DKIM (RFC 6376) fails verification when the selector’s key cannot be retrieved. DMARC (RFC 7489) fails when neither authenticated domain aligns with the From domain.
The failure each record produces when it is wrong, which is rarely the failure people expect.
An MX target that is an alias, or a relative name expanded under the wrong origin
Delivery failures that look intermittent because different senders resolve it differently
The email tester is the one to reach for when the records all look right and mail still does not land. You send a message to it from your normal mail path and it reports what authentication and spam checks concluded at that receiver. That is one receiver’s opinion, not a guarantee about anyone else’s.
One thing I learned building the DNS leak test
This is the part of the page that is not a review. It cost me three attempts in September 2026 and I have not seen it written down clearly anywhere, so it is here.
To see which resolver serves a visitor, you have to be authoritative for a name. There is no other way: the browser cannot see its resolver, and only the authoritative server for a name is contacted by that resolver directly (RFC 1035). So you delegate a zone and watch who turns up.
My Cloudflare delegation returned the parent SOA instead of a referral, and I still do not know why. The API returned success: true, the NS record appeared in the zone, and resolvers got NOERROR with the parent SOA rather than a referral to my nameserver. I first wrote that subdomain delegation was an enterprise feature. That was wrong, and I had not checked: Cloudflare documents outgoing delegation as available on Free. The failure was real; the explanation was invented. Two things I did not rule out: I tested within a minute of creating the record, and the nameserver I pointed at lived inside the same zone.
GoDaddy’s API rejected every custom nameserver hostname I tried, with “nameserver hostname is not available”, including hostnames that resolved correctly. I could find no public endpoint for registering the registry host records it appears to want. That is what happened on my account with my token, which is not the same as saying it is how the API behaves for everyone.
Route 53 does serve subdomain delegations, and registrars accept AWS nameservers without host registration because they are already registered. Registrar to Route 53 to your own listener is the chain that works.
Refusing ANY did not make my server safe, because the amplification was inside the refusal. It echoed the question section back, and the library I used decodes compressed names and re-encodes them uncompressed. A reviewer reproduced 33.9x expansion against my code using 180 compressed questions in a single packet. I did not measure that figure myself and it depends on the library. What I did measure, after the fix, is that the same attack now draws zero replies. The fix is not “answer the first question” either: RFC 9619 §4 requires FORMERR when QDCOUNT exceeds one, and the reply must never carry the caller’s question list.
The measurement that surprised me
Running the finished test through Google Public DNS, the probe arrived carrying an EDNS Client Subnet option with my IPv4 /24 in it. That is RFC 7871 working as designed: the resolver passes part of your address so authoritative servers can return a nearby answer. Cloudflare and Quad9 sent nothing in the same run. Whether it is sent depends on the resolver’s policy and the destination server, so this is one observation rather than a general rule. Worth knowing the option exists.
Who wrote this, and why it is not neutral
I am Ishan Karunaratne. I build and operate DNS Checker, which means every tool linked above is mine. A review of your own work is worth less than an independent one, and I would rather say so plainly than let the page imply otherwise.
What I think survives that conflict of interest is the second half of each entry. Nobody is incentivised to write down what their own tool cannot do, and those are the parts I would want to read before trusting a result. If you find one of them wrong, tell me and I will correct it here.
This domain also does real work: probe.insidedns.com is the zone the DNS leak test delegates to, which is why it exists at all.