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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
