[tor-dev] Tor and DNS

[Jacob Appelbaum]

On 01/30/2012 06:07 PM, Ondrej Mikle wrote:
> On 01/30/2012 11:18 AM, Jacob Appelbaum wrote:
>> On 01/30/2012 01:09 AM, Christian Grothoff wrote:
>>>
>>> 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.
> 
> Seconded, I also find it as a good idea.
>

Glad to hear it.

>> 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.
> 
> I'd suggest that client sends query string, RR type and class in the cell. The
> class is almost always INTERNET, but CHAOS can be useful for debugging which
> server of anycast cluster are you actually talking to. You'll almost never need
> the class CHAOS, but when you do, it will come in handy (see TXT "hostname.bind"
> and "version.bind").
> 

I think that almost any record type is fine.

> DNSSEC: it will become very useful once DANE protocol is standardized (see
> https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/). DANE is a
> certificate-pinning protocol, saying which site should have which TLS
> certificate or which CA should have issued it (maybe Sovereign Keys or Auditable
> CAs will catch on first, but there's no way of knowing yet).
> 

Agreed. DANE is an important nail in the CA Racket's coffin. :)

>> 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...
> 
> I agree. How do we evaluate exit nodes' attack surface? (I suggested fuzzing
> libunbound/ldns as one method). How could we hide the CHAOS queries?
> 

Well - first off, we'd want to determine the places where new code is
added - if we don't change current things and only add a cell type, I
think that's quite easy to do. Secondly, I'd imagine that we'd want to
audit the underlying library quite extensively.

>> 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.
> 
> With current code of relays, CNAME, A and PTR for in-addr.arpa would work. These
> three RR types have an advantage that they can be easily checked for resolution
> of private adresses (like Tor does now; though banning resolution of ".local"
> FQDNs might be added, it's a damn special case).
> 

Right. We could certainly enable inspection at DNSPort time - it can
check for RFC1918 addresses. I personally want a way to know what a
server replied with - even if it might be harmful, I want a true,
verifiable answer. I also want a way to ensure that it doesn't shoot
people in the foot. So, perhaps we can do both?

> I'd add NS, DNAME and AAAA to the default-allowed set (DNAME is quite rare,
> nevertheless used, there's also BNAME RFC draft that seems expired).
> 

I'd like to see - TXT, SSHFP, CHAOS, NS, DNAME, AAAA, A, PTR, CNAME, DS,
DNSKEY, RRSIG, NSEC, NSEC3, CERT, IPSECKEY, KEY, SOA, MX, SRV, SPF

It's becoming very difficult to use Tor without native SRV record for
say, Jabber and the same is true for MX and other types.

Basically, the entire list:
http://en.wikipedia.org/wiki/List_of_DNS_record_types

> If we want to support DNSSEC, then DS, DNSKEY, RRSIG, NSEC, NSEC3 should be
> allowed as well.
> 

Agreed.

>> 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.
> 

I think it's reasonable to separate it into two tasks - 'dns' flagged
exits would require supporting begin_dns - caching is something we
should probably have but a full unbound cache is something perhaps huge
to put into the same process.

> libunbound as well as unbound do caching. ldns can do parsing (libunbound uses
> ldns).

I think that seems OK. I think the first step is a proposal, the second
step is likely to implement whatever "begin_dir" means, a third step is
another proposal where we add the "dns" flag to the Tor spec; likely
we'd find that the second step requires a cache...

Thanks for hacking on this!

All the best,
Jacob