Pardon my ignorance, but would this new behaviour be considered a bug or a feature? Is there anything I can do to remedy this? I really would like the IPv6 DNS address to come from Pi-Hole, not the router, as the router just uses my ISP's DNS addresses in turn, (rarely) bypassing Pi-Hole (despite the DHCP server in the router being turned off). It means having to manually modify clients' DNS settings, which is very tedious.
1 Like
We do not have yet established that different versions of dnsmasq are causing your issue.
And indeed my findings do not suggest that this is the case.
As promised, I have reconstructed your situation in my network by disabling IPv6 support as well as stopping DHCPv6 and distribution of a ULA prefix.
I can confirm that this will prompt the behaviour you are seeing on your network.
As expected, Pi-hole won't be able to hand out a DHCPv6 address range in absence of any IPv6 prefix, resulting in the same log message you are seeing as well:
dnsmasq-dhcp[1749]: no address range available for DHCPv6 request via wlan0
I can also confirm that Pi-hole v4 and Beta 5.0 exhibit the same, identical behaviour in this regard, as demonstrated by the corresponding logs:
router provides no ULA prefix, IPv6 disabled
Pi-hole is prepared to advertise its features via eth0, but unaware of an IPv6 prefix and fails to construct a DHCPv6 address range, both for v4 and Beta 5.0. Note that Pi-hole also tries to mitigate this by actively probing for a router (RTR-SOLICIT), yet still receives no prefix.
Pi-hole v4
dnsmasq[27212]: started, version pi-hole-2.80 cachesize 10000
dnsmasq[27212]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
dnsmasq-dhcp[27212]: DHCP, IP range 192.168.0.201 -- 192.168.0.240, lease time 1d
dnsmasq-dhcp[27212]: DHCPv6, IP range ::100 -- ::1ff, lease time 1d, template for eth0
dnsmasq-dhcp[27212]: DHCPv4-derived IPv6 names on eth0
dnsmasq-dhcp[27212]: router advertisement on eth0
dnsmasq[27212]: using local addresses only for domain use-application-dns.net
dnsmasq-dhcp[27212]: no address range available for DHCPv6 request via eth0
dnsmasq-dhcp[27212]: RTR-SOLICIT(eth0) b8:27:ef:ba:de:da
dnsmasq-dhcp[27212]: no address range available for DHCPv6 request via eth0
Pi-hole Beta 5.0
dnsmasq[1749]: started, version pi-hole-2.81 cachesize 10000
dnsmasq[1749]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
dnsmasq-dhcp[1749]: DHCP, IP range 192.168.0.241 -- 192.168.0.251, lease time 1d
dnsmasq-dhcp[1749]: DHCPv6, IP range ::200 -- ::2ff, lease time 1d, template for wlan0
dnsmasq-dhcp[1749]: DHCPv4-derived IPv6 names on wlan0
dnsmasq-dhcp[1749]: router advertisement on wlan0
dnsmasq-dhcp[1749]: IPv6 router advertisement enabled
dnsmasq[1749]: using only locally-known addresses for domain use-application-dns.net
dnsmasq-dhcp[1749]: no address range available for DHCPv6 request via wlan0
dnsmasq-dhcp[1749]: RTR-SOLICIT(wlan0) b8:27:ef:ba:de:da
dnsmasq-dhcp[1749]: no address range available for DHCPv6 request via wlan0
router provides ULA prefix
Pi-hole is aware of fd00:: prefix and constructs its DHCPv6 range accordingly, both for v4 and Beta 5.0.
Pi-hole v4
dnsmasq[26288]: started, version pi-hole-2.80 cachesize 10000
dnsmasq[26288]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
dnsmasq-dhcp[26288]: DHCP, IP range 192.168.0.201 -- 192.168.0.240, lease time 1d
dnsmasq-dhcp[26288]: DHCPv6, IP range ::100 -- ::1ff, lease time 1d, template for eth0
dnsmasq-dhcp[26288]: DHCPv4-derived IPv6 names on eth0
dnsmasq-dhcp[26288]: router advertisement on eth0
dnsmasq-dhcp[26288]: DHCPv6, IP range fd00::100 -- fd00::1ff, lease time 1d, constructed for eth0
dnsmasq-dhcp[26288]: DHCPv4-derived IPv6 names on fd00::, constructed for eth0
dnsmasq-dhcp[26288]: router advertisement on fd00::, constructed for eth0
dnsmasq-dhcp[26288]: RTR-ADVERT(eth0) fd00::
dnsmasq[26288]: using local addresses only for domain use-application-dns.net
Pi-hole Beta 5.0
dnsmasq[1958]: started, version pi-hole-2.81 cachesize 10000
dnsmasq[1958]: compile time options: IPv6 GNU-getopt no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
dnsmasq-dhcp[1958]: DHCP, IP range 192.168.0.241 -- 192.168.0.251, lease time 1d
dnsmasq-dhcp[1958]: DHCPv6, IP range ::200 -- ::2ff, lease time 1d, template for wlan0
dnsmasq-dhcp[1958]: DHCPv4-derived IPv6 names on wlan0
dnsmasq-dhcp[1958]: router advertisement on wlan0
dnsmasq-dhcp[1958]: DHCPv6, IP range fd00::200 -- fd00::2ff, lease time 1d, constructed for wlan0
dnsmasq-dhcp[1958]: DHCPv4-derived IPv6 names on fd00::, constructed for wlan0
dnsmasq-dhcp[1958]: router advertisement on fd00::, constructed for wlan0
dnsmasq-dhcp[1958]: RTR-ADVERT(wlan0) fd00::
dnsmasq[1958]: using only locally-known addresses for domain use-application-dns.net
As stated before, let me also emphasize that this behaviour is to be expected:
So your observation indicates that your Pi-hole is unable to solicit an IPv6 prefix from your network.
That observation is fully supported by my test results, with consistent behaviour for Pi-hole v4 as well as Beta 5.0.
This leaves us with two potential root causes for your problem:
a) your router has stopped distributing an IPv6 prefix
b) something prevents Pi-hole from receiving an IPv6 prefix
As you have excluded your router's recent firmware update from being a cause, I would recommend to take a closer look at you router's IPv6 settings for addressing a).
As for b):
RAs are only visible to machines in the same network segment.
Did you perhaps recently change something in your network infrastructure, like introducing a new modem or an additional router, access point or switch? Or did you perhaps relocate your Pi-hole machine so it now uses a different connection than before?
1 Like
Thank you very much for your efforts. The only thing that changed in my network is the upgrade to PiHole Beta 5. I assume that my router MUST be providing IPv6 prefixes, as my IPv6 capable devices are all getting IPv6 addresses as usual. The only thing I note is that PiHole has a static IPv6 address, perhaps since the update, it has not queried the router for a prefix (no need?) and therefore has "forgotten" what the prefix is? Is that how it works? Can I force the PiHole to refresh its IPv6 address?
IPs are typically mapped in /etc/dhcpcd.conf
Let's check the configuration file jfb mentions:
For your Pi-hole machine, what's the output of:
grep -v '^[[:blank:]]*#\|^[[:blank:]]*$' /etc/dhcpcd.conf
hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option interface_mtu
require dhcp_server_identifier
slaac private
interface eth0
static routers=192.168.0.1
static domain_name_servers=127.0.0.1
inform 192.168.0.222/24
static ip6_address=2403:5800:7101:f00:xxxx:xxxx:xxxx:xxxx
Note that by defining a global IPv6 address for your Pi-hole, you potentially expose that address to be accessed from the Internet, unless your router blocks that. If you cannot set a ULA on your router, you should consider switching off IPv6.
With IPv6, router solicitations should be on by default, and as its common for an interface to carry multiple IPv6 addresses, just defining a static IPv6 should not stop your machine from soliciting a prefix, unless noipv6 or noipv6rs options are used as well.
You could still try to comment that out and see if that changes anything, or explicitly enable solicitation by supplying ipv6rs, see also man dhcpcd.conf.
Hi again. My router blocks internet access to my IPv6 devices so that is safe. It doesn't sound like there is any obvious solution to this, all we can say is that it used to work and now it doesn't. Cheers for all your help.
If this is the case, is there a reason to have IPv6 enabled on your network? Your network management is greatly simplified without IPv6.
I meant that my router blocks unwarranted requests like pings or direct access to my PiHole webserver over the internet (as it should). IPv6 otherwise works as it should.
As a side comment, I don't think we should talk people into disabling IPv6 when it's available, we should move forwards, not backwards and we need to eventually abandon IPv4.
Have you tried resolving the problem by moving DHCP back to your router?
Unfortunately when I do, all queries to PiHole appear to come from the router and I cannot see the individual clients.
IPv4 will never be abandoned, ever.
IPv6 is great when you know where, when and how to use to use it. Most people don't. When it's used incorrectly it's a security nightmare.
Best of luck solving the issue.
When you use Pi-Hole DHCP, this is the only client that doesn't get an IPV6 address? And it works properly in every respect without one?
No. When I use Pi-Hole DHCP all devices that are IPv6 compatible get IPv6 addresses, as they should (they self generate from a prefix the router provides). When Pi-Hole worked properly, it would also assign IPv6 address to some clients that requested them and also hand out its IPv6 address to ALL IPv6 clients for DNS (as well as its IPv4 address). Now my Pi-Hole doesn't seem to be able to hand out IPv6 addresses to clients that want them (not a huge issue as clients self generate them as I said) but most importantly (to me) it doesn't give out its IPv6 address for DNS (as per title of this post).
Perhaps not, but my service provider can no longer provide IPv4 addresses to new customers and they are getting very expensive to buy. CG-NAT sucks and I am sure my provider is not alone. IPv6 solves the issue nicely. I have had no problem setting up secure IPv6 on my network (just clicked the "Enable IPv6" box on the router) and it was working instantly. The average person shouldn't have to do anything, just set up the router that their service provider sends them. To be honest, the average person doesn't even know what IPv4 is, nor do they care, I predict it will be the same for IPv6. As a matter of fact, the biggest mobile network in Australia is completely IPv6. They switched a couple of years ago. Nobody noticed.
The problems we discuss here are much more of an esoteric nature, I would think. In any case, thank you for your help.
I get that, but given that DNS requests can be resolved by either IPV4 or IPV6, does this cause any problems in daily use?
Sometimes. The DNS fields auto populate with my router's IPv6 address and in turn, the router forwards those requests to the IPv6 addresses of my service provider (I can't change that). So sometimes the devices serve ads when they have bypassed the Pi-Hole via this route. The only solution has been to manually delete the router's IPv6 address from individual clients, which is tedious and I didn't have to do before.
Perhaps Pi-hole V4 is your best solution for now. It still has dnsmasq 2.80.
I thought about that as well. However, what I like on PiHole 5 is that it now actually reports client names in the dash for me, before all it did was report the IPv6 domain name assigned by my service provider (for IPv6 clients), so that's much better as I can now see what the clients are doing in a clearer way. I gained something but also lost something. Overall I feel PiHole 5 is better despite that one annoyance.
1 Like