Just an update on this :
If anyone wants this in the short-term, then it should be done the OnioNS was, like Roger suggests.
In the longer term, there are now a handful of parties interested in building a "libnss2" that provides an asynchronous name interface to : - help resolve the disaster that arises from DNSSEC TLSA records arriving slower than the regular DNS records, - move NSS configuration into user space (DJB & other's want this), and - improve support for the capabilities of GNS and Namecoin.
If you consider what that API might look like, then you realize it's potentially not so Tor friendly : Imagine running Tor on an external device, but to do name resolution the way the user wants tor must talk to nss daemon on the user's machine, but that daemon must understand that tor requests should only go over tor. Ick!
So rather than a proposal for Tor, what we need to do is write an API proposal for a local name resolution system that solves the issues with DNSSEC, and does other things, and does not cause problems for Tor users.
Oh, there is already some asynchronous DNS library in the GNU world, but it's probably not what anyone wants.
On Mon, 2015-09-28 at 16:26 -0400, Roger Dingledine wrote:
On Mon, Sep 28, 2015 at 03:20:47PM +0200, Jeff Burdges wrote:
I proposed that Tor implement NameService rules using UNIX domain sockets, or ports, since that's how GNUNet works, but maybe Tor should instead launch a helper application it communicates with via stdin and stdout. I donno if that'll work well on Windows however.
If you're to be running a second program that does the "resolves", then I think you should really think about adding a third program that talks to Tor on the control port and does all of these rewrites via the control protocol without needing any further Tor modifications. (If you wanted, you could make these second and third programs be just one program.)
This is I believe how Jesse's "OnioNS" tool works at present: you connect to the control port (e.g. via a Stem script), tell Tor that you want to decide what to do with each new stream (set __LeaveStreamsUnattached to 1), and then you let Tor pick (attachstream to 0) for all the streams except the special ones. When you see a new special stream, you do the lookup or resolve or whatever on your side, then REDIRECTSTREAM the stream to become the new address, then yield control of the stream back to Tor so Tor picks a circuit for it.
The main downside here is that you need to run a new Tor controller. But if you're already needing to run a separate program, you should be all set.
What am I missing?
--Roger
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev