On Mon, Jan 30, 2012 at 1:59 AM, Roger Dingledine <[email protected]> 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. -- Nick _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
