We assume you read through the relay guide and technical considerations already. This subpage is for operators that want to turn on exiting on their relay.

It is recommended that you setup exit relays on servers dedicated to this purpose. It is not recommended to install Tor exit relays on servers that you need for other services as well. Do not mix your own traffic with your exit relay traffic.

Reverse DNS and WHOIS record

Before turning your non-exit relay into an exit relay, ensure that you have set a reverse DNS record (PTR) to make it more obvious that this is a tor exit relay. Something like "tor-exit" in its name is a good start.

If your provider offers it, make sure your WHOIS record contains clear indications that this is a Tor exit relay.

Do use a domain name that you own. Definitely do not use torproject.org as a domain name for your reverse DNS.

Exit Notice HTML page

To make it even more obvious that this is a Tor exit relay you should serve a Tor exit notice HTML page. Tor can do that for you: if your DirPort is on TCP port 80, you can make use of tor's DirPortFrontPage feature to display an HTML file on that port. This file will be shown to anyone directing their browser to your Tor exit relay IP address.

If you didn't set this up before, the following configuration lines must be applied to your torrc:

DirPort 80
DirPortFrontPage /path/to/html/file

We offer a sample Tor exit notice HTML file, but you might want to adjust it to your needs.

We also have a great blog post with some more tips for running an exit relay.

Note: DirPort is deprecated since Tor 0.4.6.5, and self-tests are no longe being showed on tor's logs. For more information read its release notes and ticket #40282.

Exit policy

Defining the exit policy is one of the most important parts of an exit relay configuration. The exit policy defines which destination ports you are willing to forward. This has an impact on the amount of abuse emails you will get (less ports means less abuse emails, but an exit relay allowing only few ports is also less useful). If you want to be a useful exit relay you must at least allow destination ports 80 and 443.

As a new exit relay - especially if you are new to your hoster - it is good to start with a reduced exit policy (to reduce the amount of abuse emails) and further open it up as you become more experienced. The reduced exit policy can be found on the Reduced Exit Policy wiki page.

To become an exit relay change ExitRelay from 0 to 1 in your torrc configuration file and restart the tor daemon.

ExitRelay 1

DNS on Exit Relays

Unlike other types of relays, exit relays also do DNS resolution for Tor clients. DNS resolution on exit relays is crucial for Tor clients and it should be reliable and fast by using caching.

  • DNS resolution can have a significant impact on the performance and reliability that your exit relay provides.
  • Don't use any of the big DNS resolvers (Google, OpenDNS, Quad9, Cloudflare, 4.2.2.1-6) as your primary or fallback DNS resolver to avoid centralization.
  • We recommend running a local caching and DNSSEC-validating resolver without using any forwarders (specific instructions follow below, for various operating systems).
    • If you want to add a second DNS resolver as a fallback to your /etc/resolv.conf configuration, choose a resolver within your autonomous system and make sure that it is not your first entry in that file (the first entry should be your local resolver).
    • If a local resolver like unbound is not an option for you, use a resolver that your provider runs in the same autonomous system (to find out if an IP address is in the same AS as your relay, you can look it up using bgp.he.net).
  • Avoid adding more than two resolvers to your /etc/resolv.conf file to limit AS-level exposure of DNS queries.
  • Ensure your local resolver does not use any outbound source IP address that is used by any Tor exit or non-exits, because it is not uncommon that Tor IPs are (temporarily) blocked and a blocked DNS resolver source IP address can have a broad impact. For unbound you can use the outgoing-interface option to specify the source IP addresses for contacting other DNS servers.
  • Large exit operators (>=100 Mbit/s) should make an effort to monitor and optimize Tor's DNS resolution timeout rate. This can be achieved via Tor's Prometheus exporter (MetricsPort). The following metric can be used to monitor the timeout rate as seen by Tor:
tor_relay_exit_dns_error_total{reason="timeout"} 0

There are multiple options for DNS server software. Unbound has become a popular one but feel free to use any other software that you are comfortable with. When choosing your DNS resolver software, make sure that it supports DNSSEC validation and QNAME minimization (RFC7816). Install the resolver software over your operating system's package manager, to ensure that it is updated automatically.

By using your own DNS resolver, you are less vulnerable to DNS-based censorship that your upstream resolver might impose.

Below are instructions on how to install and configure Unbound - a DNSSEC-validating and caching resolver - on your exit relay. Unbound has many configuration and tuning knobs, but we keep these instructions simple and short; the basic setup will do just fine for most operators.

After switching to Unbound, verify that it works as expected by resolving a valid hostname. If it does not work, you can restore your old /etc/resolv.conf file.

Debian/Ubuntu

The following commands install unbound, backup your DNS configuration, and tell the system to use the local resolver:

# apt install unbound
# cp /etc/resolv.conf /etc/resolv.conf.backup
# echo nameserver 127.0.0.1 > /etc/resolv.conf

To avoid unwanted configuration changed (for example by the DHCP client):

# chattr +i /etc/resolv.conf

The Debian configuration ships with QNAME minimization (RFC7816) enabled by default, so you don't need to enable it explicitly. The Unbound resolver you just installed also does DNSSEC validation.

If you are running systemd-resolved with its stub listener, you may need to do a bit more than just that. Please refer to the resolved.conf manpage.

CentOS/RHEL

Install the unbound package:

# yum install unbound

If you are using a recent version of CentOS/RHEL, please use dnf instead of yum.

In /etc/unbound/unbound.conf replace the line:

  qname-minimisation: no

with

  qname-minimisation: yes

Enable and start unbound:

# systemctl enable --now unbound

Tell the system to use the local resolver:

# cp /etc/resolv.conf /etc/resolv.conf.backup
# echo nameserver 127.0.0.1 > /etc/resolv.conf

To avoid unwanted configuration changes (for example by the DHCP client):

# chattr +i /etc/resolv.conf

If you are running systemd-resolved with its stub listener, you may need to do a bit more than just that. Please refer to the resolved.conf manpage.

FreeBSD

FreeBSD ships unbound in the base system but the one in ports is usually following upstream more closely, so we install the unbound package:

# pkg install unbound

Replace the content in /usr/local/etc/unbound/unbound.conf with the following lines:

server:
    verbosity: 1
    qname-minimisation: yes

Enable and start the unbound service:

# sysrc unbound_enable=YES
# service unbound start

Tell the system to use the local resolver:

# cp /etc/resolv.conf /etc/resolv.conf.backup
# echo nameserver 127.0.0.1 > /etc/resolv.conf

To avoid unwanted configuration changes (for example by the DHCP client):

# chflags schg /etc/resolv.conf