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 <[email protected]> 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
publickey - [email protected] - 0x9288289B.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ network-health mailing list -- [email protected] To unsubscribe send an email to [email protected]
