Expected Behaviour:
PiHole dashboard no longers lists queries from IPv6 clients, yet it will list recent queries from IPv4 clients.
Actual Behaviour:
This changed in the most recent update
Debug Token:
[[[ Redacted for privacy ]]]
your RA is handing out 2600:4040:b4ca:f300::1 as the IPv6 DNS server. thats the router, so phones/pcs on v6 are probably asking the gateway and never hitting pihole. v4 still works because those clients are pointed at the pi.
on the router, set the LAN IPv6 DNS / RDNSS to your piholes GUA or ULA (or the link-local if thats what you use), not the routers own address. then renew a client and check Query Log again.
side note from the debug: refreshNames = "IPV4_ONLY" only affects name refresh, but id flip that to ALL once DNS is actually going through the pi on v6.
I redacted your OP for privacy reasons.
Better run the debugger:
sudo pihole debug
And when asked if to upload the debug log, answer with yes.
On successful upload, a token URL is presented to you.
Copy paste only this URL to here where only the developers and mods have access to.
Retention is 48 hours.
ULA is useless : IPv4 has higher priority so I am not sure if it will be used at all ?!
AFAIK it's something like :
I think even Link-Local is the better choice then ![]()
But since you can resolve AAAA records via IPv4 for your IPv6 connection then basically IPv4 is all you need! ![]()
![]()
Your debug token is: https://tricorder.pi-hole.net/wMwtNLx5/
Interesting is that when I query the db with sqllite3 I see all the transactions. My guess is probably some glitch in the admin web page.
Ahum, the ULA is recommended instead of the GUA:
I dont have access to that Tricorder link so you have to wait for a mod/dev to have a look.
But as pointed out by @nite_route already, it appears your router is most likely advertising its own IPv6 address to the clients for DNS via something thats called IPv6 RA:
Which explains why no IPv6 queries are reaching Pi-hole bc they all go to the router IPv6 address instead.
If you are running Pi-hole bare-metal (not in Docker), you can see what DNS server(s) is/are advertised via IPv6 RA if run below one:
sudo pihole-FTL dhcp-discover
Look for a line that says "Recursive DNS server" (RDNSS).
Dont post unredacted output for above one here for privacy!
Some examples for configuring IPv6 RA RDNSS in the docs --> "Router setup":
Thanks for the reply, the queries are reaching pihole, I can see them when I click on "Query Log", I can also see them when I run sql commands against the db. They just don't show up when I scroll down to "Top Clients (total)" and click on the clients with ipv6 addresses, however clients with ipv4 addresses have output from the query. It sounds like the query that being presented from the web page is not being process correctly.
I guess this never made it to the final document : Preference for IPv6 ULAs over IPv4 addresses in RFC6724 ?!
And I also guess that F.A.Q. topic needs updating since it's written before Pi-Hole v6 existed ![]()
I dont see an issue for preference.
If a client is supplied with both IPv4 and IPv6 ULA addresses for DNS, who cares which one the client chooses/prefers.
Just as long as they are Pi-hole addresses.
The LLA can be an issue though bc it cant be routed (works only for devices connected to the same network segment).
And the GUA is an issue as the GUA prefix is delegated from the ISP and can change over time.
So logically advertising the ULA is the best choice.
But only if the router is capable of advertise a ULA prefix.
And yes that FAQ is a bit old but the principle is still the same.
EDIT: Oh the docs are still current:
I understand what you mean, I have exactly the same problem after the latest update.
I did a complete re-install of pihole, but that didn't solve the problem.
Before it was working perfectly, and I didn't change any settings.
I checked this against FTL v6.7 and v6.7.1: filtering the query log by an IPv6 client works the same on both through the API, with the address URL-encoded or not. To see where it gets lost on your side, please open the query log via the Top Clients link, then your browser's developer tools (F12), Network tab, and post the URL of the request to /api/queries it shows, together with your version numbers.
Found it, it is in the web interface: the query log link encodes the client address twice, so FTL receives %3A instead of : and matches no IPv6 client. IPv4 addresses are not affected, as they contain nothing that gets encoded. This is fixed in https://github.com/pi-hole/web/pull/3888 and will be part of the next web interface release.
Does this "bug" also affect the client IP list dropdown contents in the Query Log filtering section?
(I see no IPv6 addresses in that list though I can see them doing live queries). If this is not related I can open a new topic.
Web v6.6.1 is out with the fix (Do not encode the query log API URL twice - Pull Request #3888 - pi-hole/web - GitHub), so the Top Clients links work for IPv6 clients again. Update with pihole -up, or pull pihole/pihole:2026.10.0 if you run Docker.
@duckasylum That is not related. The dropdown only suggests the 30 most active clients of the last 24 hours, so a client with fewer queries is not listed. You can still type any address into the field and filter by it.
Could this be improved by setting IPV6 custom DNS addresses in the router to ::1 ?
@mikeinanaheim1 No, ::1 is every device's own loopback address, so a client given ::1 as DNS server asks itself and never reaches Pi-hole. Advertise an address of the Pi-hole host instead, ideally its ULA (fd00::/8), as it does not change with your ISP prefix. The query log problem in this topic was a separate bug in the web interface, fixed in Web v6.6.1.
If you can set a custom IPv6 DNS address in the routers IPv6 RA RDNSS settings, you should configure the IP of the Pi-hole host instead.
Like pointed out above, preferably its ULA:
ip -br -6 address | grep ' f[cd]'
Or if no ULA is available/possible as some routers dont have the options to advertise a ULA prefix, configure its LLA instead:
ip -br -6 address show scope link
Disadvantage of that last one is that those LLA's aren't routable and only work for devices connected to the same network segment.
About GUA, LLA, ULA etc, check out the boxes at the bottom of below diagram if not familiar with those:
https://www.oreilly.com/library/view/ipv6-fundamentals-a/9780134670584/ch05.html
Try simply remembering this in the future :
The way IPv6 Localhost is treated by any OS is different than the way IPv4 Localhost is treated by any OS so you can't always use both the same way you were used to when just using IPv4 ![]()