Running an exit? Check to make sure you have at least one backup DNS nameserver.
If you're using Unbound/DNS Caching AND/OR DNSCrypt-proxy/DNS Proxy with a Tor Exit node, you should read on:
--- start super tl;dr: Have a backup DNS nameserver if your cache/proxy/whatever fails.
If you run an exit node and don't do anything with DNS, it's not a bad idea to be sure you have at least one backup DNS nameserver. --- stop super tl;dr:
I've been tinkering with this Unbound and DNSCrypt stuff myself. I've certainly deviated with my own prototype setups. But let me just add a really important bit that I've found that anyone who does this should certainly know of:
Your currently-posted system has zero redundancy, which disrupts DNS lookups for your traffic if just one thing hiccups, which, if it's a fatal error in DNSCrypt OR Unbound, you just fatally terminated all DNS queries for your node. This applies to anyone, even if you're just running Unbound, Bind, or dnsmasq, if you mark your cache as primary and it fails, and you didn't name a valid secondary nameserver, your exit node just lost DNS service, and so did everyone on your circuits.
---- Start tl;dr:
Jessie's currently-posted system: You cache encrypted DNS info, which if anything fails, your clients don't get DNS info.
My system: I cache encrypted DNS info, if caching fails on a query, I bypass it until it works. If encryption fails, I bypass it until it works again (non-encryption non-caching is normal for an exit node)
I set Unbound to use 6 DNSCrypt-Proxies (Sorted by ping in case a proxy goes down temporarily or permanently). I just added more instances in Forward-zone in unbound.conf.
I set Unbound as my primary nameserver. I set a lowest-ping DNS-Crypt proxy as my secondary nameserver. I set my ISP default nameserver as my tertiary nameserver. All set in /etc/resolvconf/resolv.conf.d/head
If you're just caching and not proxying DNS queries, you should mark your secondary and tertiary as non-cached backups such as an ISP DNS or Google DNS nameserver.
If your just proxying queries, you should mark your secondary as either a proxy or non-proxy backup such as ISP or Google DNS, and regardless, your tertiary should be said non-proxy backup.
--- End tl;dr:
First, I was having problems with DNSCrypt where a lag in the DNS server would cause a DNS timeout for my client/traffic/circuit/node. So, I added more DNSCrypt-proxies (6 of them actually, in order from lowest ping to highest), and bound them to unbound.conf through multiple entries in forward-zone:. This also protects the node in case one or more of those DNSCrypt servers goes offline.
That solved 95% of my nameserver failures. So, in addition to adding my unbound local DNS interface IP to my etc/resolvconf/resolv.conf.d/head so I'd use Unbound (which is configured to only accept DNSCrypt-proxy info), I also added the primary DNSCrypt-proxy server (DNSSEC-enabled of course) on there as the secondary nameserver, so a fault in Unbound would send requests directly to the DNSCrypt-proxy server and bypass Unbound, maintaining DNS service and encryption, albeit with normal non-cached performance. The next request would reattempt on the primary nameserver, which is Unbound like I said, so each request only bypasses if Unbound fails for any reason or for any length of time.
No nameserver failures since then. However, just because, I added a tertiary nameserver, which is my ISP's default nameserver. So if everything goes up in smoke, my clients can still have normal DNS info.
Jessie, Also, in your current configuration. You have no unbound forward-zones. Which, to my understanding, is a fatal error if you're using DNSCrypt. Tor interfaces with Unbound on your 127.5.3.53, but how does Unbound know where to forward queries to DNSCrypt-proxy?
I was also playing around with "edns0" in etc/resolvconf/resolv.conf.d/head to enable extended DNS queries, particularly since we're both increasing our buffer sizes, but I'm not sure how that works with DNSCrypt servers, and that's what I'm currently playing with.
I also get notices from Tor about ignoring resolve requests because they've already been resolved. Which is funny because you'd think Tor would not be able to distinguish the difference between resolves from Unbound vs. any other "nameserver." Perhaps it's just a dnsevent that is forwarded from Unbound to Tor?
If people have questions, I might end up making a github of my own setup for them to reference. There's no point in encrypting and caching DNS if we just end up causing DNS failures on the network.