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-valida... [3] https://nlnog.net/static/nlnogday2019/5_NLNOG_day_2019_Bert_Hubert_DNS_TLS_P...
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev