DNS Privacy: A Complete Guide to Preventing DNS Leaks and Securing Name Resolution

The Domain Name System is one of the most overlooked privacy vulnerabilities in everyday internet use. Every time you visit a website, send an email, or use virtually any networked application, your device performs a DNS query that translates a human-readable domain name into an IP address. By default, these queries are sent in plaintext over UDP port 53, meaning your Internet Service Provider, network administrator, or any attacker positioned on the network path can see every domain you look up. Even users who employ VPNs or encrypted connections often leak DNS queries that reveal their browsing habits. This guide provides a thorough examination of DNS privacy threats, the protocols designed to address them, recommended privacy-respecting resolvers, and step-by-step configuration instructions for Linux and Windows systems.

Understanding DNS Leaks

A DNS leak occurs when DNS queries bypass your intended privacy protections and are sent to an unintended resolver, typically your ISP's default DNS server. This is one of the most common and dangerous privacy failures because it exposes your complete browsing history to a third party even when all other traffic is encrypted through a VPN or proxy. DNS leaks can occur through several mechanisms that are important to understand in order to properly defend against them.

How DNS Leaks Happen

The most common cause of DNS leaks is misconfigured VPN software that fails to redirect DNS queries through the VPN tunnel. When you connect to a VPN, the VPN client should configure your system to use the VPN provider's DNS servers through the encrypted tunnel. However, many VPN clients fail to properly override the system DNS settings, especially on Linux systems where multiple network management tools may conflict. The operating system may continue sending DNS queries to the ISP-assigned resolver over the unencrypted connection while all other traffic goes through the VPN.

Another source of leaks is the WebRTC protocol built into modern web browsers, which can bypass proxy settings and reveal your real IP address along with DNS information. IPv6 DNS leaks are also common when a VPN only tunnels IPv4 traffic, allowing IPv6 DNS queries to go directly to the ISP. Split-tunnel VPN configurations, where only some traffic goes through the VPN, are particularly prone to DNS leaks because the operating system must decide which DNS server to use for each query.

Smart Multi-Homed Name Resolution (SMHNR), enabled by default on Windows, sends DNS queries to all available network interfaces simultaneously and uses whichever response arrives first. This means that even with a properly configured VPN, Windows may send your DNS queries over the unprotected interface as well. On Linux, similar behavior can occur with systemd-resolved when multiple DNS servers are configured across different network interfaces.

Testing for DNS Leaks

Before configuring privacy-enhancing DNS, you should establish a baseline by testing your current setup for leaks. Several online tools and command-line methods can help. The website dnsleaktest.com performs an extended test that queries multiple unique domains and reports which DNS servers resolved them. If any server belongs to your ISP when you expect all queries to go through a VPN or encrypted resolver, you have a leak.

# Command-line DNS leak test using dig
dig +short whoami.akamai.net @ns1-1.akamaitech.net

# Check which DNS server is being used
dig +short txt o-o.myaddr.l.google.com @ns1.google.com

# Verify DNS traffic is encrypted with tcpdump
# (should show NO traffic on port 53 if properly configured)
sudo tcpdump -i eth0 port 53 -n

# Check systemd-resolved configuration
resolvectl status

DNS over HTTPS (DoH)

DNS over HTTPS (DoH) encrypts DNS queries by wrapping them in standard HTTPS connections on port 443. This makes DNS traffic indistinguishable from regular web traffic, preventing network-level blocking or inspection of DNS queries. DoH is defined in RFC 8484 and has been implemented by all major browsers and operating systems. The dnsprivacy.org project maintains comprehensive information about DNS privacy implementations and deployment.

Advantages of DoH

The primary advantage of DoH is that it uses the same port 443 as regular HTTPS traffic, making it extremely difficult for network administrators or censors to selectively block encrypted DNS without blocking all HTTPS traffic. This censorship resistance is valuable in restrictive network environments. DoH also benefits from the mature TLS ecosystem, including certificate transparency logs and established certificate authorities, which provide strong authentication of the DNS resolver. Additionally, DoH can leverage HTTP/2 connection multiplexing, allowing multiple DNS queries to be sent over a single connection with reduced latency.

