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

[Ondrej Mikle <ondrej.mikle@xxxxxxxxx>]

On 01/31/2012 09:35 PM, Roger Dingledine wrote:
> 
> I totally agree that writing our own dnssec code would be absurd.
> 
> But I'm confused here about why we're adding dns support to Tor itself.
> Are we doing it to be able to proxy more requests from applications to
> dns servers? Or are we doing it because the Tor client itself wants to
> be able to learn the answers to dnssec questions?
> 
> If it's the former, then we should try as much as we can to *not* learn
> the details of the protocol. After all, Tor doesn't have an ssh protocol
> parser or validator, but it can proxy ssh traffic just fine.

This question comes up very often when dnssec is considered: where should it be
implemented? At client program? A daemon in OS? A server on a network of an ISP?
There is never an unanimous agreement, dnssec just seems to "not exactly fit
anywhere" (it's not a transport protocol and it's not really an application
protocol; it's just at the same level as DNS).

I thought a bit about (dis)advantages of each, some key points:

1. open DNS resolver listening on TCP somewhere

+ works with current Tor implementation
- there is potential loss of anonymity - there are not many open resolvers and
the issue with transaction IDs was already mentioned
- bit worse performance (creating multiple connections when validating on
client's side)

2. unbound running locally on OR (as exit-enclave)

+ requires only change in packaging
- more code needs to be reviewed compared to libunbound (more code => higher
chance of bug)
- multiple connections when validating

3. libunbound in Tor

+ less code to review than complete unbound
- implementation is more complex

Ondrej
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev