I have a NAS which should be resolved from the internet with the DnyDNS IP and locally with a private 192.168.x.x IP.
My setting:
Server a (192.168.2.20) with unbound with some entries
local-zone: "home.xxxxx.de." static
local-data: "pi.home.xxxxx.de. IN A 192.168.120.10"
local-data: "nas.home.xxxxx.de. IN A 192.168.2.21"
No forwarding server, resolving all queries recursively.
Works like a charme and resolves all local entries when using dig or nslookup from every client, with one exception.
Server b (192.168.120.10) with pihole and only the unbound server as forwarder (-> 192.168.2.20)
Pihole does not resolve nas.home.xxxxx.de correctly. It always shows the DynDNS IP. For its own hostname it shows an DHCP ip address from the wifi interface which had been deleted some hours ago (and rebooted several times).
Debug Token:
https://tricorder.pi-hole.net/eYlXHEIa/
Run from your Pi-hole machine, please share the output of:
nslookup nas.home.xxxxx.de
nslookup nas.home.xxxxx.de 192.168.2.20
nslookup nas.home.xxxxx.de 192.168.120.10
Your debug log shows Pi-hole and unbound to be on different subnets.
How did you ensure that requests from Pi-hole do get routed to unbound?
Unrelated to your issue, your debug log shows that your router is distributing unbound (at 192.168.2.20) next to Pi-hole (at 192.168.120.10) as local DNS servers via DHCP:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
* Received 312 bytes from eth0:192.168.120.1
Offered IP address: 192.168.120.195
DHCP options:
Message type: DHCPOFFER (2)
broadcast: 192.168.120.255
dns-server: 192.168.120.10
dns-server: 192.168.2.20
router: 192.168.120.1
--- end of options ---
This would allow clients to by-pass Pi-hole by using unbound at their own discretion.
Pi-hole has to be the sole DNS server for your clients.
Hello,
thanks for your fast answer.
Routing is working fine, the subnet with the pihole is for testing.
DHCP Settings are correct, because pihole is resolving the nas.home.xxxxx.de not correctly and therefore unbound is propagated as primarely DNS server.
user@pi:~ $ nslookup nas.home.xxxxx.de
Server: 192.168.2.20
Address: 192.168.2.20#53
Name: nas.home.xxxxx.de
Address: 192.168.2.21
user@pi:~ $ nslookup nas.home.xxxxx.de 192.168.2.20
Server: 192.168.2.20
Address: 192.168.2.20#53
Name: nas.home.xxxxx.de
Address: 192.168.2.21
user@pi:~ $ nslookup nas.home.xxxxx.de 192.168.120.10
Server: 192.168.120.10
Address: 192.168.120.10#53
Name: nas.home.xxxxx.de
Address: 192.168.2.21
nslookup from my windows client - dyndns IP as answer from pi
PS C:\Users\textlastig> nslookup nas.home.xxxxx.de 192.168.120.10
Server: UnKnown
Address: 192.168.120.10
Nicht autorisierende Antwort:
Name: nas.home.xxxxx.de
Address: 149.172.xxx.xxx
PS C:\Users\textlastig> nslookup nas.home.xxxxx.de 192.168.2.20
Server: server.home.xxxxx.de
Address: 192.168.2.20
Name: nas.home.xxxxx.de
Address: 192.168.2.21
Resolving pi.home.xxxxx.de - pi answers with old IP from removed wifi interface
PS C:\Users\textlastig> nslookup pi.home.xxxxx.de 192.168.2.20
Server: server.home.xxxxx.de
Address: 192.168.2.20
Name: pi.home.xxxxx.de
Address: 192.168.120.10
PS C:\Users\textlastig> nslookup pi.home.xxxxx.de 192.168.120.10
Server: UnKnown
Address: 192.168.120.10
Name: pi.home.xxxxx.de
Address: 192.168.120.195
Testing from different clients showing consistently the same answers.
Above demonstrates that Pi-hole does provide the expected resolution if it is queried directly.
It is peculiar that your Windows PC returns a different result for the same request:
The obvious difference is of course the public IP, but there's also a more subtle difference: The DNS server's address 192.168.120.10 is identified as unknown.
This would indicate that the respective DNS address was handled by an alternative DNS server instead of Pi-hole.
That would be further supported if the respective DNS requests would not register in Pi-hole's Query Log.
If that would be the case, something would intercept and redirect DNS requests in your network or on the client that issued the lookup.
The usual candidates would be routers, VPN client software or an anti-virus package's DNS feature (like AVAST RealSite or AVG SecureDNS).
That sounds plausible. I'll check whether the Unifiy Dream Machine is “manipulating” the DNS queries.
In the end it was a mixture of Unifis Dream Machine Pro Ad Blocking feature and wrong settings in the pi hole (after playing around and clicking on every checkbox).
Thanks for pointing me to the right direction. Now it works again perfectly.
1 Like