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
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:
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:
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?
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.
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.
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.
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