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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev