DNS Leak Check by Hand: Commands That Show Who Answers You

What a DNS leak actually is

The phrase sounds alarming, and the dnscrypt-proxy wiki calls it misleading for exactly that reason. Some resolver always knows which address asked for which name. The real question is whether that resolver is the one you chose, reached over the encrypted channel you configured, rather than the ISP’s or the hotspot’s server picked up silently from the network.

In practice a DNS leak has three common causes. A second resolver stays configured next to the local proxy, often an IPv6 address handed out by the router. An application such as a browser runs its own resolver and ignores the system. Or a VPN client sends DNS outside the tunnel. Each one needs a different check.

Ask Akamai which resolver reached it

Akamai runs authoritative servers for special names that reply with the address of whoever queried them. Because your device asks your resolver, and your resolver asks Akamai, the answer names the resolver that really did the work. Akamai’s May 2018 announcement replaced the older whoami.akamai.net A record with these TXT names:

dig +short TXT whoami.ds.akahelp.net
dig +short TXT whoami.ipv4.akahelp.net
dig +short TXT whoami.ipv6.akahelp.net

On Windows, nslookup -type=TXT whoami.ds.akahelp.net asks the same question. The ns field is the unicast address of the recursive resolver. An ecs field appears only when that resolver forwards part of your address as EDNS Client Subnet, and ip is a sample address from that subnet, not your exact address.

Read the ns value against what you expect. If you use Quad9 or Cloudflare through dnscrypt-proxy, it should belong to that operator’s network, not your ISP’s. One wrinkle: Cloudflare’s FAQ says 1.1.1.1 never sends EDNS Client Subnet except to this very Akamai debug name, so an ecs line there is expected behaviour.

Check whether something on the path intercepts DNS

A resolver can be bypassed in the other direction too: a router or captive network that catches every packet to port 53 and answers it itself. Google Public DNS documents a test name for exactly that situation, sent straight to its own servers instead of to whatever resolver the system uses:

dig -t TXT test.dns.google.com. '@dns.google.'
dig -t TXT +tcp locations.dns.google.com. '@dns.google.'
nslookup -debug -type=TXT test.dns.google.com. dns.google.

Google’s troubleshooting page explains the outcomes. “Thanks for using Google Public DNS.” means your UDP queries really reach Google, and a reply naming locations.publicdns.goog means TCP queries do too. NXDOMAIN means another resolver answered in Google’s place, which is interception, and a timeout means plain DNS to Google is blocked.

Cloudflare offers a similar identity check, dig +short CHAOS TXT id.server @1.1.1.1, which its troubleshooting page says identifies the Cloudflare server that handled the request. Both checks deliberately use plain DNS, so they test the network path. They do not test your encrypted setup, which the next two sections cover.

Read dnscrypt-proxy’s own query log

If dnscrypt-proxy is your resolver, its log is the most direct evidence of a DNS leak, or of its absence. The [query_log] section of dnscrypt-proxy.toml is off until you give it a file. The Logging wiki page notes that these logs stay on your computer and are never sent anywhere. A minimal setup looks like this:

[query_log]
file = '/var/log/dnscrypt-proxy/query.log'
format = 'tsv'

With tsv, each line holds the timestamp, client IP, query name, query type, return code, duration, server and relay. Use your device normally for a few minutes, then read the file. Names you just visited should appear with the upstream server you configured; a site that loads but never shows up resolved somewhere else.

The wiki adds two blunter tests. Pausing the proxy with pkill -STOP dnscrypt-proxy should break name resolution everywhere until pkill -CONT dnscrypt-proxy resumes it. And a packet capture shows any plain DNS still leaving the machine for a non-local address. Run it while a browser and a mail client are open, so background traffic shows up too:

sudo tcpdump -n dst port 53 and \
  'not dst net (::1 or 10 or 127 or 172.16/12 or 192.168/16)'

The IPv6 leak nobody configured

The most common IPv6 leak comes from the network, not from you. A router announces an IPv6 DNS server, the system adds it next to 127.0.0.1, and some lookups take that route instead. The Checking page is explicit that the proxy should be the only resolver configured on the system for any of these tests to mean anything.

Two settings in dnscrypt-proxy.toml relate to this. ipv6_servers = false is the default and only controls whether upstream resolvers are reached over IPv6. block_ipv6, also false by default, answers IPv6 queries locally with an empty response. Neither removes a system-level IPv6 resolver, so check the adapter settings and repeat the whoami.ipv6.akahelp.net query.

Browsers that bring their own resolver

Browsers can resolve names over DNS-over-HTTPS on their own, which means the system resolver, and your proxy, never see those lookups. That is not a leak in the usual sense, but it does mean a browser check and a terminal check can disagree. The wiki warns that web-based tests only reflect the browser configuration anyway.

dnscrypt-proxy has an answer for this: the [local_doh] section turns the proxy into a local DoH server, for example at https://127.0.0.1:3000/dns-query. The Local DoH wiki page explains that Firefox can then use DoH, and enable features such as encrypted ClientHello, without bypassing your DNS proxy. Other browsers need a locally trusted certificate first.

VPN leak protection: where DNS should exit

With a VPN, the dnscrypt-proxy wiki advises keeping DNS queries at the same exit node as the tunnel, since a website can compare the address that connects with the one your proxy should produce. Whatever a VPN client calls its leak protection, check it with the Akamai query while connected.

Platform settings interact with this. Quad9’s Android guide notes that Private DNS is not used while a VPN is active, so the VPN’s own DNS settings decide. On Windows 11, Microsoft’s DNS over HTTPS options include Fallback to plaintext; when it is on, a failed encrypted query can silently go out unencrypted, a gap worth closing.

If the checks show a DNS leak

• Remove every resolver except the proxy from the adapter, for IPv4 and IPv6. The installation guides show where each operating system keeps this setting.
• On Windows 11, turn Fallback to plaintext off once the encrypted resolver works.
• Point browsers at the local DoH endpoint, or turn their own secure DNS off so the system path applies.
• On Android, see whether Private DNS or the VPN app is in charge before testing.
• Hide your own address from the resolver as well with Anonymized DNS relays; the route builder writes the [anonymized_dns] block.
• Rerun the Akamai and Google checks after each change. The encrypted DNS overview explains what each protocol can and cannot hide.