...and what is dnscrypt supposed to do for a relay? where are the DNS queries themselves supposed to come out?
i'm yet to hear why a big caching nameserver is insufficient. i'm doing 30mb/s on an exit node. here's my rndc stats:
[View: internal] 86635983 IPv6 queries sent 76987085 IPv6 responses received 4075735 NXDOMAIN received 1085798 SERVFAIL received 17517 EDNS(0) query failures 5684046 truncated responses received 16097299 query retries 9670300 query timeouts 69955769 DNSSEC validation attempted 33207889 DNSSEC validation succeeded 36673375 DNSSEC NX validation succeeded 52281 DNSSEC validation failed 6114026 queries with RTT < 10ms 37261728 queries with RTT 10-100ms 31296765 queries with RTT 100-500ms 1128740 queries with RTT 500-800ms 1159610 queries with RTT 800-1600ms 26152 queries with RTT > 1600ms 86 active fetches 31 bucket size 279 REFUSED received 53264941 COOKIE send with client cookie only 340790 spilled due to server quota
first off, look at the RAW AMOUNT OF QUERIES. i last restarted the nameserver on July 28th for a maintenance reason. do you see the scale of busy i am talking about now?
[View: internal (Cache: internal)] 820788430 cache hits 102325730 cache misses 151111224 cache hits (from query) 232971711 cache misses (from query) 0 cache records deleted due to memory exhaustion 57238152 cache records deleted due to TTL expiration
now, look at the cache rate. the hit rate is currently about 87%. i don't think my internal projects are even a rounding error on nearly a billion DNS queries in not even two weeks.
nearly 90% of a tor user's dns queries will never leave the exit node.
i strongly feel you guys are overcomplicating this. worrying about too many queries going to the same AS, dnscrypt, christ on a crutch.
if you are going to advocate for a more complex, failure prone, difficult to maintain solution then you need to articulate the benefits of it. the solutions i am seeing are.....silly, to put it mildly. there's standardized and robust tools people can use. use them.
On Mon, Aug 7, 2017 at 12:04 PM, Chuck McAndrew chuck.mcandrew@leblibrary.com wrote:
I was wondering about how beneficial DNS Crypt or DNS Privacy would be for relays. Is anyone using any kind of encryption for their DNS queries on their relay?
https://networkfilter.blogspot.com/2017/04/be-your-own-vpn-provider-with-ope... shows how to set up multiple dnscrypt proxies on openbsd for redundancy (with a local instance of unbound as well). Any benefit to doing something like this?
Regards Chuck
On 08/06/2017 10:47 PM, Philipp Winter wrote:
On Sun, Aug 06, 2017 at 04:03:53PM -0400, Dennis Emory Hannon wrote:
Guide is meant for debian/linux users http://backplanedns.org/TOR_exit_dns_resolver_howto.htm
I think the solution to Google seeing so many DNS requests is more nuanced. A single organisation seeing that many request is certainly problematic but so is random ASs on the Internet seeing the same requests -- which is what happens when you resolve a domain name on the exit relay. We also want low query latency and integrity, which Google's resolver happens to be good at.
While we can quantify all these properties, there is no easy way to compare them against each other. Do you prefer an exit relay that uses Google or one that exposes your queries to numerous ASs, and is also more likely to be poisoned?
On a more optimistic note, the DNS privacy project is doing some promising work that exit relays may benefit from: https://dnsprivacy.org _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays