[IPv6, FTL, DNS] 'dig -6' not working with Pi-hole/FTL

Help
1

General Info

  1. Pi-hole OS: Raspbian v5.15.84-v8
  2. Hardware: Raspberry Pi 3
  3. Pi-hole version is v5.15.1 (Latest: v5.15.1)
  4. AdminLTE version is v5.18.2 (Latest: v5.18.2)
  5. FTL version is v5.20.1 (Latest: v5.20.1)
  6. fddd::12 is the IPv6 of the Pi-hole which is running FTL
  7. fddd::1 is the IPv6 of another server which is running dnsmasq

Expected Behaviour:

Running dig -6 @fddd:12 google.com aaaa should return an IPv6 answer section, like for example:

; <<>> DiG 9.16.33 <<>> -6 @fddd::12 google.com aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10677
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
google.com.             258     IN      AAAA    2607:f8b0:4009:81b::200e

;; Query time: 30 msec
;; SERVER: fddd::12#53(fddd::12)
;; WHEN: Mon Jan 23 08:23:45 EST 2023
;; MSG SIZE  rcvd: 67

Actual Behaviour:

Running dig -6 @fddd:12 google.com aaaa returns a "no servers reached error":

user@Host ~ % dig -6 @fddd::12 google.com aaaa

; <<>> DiG 9.16.33 <<>> -6 @fddd::12 google.com aaaa
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Additional Info:

I know that I can reach the pi-hole because I can ping it and ssh info it using IPv6:

Ping Test

user@Host ~ % ping -6 fddd::12 -c 2
PING fddd::12(fddd::12) 56 data bytes
64 bytes from fddd::12: icmp_seq=1 ttl=64 time=26.9 ms
64 bytes from fddd::12: icmp_seq=2 ttl=64 time=28.8 ms

--- fddd::12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 26.906/27.868/28.830/0.962 ms

SSH Test:

user@Host ~ % ssh user@fddd::12    
Linux raspberrypi 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Jan 23 13:34:13 2023 from 192.168.3.11

Wi-Fi is currently blocked by rfkill.
Use raspi-config to set the country before use.

user@raspberrypi:~ $

I also know that I can succesfully query another dns server using only IPv6:

Alternate Server Test:

user@Host ~ % dig -6 @fddd::1 google.com aaaa 

; <<>> DiG 9.16.33 <<>> -6 @fddd::1 google.com aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30005
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.                    IN      AAAA

;; ANSWER SECTION:
google.com.             132     IN      AAAA    2607:f8b0:4009:814::200e

;; Query time: 40 msec
;; SERVER: fddd::1#53(fddd::1)
;; WHEN: Mon Jan 23 08:40:51 EST 2023
;; MSG SIZE  rcvd: 67

I can also see that running dig locally on the Pi-hole gives results:

Local Test

user@raspberrypi:~ $ dig -6 @::1 google.com aaaa

; <<>> DiG 9.16.33-Debian <<>> -6 @::1 google.com aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55471
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.                    IN      AAAA

;; ANSWER SECTION:
google.com.             300     IN      AAAA    2607:f8b0:4009:81a::200e

;; Query time: 43 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Jan 23 13:50:59 GMT 2023
;; MSG SIZE  rcvd: 67

I can see that FTL is listening on port 53 for all foreign addresses and all local addresses:

Netstat Result

user@raspberrypi:~ $ sudo netstat -tulpn | grep :53
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      686/pihole-FTL      
tcp6       0      0 :::53                   :::*                    LISTEN      686/pihole-FTL      
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           380/avahi-daemon: r 
udp        0      0 0.0.0.0:53              0.0.0.0:*                           686/pihole-FTL      
udp6       0      0 :::5353                 :::*                                380/avahi-daemon: r 
udp6       0      0 :::53                   :::*                                686/pihole-FTL

I'm sure that it isn't a firewall issue for two reasons:

  1. I've set both devices into the same firewall zone and allowed unconditional forwardings between all devices in that same zone
  2. I can nmap to see that the port is open:

Nmap Test

user@Host ~ % nmap -6 -p 53 fddd::12
Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-23 08:59 EST
Nmap scan report for pi.hole (fddd::12)
Host is up (0.0072s latency).

PORT   STATE SERVICE
53/tcp open  domain

Nmap done: 1 IP address (1 host up) scanned in 6.57 seconds

Debug Token:

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

Request