Configuring DoH on Linux with systemd-resolved

Modern Linux distributions using systemd version 249 or later support DoH natively through systemd-resolved. Configuration is straightforward:

# /etc/systemd/resolved.conf
[Resolve]
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net
DNS=194.242.2.2#dns.mullvad.net
FallbackDNS=
DNSOverTLS=no
DNSOverHTTPS=yes
DNSSEC=allow-downgrade
Domains=~.

# Restart the service
sudo systemctl restart systemd-resolved

# Verify the configuration
resolvectl status
resolvectl query example.com

The Domains=~. setting is critical because it tells systemd-resolved to route all DNS queries (the root domain "." and all subdomains) through the configured DNS servers. Without this, queries for local domains might be sent to a different resolver.

Configuring DoH with Firefox

Firefox has built-in DoH support that operates independently of the system DNS configuration. This provides encrypted DNS even on systems where you cannot modify the system-level settings:

// In about:config
network.trr.mode = 3          // DoH only, no fallback
network.trr.uri = https://dns.quad9.net/dns-query
network.trr.custom_uri = https://dns.quad9.net/dns-query
network.trr.bootstrapAddr = 9.9.9.9
network.trr.excluded-domains = ""
network.trr.disable-ECS = true

Setting network.trr.mode = 3 forces Firefox to use only DoH, with no fallback to the system DNS resolver. This is the most private setting but means that DNS resolution will fail entirely if the DoH server is unreachable. Mode 2 uses DoH as the primary resolver but falls back to the system DNS if DoH fails, which is more reliable but provides weaker privacy guarantees because fallback queries are unencrypted.

DNS over TLS (DoT)

DNS over TLS (DoT) encrypts DNS queries by wrapping them in a TLS session on a dedicated port, 853. Unlike DoH which blends with HTTPS traffic, DoT uses its own well-known port, which makes it easier to identify and potentially block but also easier to manage from a network administration perspective. DoT is defined in RFC 7858 and is widely supported by privacy-focused DNS resolvers.

Configuring DoT with Stubby

Stubby is a lightweight DNS stub resolver specifically designed for DNS-over-TLS. It runs as a local daemon and forwards all DNS queries over TLS to configured upstream resolvers:

# Install Stubby
sudo apt install stubby    # Debian/Ubuntu
sudo dnf install stubby    # Fedora

# /etc/stubby/stubby.yml
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private: 1
round_robin_upstreams: 1
idle_timeout: 10000
listen_addresses:
  - 127.0.0.1@5353
  - 0::1@5353
upstream_recursive_servers:
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"
    tls_port: 853
  - address_data: 149.112.112.112
    tls_auth_name: "dns.quad9.net"
    tls_port: 853
  - address_data: 194.242.2.2
    tls_auth_name: "dns.mullvad.net"
    tls_port: 853

# Start and enable Stubby
sudo systemctl enable --now stubby

# Point system DNS to Stubby
# /etc/resolv.conf
nameserver 127.0.0.1

The tls_query_padding_blocksize: 128 setting adds padding to DNS queries to prevent traffic analysis based on query size. Without padding, an observer who can see the encrypted TLS traffic can still infer which domains are being queried based on the size of the encrypted packets, because different domain names produce queries of different lengths.

DNSCrypt

DNSCrypt is an older protocol that encrypts and authenticates DNS traffic using elliptic-curve cryptography. While DoH and DoT have largely superseded it in mainstream adoption, DNSCrypt offers several unique features that make it valuable for privacy-conscious users. It supports anonymous relays that separate the user's identity from their queries, and it can use DNS stamps for compact resolver configuration. The dnscrypt-proxy client on GitHub is the reference implementation and is actively maintained.

Setting Up dnscrypt-proxy

