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, [email protected] 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 -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
tor-relays mailing list -- [email protected]
To unsubscribe send an email to [email protected]
