Failed to resolve via Local Link Unicast Adress

bigtreiber · January 1, 2024, 5:35pm

Hello,

I just did a fresh install for Pi-Hole on a Raspberry Pi 4 and ran a debug-log to see if there are any issues. And yes, there is an issue with name resolution. That doesn't seem to work for the LLUA Adress

Expected Behaviour:

No problem with name resolution (IPv6)

Actual Behaviour:

Error Message in Debug log
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] www.copoqyoxyi.live is :: on lo (::1)
[✓] www.copoqyoxyi.live is :: on eth0 (2003:<redacted>e5)
[✓] www.copoqyoxyi.live is :: on eth0 (fd00:cece:1eff:1ccc:d7d6:3b45:47b1:dbaf)
[✓] www.copoqyoxyi.live is :: on eth0 (fd32:b402:707f:fa49:451c:e18d:641b:a726)
[✗] Failed to resolve www.copoqyoxyi.live on eth0 (fe80::3c92:fd5c:ccf3:1bf3)
[✓] doubleclick.com is 2a00:1450:4016:809::200e via a remote, public DNS server (2001:4860:4860::8888)

Debug Token:

https://tricorder.pi-hole.net/Oy4w2gsu/

Bucking_Horn · January 2, 2024, 10:41am

What's the output of the following command:

dig pi.hole @fe80::3c92:fd5c:ccf3:1bf3

bigtreiber · January 2, 2024, 11:14am

The output is:

pi@faramir:~ $ dig pi.hole @fe80::3c92:fd5c:ccf3:1bf3
;; UDP setup with fe80::3c92:fd5c:ccf3:1bf3#53(fe80::3c92:fd5c:ccf3:1bf3) for pi.hole failed: invalid file.
;; UDP setup with fe80::3c92:fd5c:ccf3:1bf3#53(fe80::3c92:fd5c:ccf3:1bf3) for pi.hole failed: invalid file.
;; UDP setup with fe80::3c92:fd5c:ccf3:1bf3#53(fe80::3c92:fd5c:ccf3:1bf3) for pi.hole failed: invalid file.

Bucking_Horn · January 2, 2024, 11:41am

What machine did you run that command from?

Also, please run the following command from a client in your network (i.e. not from the machine hosting your Pi-hole):

nslookup google.com fe80::3c92:fd5c:ccf3:1bf3

bigtreiber · January 2, 2024, 11:47am

The dig-command was run from the pi-hole itself.

The output from nslookup google.com fe80::3c92:fd5c:ccf3:1bf3 from a client is:

;; connection timed out; no servers could be reached

When running dig pi.hole @fe80::3c92:fd5c:ccf3:1bf3 from another machine the output is

; <<>> DiG 9.10.6 <<>> pi.hole @fe80::3c92:fd5c:ccf3:1bf3
;; global options: +cmd
;; connection timed out; no servers could be reached

The output of ip address | grep "inet6" on the pi-hole is

    inet6 ::1/128 scope host noprefixroute
    inet6 2003:c1:1723:f500:4af8:a8f7:132c:ba5c/64 scope global dynamic noprefixroute
    inet6 fd00:cece:1eff:1ccc:d7d6:3b45:47b1:dbaf/64 scope global dynamic noprefixroute
    inet6 fd32:b402:707f:fa49:451c:e18d:641b:a726/64 scope global dynamic noprefixroute
    inet6 fe80::3c92:fd5c:ccf3:1bf3/64 scope link noprefixroute

IPv6 DNS Setting in my fritz.box is

Anything else I can check?

Bucking_Horn · January 2, 2024, 12:05pm

To keep things focused, please just share information as requested - there is a wealth of it in your debug log, no need to duplicate that.

Your debug log suggests that your RPi4 either runs Debian 12 or the 64bit RaspberryPi OS 12.

What OS is the client running that issued the lookups?

And could you please 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 google.com fe80::3c92:fd5c:ccf3:1bf3%eth0

bigtreiber · January 2, 2024, 1:09pm

Sorry for the information overload.
The Pi is running RaspberryPi OS (lite) 12 und the client is running macOS14.

The result of nslookup google.com fe80::3c92:fd5c:ccf3:1bf3%en0 is

Server:		fe80::3c92:fd5c:ccf3:1bf3%en0
Address:	fe80::3c92:fd5c:ccf3:1bf3%20#53

Non-authoritative answer:
Name:	GOOGLE.COM
Address: 172.217.19.78

Bucking_Horn · January 2, 2024, 11:53pm

Hmm, that may suggest that something is amiss with your client's OS networking stack, or its DNS lookup utilities. I'd expect them to attach the interface to DNS requests as applicable.

We've received a similar observation from another user not so long ago, see Trouble sending queries to link-local (IPv6) - #7 by Maarten.

bigtreiber · January 3, 2024, 7:31am

Thanks for you analyst. Then I assume there is nothing I can do?
What I don't understand: The "original error" (failed to resolve ... LLUA) can be seen on the debug log of the Pi itself. How is this affected by the "nslookup" on the macOS Client?

Bucking_Horn · January 3, 2024, 8:28am

The debug script runs the lookups for the test just as a client like your MacOS would, by running a dig against the address as reported (so dig is the client here).

Pi-hole's DNS server part would become involved if that request would make it to Pi-hole, which it doesn't in this case. You'll note that the respective requests never register in Pi-hole's Query Log.

I am able to reproduce your observation from a client running a Debian 12 variety (LMDE), but not from a Debian 10 (Armbian), so this seems to be tied to the OS release somehow.
As both dig and nslookup are failing with the same "UDP setup with <LLA> for <domain> failed: invalid file message, that may suggest a common cause, perhaps with some glibc functions - in any case, something outside of Pi-hole.

I am unsure whether this is a glitch in the client, or whether we may have to consider adopting our debug test for recent OS versions.
I'm currently more leaning to the former, as I'd expect nslookup and dig to be able to handle a plain LLA without a scope id.

There is nothing you have to do.

In your case, your router is distributing your Pi-hole host machine's ULA address as local DNS resolver, and obviously, ULA addresses do not trigger that behaviour.

bigtreiber · January 3, 2024, 4:24pm

Well, then thanks a lot for the explanation

system · January 24, 2024, 4:24pm

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