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