Domain being blocked but shown as not blocked in query


#26

It depends. It would still be useful if you could run the grep command I suggested. I planned to explain what happens based on your response, but I can also explain the principles without this:

  1. Assume you query gstaticadssl.l.google.com. It is blocked by Pi-hole because it is in black.list. So far - so easy.
  2. Assume you query whatever.google.com and your Pi-hole doesn’t know the answer. It forwards whatever.google.com to your upstream destination. The upstream server replies with:
    whatever.google.com is a CNAME.
    REPLY: - gstaticadssl.l.google.com is 216.58.211.99
           - gstaticadssl.l.google.com is 172.217.20.99
    
    This is then immediately forwarded to your client as it is a valid response of the query. It is not intended to process the return of your upstream server and validate it against the known blocked domains. This is not possible with dnsmasq and hence also not with pihole-FTL which is based on it.

#27

8 posts were split to a new topic: CNAME, running two Pi-Holes together


#28

By three files you mean regex/blacklist/gravity?

Regex works and also gravity that I can see in the webinterface when blocking other domains.

None of the domains in the blacklists are represented correctly in the webinterface when blocked.

I will test gvt1.com in each file separate later on the evening.


#29

what should i do, remove it from my personal lists and block it only in blacklist ? And see what the results are in a day or so ? i am just testing :slight_smile:


#31

A post was merged into an existing topic: CNAME, running two Pi-Holes together


#38

Here are the three types of blocking:


#39

A post was merged into an existing topic: CNAME, running two Pi-Holes together


#40

How do the corresponding log lines (/var/log/pihole.log) look like?


#41

how to explain ?


#42

I can run the test again. I bet they won’t look any different than pihole.log entries I stated before.


#43

Also on the latest dev version.

Added “gvt1.com” to the blacklist as an exact block, and it shows on the web GUI in the Exact blocking section… Ran “dig” for that domain from a connected client (NULL returned) and get this in the pihole.log.

Oct 12 11:26:00 dnsmasq[8277]: query[A] gvt1.com from 192.168.0.135
Oct 12 11:26:00 dnsmasq[8277]: /etc/pihole/regex.list gvt1.com is 0.0.0.0

The query log showed that the request was OK (cached):

Then, clear “gvt1.com” from the blacklist and add it back as a wildcard. Now it shows in the Regex & Wildcard blocking section as * (^|.)gvt1.com$.

Ran “dig” for that domain from a connected client (NULL returned) and get this in the pihole.log.

Oct 12 11:36:43 dnsmasq[8277]: query[A] gvt1.com from 192.168.0.135
Oct 12 11:36:43 dnsmasq[8277]: /etc/pihole/regex.list gvt1.com is 0.0.0.0

Query log shows this: original query at bottom, two digs at top. Request was blocked by regex/wildcard.


#44

Thanks jfb for confirming. Looking at the first log lines are stating it came from the regex.list and I think it must have stated Null.


#45

I didn’t see the (null) in the pihole.log, but I did get a NULL (0.0.0.0) reply to the DNS query.


#46

Then if you add as exact then how is it ending up in regex.list?


#47

It isn’t in the regex list, but the query log is showing that it is.

 cat /etc/pihole/blacklist.txt
    checking-apple-forcleaning1.com
    www.spreediscount.com
    gvt1.com

#48

Lets hope it is resolved before 4.1 is released. :grinning:

Personally I think that has to that the blocked domain is moved into cache and there race condition between the request/answer and the cache when moving to log and database.


#49

Eeeehm first will the regex be processed and if there is a match then processing stops.

So if you had it in the regex then it would explain the regex.list. More puzzling is then why black.list seem to be still being processed causing green cached line.

I will test if this is possible.

Tested it and regex.list is beating everyone in making the catch so no explanation for that earlier result.


#50

The first time I ran this, the domain had not been in the regex list. It was only added to the black list at that point. Then subsequently removed from the black list and placed in regex.


#51

I agree that something is definitely fishy here. I only recently moved to a new flat and still have no Internet here (I’m only on a rather limited mobile data plan with 1GB per month) so my coding/debugging capabilities are really limited at the moment. Unfortunately, construction work is going on here and it’s totally unforeseeable when I can get proper connectivity :confused: .

We can surely block the release of 4.1 until we have confirmed/resolved the reported problems. I see two issues here:

  1. The shown status in the Query Log is wrong (and hence the color)
  2. @jfb is getting shown that the domain was cached on the Query Log, that it was regex blocked in the pihole.log file although the domain is actually exact (blacklist blocked). This is much more severe in my eyes and a counter that is off by one or something similar may explain this as well as the other issue.

As soon as I can get a mobile data uplink that is stable enough to try to reproduce this on my Pi-hole, a fix shouldn’t take long. It is important for me that pihole-FTL is bug free. I may be able go somewhere tomorrow (e.g. to a coffee shop) for stable Internet, let’s see how I can arrange things.


#52

It is only cosmetical so I have a relaxed position on it.

The functionality is not impeded as far as I can see.

Goodluck with your new flat and getting hooked up to the Internet.