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@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev