Very strange IPv6 blocking addresses


#1

Expected Behaviour:

receive :: as blocking address

Actual Behaviour:

receiving :: with random stuff in added to the addresses

I am running DEV: Version vDev (development, v3.3.1-577-ga36734d) Web Interface Version vDev (devel, v3.3-362-g193e43c) FTL Version vDev (development, vDev-d288b7d)

nslookup on PC with Pi-hole as DNS server.

Name:    sls.update.microsoft.com
Addresses:  ::ba27:ebff:fe6b:420b
          0.0.0.0

Name:    doubleclick.com
Addresses:  ::5500:0:5600:0:5700:0
          0.0.0.0

Name:    facebook.com
Addresses:  ::5500:0:5600:0:5700:0
          0.0.0.0

Name:    facebook.com
Addresses:  0:0:1400::
          0.0.0.0

After a restart of Pihole-FTL the last lookup for facebook put the random stuff in front of ::


#2

I’m on the same version as you are

# ./pihole-FTL version
v4.1-95-gd288b7d

but cannot reproduce this

# nslookup -querytype=AAAA doubleclick.com
Server:         127.0.0.1
Address:        127.0.0.1#53

doubleclick.com has AAAA address ::
# nslookup -querytype=AAAA facebook.com
Server:         127.0.0.1
Address:        127.0.0.1#53

facebook.com    has AAAA address ::

Is there anything spacial about your configuration? What are the contents of /etc/pihole/pihole-FTL.conf (if any)?


#3

Content of phole-FTL.conf

MAXDBDAYS=2
DBINTERVAL=10.0
DBIMPORT=yes
IGNORE_LOCALHOST=yes
PRIVACYLEVEL=0


# nslookup facebook.com
Server:    192.168.xx.xx
Address 1: 192.168.xx.x server-01

Name:      facebook.com
Address 1: 0.0.0.0 wpad
Address 2: ::2500:0:2d00:0:3c00:0

The interesting part is that I have the word “wpad” to the IPv4 address.

I am going to disable any wpad protection entries and look if that was the cause.

This is in my /etc/hosts file:

# Cert vulnerability 598349
0.0.0.0 wpad
:: wpad

Going to remove it and restart pi-hole.

That did nothing so next the regex/list

^wpad\.

That was it also not…


#4

This looks strange to request the PTR of 0.0.0.0 and ::


#5

The Pi-hole itself should not look up these domains. Did these queries originate from your Pi-hole or for your client (judging by the displayed IP address)?


#6

I’m not too familiar with the tool nslookup but I assume it shows wpad for you as your /etc/hosts specified 0.0.0.0 wpad, i.e., the address 0.0.0.0 is the host name wpad. So this, at least, is correct.


#7

It was not the pi-hole system but an other unix having not wpad in the hosts file. Wpad is comming from the pi-hole stystem.

Now it gives an other domain behind 0.0.0.0. now I removed the wpad lines.

I tested it a one or few version ago to test new wildcard format in 2.80 and then it was working as expected then.

My clients don’t use IPv6 (only local) so it not a big problem right now. Going get back pi-hole out of retitrement and update that to Master.


#8

I have activated my backup Pi-hole and that one was on the DEV version. Updated it to the last version and it shows exactly the same behavior as my current pi-hole.

Downgraded the backup Pi-hole to MASTER and the strange behaviour was gone. So it only occurs in the DEV version.

Server:  backup.pi.hole
Address:  192.168.XX.4

Name:    facebook.com
Addresses:  ::
          0.0.0.0

And the log when starting:

