Hi evereyone,
Please ensure that you are running the latest version of the beta code.
Pi-hole version is v4.3.2-391-ge0b3405 (Latest: v4.3.2)
AdminLTE version is v4.3.2-360-g88da85f5 (Latest: v4.3.2)
FTL version is vDev-9889501 (Latest: v4.3.1)
Problem with Beta 5.0:
Can someone please explain what happens here? Is there a difference in blocking A and AAAA requests? That's the only difference I can see now.
@jpgpi250 even if your response is off-topic here, I can't explain the difference but I guess you both are on the same commit.
I understand your eagerness to be on the absolute bleeding edge but please do not derail topics. It's hard enough to answer all the support questions without having to weed through what is part of the question and what is extra noise.
Please provide a debug token with pihole -d and we will take a look.
Debug Token
https://tricorder.pi-hole.net/er1tgbdom0
Is this topic (Some domains are intermittently blocked even though they are on the whitelist) related?
Hmm, yes, maybe. Could you add the debugging options I put in there as well and check what the FTL log says for you when this happens again?
@DL6ER
Done.
What to look for in /var/log/pihole-FTL.log ?
Still got the same situation as in the screenshot. To reproduce I did an apt-get update on the client hitting the Brave repository.
Debug Token
https://tricorder.pi-hole.net/59vdqa1s9h
When I put the CNAME domain (u2.shared.global.fastly.net) on the whitelist there is a different result. Did that at 14:16:43.
Edit: Removing CNAME from withelist again gives result as screenshot in first post.
@Arno We collected enough details in the other thread you referenced above to believe that it is really the same cause. It is a caching issue inside FTL where special whitelisting rules were not applied as they were meant to be. I proposed a fix which you could try with
pihole checkout ftl fix/deeply_whitelisted_domain
Any testing would be highly appreciated.
@DL6ER
What I did:
On the latest version
pihole checkout ftl fix/deeply_whitelisted_domain
pihole restartdns
On client: sudo apt-get update
Result:
brave-browser-apt-release.s3.brave.com does not show up in Query log or pihole-FTL.log and isn't resolved on the client,
Are you sure the client is still using the Pi-hole as DNS server? Queries not appearing in the log should not be possible in any way.
Yes it does but now I also did sudo systemd-resolve --flush-caches on the client. Now it shows up in Query Log.
pihole -q brave-browser-apt-release.s3.brave.com
[i] No results found for brave-browser-apt-release.s3.brave.com within the block lists
u2.shared.global.fastly.net is still blocked.
Is it the same issue as mine? From this
[i] No results found for brave-browser-apt-release.s3.brave.com within the block lists
it looks like you haven't whitelisted brave-browser-apt-release.s3.brave.com. Is the issue here that the AAAA request is allowed (i.e. are both requests supposed to be blocked)?
Correct. For me the expected result now is the above domain is not blocked (see pihole -q).
What I don't understand is the difference for IPv4/IPv6.
That I blocked the CNAME domain is out of scope of this topic.
I still block it to keep my test the same as when I started the topic.
Well if you blocked the CNAME domain, then brave-browser-apt-release.s3.brave.com should be blocked as well due to deep CNAME inspection unless you whitelist it specifically, no?
But yes, the difference between IPv4/IPv6 confuses me too (and I know that's the bug you're addressing), but I was confused on whether the intended behavior was that both the IPv4/IPv6 were supposed to be allowed or blocked. Unless I'm mistaken, if you blocked the CNAME domain then they should both be blocked, and the IPv6 request is incorrectly allowed?
If that's the case I was thinking it's actually sort of the opposite of my issue where a domain is erroneously allowed.
The IPv4 request is incorectly blocked imo.
Expected result for me with my configuration:
brave-browser-apt-release.s3.brave.com IPv4 and IPv6 allowed. (because it is not on any list)
u2.shared.global.fastly.net (next in chain) IPv4 and IPv6 blocked (as expected because it is blocked by regex. Fix, by design, is to whitelist domain)
FTL does not really differentiate between A and AAAA requests. Do you see the same results even if you request them in reversed order?
Please go back onto the release/v5.0 branch before you test this as my fix was merged:
pihole checkout ftl release/v5.0
pihole checkout ftl release/v5.0
...
Have you read and understood this? [y/N] y
[✓] Branch release/v5.0 exists
[✓] Downloading and Installing FTL
[✓] Restarting pihole-FTL service...
[✓] Enabling pihole-FTL service to start on reboot...
pihole version
Pi-hole version is v4.3.2-391-ge0b3405 (Latest: v4.3.2)
AdminLTE version is v4.3.2-360-g88da85f5 (Latest: v4.3.2)
FTL version is vDev-9a5a941 (Latest: v4.3.1)
How do I request them in reverse order? Is dig -6/dig -4 a good test?.
Before I did apt-get update on the client.
It should be
dig AAAA whatever.com
dig A whatever.com