No DNS resolving with use of de IPv6 LLA of the server

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)

Debug Token:
https://tricorder.pi-hole.net/0uqVwBXh/

Not related to the issue but above IP is not a ULA but an LLA with that fe80 prefix:

ULA's have a fc00::/7 prefix (from above diagram).
See also below:

Thank you, I have corrected the text to avoid misunderstandings.

1 Like

Missed the title :wink:

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.

1 Like

Please share the output of

nslookup pi.hole fe80::<redacted>02
nslookup discourse.pi-hole.net fe80::<redacted>02

where you substitute fe80::<redacted>02 with your current LLA.

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

From a Windows PC on the local network:

nslookup fe80::<redacted>02
Server:  pi.hole
Address:  192.168.178.2

Name:    pi.hole
Address:  fe80::<redacted>02
nslookup discourse.pi-hole.net fe80::<redacted>02
Server:  pi.hole
Address:  fe80::<redacted>02

Non-authoritative answer:
Name:    discourse.pi-hole.net
Address:  52.14.183.198

The used LLA is the LLA of the server running pi.hole.

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

nslookup discourse.pi-hole.net fe80::<redacted>02%eth0

If that succeeds, then there's nothing to worry about.

Just curious: What's the OS and release of your machine hosting Pi-hole?

The server with pi-hole runs on: Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-51-generic x86_64)

The results of testing with ssh-connection on the pi-hole server:

nslookup pi.hole fe80::<redacted>02%enp3s0
Server:         fe80::<redacted>02%enp3s0
Address:        fe80::<redacted>02%2#53

Name:   pi.hole
Address: 192.168.178.2
Name:   pi.hole
Address: 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:e02
nslookup discourse.pi-hole.net fe80::<redacted>02%enp3s0
Server:         fe80::<redacted>02%enp3s0
Address:        fe80::<redacted>02%2#53

Non-authoritative answer:
Name:   discourse.pi-hole.net
Address: 52.14.183.198

Testing from the Windows 11 PC on the local network:

nslookup pi.hole fe80::<redacted>02%enp3s0
*** Can't find server address for 'fe80::<redacted>02%enp3s0':
Server:  pi.hole
Address:  192.168.178.2

Name:    pi.hole
Addresses:  2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:e02
          192.168.178.2
nslookup discourse.pi-hole.net fe80::<redacted>02%enp3s0
*** Can't find server address for 'fe80::<redacted>02%enp3s0':
Server:  pi.hole
Address:  192.168.178.2

Non-authoritative answer:
Name:    discourse.pi-hole.net
Address:  52.14.183.198

All good.

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.

Thank you very much for your help

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.