[tor-dev] Special-use-TLD support

Jeff Burdges burdges at gnunet.org
Tue Oct 6 15:19:01 UTC 2015

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

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151006/58aaa436/attachment.sig>

More information about the tor-dev mailing list