Expected Behaviour:
I'm using version 5.21 on a server running Ubuntu. I am very happy with Pihole, but sometimes the DNS of domains is resolved slowly or not at all.
When running a debug test, I keep getting the message below that resolving via the server's LLA is not working.
Actual Behaviour:
Resolving a domain name via the LLA (fe80::<redacted>02) fails every time the test with the debug test. See the part of the debug.log below:
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] ananyaresort.com is :: on lo (::1)
[✓] ananyaresort.com is :: on enp3s0 (2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxxx:xxx)
[✗] Failed to resolve ananyaresort.com on enp3s0 (fe80::<redacted>02)
[✓] doubleclick.com is 2a00:1450:400e:805::200e via a remote, public DNS server (2001:4860:4860::8888)
I read the texts but that did not solve the problem.
When I view my network settings, my server has a: fixed IPv4 address, a fixed LLA IPv6 address and also a fixed global IPv6 address. I cannot find a ULA on any of the devices on my network.
What could be the cause that the pi-hole on the server cannot resolve DNS via the LLA address?
While technically not wrong, only fd00::/8 (with the L bit set) is in use for generating ULAs, while fc00::/8 (with the L bit unset) is reserved for future use, see RFC4193.
On the server running pi.hole with use of ssh-connection from a windows PC in the local network:
nslookup fe80::<redacted>02
2.0.e.0.5.8.e.f.f.f.4.f.f.5.e.b.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa name = pi.hole.
nslookup discourse.pi-hole.net fe80::<redacted>02
;; UDP setup with fe80::<redacted>02#53(fe80::<redacted>02) for discourse.pi-hole.net failed: invalid file.
;; no servers could be reached
;; UDP setup with fe80::<redacted>02#53(fe80::<redacted>02) for discourse.pi-hole.net failed: invalid file.
;; no servers could be reached
;; UDP setup with fe80::<redacted>02#53(fe80::<redacted>02) for discourse.pi-hole.net failed: invalid file.
;; no servers could be reached
You haven't run the first command as requested (missing out pi.hole), but never mind - the results are sufficient as they are.
Your successful nslookup from a Windows client already demonstrates that your Pi-hole is receiving DNS requests via its host's LLA, so everything works as it should.
Some OS varieties seem to have difficulties resolving DNS via an unscoped LLA, which is what the debug script uses for its test.
Your nslookup will likely succeed if you extend your statements by %interfacename of the network interface of the client that runs the lookup, e.g. if that client is using eth0
As already demonstrated by your first set of nslookups, clients have no difficulties talking to your Pi-hole via its host machine's LLA. It's just the debug log that uses an LLA without an explicit scope, and that fails on some OS varieties.