[tor-dev] Prop279 and DNS

George Kadianakis desnacked at riseup.net
Wed Apr 5 10:45:16 UTC 2017

Jeremy Rand <jeremyrand at airmail.cc> writes:

> 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.


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:

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

- 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 :) 

More information about the tor-dev mailing list