Support all kinds of DNS over Tor
Please allow to request any kind of DNS over Tor through exit nodes.
DNSSEC, clear thing.
MX records example use case: Mixmaster over Tor.
Activity
changed milestone to %Tor: unspecified
Closing as duplicate of #7797 (moved)
Hi, I'm a guy who post issue #9081 (moved). Seems like many people, including me, want TorDNS that can query anything.
"Use other DNS provider then"
Yeah Of course, there's a "OpenNIC", but I can't trust it. Maybe they're logging. It's a pity that TorDNS didn't appear in "DNS Provider" section. -> http://prism-break.org/
Only A is not enough, I also want MX and TXT. If "A" query resolve in Tor's Exit nodes, I think it is not possible to query these things too. Even PHP supports any type of DNS queries.
Just a comment, sorry about that
Trac:
Username: ikurua226 month passed since #7829 (moved) posted.
Trac:
Type: enhancement to task
Keywords: tor-relay needs-proposal deleted, tor-relay needs-proposal dnssocks added
Priority: normal to major-
Yup. This one is worth doing, and important to do. It needs somebody with the time to actually write the design proposals, and do the security analysis.
I believe that somebody was sending draft proposals to tor-dev some time in the last 18 months, but they never actually got finished. Anybody want to dig up links to those?
-
I look at a source code of Tor, version 0.2.4.14 alpha. And found this lines;
File is /src/or/dnsserv.c Line 87 to 98,
for (i = 0; i < req->nquestions; ++i) { if (req->questions[i]->dns_question_class != EVDNS_CLASS_INET) continue; switch (req->questions[i]->type) { case EVDNS_TYPE_A: case EVDNS_TYPE_AAAA: case EVDNS_TYPE_PTR: q = req->questions[i]; default: break; } }
Maybe, add these 2 line will do a job... case EVDNS_TYPE_MX: case EVDNS_TYPE_TXT:
And they (Tor Project Devs) said in source code, "None of the questions we got were ones we're willing to support."
Seems like we can't expect an update about this :-(
Trac:
Username: ikurua22
Priority: major to critical -
Not tested, but...
**********[1]********** for (i = 0; i < req->nquestions; ++i) { <--------------------------------LINE 87 if (req->questions[i]->dns_question_class != EVDNS_CLASS_INET) continue; switch (req->questions[i]->type) { case EVDNS_TYPE_A: case EVDNS_TYPE_AAAA: case EVDNS_TYPE_PTR: //!!---<ADD start case EVDNS_TYPE_MX: case EVDNS_TYPE_TXT: //!!--->ADD end q = req->questions[i]; default: break; } }<--------------------------------LINE 98 **********[2]********** if (q->type != EVDNS_TYPE_A && q->type != EVDNS_TYPE_AAAA) {<-----------LINE 105 tor_assert(q->type == EVDNS_TYPE_PTR); }<------------------LINE 107 - LINE 105 + LINE 105: if (q->type != EVDNS_TYPE_A && q->type != EVDNS_TYPE_AAAA && q->type != EVDNS_TYPE_MX && q->type != EVDNS_TYPE_TXT) { **********[3]********** if (q->type == EVDNS_TYPE_A || q->type == EVDNS_TYPE_AAAA) <--------LINE 129 entry_conn->socks_request->command = SOCKS_COMMAND_RESOLVE; else>--------------------LINE 131 - LINE 129 + LINE 129: if (q->type == EVDNS_TYPE_A || q->type == EVDNS_TYPE_AAAA || q->type == EVDNS_TYPE_MX || q->type == EVDNS_TYPE_TXT) **********[4]********** From Line 265 ~Damn. Seems like current source code only thinks about "resolve IP to hostname" and "resolve hostname to IP addr".
Trac:
Username: ikurua22 -
"None of the questions we got were ones we're willing to support."
This is a statement about what Tor currently supports, not a policy statement.
You're looking at dnsserv.c for information on adding new types, and that's a useful, but you'll also need to figure out a wire format for how to ask an exit node for a non-A/AAAA/PTR resolve, and how to get the reply back. (See dns.c for the exit-node side of DNS lookup. See eventdns.c in tor or evdns.c in libevent for the DNS backend.)
For a much better place to start work on these things, see the two mail threads starting on tor-dev from last January, "Tor and DNS", and "DNS/DNSSEC resolving in Tor (PoC implementation)."
The "Tor and DNS" thread had a design proposal draft in it, and some discussion. I don't recall the state of the proposal; it could probably use some tightening up and another glance. That would be a good place to start.
-
Needed task:
how to ask an exit node for a non-A/AAAA/PTR resolve, and how to get the reply back
Data: https://lists.torproject.org/pipermail/tor-dev/2012-February/thread.html#3264
Target: dnsserv.c dns.c eventdns.c evdns.c
I'll read them later.
Trac:
Username: ikurua22 -
Also, if you want to suggest patches, please use the "diff -u" tool or the "git format-patch" command to generate them. Those tools produce output that other people can use to automatically patch their own code trees. They're pretty much standard for exchanging patches in open source projects.
If you're looking at those files, you'll also want to look at some parts of relay.c and connection_edge.c to see how client and exit nodes handle RESOLVE sells.
Bumping priority down to major. I'd rather reserve "critical" for stuff where we can't possibly call the next release series stable without finishing it. Don't get me wrong -- it would be very good to get this into 0.2.5 -- but if it's not done by the time 0.2.5 is ready, it could wait for 0.2.6 or later without the world ending. (You'll notice there are no other "Critical" tickets in this milestone.)
Adding hiviah to cc. Say Ondrej, what's the status of those design proposals you wrote last year?
Trac:
Cc: adrelanos to adrelanos, hiviah
Priority: critical to major -
Related to this (though also as a feature enhancement) is what I proposed over 2 years ago in ticket #3852 (moved)
Trac:
Username: mr-4 As a side note, DNS queries for keyservers are bound to leak with the “modern” (2.1.x) branch of GnuPG, since dirmngr needs to route arbitrary DNS requests and in particular needs all A/AAAA/… records. See Werner's comment at https://lists.gnupg.org/pipermail/gnupg-users/2015-September/054322.html.
Would implementing proposal 219 solve the DNS leak problem of GnupG 2.1?
mentioned in issue #9081 (moved)
mentioned in issue #20925 (moved)
mentioned in issue #30753 (moved)
moved to tpo/core/tor#7829 (closed)