[2018-12-16 16:20:56.339] ########## FTL started! ##########
[2018-12-16 16:20:56.339] FTL branch: development
[2018-12-16 16:20:56.339] FTL version: 
[2018-12-16 16:20:56.339] FTL commit: d288b7d
[2018-12-16 16:20:56.339] FTL date: 2018-12-13 20:06:40 -0500
[2018-12-16 16:20:56.339] FTL user: pihole
[2018-12-16 16:20:56.339] Starting config file parsing (/etc/pihole/pihole-FTL.conf)
[2018-12-16 16:20:56.340]    SOCKET_LISTENING: only local
[2018-12-16 16:20:56.340]    AAAA_QUERY_ANALYSIS: Show AAAA queries
[2018-12-16 16:20:56.340]    MAXDBDAYS: max age for stored queries is 2 days
[2018-12-16 16:20:56.340]    RESOLVE_IPV6: Resolve IPv6 addresses
[2018-12-16 16:20:56.340]    RESOLVE_IPV4: Resolve IPv4 addresses
[2018-12-16 16:20:56.340]    DBINTERVAL: saving to DB file every 600 seconds
[2018-12-16 16:20:56.340]    DBFILE: Using /etc/pihole/pihole-FTL.db
[2018-12-16 16:20:56.340]    MAXLOGAGE: Importing up to 24.0 hours of log data
[2018-12-16 16:20:56.340]    PRIVACYLEVEL: Set to 0
[2018-12-16 16:20:56.340]    IGNORE_LOCALHOST: Hide queries from localhost
[2018-12-16 16:20:56.340]    BLOCKINGMODE: Null IPs for blocked domains
[2018-12-16 16:20:56.340]    REGEX_DEBUGMODE: Inactive
[2018-12-16 16:20:56.340]    ANALYZE_ONLY_A_AND_AAAA: Disabled. Analyzing all queries
[2018-12-16 16:20:56.340]    DBIMPORT: Importing history from database
[2018-12-16 16:20:56.340]    PIDFILE: Using /var/run/pihole-FTL.pid
[2018-12-16 16:20:56.340]    PORTFILE: Using /var/run/pihole-FTL.port
[2018-12-16 16:20:56.340]    SOCKETFILE: Using /var/run/pihole/FTL.sock
[2018-12-16 16:20:56.340]    WHITELISTFILE: Using /etc/pihole/whitelist.txt
[2018-12-16 16:20:56.340]    BLACKLISTFILE: Using /etc/pihole/black.list
[2018-12-16 16:20:56.340]    GRAVITYFILE: Using /etc/pihole/gravity.list
[2018-12-16 16:20:56.340]    REGEXLISTFILE: Using /etc/pihole/regex.list
[2018-12-16 16:20:56.340]    SETUPVARSFILE: Using /etc/pihole/setupVars.conf
[2018-12-16 16:20:56.340]    AUDITLISTFILE: Using /etc/pihole/auditlog.list
[2018-12-16 16:20:56.340] Finished config file parsing

And the ports:

tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      0          12809      619/unbound
tcp        0      0 192.168.XX.40:53         0.0.0.0:*               LISTEN      999        11150      551/pihole-FTL
udp        0      0 127.0.0.1:53            0.0.0.0:*                           0          12808      619/unbound
udp        0      0 192.168.XX.40:53         0.0.0.0:*                           999        11149      551/pihole-FTL

#9

Msatter has left the DEV version and entered the Master version of Pi-hole.

All is back to normal now.


#10

I think I somehow know what might be happening (even if it is not happening for me): The IPv6 address may only be partially initialized and not all elements have been set to zero… If you are willing to continue testing, I can try to come up with a solution soon.


#11

I don’t mind to test further and let me know when I can have go and I change to DEV again.
Remember that IPv4 also had a added word wpad on a system that did not know it.
It was comming from the Pi-hole.

The last time I tried it it was the first entry from the blacklist on the Pi-hole. That name was also unkown to that system.

I suspect I kind of internal leaking/overflow of data inside pi-hole.


#12

It would be nice if you could try the new tweak/zero_init_all_addr_structs branch on the FTL repository.


#14

Got it I had to put ftl in front. I see that mcat12 has made a correction.

Saddly this version did not correct the problem.

I tried nslookup on a other Linux device and it sends the first entry from black.list / blacklist.txt appended to the IPv4 address.

