Failing DNSSEC Resolver Test after installing Unbound?

Hi there!

I recently installed Unbound in addition to Pihole (I also had pivpn and wireguard installed before that). If I use these commands to test for DNSSEC it appears to be fine since I get SERVFAIL and NOERROR respectively:

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

However, if I head to https://dnssec.vs.uni-due.de/ it says “No, your DNS resolver does NOT validate DNSSEC signatures.”.
On this webpage though, it says it’s fine: https://dnssec-tools.org/test/


So I’m pretty confused with this one.
Typing: cat /etc/resolv.conf gets me the following:

# Generated by dhcpcd from eth0.dhcp
# /etc/resolv.conf.head can replace this line
nameserver 127.0.0.1
# /etc/resolv.conf.tail can replace this line

By using nslookup pi.hole I get:

Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   pi.hole
Address: 127.0.0.1
Name:   pi.hole
Address: ::

Finally, by using cat /etc/dhcpcd.conf I get:

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
interface eth0
        static ip_address=192.168.1.8/24
        static routers=192.168.1.1
        static domain_name_servers=127.0.0.1
        hostname = orangedietpi

My router settings (DHCP is enabled on Pihole):




I think everything looks OK? But the DNSSEC on that webpage fails for some reason.
Anything I should take into account?

Thanks guys.


Edit: Some additional information, if I connect from an outside connection and use my VPN from Wireguard the test at https://dnssec.vs.uni-due.de/ is fine and I get the success message. How come this happens then?

For what it’s worth, I am using dnsmasq and both sites show that I am using DNSSEC. Moreover validation tests are correct.

Which nameserver are you using in both cases when you test from the home and from outside over WG? Is it the same Pi-hole you are using?

Thanks for the reply Trendy.

Not sure what is dnsmasq?
As for the name servers, how can I check that information?

Thank you again.

Is there a reason why you use dhcpcd instead of applying a static IP via /etc/network/interfaces?

Did you try bypassing Pi-hole and check whether Unbound itself succeeds DNSSEC?

Hey Michael,

I am using Dietpi’s network config though:




As for your second question, may I ask how to do that?
Thanks

Hi,

I do not recommend to use 127.0.0.1 as DNS server on the DietPi device itself. Better to use a public DNS provider like Quad9 or Cloudflare. You are asking why? Because what will happen if PiHole is failing? Correct, you would not be able to resolve a DNS request anymore on the DietPi device itself and you would need to change the DNS server to be able to fix PiHole or do a reinstall :wink: . Next point is to reduce useless roundtrips. Because in your current configuration, DietPi will ask PiHole > Unbound > Upstream DNS on a DNS request. Why not asking upstream directly? Usually there is nothing to block on a DietPi device. At least as long you don`t use a desktop/browser.

BTW: both test side from first post succeed without issues. I’m using PiHole + unbound as well.

MichaIng
I guess the test you requested was already done above by running

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

gasto
Okay, then I’d purge dhcpcd as it currently also applies network configs (and hence conflicts with ifupdown), at least /etc/resolv.conf is controlled by it:

apt purge --autoremove dhcpcd5

Okay, so dig says that DNSSEC is fine on Unbound, one website says its fine with Pi-hole and the other one says its not fine with Pi-hole. When I try it here, it’s the same, the first says “No”, the second says “Yes”, so it looks to me like the first test website is broken, or not applicable for other reasons.

But you could again test dig and those websites with both, Unbound only and Pi-hole, to have better comparable results:

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

And to test the websites with Unbound only, temporarily you could do:

systemctl stop pihole-FTL
G_CONFIG_INJECT 'port:[[:blank:]]' '	port: 53' /etc/unbound/unbound.conf.d/dietpi.conf
systemctl restart unbound

Then test DNSSEC via those websites. Then to revert to Pi-hole:

G_CONFIG_INJECT 'port:[[:blank:]]' '	port: 5335' /etc/unbound/unbound.conf.d/dietpi.conf
systemctl restart unbound
systemctl start pihole-FTL

Thanks again Michael. I followed every step. When doing it via Unbound only it seemed to work?

So there must be something related to Pihole then, right?
Regards.

I guess a misunderstanding. Inside PiHole you don’t need to setup anything as DNSSEC is done by Unbound.