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.
Reading DNS itself
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.
Judging an address you did not choose
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 fails silently when you exceed the ten DNS lookups RFC 7208 §4.6.4 allows; DKIM (RFC 6376) fails when the selector does not exist or the key is the wrong length; DMARC (RFC 7489) fails when alignment is stricter than the mail you actually send.
The failure each record produces when it is wrong, which is rarely the failure people expect.
| Record | Typical mistake | What you see |
|---|
| SPF |
More than ten DNS lookups once includes are expanded |
A permanent error that many receivers treat as no SPF at all |
| DKIM |
Selector published for one sender, mail sent through another |
Signature missing rather than invalid, which looks like nothing is wrong |
| DMARC |
Strict alignment with a subdomain or third-party sender |
Mail that passes SPF and DKIM and is still rejected |
| MX |
A CNAME where the hostname should be, or a trailing dot missing |
Intermittent delivery depending on the sending server’s tolerance |
The email tester is the one to reach for when the records all look right and mail still does not land. It sends a real message and reports what the receiving side actually concluded, which is the only opinion that matters.
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.
- Cloudflare’s free plan accepts an NS record for a subdomain and never serves the referral. The API returns
success: true, the record appears in the dashboard, and resolvers get NOERROR with the parent SOA. Subdomain delegation is an enterprise feature. Nothing errors, so the delegation simply does not work and you are left debugging your nameserver.
- GoDaddy’s API refuses custom nameserver hostnames that are not registered as host records at the registry, and host record management is not in the public API. It reports “nameserver hostname is not available” even when the hostname resolves correctly.
- 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 queries does not make an authoritative server safe. Mine echoed the question section back in refusals, and a DNS library that decodes compressed names re-encodes them uncompressed. One packet of 180 compressed questions produced a reply 33.9 times its size, aimed at whatever source address was spoofed. The fix is to validate before replying and answer only a single question, never the caller’s list.
The measurement that surprised me
Running the finished test through Google’s public resolver, the probe arrived carrying an EDNS Client Subnet option with my own /24 in it. That is RFC 7871 working exactly as designed: the resolver tells authoritative servers roughly where you are so they can return a nearby answer. It is a performance feature with a privacy cost that almost nobody using a public resolver has been told about, and it is visible to every authoritative server you touch.
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.