[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Tor and DNS
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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev