The issue I am facing:
After rebooting my Raspberry Pi (sudo reboot), a DNS leak test on normal clients IP Range 1 shows the DNS servers of my VPN provider in addition to those of my ISP. However, if I manually restart Unbound after the reboot (sudo systemctl restart unbound), everything works as expected:
Normal clients IP Range 1 exclusively use the DNS servers of my ISP.
VPN clients IP Range 2 correctly use the DNS servers of the VPN provider.
Details about my system:
I am using a Raspberry Pi 5 running Debian, with Unbound and Pi-hole plus Wireguard Server installed. The Raspberry Pi serves as both a DNS resolver and VPN gateway. My setup uses two distinct IP ranges with separate DNS configurations:
IP Range 1:
DNS: Handled by Pi-hole/Unbound.
Default Gateway: Fritzbox (which also provides DHCP).
Public IP/DNS: From my ISP.
IP Range 2:
DNS and Gateway: Managed by the Raspberry Pi (VPN gateway_Wireguard Server).
Public IP/DNS: From the VPN gateway_Wireguard Server provider.
The configuration for Unbound is based on the official Pi-hole guide (link). I have added the following forward-zone to my configuration:
That configuration doesn't make sense.
You are not using unbound as recursive resolver, but as a mere forwarder, as you are instructing unbound to forward all traffic to 192.168.178.1 or fd00::1 (presumably, your router).
If that would be your intention, then there would be no need to involve unbound at all:
You could uninstall unbound and simply configure 192.168.178.1 or fd00::1 as Pi-hole's upstreams.
As for your DNS leak test results:
As your 192.168.178.1/fd00::1 is handing DNS to public servers, such external observations would depend on its choice of configured upstream DNS servers.
Apologies if this question seems a bit naive, but how can I reliably tell whether Pi-hole is working as a forwarder or as a recursive resolver?
Based on my research, it appears that if the Pi-hole query logs show "OK (sent to localhost#5335)" and my DNS IP is still that of my ISP, then the DNS query is routed through Unbound.
This is only appying when I add the forward-zone rule in the /etc/unbound/unbound.conf.d/pi-hole.conf
Pi-hole is a filtering DNS forwarder.
It can never work as a recursive resolver.
unbound is a recursive resolver, i.e. it will walk through all involved authoritative DNS servers in order to resolve a given domain - unless you configure it otherwise, which is what you've done with your forward-zone configuration.
Quoting unbound's documentation:
Unbound does not perform recursion itself for the forward zone, it lets the remote server do it.
What is your motivation for doing so?
Do you actually want to use your router(?) at 192.168.178.1 /fd00::1 as Pi-hole's upstream?
Absolutely understandable and plausible – for now, Pi-hole and Unbound seem to be working correctly in conjunction with WireGuard. However, the behavior of Unbound after a system restart is difficult to understand, as it creates a state that only changes after a manual restart.
A test has shown that this state can also be established after a system restart by running the commands unbound-control flush_zone . and ip route flush cache, after which Unbound exclusively queries the two DNS servers provided by the ISP.
I suspect that Unbound is not working correctly after a system reboot. Among other issues, this leads to a DNS leak, which poses a significant security risk. I’d like to clarify whether this is caused by configuration settings or if it’s due to a problem in Unbound’s behavior itself.
You didn't answer my question, but I take it then you do indeed want to use your router at 192.168.178.1 /fd00::1 as upstream.
In that case, unbound is redundant for your configuration, just consuming additional resources without providing anything.
You should uninstall unbound and configure Pi-hole to use 192.168.178.1 as its only upstream.
But as explained, it is your router's choice of upstreams that would affect what public DNS servers are used.
unbound would not query your ISPs DNS resolvers, neither in recursive mode nor in your custom configuration - with that, it will query your router at 192.168.178.1 /fd00::1, which in turn may well forward queries to your ISP, depending on its configuration.
I’m unable to answer your question because I don’t fully understand it. Let me summarize my setup and intention briefly again:
I plan to use Unbound as a recursive DNS resolver. To achieve this, I want to configure Unbound in Pi-hole under "Custom DNS" with 127.0.0.1#5335 as the upstream server, instead of using the Fritzbox.
According to the documentation at https://docs.pi-hole.net/guides/dns/unbound/, Unbound acts as a recursive DNS resolver when 127.0.0.1#5335 is set. It forwards queries directly to root servers and authoritative servers, avoiding public DNS servers like Google DNS or Cloudflare DNS.
However, if I set the Fritzbox (192.168.178.1 or fd00::1) as the upstream server in Pi-hole, the system would route queries through public DNS servers like Google DNS or Cloudflare DNS. This is something I want to avoid. That’s why I configured Unbound and set 127.0.0.1#5335 as the custom DNS in Pi-hole. In the query log, I can see that requests are being answered by 127.0.0.1#5335.
My question for clarification:
What DNS servers would you expect to see on the clients with a standard Pi-hole and Unbound configuration?
Then what's the purpose of your forward-zone configuration?
That would apply if you'd use the configuration from our guide.
As explained in my initial reply, that isn't the case with your custom configuration:
If you want to use unbound in recursive mode, you'll need to drop your custom configuration.
It's not entirely clear if you run a local Wireguard server (acting as a gateway for remote clients) or if you'd contracted the services of a VPN service provider (establishing a gateway for local clients).
In the latter case, a recursive resolver like unbound won't work at all, as VPN service providers commonly forcefully redirect all DNS traffic to their own DNS servers, in an effort to prevent DNS leakages, depriving recursive resolvers from communicating directly with authoritative DNS servers.
I was under the assumption – based on forum discussions – that this configuration would allow for a separation of the IP ranges. However, thanks to your help and clarification, I now understand that this is not the case. Therefore, I will revert to the original Unbound configuration, as you suggested
IP Range 1:
DNS: Handled by Pi-hole/Unbound.
Default Gateway: Fritzbox (which also provides DHCP).
Public IP/DNS: From my ISP.
IP Range 2:
DNS and Gateway: Managed by the Raspberry Pi (VPN gateway_Wireguard Server).
Public IP/DNS: From the VPN gateway_Wireguard Server provider.
Apologies if I expressed myself in a somewhat complicated way or if my explanation wasn’t entirely clear. The terminology in this field can be challenging for someone like me who isn’t an expert. I’m trying to learn these topics autodidactically and rely a lot on a trial-and-error approach. That’s why I’m grateful for any help or corrections to improve my understanding.
I want to use WireGuard as a service provided by a VPN provider. The Raspberry Pi should act as a gateway. Additionally, Pi-hole and Unbound will run on the Pi to manage DNS queries. I aim to provide two separate IP ranges, as described above:
As mentioned, you likely won't be able to use unbound in conjunction with a VPN service provider. But your IP Range 2 configuration doesn't mention using Pi-hole for DNS (and thus no unbound upstream), so that wouldn't apply here.
That’s correct and actually intentional for IP Range 2, as I don’t need Pi-hole/Unbound in this case. The VPN service provider already provides DNS servers that can also block ads.