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.
–
kadajFeb 11 '14 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.
–
user263485Feb 11 '14 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.
–
Hikariyesterday

4 Answers
4

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.

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.

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.