I want to use DNSSEC and DNSCrypt with Tor. I wonder which configuration is more secure and better?

  1. SOCKS4 + dnscrypt-proxy: Forward the DNS traffic to a DNS server which I choose. Although the DNS server is DNSSEC, DNSCrypto and has no logs.
  2. SOCKS4a: Forward DNS traffic within Tor network and resolve it from many IP address.
  3. SOCKS5: Forward DNS traffic within Tor network, but resolve it from one IP address (exit node).

So, basically the question is "How to use DNSSEC and DNSCrypt correctly over Tor?"

  • 1
    If you are worried about DNS leaks you can use SOCKS5 and then set network.proxy.socks_remote_dns to true in Firefox. The config is already set if you use the tor browser bundle.
    – user1133
    Feb 11, 2014 at 6:42
  • 1
    There is also another way to route your traffic through TOR by using Privoxy. So route all the traffic to privoxy by using its proxy for all the protocols. In Privoxy forward them using SOCKS5 to TOR. But neither of these methods will bring you DNSSEC.
    – user263485
    Feb 11, 2014 at 12:42
  • I question the real validity of DNS being insecure. Most networks use to block only HTTP GET URLs, where they get domain info to block. Some gateways look on HTTP body for keywords.
    – Hikari
    Mar 30, 2015 at 1:54
  • But are there any DNS servers that are handling TCP requests on port 53? The main issue of tor is that it cannot handle udp traffic and since the "standard" DNS protocol uses udp, proxying through tor makes no sense whatsoever. My guess is that tor will never support udp, both from the perspective of protecting its network from potential bandwidth abuse and due to the fear that they'll get closed down if they'll ever support the whole TCP/IP stack. A pity though, I would have used DNSSEC through tor too, since DNSCrypt is centralized and uselessly encrypted.
    – user7363
    May 5, 2015 at 23:28
  • @user7363 I wouldn't say it is useless. At least it gives certainty that data that gets transferred between the remote resolver and your local machine doesn't get forged. I thank you for mentioning the issue that tor is unable to handle UDP traffic though.
    – konsolebox
    May 13, 2016 at 10:05

5 Answers 5


The 3 configuration examples given offer different benefits and drawbacks. Our preference would be towards #1, as this minimizes latency while offering security on the transportation layer (and with a DNSSEC validating cache, validation of the origin and answer itself).

From a security standpoint, this should allow the same level of protection that Tor does from an encryption standpoint. Of course the DNS server that you are using knows your IP address and what you are requesting, so either you have to trust the DNS server you are using, or you have to use one of the other 2 options proposed.

The major drawback we see regarding the other 2 options are added latency. DNS is pretty time sensitive, the longer it takes to resolve, the worse things go for you. While adding 3 seconds of latency to an HTTP request isn't good, it's not going to break anything. If you add 3 seconds of latency to a DNS request, it's likely your computer will simply act as if the request failed. So, either SHOULD work, the security offered between them is pretty comparable, but there are many different opinions on this point.

The main reason to go for option 2 or 3 (although not sure there's enough difference between those 2 to really matter) would be wanting to hide your source IP from the DNS server.

SOURCE: OpenDNS Support Team


If you enable tcp-upstream: yes in your unbound configuration, the remote DNS server should also be able to reply to TCP requests, in other words, to be listening on port 53 TCP. I couldn't find a free DNSSEC enabled server that does this, all of them talk only UDP.


For what it's worth, you can also use unbound as a DNSSEC validating DNS recursor over Tor. But think long and hard about how this will affect circuit isolation and fingerprinting!

# /etc/unbound/unbound.conf

  auto-trust-anchor-file: "/var/lib/unbound/root.key"
  do-ip6: no
  tcp-upstream: yes

unbound doesn't support Socks, so you would use transparent proxying or maybe torsocks.


I question the real validity of DNS being insecure. Most networks use to block only HTTP GET URLs, where they get domain info to block. Some gateways look on HTTP body for keywords.

DNS is used only when network admin is handling hackers, who he believes have already bypassed his HTTP blocks. It's very rare even for power users to bother about DNS.

But if this admin is unable to properly block HTTP, will he be able to do so with DNS?

The major issue is that DNS queries are the base for all Internet requests based on domains. ANYTHING we access pointing to a domain needs to be resolved. So, DNS is used a lot, and it needs to reply FAST. Using blacklist filters in DNS servers can make them slow, and the whole network will suffer.

Just logging every query everybody does to later use it in statistics is possible, in this case I agree you need to be careful. But again, few uses will be able to properly hide their HTTP usage at the same time admin is unable to block them.

  • lol I was asking something else and StackExchange suggested me this question, I read this answer and was gonna comment it, when I saw I was the one to do it!
    – Hikari
    Aug 3, 2019 at 4:37
  • To sum it up. There's even DNS-over-HTTPS solutions, but if you really have reason to be concerned, I'd suggest you have a local BIND server - or a full pihole, it's awesome, I now have one forwarding to my good-old BIND - forwarding to OpenDNS or something equivalent. Definitely don't use your ISP DNS for general sites, only for a few big CDN domains that it will point to its intranet servers.
    – Hikari
    Aug 3, 2019 at 4:39
  • A ISP hardly will monitor and block DNS traffic leaving and returning on their network. This would add much more latency and support trouble than any blocking benefit for them.
    – Hikari
    Aug 3, 2019 at 4:42

I'm using BIND tuned up for forwarding all the dot-onion to Tor DNS resolver+binder and all the rest is resolved recursively without any forwarding. Works like a charm

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .