[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
On Fri, 2020-05-15 at 15:29 +0000, Alexander Færøy wrote:
> Hello Christian,
>
Hi Alex!
> On 2020/04/26 19:37, Christian Hofer wrote:
> > I have a proposal regarding DNS name resolution.
> >
> > Ticket: https://trac.torproject.org/projects/tor/ticket/34004
> > Proposal:
> > https://trac.torproject.org/projects/tor/attachment/ticket/34004/317-secure-dns-name-resolution.txt
> > Implementation: https://github.com/torproject/tor/pull/1869
> >
> > All functioniality is behind the DNSResolver feature flag, so don't
> > forget to activate it before you start testing.
> >
> > Please let me know what you think.
>
> Thanks for doing this work. I think our DNS subsystem has been
> lacking
> behind for a while. This work is exciting.
>
> Generally, after having done one pass over your code, I think the
> source
> code is good quality, especially if this is your first contribution
> to
> Tor! However, I think this is going to be a bit problematic for us to
> import.
>
> It will be hard, if not impossible, for Tor's Network Team to adopt
> 27k
> LOC's in one pull-request. We will have to have multiple people going
> over each line repeatedly and try to build up some confidence in this
> code. If we are to go down this path, with having a complete DNS
> subsystem in Tor, we need to add some capacity from our side to take
> this in and maintain it. I think that with the recent layoffs in Tor,
> it
> will be hard to achieve in a time-frame that is fair towards you.
>
There are not many changes to the existing code, but most of the code
is new. How could I prepare the changes to simplify the review? Since
most parts depend on other parts within this change, I don't think it
would be a good approach to split them up in multiple PRs?
> One of the goals with our specification process is to have a set of
> documents, which allows other people to understand how Tor is working
> to
> the point where they should be able to implement Tor from scratch if
> they found that useful. This isn't always possible today, but this is
> a
> goal we should have in mind. Your proposal is mostly a specification
> of
> the *implementation* of the DNS resolver patches and doesn't contain
> any
> information on any changes to the network layer of Tor. Instead,
> those
> seem to be referenced as the various DNS related RFCs from the IETF.
> Configuration options of the Tor binary is largely an implementation
> detail.
>
There is only one entry and one exit point, apart from this there are
no further changes to the network layer if you consider these
changes even as a change to the network layer. See the sections
"SocksPort related changes" and "DNSPort related changes" in the
proposal. The DNS resolver implementation should of course comply to
the DNS RFCs.
I would like to try to improve the specification. So, you suggest to
remove the section about configuration options and add more details
about network layer changes?
> I wonder if it would make more sense to have an onion-aware
> DNSSEC-enabled resolver *outside* of the Tor binary and have a way
> for
> Tor to query an external tool for DNS lookups. Such tool should be
> allowed to use Tor itself for transport of the actual queries. One of
> the best parts of Tor (in my opinion) is the Pluggable Transport
> subsystem. This subsystem allows external developers, researchers,
> and
> hackers to build new technology that benefits users in censored areas
> *without* having to alter a single line of C code in tor.git.
>
> Let's say we had a "Pluggable DNS" layer in Tor. Users would be able
> to
> configure their Tor process to *never* use the built-in DNS subsystem
> in
> Tor, but instead outsource it to an external process that Tor spawns
> on
> startup. This process could use .onion's to reach a
> DNS-over-(TLS|HTTPS|TCP) server as onions themselves aren't looked up
> via DNS.
>
Sounds great. Let's start?
> A "Pluggable DNS" subsystem would be much less code, I believe, and
> it
> wouldn't require us to have a DNS+DNSSEC implementation in the heart
> of
> Tor to maintain in the future. Such a system would be similar to the
> proposed design for Name => Onion lookups defined in proposal #279 by
> asn, yawning, and dgoulet.
>
> Lastly, I assume it's just for testing purpose, but I don't think we
> could ship with CloudFlare's DNS-over-Onion services as the default
> servers for a feature like this without having a discussion in the
> community about it first :-)
>
You are right. There is even the DNSResolver flag that defaults to off,
which completely disables this feature.
> All the best,
> Alex.
>
BR
Christian
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev