On Mon, Jan 30, 2012 at 1:59 AM, Roger Dingledine arma@mit.edu wrote:
On Thu, Jan 19, 2012 at 05:13:19PM -0500, Nick Mathewson wrote:
But I think the right design is probably something like allowing clients to request more DNS info via exit nodes' nameservers, and get more info back. We should think of ways to do this that avoid extra round trips, but that should be doable.
Ha. That'll teach me to answer tor-dev threads assuming nobody broke the threading. :)
So Nick, are you thinking we want a way for exit relays to receive an already-formatted dns query inside the Tor protocol, and get it onto the network somehow heading towards their configured nameservers? Or did you have something else in mind?
Approximately. There are parts of a DNS packet that we wouldn't want to have the Tor client make up. For example, DNS transaction IDs would need to avoid collisions. Similarly, I don't see why the client should be setting most of the possible flags.
I wonder if we want a begin_dns relay command, sort of like the current begin and begin_dir commands, and then just let them talk TCP to one of our nameservers? Or is that too much like the previous hacks?
I think the exit should be able to make the tcp/udp decision, and we'd want the first part of any query to nest inside the begin_dns cell type to avoid using two cells where one would do. Perhaps it also should be something where the last cell of a query gets a "this is the last cell" flag to avoid having to use an END _QUERY cell.
I think exits should do some rudimentary validation on client queries, to avoid shenanigans.
I think that we should also consider having an improved resolve+connect mechanism so that we can get the performance of a BEGIN cell (by avoiding a redundant round-trip) while still getting the DNS information we want.