Pi-Hole and unbound not working

Was anyone able to ever resolve this, or isolate the issue? I went to bed with (what i thought to be) a working Pi-hole v4.0 configuration (Primary/Secondary nameservers, both on Ubuntu Server 18.04.1 LTS VMs) with recently applied Unbound as my own authoritative servers... but woke up today to machines on the network that were either slow, or not responding at all.

A quick reboot seems to have corrected the issue, I am now able to resolve domain names, but I'm unable to figure out what might have gone wrong. Initially I thought it was my attempts at redirecting devices with hard-coded DNS servers to use my local Unbound devices, but after removing those rules from the Edgerouter, the problem persisted. Turned out to be something else entirely. Is this an Unbound problem? A Pi-hole issue? A me problem? Would be happy to try and help troubleshoot this by providing any logs or documentation / settings / configurations, but I'm lost at this point.

My Edgerouter has dnsmasq enabled. Unsure what else I could have done that caused the problem. I'm only 1 day into my Unbound experience, so I could almost certainly have something configured incorrectly.

Run a few dig commands to see if unbound is returning IP addresses (run these from the Pi device terminal). These commands assume you have unbound on port 5353 (per this guide: Redirecting...)

First with domain not likely to be on a block list:

dig cnn.com

dig cnn.com -p5353

dig cnn.com @1.1.1.1

Then with a known-ad server:

dig flurry.com

dig flurry.com -p5353

dig flurry.com @1.1.1.1

Thank you for moving/posting this, sir -- I thought halfway through my retort that I should probably have started my own topic. Unfortunately, I ended up rolling both machines back to prior Checkpoint/Snapshots (one was on Hyper-V server, the other a VMware host). I was considering starting over, or perhaps starting a brand new Unbound server on pure Debian. That guide (link referenced above) was fantastic and I was able to get things setup fairly easily. I thought I had a successful project and stepped things up with a wonderfully performing set of authoritative DNS servers in-house, but my experience was too limited to attempt to troubleshoot.

Yes, was running port 5353. The only thing I did that may have caused an issue was to run the unbound-anchor command at one point on both machines. Could that have somehow caused issue? I had downloaded/updated the root-hints during the initial install.

Also at one point referenced this guide in a futile attempt to resolve (pun intended) my issues: Unbound DNS Server Tutorial @ Calomel.org

My config to get UNBOUND working with Pi-Hole & dnsCRYPT:

Set Pi-Hole IP in Router's DNS1+DNS2 option.

In Router's DHCP option set local DNS resolver to: Pi-hole IP

DNS.Rebind to: pi.hole

Remove all DNSMASQ-Packages.

Create new dnsmasq.conf (/etc/)

####################
####/:DNSMASQ://####
####################
rebind-domain-ok=/pi.hole/

add-hosts=/etc/hosts.dnsmasq

##//:conf-DIR://##
conf-dir=/etc/dnsmasq.d

Create new file named: hosts.dnsmasq (/etc/)

"IP" (your HOSTNAME)
"Pi-Hole IP" DietPi
"Pi-Hole IP" pi.hole

Set Pi-Hole DNS Custom 1 (IPv4) to: Router IP#53 (ROUTER)
Set Pi-Hole DNS Custom 2 (IPv4) to: 127.0.0.1#5353 (UNBOUND)

In /path/to/dnscrypt-proxy.toml = listen_addresses = ['127.0.0.1:54']


"Unbound"
#/etc/unbound/unbound.conf.d/#

Create a new file named: dnsCRYPT-PROXY.conf

server:
do-not-query-localhost: no

forward-zone:
	name: "."
	forward-addr: 127.0.0.1@54

Create a new file named: pi-hole.conf

server:
verbosity: 1
port: 5353
do-ip4: yes
do-udp: yes
do-tcp: yes
do-ip6: no
root-hints: "var/lib/unbound/root.hints"
harden-glue: yes
harden-dnssec-stripped: yes
use-caps-for-id: yes
edns-buffer-size: 1472
cache-min-ttl: 3600
cache-max-ttl: 86400
prefetch: yes
num-threads: 4
msg-cache-size: 50m
rrset-cache-size: 100m
so-reuseport: yes
so-rcvbuf: 1m
private-address: 192.168.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8

Edit unbound.conf (/etc/unbound/unbound.conf)

server:
include: "/etc/unbound/unbound.conf.d/*.conf"

For the record, i did perform both of these tests (at least initially) and they had returned proper results:

Test validationΒΆ

You can test DNSSEC validation using

dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5353
dig sigok.verteiltesysteme.net @127.0.0.1 -p 5353

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.