Re: [tor-dev] Prop279 and DNS

[Jeremy Rand <jeremyrand@xxxxxxxxxx>]

George Kadianakis:
> Hmmm,
> 
> using DNS for the query/resolve part of the NS API might actually be a
> reasonable approach for Tor. Prop279 is currently doing query/resolves
> using stdin/stdout messages but people have rightly pointed out that
> this sucks in mobile platforms:
>        https://lists.torproject.org/pipermail/tor-dev/2016-October/011516.html
>        https://lists.torproject.org/pipermail/tor-dev/2017-March/012077.html

Interesting, I wasn't aware of the mobile platform issues with
stdin/stdout, but that does make sense.  Seems like DNS would be one way
to improve that situation.

> I'm not sure if TCP and DNS is the right approach here, but it seems
> like worth exploring further.
> 
> Some thoughts:
> 
> - If we replace the stdin/stdout protocol with a DNS client/server, this
>   means that any interested in name system would also have to implement
>   a DNS server as part of its NS API wrapper.
> 
>   This seems harder to prototype than an stdin/stdout protocol. I wonder
>   if a library could be made to make it easier for name systems to do
>   this (and imagine that in our case, a name system might be something
>   as simple as a local hosts file; not necessarily something as big as
>   Namecoin).

One of the Namecoin developers, Hugo Landau, wrote a Golang library that
might be helpful for this.  The library is at
https://github.com/hlandau/madns , and the Namecoin authoritative DNS
server that uses it is https://github.com/hlandau/ncdns .  I'll point
Hugo to this thread so that he can elaborate on anything I've left out
and/or answer questions.  DNS is certainly a more complex protocol than
stdin/stdout.  AFAIK there aren't any good Python libraries for this
kind of thing (at least, none that support DNSSEC), though it's been a
year or so since I last looked.

> - If we manage to replace the stdin/stdout protocol with DNS, I wonder
>   what can be done about the environment variables part of the protocol,
>   which apparently also sucks for mobile platforms.
> 
>   In the current prop279, environment variables are set by Tor before it
>   execve()s the guest name system. They are used to pass arbitrary
>   options to the name system, instruct it on where it should store
>   files, and let it know of ControlPort configuration etc.

I'm honestly not sure on this one.

> - A big part of the prop279 spec would have to be rewritten to port it
>   to the DNS protocol. I doubt I have time to do this in the short-term,
>   especially given how clueless I am wrt the DNS protocol. Ideally
>   someone would take over this proposal and fix it up....

I can ask Hugo if he'd be willing to help out with the DNS end of
things, but I don't think he has intimate familiarity with Tor, so he
probably wouldn't be able to do all of it (assuming that he has the time
available, which I am unsure of).

>   Also, is there a spec for how Namecoin uses DNS to do stuff? 

We have a spec that describes how a Namecoin JSON object is converted
into a set of DNS records:
https://github.com/ifa-wg/proposals/blob/master/ifa-0001.md .  (That URL
will probably change in the future.)  We then use ncdns (see above) to
run an authoritative DNS server for .bit, which is signed with a
per-machine DNSSEC key generated at install time.  We then use a local
Unbound as the main DNS server for the user, configured to use ncdns as
a stub zone.

Hypothetically, Tor could act as a recursive DNS server (substituting
for Unbound), and allow stub zones to be specified similarly to how
Unbound does it.  In Namecoin's case, the .bit and .bit.onion stub zones
would point to a local ncdns installation.

It's worth noting that some Namecoin node types will generate network
traffic to do the lookup.  This should support stream isolation based on
what stream caused the Namecoin lookup.  Hugo tells me that one
plausible way to communicate this info to ncdns over the DNS protocol
would be edns.

I think there are probably 2 orthogonal questions: (1) should DNS be the
standard abstraction protocol used for Tor naming, and (2) should
Namecoin naming in Tor be implemented using DNS?  If (1) is "no" but (2)
is "yes", then we would still get the benefits of DNS and DNSSEC
interoperability, although not the benefits for mobile platform
compatibility.

Also, to throw another idea out there that plausibly might be worth
thinking about in this discussion: it might be useful to have a
mechanism for a Tor exit relay to do the Namecoin lookup and return the
record along with a merkle proof of blockchain inclusion, similarly to
how exit relays do DNS lookups now.  This might reduce latency by one
round-trip in some cases, since the exit relay could open a connection
to the .bit website before the merkle proof is checked.  It also would
mean that we would need a protocol for Tor send that merkle proof to
Namecoin for validation.  I have no idea whether this functionality
would also be useful for OnioNS and GNS, but I guess that it would be
beneficial for DNSSEC.

Anyway, I don't have a strong view on whether using DNS as the
abstraction protocol is the right choice -- but it's good to have the
discussion, I think.

Cheers!
-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmobile@xxxxxxxxxx
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jeremy@xxxxxxxxxxx is having technical issues at the
moment.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev