Ipv6 not blocking at least on custom address

Please follow the below template, it will help us to help you!

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

Expected Behaviour:

I am trying to block youtube(completely not just adds) on a custom group. When I disabled the ipv6 on my router it worked. When I give ping www.youtube.com I get an answer with ipv4 I did not (once the backlist was active)

Actual Behaviour:

With ipv6 active my blacklist group does not work, however, I am so fresh to pi-hole that I am not sure how to work with logs - I have a feeling that the standard add-blocking works for ipv6, but I am not sure...
I changed pi to be the DHCP server on my net and as far as I can see the pi is given as the DNS...

Debug Token:

[Replace this text with the debug token provided from running pihole -d (or running the debug script through the web interface]
https://tricorder.pi-hole.net/t2xg0zyr74

With IPv6, your router may be advertising its own IPv6 address as DNS server, and thus any device may by-pass Pi-hole via IPv6.

You'd have to find a way to configure your router to advertise your Pi-hole host machine's IPv6 as DNS server instead of its own.

You'd have to consult your router's documentation sources on further details for its IPv6 configuration options.

If your router doesn't support configuring IPv6 DNS, you could consider disabling IPv6 altogether.

If your router doesn't support that either, your clients will bypass Pi-hole via IPv6.

Yeah, well I have FritzBox 7490. As far as I can see I put the pihole DNS everywhere. When I look at my PC.
I get with ipconfig something like:

	Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : lan
   Description . . . . . . . . . . . : Intel(R) Ethernet Connection (2) I219-V
   Physical Address. . . . . . . . . : XX-XX-XX-XX
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2003:d4:c731:3e00::198(Preferred)
   Lease Obtained. . . . . . . . . . : 30 April 2021 07:06:19
   Lease Expires . . . . . . . . . . : 01 May 2021 07:06:18
   IPv6 Address. . . . . . . . . . . : 2003:d4:c731:3e00:4c96:e152:45a4:1582(Preferred)
   IPv6 Address. . . . . . . . . . . : fd00::198(Preferred)
   Lease Obtained. . . . . . . . . . : 30 April 2021 07:06:19
   Lease Expires . . . . . . . . . . : 01 May 2021 07:06:19
   IPv6 Address. . . . . . . . . . . : fd00::4c96:e152:45a4:1582(Preferred)
   Temporary IPv6 Address. . . . . . : 2003:d4:c731:3e00:9da0:4e0:e03b:cc95(Preferred)
   Temporary IPv6 Address. . . . . . : fd00::9da0:4e0:e03b:cc95(Preferred)
   Link-local IPv6 Address . . . . . : fe80::4c96:e152:45a4:1582%9(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.178.77(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 30 April 2021 07:06:16
   Lease Expires . . . . . . . . . . : 01 May 2021 07:06:27
   Default Gateway . . . . . . . . . : fe80::e228:6dff:fecb:67ad%9
                                       192.168.178.1
   DHCP Server . . . . . . . . . . . : 192.168.178.2
   DHCPv6 IAID . . . . . . . . . . . : 53517347
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-23-13-78-25-30-9C-23-68-B8-5D
   DNS Servers . . . . . . . . . . . : fd00::c5ee:dfc7:cc3f:458c
                                       2003:d4:c731:3e00:664d:4fef:8b8b:28ea
                                       192.168.178.2
                                       fe80::ac00:76eb:e4ce:c1dd%9
                                       2003:d4:c731:3e00::12e
   NetBIOS over Tcpip. . . . . . . . : Enabled

I have the pi-hole as DHCP and DNS. If I disable ipv6 from DNS tab in pihole I still get an ipv6 address in reply to the ping www.google.com does this indicate that there is another DNS still there somewhere? all of those DNS addresses in ipconfig are related to my pi, though:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.2/24 brd 192.168.178.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 2003:d4:c731:3e00::12e/128 scope global dynamic noprefixroute
       valid_lft 78966sec preferred_lft 78966sec
    inet6 fd00::12e/128 scope global dynamic noprefixroute
       valid_lft 78966sec preferred_lft 78966sec
    inet6 fd00::c5ee:dfc7:cc3f:458c/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 6998sec preferred_lft 3398sec
    inet6 2003:d4:c731:3e00:664d:4fef:8b8b:28ea/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 6998sec preferred_lft 972sec
    inet6 fe80::ac00:76eb:e4ce:c1dd/64 scope link
       valid_lft forever preferred_lft forever

Pinging an IP address is absolutely expected to be successful, regardless of Pi-hole's settings.
DNS -and thus Pi-hole- has no involvement with ping-ing an IP address.

You should use dig or nslookup to analyse DNS issues.

Note that DNS is capable of returning A and AAAA records regardless of the transport IP protocol used, so nslookup may well resolve a domain to IPv4 as well as IPv6 addresses even if IPv6 is completely disabled in your network or vice versa.
Unless you've www.google.com on one of your blocklists, successful resolution into IP addresses is expected.

As you can trace all the IPv6 addresses back to your Pi-hole host machine, your network seems to be correctly configured with regards to IPv6 DNS.

Yeah, I realized that with the IP and edited my post while you were answering. Anyway the google answered with ipv6, even when I had the ipv6 DNS disabled in pi? I am not sure what I should give for nslookup, but when giving that in windows command prompt in my client I get:

nslookup
Default Server: pihole.lan
Address: fd00::c5ee:dfc7:cc3f:458c

As explained:

So it's normal to receive a similar output as below, regardless of IPv6 or IPv4 or both being enabled:

nslookup www.google.com

Server:         192.168.178.2
Address:        192.168.178.2#53

Non-authoritative answer:
Name:   www.google.com
Address: 142.250.74.196
Name:   www.google.com
Address: 2a00:1450:4001:803::2004

The thing is, I got it all running just fine, when I disable the ipv6 on the router. So I think that my blacklist is ok so far. In that case I get no reply to ping www.youtube.com

When I activate the ipv6 in FritzBox with
IPv6 support enabled and IPV6 Connectivity - Option Use native IPv4 connection
(alternatives native IPv6 and use IPv6 tunnel protocol)

I can see that my DNS gets the IPV6 address of pi. I have changed all of the entries which have anything to do with DNS to point to pi. Yet it does not block anything anymore. Can't I see it somewhere on some log or another that the DNS on pi passed on the IPV6 address?

for nslookup it looks as if the IP addresses are coming from pi:

>nslookup www.youtube.com
Server:  pihole
Address:  192.168.178.2

Name:    youtube-ui.l.google.com
Addresses:  2a00:1450:4001:803::200e
          2a00:1450:4001:827::200e
          2a00:1450:4001:828::200e
          2a00:1450:4001:829::200e
          0.0.0.0
Aliases:  www.youtube.com

Now that's a most peculiar nslookup output.

Could you please show the corresponding log entries for such a lookup?

The following command may help with this when run from your Pi-hole host machine:

 grep -n www.youtube.com /var/log/pihole.log

The nslookup was done from my windows client.
The corresponding log entries:

Apr 30 23:37:16 dnsmasq[3371]: query[AAAA] www.youtube.com.fritz.box from 192.168.178.77
Apr 30 23:37:16 dnsmasq[3371]: forwarded www.youtube.com.fritz.box to 2001:4860:4860::8888
Apr 30 23:37:16 dnsmasq[3371]: reply www.youtube.com.fritz.box is NXDOMAIN
Apr 30 23:37:16 dnsmasq[3371]: query[A] www.youtube.com from 192.168.178.77
Apr 30 23:37:16 dnsmasq[3371]: exactly blacklisted www.youtube.com is 0.0.0.0
Apr 30 23:37:16 dnsmasq[3371]: query[AAAA] www.youtube.com from 192.168.178.77
Apr 30 23:37:16 dnsmasq[3371]: cached www.youtube.com is <CNAME>
Apr 30 23:37:16 dnsmasq[3371]: forwarded www.youtube.com to 2001:4860:4860::8888
Apr 30 23:37:16 dnsmasq[3371]: reply www.youtube.com is <CNAME>
Apr 30 23:37:16 dnsmasq[3371]: reply youtube-ui.l.google.com is 2a00:1450:4016:806::200e
Apr 30 23:37:16 dnsmasq[3371]: reply youtube-ui.l.google.com is 2a00:1450:4016:807::200e
Apr 30 23:37:16 dnsmasq[3371]: reply youtube-ui.l.google.com is 2a00:1450:4016:802::200e
Apr 30 23:37:16 dnsmasq[3371]: reply youtube-ui.l.google.com is 2a00:1450:4016:803::200e
Apr 30 23:37:16 dnsmasq[3371]: reply www.youtube.com.fritz.box is NXDOMAIN

That log confirms your observation, so we can rule out an external component on your client interfering with DNS results (as some antivirus DNS features sometimes would).

The difference between requesting A records for IPv4 and AAAA records for IPv6 is that Pi-hole is using a cached copy for the latter. Since www.youtube.com has a rather long TTL (of about a day), this could be a caching issue.

Could you restart Pi-hole via pihole restartdns reload, rerun your nslookups and check the logs again?

Ok,

On windows client:

>nslookup www.youtube.com
Server:  pihole
Address:  192.168.178.2

Name:    youtube-ui.l.google.com
Addresses:  2a00:1450:4001:828::200e
          2a00:1450:4001:829::200e
          2a00:1450:4001:82a::200e
          2a00:1450:4001:82b::200e
          192.168.178.2
Aliases:  www.youtube.com

...and at the same time on pi:

May  1 08:31:02 dnsmasq[583]: query[PTR] 2.178.168.192.in-addr.arpa from 192.168                                                .178.77
May  1 08:31:02 dnsmasq[583]: /etc/pihole/local.list 192.168.178.2 is pihole
May  1 08:31:02 dnsmasq[583]: query[A] www.youtube.com.fritz.box from 192.168.17                                                8.77
May  1 08:31:02 dnsmasq[583]: forwarded www.youtube.com.fritz.box to 8.8.4.4
May  1 08:31:02 dnsmasq[583]: reply www.youtube.com.fritz.box is NXDOMAIN
May  1 08:31:02 dnsmasq[583]: query[AAAA] www.youtube.com.fritz.box from 192.168                                                .178.77
May  1 08:31:02 dnsmasq[583]: forwarded www.youtube.com.fritz.box to 8.8.4.4
May  1 08:31:02 dnsmasq[583]: reply www.youtube.com.fritz.box is NXDOMAIN
May  1 08:31:02 dnsmasq[583]: query[A] www.youtube.com from 192.168.178.77
May  1 08:31:02 dnsmasq[583]: exactly blacklisted www.youtube.com is 192.168.178                                                .2
May  1 08:31:02 dnsmasq[583]: query[AAAA] www.youtube.com from 192.168.178.77
May  1 08:31:02 dnsmasq[583]: forwarded www.youtube.com to 8.8.4.4
May  1 08:31:02 dnsmasq[583]: reply www.youtube.com is <CNAME>
May  1 08:31:02 dnsmasq[583]: reply youtube-ui.l.google.com is 2a00:1450:4001:82                                                8::200e
May  1 08:31:02 dnsmasq[583]: reply youtube-ui.l.google.com is 2a00:1450:4001:82                                                9::200e
May  1 08:31:02 dnsmasq[583]: reply youtube-ui.l.google.com is 2a00:1450:4001:82                                                a::200e
May  1 08:31:02 dnsmasq[583]: reply youtube-ui.l.google.com is 2a00:1450:4001:82                                                b::200e

I'd expect that to return 0.0.0.0 instead of your Pi-hole's IP.
Did you change your installation in the meantime, e.g. switch to another blocking mode?

I cannot reconstruct your behaviour on my machine:
I get a consistent 0.0.0.0 / :: result if I block www.youtube.com exactly, both when using the default group or when applying client-based filtering as you did.

No, at least not consciously. I have been trying some things, I found from net, for example changes on pihole-FTL.conf, other than that...:

$ cat /etc/pihole/pihole-FTL.conf
AAAA_QUERY_ANALYSIS=no
RESOLVE_IPV6=no
DEBUG_RESOLVER=true
BLOCKINGMODE=IP
PRIVACYLEVEL=0

I have activated all four DNS checkboxes for google DNS so I have something like this in setupVars.conf:

DNSMASQ_LISTENING=single
PIHOLE_DNS_1=8.8.8.8
PIHOLE_DNS_2=8.8.4.4
PIHOLE_DNS_3=2001:4860:4860:0:0:0:0:8888
PIHOLE_DNS_4=2001:4860:4860:0:0:0:0:8844
DNS_FQDN_REQUIRED=true
DNS_BOGUS_PRIV=true
DNSSEC=false
REV_SERVER=false

Other than that, no idea where to look for it...

This looks self-inflicted. Copy/Pasting random configurations that you find on the net is going to both confuse you and frustrate anyone trying to provide you help while you're changing things without understanding what you've changed or telling us that you're changing it.

https://docs.pi-hole.net/ftldns/configfile/#aaaa_query_analysis

AAAA_QUERY_ANALYSIS=yes|no

Should FTL analyze AAAA queries? The DNS server will handle AAAA queries the same way, reglardless of this setting. All this does is ignoring AAAA queries when computing the statistics of Pi-hole. This setting is considered obsolete and may be removed in a future version.

https://docs.pi-hole.net/ftldns/configfile/#resolve_ipv6

RESOLVE_IPV6=yes|no

Should FTL try to resolve IPv6 addresses to hostnames?

https://docs.pi-hole.net/ftldns/configfile/#blocking_mode

BLOCKINGMODE=NULL|IP-NODATA-AAAA|IP|NXDOMAIN

How should FTL reply to blocked queries?

Thanks. I removed those entries and left this:

$ cat /etc/pihole/pihole-FTL.conf
DEBUG_RESOLVER=true
PRIVACYLEVEL=0

Now it is working. The initial problem where I started going wrong was, that in my first trial I had given MAC Address of my WLAN Adapter. Later on when I started working on the further lists I was on LAN and once it was not blocking I started looking at solutions and overlooked the wrong MAC Address. There are similar cases and in some of them those parameters apparently solved some of those cases, in my case they introduced the problem. I am just not the RTFM type, I am a trial and error person and I am too old dog to learn new tricks or become housetidy. So, yes, in the end it was indeed self-inflicted, sorry about that and thanks for the help solving the problem.

Yes. The description of AAAA_QUERY_ANALYSIS is pretty old and certainly outdated by now. It comes right from 2017 when this was still accurate. It was before regex blocking any many more things were added.

This setting actually does what it says: It disables any kind of analysis. Including checking AAAA queries against groups etc. so they would never be blocked when this setting it set to true. This will hurt more often than it was useful in the past which is also why