Default blocking behavior makes Chrome slow

[philwo]

Versions

• Pi-hole: Pi-hole version is v5.2.4 (Latest: v5.2.4)
• AdminLTE: AdminLTE version is v5.4 (Latest: v5.4)
• FTL: FTL version is v5.7 (Latest: v5.7)

Platform

• OS and version: Debian 10

• Platform: Raspberry Pi

Expected behavior

Pi-hole should consider switching its default blocking behavior to NODATA instead of the current NULL behavior, if you think this is a net win for performance.

The reason is that Chrome and/or macOS Big Sur (see below Reddit link) have an issue where connections to 0.0.0.0 don't fail immediately, but run into timeouts, causing Chrome to become extremely sluggish and other weird issues (video conferences start to lag and desync, typing into input fields has a noticeable one second lag, ...).

Chrome is looking into improving things on their end (see below linked Chromium issue report) and I have personally configured my Pi-hole to use NODATA now, but I figured maybe this is a good time to switch to the NODATA strategy by default to help the users who don't know how to fix their "slow Chrome browser when using Pi-hole" (it took me weeks to figure out the connection between a sluggish but otherwise fine browser and Pi-hole). 😊

I'm copying some additional thoughts from a Chromium engineer here from the issue linked below: "My suggestion for ideal blocking strategy would be NODATA with a TTL provided via SOA record in the Authority section and a relevant EDE (see RFC 8914). Creates a cacheable response while being mostly honest with the client about the situation rather than completely forging false results (REFUSED would be more honest than NODATA but it's not cacheable and it sounds like they're sensitive to that). But the caveat to my suggestion is that I'm biased due to knowing that Chrome can handle and cache such a response, but maybe the pi-hole peeps have experience with DNS clients that handle things poorly."

Actual behavior / bug

Pi-hole currently uses the NULL strategy to block domains via DNS, which causes issues with Chrome.

Steps to reproduce

Steps to reproduce the behavior:

1. Install Pi-hole with default settings.
2. Use Chrome to join a video conference.
3. Notice massive lags as soon during the call, especially when performing any action in other tabs (e.g. browsing to a new site or refreshing one).

Debug Token

• URL: https://tricorder.pi-hole.net/jgmk783hdp

Additional context

Other user reports:

• https://bugs.chromium.org/p/chromium/issues/detail?id=1194888
• https://www.reddit.com/r/MacOS/comments/jthm1q/pihole_and_macos_big_sur/

[dschaper]

Just off the cuff it sounds like Chrome is broken then. I do see that you have IPv6 configured and that often causes a number of issues with DNS resolution.

I haven't seen this slowdown. @jfb-pihole Do you see any of this on mac?

Discussion about changing is fine but this isn't a bug and that discussion should happen on https://discourse.pi-hole.net

[philwo]

@dschaper According to that Reddit thread, it seems to affect a few people using Firefox, too. (Personally, I could only reproduce it reliably with Chrome, though.)

I was also able to repro the issue when deactivating IPv6 on my Mac.

I'm happy to raise that discussion on Discourse instead: https://discourse.pi-hole.net/t/consider-making-nodata-the-default-blocking-strategy/46080

[jfb-pihole]

I have not seen this on my MacBook Air running Chrome on Big Sur latest. My Pi-hole blocking mode is NULL.

This isn't a Pi-hole problem. We should not change the default blocking mode in response to badly behaved apps on specific OS platforms. Happy to continue the conversation on a discourse post.

[chloverdose]

Possible change: Make it a toggle in settings with the text "if you experience slowdowns in some apps, turn this on/off".
Default is still NULL, but at least there's an easy switch.

[dschaper]

Because of the number of requests and the very limited resources we have as a free open-source project run by volunteers, we ask that you open all Feature Requests at our Discourse Forum.

Thank you for your understanding.

[pralor-bot]

This issue has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/pi-hole-slow-dns-queries-when-browsing/48151/3