Hi all,
Now my Pi-hole is up and running with Unbound, I am having a look at what the dashboard says. However, I am not entirely sure what I should be expecting.
Expected Behaviour:
I would expect to see requests blocked, requests cached, and requests sent to Unbound. I would also expect to only have IPs of services accessed.
Actual Behaviour:
In practice, however, the dashboard also lists my router and an "other" category, and there are apparently numerous reverse DNS requests (IPv4 and IPv6) for the IP of the Pi (192.168.8.101 is the Pi's IPv4 address and I guess, but could be wrong, that the IPv6 address is also that of the Pi; it starts with fe:80 so it should local, right?).
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
There are some DNS queries which are neither sent upstream nor are they cached or blocked (like local SERVFAIL, or some queries used to probe which upstream is the fastest).
If these queries are ignored in the pie chart, it will cause a mismatch on the calculated blocked percentage compared to the value reported at the top box.
You are using Conditional Forwarding.
This is actually forwarding local queries to your router and the chart is showing these queries.
Yes. Your debug log confirms this is the case.
Local queries also show up in the graphics and tables.
They are queries made by Pi-hole itself (pi.hole), and by the OS on which Pi-hole is installed (localhost) if that OS is using Pi-hole (ie, itself) for DNS. They will use IPv6 if IPv6 is available to use, for example if the Pi-hole's OS is running it and other clients on the network are too, especially if the router supports it and it is enabled there.
Yes, especially if conditional forwarding is enabled. Nothing to be concerned about.
Thanks for the explanation. Last thing: would you recommend turning off conditional forwarding and using pi-hole as DHCP server? To be honest, the only reason that I have not done it is because I bought a good router and thought it might make a better dhcp server. That's about the extent of my thinking on the matter...
The advantage of the router is that it can tie its DHCP functions into other functions such as parental control, prioritisation and so on, making them a bit easier to manage.
The advantage of the Pi-hole is that it always tells clients to use itself as DNS server (that can be tweaked if really needed) and it gets access to the client names directly (so no need for Conditional Forwarding). It's easy to manage and probably more up to date than a typical "install and forget" home router.
I use mine for DHCP and never had any problems. Here's a handy tip (assuming your router is .1). Set the Pi-hole's DHCP server range from .20 to .139 ("the low range", 120 addresses) and the router's DHCP range from .140 to .254 ("the high range", 115 addresses). Then turn off the router's DHCP and use Pi-hole.
That gives you 120 usable addresses on the Pi-hole, plus the addresses below .20 for manual static use (eg if you had a NAS you could manually place it on .8, the Pi-hole itself can be .2 and so on). If you ever need to switch back to the router you can turn off Pi-hole's DHCP, turn on the router's DHCP and bounce the clients off and on the network to pick up the change.
The separation of the addresses means the router's addresses won't ever conflict with the Pi-hole's addresses, and you can tell which DHCP server was used by whether it's in the low or high range. It's handy if doing any kind of update on Pi-hole that needs it to be offline for a bit.
@chrislph hmmm.. Working on it right now. It seems to work for my lan. However, how can the pi also hand out addresses to devices on the guest network(s)?
EDIT: For the time being, the pi is set up to distribute DHCP but only to devices on the lan. Other devices still get DHCP from the router (on different subnetworks). As a result, I guess conditional forwarding is still needed, which negates the activation of DHCP on pi-hole. So the question is whether pi-hole is able to assign IP address on different subnetworks. If it can't, then might as well just have the router handle it all, no?
I'm not sure on that one, a dev should be able to advise. The OS can certainly have a static IP on both subnets. There may be a way to service both using dnsmasq's config options directly. The options which Pi-hole sets, including its DHCP interface, are a sort of "subset" of those based on the typical application of Pi-hole.
Commonly, a guest network is a kind of preconfigured VLAN.
It would depend on your router if and how it would allow you to configure inter-VLAN communication with the machine hosting your Pi-hole.
However, while inter-VLAN communication would be enough for reaching a DNS server, it may not be sufficient for a DHCP server: DHCP broadcasts are same-link only, and VLANs constitute separate links, i.e. a DHCP server would only receive DHCP requests of clients connected to the same VLAN.
You'd need a DHCP relay in order to forward DHCP requests to another link.
Again, it would depend on your router if and how it would support that.
You'd have to consult your router's documentation and support for further details.
lan is the correct interface as this is where pi-hole is located
local_address is a static IP on the iot subnetwork that will be indicated as DHCP for that subnetwork (and not assigned to other devices)
server_addr is pi-hole's IP address on the lan subnetwork.
Is that right?
Also, when the description says, for server_addr, "This address must be routed correctly (i.e. you can ping it successfully from the OpenWrt command line).", how exactly do I ensure this?
Would it be an issue to turn off IPv6? I do really have the impression that it's needed. How would one go about this? (router is now running the latest openwrt snapshot for GL.iNet GL-MT6000).
Sorry, maybe I wasn't clear. I mean mean to turn it off entirely, I meant more the constant quizzing of pi-hole for local IPv6 addresses. It feels like the local network could do without IPv6, if that makes sense.
