Opened 3 years ago

Closed 2 years ago

#20925 closed enhancement (duplicate)

Tor should handle DNSSec RR types (DS, DNSKEY, DLV, etc.) as well as MX

Reported by: paulj Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: #7829 Points:
Reviewer: Sponsor:

Description

I use a Tor client as a DNS resolver, to hide my DNS traffic generally. Even for traffic that does not go over Tor. With the intention that with services that multiplex/aggregate traffic for different domains to some service provider over a secure channel, that the target domain is not exposed to middle-men by DNS.

The idea is to frustrate passive data-collection efforts (as is now a legal requirement on ISPs and mobile telcos in a number of countries) as much as possible, even when not using Tor for my other data-traffic.

E.g., for email to domains hosted with some service provider (e.g. Google, or register.com, or whatever), and delivered by SMTP over SSL, or by MSA to a smart-host, if DNS is not obfuscated/onion-routed, then a middle man can tell who I am emailing even if the email itself is delivered securely over a channel that serves many many domains. As at least some countries in Europe now require ISPs to log all customer DNS queries, this matters.

As another example, for HTTPS+SNI and for web sites that are hosted on large, generic content providers (e.g. CDNs), a 3rd party data-collector can not tell which website I am visiting. They only (passively) can tell I am connecting to a CDN. At least, this is true if the DNS is obfuscated via onion-routing.

I have a caching, recursive nameserver (BIND) configured as my primary nameserver. I have Tor client acting as DNS server on port 5353. I have BIND configured to forward queries to the Tor DNS on 5353.

Unfortunately:

  1. For the SMTP example, Tor does not implement MX, it seems. So when BIND gets "NotImp" from Tor, BIND fetches the MX directly itself - so at least my email gets delivered. However, it means the MX query is visible at my ISP and logged.
  1. For the HTTPS/SNI example, Tor does support A and AAAA records, however it does not support DNSSec related records (DS, DNSKEY, DLV are some I've seen NotIMP returned for, NSEC,NSEC3,RRSIG, etc probably would also be required). My BIND server is configured to make DLV-lookaside DNSSec checks, and so the DNSSec/lookaside related DNS traffic still leaks the target domains to my ISP.

It would be nice if Tor DNS client could support more types. This would allow Tor to be used to onion-route all DNS client traffic, even when other data-traffic is not being onion-routed. This would reduce the information-leak footprint of clients to their ISPs, which would reduce the browsing data logged on them - routinely in a number of European countries (esp. UK).

This would therefore allow Tor to be used to enhance people's privacy, even when Tor was not being used for the data traffic itself.

Child Tickets

Change History (5)

comment:1 Changed 3 years ago by gk

Component: - Select a componentCore Tor/Tor

comment:2 Changed 3 years ago by dgoulet

Milestone: Tor: 0.3.???
Parent ID: #7829

Duplicate from #7829. Proposal 219 is also about this. I'll keep this one open as a child of the main ticket.

comment:3 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:4 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:5 Changed 2 years ago by nickm

Resolution: duplicate
Status: newclosed
Note: See TracTickets for help on using tickets.