Whitelisted items are still blocked!

Expected Behaviour:

When I whitelist a domain, it will allow me to get that value in DNS.

I installed Pi-Hole through TrueNAS (not TrueCharts). It runs as a Docker container on their Kubernetes app infrastructure.

It's not machine-dependent either. My PC with two NICs and my phone on Wi-Fi both experience the same issue.

Actual Behaviour:

Pi-Hole allows me to whitelist domains, but for some reason, they still show up as blocked even in the Query Log where I whitelisted the domain.

Even if I disable the blocklists in Pi-Hole, I still can't get to those domains.

I'm also making sure to run ipconfig /flushdns each time before I try. Is there anything special I need to do when running it?

When I do an nslookup using 1.1.1.1, I'm also seeing 0.0.0.0 as the response, but that shouldn't be correct. So it's like all DNS queries are going through Pi-Hole from my NICs.

If I query from my PC to my phone's mobile hotspot to its LTE connection, then I can get IPs back in my DNS query.

Debug Token:

https://tricorder.pi-hole.net/cfik2IE7/

I noticed that some whitelisted entries work fine, but others do not. Is it possible there's a blocklist taking priority over my whitelist overrides?

Taking it one step further, even disabling Pi-Hole or swapping to another DNS server by manually setting up my IPv4 IP in Windows, I have the same issue.

I can get to this URL from my phone on LTE, so I know it's possible. I also looked up the DNS entry, and it's there.

But for some reason, these links no longer work from inside my network only after setting up Pi-Hole.

Whitelist always takes precedence.

The priority is:

  1. Exact Whitelist
  2. Regex Whitelist
  3. Exact Blacklist
  4. Blocklist domains (AKA gravity)
  5. Regex Blacklist

If a domain is found anywhere from top to bottom, FTL skips the rest of the tests.

I believe you. Then I wonder why some can't be resolved using DNS. Either those domains only work with IPv6, they don't support DNSSec (which I tried disabling too), or something else is wrong.

It worked fine normally, so I'm wondering if it's some combination of these that's causing the issue. Also note, the Pi-Hole was blocking these URLs, and when requested, it does show they're blocked in the UI.

Could you provide an example of such a blocked domain, e.g. by sharing the result of

nslookup blockdomain

along with the corresponding log lines from the UI and/or /var/log/pihole/pihole.log?

1 Like
# nslookup blockdomain
Server:         172.17.0.10
Address:        172.17.0.10#53

** server can't find blockdomain: NXDOMAIN

Here's a simple one for when I try to click on emails from Reddit:

This might be a different issue. Now that I'm seeing this log, it looks like 1.1.1.2 said it doesn't exist, but I never had these issues from my UniFi router when it connected out to 1.1.1.2, but even if I query it or 1.1.1.1 directly, it still doesn't work.

C:\Users\xxxxx>nslookup click.redditmail.com 10.1.0.1
Server:  setup.ui.com
Address:  10.1.0.1

Name:    click.redditmail.com
Addresses:  ::
          0.0.0.0


C:\Users\xxxxx>nslookup click.redditmail.com 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Name:    click.redditmail.com
Addresses:  ::
          0.0.0.0

This URL works fine when connected through my phone's mobile hotspot or on my phone itself.

Ah - I didn't mean to lookup blockdomain verbatim, but for you to substitute that with 'such a blocked domain', and then share the results, along with Pi-hole's corresponding log lines. :wink:

Correlating the log files with your nslookup will allow us to tell if Pi-hole did actually receive those queries and how they were processed.

That nslookup output seems to suggest that it is 1.1.1.1 that is blocking click.redditmail.com.
However, I do not see that block when using 1.1.1.1, so there may be something different at play here.

1 Like

What could be causing the issue?

From the pihole you could run pihole -q -exact click.redditmail.com and post result. This would show all instances of click.redditmail.com in the lists.

Sharing that nslookup along with the corresponding log lines as requested would help to find that.

# pihole -q -exact click.redditmail.com
 Exact match found in exact whitelist
   click.redditmail.com
 Exact matches for click.redditmail.com found in:
  - https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
  - https://v.firebog.net/hosts/Easyprivacy.txt
  - https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=0&mimetype=plaintext
  - https://hostfiles.frogeye.fr/firstparty-trackers-hosts.txt

I remember now. When I tried to get the logs before it flooded my CLI, and I forgot about it.

Literally nothing in today's logs either:

# nslookup click.redditmail.com 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

Name:   click.redditmail.com
Address: 0.0.0.0
Name:   click.redditmail.com
Address: ::

# nslookup click.redditmail.com 10.1.0.1
Server:         10.1.0.1
Address:        10.1.0.1#53

Name:   click.redditmail.com
Address: 0.0.0.0
Name:   click.redditmail.com
Address: ::

# nslookup click.redditmail.com         
Server:         172.17.0.10
Address:        172.17.0.10#53

Name:   click.redditmail.com
Address: 0.0.0.0
Name:   click.redditmail.com
Address: ::

# cat /var/log/pihole/pihole.log | grep click.redditmail.com
# 

Strange that it uses 172.17.0.10 rather than 10.1.0.6 for its internal IP though, but it's not got "Host Network" enabled.

Last time I had it checked, I couldn't access the UI and the port wasn't freed up until I restarted my TrueNAS. But that might've been the TrueCharts version, not the TrueNAS version of the image.

If that request for click.redditmail.com really did not show up in Pi-hole's log, that would indicate that those DNS requests never made it to Pi-hole.

However, I wonder where you actually did run that cat /var/log/pihole/pihole.log?

You've stated:

Did you run that statement from inside the container?

Correct. I logged into the container's shell and did it from there.

I think I may have figured it out:

I found this when searching if IDS/IPS was turned on in UniFi.

Looks like they have their own Pi-Hole style blocking?

image

image

I'll try disabling that and see if it fixes my issue. I would 100% assume this is the problem since nothing else makes sense.

They have probably altered all UDP 53 traffic which is why DNSSEC doesn't have the issue; at least, that's what it says.

I had DNSSEC enabled in Pi-Hole though. It broke when trying to get local DNS names from the UniFi router, so I disabled it. Still, that's only recently. It was DNSSEC when I was having issues before.

If UniFi is blocking that stuff, that seems pretty intrusive. It's not just ads but trackers too?

And the DNS Shield part is just using Cloudflare security. What's that?

I turned off both and now it works:

$ nslookup click.redditmail.com
Server:  UnKnown
Address:  192.168.6.1

Non-authoritative answer:
Name:    thirdparty.bnc.lt
Address:  18.144.119.190
Aliases:  click.redditmail.com

Ah. Once I disable DNS Shield and bring it back up, this makes a LOT more sense:
image

After enabling only one or the other, I found that the issue was the Ad Blocking setting. I went ahead and disabled it.

It's crazy they developed their own Pi-Hole. Not only did I have it turned on, but I had no clue. I must've clicked it one day and forgotten about it.

Looking through the logs, I can't even tell when I enabled it.

Yep, I can confirm from the Unifi community forums that using Ad Blocking in Unifi causes it to redirect all DNS requests to another service for blocking/filtering, and it ignores whatever manual DNS settings you have configured.

Otherwise, I don't think their blocking would work at all. That's why they have the information text "The DNS servers configured on the WAN will no longer be used." They are using lists from cleanbrowsing.org, and implemented the feature set over a year ago. It works well from what I've seen reported, but there's currently no visibility into the list contents.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.