Hi forest, First of all it's great to see you running relays in such diverse locations. Good job. And indeed IPv4 addresses are insanely expensive nowadays, so alternative strategies to limit their usage is almost always a sound approach. DNS is a complex topic with many considerations, but I think you're on the right track. Latency wise ideally you would find some location that covers a lot of middle ground between the relays, as to prevent some exit relays having a <20 ms DNS latency while others have >200 ms latency. But your relays are spread very far and wide so this may prove challenging. Then timeless timing attack (and also correlation attack!) wise, I think one cache actually is better as long as you configure it properly. In theory, DNS centralization with a extensive cache is actually a good thing for DNS privacy since it limits the viability of correlation attacks. At Nothing to hide we're working on a project to limit timeless timing attacks and correlation attacks severely by making extensive use of DNS caching. As you have noted we wrote about it before here: https://nothingtohide.nl/blog/improving-dns-privacy/, but do note that we have made some good conceptual progression since then and that this blog is a bit outdated as a result. We're still working on upgrading our networking and hardware capabilities before we can deploy our new DNS setup (hopefully in Q1-2026) and verify the different hypothesis we made about mitigating these attacks, but at a small scale you could already implement some basic measures. Some examples: * Only allow your Tor exit relay servers to send DNS requests to your DNS load balancer/recursor. This makes it harder for adversaries to check the in-cache TTL values. Or when providing the DNS response, randomize the TTL value then (ideally per RRSet). You could also add latency to DNS responses so they all are similarly slow (as if the record wasn't cached), but this has downsides of its own. * Decouple TTL values from the original DNS record's TTL and the value in your cache. You could even randomize this (again per RRset ideally) to make it even less predictable. * Preload the top 1k/10k/100k/1M/10M (depending on your networking and hardware capacity) domain's records and keep them 'hot' by fetching their records with a random offset before they would expire. A previous experiment with a small preload list (1k iirc) increased DNS cache hits from ~74% (without preloading/automatic refreshes) to ~93% (with preloading/automatic refreshes), decreasing DNS cache misses considerably. My assumption is that the DNS cache hit rate will increase significantly with 1) a larger preload list and 2) more queries per second, but this is something I can finally verify when our new infrastructure is in place next year. So "Would it be reasonable to dedicated a single, cheap VPS for DNS queries, and have all my other exits use it as their resolver over DoT?"? I think this is a reasonable approach, even when it adds some DNS latency (within reason) to your exit relays. But I would also try (where possible/feasible) to take some countermeasures against some of the more common/easy attacks. I think in many cases (even without extensive countermeasures) a centralized DNS recursor for your own exit relays, at the very least isn't a significant downgrade from running them locally on your exit servers. When our DNS infra is finally upgraded you're free to use it as well (we can whitelist all your IP addresses), but in terms of latency it might be a bad fit since your relays are situated in other parts of the world. Perhaps there are Tor operator that run DNS recursors in South Africa, Moldova, US and Canada for you to use :). You could also ask in the IRC operators channel to see whether other operators can provide you with access to their recursors. Hope this helps, feel free to discuss or ask about this topic! Have a great day, tornth On 21-10-2025 23:49, foreststack@dmc.chat via tor-relays wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Hello.

I run several exit relays. I'm trying to keep them in diverse locations (South Africa, Moldova, USA, and Canada so far, with none in any AS that hosts more than 1% of network bandwidth). I'm using Unbound as a local recursive DNS resolver so I don't have to trust 3rd parties with the DNS queries. But I can't run Unbound on the same IP that exit traffic goes through because some nameservers blacklist Tor, so I use a second IP. With the price of IPv4s these days, this can inflate the cost of a budget VPS by a significant percentage of its original cost.

Right now, Unbound is set up with prefetching and key prefetching enabled, DNSSEC validation enabled, QNAME minimization, a large cache and negative cache, and a local copy of the root zone (RFC 8806).

Would it be reasonable to dedicated a single, cheap VPS for DNS queries, and have all my other exits use it as their resolver over DoT? The way I see it, that has a few pros:

* By saving on IPv4 costs, I can run more relays. * An attacker who can monitor the outgoing DNS traffic doesn't know which relay it is coming from, as all relay DNS queries are mixed. * By sharing a single cache, there will be more cache hits and less need to talk to nameservers and expose queries to them. In other words, a nameserver would only know "someone on one of forest's relays looked up this site" rather than "someone on this particular relay looked up this site".

But I can see there being a few cons as well:

* By sharing a single cache, "timeless timing attacks" may become worse because a single lookup will prime the cache of all of my relays. * Due to their diverse geographical nature, some exits will have sub- optimal routes to the "master" resolver, which increases latency and allows more entities to know when and how many lookups my servers are making (although not what is being looked up, because of DoT).

So what should I do? Run a local recursive resolver on each exit? Set up my own upstream resolver and point all my exits to it? Try to use the ISP's resolver and hope that they configure it well? Use some privacy- friendly upstream resolver like dot.sb? Use a DNS resolver hosted by a major exit operator, as suggested by Nothing To Hide in his blog post https://nothingtohide.nl/blog/improving-dns-privacy-on-tor-exit-relays/?

I would like advice on the best solution here.

Regards, forest -----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj3/7UACgkQBh18rEKN 1gtA5RAAj7k0/SbG/ki9uQCAG4MjxQAZU8nfjuIaVet7PRCpiLoH8obBSM6m7Gve Qb+AV+uOl3IwjUwu914opEZmSolZXRF2CJ4mX+dfZlbigRHqf0jCiBwOVChCMeDR lGGrFICZvH+t2Sy3totmlcWD57aHXkDux/0eNHj0c5VmfOQKiehSqF0IlK6xI3KC ozNzBaYjjdYdtsQetpeQ0ZEgtv/xU4a+DqiLh5MApCiyt0lP88nTUTuQ8tu1qL3j ijLoac2/ZXG2nlMrKkIB7qNDG1r5CsIb6BdJM/hyfNr1d23VqJfrlILYJFXi3ZAd GurC4tGb/3m2BqWEgzNu/zT/xZ99Ky5zSK+oJDKCeQ8OLaP1IvgviMB0yXLLozB9 NlJweJMn3c1mJ9TxvG1zWbrABee847bizb0ncwkv3ikrownWaSRW5n4v1SXHv/lO yLYjrNI7KJfqvgECgtYni5n4DBzW98pNkFrD3sBxtz0BUtngC6lXjN1ru9l4m5sW EiMS7ifAOnCTN8g8ipocBihYoNvsESmbjzUka63nrnqnvmG3tZB5oIR+WpvXnU3o hxxmlXfjAgmBNf4kuzlAfBRenFf0HkfE9y//YOmCJOgiZzuV6Tv040kkdUKtXbbS F4ZShpS04UvpniCKSBa3mn8Ft33GR01mRvgzRZ2dXv3heqqWlmo= =wsTY -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Thank you for your reply.

DNS is a complex topic with many considerations, but I think you're on the right track. Latency wise ideally you would find some location that covers a lot of middle ground between the relays, as to prevent some exit relays having a <20 ms DNS latency while others have >200 ms latency. But your relays are spread very far and wide so this may prove challenging.

Unfortunately, some of them would indeed have >200 ms rtt, as measured by a quick ping between them just now. Perhaps in the future, if I find an affordable dedi host in a good AS, I may focus on them and put out a few Gbps, which would make that more feasible. Until then, I'm drifting around looking for smaller hosts that allow Tor. It's been frustrating at times, with one host (vsys.host) saying that they allow Tor exits and happily accepting my payment, then changing their mind and asking me not to run it. Then responding again saying they elevated it to a senior manager and that it was indeed allowed, and then replying again apologizing and saying that no, it's not. At least they recognized the confusion and were willing to issue a refund. Frustratingly, they are still listed as a good ISP on the community wiki, and there are 3 exits hosted successfully on their AS...

* Only allow your Tor exit relay servers to send DNS requests to your DNS load balancer/recursor. This makes it harder for adversaries to check the in-cache TTL values. Or when providing the DNS response, randomize the TTL value then (ideally per RRSet). You could also add latency to DNS responses so they all are similarly slow (as if the record wasn't cached), but this has downsides of its own. * Decouple TTL values from the original DNS record's TTL and the value in your cache. You could even randomize this (again per RRset ideally) to make it even less predictable.

I thought about that after reading your blog post, but I couldn't find out how to do that without patching the Unbound source code. That is something I could do, but at the moment I don't have the time on my hands to maintain such a fork, at least not to the quality standards that would be wanted for Tor.

* Preload the top 1k/10k/100k/1M/10M (depending on your networking and hardware capacity) domain's records and keep them 'hot' by fetching their records with a random offset before they would expire. A previous experiment with a small preload list (1k iirc) increased DNS cache hits from ~74% (without preloading/automatic refreshes) to ~93% (with preloading/automatic refreshes), decreasing DNS cache misses considerably. My assumption is that the DNS cache hit rate will increase significantly with 1) a larger preload list and 2) more queries per second, but this is something I can finally verify when our new infrastructure is in place next year.

I'm unsure how to preload the top domains. I couldn't find anywhere to import an up-to-date cache, and having a script attempt to resolve a large number of domains and keep them hot would probably not go over too well with most hosting providers, I imagine. I suspect that might not be helpful with smaller relays. One of my relays is currently doing ~10 Mbps (it's capable of much more; I'm just assuming it'll take more time before the BW authorities raise its consensus weight), and it has a very low cache hit rate. I suspect this is because TTL expiration starts to be the dominant cause of loss of cache entries, even with prefetch enabled. The hit ratio is not great. Since last reset a few days ago: thread0.num.cachehits=74xxx thread0.num.cachemiss=1637xxx thread0.num.prefetch=28xxx For reference, this is my current Unbound config (cache size varies from system to system depending on available resources): server: outgoing-interface: <outgoing ipv4 goes here> do-ip6: no rrset-cache-size: 64m msg-cache-size: 32m neg-cache-size: 8m prefetch: yes prefetch-key: yes auth-zone: name: "." master: f.root-servers.net master: k.root-servers.net master: l.root-servers.net master: j.root-servers.net fallback-enabled: yes for-downstream: no for-upstream: yes zonefile: "/var/lib/unbound/root.zone"

So "Would it be reasonable to dedicated a single, cheap VPS for DNS queries, and have all my other exits use it as their resolver over DoT?"? I think this is a reasonable approach, even when it adds some DNS latency (within reason) to your exit relays. But I would also try (where possible/feasible) to take some countermeasures against some of the more common/easy attacks. I think in many cases (even without extensive countermeasures) a centralized DNS recursor for your own exit relays, at the very least isn't a significant downgrade from running them locally on your exit servers.

The worst rtt is ~250ms from my test. I know that systemd-resolved will keep its own local cache even if it's using an upstream resolver, but the size is small and fixed. Would a centralized resolver be feasible even in my case? I suppose I could try to find a very well-peered AS and find a cheap VPS on it for only the purposes of DNS resolution (and perhaps as a bridge relay, so bandwidth isn't going to waste).

When our DNS infra is finally upgraded you're free to use it as well (we can whitelist all your IP addresses), but in terms of latency it might be a bad fit since your relays are situated in other parts of the world. Perhaps there are Tor operator that run DNS recursors in South Africa, Moldova, US and Canada for you to use :). You could also ask in the IRC operators channel to see whether other operators can provide you with access to their recursors.

Maybe I can switch to it for the nearest exits. If I had more networking experience, I'd set up my own set of DNS resolvers for the Tor network with anycast, and allow any IP that is a Tor exit to resolve from them. That would at least be better than using 8.8.8.8. But of course, I have neither the time, networking experience, or trust in the community as a new exit operator to do that. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj40hsACgkQBh18rEKN 1gsMbg//Txhgv0mWny5CdsSjDQD1Oba2sdN0QvMorsM3UbtzJFAMi5dk2jwjYmYj GwZd8/pBbqH5gUDq4xFl8whnRUOiNwDezZEHJIS1gTrz9yC9V+tBLVr5sGW5FfvU dGw4MNWLwXubnpDP1q3HlSirvOfQrLKuxP0z7S9FCptzzJpjEG07st8M6Uh3SBAU MjbX/36NbsHDZ1oD44wgbzdpExWlz2ob2BxqMFLudsqxGim3G9IejnxLS5ONFu8y n5nHtm2AKO2Sf74lcfFi/qAqfhMBFWFZ/JKau2jotbR45ZkJffjDtJsUcUCHVt6k sb2suvmSJfDC6/kBd4vgH+8BqwtjYJu5XS9qPp4zNLifr7Gp5yv2nHx9cxiMRAvh 6xf/8z01qDrXZxygVRb1IeLU3kw3xMgZQQHVxAW+1NbJ86F/MMQcNFoIgOGhI2eH dUd0KTdUvC4O+BQEXt2ZCwU5XwskDu+HuO5EAo5dZK4t5vI8pWchAWkdYGVh1x3P nDmemYK3U/ndtSw+8RVTuTlRXfkBBqyavjK4pNkeK9iHuEEYtadU6F3AAKwzBXxx ta7UBWPiMldqd25JTT/9Tj9fboR9IIXZ4TSf9ZuyyV59oz77c0bycsTIhFP4oHs4 7bR2VGZ4yRrouT5u9TlfyUnKK0cO5HZSIRZE+zR8p19oGOM+wPc= =sB2a -----END PGP SIGNATURE-----

Webtunnel relays default web page. I cannot find were the index.nginx-debian.html and or the index.html files that display the nginx default web page resides. It’s not in the normal location. I would like to edit it to something more “real”. My tunnels do not have other domains residing on the servers. I know once I know it, I will feel silly. find /-name does not dig out anything that seems right Gerry From: DocGerry via tor-relays <tor-relays@lists.torproject.org> Sent: 22 October 2025 13:25 To: 'Nothing to hide' <mail@nothingtohide.nl>; foreststack@dmc.chat Cc: tor-relays@lists.torproject.org Subject: [tor-relays] Re: Exit relays and DNS privacy Could not SOCAT be your friend? Could it be set to listen to port 53 and send on to IPV4 anywhere or IPv6 locally or anywhere? You can have many IPv6s for free on the main server. I have just put unbound on my Pi5 PiHole at home and surprised that it has not added any noticeable delay in requests as it builds up its own cache Gerry From: Nothing to hide via tor-relays <tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> > Sent: 22 October 2025 11:17 To: foreststack@dmc.chat <mailto:foreststack@dmc.chat> Cc: tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> Subject: [tor-relays] Re: Exit relays and DNS privacy Hi forest, First of all it's great to see you running relays in such diverse locations. Good job. And indeed IPv4 addresses are insanely expensive nowadays, so alternative strategies to limit their usage is almost always a sound approach. DNS is a complex topic with many considerations, but I think you're on the right track. Latency wise ideally you would find some location that covers a lot of middle ground between the relays, as to prevent some exit relays having a <20 ms DNS latency while others have >200 ms latency. But your relays are spread very far and wide so this may prove challenging. Then timeless timing attack (and also correlation attack!) wise, I think one cache actually is better as long as you configure it properly. In theory, DNS centralization with a extensive cache is actually a good thing for DNS privacy since it limits the viability of correlation attacks. At Nothing to hide we're working on a project to limit timeless timing attacks and correlation attacks severely by making extensive use of DNS caching. As you have noted we wrote about it before here: https://nothingtohide.nl/blog/improving-dns-privacy/, but do note that we have made some good conceptual progression since then and that this blog is a bit outdated as a result. We're still working on upgrading our networking and hardware capabilities before we can deploy our new DNS setup (hopefully in Q1-2026) and verify the different hypothesis we made about mitigating these attacks, but at a small scale you could already implement some basic measures. Some examples: * Only allow your Tor exit relay servers to send DNS requests to your DNS load balancer/recursor. This makes it harder for adversaries to check the in-cache TTL values. Or when providing the DNS response, randomize the TTL value then (ideally per RRSet). You could also add latency to DNS responses so they all are similarly slow (as if the record wasn't cached), but this has downsides of its own. * Decouple TTL values from the original DNS record's TTL and the value in your cache. You could even randomize this (again per RRset ideally) to make it even less predictable. * Preload the top 1k/10k/100k/1M/10M (depending on your networking and hardware capacity) domain's records and keep them 'hot' by fetching their records with a random offset before they would expire. A previous experiment with a small preload list (1k iirc) increased DNS cache hits from ~74% (without preloading/automatic refreshes) to ~93% (with preloading/automatic refreshes), decreasing DNS cache misses considerably. My assumption is that the DNS cache hit rate will increase significantly with 1) a larger preload list and 2) more queries per second, but this is something I can finally verify when our new infrastructure is in place next year. So "Would it be reasonable to dedicated a single, cheap VPS for DNS queries, and have all my other exits use it as their resolver over DoT?"? I think this is a reasonable approach, even when it adds some DNS latency (within reason) to your exit relays. But I would also try (where possible/feasible) to take some countermeasures against some of the more common/easy attacks. I think in many cases (even without extensive countermeasures) a centralized DNS recursor for your own exit relays, at the very least isn't a significant downgrade from running them locally on your exit servers. When our DNS infra is finally upgraded you're free to use it as well (we can whitelist all your IP addresses), but in terms of latency it might be a bad fit since your relays are situated in other parts of the world. Perhaps there are Tor operator that run DNS recursors in South Africa, Moldova, US and Canada for you to use :). You could also ask in the IRC operators channel to see whether other operators can provide you with access to their recursors. Hope this helps, feel free to discuss or ask about this topic! Have a great day, tornth On 21-10-2025 23:49, foreststack@dmc.chat <mailto:foreststack@dmc.chat> via tor-relays wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I run several exit relays. I'm trying to keep them in diverse locations (South Africa, Moldova, USA, and Canada so far, with none in any AS that hosts more than 1% of network bandwidth). I'm using Unbound as a local recursive DNS resolver so I don't have to trust 3rd parties with the DNS queries. But I can't run Unbound on the same IP that exit traffic goes through because some nameservers blacklist Tor, so I use a second IP. With the price of IPv4s these days, this can inflate the cost of a budget VPS by a significant percentage of its original cost. Right now, Unbound is set up with prefetching and key prefetching enabled, DNSSEC validation enabled, QNAME minimization, a large cache and negative cache, and a local copy of the root zone (RFC 8806). Would it be reasonable to dedicated a single, cheap VPS for DNS queries, and have all my other exits use it as their resolver over DoT? The way I see it, that has a few pros: * By saving on IPv4 costs, I can run more relays. * An attacker who can monitor the outgoing DNS traffic doesn't know which relay it is coming from, as all relay DNS queries are mixed. * By sharing a single cache, there will be more cache hits and less need to talk to nameservers and expose queries to them. In other words, a nameserver would only know "someone on one of forest's relays looked up this site" rather than "someone on this particular relay looked up this site". But I can see there being a few cons as well: * By sharing a single cache, "timeless timing attacks" may become worse because a single lookup will prime the cache of all of my relays. * Due to their diverse geographical nature, some exits will have sub- optimal routes to the "master" resolver, which increases latency and allows more entities to know when and how many lookups my servers are making (although not what is being looked up, because of DoT). So what should I do? Run a local recursive resolver on each exit? Set up my own upstream resolver and point all my exits to it? Try to use the ISP's resolver and hope that they configure it well? Use some privacy- friendly upstream resolver like dot.sb? Use a DNS resolver hosted by a major exit operator, as suggested by Nothing To Hide in his blog post https://nothingtohide.nl/blog/improving-dns-privacy-on-tor-exit-relays/? I would like advice on the best solution here. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj3/7UACgkQBh18rEKN 1gtA5RAAj7k0/SbG/ki9uQCAG4MjxQAZU8nfjuIaVet7PRCpiLoH8obBSM6m7Gve Qb+AV+uOl3IwjUwu914opEZmSolZXRF2CJ4mX+dfZlbigRHqf0jCiBwOVChCMeDR lGGrFICZvH+t2Sy3totmlcWD57aHXkDux/0eNHj0c5VmfOQKiehSqF0IlK6xI3KC ozNzBaYjjdYdtsQetpeQ0ZEgtv/xU4a+DqiLh5MApCiyt0lP88nTUTuQ8tu1qL3j ijLoac2/ZXG2nlMrKkIB7qNDG1r5CsIb6BdJM/hyfNr1d23VqJfrlILYJFXi3ZAd GurC4tGb/3m2BqWEgzNu/zT/xZ99Ky5zSK+oJDKCeQ8OLaP1IvgviMB0yXLLozB9 NlJweJMn3c1mJ9TxvG1zWbrABee847bizb0ncwkv3ikrownWaSRW5n4v1SXHv/lO yLYjrNI7KJfqvgECgtYni5n4DBzW98pNkFrD3sBxtz0BUtngC6lXjN1ru9l4m5sW EiMS7ifAOnCTN8g8ipocBihYoNvsESmbjzUka63nrnqnvmG3tZB5oIR+WpvXnU3o hxxmlXfjAgmBNf4kuzlAfBRenFf0HkfE9y//YOmCJOgiZzuV6Tv040kkdUKtXbbS F4ZShpS04UvpniCKSBa3mn8Ft33GR01mRvgzRZ2dXv3heqqWlmo= =wsTY -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> To unsubscribe send an email to tor-relays-leave@lists.torproject.org <mailto:tor-relays-leave@lists.torproject.org>