How do operating system DNS settings (like systemd-resolved or DNS cache) create leaks with Tor?
Executive summary
Operating-system DNS services like systemd-resolved, nscd and other system caches can cause DNS queries to bypass Tor’s SOCKS proxy and be sent to local or ISP resolvers, producing the classic “DNS leak” that reveals visited hostnames or timing information (examples of systemd-resolved and nscd leaks are documented) [1] [2]. Separately, Tor’s own DNS behavior — exit-node resolution plus shared exit DNS caches — creates different privacy exposures (timeless timing attacks and cache-probing) that let an adversary learn whether a domain was recently visited through an exit [3] [4].
1. How Tor normally handles DNS — exit-node resolution, not local lookups
Tor clients typically send hostnames through the circuit and let the exit relay perform DNS resolution; the client does not perform normal local recursive DNS queries for web destinations when properly configured [5] [6]. That design prevents straightforward client-side DNS leaks when applications honor SOCKS5 hostname resolution [5] [7].
2. Where the “OS DNS leak” comes from — system resolvers and caches doing their own work
Problems arise when the operating system or other background services (for example systemd-resolved’s stub resolver, nscd, dnsmasq or other caching daemons) independently resolve or refresh DNS entries. systemd-resolved has been reported to send queries over non-Tor interfaces when VPNs are up or when interface routing priorities differ, producing DNS traffic that bypasses the intended privacy tunnel [1] [8]. Similarly, Tor Browser developers and users have documented nscd copying Tor-resolved names into the system cache and later refreshing them via the system nameservers, leaking domain queries to the local resolver [2].
3. Practical leak mechanisms — prefetches, cache refreshes and app behavior
There are multiple concrete mechanisms that produce leaks: an application that resolves hostnames itself (e.g., some browser extensions or non‑SOCKS-aware apps) will query the system DNS instead of Tor [9]; a system cache that stores a Tor-resolved domain then refreshes it periodically to upstream resolvers will turn a safe Tor resolution into an external DNS lookup [2]; and systemd-resolved’s per-interface DNS handling can send lookups to a faster non‑Tor resolver depending on interface ordering, producing leaks visible outside Tor [8] [1].
4. Tor’s internal DNS problems — exit caches and timing attacks
Even when the client-side stack is perfect, Tor’s architecture has DNS privacy risks. Exit relays often perform and cache DNS answers; researchers have demonstrated “timeless timing” attacks that reliably probe whether a domain exists in an exit’s cache, revealing that the domain was requested recently through that exit [3] [10]. The Tor project tracks these weaknesses and maintains issues about exit relay cache behavior and mitigation [4] [11].
5. Real-world examples and incidents
Browsers and apps have shipped leaks: Brave’s Tor window once sent .onion or Tor‑mode queries to public DNS resolvers, leaking visited Tor addresses until fixed [12] [13]. Systemd and VPN interactions have produced persistent community bug reports where DNS queries escape the tunnel [1] [14]. Tor Project issue threads also show active concern about system caches and shared resolvers causing inadvertent leaks [2] [4].
6. How people and projects recommend limiting these leaks
Community and project advice converges on “fail-closed” approaches: ensure applications use SOCKS5 hostname resolution (network.proxy.socks_remote_dns in Firefox/Tor Browser) so Tor resolves names remotely [7]; avoid or disable system-wide DNS caches that refresh via upstream servers (nscd example) or configure them to use Tor’s local resolver only [2]; and, on Linux, integrate VPN scripts with systemd-resolved (update-systemd-resolved helper or openvpn-systemd-resolved) so the correct DNS servers are used per-TUN interface [15] [14]. Tor operator guidance also suggests running local recursive resolvers on exits to reduce external DNS exposure [16] [17].
7. Limitations, trade-offs and remaining risks
Available sources document many leak vectors but do not provide a single universal fix: disabling all caching and forcing every app through SOCKS is brittle and can break functionality; modifying systemd-resolved or nscd settings can be error-prone across distributions [8] [2]. Meanwhile, Tor’s exit-cache mitigations (preload defenses, disabling cache features) are active research topics rather than universally deployed fixes [3] [11]. Available sources do not mention a turnkey OS‑level setting that guarantees no DNS leakage in every environment.
8. Bottom line for users and administrators
If you require strong anonymity: use the Tor Browser bundle (it configures Firefox to remote-resolve hostnames via SOCKS by default) and avoid using the system’s general-purpose apps that perform independent DNS queries [7]. System administrators running Tor exits should consider local recursive resolvers and follow Tor Project recommendations to reduce external DNS traffic [16] [17]. Auditors and paranoid users must watch both OS-level resolvers (systemd-resolved, nscd, dnsmasq) and Tor’s server-side DNS behavior — both are documented sources of leakage [1] [3].
Sources cited above come from Tor Project docs, community bug trackers, Stack Exchange investigations, and USENIX research papers cited in the provided results [9] [7] [1] [3] [2] [4].