Very strange IPv6 blocking addresses


#49

Okay, this bugfix will be included in v4.2 and, as such, the bug never hit any released version but was only present in development. Thanks for your report and the continued testing!


#50

Is this a dnsmasq2.80 bug or a pihole-FTL bug?


#51

Reading the commit then it seems more like a communication problem between both when using Null blocking.


#52

It’s a pihole-FTL bug and got introduced when I optimized the memory footprint by summarizing the A and AAAA records in one cache entry rather recently. Cache entries with validity for both, A and AAAA requests are not available in dnsmasq (those are wildcards).


#53

It was still nagging me that I also had on my Linux devices had still the first full domain name after a Null IPv4 blocking. So I put a special domain name at the first line of the two blacklist files. I did the nslookup and the Linux device displayed the full domain name, I just entered before restarting Pi-hole. I don’t have dig available on these devices to I have resort to use nslookup.

nslookup facebook.com
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name:      facebook.com
Address 1: 0.0.0.0 testingmemip4.com
Address 2: ::

Pihole.log

Jan  5 11:08:55 dnsmasq[5136]: query[A] facebook.com from 192.168.XX.107
Jan  5 11:08:55 dnsmasq[5136]: /etc/pihole/regex.list facebook.com is 0.0.0.0
Jan  5 11:08:55 dnsmasq[5136]: query[AAAA] facebook.com from 192.168.XX.107
Jan  5 11:08:55 dnsmasq[5136]: /etc/pihole/regex.list facebook.com is 0.0.0.0
Jan  5 11:08:55 dnsmasq[5136]: query[PTR] 0.0.0.0.in-addr.arpa from 192.168.XX.107
Jan  5 11:08:55 dnsmasq[5136]: /etc/pihole/black.list 0.0.0.0 is testingmemip4.com

2019-01-05 10:08:55 PTR 0.0.0.0.in-addr.arpa 192.168.XX.107 Blocked (blacklist)

When I run dig on the Pi-hole itself I get:

dig +short ptr 0.0.0.0.in-addr.arpa
testingmemip4.com.

Here it seems to be caused by the PTR request.

Running: FTL Version vDev (release/v4.2, vDev-f6be502)


#54

I think this might be normal behavior of nslookup. Also, there may be different flavors of nslookup floating around so the particular behavior may depend on the operating system and the source nslookup was installed from. However, I don’t know. Pinging @DanSchaper as he might know.

I suspect that this is normal behavior for nslookup as it might do an A lookup and then a PTR on the returned IP and show this whenever the returned hostname differs from the requested domain. Have a look at the latest snippet you posted. It is not only in the Answer section:

but also in the server section:


#55

The program nslookup put me on the trail of this.

Maybe you did not see or ignored that I also put an dig result of this in my posting. Which indicates the same false result as nslookup does.

Maybe better is to return a nxdomain on a 0.0.0.0.in-addr.arpa


#56

Thanks for the clarification, I misunderstood your original question. You’re asking why Pi-hole returns this host name, not why nslookup is showing it.

When I run a similar command, I get a similar answer:

$ dig +short ptr 0.0.0.0.in-addr.arpa
www.aviationweather.gov.

This domain is the last entry of my black.list. We had this behavior before when the IP blocking mode and have not checked it for the NULL mode, thanks for pointing this out. Unfortunately, our bugfix back then will not work here, but I put this in the top of my ToDo list to find a solution that will be included in the next release of FTL.


#57

Thank you for the reply and it seem that I am mostly hitting the exotic problems in software. :slight_smile:


#58

#59

@msatter The fix has been merged into, both, release/v4.2 and development.


#60

Thanks, I have it already running for a few hours. It tested good and thank you very much for fixing this.