When Tor Doesn't Protect Your Queries: A Technical Guide to DNS Leaks and How to Test for Them

The mental model most users carry about Tor is straightforward: traffic enters an encrypted tunnel, travels through three relays, and emerges at an exit node before reaching its destination. Under this model, an observer watching the user's local network connection sees only encrypted data addressed to a Tor guard node. What the model frequently omits is DNS — the Domain Name System — and the specific conditions under which DNS queries can bypass the Tor tunnel entirely, transmitting the domains a user is visiting in plaintext to resolvers operated by their ISP or commercial DNS providers.

DNS leakage is not a theoretical concern. It is a documented failure mode that has affected real users running configurations they believed to be secure. Understanding why it occurs, how to detect it, and how to eliminate it is foundational to operating with genuine anonymity on the Tor network.

Why DNS Is Architecturally Different From Other Traffic

When a browser requests a webpage, two distinct operations occur. First, the browser must resolve the domain name — for example, converting example.com into an IP address. Second, the browser connects to that IP address to retrieve the page content. In a correctly configured Tor Browser session, both operations occur within the Tor tunnel: the DNS resolution request is forwarded to the exit node, which performs the lookup on the user's behalf, and the exit node then connects to the resolved IP address. The user's local system never directly contacts a DNS resolver.

The problem arises when other software on the system — or the operating system itself — intercepts or initiates DNS queries through mechanisms that bypass the Tor tunnel. This can occur because DNS resolution is a system-level function that many applications rely on independently of whatever proxy or VPN configuration the user has established for their primary traffic.

Common Misconfiguration Patterns That Produce DNS Leaks

Tor Browser used alongside a system-wide proxy configuration. When users configure a SOCKS proxy at the operating system level and launch Tor Browser within that environment, conflicts between the system proxy settings and Tor Browser's internal proxy configuration can cause DNS resolution to fall back to system-level resolvers. Tor Browser is designed to handle its own DNS routing internally, but misconfigured proxy chains can interrupt this behavior.

Using Tor with a VPN in an incorrect order. A common setup involves routing Tor traffic through a VPN — either Tor-over-VPN or VPN-over-Tor. When these are configured incorrectly, DNS queries may be handled by the VPN client's resolver before the Tor circuit is established, or after the Tor exit in ways that expose the query to the VPN provider's infrastructure. Neither outcome provides the isolation the user intends.

Third-party applications running alongside Tor Browser. On Windows systems in particular, applications including system update services, cloud storage clients, and browser extensions that operate as separate processes may issue DNS queries through the system resolver regardless of Tor Browser's configuration. These queries are not tunneled through Tor and are visible to the user's ISP.

Misconfigured torrc files in manual Tor setups. Users who run the Tor daemon independently — rather than through Tor Browser — and configure applications to use Tor as a SOCKS proxy must ensure that those applications are configured to perform remote DNS resolution rather than local resolution. In SOCKS5, the distinction between SOCKS5 and SOCKS5h protocol specifications controls whether DNS resolution occurs locally or remotely. Applications configured to use SOCKS5 rather than SOCKS5h will resolve DNS locally, bypassing Tor entirely for that step.

IPv6 DNS leaks on dual-stack systems. Systems configured with both IPv4 and IPv6 connectivity may issue DNS queries over IPv6 even when the user's Tor configuration correctly routes IPv4 DNS through the tunnel. Tor does not currently route IPv6 traffic, meaning that IPv6 DNS queries exit the system outside the tunnel. This is a particularly common failure mode on modern home networks where ISPs assign IPv6 prefixes by default.

Step-by-Step Testing Methods

Verifying whether your configuration leaks DNS does not require specialized expertise. The following tests can be performed immediately.

Test one: DNS leak test services. With Tor Browser running, navigate to dnsleaktest.com or ipleak.net. These services prompt your browser to initiate DNS queries through JavaScript and report which resolvers responded. In a correctly configured Tor Browser session, the resolvers listed should correspond to infrastructure associated with Tor exit nodes — not your ISP's resolver or commercial resolvers such as those operated by Google (8.8.8.8) or Cloudflare (1.1.1.1). If your ISP's resolver appears in the results, a leak is present.

Test two: Tor Project's own check page. Navigating to check.torproject.org within Tor Browser confirms whether your connection is recognized as originating from the Tor network. A result indicating you are not using Tor, despite having Tor Browser open, suggests a fundamental routing problem that may include DNS leakage.

Test three: Packet capture analysis. For users comfortable with network analysis tools, running Wireshark or tcpdump on the local network interface while browsing through Tor Browser and filtering for UDP port 53 traffic will reveal any DNS queries leaving the system outside the tunnel. On a correctly configured system, no UDP port 53 traffic should be visible on the local interface during a Tor Browser session.

Test four: IPv6 leak verification. Temporarily disable IPv6 on your system and repeat the DNS leak tests. If the resolvers reported change — particularly if ISP-associated resolvers disappear — you have identified an IPv6 DNS leak. On Windows, IPv6 can be disabled per-adapter through the Network Adapter Properties interface. On Linux systems, adding net.ipv6.conf.all.disable_ipv6 = 1 to /etc/sysctl.conf and applying with sysctl -p achieves the same effect.

Remediation Strategies

For Tor Browser users: The simplest and most effective remediation is to use Tor Browser exclusively for anonymous browsing, without layering additional proxy configurations or VPN clients that interact with the browser's network stack. Tor Browser is specifically engineered to route all DNS through the Tor network; external configurations are the primary source of DNS leaks in this context.

For users running the standalone Tor daemon: Audit every application configured to use Tor as a SOCKS proxy and verify that each is configured for remote DNS resolution. In curl, this means using the --socks5-hostname flag rather than --socks5. In application-level SOCKS configurations, this means specifying socks5h:// as the protocol rather than socks5://.

For IPv6 leaks: Disable IPv6 at the network adapter level on any system where Tor anonymity is a priority. While IPv6 provides legitimate networking benefits, its incompatibility with Tor's routing architecture makes it a consistent source of DNS exposure on dual-stack systems.

For advanced users — DNS-over-Tor via system configuration: On Linux systems using systemd-resolved, it is possible to configure the system resolver to forward all queries through a local Tor-aware DNS proxy such as tor-resolve or a bound instance of dnsmasq configured to forward through the Tor SOCKS port. This approach provides system-wide DNS protection rather than relying on per-application configuration, but requires careful implementation to avoid introducing new failure modes.

The Gap Between Perceived and Actual Anonymity

DNS leakage is instructive precisely because it is invisible to the user who has not specifically tested for it. The browser appears to function normally. Pages load. The Tor circuit indicator shows a connected state. Nothing in the user experience signals that DNS queries are traveling outside the tunnel. This invisibility is what makes the failure mode consequential: users operating under a false sense of security may engage in activities that their actual configuration cannot protect.

Verifying your DNS configuration is not a one-time task. System updates, new application installations, and changes to network environment — particularly moving between networks with different IPv6 configurations — can reintroduce leaks that were previously absent. Periodic retesting using the methods described above is a straightforward practice that meaningfully closes the gap between the anonymity Tor is designed to provide and the anonymity your specific configuration actually delivers.