On 01/30/2012 07:34 AM, Roger Dingledine wrote:
On Thu, Jan 26, 2012 at 10:42:53PM +0100, Ondrej Mikle wrote:
I decided to give it a shot in implementing full DNS/DNSSEC resolution support for Tor, here's the branch:
So it looks like Tor would get two new libraries linked in, and exit relays would inherit whatever security/stability issues libunbound has since clients can basically hand them packets that they have to parse and deal with.
In my implementation, client sends only query string and RR-type (16-bit integer), relay builds the actual query packet. Thus no "funny multiple queries", leaking of transaction IDs or other corner cases. Flags are set to "default recursive query" when relay makes the query (if anyone wants to e.g. query an authoritative server directly, he needs to make a "normal" TCP connection over Tor). Note that libunbound links with ldns itself.
I understand your concern about adding additional binary dependencies. I can try fuzzing libunbound and ldns - I've found some issues in Knot DNS server this way. It's no model-checking, but it has the capacity to unveil weird bugs. (So far I've "bent" libunbound quite hard while using in various tools and from experience I can say it's pretty solid - not a single segfault or abort due to memory corruption.)
The previous hack recommendation had been for the client to use ttdnsd to run dns queries as normal Tor TCP flows: https://gitweb.torproject.org/ioerror/ttdnsd.git https://gitweb.torproject.org/ioerror/ttdnsd.git/blob_plain/HEAD:/README.Tor... which resolves the "what about answers bigger than Tor's cell size" question, as well as the "are we really sure we want a whole dns server implementation inside Tor" question, but leaves such niggling issues as "so do you direct the streams to 8.8.8.8, or what?" It also has the advantage that 8.8.8.8 runs a single known version of its nameserver, rather than a collection of exit relays that each offer whichever version they linked.
There are few open recursive DNS (also validating) resolvers besides Google's I know of:
149.20.64.20 (DNS-OARC) 217.31.204.130 (CZ.NIC - my employer, just saying to get conflict-of-interest out of the way)
Concerning Google's resolvers: I am pretty sure that there are many machines running different software "hidden" behind a load-balancer of 8.8.8.8 and 8.8.4.4 IPs. While I was testing DNSSEC over Tor with unbound+socat, sometimes validation worked and sometimes it didn't.
What do you think about the tradeoffs here? I'd like Tor to support more of dns, but I also think it's important to avoid needing exit relays to know all the details.
Short answer: at this point, I'd go for libunbound (seems good enough for the job).
Long answer: we need to gather all the requirements. The "Tor and DNS" thread raised some important points, like masking client's transaction IDs. (lib)unbound should employ randomized IDs (in my proto-design I accidentally side-stepped the issue ;-) )
I looked at the proposals in torspec, references to DNS were mostly related to IPv6. I can write new spec for DNS resolution, and also fix/rewrite the PoC code to use begin_dns so that we can have responses longer than cell size.
Little over-engineering: Having unbound server running accessible as exit-enclave in chroot on relay (with PIE, grsecurity/SELinux/AppArmor or other hardening) would be really nice, but it would also be a major pain for operators.
Ondrej