I had the same problem. In my case, it depended on the integration/component.
I recently switched all the hardcoded IPs in my configuration files to local names instead and I saw a huge jump in my pihole chart (like you did). Requests from my hassio went from the low 100s to nearly 3000 per 10 minute timeframe. I could see which host it was requesting records for in the pihole logs (like you did) and I then used trial and error to back out the changes until I found the culprit.
I came across this after I observed the same issue with my pi-hole/hass setup. I found a solution that seemed to work for me. Posting in the hope that it will help someone else too.
Initially, I disabled the Nmap Tracker integration. All x.x.x.x.in-addr.arpa PTR lookups seemed to stop.
After looking a little more at the integration, and NMAPs options, I reconfigured the Nmap Tracker and added the following to suppress DNS resolution.
This is happening to me as well. Running HASSIO on a RPI4, and it shoots ton of PTR scans through the pihole.
It started doing this recently (perhaps after updatinf to latest HASSIO core??, I do not know what causes /how to stop it
Any suggestion is appreciated
Hope someone figures this out , Iām not using nmap either, it is annoying enough on a /24 network but for a while I was on a /16 and it was trying to do a reverse lookup on every possible host address. Iām sure it did not always do this.
Subscribing because Iām curious. I have these too but was never really that bothered by it. I have an HAOS setup and ship all my logs over to Grafana so I can pretty clearly see the pattern. Every hour like clockwork something makes like 200 PTR requests to the hassio_dns container asking for the hostname of almost every IP address in the range I use for my LAN (192.168.1.x). Nearly all just return NXDOMAIN but it doesnāt seem to matter to whatever is doing it.
There are a few other interesting notes about this data:
I donāt see every number. The logs are missing every IP address which is actually assigned a device. I donāt know if thatās because it doesnāt query those or because the hassio_dns container only logs NXDOMAIN requests though.
It stops at 192.168.1.202 every time. Another mystery, the range goes to 254 and nothing above 80 or so is assigned.
I do run adguard. I guess that could be it? Would be weird though because Adguard is my DHCP server, dunno why it would be asking anyone else to do reverse lookups on my LAN for it. And even if it did I would think it would be asking my gateway. To my knowledge the adguard add-on doesnāt know anything about hassio_dns, rather hassio_dns asks it to resolve external requests a lot.
These PTR requests say their source is 172.30.32.1. Thatās the gateway of the hassio network not sure that really means anything we didnāt already know (its coming from somewhere in HA)
I was wondering if this was zeroconf. I know zeroconf is a key piece of discovery and is scanning your network for supported devices and I believe it uses DNS to do this based on the code. But I donāt really see anything in there that would suggest an hourly schedule so Iām not really sure.
EDIT: Oh wait, I think I was looking at the wrong core discovery integration, I think its dhcp. That one clearly does have a 60 minute schedule right here
I see these PTR requests in adguard. So looks like hassio_dns logs the failures but passes all of these on to adguard. I find adguardās query log very confusing since it doesnāt seem to be sorted by time and I canāt sort by any of the columns but when I started searching for individual PTR requests I found the pattern. Interestingly what seems to happen is there is a PTR request once per hour for unused addresses and once every 10 minutes for addresses actually in use, no wonder these numbers are so high.
I removed the dhcp component from my configuration.yaml after my initial post about an hour ago. There has been no PTR requests since then. Will continue to monitor but definitely starting to look like the culprit.