Can anyone help me with figuring out what is going wrong? This is a vanilla Pi-hole install and I've tested everything I could think of, as shown by the tests given above. I'm hoping it's just a config setting that I'm over looking or am unaware of.

2

I am unable to recreate your issue on my Pi-hole machines.

Your above result would imply that the request never reached your Pi-hole.
Commonly, that would suggest networking or firewall issues.

We can rule out networking issues, since your shared ping and ssh test results would suggest that you can reach fddd::12, at least from your test machine.
EDIT: I may perhaps have been a little too hasty here.
Your debug log shows this interesting message:

*** [ DIAGNOSING ]: Pi-hole diagnosis messages

(...) ignoring query from non-local network fddd::fdc (logged only once)

It also shows that your IPv6 address wasn't auto-created, as can be told by the /128 prefix:

*** [ DIAGNOSING ]: Networking

[✓] IPv6 address(es) bound to the eth0 interface:
    fddd::12/128

How did your Pi-hole host machine get that IPv6 address?

I'm not quite sure about your firewall yet.
The port may be open, but your firewall may still reroute packets someplace where Pi-hole is not receiving them.

If Pi-hole is receiving, then the following statement

nmap -6 -sV -p 53 fddd::12

should return something similar to:

PORT   STATE SERVICE VERSION
53/tcp open  domain  dnsmasq pi-hole-v2.88
3

The Pi-hole got the fddd::12 ip from a DHCPv6 server that has disabled SLAAC for the network. fddd:: is a stateful ULA address space. I'm not near those computers for the moment, but that does make me think I should try the global ipv6 address for the pi-hole. Maybe the issue is that Pi-hole/FTL doesn't like ULA addresses by default? I'll also try the command you suggested once I return to those devices.

4

In contrast to IPv4's DHCP, DHCPv6 servers do not provide a gateway (nor any other routing information). That is the reason why DHCPv6-issued IPv6 addresses do carry a /128 range (i.e. they are not part of any subnet).

IPv6 clients learn routes from corresponding RAs.
Thus, your router has to advertise a route for your fddd:: prefix.

Disabling SLAAC very probably has stopped RAs from that machine.
If that machine was also your primary source for IPv6 prefixes, then your network would now be missing the corresponding routing information.

When you're back, you may verify your current status.
Run from your Pi-hole host machine, what's the output of:

 ip -6 route | grep -E 'fddd|default'
5

So I ran the commands as you asked and here are their outputs:

IP Route

user@raspberrypi:~ $ ip -6 route | grep -E 'fddd|default'
fddd::/64 dev eth0 proto ra metric 202 mtu 1500 pref medium
default via fe80::blah dev eth0 proto ra metric 202 mtu 1500 pref medium

Nmap Test 2

user@Host ~ % nmap -6 -sV -p 53 fddd::12
Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-23 16:13 EST
Nmap scan report for pi.hole (fddd::12)
Host is up (0.035s latency).

PORT   STATE SERVICE    VERSION
53/tcp open  tcpwrapped

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.89 seconds

I also ran nmap on IPv4 just to make sure it agreed with your post:

Nmap IPv4 Test

user@Host ~ % nmap -4 -sV -p 53 192.168.3.12
Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-23 16:14 EST
Nmap scan report for pi.hole (192.168.3.12)
Host is up (0.028s latency).

PORT   STATE SERVICE VERSION
53/tcp open  domain  dnsmasq pi-hole-v2.88

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.80 seconds

I thought that having the line fddd::/64 dev eth0 proto ra metric 202 mtu 1500 pref medium meant that Pi-hole knew how to route back to a source on fddd::/64, so a source of fddd::abab/128 would be fine. Are you saying that the /64 on the route means Pi-hole can't route using a /128 address?

6

No.
The /128 is normal for IP addresses acquired via DHCPv6.
The catch is that DHCPv6 servers do not provide routing information, so your client has to learn about a gateway by some other means.

The Pi-hole diagnosis message from your debug log suggests that fddd::fdc is not considered local, so it may not have been aware of fddd as a local prefix.
If your router wouldn't advertise an fddd: prefix route, then your network wouldn't have been aware of a corresponding route.

But according to your ip route output, your Pi-hole host machine has that and a default route as well.

That would hint at a firewall service, though TCP wrappers actually predate packet filters like firewalls.
But it may also mean that nmap is misinterpreting the result, if Pi-hole would be receiving nmaps port scan and ignoring it.

