DNS resolution on LLA address fails

Help
,
1

Good morning
the problem is similar to this question :

pihole-docker (latest version) is running under podman in network-mode "host". Binds are as follows:

udp   UNCONN 0      0                                    127.0.0.1:53        0.0.0.0:*    users:(("pihole-FTL",pid=7729,fd=6))
udp   UNCONN 0      0                                    10.0.0.24:53        0.0.0.0:*    users:(("pihole-FTL",pid=7729,fd=4))
udp   UNCONN 0      0                                        [::1]:53           [::]:*    users:(("pihole-FTL",pid=7729,fd=14))
udp   UNCONN 0      0            [fd28:reacted:be24:11ff:fef2:d4e]:53           [::]:*    users:(("pihole-FTL",pid=7729,fd=12))
udp   UNCONN 0      0           [2001:redacted:be24:11ff:fef2:d4e]:53           [::]:*    users:(("pihole-FTL",pid=7729,fd=10))
udp   UNCONN 0      0              [fe80::be24:11ff:fef2:d4e]%eth0:53           [::]:*    users:(("pihole-FTL",pid=7729,fd=8))
tcp   LISTEN 0      32                                   127.0.0.1:53        0.0.0.0:*    users:(("pihole-FTL",pid=7729,fd=7))
tcp   LISTEN 0      32                                   10.0.0.24:53        0.0.0.0:*    users:(("pihole-FTL",pid=7729,fd=5))
tcp   LISTEN 0      5                                    127.0.0.1:4711      0.0.0.0:*    users:(("pihole-FTL",pid=7729,fd=18))
tcp   LISTEN 0      32          [2001:redacted:be24:11ff:fef2:d4e]:53           [::]:*    users:(("pihole-FTL",pid=7729,fd=11))
tcp   LISTEN 0      32          [fd28:redacted:be24:11ff:fef2:d4e]:53           [::]:*    users:(("pihole-FTL",pid=7729,fd=13))
tcp   LISTEN 0      32             [fe80::be24:11ff:fef2:d4e]%eth0:53           [::]:*    users:(("pihole-FTL",pid=7729,fd=9))
tcp   LISTEN 0      32                                       [::1]:53           [::]:*    users:(("pihole-FTL",pid=7729,fd=15))
tcp   LISTEN 0      5                                        [::1]:4711         [::]:*    users:(("pihole-FTL",pid=7729,fd=20))

Name resolution on the same server works for the ULA, but. not for LLA:

root@abackport ~/podman/pihole $  dig aaaa @10.0.0.24 heise.de

; <<>> DiG 9.18.33 <<>> aaaa @10.0.0.24 heise.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15532
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;heise.de.			IN	AAAA

;; ANSWER SECTION:
heise.de.		42570	IN	AAAA	2a02:2e0:3fe:1001:302::

;; Query time: 3 msec
;; SERVER: 10.0.0.24#53(10.0.0.24) (UDP)
;; WHEN: Sat Feb 01 18:47:06 CET 2025
;; MSG SIZE  rcvd: 65


root@abackport ~/podman/pihole $  dig -6 aaaa @fd28:redacted:be24:11ff:fef2:d4e heise.de

; <<>> DiG 9.18.33 <<>> -6 aaaa @fd28:redacted:be24:11ff:fef2:d4e heise.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18000
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;heise.de.			IN	AAAA

;; ANSWER SECTION:
heise.de.		42585	IN	AAAA	2a02:2e0:3fe:1001:302::

;; Query time: 0 msec
;; SERVER: fd28:redacted:be24:11ff:fef2:d4e#53(fd28:redacted:be24:11ff:fef2:d4e) (UDP)
;; WHEN: Sat Feb 01 18:46:51 CET 2025
;; MSG SIZE  rcvd: 65


root@abackport ~/podman/pihole $  dig -6 @fe80::be24:11ff:fef2:d4e heise.de
;; UDP setup with fe80::be24:11ff:fef2:d4e#53(fe80::be24:11ff:fef2:d4e) for heise.de failed: invalid file.
;; no servers could be reached
;; UDP setup with fe80::be24:11ff:fef2:d4e#53(fe80::be24:11ff:fef2:d4e) for heise.de failed: invalid file.
;; no servers could be reached
;; UDP setup with fe80::be24:11ff:fef2:d4e#53(fe80::be24:11ff:fef2:d4e) for heise.de failed: invalid file.

Debug Token is https://tricorder.pi-hole.net/rm8iBLe5/

Regards,
Patrick

2

Quite likely, that isn't an error.

You are running that dig from the machine hosting your Pi-hole with an unscoped LLA, where some OS varieties would require a scope id.

Your lookup 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:

dig @fe80::be24:11ff:fef2:d4e%eth0 heise.de
3

Hi,

thank you for your feedback.

You are indeed right, it does work when appending the interface name, both from the server itself as well as from a different Linux machine.

EDIT It does look like I need to look up the concept of "zone index" for non-global IPv6 addresses. Thanks so much for your help.

4

Pi-hole isn't involved here: It is the respective OS's IPv6 addressing that would or would not require a scope id, despite expectations of working without one.
You should also note that the scope id is specific to the client, so on your MacOS machine, you'd have to use that machine's interface that handles communication to your Pi-hole machine, which may well have a name different of eth0.

But as you mention you'd want to use this in a Fritzbox router:

Your FB does not have to advertise any IPv6 address as DNS server.
It already distributes an IPv4 address via DHCP, so your IPv4 only as well as your dual stack clients will already know a DNS server - and one DNS server is fully sufficient.

Just configure your Fritzbox to not distribute an IPv6 address as DNS server at all, see e.g. Unresolved ipv6 adress in my top list - #4 by Bucking_Horn.

That configuration not only avoids using an LLA altogether, it also makes Pi-hole's Query Log less cluttered and easier to read.

5

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