# Install dnscrypt-proxy
sudo apt install dnscrypt-proxy    # Debian/Ubuntu

# /etc/dnscrypt-proxy/dnscrypt-proxy.toml
listen_addresses = ['127.0.0.1:5353', '[::1]:5353']
max_clients = 250
ipv4_servers = true
ipv6_servers = false
dnscrypt_servers = true
doh_servers = true
require_dnssec = true
require_nolog = true
require_nofilter = false
force_tcp = false

# Use anonymized DNS relays
[anonymized_dns]
routes = [
    { server_name='quad9-dnscrypt-ip4-filter-pri', via=['anon-relay-1', 'anon-relay-2'] },
    { server_name='mullvad-doh', via=['anon-relay-1', 'anon-relay-3'] }
]

[sources]
    [sources.'public-resolvers']
    urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/public-resolvers.md']
    cache_file = '/var/cache/dnscrypt-proxy/public-resolvers.md'
    minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'

# Start the service
sudo systemctl enable --now dnscrypt-proxy

# Test resolution
dnscrypt-proxy -resolve example.com

Anonymous DNS Relays

The anonymized DNS relay feature in dnscrypt-proxy is unique among DNS privacy solutions. It works by routing encrypted DNS queries through intermediate relay servers that only see the client's IP address but cannot read the query content, while the destination resolver can read the query but only sees the relay's IP address. This is conceptually similar to Tor's onion routing but specific to DNS traffic. The relay cannot decrypt the query because it is encrypted with the destination resolver's public key, and the resolver cannot identify the client because the query arrives from the relay's IP address. This separation of knowledge provides stronger anonymity than simple encryption alone.

Recommended Privacy-Focused DNS Resolvers

Choosing the right DNS resolver is as important as choosing the right encryption protocol. Not all DNS providers respect user privacy, and some use DNS query data for advertising or surveillance. The following resolvers have strong privacy policies, have undergone independent audits, and support encrypted DNS protocols.

Quad9

Quad9 is a nonprofit DNS resolver operated by the Quad9 Foundation, based in Switzerland, which provides strong legal protection for user data under Swiss privacy law. Quad9 supports DoH, DoT, and DNSCrypt, does not log source IP addresses, and provides threat blocking based on multiple threat intelligence feeds. The primary servers are at 9.9.9.9 and 149.112.112.112. An unfiltered variant without threat blocking is available at 9.9.9.10. Quad9 has completed multiple independent privacy audits and publishes transparency reports.

Mullvad DNS

Mullvad DNS is operated by the Swedish VPN provider Mullvad, known for its strong commitment to privacy. Mullvad DNS supports DoH and DoT, does not log any user data, and offers variants with ad blocking and tracker blocking. The base resolver is at 194.242.2.2 (DNS name: dns.mullvad.net). The ad-blocking variant is at 194.242.2.3 (adblock.dns.mullvad.net), and the extended blocking variant that also blocks trackers, malware, and social media trackers is at 194.242.2.4 (extended.dns.mullvad.net). Mullvad is notable for accepting anonymous payment methods including cash sent by mail.

NextDNS

NextDNS is a configurable DNS resolver that provides granular control over blocking and filtering through a web dashboard. Users create a configuration profile that specifies which blocklists, security features, and privacy protections to enable. NextDNS supports DoH, DoT, and DNSCrypt. While it offers a generous free tier, the logging policy depends on user configuration. For maximum privacy, users should disable all logging in the NextDNS settings panel. NextDNS is useful for users who want both privacy and content filtering in a single solution, but users should be aware that the configurable nature means the default settings may not be the most private option.

System-Wide DNS Configuration on Linux

Properly configuring system-wide DNS on Linux requires understanding the interaction between multiple components: /etc/resolv.conf, systemd-resolved, NetworkManager, and individual application DNS settings. Misconfigurations in this chain are the most common cause of DNS leaks on Linux systems.

Preventing resolv.conf Override

