any more ideas or help?
Stop unbound and start it again and look what the problem is:
sudo unbound -d -vvvvv
pi@pi-hole:~ $ sudo unbound -d -vvvvv  unbound[28022:0] notice: Start of unbound 1.6.0.  unbound[28022:0] debug: increased limit(open files) from 1024 to 4140  unbound[28022:0] debug: creating udp4 socket 127.0.0.1 5353  unbound[28022:0] debug: creating tcp4 socket 127.0.0.1 5353  unbound[28022:0] debug: creating tcp4 socket 127.0.0.1 8953  unbound[28022:0] debug: setup SSL certificates  unbound[28022:0] debug: chdir to /etc/unbound  unbound[28022:0] debug: drop user privileges, run as unbound  unbound[28022:0] debug: switching log to /var/log/unbound.log
I think this may be linked with qname minimisation.
I noted I had a file
This file contains:
If I remove this file and add the qname option to the main
/unbound.conf.d/pihole.conf file I see similar behaviour.
If I change the option to
qname-minimisation: no I see similar behaviour.
If I remove
qname-minimisation completely from the config, I dont appear to have any problems
You are using a outdated version of Unbound that is still current on Jessie and Stretch with Debian.
If you are using Debian Buster or Stretch on a RaspberryPI try to install 1.93 and the file can be downloaded directly:
I hope the dependencies are kind to you.
im running stretch lite.
apt-cache policy tells me 1.6.0 is the latest available version for this distro
Im not sure i know how to compile etc to bump up the unbound version?
This should have no bearing on the problem. The older version of unbound still works properly.
This would be my understanding also, but at this point ill try anything to have it working as i want.
deb http://ftp.uk.debian.org/debian sid main to my
guess i cross my fingers now?
edit: no key for http://ftp.uk.debian.org/debian
Is there any know issues with qname minimisation? Ive not found anything via Google?
You don’t have to compile and it is already done. It is the install version for SID.
Change to directory /tmp sudo wget http://ftp.us.debian.org/debian/pool/main/u/unbound/unbound_1.9.3-1+b1_armhf.deb sudo dpkg -i unbound_1.9.3-1+b1_armhf.deb
If you can life without the qname minimization and all works now then stay on it and when 1.94 is current you can always try that.
If you have you RaspberryPI only for Pihole and Unbound then also consider to move to Buster which is the current version for the RaspberryPI.
I can live without it, but the point is i shouldnt have to. As others have the same version of unbound running, and working, there must be something up on my install? And im a tinkerer, and would like to know what and how to fix!
Currently I have pi-hole, unbound and OpenVPN running on this particular rasperry pi.
Ive looked at doing an in place upgrade to Buster, just nervous about losing data and current setup etc. and not had time to make a backup of the sd card
I’m still seeing
SERVFAIL error in my logs, for every query now.
Any tips on where to start?
SERVFAIL typically indicates that the DNSSEC process could not be completed. If the time/date on the Pi are correct, that may indicate a problem with your certificate.
If it were me, I would do a complete unbound removal, then reinstall.
I’ve checked the time and it’s correct.
How would you best advise to completely remove unbound from the system?
I would do the opposite of how you installed it. Stop the program, uninstall it, then eliminate all the configuration files.
apt purge? Then manually check for config files etc?
Yes, that would be the process I would follow.
Thanks, appreciate your help.
I’ll try that now, brace yourself for more questions to follow
When I create the pi-hole unbound conf file in
/etc/unbound/unbound.conf.d what user should the file be created as?
sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf
You will need to use sudo nano, since the permission on that folder are root.
So, I’ve fully uninstalled unbound.
Manually deleted any remaining config files
Reinstalled unbound following the guide to the letter.
And yeah, you guessed…still have
https://dnssec.vs.uni-due.de/ reports that dnssec is not working
(This is the case on multiple browsers)
Yet if I use the
dig commands noted in the guide the results are as expected.
Head and brick wall