Very strange IPv6 blocking addresses


Confirming with Null mode strange IPv6 returns plus.

With my config IPV6_address=fe80::…

Server: pi.hole
Address: 192.168.XX.X

Addresses: fe80::…

With tweaked config IPV6_address=::
Server: pi.hole
Address: 192.168.XX.X

Addresses: ::

I had this time removed the RaspberryPI own IPv6 address from setupVars.conf because that invalidated the result.


FTL version is vDev-c46a744 (Latest: v4.1) did not change the outcome.

Managed to Wireshark the conversation:


Compared to the current master 4.1:



I am using since a few days the command: pihole disable 2s instead of pihole restartdns reload.

Often the gravity.list is not put back and so empty…but the strange thing is that the first line of gravity.list was returned ( to the client while the gravity.list was empty.



Testing 4.1.2 and the IPv6 seems to be clean ( :: ) and I got still an extra blacklist line attached to the IPv4. Have to boot an other linux device to test it more.

  Pi-hole version is v3.3.1-579-g3bb94d4 (Latest: v4.1.1)
  AdminLTE version is v4.1-12-g798486b7 (Latest: v4.1.1)
  FTL version is vDev-ab9dc6e (Latest: v4.1.2)


  Pi-hole version is v3.3.1-581-gb984fc4 (Latest: v4.1.1)
  AdminLTE version is v4.1-12-g798486b7 (Latest: v4.1.1)
  FTL version is vDev-6fc52c6 (Latest: v4.1.2)

Addresses:  ::2500:0:2d00:0:3c00:0



I noticed just that the strange values only occur when there is a OPT flag at the end of Wireshark line.

I searched for this and this indicates that EDNS is being used. In Pi-hole I have disabled DNSSEC.

The first version of DNSmasq 2.80 seemed not to have the extra information sent but the latest DEV versions do. I am not sure any more that it worked good in the DEV because of I did not know if normal DNS was used or EDNS.


Is there a way of reproducing this reliably so I could look into it myself a bit more?


On the Raspberry self running the development version of Pi-hole:

dig +short AAAA


I tried this with Pi-hole on exactly the same commit you’re using but still don’t see the extra bits even when OPT is present in Wireshark:

FWIW, I’m blocking facebook and a few siblings with a regex rule.


The only difference is that I put in the DNS request in not on the localhost address but on the external address.

I have this behaviour on both RaspberryPI one Jessie and on Stretch.

When I upgrade Master to Development it starts and when I go back to Master it is normal again. So I don’t a rebuild will help.


Please elaborate on this, I don’t really know what you mean.

I do believe that there is a problem as you’re constantly seeing this. I’m not trying to say that you are doing something wrong or crazy, I just need to be able to reproduce this in order to analyze the origin, as I already looked two times in depth at the corresponding code can wasn’t able to identify any possible issues that could lead to what you observe.


I have Unbound running on localhost port 53 and Pi-hole is running at the interfacing addres.

# netstat -tulpn | grep :53
tcp        0      0 192.168.xx.xx:53*               LISTEN      999        2293404     13588/pihole-FTL
tcp        0      0  *               LISTEN      0          2258532     3766/unbound
udp        0      0 192.168.xx.xx:53*                           999        2293403     13588/pihole-FTL
udp        0      0  *                           0          2258531     3766/unbound
tcp6       0      0 fe80::..............:53 :::*                    LISTEN      999        2293406     13588/pihole-FTL
udp6       0      0 fe80::..............:53 :::*                                999        2293405     13588/pihole-FTL

I thank you for your help and I am looking for a way to not have a EDNS answer triggered to see if it is really that. Then you had an EDNS answer without any extras. I tried with Unbound disabled and Pi-hole also listening at to no avail.

Update: I just performed a lookup on the Development and that was answered without an OPT (EDNS) and with extra information so EDNS is not longer a suspect. :wink:


So it also happens for the most simple setup, i.e.,

  • having pihole-FTL on default settings, and
  • use a standard upstream provider such as,, or ?

I still have no clue what it might be, so it would be good if you can confirm this on a setup with standard parameters, just switched to development branches.


That is strange. I uninstalled Pi-hole and then installed it with master and moved to dev. Now the version number of Pi-hole is increased, was Pi-hole version was: v3.3.1-579-g3bb94d4 (Latest: v4.1.1)

  Current Pi-hole version is v4.0-189-g262d5ee
  Current AdminLTE version is v4.1-12-g798486b7
  Current FTL version is vDev-62a4de6

Going to disable Unbound and restart the RaspberryPI…nope still no clean resolv.

~# dig +short AAAA

So a clean install still produces no clean IPv6 block (::).


Any advances? How about the pihole.log file? Is the strange address also visible in here?


I hoped for advances with the latest FTL but that was short lived. On reboot it was back.

My log states:

Jan  1 13:04:51 dnsmasq[549]: query[PTR] from 192.168.XX.XXX
Jan  1 13:04:51 dnsmasq[549]: /etc/hosts 192.168.XX.X is pi.hole
Jan  1 13:04:51 dnsmasq[549]: query[A] from 192.168.XX.XXX
Jan  1 13:04:51 dnsmasq[549]: /etc/pihole/black.list is
Jan  1 13:04:51 dnsmasq[549]: query[AAAA] from 192.168.XX.XXX
Jan  1 13:04:51 dnsmasq[549]: /etc/pihole/black.list is


Since I wasn’t able to reproduce this so far there wasn’t anything I did that could have caused an improvement.

Okay, please try

sudo pihole checkout ftl fix/msatter_crazy_IPv6

and look for another log snippet like you posted above. I haven’t changed any functionality but only the logging. The commit (see version string) should be 1a2be05.


Now it shows also in the log:

Jan  1 14:52:03 dnsmasq[4312]: query[AAAA] from 192.168.XX.X
Jan  1 14:52:03 dnsmasq[4312]: /etc/pihole/black.list is ::905b:e501:0:0:9d34:5800

Thank for working on it on New Years day and this is the testing version so not live on my side. I am running Master currently.

ps. when I use nslookup it states the two requests:

Jan  1 14:56:41 dnsmasq[542]: query[A] from 192.168.XX.XXX
Jan  1 14:56:41 dnsmasq[542]: /etc/pihole/black.list is ::905b:6601:0:0:9d54:4900
Jan  1 14:56:41 dnsmasq[542]: query[AAAA] from 192.168.XX.XXX
Jan  1 14:56:41 dnsmasq[542]: /etc/pihole/black.list is ::905b:6601:0:0:9d54:4900


This is expected. The dnsmasq logging routine can only either log an IPv4 or an IPv6 address. It preferred IPv4 before and prefers IPv6 in the version you’re testing.

Now we at least know that this comes from inside dnsmasq's cache and is not, e.g., a transmission artifact.
Please update FTL (version commit should be ddae44d) and test again. There was an incomplete memory copy process that might be the explanation for what you’ve been seeing.


Hi DL6ER, it look good now and even after a reboot of the RaspberryPI there is no addition info sent.

Jan  1 17:26:55 dnsmasq[5242]: query[AAAA] from 192.168.XX.4
Jan  1 17:26:55 dnsmasq[5242]: /etc/pihole/black.list is
Jan  1 17:27:00 dnsmasq[5242]: query[PTR] from
Jan  1 17:27:00 dnsmasq[5242]: config 192.168.XX.177 is NXDOMAIN
Jan  1 17:27:29 dnsmasq[5242]: query[A] from 192.168.XX.107
Jan  1 17:27:29 dnsmasq[5242]: /etc/pihole/black.list is
Jan  1 17:27:29 dnsmasq[5242]: query[AAAA] from 192.168.XX.107
Jan  1 17:27:29 dnsmasq[5242]: /etc/pihole/black.list is
Jan  1 17:27:29 dnsmasq[5242]: query[PTR] from 192.168.XX.107
Jan  1 17:27:29 dnsmasq[5242]: /etc/pihole/black.list is
Jan  1 17:28:00 dnsmasq[5242]: query[PTR] from
Jan  1 17:28:00 dnsmasq[5242]: config 192.168.XX.107 is NXDOMAIN

I tried it on three different system of which one was a Windows10. I prefer nslookup because I get both addresses back in one go.

Thank you for being that patient in this all.