Please explain: Difference in blocking IPv4 and IPv6?

I'm using two forwarders in my pihole configuration:

server=127.10.10.2#5552
server=fdaa:bbcc:ddee:2::5552#5552

All the queries for this domain have been forwarded to the same unbound resolver (fdaa:bbcc:ddee:2::5552#5552 - see screenshot below), in fact, of all the queries performed since the restart this morning, 56.2% have been answered by the IPv6 resolver, 6.6% cached and 36.9% blocklist. Currently, pihole doesn't like the IPv4 (127.10.10.2#5552) resolver very much (slower).

Not related to this issue but you don't need to use IPv6 over a local connection to the same host. Just use the 127 address. You're over complicating a lot of things.

Didn't watch it since the patch. Never saw different results of same query.
Only saw difference between A and AAAA.

And clicking on blocked cname gives no matches.

1 Like

Thanks, so your questions have been answered?

DL6ER did release an update for the branch new/CNAME_inspection_details this morning, run pihole -up and don't forget to clear the browser cache. Since the update, clicking on the domain in the query log shows the relevant queries.

in the query log:


click on the domain:

I would really appreciate if you also list your configuration, and use my method to identify a recent occurrence of the problem we have been seeing. If NOT, I'm afraid the bug report will be closed without further investigation (independent source).

Was on v5.0 Beta, now on

pihole checkout ftl new/CNAME_inspection_details
pihole checkout web new/CNAME_inspection_details

  Pi-hole version is v4.3.2-391-ge0b3405 (Latest: v4.3.2)
  AdminLTE version is v4.3.2-363-g90a09d1c (Latest: v4.3.2)
  FTL version is vDev-122a701 (Latest: v4.3.1)

Resolver configuration? unbound or other?

Please run the sql script and evaluate the results in the csv, really easy, doesn't take up to much of your time.

Unbound 1.9.4-2+b1

Can't use LTD (lighttpd issue). Can use Query Log - Show all

apt-get update on the client gives expected results.

msn.com in browser gives one query (A) OK. I whitelisted msn.com. Next domain in chain is blocked.
When I remove msn.com from the whitelist it is Blocked (gravity, CNAME)

15 posts were split to a new topic: Inconsistend CNAME blocking?

Mine are. Don't know about @jpgpi250.
Can I go back to release/v5.0?
Will the patch be merged before release? I know I will loose the patch in the meantime.

Yes, this will all go in to the release. I don't know if the branches are compatible yet for going back to beta5.0 branch but if you give us a few hours to review and merge that branch in then you should be able to return to beta5.0 branch. Once Improvements to deep CNAME inspection data processing by DL6ER · Pull Request #685 · pi-hole/FTL · GitHub shows a purple Merged flair then you should be good to go.

Thanks, I will see when it's merged.
Now going back to release/v5.0 to rule out if this patch is the cause of a Fatal PHP error in Long term data.

There is no PHP error release/v5.0.
Is it correct to apply your patch by checking out core/web/ftl of your patch?

Please open a new topic for any PHP errors. This topic/thread is resolved.

List any steps you have taken and what errors you are seeing.

Sure but I think your patch for this topic is the cause of the PHP error.

Thanks, 94 posts in a topic is too many. We need to keep things on topic and short to review.

Can't reproduce PHP error. Forget about it. Thanks for your help in this topic.

Check.

1 Like

Just updated - looking and working fine so far. One small thing happened, don't know if it had something to do with ne new code:

The lighttpd error log was flooded extremely with

unexpected "=" in pihole-FTL.conf line 4

and a relating PHP error. The reason for this was that the pihole-FTL.conf must be rewritten during the update process and looked like this:

BLOCKINGMODE=NULL
MAXDBDAYS=30
RESOLVE_IPV6=yes
RESOLVE_IPV4=yesPRIVACYLEVEL=0

The web interface did its work anyway. I added the missing linefeed, stopped lighttpd, deleted its large error log, restartet it and no error occured so far.