Try changing Pi-hole's Interface Settings to Permit all origins via Settings | DNS and rerun the nmap command.

If it still shows tcpwrapped instead of dnsmasq pi-hole-v2.88, then that would suggest a firewall issue.

7

Okay, I thought that's what you meant, but I over thought it. Good to have that confirmed.

I did this and nmap and dig work now!

Nmap Test 3

user@Host ~ % nmap -6 -sV -p 53 fddd::12
Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-23 17:23 EST
Nmap scan report for pi.hole (fddd::12)
Host is up (0.026s latency).

PORT   STATE SERVICE VERSION
53/tcp open  domain  dnsmasq pi-hole-v2.88

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.26 seconds

Dig -6 Test

user@Host ~ % dig -6 @fddd::12 google.com aaaa

; <<>> DiG 9.16.33 <<>> -6 @fddd::12 google.com aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51226
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.                    IN      AAAA

;; ANSWER SECTION:
google.com.             300     IN      AAAA    2607:f8b0:4009:809::200e

;; Query time: 50 msec
;; SERVER: fddd::12#53(fddd::12)
;; WHEN: Mon Jan 23 17:23:36 EST 2023
;; MSG SIZE  rcvd: 67

So, here's a question. How do I get pi-hole to consider the fddd::/64 space to be local? (Especially since the fd00::/8 space is suppose to be Local)

8

Don't let yourself get confused by mixing different terminology. :wink:
Yes, the ULA address range for locally assignable global ids is meant for private local (as opposed to public Internet) usage, but the specific prefixes on a link are local to a specific machine.

Pi-hole takes that information from its host's network interfaces.
In your case, that is:

   2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
       inet 192.168.3.12/24 brd 192.168.3.255 scope global dynamic noprefixroute eth0
          valid_lft 40120sec preferred_lft 34720sec
       inet6 fddd::12/128 scope global dynamic noprefixroute 
          valid_lft 40117sec preferred_lft 40117sec
       inet6 26<redacted>::12/128 scope global dynamic noprefixroute 
          valid_lft 40117sec preferred_lft 40117sec
       inet6 fe80::<redacted>e3/64 scope link 
          valid_lft forever preferred_lft forever

For IPv4, 192.168.3.12/24 means that all addresses from that range are considered a local subnet, i.e. 192.168.3.0 to 192.168.3.255.

For fddd::12/128, that translates to fddd::12 exclusively - so just that one address.

So you'd need an active ULA address with a fddd::/64 range.
In other words: Re-allow SLAAC.

Commonly, using SLAAC would be preferred over Stateful or Stateless DHCPv6.
Some OSs like Android do not support DHCPv6 at all, they use SLAAC exclusively.

2 Likes
9

Enabling SLAAC did fix the issue and I could set the DNS setting back to local only. Thank you!

Is it possible to get DHCPv6 to give out /64 addresses instead of /128? I like having such simple ipv6 addresses, the statefulness of DHCPv6, and the ability to tell devices their IPv6. But I don't like having 4 separate IPv6 addresses for every single interface, especially since it makes the logs confusing. (5 if you include the LLA)

10

No.
RFC8415 mandates that exact prefix length exclusively for an IPv6-address:

A client MUST NOT form an implicit prefix with a length other than 128 for this address. A 16-octet field.

You may want to reconsider your preferences.

Different IPv6 prefix ranges and interface identifier computation methods have been designed to adress different specific needs, e.g. RFC8981 (updating the older RFC4941 Privacy Extension addresses) may increase your privacy by making it harder to track your activities by remembering your IP address.

You are cutting yourself off from any of these potential benefits by going Stateful DHCPv6 only. In addition, you must have sufficient knowledge to properly deal with the implications (where the current case serves as an example). And as already mentioned, you are shunning out those clients that do not support DHCPv6 at all from joining your IPv6 network.

If you're still absolutely determined to do strictly Stateful DHCPv6, you probably could opt for defining a static IPv6 address on your Pi-hole host machine. But note that some network configuration tools may stop processing RAs if you'd define a static IPv6, so your host would not receive routing information automatically anymore.

All of the above is about IPv6 network configuration, rather than Pi-hole.
You may want to consider consulting other forums specialising in IPv6 networking issues for further insights. :wink:

2 Likes
11

I see. I see. Thanks for those links and I'll definitely reevaluate my choices to see if it still fits the network I want. Appreciate all the help you've given!

12

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