On 02/10/2012 08:20 AM, Jakob Schlyter wrote: > On 7 feb 2012, at 22:08, Ondrej Mikle wrote: > >> 1. full packet might leak identifying information about OS or resolver used, >> quoting Nick: >>> 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. >> >> The query will work as if following was set: flags 0x110 (recursive, >> non-authenticated data ok), DO bit set. Is there any reason for setting some >> flags otherwise or make some optional? > > If you bundle a full resolver (e.g. libunbound) with the TOR client, you will > be much better off doing full DNS packet transport, or you have to rewrite > the upstream forwarding code. I do about the potential fingerprinting issues > (I'm one of the people behind Net::DNS::Fingerprint), but in this case I > believe we can mitigate these issues (if considered important) by > masking/rewriting some DNS request fields within the TOR client and/or exit > node.
I guess you are right as long as the DNS packet transmitted to exit node is always generated by libunbound (BTW fpdns is a neat tool). Validation must be on by default as well, otherwise it would be really to fingerprint users that turned it on manually. I'll update the draft in a few days, just a quick summary of changes: - drop IDs (use StreamID), drop length from DNS_RESPONSE, keep just uint16_t total_length - separate tool for AXFR/IXFR so that server can be specified - validation always on client side by default Ondrej _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev