Jeremy Rand jeremyrand@airmail.cc writes:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hello!
Maybe this topic has already been brought up, but in case it hasn't, I'll do so. I notice that Prop279 (onion naming API) defines its own API rather than using DNS. I guess that this is because of security concerns about the centralization of the DNS.
However, in case you're unaware, Namecoin is designed to interoperate with DNS. Let's say that, hypothetically, Tor defined a DNS-based naming system for onion services, where "_tor.example.com" had a TXT record that was verified with DNSSEC in order to make Tor direct "example.com" to whatever that TXT record had. If this were done, Namecoin would be able to produce the necessary TXT record and DNSSEC signatures, via the standard DNS protocol, using an authoritative nameserver that runs on localhost. (The DNSSEC keys used would be unique per user, generated on installation.) Indeed, this is how we're planning to interoperate with non-proxy-based Internet applications.
My guess is that it would be a lot less work on Namecoin's end if such a system were used with Tor rather than a separate naming API. It's unclear to me how this would affect other naming systems such as GNS (does GNS interoperate with clients that use DNS?), and it's also unclear to me whether this would produce extra work for the Tor developers (maybe DNS adds extra attack surface that would need to be mitigated somehow, or maybe there would be complexity in implementing stream isolation?).
Anyway, just figured I'd bring up the topic so that everyone's on the same page regarding figuring out whether it's a good idea.
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
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).
- 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.
- 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....
Also, is there a spec for how Namecoin uses DNS to do stuff?
Thanks for the input :)