This isn’t currently deployed, but by self-hosting the authoritative nameserver (rather than using Cloudflare), we could observe per-attempt wildcard DNS queries (e.g. <timestamp>.<fingerprint>.tor.exit.validator.1aeo.com) and correlate whether those queries reach the authoritative server when initiated by exit relays. When comparing exits within the same IPv6 /64, we would expect to see one of three outcomes: 1) queries arrive directly from the exit IP (recursive resolution) 2) queries arrive via a shared upstream resolver 3) no queries arrive at all, which would be consistent with resolver-side or upstream /64-level blocking Implementing this requires some additional work, so it would be useful to understand how commonly exit operators encounter suspected /64-level DNS blocking in practice. On Saturday, January 17th, 2026 at 3:46 PM, forest-relay-contact--- via network-health <network-health@lists.torproject.org> wrote:
Hello.
Tor at 1AEO wrote:
- Classifies failures: timeout, NXDOMAIN, wrong IP, SOCKS errors
Would this be capable of detecting whether or not nameservers block the entire /64 that an IPv6 exit is on? I've always been concerned about enabling IPv6 in Unbound with the fear that, even if the IP differs, it would still be blocked due to being in the same /64.
For IPv4, the solution is expensive but easy: Buy a second IP. For IPv6, it would be really nice if I didn't have to buy a second /64.
Regards, forest