On Sat, 2020-05-16 at 01:37 +0200, nusenu wrote: > Alexander Færøy: > > 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. > > I'm also in favor of this approach, > and you can do this today with no code changes to tor at all. > > CF demonstrated it even before DoH/RFC8484 was finalized: > https://blog.cloudflare.com/welcome-hidden-resolver/ >
Do you have DNSSEC validation in this approach? Looking at [1] it seems that it is only a proxy forwarding requests. I can not see any verification of answers. What you achieve here is that you no longer have to trust the exit relays, but now you have to trust CF. I don't think this such a big improvement. If you want to add DNSSEC validation to this setup using unbound or something else you have the issue with additional round-trips as pointed out by Roger. And you have no means to reduce them in this scenario. [1] https://github.com/cloudflare/cloudflared > > > 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. > > + 1 for DoT and DoH over tor, especially due to the DoH > implementation that is > available in firefox (it would still require work on stream isolation > and caching > risks to ensure the usual first party isolation). > In terms of achieving a big improvement on tor browser users in the > context of DNS > this would be the most effective path to spend coding resources on in > my opinion. > > It seems that Firefox's DoH implementation does not employ DNSSEC validation, see [2]. They trust CF doing it for them. Be careful here. Furthermore, there are privacy concerns about additional metadata regarding the use of DoH (agent headers, language settings, and cookies) see [3]. To be fair I have to admit that I have not looked into this myself. [2] https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_do-you-validate-dnssec [3] https://nlnog.net/static/nlnogday2019/5_NLNOG_day_2019_Bert_Hubert_DNS_TLS_Privacy.pdf > > > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev