I'm running Pi-hole on a Raspberry Pi 4 running Bullseye. Pi-hole v5.8.1, AdminLTE v5.10.1, and FLT v5.13
My router is a UniFi UDM Pro, which doesn't allow ULA setup. I get a /56 GUA subnet through my ISP. I have a few Thread-enabled devices on my LAN which create unique ULA's for their traffic.
My issue is Pi-hole chooses to use the constantly changing Thread subnets rather than the static GUA IPv6 I've assigned it in /etc/dhcpcd.conf and in /etc/pihole/setupVars.conf, and is reachable.
I know that Pi-hole prefers a ULA over GUA, as the latter can change. However, why is it ignoring the user-assigned IPv6? any help or insight would be greatly appreciated.
Below are my outputs (edited to remove identifying info)
$ dig pi.hole ANY
; <<>> DiG 9.10.6 <<>> pi.hole ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24102
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;pi.hole. IN ANY
;; ANSWER SECTION:
pi.hole. 0 IN A 10.0.0.9
pi.hole. 0 IN AAAA fd69:####:####:####:####:####:####:57c2
;; Query time: 1 msec
;; SERVER: 2603:####:####:####::9#53(2603:####:####:####::9)
;; WHEN: Thu Jan 06 15:13:15 PST 2022
;; MSG SIZE rcvd: 80
I do not see an issue here:
From a client perspective, it doesn't matter what IPv6 address is returned for pi.hole as long as the Pi-hole host machine is reachable via that address.
Your debug log suggests that to be the case.
In general, I'd recommend against assigning a static GUA IPv6 address.
While you may be able to avoid potential configuration issues if you know what you're doing, you don't control the IPv6 prefix of that address - your ISP does.
Depending on your country of residence and your actual ISP plan, that prefix would be subject to change regularly (like once a week or one every 24 hours) or upon router reboot or exchange.
If that happens, not only will your static IPv6 become unusable, but because of using a GUA, your DNS requests may even be leaving your private network.
Also note that by using a GUA, a precondition of publically exposing your Pi-hole instance would be met, and you'd run the risk of turning it into open resolver (which the Pi-hole team strongly discourages to do).
Thank you for your reply. DNS resolution happens mostly over IPv6 and is working normally. Your concern with assigning a static GUA is right, but the Pi still gets a GUA from SLAAC and another from DHCPv6.
For the prefix, I haven't asked my ISP Spectrum directly, mostly because I don't know how to ask to be routed to a person who knows what they're talking about with IPv6. The first line reps certainly don't. However, when I request a /64 subnet and get one, it changes every time I reboot the router or modem. On a /56 subnet, it hasn't changed once with many reboots. My assumption is it won't change, since expecting customers to change change configurations for 256 subnets would cause quite a backlash.
I don't have port 53 forwarded, so inbound DNS requests are dropped by the router and don't reach Pi-hole.
To not get away from the underlying issue. How could it not be an issue if Pi-hole ignores a user-assigned value? regardless whether it's correct or not. It's the user's responsibility if they break their configuration. But in this case, it works fine sending requests to the static GUA.
I still don't see an issue.
You may misunderstand the purpose of those IPVx_ADDRESS settings.
The IPV4_ADDRESS and IPV6_ADDRESS variables in setupVars.conf were originally intended to control the IP address that Pi-hole should answer when configured for one of its IP or IP-NODATA-AAAAblocking modes.
Since Pi-hole FTL v5.8 (see section Automated IP blocking mode), Pi-hole dynamically determines the address to use based on the query received. Strictly speaking, the respective IPVx_ADDRESS settings have become somewhat obsolete since then.
The purpose of providing name resoluton for pi.hole is to allow access of Pi-hole's web UI via that name. That purpose is accomplished when providing an address that is accessible for a client.
It seems that does work in your case? Please elaborate if it wouldn't.
And as far as Pi-hole's DNS operation is concerned:
Interface listening behaviour is controlled by a separate set of UI settings of its own.
I agree that Pi-hole could answer the full set of IPv6 addresses associated to its host for pi.hole.
On the other hand, just providing a single address makes for a smaller size answer, and it spares your clients from selecting a suitable address from a set.
The problem seems to be deeper than I thought. Running dig netpi ANY the hostname of the Pi that Pi-hole is running on, returns the same result as dig pi.hole ANY
$ dig netpi ANY
; <<>> DiG 9.10.6 <<>> netpi ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59050
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;netpi. IN ANY
;; ANSWER SECTION:
netpi. 0 IN A 10.0.0.9
netpi. 0 IN AAAA fd69:####:####:4####:####:####:####:57c2
;; Query time: 1 msec
;; SERVER: 2603:#####:#####:####::3c#53(2603:####:####:####::3c)
;; WHEN: Fri Jan 07 16:58:46 PST 2022
;; MSG SIZE rcvd: 78
Pi-hole is not returning other IPv6 addresses that dhcpcd is picking up whether SLAAC or DHCPv6. I also disabled the static IPv6 assignment and ran pihole -r and rebooted, but that did nothing.
I can only repeat myself:
Your observation matches the expected behaviour.
If that expected behaviour would be causing issues for you, please elaborate:
Is Pi-hole's DNS operation not working?
Are you unable to access Pi-hole's web UI via pi.hole?
Pi-hole indeed favors ULA over GUA over LL as you've described above. Also
is expected as getting the addresses is a (somewhat) complex task. We have seen Pi-holes running in machines with over 20, partially virtual, interfaces. Whenever a query arrives, we talk to the kernel and request the current addresses of the corresponding interfaces. We cannot ask for specific interfaces, just "give me the network config" because selection works only per address, not per interface.
Hence, we loop over all addresses until we find an ULA that matches the interface. We then exit early from the loop over addresses to save time.
This shortcut could be removed, revealing more addresses at additional costs. We'd also have to allocate more memory to allow storing more than one address.
However, I do fully agree as @Bucking_Horn said above:
This is another motivation for why we chose what we have. We had issues in the past with clients caching the IPv6 GUA of a Pi-hole device. Whenever the prefix changed, the Pi-hole wasn't reachable because the NAS they had it running on immediately stopped listening on expired addresses instead of giving them some grace time. Even when this is surely an edge-case, I don't want to break things for them.
Concerning your ANY request, I'd like to refer to RFC 8482 which basically deprecates ANY. Check out this blog post about deprecation of ANY from Cloudflare if you prefer reading this instead of the RFC (very understandable decision):
Given that ANY is going to be removed anywhere sooner or later, I don't see much justification for changing the Pi-hole code to return multiple addresses. How about a compromise of not returning multiple addresses but adding a config option allowing you to specify if the address-searching algorithm prefer ULA (default) or GUA or even LL?