The change is that with the most recent version, we also try to get host names for devices in your network which are not actively using Pi-hole. Assuming your devices made only (or at least mostly) queries over IPv4 to your Pi-hole, we haven't tried to resolve their IPv6 host names before.
We're already looking into this. The issue itself comes from the growing number of temporary IPv6 addresses being enabled by default in Windows and Mac (if I recall correctly). My proposed solution is to add a new option REFRESH_HOSTNAMES which which you can change how the hourly PTR requests are made. I'm currently thinking about three options:
REFRESH_HOSTNAMES=NONE - Don't do any hourly PTR lookups
This means we look host names up exactly once (when we first see a client) and never again. This means we will miss future changes of host names.
REFRESH_HOSTNAMES=IPV4 - Do the hourly PTR lookups only for IPv4 addresses
This is planed to become the new default and should do away with the issue.
REFRESH_HOSTNAMES=ALL - Do the hourly PTR lookups for all addresses
This is the same as what we're doing right now with FTL v5.3
This - including the new default IPV4 should resolve this issue. What do you all think? Any suggestions for improvement/additional options?
Thank you for being so responsive. I like the idea of having optionality so that the user can control their own experience. In the meantime I have downgraded to the previous version, so will wait until this is implemented.
and continue to monitor the PTR request spikes (hopefully, there are none). As mentioned above, I have the new option REFRESH_HOSTNAMES defaulting to IPV4. You can also try to switch to NONE to get completely rid of trying to resolve clients hourly.
Any testing is highly appreciated as my local testings always only happen in a rather quiet network without any Windows or Apple devices.
You can always use pihole checkout to go back to v5.2 if this does not yet address the issue sufficiently.
Great to see a proposed solution! Just wondering assuming the fix properly solves the issue, is there a way to automatically go back to master or does it need to be done manually?
The update script will only always update the current branch for the respective component of Pi-hole you checked out. For instance, if you ran
pihole checkout ftl release/v5.2
your FTL version will always stay fixed while the other components (core and web interface) will still update. You'll have to run
pihole checkout master
at any point to get back on track with all the components.
Yes, it has to be done manually. However, timing is uncritical. You can set FTL back to master before or after installing the update. This (typically*) doesn't matter.
*) On major version jumps, like to a future Pi-hole v6.0, synchronicity is typically important to respect severe changes in the machinery. However, such an upgrade will (read as: should) never come as a surprise as we're always doing a long beta period.
You have to add it yourself to /etc/pihole/pihole-FTL.conf
If the option isn't there (or the file does not exist), the default value will be used.
Run pihole restartdns after modifying the file to re-read the config file.
You should have your entire Pi-hole updated to the most recent version before switching branches. It may still work how you did it, but run
The fix certainly seems to deal with the issue, at least using the default IPv4 mode. I haven’t tried the other modes. Thank you!
A small aside - I note now that my top clients list on the dashboard shows localhost for the IPv4 localhost (127.0.0.1), but only ::1 for the IPv6 localhost. Not a big deal, but it is a little odd, since the list of known clients under Group Management does include ::1 as an address for the localhost hostname/domain. So I would have thought the top clients list would also use that hostname/domain for IPv6.
Hello!
I'm experiencing a similar problem since I updated my Pihole yesterday. After the update, I see exactly 234 PTR requests from 127.0.0.1 every hour. But these requests are IPV4. All these requests get answered from cache.
The dashboard says I have 19 clients. Network overview shows 14 green devices, 5 yellow, 43 light red and 10 red.
Before the update, I never had that many hourly requests. I can't explain where these requests come from, because my Pihole only knows 72 devices including the red and light-red ones.
Am I experiencing the same problem as described in ths thread?
I guess the "disable PTR for IPV6"-method will not work for me because my hourly requests are IPV4?
My debug-token is: https://tricorder.pi-hole.net/ju809xxgle
Screenshot about my previous post:
Last night at 2am I made the update. Now I get these spike with exactly 234 Requests from localhost every hour. (IPV4-Requests, no IPV6!)
Also, but this is just a small problem, my statistics are useless now when 234 requests gets answered from cache every hour...
