Pi-hole answers 'pi.hole' AAAA query with global IPv6 address, link-local address expected though

Help
1

Expected Behaviour:

nslookup pi.hole

Server: pi.hole
Address: fe80::w:x:y:z

Name: pi.hole
Addresses: fe80:: w:x:y:z
192.168.0.2

Actual Behaviour:

nslookup pi.hole

Server: pi.hole
Address: fe80::w:x:y:z

Name: pi.hole
Addresses: r:s:t:u:w:x:y:z
192.168.0.2

Problem

This prohibits to access the Pi-hole web-interface from a local browser (with IPv6 support) in the same subnet by typing 'pi.hole/admin' as address/

2

Regardless of LLA, ULA or GUA: Using any of your Pi-hole host's IPv6 addresses would work, provided that Pi-hole is able to receive DNS requests via that address.

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

3
  1. It's not logical to reply with a global address since it is a local service.

Moreover pihole-FTL (dnsmasq) replies with link-local address of all other hosts in the same subnet.
So it seems not only unlogical to me but also inconsistent.

Is there a specific reason that pihole-FTL makes an exception for address resolution of 'pi.hole' ?

So it's not a bug just a minor annoyance.

  1. DietPi install adds:
$HTTP["url"] =~ "^(/html)?/admin/" {
        $HTTP["remoteip"] !~ "^(1(27|92\.168|0|72\.(1[6-9]|2[0-9]|3[0-1]))\.|::1|fe[89ab].:|f[cd]..:)" {
                url.access-deny = ("")
        }

to the the lighttppd script which seems logical but blocks remote IP addresses.

That's why I cannot access the webadmin dashboard using 'pi.hole/' address in my browser.

So not a real problem but I think it is still worth mentioning.
That's all.

Not to forget: thanks for the great product that Pi-hole is! It makes browsing the web a lot more comfortable.

4

I cannot know (for lack of a debug log), but chances are your Pi-hole would source local names from your router, i.e. it would be your router providing the answer.

Resolution of pi.hole is indeed special, as Pi-hole makes an effort to answer with the correct IP address depending on the network interface that the request has arrived on.
This is especially useful in situations where Pi-hole is hosted in an environment with several NICs, or several attached IPs per NIC.

I think that for AAAA requests for pi.hole, it may be sensible to have Pi-hole provide all IPv6s for a NIC, so a client may pick one to its liking.

While that's not the case at the moment, Pi-hole allows to configure the IPv6 used for the AAAA reply.

You may mitigate your issue by setting a fixed LOCAL_IPV6 in pihole-FTL.conf.

1 Like
5

Thanks, will try that.

It is both, router and pi-hole indeed.

On the router, I have included 'host-record=pi.hole,192.168.168.192,fe80::-:----:----:9c07' in the router's dnsmasq conf, but that works only on the router itself. Other hosts still get the global address.

Had included 'host-record=pi.hole,192.168.168.192,fe80::-:----:----:9c07' in Pi-holes 'dnsmasq' conf, but that does not help.

But adding LOCAL_IPV6 in pihole-FTL.conf really did the trick ! Thanks.

6

One of the limitations with IPv6: Filtering by remote address ranges does not work, unless LLAs are used (which is not always possible across routers/switches) or ULAs enabled (which is not always wanted and usually not the default). With IPv6 enabled, every device gets a GUA, which is a global range address, and in this case used for LAN accesses as well.

Good that there is a way to enforce a static local IPv6 address in router and Pi-hole DNS to fix it. Best is of course to just not forward port 80/443, in which case the public IP range blocking is not required (resp. only a secondary access barrier).

7

Thanks, Micha,

It becomes a little bit more clear to me. Learning and understanding IPv6 is a steep curve to take.
But it is your addition to the script:

$HTTP["url"] =~ "^(/html)?/admin/" {
        $HTTP["remoteip"] !~ "^(1(27|92\.168|0|72\.(1[6-9]|2[0-9]|3[0-1]))\.|::1|fe[89ab].:|f[cd]..:)" {
                url.access-deny = ("")
        }

that prohibits webadmin access when 'pi.hole' is resolved to a ipv6 address!

Thanks gain, this may be closed from my part.

8

Yes, you are asked during the installation whether you want to install this public access block or not, and it tells you the IP ranges which are blocked as well. But probably we should add some more info about the consequence in case of IPv6 usage in LAN without ULAs explicitly.

Btw, just in case you do not remember. The prompt also gave the commands to toggle the block. If you want to remove it:

lighty-disable-mod dietpi-pihole-block_public_admin
9

Yes, that's definitely an option. Thanks.

10

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