Best tools to test for DNS leaks in Tor
Executive summary
For testing DNS leaks when using Tor, the most frequently cited practical checks are specialized online leak sites (IPLeak, DNSLeakTest, DNSleaktest.com), privacy tool suites (Whoer/Whoerip and BrowserLeaks), and network-level inspection with tcpdump or packet filters—each approach catches different failure modes [1] [2] [3] [4] [5]. The Tor Project itself recommends application-level SOCKS diagnostics and log flags (TestSocks/SafeSocks) to detect apps that resolve hostnames outside Tor [6].
1. Why DNS leak testing matters for Tor — a simple, sharp risk picture
DNS queries reveal destinations even when content is hidden; a misconfigured OS, extension, or app can resolve names outside the Tor path and expose where you browse. Multiple guides warn that DNS leaks are common on full OS installs (Windows, Android) and when non‑Tor apps issue queries, so testing is essential before accessing sensitive services [7] [1] [8].
2. Quick, browser‑level checks — what leak test sites find and what they miss
Public leak sites like IPLeak (ipleak.net), DNSLeakTest.com, DNSleaktest.com and BrowserLeaks give immediate evidence of which DNS servers answered recent queries and flag obvious leaks [1] [2] [4]. Whoer’s roundup highlights IPLeak.net as the most exhaustive web‑fronted test for intermittent or subtle leaks because it performs many queries and bundles IP/DNS/WebRTC checks [3]. These sites are indispensable for a fast sanity check but cannot inspect traffic generated outside the browser or prove that a background service won’t leak later [3] [4].
3. Network‑level forensics — tcpdump, packet captures and router inspection
The Tor user community and Stack Exchange recommend monitoring actual DNS packets with tcpdump on the internal interface or the router that routes traffic through Tor. A tcpdump filter for port 53 will show DNS requests leaving the LAN (example output and workflow shown on Tor Stack Exchange), which catches leaks that web pages and online tests cannot see [5] [8]. This method requires network access and analysis skills but is the only way to see leaks from non‑browser apps or intermittent background processes [8].
4. Application and Tor‑internal diagnostics — TestSocks, SafeSocks, and logs
The Tor Project documents an explicit method to detect applications that perform DNS resolution while using SOCKS: enable TestSocks in torrc and watch Tor’s logs. Tor will warn when connections leak DNS; SafeSocks can be set to automatically block those connections [6]. This is a direct, authoritative way to determine whether a particular SOCKS‑using app is resolving names locally rather than through Tor [6].
5. Combining approaches — best practice for a defensible test plan
No single tool is sufficient. Start with an online leak test (IPLeak/DNSLeakTest/Whoer/BrowserLeaks) to catch obvious problems, then run tcpdump or router captures to find non‑browser leaks, and use Tor’s TestSocks/SafeSocks for application‑level confirmation [3] [2] [5] [6]. Community advice also recommends restrictive firewall rules so traffic “fails closed” — this prevents accidental egress when Tor isn’t used [8].
6. What sources disagree on, and what they don’t say
Privacy blogs and guides emphasize user‑friendly web tools and the evolving threat from IPv6/DoH changes in 2025, pushing users toward more frequent testing [3] [7]. Technical sources (Tor Project, Stack Exchange) prioritize packet captures and torrc diagnostics as the definitive checks [6] [5]. Available sources do not mention privately developed closed‑source scanners beyond the public sites listed; they also do not provide a single authoritative “one‑click” test that guarantees no leak for all processes (not found in current reporting).
7. Practical checklist you can run right now
- Run an online DNS/IP leak test: IPLeak, DNSLeakTest.com, DNSleaktest.com, BrowserLeaks [1] [2] [4].
- Capture DNS traffic on the gateway or client with tcpdump (filter port 53) and inspect for servers outside Tor [5].
- Enable TestSocks 1 and monitor Tor logs; set SafeSocks 1 to auto‑block leaking apps [6].
- Harden with firewall rules so non‑Tor egress is blocked [8].
Each step is supported by the cited community or project guidance [5] [6] [8] [3].
Limitations and transparency: online leak checks are necessary but not sufficient; packet captures and Tor’s diagnostics are required to detect leaks from non‑browser apps. Sources used: Tor Project support [6], Tor Stack Exchange troubleshooting and how‑to threads [5] [8], public leak sites and reviews [1] [2] [4] [3], and privacy reporting on Tor risks [7].