Hey there!
I configured pihole with unbound on Dietpi on OdroidN2 and got some blocking lists, activated and updated them. Then I set every client to use the IP of the pihole (IPv6 is deactivated). But if I check queries, I see nothing there. If I check the DNS via DNS leak test, I get the ISP router DNS.
So no blocking works, despite the fact, that pihole is set as DNS server on clients.
Here is the token: https://tricorder.pi-hole.net/xvLiXRWA/
Cheers
pihitch
Are they not using DHCP to get their network addressing? Your log shows that your Pi-hole is working on address 192.168.2.33. Try running these commands in a terminal window from a client which you believe should be usinng your Pi-hole:
nslookup pi.hole
nslookup flurry.com
nslookup flurry.com 192.168.2.33
Your router is the DHCP server and it is telling clients to use itself as the DNS server.
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
...
DHCP options:
Message type: DHCPOFFER (2)
server-identifier: 192.168.2.1
lease-time: 3600 ( 1h )
netmask: 255.255.255.0
router: 192.168.2.1
>>>> dns-server: 192.168.2.1
wpad-server: "http://192.168.2.1:81/proxy.pac"
ntp-server: 192.168.2.1
domain-name: "localdomain"
--- end of options ---
In your router settings go to the DHCP section and edit the DNS server entry and change it from 192.168.2.1 (your router) to 192.168.2.33 (your Pi-hole).
While you're in there, if you have the option of "reserving an address" for clients, make sure the Pi-hole always gets that .33 address from the router, so that it has a static IP.
Once done, disconnect and reconnect your devices from the wireless, or unplug and replug the network cables, to make sure they pick up the changes. They should then start using Pi-hole and you'll see them appear in the Query Log when you refresh it.
Server: 10.139.1.1
Address: 10.139.1.1#53
Name: pi.hole
Address: 192.168.2.33
what is 10.139.1.1?? Did not set it
Server: 10.139.1.1
Address: 10.139.1.1#53
Name: flurry.com
Address: 0.0.0.0
Name: flurry.com
Address: ::
Server: 192.168.2.33
Address: 192.168.2.33#53
Name: flurry.com
Address: 0.0.0.0
Name: flurry.com
Address: ::
the thing is, I'm behind ipfire. And there I can not set the pihole as DNS. It shows me an error. Did not solve it yet.
But no client uses DHCP within my network. So it should be no problem, for no client should use the DNS of the router/ipfire. Their DNS is set to pihole.
Whatever it is, it's the default DNS server that that client's requests are going to. And yet it is resolving names via Pi-hole. This implies something system-level. The IP, and the 10.139... range doesn't appear in your debug log.
Since the query was ultimately resolved by Pi-hole, what do you see in Pi-hole's Query Log when you run these tests? Are they appearing in there?
Note that because you are using Unbound in recursive mode (assuming you used the Pi-hole Unbound guide), DNS leak test will show your external IP address as the address of your DNS server. That is normal – to DNS leak test that's where your Unbound queries seem to be coming from, since you are running it on your ISP connection.
Your debug log shows your Pi-hole is working, and the first two nslookup commands show that Pi-hole is recognised and that a known ad domain is being blocked.
Apart from the mystery IP address, everything appears to be working. Double check your OS DNS settings, and check that queries are indeed appearing in Pi-hole's Query Log.
could it have smth to do with unbound? Because I set no such IP and no such range. It must be an automatical setting of some service within pihole or dietpi.
Query log shows nothing. But the dashboard shows some queries over last 24 hours. If I click on one of them, it shows me nothing.
ah, good to know. because I don't understand unbound in it's depth.
I see the problem. Your privacy level is set to Anonymous mode. Go to Settings > Privacy and choose the top option to enable the normal Query Log.
Then run the nslookup tests again and confirm they appear in the Query Log. You'll see other things in there too from your other clients.
The install guide linked earlier walks through the process of how it works usually, without Unbound, and how it works with Unbound in recursive mode. Since all these queries come from your IP address, that is the address that DNS leak test sees as the DNS server. It shows the ISP which this IP belongs to, and that can make it seem like you're using your ISP's DNS when in fact it is your own.
Check your public IP at this site. It will match the DNS server that DNS leak test says you are using, ie it is you.
yesss! thanks! I forgot that as I activated the logging.
now I see the blocking of flurry and also the blocking of facebook, according to the blocking list I added.
canyoublockit shows also that the addblocker seems to work.
I also disabled DHCP in the router and set the IP of pihole in /etc/resolve.conf of dietpi (there I had the ip of the router). Maybe it has smth to do with the problem.
BUT, what is 10.139.1.1 and why does it working on normal nslookup??
I suspect this is something specific to DietPi. Your debug log does not mention this IP at all, but your debug log is running inside the Pi-hole environment on there. Am I right to say that DietPi can do some sort of environment partitioning, akin to Docker? (pinging @MichaIng).
Do you have anything else running on there, maybe some VPN type application? I'm thinking that your DietPi Pi-hole in fact has multiple IPs, visible from elsewhere on the network such as the machine you're running these tests from, while Pi-hole can only see the one it is using.
Try running the command
arp -a
Do you see that IP address and your Pi-hole IP address? Does they have the same MAC / Physical Address?
If Pi-hole was installed via dietpi-software, it is bare metal, in fact using the official Pi-hole installer, but allows to choose between Apache, Nginx and Lighttpd as webserver, uses PHP-FPM (instead of CGI) and allows to optionally have Unbound installed and configured with it (close to the Pi-hole Unbound guide).
The 10.139.1.1 IP indeed looks like a VPN or other dedicated network this client is connected to, and which also Pi-hole is (obviously) connected to as well. Some WireGuard connection probably? At least it is not the default dietpi-software WireGuard server install option, which uses 10.9.0.1/24 and OpenVPN would be 10.8.0.1/24 by default. Unbound has nothing to do with it, which sits completely passive behind Pi-hole.
I don't think wireguard (or any other VPN) is involved here.
The debug log shows none of the usual tun0 or wg0 VPN interfaces - in fact, it only shows eth0, and the routing table has only two entries:
*** [ DIAGNOSING ]: Network routing table
default via 192.168.2.1 dev eth0 onlink
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.33
This looks perfectly normal.
I'd put my bets on IPFire then.
I think IPFire would propose 10.0.0.0/8 range IP addresses for its DMZ, and it seems just like the tool being able to force traffic through its gateway to a specific DNS server on a different subnet, while taking care of routing to that subnet at the same time.
I also think, that it has to do with dietpi. I have nextcloud running on this device. But no VPN.
it shows me just some connected devices, but nothing with 10.x.x.x
Indeed, I use wireguard, but not on the device running Dietpi and pihole. Pihole is used on the extra VPN device as DNS. Installed software on dietpi: nextcloud with lighttpd/mariaDB/PHP, Certbot, Fail2Ban, pihole, unbound, redis, git.
the thing is, pihole doesn't run in DMZ (there I set the VPN device). It just runs in the GREEN of ipfire.
And the mystery is, that I did not set any DNS server with such IP. My DMZ IP range is also different to 10.139.x.x
I suppose, that's the point. It seems to be some virtual partitioning within dietpi.
MichaIng already explained that Pi-hole is a bare-metal installation when using DietPi's installer, so there is no virtualisation.
There are no indications that DietPi would be involved.
I didn't suggest it would, nor does it have to.
I suggested that the 10.139.1.1 address could be an address handled by your IPFire.
As that address is not on-link, it could be on any network that your network knows a route to, including your DMZ.
But now that you mention:
At the time you ran that nslookup, would the client that you ran it from have been connected to your network via wireguard?
Then that 10.139.1.1 could be the wireguard internal IP of your wireguard gateway.
nope, it has different IP.
The client, I used to nslookup was not connected via wireguard, just wifi.
Now is no client connected to wireguard and nslookup shows the strange IP.
that's really weird.
Ah... maybe it's the fact, that I'm using QubesOS on the client. So it's the virtualization within the client. I think, that must be the point. Isn't it?
That would seem highly likely. 
From QubesOS docs on Setting up networking for HVMs
The DNS IP addresses are
10.139.1.1and10.139.1.2.
yesss! Does it make some troubles in my case? I think, no.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.