[tor-dev] Tor and DNS
ondrej.mikle at gmail.com
Sun Feb 12 19:53:06 UTC 2012
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
- separate tool for AXFR/IXFR so that server can be specified
- validation always on client side by default
More information about the tor-dev