On 02/10/2012 08:20 AM, Jakob Schlyter wrote:
On 7 feb 2012, at 22:08, Ondrej Mikle wrote:
- 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