tl;dr: Pihole should use the link-local-IPv6-address as default.
i recentlty diagnosed a problem with a recent Pihole-Installation at a friends network.
A lot of Webpages on android loaded quite slow and the reason for that was that Pihole resolved some blacklisted domains to the configured IPv6-Address.
The IPv6 in question was 2003:f2:....
The prorblem here in Germany is that certain ISPs don't offer static IPv6-Prefixes, these tend to change on Router reconnect. And if these changes, lookups for IPv6-Domains on Blacklist are resolving to IPv6-Addresses with the old prefix.
To fix that i configured Pihole to use the fe80::... (link-local)-Address
We use the ULA if it's available and that's a more stable address. It's not as volatile as the ll, since that can change depending on privacy extensions, the particular network segment the interface is attached to and a handful of other cases that cause rotation of that address.
We are aware of the rotation of GUA's and the problem that causes. The installer will check for a ULA and suggest that, it will not use GUA if there is a better option to select.
In this case there only was a GUA and a link-local-address beginning with fe80 and in some routers one can't activate the usage for ULAs in in the fc/fd-range.
That case is rather rare from what we've seen. Defaulting to a link local is problematic, as it just exists on that single link. The ULA is the preferred approach, by definition though they have to exist in fc00::/7 space. The installer would have allowed the GUA to be entered as in this case there was no ULA as an option. I'm not sure if we can code around a case where ULA is not possible, perhaps a tiered approach of ULA > LL > GUA, but that may be a bit inelegant to implement. @DL6ER do you have any thoughts on this?
Hmm, the implementation is not what bothers me, that should be doable fairly straightforward. I'm more wondering about the implications, i.e. if it would make things worse. Example: many users have a non-changing GUA so there is in fact no issue when ULA is not available. Now, what happens if we give these people a LL as default instead? Will all devices be able to reach it?
Thinking about scenarios where they are not strictly on the same link level:
Pi-hole connected over Ethernet, clients connected over WiFi (that may work)
Clients connected over VPN
I think we need to clarify this before implementing.
@bonsi I'm a Deutsche Telekom user myself and equally affected by their GUA rotation. That was the reason for my ULA implementation as my Speedport allow enabling them with a simple click. I've recently switched to a DD-WRT based router and don't use ULAs any longer because with the new NULL IP based blocking of FTLDNS a static IPv6 address is not needed any longer. Maybe this is something you want to try as well?
I'm in agreement with all the points. My primary issue would be with off link devices, any router will drop the Link Local, so only the local collision domain would be able to speak to the Pi-hole. VPN, vLAN, off-link would all no longer be able to use the Pi-hole for DNS resolution as any packets they send with that address would be dropped at the edge of the segment. It's been my understand and practice that Link Local addresses are only for bootstrapping an interface to get it to the condition where it can negotiate DAD with neighbors and to receive stateful addresses.
I think it may get unnecessary with FTLDNS and its more refined blocking methods.
We could also have FTLDNS hand out
NXDOMAIN for AAAA queries to ads, and
the correct IPv4 of the Pi-hole for A queries.
In theory (just speculating here, I haven't tried anything) this should make all clients fall back to the IPv4 IP for obtaining the blocking page and vastly simplify things.
What do you think @DanSchaper@jacob.salmela ?
NXDOMAIN isn't the proper response for that kind of set up, but I get what you are going for and with the right technical implementation, yes it would work. Clients would receive the message that there is no AAAA record and would fall back to the A result and use that IP for the transit. I'm in favor of it, cleans things up!
Thanks