How do DNS leaks occur when using Tor and what are common causes?
Executive summary
DNS leaks while using Tor happen when hostname lookups escape the Tor network and go to a local or public DNS resolver; reported causes include browser features or extensions that resolve names locally (for example Brave’s ad‑blocking CNAME checks), misconfigured SOCKS/SOCKS5 usage, or OS/router setups that send DNS outside Tor [1] [2] [3]. Tor Browser and the Tor client normally route DNS resolution through the network, but real‑world leaks have come from third‑party code, application behaviour, or router/OS misconfiguration [4] [5] [6].
1. How DNS resolution is supposed to work inside Tor — and where the boundary lies
Tor clients are designed so applications ask Tor (via SOCKS) to connect to hostnames and the Tor circuit (typically the exit relay) performs the DNS resolution; the client generally does not perform DNS queries itself [5] [4]. The Tor Browser bundle enforces settings (like network.proxy.socks_remote_dns) so DNS lookups are tunneled through Tor, which is why the bundled browser normally avoids leaking visited hostnames to the local resolver [7] [4].
2. Common application-level causes: features, extensions and error-prone components
Applications or browser components that resolve hostnames themselves create the single biggest risk. Examples include browser extensions or ad‑blocking logic that perform DNS queries to decide blocking rules; Brave’s Tor window leaked .onion visits because a CNAME‑based ad‑blocking check issued DNS queries outside Tor, exposing visited hidden services to configured DNS servers and ISPs [1] [8] [2]. Tor Project guidance explicitly warns that even correctly using SOCKS doesn’t prevent leaks if the application resolves names locally [3].
3. Misuse of SOCKS and how it produces leaks
Even when an application is talking to Tor via SOCKS, there are SOCKS variants and usage patterns that can leak DNS. Tor’s diagnostic advice is to enable test modes (TestSocks 1 / SafeSocks) and watch Tor logs: Tor logs "warn" entries for connections that leak DNS and can be configured to disable those unsafe connections [3]. In short: an app must use remote DNS resolution over SOCKS5 and not resolve names itself [3] [5].
4. Router and OS network configurations that force DNS outside Tor
Routing every client through a Tor router is tricky: if the router or clients still send DNS to hardcoded resolvers (ISP, Google, Cloudflare) rather than to Tor’s DNS port, queries will leave the anonymized circuit. Community reports and router forum threads show users observing DNS traffic to public resolvers (8.8.8.8) when a gateway isn’t configured to intercept and redirect DNS into Tor; common mitigation is to redirect DNS to the Tor resolver and block direct DNS egress [6] [9].
5. VPNs, IPv6 and other network-layer pitfalls
VPNs and mixed stacks complicate the picture. Users who chain VPN+Tor or use system‑level DNS overrides can see DNS directed to the VPN provider or local resolvers instead of Tor exits. Tor Stack Exchange and community posts note that VPN clients or OS behaviors (e.g., Windows’ DNS settings) can leak DNS unless configured to block outside DNS or to use the VPN’s DNS properly [7] [5]. Available sources do not mention every modern IPv6-specific leak vector in detail; not found in current reporting.
6. How to detect leaks — what Tor recommends
Tor Project documentation instructs users to monitor Tor logs (TestSocks) where safe vs leaking connections are logged, and to enable SafeSocks to automatically block leaking connections [3]. Community methods include tcpdump on DNS ports and running DNS leak tests from within Tor to confirm the DNS servers seen come from Tor exits rather than local resolvers [6] [7].
7. Practical fixes and trade‑offs
Fixes in the sources cluster around: use Tor Browser (which hardens DNS behavior) rather than ad‑hoc Tor windows in other browsers; disable extensions/features that perform out‑of‑band DNS checks; configure routers to redirect DNS into Tor and block direct DNS egress; and enable Tor’s SafeSocks/testing to detect leaks [3] [1] [6] [7]. Each fix carries trade‑offs: aggressive firewalling or DNS redirection can break services, and relying on third‑party applications always risks future regressions [10].
8. Conflicting perspectives and implicit agendas
Browser vendors other than the Tor Browser (Brave in this case) argued the leak was due to a specific ad‑blocking feature and patched it quickly; security researchers framed the same event as a severe deanonymization risk [1] [8]. Community posts push “lockdown” measures (iptables rules, route‑all‑through‑Tor routers) that increase assurance but add complexity and potential usability problems [10] [6]. Readers should weigh convenience against the higher assurance of a vetted bundle like Tor Browser [7] [4].
Limitations: this summary draws only on the supplied sources and does not cover every possible vector (for example detailed IPv6 routing behavior or post‑2025 research beyond the provided items); available sources do not mention those specifics.