Hi Dan,
yes, two MacBooks and a IPhone
If there are IPv6 addresses that have queried Pi-hole and you want to know the hostname associated to that IPv6 address then I think this is what you are going to see. Pi-hole doesn't have any way to know if a host has changed it's IPv6 address after it used Pi-hole. I know the recent Apple iOS added security features that changes IPv6 addresses to prevent identification and this is preventing us from identifying the clients.
It's up to you to decide if you want to disable those features or disable IPv6 until you can find a setup that works for your particular needs. I personally don't see a need for global IPv6 addressing on a LAN segment but that viewpoint has caused a number of IPv6 fans to call me various names and slurs so I now leave that decision up to the user.
yes, I'm with you about the IPV6 in a small LAN. The irritating thing for me is that these Localhost queries startet after the Pihole update yesterday. None of the Apple devices has gotten an update.
Hi Dan so I'm not too network saavy (just good at following guides and directions). So I have disabled ipv6 on my router as well as done pinole -r to reconfigure and deselected ipv6. However my diagnostic token shows that it's listening on ipv6.
Are you saying that this original issue I mentioned would be resolved if I disabled ipv6? If so, how can I ensure that happens? Like I said I thought I did that already but it seems something isn't sticking because if you look at my original post I saw in the diagnostic that pi-hole is listening on two IPV6 addresses but it's saying it doesn't match.
That's a detection to see when things are not listening when we expect them to. It's okay to be listening when there is no queries being sent. (It's listening on the IPv6 loopback address that always exists unless you disable IPv6 in the linux kernel.)
Edit: Listening on fe80 is fine, that's an internal address called a link-local, it's similar to 127.0.0.1 in IPv4 land.
so I show two under "IPv6 address(es) bound to the eth0 interface:". I see the fe80 like you mentioned as well as a fddb address. This should be reflected in the debug log.
So all that to say, what can/should I do to stop this practice of the pi-hole running these reverse DNS requests every hour?
I also have many Apple devices, but I have turned off "Private Address" for all of them.
You also recommended that I disable IPV6 when I asked about getting odd BOGUS results when DNSSEC is turned on (Getting BOGUS results only from specific domains - #2 by Coro). Apologies for not following up, but I ended up just turning off DNSSEC since turning off IPV6 on my router and Pi-Hole did not help.
I am also seeing this behaviour since (and only since) updating to the latest release two days ago.
The graph below gives an indication of the changed behaviour:
The PTR requests from the Pi-hole that spike every hour are both on IPv4 as well as IPv6 - in fact the majority are for IPv4. Edit: Correction - while the majority are from the IPv4 localhost (127.0.0.1), they are primarily for IPv6 addresses. The fact that this only started after updating Pi-hole suggests to me that something is not quite right with the update. I don't accept that the solution is to turn off IPv6 - that is a bandaid at best.
The behaviour renders the query log graphs mostly useless as the Pi-hole PTR requests dwarf everything else. Worse, anecdotally there is degraded network performance when these spikes occur - presumably because the pi-hole gets overloaded with queries and therefore DNS resolution is affected.
It would be greatly appreciated if this could be looked into.
2 Likes
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.
Anyone who want to try my idea can now run:
pihole checkout ftl fix/hourly_PTR_requests
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.
1 Like
it seems to work:
These spikes up to 2200 queries are gone, there are 7 to 10 localhost queries now.
1 Like
Thanks for testing @Frank_S the fix is ready for review and testing by the core team as
If everything goes well and we can allocate enough time in the team for testing, the fix should become live for everyone hopefully rather soon.
1 Like
I've installed the test FTL version (Web UI is showing FTL version as vDev-b833b73) and will report back on my experience.
I can't find though the REFRESH_HOSTNAMES option? Is it meant to be in setupVars.conf or somewhere else?
Note I switched to the test FTL version from FTL 5.2 - should I switched to FTL 5.3 first?
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
pihole checkout master
pihole checkout ftl fix/hourly_PTR_requests
just to be on the safe side.
OK, I now switched to master first and then to the dev fix.