After a glitch, I had to re-set up my home network and it feels like something is off. I now run the latest snapshot of OpenWRT on my GL.iNet Flint 2 and have pi-hole on a raspberry pi plugged into it, on the lan. In addition, I have a guest network and an iot network. Both pretty much the same, but just to keep guests separate from iot devices. Pi should handle DNS and the router DHCP.
What feels wrong is that the router is making a lot of PTR requests a bit all the time, and sometimes requests from the router shoot off and the router goes beyond the 2000 limit.
I feel like I may not have set up my pi as dns properly this time around, but cannot seem to find a definite guide to doing it. For instance, in network > interfaces, should I put the pi's address both in "advanced settings > Use custom DNS servers" AND in "DHCP servers > advanced settings > DHCP options" (as "6,[IP])? Also, in the wan interface > advanced settings, should I uncheck "Use DNS servers advertised by peer"?
Easy solution would be to configure your router WAN settings to use a public (non-Pihole) DNS but let it tell LAN clients to use the Pihole. Not an OpenWRT user, but from your description it seems the "Use custom DNS servers" option should be set to a public DNS (either your ISP or Quad9, Cloudflare, etc.) and the Advanced Settings/DHCP Options should have the Pihole IP address.
The "Use DNS Servers Advertised by Peer" is your choice, as it typically just adds the ISP-provided DNS servers in addition to what you have specified for a public DNS server.
it seems the "Use custom DNS servers" option should be set to a public DNS (either your ISP or Quad9, Cloudflare, etc.) and the Advanced Settings/DHCP Options should have the Pihole IP address.
I see. But what would be the point of providing an outside DNS if I don't plan on using it?
typically just adds the ISP-provided DNS servers in addition to what you have specified for a public DNS server.
Now that sounds like something I really want to avoid, actually.
The DNS for the WAN is typically just lookups performed directly by your router (time server lookups, maybe chatter back to the manufacturer, DDNS services you use those, etc.), not the LAN devices attached to the router. True, you would bypass Pihole for these router-based lookups, but it's typically just the kind of traffic you're trying to filter out as originally reported anyway.
That's worth a try. Actually, i just realised that for the wan interface, there was nothing provided for "Use custom DNS servers". I put Quad9 for now.
However, the top quizzed (and permitted) domains are on the local network. So I'm guessing this won't be affected by wan settings, right?
Those *dns-sd.* domains are RFC6763 DNS service discovery requests as used by zeroconf clients, often in conjunction with wide area mDNS (like Apple's Bonjour or Linux' avahi), to gather information about services in your network, e.g. to allow discovery of AirPrint printers.
Pi-hole just receives and answers those requests.
If no such services are available (which they usually are if you didn't explicitly configure them), you'd see an NXDOMAIN reply, which should stop clients from further searches.
You could try to single out the clients that issue those requests and control their behaviour, e.g. by disabling their mDNS stack (provided you would not rely on it).
That would suggest that your router has been using Pi-hole as its upstream.
If at the same time you'd pointed your Pi-hole to use your router for DNS, e.g. by enabling Pi-hole's Conditional Forwarding to your router, then that may have closed a (partial) DNS loop, potentially contributing to your rate limit observation.
Thanks. But, if all this is local, shouldn't the router have the answers, since it's responsible for dhcp? I even gave static leases to all devices, thinking that would make it clear to the router and the router would have the answer..
You could try to single out the clients that issue those requests and control their behaviour, e.g. by disabling their mDNS stack (provided you would not rely on it).
Dunno if that answers your question, but pi-hole says the "lb._dns-sd._udp.0.8.168.192.in-addr.arpa (or similar dns-sd requests) are made by the router itself. Surprisingly (to me), 192.168.8.0 isn't assigned to any device (the router is 192.168.8.1, for instance).
That would primarily depend on the router, and then on the specific domain requested.
Commonly, a router's DHCP server may register hostnames with its colocated DNS server, but that's not a specification requirement.
You should check how your OpenWRT is configured in that regard.
Even if it does run a DNS server with properly maintained local DNS records, clients may send requests for names that your router's DNS does not know how to answer (or not anymore), e.g. by unknown plain non-dot domains, or domains expanded by the local search domain (which both would close the partial loop with CF).
Thanks for the help. Since I can't really change my DHCP server to pi-hole, it really feels like it's a router/openwrt issue. I'll keep trying on that side.
Quick clarification: when you say that pi-hole is the router's upstream server, do you mean the dns server indicated for the wan interface? Because, if so, I have already added Quad9 under "Use custom DNS servers".
As for the solution you provide, I assume it's mean to handle not the PTR requests from the router, but the ip6.arpa requests from pi-hole itself, is that right? Because those are also quite numerous. However, I am not sure I understand what those are (since they are not the same as the PTR requests from the router that we mentioned above).
This actually looks promising, although let's see when the router restarts in the morning.
However, it focuses on router requests and therefore does not address the (also constant) ip6.arpa requests, as well as the 2.8.168.192.in-addr.arpa requests all made by pi-hole (192.168.8.2 is the pi itself).
I understand that pi-hole may need to requests things, but quizzing this literally every 30 seconds seems more like a bug, no?
Hi @Bucking_Horn, so indeed the page I linked to before did solve the situation, which is great. All the in-addr.arpa requests relating to the local network are gone.
However, I note that pi-hole itself is still quizzing for reverse dns lookup like there's no tomorrow. Do you know what these requests are about? fe:: and fde:: are also local addresses, no?
If I understand correctly, then you've now configured your router's dnsmasq instance to answer all private range reverse lookups strictly locally, not forwarding them upstream.
You should be aware that this would deprive your router from reverse querying Pi-hole for any local DNS names as defined by Pi-hole itself.
Of course, this would be relevant in particular if your router would be using Pi-hole exclusively as its upstream DNS server.
Pi-hole would issue reverse lookups for its observed client IP addresses once every sharp hour, in an attempt to learn currently associated hostnames.
Note that while DNS requests are required to identify client IPs as source, they do not hold any information on the actual process that issued the request.
Your observation would suggest that another process on your Pi-hole host machine would generate those queries.
If I understand correctly, then you've now configured your router's dnsmasq instance to answer all private range reverse lookups strictly locally, not forwarding them upstream.
Yes, I guess that's the result. But we're really talking about locally, right? And not to a DNS server set for the router? I had set Quad9, but this should not do anything for local IPs.
You should be aware that this would deprive your router from reverse querying Pi-hole for any local DNS names as defined by Pi-hole itself.
I understand. However, since dhcp is handled by the router, there should not be any names attributed by pi-hole, right? At least, I have not configured any in pi-hole.
Of course, this would be relevant in particular if your router would be using Pi-hole exclusively as its upstream DNS server.
The router should still be able to use pi-hole as upstream DNS server and it does. As I understand it, we only requested that specific lookups be handled locally by the router.
Could you provide a fresh debug token?
Sure. Ain't home at the moment, but I am happy to send that when I am.
