On 09/29/2015 12:19 AM, Jeff Burdges wrote:
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?
Very interesting. Yes, this sounds reasonable in the short run. In the longer run, there are several people with an interest in externalizing Tor's DNS handling, which changes things. I'll check out OnioNS and discuss this with people at the meeting.
Also, as you see from str4d's message, there are other projects interested in having a new name resolution *API* to access Namecoin, GNS, DNSSEC etc. Thus, it makes more sense to define a new name resolution service that all of those can use, instead of a Tor-specific hack.