On 08/20/2012 02:43 AM, Mike Perry wrote:
Thus spake Ondrej Mikle (ondrej.mikle@gmail.com):
I've revised the DNS draft, attaching it. In section 4 there are some options for integration with libunbound, but each of them requires some work with the stock libunbound code.
I'm not a DNS expert, but I have a couple preliminary requests/questions.
First, can you provide a section in the proposal on the analysis of the number of round trips over Tor for different request scenarios? If you offload full DNS responsibility to the client, certain query behaviors are going to be better than others with respect to the number of round trips over Tor. We're going to want to minimize these round trips, especially if we decide we want to rely on DNSsec/DANE for everything. Clients may also want to use this information to try to intelligently decide cases where we don't want to do full DNSsec queries and revert to the oldstyle SOCKS4A.
Added section 8 to the draft with a "common" and "extreme" example. Validation still would be done at both exit and client: client can't trust the AD bit from exit and exit must implement own recursive resolver via libunbound as ISP's resolvers often won't work with DNSSEC, the problem is usually in fetching DS records.
Second (and related), is it totally insane to map some sort of magic IP to "foward this query the local exit node resolver" so that the client can easily get DNS(sec) perspectives from each exit node's resolver caches? This might both minimize round trips for clients who don't want to either hardcode 8.8.8.8 or do full recursive resolves against the root servers. On the other hand, it might complicate query handling on the exit side and also introduce weird cache/poisoning attacks?
It's actually quite interesting idea, though not sure how to map a local 127.0.0./8 IP to a specific exit. If the exit changes inbetween queries (new circuit), should the client know somehow?
I also thought about "most lightweight" implementation which would just use ldns library on the exit's side - client would employ the "magic IP" as forwarder for local standalone unbound daemon. But it breaks on the inability of ISPs' resolvers to fetch DS records mentioned above.
For the perspective it should be noted that many CDNs and load balancers use short TTLs in the range 5-30, two subsequent queries may return different results.
Ondrej