Re: [tor-dev] Tor and DNS

[Ondrej Mikle <ondrej.mikle@xxxxxxxxx>]

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.

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

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

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

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

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

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

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

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

Ondrej
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev