The router has the pi-hole IPv4 and IPv6 addresses listed as DNA servers. I'm just using the primary DNS server address and the secondary is blank for both v4 and v6.
Did you change it just now or was it like that already? In case it does not seem to work for IPv6 for some reason. Can you remove the primary address for IPv6 as well, and see whether this removes the router's IPv6 from sudo resolvectl status
(might take up to 30 minutes until a new RA is sent out, to have the output updated)? For resolving hosts to IPv6 addresses, the DNS server does not need to be accessed via IP6, so it is generally not needed.
Also, are these the router's DHCP settings, or is it the upstream DNS servers use by the router itself? Theoretically this can be two different settings, and possibly the router enforces itself as DNS resolver in addition to what has been configured for DHCP, and uses a different upstream DNS.
I removed the IPv6 DNS entry on the router, and set it to auto and pi.hole/admin now works! Thank you
udo resolvectl status
[sudo] password for rob:
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (enp3s0f2)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 3 (wlp2s0)
Current Scopes: DNS
Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.20
DNS Servers: 192.168.1.20 fe80::<redacted>d6 fe80::<redacted>ed
DNS Domain: home
Link 4 (docker0)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 5 (br-d843fb2138b9)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 6 (veth58b078b)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
My router's IPv6 address is still listed there above as a DNS server, but I'm hoping that it is still sending traffic to my pi-hole rather than to it's built-in upstream DNS servers, which are still shown in the router config, but hopefully are fully bypassed by the custom DNS server entry that points to my pi-hole.
I'm not sure I fully understand your question/point about DHCP.
Your machine is still aware of two IPv6 link-local addresses DNS servers, it's just not using them at the moment.
fe80::d6 is your router, fe80::ed is a Raspberry Pi, likely the one that is running Pi-hole.
Did you try adding your RPis link-local in all of your router's IPv6 DNS slots?
Adding the RPis IPv6 into both primary and secondary slots also still works. It makes me wonder if I should add in the IPv4 into the secondary v4 DNS slot for completeness.
no change from the client machine:
sudo resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (enp3s0f2)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 3 (wlp2s0)
Current Scopes: DNS
Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.20
DNS Servers: 192.168.1.20 fe80::7297:41ff:fe43:63d6 fe80::ba27:ebff:febc:9ced
DNS Domain: home
Link 4 (docker0)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 5 (br-d843fb2138b9)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 6 (veth5032d1a)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
The router's IPv6 address is still there. Should be currently random whether Pi-hole or the router is used as DNS, and can change with any router advertisement and hence resolved update.
You do change this currently in the DHCP or LAN settings or the router, right?
No, that didn't work.
If it would, your router's link-local should have vanished from resolvectl status
output.
Could you share a screenshot of your router's configuration screen for those IPv6 addresses?
I meant that pi.hole/admin still resolves.
Screenshots of IPv4 and IPv6 router config pages attached.
I think so yes. My router is still the DHCP server
Please run
sudo pihole-FTL dhcp-discover | pihole tricorder
and share the token.
Hmm, I was hoping to see your router's RAs, but RAs are only solicited with v6, so your results suggest they were produced by a v5 pihole-FTL binary?
What's the output of
pihole -v
dig version.ftl chaos txt
root@DietPi:~# pihole -v
Pi-hole version is v5.18.4 (Latest: v6.0.4)
web version is v5.21 (Latest: v6.0.1)
FTL version is v5.25.2 (Latest: v6.0.3)
root@DietPi:~# dig version.ftl chaos txt
; <<>> DiG 9.18.33-1~deb12u2-Raspbian <<>> version.ftl chaos txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29169
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;version.ftl. CH TXTtype or paste code here
;; Query time: 30 msec
;; SERVER: 192.168.1.254#53(192.168.1.254) (UDP)
;; WHEN: Sat Mar 01 13:38:13 GMT 2025
;; MSG SIZE rcvd: 40
192.168.1.254 is my router...
Seems you are still running Pi-hole v5.
Is that by intention?
At the moment, yes. I will upgrade, but it seemed worth just letting the dust settle a bit before jumping in. I wasn't sure it would run well on a RPi2b, so I needed to be sure it would (and wait for the dietpi upgrade which has now come). I also wanted to get the pi.hole URL working first (hence this thread).
Is the upgrade path 100% reliable now, or is a clean install preferred?
If you are on DietPi v9.10 or lower, best is to upgrade Pi-hole first, DietPi afterwards. The update will do some further cleanup of DietPi-specific stuff that is obsolete with Pi-hole v6, and offers to uninstall webserver and PHP, unless something else is installed which requires it.
If you are on DietPi v9.11 already, you can re-apply the update, after Pi-hole was updated:
dietpi-update -1
We are thinking of a dedicated script, check and notification to offer said cleanup steps, but for now re-applying the DietPi update works well, as it was a release which almost only added proper Pi-hole v6 support to dietpi-software
.
100% guarantee does not exist, but I am not away of any general left issues, and if anything goes wrong, we are here to help .
That all worked fine, thanks a million! DietPi is great
I updated to v6 and this is the resolvectl status on my problem client:
sudo resolvectl status
[sudo] password for rob:
Sorry, try again.
[sudo] password for rob:
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (enp3s0f2)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 3 (wlp2s0)
Current Scopes: DNS
Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fe80::7297:41ff:fe43:63d6
DNS Servers: 192.168.1.20 fe80::7297:41ff:fe43:63d6 fe80::ba27:ebff:febc:9ced
DNS Domain: home
Link 4 (br-d843fb2138b9)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 5 (docker0)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 6 (vethc9aa558)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
tricorder token result:
sudo pihole-FTL dhcp-discover | pihole tricorder
/usr/local/bin/pihole: line 34: /etc/pihole/versions: Permission denied
Upload successful, your token is: https://tricorder.pi-hole.net/Usnr2Bbf/
As far as RAs are concerned, that looks better:
* Received 104 bytes from fe80::<redacted>d6 @ eth0
Hop limit: 64
Stateful address conf.: No
Stateful other conf.: Yes
Router preference: Medium
Router lifetime: 180 s
- Prefix: 2a<redacted>::/64
Valid lifetime: 300 sec
Preferred lifetime: 120 sec
On-link: Yes
Autonomous address conf.: Yes
Recursive DNS server 1/2: fe80::<redacted>ed
Recursive DNS server 2/2: fe80::<redacted>ed
DNS server lifetime:60 sec
MTU: 1492 bytes (valid)
Your v6 pihole -FTL
did solicit above router advertisement (RA) from your router, and it correctly shows your Pi-hole's LLA ending in ed
in both slots.
But your client is a still aware of your router's LLA, ending in d6
:
This could be a leftover from a previous RA.
Please monitor if that would vanish within the next 5 minutes (the longest lifetime from the RA, at 300 seconds).
Still there after an hour.