On 01/19/2012 11:13 PM, Nick Mathewson wrote:
On Thu, Jan 19, 2012 at 7:39 AM, Linus Nordberg linus@nordberg.se wrote:
Hi,
After some interesting discussions irl last week with knowledgeable DNS and security people (hi Jakob) I'd like to hear from people involved with DNS in Tor what current status is and what needs to be done.
More specifically, what's the status of ttdnsd and TorDNSd? Are they being used? Any thoughts about having a local validating resolver?
So far I've seen ttdnsd used only in Tails, TorDNSd was seen mentioned only in the Tor mailing lists (not sure how many individuals may be using it though).
ttdnsd: kind of works, unless validation is required (ttdnsd fails as unbound forwarder, most likely because of not handling DS queries correctly)
It seems that bunch of people who experimented with DNS over Tor came to conclusion that using existing caching resolver like unbound is simpler than specialized resolvers like ttdnsd.
Originally, we limited the DNS functionality that the exit node would expose for you because we were worried about what kind of shennanegans somebody could do with an arbitrarily crafted DNS request, and so we restricted ourselves to a minimalist subset. (This was back when Dan Kaminski's favorite hobby was finding unexpected applications of DNS, like streaming video and whatnot.)
The same queries can be done by anyone via setting up a tunnel to a recursive resolver (except the constraint that it has to be over tcp). So video streaming over DNS and other DNS-tunelling tricks would work.
But I think the right design is probably something like allowing clients to request more DNS info via exit nodes' nameservers, and get more info back. We should think of ways to do this that avoid extra round trips, but that should be doable.
A naive/straightforward idea is to bundle unbound with Tor/TBB and have it accessible through exit-enclave (unless new cell is explicitly desired). However that adds another thing to maintain. And while rare, there exist networks that either "transparent-proxy" DNS or scrub DNSSEC data from answers.
At the most extreme, this could just give clients the ability to generate arbitrary DNS requests and get the entire response back. If that seems worrisome, we could limit the form of the requests to a reasonable subset, prevent various "christmas-tree" requests, and so on. I don't personally understand the security issues here too well, but I know they exist.
The only problematic "christmas tree request" I can think of is the DNSSEC traffic amplification for some crafted queries (but that can be done now over tunnel to recursive resolver as well).
As an aside, DNSSEC for hostname lookup only helps so much here: If I know for certain that www.example.com is 10.2.3.4, that doesn't really help me if I can't know whether I'm really talking to 10.2.3.4. But there are DNSSEC uses, such as TLS certificate stapling, that would still be reasonable to do over Tor.
Sure, exit node must be trusted (same way routers must be trusted not to do some funny DNAT-ing). DNSSEC validation would mitigate a DNS poisoning attack on exit node's resolver (resolvers using static/sequential ports are still widespread).
Ondrej