nslookup facebook.com 192.168.XX.4
Server:    192.168.XX.4
Address 1: 192.168.XX.4 pi2.hole

Name:      facebook.com
Address 1: 0.0.0.0 api.openweathermap.org
Address 2: ::e100:0:ea00:0:2000:0

#15

This is maybe something important. The location of the added info can added behind :: and after a restart it is added in front of the ::.

nslookup facebook.com 192.168.XX.4
Server:    192.168.XX.4
Address 1: 192.168.XX.4 pi2.hole

Name:      facebook.com
Address 1: 0.0.0.0 api.openweathermap.org
Address 2: 0:0:500:0:4187::

#16

This is not the problem we’re trying to solve here , this is probably correct behavior from your local version of nslookup (show the first returned PTR result for the returned IP address). Please retry with, e.g.,

dig +short facebook.com

Only if we see the domain here as well, I start to get worried…


The problem we’re dealing with here is the "strange things before/after ::" issue.

I have two more questions for you:

  1. What is your blocking mode?
    If your blocking mode is “IP” (I’m assuming this), please add the line IPV6_ADDRESS=:: to your /etc/pihole/setupVars.conf, restart FTL and try again. Is the IPv6 answer now always :: without any extras?
  2. Please remove the line you just added to setupVars.conf again, update FTL and verify that my latest change resolve this issue even without having to add such a line.

#17

I have to wait till my backup Pi-hole is recovered and I tried to upgrade it from Stretch to Buster and a NWS after that.

As far as I remember I am using Null blocking as that is the the default blocking method in Pi-hole.

Also I want to bring forward that I had/have not the problem in current Master and up to in the first version of DEV 4.1.x.

Those NSlookups came from two Linux devices and one Windows 10 system. I tried to Wireshark the traffic in the router but I went through the switch part so not visible. The Pi-hole is connected and only reachable by the router/switch.

As soon the backup Pi-hole is running again I will run dig and post the findings.

Update:

I had some time before my backup Pi-hole was recovered and maybe my findings have to do with this: https://github.com/pi-hole/FTL/pull/419


#18

First results and this is before going to the tweaked version just to confirm the problem is still there:

Commands and results:
nslookup

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

Name:    facebook.com
Addresses:  ::2500:0:2d00:0:3c00:0
          0.0.0.0
dig @192.168.XX.X +short facebook.com
0.0.0.0

dig @192.168.XX.X +short AAAA facebook.com
::2500:0:2d00:0:3c00:0

Query screen

2018-12-18 10:04:06 	AAAA	facebook.com	192.168.XX.XXX	Blocked (regex/wildcard)	- (0.4ms)	
2018-12-18 10:03:35 	A	facebook.com	192.168.XX.XXX	Blocked (regex/wildcard)	- (0.3ms)	
2018-12-18 10:02:59 	PTR	X.XX.168.192.in-addr.arpa	192.168.XX.XXX	Unknown	N/A	
2018-12-18 10:02:59 	A	facebook.com	192.168.XX.XXX	Blocked (regex/wildcard)	- (3.1ms)	
2018-12-18 10:02:59 	AAAA	facebook.com	192.168.XX.XXX	Blocked (regex/wildcard)	- (0.3ms)

Tried your suggestions of switching over to IP blocking and adding IPV6_ADDRESS=:: and then I get clean IP addresses returned.

First results of the tweaked version:

IPv6 still extra information in front and after :: also the first entry from the black.list behind the IPv4.

I am now having my late breakfast. :slight_smile:


#19

Yes, I was already thinking that the mentioned PR is the source of the problems and my tweak branch was targeting this direction of though. Can you quickly verify with pihole-FTL version if you are indeed on the latest commit of the tweak branch?


#20

I am on vDev-d058eaf


#21

Okay, that’s fine. Just to make this clear:

  1. On blocking mode NULL, you see the strange IPv6 return
  2. On blocking mode IP and IPV6_ADDRESS=:: set, everything is okay

Correct?