On Tue, May 13, 2014 at 08:12:05PM +0200, Peter Palfrader wrote: > Doing proper DNS resolution, including returning the entire dnssec chain > back to the client on resolves, would be nice. Somebody should do it. :)
Based on CCC talks, I believe the Tor community is considering an unbound-based resolver deployed with exit nodes and/or creating their own ldns-based resolver (though this seems unlikely). There are currently proxy tools like ttdnsd (Tor TCP DNS Daemon, now the default in distros like Tails, which oddly defaults to 8.8.8.8 in configurations), and command line tools like tor-resolve. These are to replace older resolution systems like tor-proxy-dns. The packet size is not the only limitation. Tor exit nodes have a djbdns-like limit of 256 simultaneous outbound connections. Some limits are needed to prevent abuse of exit nodes, but since there's no coalescing or duplicate outbound surpression, this creates a birthday vulnerability (which seems to be mitigated by 0x20, the small linked list size, and the lack of any community advice around modification of this winow). This leaves only flushing attacks on the small cache linked list (which seem fairly pointless since Tor is already slow). There is an effort to improve the proxies, e.g., responding with NOTIMPL for unsupported qtypes, to somewhat improve overall DNS conversations. But as noted there's much work to be done. The community appropriately seems more concerned with leaks (e.g., HiddenServicePort resolution of host names), and ensuring that resolution occurs always over Tor circuits, rather than via complete but localized DNS iterators. I suspect that once leak protection and abuse mitigation are well managed, then exit nodes will ultimately rely on companion deployments of unbound or bind. (DNS is hard, and Tor makes it much harder.) There are some very interesting resolution systems within the larger community (e.g., GNU name service, which is more of an identity framework-with-resolution; i2p jump services; SusiDNS, etc.) But since Tor is designed to interact with what is described as the larger "ICANN Internet", there certainly is a need for more robust resolution. I encourage others to take a look and lend a hand. -- David Dagon da...@sudo.sh D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
