For what’s felt like forever, I’ve run dnscrypt-proxy as a local DNS resolver for my LAN. Queries initially hit a BIND instance for my “local” domains and dnscrypt-proxy is the forwarder for this setup. This configuration doesn’t lend itself well to query logging or to individually unblocking “semi-desirable”1 trackers with the ad-blocking lists I’ve configured through dnscrypt-proxy. I could finagle something with BIND’s views, but why not look at something like Pi-Hole?
I’ve looked at Pi-Hole off and on before. I usually come back to the same problem: local DNS.There are several forward and reverse zones I run in a split DNS setup with BIND. Pi-Hole partially supports something like this with conditional forwarding; however, I’ve got more than one zone to contend with forwarding. dnsmasq has the option to set several upstreams per domain and Pi-Hole seems to have maintained this functionality as they progress with their own fork.
So as long as this upstream server setting remains, I create /etc/dnsmasq.d/99-forwarders.conf with the following type of content to enable all this forwarding:
server=/example.com/192.168.1.x
server=/1.168.192.in-addr.arpa/192.168.1.x
server=//192.168.1.x
This setup allows BIND to still answer for the zones it’s responsible for while letting Pi-Hole do what it does best. Now, if you’re wondering where dnscrypt-proxy is in my setup – it’s still there! I have Pi-Hole querying it as an upstream resolver. It took me a minute to figure out that the Pi-Hole GUI wants the upstream DNS port to be expressed with a # vs a : though. Now I’ve got the ability to group my “clients” with Pi-Hole and maintain my local DNS. Truly, the best of both worlds.
- So many sites become useless if you block their tracker and telemetry hosts. Chipotle and other online restaurants are good examples of this. Both their app and website simply fail with an unknown error if you block Traffic Manager, which seems to occasionally appear on crowd sourced DNS blocklists. ↩︎