I have two raspberry pi 4's (A and B) with pihole installed, along with unbound. I use a Synology router which handles dhcp. My Lan points to Pi A as a primary, and Pi B as the secondary. For the Internet, the router points to Pi B as the primary, and Pi A as the secondary. Conditional forwarding is active on both pi's.
Thanks
Expected Behaviour:
No or fewer *.in-addr.arpa queries.
Actual Behaviour:
I am seeing 1000+ queries at the beginning of each hour. The debug token is for Pi A which is seeing the queries.
I had the same query a couple of years ago. One way to deal with this is to filter the queries out so they don't appear in the Top Domain Lists or Query Log.
To do this, go to Settings then Web Interface / API. Look in the section Exclusions and enter the following under "Domains to be excluded from Top Domain Lists and Query Log":
EDIT: originally entered wrong string, now corrected:
\.home\.arpa$
\.in-addr\.arpa$
Then go to "Clients to be excluded from Top Client Lists and Query Log" and enter:
\.in-addr\.arpa$
That should clean up your Query Log and Dashboard nicely.
That will cause the arpa queries. Pi-hole needs to know what hostname is assigned to the IP addresses you have set for the subnet to forward to the DHCP server. If this did not happen then all of the Pi-hole web interface sections would only show IP addresses and not the associated hostname.
Edit: You have some ratelimiting going on because the upstream DNS server for your Conditional Forwarding (10.0.4.1) is refusing queries
Mar 3 00:00:03 dnsmasq[754]: query[A] checkip.synology.com from 10.0.4.1
Mar 3 00:00:03 dnsmasq[754]: config error is REFUSED
Mar 3 00:00:03 dnsmasq[754]: Rate-limiting checkip.synology.com is REFUSED (EDE: blocked)
Mar 3 00:00:03 dnsmasq[754]: query[A] rules.emergingthreats.net from 10.0.4.1
Mar 3 00:00:03 dnsmasq[754]: config error is REFUSED
Mar 3 00:00:03 dnsmasq[754]: Rate-limiting rules.emergingthreats.net is REFUSED (EDE: blocked)
Mar 3 00:00:03 dnsmasq[754]: query[AAAA] rules.emergingthreats.net from 10.0.4.1
Mar 3 00:00:03 dnsmasq[754]: config error is REFUSED
Mar 3 00:00:03 dnsmasq[754]: Rate-limiting rules.emergingthreats.net is REFUSED (EDE: blocked)
Mar 3 00:00:03 dnsmasq[754]: query[PTR] 89.4.0.10.in-addr.arpa from 10.0.4.1
Mar 3 00:00:03 dnsmasq[754]: config error is REFUSED
Mar 3 00:00:03 dnsmasq[754]: Rate-limiting 89.4.0.10.in-addr.arpa is REFUSED (EDE: blocked)
Mar 3 00:00:03 dnsmasq[754]: query[PTR] 1.4.0.10.in-addr.arpa from 10.0.4.1
Mar 3 00:00:03 dnsmasq[754]: config error is REFUSED
Mar 3 00:00:03 dnsmasq[754]: Rate-limiting 1.4.0.10.in-addr.arpa is REFUSED (EDE: blocked)
Mar 3 00:00:03 dnsmasq[754]: forwarded 1.4.0.10.in-addr.arpa to 10.0.4.1
Mar 3 00:00:03 dnsmasq[754]: query[PTR] 1.4.0.10.in-addr.arpa from 10.0.4.1
Mar 3 00:00:03 dnsmasq[754]: config error is REFUSED
Mar 3 00:00:03 dnsmasq[754]: Rate-limiting 1.4.0.10.in-addr.arpa is REFUSED (EDE: blocked)
Mar 3 00:00:03 dnsmasq[754]: forwarded 89.4.0.10.in-addr.arpa to 10.0.4.1
2025-03-03 08:00:02.582 GMT [754/T11141] INFO: Tried to resolve PTR "1.4.0.10.in-addr.arpa" on 127.0.0.1#53 (UDP)
2025-03-03 08:00:02.593 GMT [754M] INFO: Rate-limiting 10.0.4.1 for at least 26 seconds
2025-03-03 08:00:04.598 GMT [754/T11141] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2025-03-03 08:00:04.598 GMT [754/T11141] INFO: Tried to resolve PTR "1.4.0.10.in-addr.arpa" on 127.0.0.1#53 (UDP)
2025-03-03 08:00:28.007 GMT [754/T11140] INFO: Ending rate-limitation of 10.0.4.1
2025-03-03 08:49:14.924 GMT [754/T11138] INFO: Received 8/8 valid NTP replies from pool.ntp.org
2025-03-03 08:49:14.924 GMT [754/T11138] INFO: Time offset: -2.194541e+00 ms (excluded 1 outliers)
2025-03-03 08:49:14.924 GMT [754/T11138] INFO: Round-trip delay: 1.158605e+01 ms (excluded 1 outliers)
2025-03-03 09:00:01.012 GMT [754M] INFO: Rate-limiting 10.0.4.1 for at least 27 seconds
2025-03-03 09:00:02.326 GMT [754/T11141] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2025-03-03 09:00:02.326 GMT [754/T11141] INFO: Tried to resolve PTR "1.4.0.10.in-addr.arpa" on 127.0.0.1#53 (UDP)
2025-03-03 09:00:04.342 GMT [754/T11141] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2025-03-03 09:00:04.342 GMT [754/T11141] INFO: Tried to resolve PTR "1.4.0.10.in-addr.arpa" on 127.0.0.1#53 (UDP)
2025-03-03 09:00:28.745 GMT [754/T11140] INFO: Ending rate-limitation of 10.0.4.1
2025-03-03 09:49:15.117 GMT [754/T11138] INFO: Received 8/8 valid NTP replies from pool.ntp.org
2025-03-03 09:49:15.118 GMT [754/T11138] INFO: Time offset: -1.649550e+00 ms (excluded 1 outliers)
2025-03-03 09:49:15.118 GMT [754/T11138] INFO: Round-trip delay: 1.723337e+01 ms (excluded 1 outliers)
2025-03-03 10:00:01.265 GMT [754M] INFO: Rate-limiting 10.0.4.1 for at least 27 seconds
2025-03-03 10:00:02.902 GMT [754/T11141] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2025-03-03 10:00:02.902 GMT [754/T11141] INFO: Tried to resolve PTR "1.4.0.10.in-addr.arpa" on 127.0.0.1#53 (UDP)
2025-03-03 10:00:04.918 GMT [754/T11141] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2025-03-03 10:00:04.918 GMT [754/T11141] INFO: Tried to resolve PTR "1.4.0.10.in-addr.arpa" on 127.0.0.1#53 (UDP)
2025-03-03 10:00:28.501 GMT [754/T11140] INFO: Ending rate-limitation of 10.0.4.1
So what is a sensible way to go forward @DanSchaper ? Should I keep Conditional Forwarding, perhaps filtering out as suggested by @nprampage . I turned them off last night as a test, and the queries have disappeared. For now, the hostnames remain. In terms of rate limiting, if I were to keep the conditional forwarding, what should I set the rate at?
Your router's DHCP server correctly distributes your two Pi-hole machine's IPv4 as local DNS servers:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 6 seconds)
Scanning all your interfaces for DHCP servers and IPv6 routers
* Received 311 bytes from 10.0.4.1 @ eth0
Offered IP address: 10.0.4.8
DHCP options:
Message type: DHCPOFFER (2)
dns-server: 10.0.4.8
dns-server: 10.0.4.172
router: 10.0.4.1
--- end of options ---
Your DHCP clients will use Pi-hole for DNS, and Pi-hole will forward allowed queries to an unbound instance on the same machine.
It seems you have configured a partial DNS loop, with Pi-hole conditionally forwarding reverse lookups to your router, while your router is using Pi-hole as its upstream DNS server at the same time. If your router doesn't know the answer for a reverse lookup, it will query its upstream, i.e.send it to Pi-hole, and Pi-hole conditionally forwards it to your router, and so forth until timeout.
Is there a reason why your router would have to use Pi-hole as upstream DNS server?
Usually, having it distribute Pi-hole as your sole local DNS server would already result in your home network being filtered by Pi-hole.
So if you don't require your router to use Pi-hole as upstream, the easiest fix would be to configure your router's upstream for a public DNS server.
My Synology router is set up where you 'Manually Configure DNS Server', and this is in the Internet section of the Network Centre. Would this be the up-stream DNS server?
Under the 'Local Network', I can also set a 'Primary' and 'Secondary' DNS.
From your post I would assume that I leave the Local Network settings unchanged (e.g. still pointing to pi A and pi B), and update the Internet section to a DNS provider of my choice (e.g. cloudflare/quad9 etc). I also assume I could probably go back and add the conditional formatting setting back in as the loop would have been removed.
Hey, @turop, I used to run a Synology router and got hit by the same issue.
Yes, "Manually Configure DNS Server" under Internet should be a public DNS and definitely not Pihole, or this symptom will occur. Set "Local Network" DNS settings to point to Pihole, and set Conditional Forwarding to point to your router and you'll be set.