# Method 1: Immutable resolv.conf
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf
sudo chattr +i /etc/resolv.conf

# Method 2: Configure NetworkManager to not manage DNS
# /etc/NetworkManager/conf.d/dns.conf
[main]
dns=none
systemd-resolved=false

sudo systemctl restart NetworkManager

# Method 3: Use systemd-resolved with proper symlink
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
# Then configure systemd-resolved as shown above

# Verify no DNS leaks through the unencrypted path
sudo tcpdump -i any port 53 -n -c 20

Firewall Enforcement of DNS Privacy

The most robust way to prevent DNS leaks is to use firewall rules that block all plaintext DNS traffic, forcing all applications to use the local encrypted resolver. This catches any application or library that ignores the system DNS configuration:

# Block all outgoing plaintext DNS except to localhost
sudo nft add table inet dns_leak_prevention
sudo nft add chain inet dns_leak_prevention output { type filter hook output priority 0 \; }
sudo nft add rule inet dns_leak_prevention output udp dport 53 ip daddr != 127.0.0.1 drop
sudo nft add rule inet dns_leak_prevention output tcp dport 53 ip daddr != 127.0.0.1 drop

# Allow DoH (port 443) and DoT (port 853) to specific resolver IPs
sudo nft add rule inet dns_leak_prevention output tcp dport 853 ip daddr { 9.9.9.9, 149.112.112.112, 194.242.2.2 } accept

This firewall approach is the same principle used by Whonix and Tails to prevent non-Tor traffic. By blocking plaintext DNS at the firewall level, you create a hard guarantee that no DNS query can leave your system unencrypted, regardless of application misconfigurations or bugs in the DNS resolution chain. For a broader approach to securing your system at the network and kernel level, see our Linux security hardening guide.

DNS Privacy on Windows

Windows 11 and later versions include native support for DNS over HTTPS. Configuration is available through both the Settings application and PowerShell:

# PowerShell: Configure DoH on Windows 11
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("9.9.9.9","149.112.112.112")
Set-DnsClientDohServerAddress -ServerAddress "9.9.9.9" -DohTemplate "https://dns.quad9.net/dns-query" -AllowFallbackToUdp $false -AutoUpgrade $true
Set-DnsClientDohServerAddress -ServerAddress "149.112.112.112" -DohTemplate "https://dns.quad9.net/dns-query" -AllowFallbackToUdp $false -AutoUpgrade $true

# Disable Smart Multi-Homed Name Resolution to prevent DNS leaks
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name "DisableSmartNameResolution" -Value 1

# Verify DoH is active
Resolve-DnsName -Name example.com -DnsOnly
Get-DnsClientCache | Select-Object -First 10

The -AllowFallbackToUdp $false parameter is essential because it prevents Windows from falling back to plaintext DNS if the DoH server is temporarily unreachable. Without this setting, a transient network issue could cause all your DNS queries to revert to unencrypted resolution without any notification.

Advanced Considerations

Even with encrypted DNS in place, there are additional privacy considerations. Encrypted Client Hello (ECH), formerly called ESNI, is needed to prevent the server name from being visible during the TLS handshake, because without ECH, the domain name is exposed in the ClientHello message even if DNS was encrypted. DNSSEC provides authentication of DNS responses but does not provide privacy. It should be enabled alongside encrypted transport, not as an alternative. DNS query minimization (QNAME minimization, RFC 7816) reduces the amount of information sent to authoritative nameservers by only querying the minimum domain components needed at each level of the DNS hierarchy.

For users whose threat model includes sophisticated network adversaries, combining encrypted DNS with Tor provides the strongest protection. When using Tor Browser, all DNS queries are resolved through the Tor network by the exit node, which provides both encryption and anonymity. For system-wide Tor DNS resolution, configure the Tor daemon's DNSPort directive and point your system resolver at it. Understanding browser fingerprinting is equally important, as DNS privacy is only one component of a comprehensive privacy strategy that must address multiple layers simultaneously.