Re: Exit relays and DNS privacy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
You should definitely try setting up IPv6. Essentially, your problem is rooted in the limited number of IPv4 addresses. With IPv6, you most certainly can have more than one IPv6 address on every VPS for free. Using IPv6 wherever possible tackles the root issue.
This would only work if all nameservers support IPv6, no? I would still need to use IPv4 for the nameservers that don't, which means continuing to pay for the extra IPv4. What I'm thinking of doing is choosing a single reliable exit in each geographic location that I run, and using it as the upstream DNS resolver for all the other relays in the region. Thus I can use one relay in the USA to serve my relay in Canada, and one relay in Moldova to serve other relays in Europe. I would only need to pay for an extra IPv4 for each geographic region, and wouldn't have to suffer from the nasty >200ms latency incurred through transoceanic cables. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj7ch4ACgkQBh18rEKN 1gu6jBAArMfWI6mXe6Ce+9UUQ8FQPgxDYjiySBij3QqN3NmM2N0TGxU/+wjldLrP wE/1zFjuTTQfZsOXJcLd13kmiqpt4jFRVAe+d0vpdfMkIppbDRmYRlcGrn7k1YwI Sdac1Dd3bUxRU3XLF/tVKeDjAsU55qu7el7qkd7RdhPjQ1IYV6GIzJPANcaREzv1 m6DBkkTAgkqvBVAQTFbOWLkLYL8KGXYTSjp14ZxB0SH8wrDKaZ/Hb0ASHlDYO7J8 lgjgR1fjfj13IlyjyRLlSeZiXmvHgi1W3NBLwp6nR2V1uwQ+VB7IIkjg+TJ3EN3x wMt1xCmqX9wqsfUgjR5wHJMFNu1maAgdMRUTSWDj0g1P4A4Dvvq1zQJUPtRViZsM 7NzgyrEqWd9gXHAxbP/82eM8QYbzflXEwtz5YFLDhFnXx1sQfE911pE3fklYMnEX SnyslYhK76Xg+E59Q6sGgKYnWyJSPIr88/KouTYKdqbywmg3duEM8a0tp/lLte6o nuA/HI83+sGrSnxGF8cZy8GOY6+MepzUEwX8uQlYSE9RNu/owqF3pCRpyJ6E6udz QvlSzQy6a8d8CewUQ6G8cQETAoSadaEsPdZzaEAj/6jgThTcZKnMnUFx3G/6VM2c ykHHoe6dBLlmesiqirXOiT99Hel09yvlI07H82kmT2JmRcqgUak= =M4IK -----END PGP SIGNATURE-----
* foreststack@dmc.chat via tor-relays:
This would only work if all nameservers support IPv6, no? I would still need to use IPv4 for the nameservers that don't, which means continuing to pay for the extra IPv4.
Have you considered using dnscrypt-proxy [1] with a couple of their IPv6-capable servers configured as forwarders? No need for your own server to have an Internet-routable IPv4 address in that scenario. [1] https://github.com/DNSCrypt/dnscrypt-proxy -Ralph
My suggestion: If DNS is being blocked from a Tor exit the site itself that is being resolved is also likely to be blocked, so it should be a rarer case than you'd otherwise expect. So just run a local recursive resolver ON the exit node, but with a small patch so if the recursive resolver fails to resolve a name you have a fallback to a separate recursive resolver, the one that is run by the ISP where you are running your Tor node, so it will still resolve if the site only blocks DNS but not the final connections. And the privacy implication is very low: after all, the ISP can see the final traffic anyway and DNS doesn't exist in a vacuum but is used to contact sites.
On Oct 24, 2025, at 6:35 AM, Ralph Seichter via tor-relays <tor-relays@lists.torproject.org> wrote:
* foreststack@dmc.chat via tor-relays:
This would only work if all nameservers support IPv6, no? I would still need to use IPv4 for the nameservers that don't, which means continuing to pay for the extra IPv4.
Have you considered using dnscrypt-proxy [1] with a couple of their IPv6-capable servers configured as forwarders? No need for your own server to have an Internet-routable IPv4 address in that scenario.
[1] https://github.com/DNSCrypt/dnscrypt-proxy
-Ralph _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
* Nick Weaver via tor-relays:
If DNS is being blocked from a Tor exit the site itself that is being resolved is also likely to be blocked, so it should be a rarer case than you'd otherwise expect.
I disagree with your assumption of "if a nameserver for example.com blocks the Tor exit, somehost.example.com will likely block the exit as well" (I am of course paraphrasing). First, many domains use third-party DNS hosts. Second, an imaginary nameserver ns.example.com /might/ block the same hosts as www.example.com, but why would it? The hosts provide very different services. As for the rarity of blocks, I think you have a better point there.
So just run a local recursive resolver ON the exit node, but with a small patch so if the recursive resolver fails to resolve a name you have a fallback to a separate recursive resolver, the one that is run by the ISP where you are running your Tor node
That would provide a DNS resolver fallback, but also a privacy leak. Your ISP could block your own resolver to force fallback to theirs. It depends on how cautious/paranoid one wants to be in this matter. I recommend local, caching resolvers on Tor guards or middle nodes, but for exits this matters less, due to the next point you mentioned:
And the privacy implication is very low: after all, the ISP can see the final traffic anyway [...]
Indeed. Also, the Tor exit X making connections to some destination Y does not place the initiating Tor client Z at risk, what with Z and X being separated by the Tor circuit. Overall, I see the deployment of a local caching resolver (without fallback to ISP resolvers) like Unbound as sufficient, and I already mentioned dnscrypt-proxy as an alternative. I prefer Unbound, with its small footprint, simple configuration and DNSSEC support. -Ralph
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Second, an imaginary nameserver ns.example.com /might/ block the same hosts as www.example.com, but why would it? The hosts provide very different services.
This is correct. Most blocking of Tor is not done by some upstream NOC that has control over all the traffic passing through its servers, but by some WAF or major CDN, neither of which are going to be used by a nameserver. That is, Tor is more likely to be blocked by Cloudflare, Akamai, Imunify360, Securi, etc. Likewise, nameservers that block Tor often do so separately from the domains that they manage, often by importing bulk IP blacklists that unfortunately contain Tor addresses. Access is then denied by the resolver software itself.
That would provide a DNS resolver fallback, but also a privacy leak. Your ISP could block your own resolver to force fallback to theirs.
In my view, the threat model is one of passive collection of data which is individually not particularly sensitive, but cumulatively gives an unnecessarily-large insight into traffic. A malicious ISP would be unlikely to gain much from forcing fallback for a single node.
Also, the Tor exit X making connections to some destination Y does not place the initiating Tor client Z at risk, what with Z and X being separated by the Tor circuit.
I recall there being several papers which showed that DNS privacy is more important than it seems. When exit X makes a connection to Y on behalf of client Z, there is a risk if anyone on the path been X and Y collude with anyone on the path from Z to its guard. When using a local recursive resolver, far more entities learn information about the communication between X and Y.
Overall, I see the deployment of a local caching resolver (without fallback to ISP resolvers) like Unbound as sufficient
I agree. Although it does have some downsides, I think the upsides outweigh them. The only problem is the IPv4 shortage. :) Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj858kACgkQBh18rEKN 1gs+nBAAhAEa6pzZVIBASVe09VUk4poA63ldBDJdqu+INrVMPS42j73NKq0TvnHk 7rqOQtHF8xdCznmy6/Abv+aOgpAPSR9miwmJojp0zzw3VZGtdCzUihuPaDtCSkTa uLrVSF90j7vC/T3nIB2FyAYqK3jLNdJzm22+9xyfDmivnutrqSsq7EubYIFktyuz 1mBteVBuBTvJvKrnafPNI+CFp6cYDoJdrkBgCsxfNswcS6VT2VUb6dEZGgOjov9R 6yyRAVkHbkSis8Wo4QOwEnyv4+XxV7UrubHnWS6vE3shxhiUSo6mXpE+dvD0RApZ uM/KSHEMLT9dDI0oukoNwgLg9XuT0IIBw4PddkHE6+8XirXpRa5O3GEBCuJ6EO+W eD6LZFonAib/VISM33wOdBBUB2NNPMP3aV2a3cs7hxPXO56SIAekUDJV/PJVp2XB 1iOr0HdKChxA/yQvwcQQMht2nPZUjLCmkoS0LzPOZv3EKC7Htw0FC7OZvnPtRmAv 8nqPWQIHjnfUmzTtab3SjUMY8LeBNxpRwmv9gNyLyfxfsuBjCWaycg3oZW3wE6y0 nJ9uClU7vaAMbEfJn6R5xYrzMA0k0PZKGzWGzCkd+Mcs1XxJKfpyIBiTlQf8X3p5 BBeznSTJkRIH5Tk6KqkTr21q40cu2nupCNZoLqp/yvZIkB7mirM= =xzyZ -----END PGP SIGNATURE-----
participants (3)
-
foreststack＠dmc.chat -
Nick Weaver -
Ralph Seichter