Post-mortem: Our Leak Test Was Inventing Leaks

Our DNS leak test reported a phone leaking queries to Google Public DNS. It was not. The probe zone is delegated to a host whose port 53 serves strictly as a recursive resolver, so probe queries ended in SERVFAIL. Quad9 retried 18 times, gave up, and the phone fell back to a secondary resolver 57ms later - which we then recorded as an extra 'leaked' resolver on top of the correct ones. The test itself kept working and kept finding real leaks throughout; the defect added entries rather than removing them, which is why it survived so long.

A new post-mortem documents a false positive in our own DNS leak test.

The probe zone is delegated to this host, but port 53 here serves strictly as a recursive resolver with no authority for that zone. Probe queries were forwarded upstream, the upstream recursor was pointed straight back at us, and the resulting resolution loop ended in SERVFAIL. Clients then did what clients do when a lookup fails - they retried against a secondary resolver. Our capture recorded that fallback resolver as though it were a leak.

The test was not broken. It kept detecting genuine leaks and reporting real resolvers correctly the whole time. What the SERVFAIL added was an occasional extra entry, and only when a client's fallback landed inside a narrow timing window - which is precisely why it went unnoticed for so long. We cannot date the first wrong result: our resolver keeps no query log by design and the journal had already rotated past the relevant window, so we are not going to guess.

The zone is now answered by a dedicated authoritative responder, with the redirect applied only to queries arriving inbound so that genuine leak detection still works. Retries per probe dropped from as many as 33 to 1, and phantom entries to zero, verified on 5G and on desktop.

If our test ever listed a resolver you did not recognise, please run it again.

Highlights