[tor-dev] Support for full DNS resolution and DNSSEC validation

[Christian Hofer]

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