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!