[tor-dev] DNS/DNSSEC resolving in Tor (PoC implementation)

[Ondrej Mikle]

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:
>>
>> https://github.com/hiviah/tor
> 
> 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.TorDNS
> 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