On 01/30/2012 01:09 AM, Christian Grothoff wrote:
On 01/30/2012 07:59 AM, Roger Dingledine 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.
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?
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?
In GNUnet, we simply send the raw DNS payload over the mesh network to the exit node (in what for you would be a new cell type), the exit node sends it out via UDP to whatever DNS server the user provided, and the exit sends the response back to the initiator. So the exit never parses the DNS request or response at all. From what I've seen so far, 512 byte cells might do just fine >90% of the time, unless of course DNSSEC somehow takes off. However, GNUnet's message size limit is 64k, so this is not something I've been studying extensively.
In cases where we need to parse DNS queries (likely outside of Tor's scope), we have our own library to do so, but even there we never parse DNS queries that did not originate from our own system.
In summary, I think begin_dns is a good idea, but I'm not sure you need to then talk TCP to the nameserver -- UDP ought to suffice.
I think begin_dns is a good idea as well.
It seems to me that there are a few ways to do it:
send the query and the type send a raw packet that is then forwarded send a variable query and a fixed type (what we do now)
I think that even if DNSSEC dies tomorrow, we'd be silly to stick with the way we do things now. I also think that sending a raw packet is a bit sketchy as it basically means that you're sending client side crafted data - this usually isn't good news from an anonymity perspective.
If begin_dns worked by sending the query and the type, we'd remove almost all possibilities of client side DNS fingerprinting but we'd add attack surface to the exit nodes...
However, I imagine that if we wanted, we could add a new flag 'dns' that would allow various exit nodes to declare themselves open for begin_dns cells. When a user opens the DNSPort, they could select nodes flagged with 'dns' to query directly. If none existed or the query was of a generic CNAME, PTR or A record type, we could use any normally available node.
On the 'dns' flagged exit nodes, a client could begin_dns and then we'd parse the query and the type, generate the DNS query and then ask the our locally configured name server. In an ideal world, we'd use something like unbound to do the parsing and perhaps even to do caching.
All the best, Jacob