#34004: Support for full DNS and DNSSEC resolution
--------------------------+------------------------------------
Reporter: chrisss404 | Owner: (none)
Type: enhancement | Status: needs_review
Priority: Medium | Milestone: Tor: 0.4.4.x-final
Component: Core Tor/Tor | Version:
Severity: Major | Resolution:
Keywords: DNS, DNSSEC | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------+------------------------------------
Comment (by cypherpunks):
Thanks for the great patch.
It is one big step forward to giving more reliability and control to
client of what plaintext information, addresses of contacted hosts you may
share with exit relays. Less trust must be given to exit relay, because
they could lie to you in DNS response without your knowledge! DNSSEC gives
a way to verify.
Also it will make client connections through exit servers more reliable.
Because many of them fail at not so unimportant low rates, that makes them
"unusable" (for tbb ) or any domain name based connections. discussed
beforehand #32864
It will take of load and bandwidth off exit relays witch is the overall
lowest advertised bandwidth in tor consensus to date.
SESSION_GROUP_DNS_LOOKUP will ensure, that if you look up hostname from
socksport request to .torproject.org, it will not be send to the resolver
over the same exit circuit the than resolved ip connection stream is going
to use. If a clearnet resolver may be used.
This gives the exit node or anyone monitoring it, no clue about what host
you may contacted, if not does deep packet inspection and the IP not have
a single mapped domain and no reverse dns record to it or used protocol
exposes it. (like http host header| | tls without esni)
My only concern is the privacy gain that one may like or think to earn
from using onion resolvers with this solution configured with
DNSResolverNameservers.
1.
SESSION_GROUP_DNS_LOOKUP along with default isolation effectively allows
to let two streams or lets call it domain name resolution lookups to share
the same circuit.
Example Scenario:
TBB user visits .torproject.org and in new tab visits .cock.li
Without
{{{
DNSResolver
}}}
tor will open two destination isolated circuits each attaching stream
resolving its domain through exit.
exit will not learn both destinations.
With enabled
{{{
DNSResolver 1
}}}
tor will open two destination isolated circuits each resolving its domain
beforehand through stream to configured DNSResolverNameservers through
same resolver circuit.
exit will not learn both destinations. Bonus Exit will not learn domain
name.
Resolver will learn, a user that first contacted .torproject.org may got a
mail address from .cock.li too.
even if Resolver is contact with the default onionresolvers. Because, the
first stream of resolver MAY can share the same circuit. The resolver
owner will not know the ip or country of the request but knows that both
came from the same client (individual)!
Effectively ignoring and erasing the isolation flags of socksport,
decreasing the isolation level.
Allowing resolver to learn activity profiles over time, by correlating dns
requests.
it is even worse if the client should use the same resolver as before the
two isolated exit servers. because now there is a connection between these
two. i hope to have made it clear with the example.
Note: I only did a quick look over it. That is what came up to my mind.
Not tested it out actually yet.
''sogar wenn der client denselben resolver verwenden sollte wie zuvor die
beiden isoliert verwendeten exit server, ist es schlechter. da nun ein
Zusammenhang zwischen diesen beiden besteht. ich hoffe es mit dem Beispiel
deutlich gemacht zu haben.''
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/34004#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online