I’ve been preparing to run a relay and feel like I’ve covered most of the fundamentals. However, I’m still not entirely sure about best practices for DNS.
More specifically: is it best practice to run a local resolver (e.g. Unbound) directly on the relay, or to use a separate machine as the resolver so that recursive queries don’t originate from an exit relay IP?
The official relay setup tutorial (Tor Project | Exit Relay) recommends Unbound locally on the relay, but I came across research that seemed to indicate that resolves from relay nodes fail more frequently than “clean” IPs (of course I can’t find the reference now, sigh).
For those of you running relays: what has your experience been? Do you keep the resolver local to the relay host, or do you rely on an external resolver outside your Tor infrastructure?
Curious to hear what others are doing. I’m sorry if I missed an obvious dupe of this question. Anyway, cheers, and enjoy the rest of your weekend.
Update for others who are considering using external IPs for name resolution: I did not find a clear answer, but I did come across a post from about a month ago that discusses a very similar issue, but viewed from a security rather than a performance perspective: [tor-relays] Exit relays and DNS privacy - #9 by foreststack_dmc.chat. The thread doesn’t come to a clear conclusion, but the discussion is still very relevant to this topic. At this point, I guess the only way forward is to test it in practice. I’ll report back with the setup used and results.
I’d say, if possible (financially/technically) go with the separate IP address for your outgoing DNS queries. Either by attaching a second IP address to your Tor machine or by adding another machine with a separate IP address. Bonus points if the IP address is from another block, but this shouldn’t matter much (at least it does not for us).
If there are constraints though (IP addresses are expensive), then you can also try to just run a local recursor on your Tor IP address and monitor whether the IP address gets blocked somewhere upstream or not. And as a suboptimal hybrid, you could even forward a few queries that can’t reach the nameserver/root server to Applied Privacy/Cloudflare/Quad9/whatever. If more than a few though, I’d say get that second IP address instead.
Thank you for the helpful response. I got caught up in something else for a bit, but I think this gives me what I need to proceed. I imagine the setup will look something like this (please correct me if anything is off):
The relay will be hosted in Norway, since I already have a server there. It will run with a reduced exit policy to prevent abuse.
The DNS node will be hosted in Hetzner’s datacenter in Finland partly because it’s inexpensive, and partly because it’s geographically close to the relay, which I assume should help minimize query response times.
The DNS node will use the resolver provided by Hetzner for its datacenter, as described in the relay operator’s guide.
I’ll monitor performance through the relay’s Prometheus port.
I understand the network has been targeted by DDoS attacks (Tor is slow right now. Here is what is happening. | The Tor Project). Would you recommend running any UFW rules on the relay host? If so, is there an approved or standardized ruleset that should be applied? Sorry if I missed this somewhere in the docs.
Looks good, although it’s generally better to not use Hetzner (or other hosting provider) DNS resolvers. Hetzner specifically already has a large amount of potential influence over the Tor network, so it’s better to not give them even more insight in to the Tor network’s DNS queries.
I’d say: either resolve the requests yourself (which is easy to do) or use a combination of some external (DoH, DoT, DoQ) DNS services with better privacy protections, such as Applied-Privacy (at the cost of latency). When DNS records are cached, most queries will be handled from cache anyway (lowering average latency considerably). You could even increase minTTL to like 300 seconds to combat those crappy <60s TTLs to increase cache hit rate even more.
About firewalls: it’s not mandatory or anything, but a basic firewall can filter some DoS traffic here and there so that it doesn’t reach the Tor processes (which is often more costly in terms of CPU cycles and memory consumption). If you want to have a basic firewall:
Make sure to have a rule to not lock yourself out from SSH. And make sure to have a rule that allows you to connect to the SSH server (e.g. by allowing your home/management IP on port 22).
Often UDP isn’t necessary for running Tor, so you can probably block it completely.
It’s important to allow established connections, to allow incoming TCP traffic to your relay’s IP(s)/port(s) and for relays to be able to connect externally (outgoing) to other relays (for guard/middle) and the general internet (for exit) as well.
I don’t use Linux of UFW, but looking at the documentation it should be something like the following:
ufw default deny incoming
ufw default allow outgoing
ufw allow in proto tcp from $MANAGEMENT_IP to port 22
ufw allow in proto tcp to any port $RELAY_PORT
ufw enable
This doesn’t block outgoing UDP traffic, but I must say, UFW lives up to its name with such easy syntax ;). Perhaps some Linux users with a better understanding of UFW can chime in for some better/more specific ruleset. Also do note that firewalling all traffic will use resources as well. If you have some CPU and memory headroom, then you probably don’t have to worry about this with a few relays though.
