adns and TOR

[Ian Jackson]

Werner Koch writes ("Re: adns and TOR"):
> On Tue, 20 Oct 2015 17:11, ijackson at chiark.greenend.org.uk said:
> > I am not opposed to supporting SOCKS.  But I don't understand why so
> > much of this has to be done in adns.  Can't SOCKS provide `connect' ?
> > Is there not some library with the SOCKS protocol client ?
> 
> I think there are libraries but 
> 
>   - they are overkill because we do not need to implement any
>     SOCKS authenticatian method,
>   - probably won't fit into ADNS event driven model,
>   - adds an other dependency.

These are fairly convincing reasons.  I don't fancy trying to break
out asynchronous SOCKS support into its own library at this stage,
which is what the alternative would probably look like.

> > Also, I don't understand why it isn't better to use adns_init_strcfg.
> > Do we want other random utilities, eg command line utilities, to be
> > able to use the socksified adns ?
> 
> You mean a new option?  Makes sense to me.  AFAICS, those options set an
> adns_if flag anyway.  My current GnuPG configure checks whether that
> flag is in adns.h to decide whether Tor support will be possible.  A
> function to ask for that at runtime would of course be safer.

I mean a textual config option in the config file (the resolv.conf,
which adns lets you provide a different one of).  To use the TOR
resolver you're going to have to specify nameservers anyway, so you
already have a custom resolv.conf, presumably.

The init flags are for properties of the application's interaction
with the adns API, not really for how to configure where DNS data
comes from.  The latter is defined in the config file.

> > And I don't understand why it is a good idea to teach adns about TOR
> > rather than to have the next-layer-up TOR things know about that.
> > But perhaps I don't understand how the TOR client software is
> > structured.  If you point me to something where I could do some
> 
> Tor is more than a HTTP proxy so you can't use the standard http_proxy
> thing.  Tor allows to relay all *TCP* traffic.  To accomplish this you
> send all your traffic via SOCKS.  The problem is that the Tor server and
> the network has only limited capabilities for DNS.  It would be much
> cooler if we could ask TOR to retrieve arbitrary RRs but that has not
> been implemented.  Thus the hack to force the use of TCP for name
> resolution and to route this over Tor to a public resolver.  Yes, Google
> can easily manipulate the DNS - it is not safe but that is a different
> story.

Right.

I guess I meant: is it intended that every application program which
one might want to use to access a TOR service would have to be patched
to know about TOR, specifically ?

That seems like it would be a pain.  Surely it would be better to
allow use of any SOCKSified application.

But I don't know how SOCKS is usually configured.  How do you normally
tell a SOCKSified client program where to find its SOCKS server ?

(For that matter, in the TOR context, how do you tell an application
to use a different resolver?)

Regards,
Ian.