So not strictly a pihole problem, but I'm hoping that there's a workaround.
I subscribe to a dns service (StrongDNS)and the most recent version of dig (9.18+) times out when trying to contact it. This is a problem because when I add the server to pihole as the upstream DNS server, it also times out. I've been using this configuration for many years, so I know it works, but the combination of v6 and various linux updates broke something.
After much searching, I found this article that suggests increasing the maximum UDP size by using +bufsize=4096
Here it is without:
user@pihole:/etc/dnsmasq.d$ dig @209.107.219.5 +short -t txt versions.pi-hole.net
;; communications error to 209.107.219.5#53: timed out
;; communications error to 209.107.219.5#53: timed out
;; communications error to 209.107.219.5#53: timed out
When I have it configured using this upstream DNS, I obviously lose connectivity so I can't upload by debug log. However, I'll paste the beginning of it here to show the error:
*** [ INITIALIZING ]
[i] 2025-04-07:20:04:01 debug log has been initialized.
[i] System has been running for 0 days, 2 hours, 27 minutes
*** [ DIAGNOSING ]: Core version
[✓] Version: v6.0.6
[i] Remotes: origin https://github.com/pi-hole/pi-hole.git (fetch)
origin https://github.com/pi-hole/pi-hole.git (push)
[i] Branch: master
[i] Commit: v6.0.6-0-g0f7803b
*** [ DIAGNOSING ]: Web version
[✓] Version: v6.1
[i] Remotes: origin https://github.com/pi-hole/AdminLTE.git (fetch)
origin https://github.com/pi-hole/AdminLTE.git (push)
[i] Branch: master
[i] Commit: v6.1-0-g1eaddca
*** [ DIAGNOSING ]: FTL version
[✓] Version: v6.1
[i] Branch: master
[i] Commit: a3313229
*** [ DIAGNOSING ]: Operating system
[i] Distro: Ubuntu
[i] Version: 20.04
[✗] dig IPv4 return code: 1
[✗] dig response: dig: couldn't get address for 'ns1.pi-hole.net': failure
[i] Retrying via IPv6
[✗] dig IPv6 return code: 1
[✗] dig response: dig: can't find IPv6 networking
[✗] Error: dig command failed - Unable to check OS
Pi-hole would use ns1.pi-hole-net for retrieving its supported OS versions, which isn't 209.107.219.5.
I fail to see how UDP buffer size could actually be involved in this, as retrieving the versions involves DNS replies of under 400 bytes, which is well below the 1232 byte limit.
You'll see MSG SIZE as part of dig output if you omit +short.
You should also be aware that pihole-FTL/dnsmasq has been using edns-packet-max=1232 by default since Pi-hole FTL v5.22 released, i.e. as early as March 2023.
You should consider to approach StrongDNS support with your observation - it's a paid service, after all.
I believe that pihole is trying to make a TCP connection instead of a UDP connection, and my understanding is that it only does that if the packet size is too big.
I have reached out to StrongDNS support but haven't heard back.
That's a StrongDNS IPv4 again, I presume?
That DNS server (or something en route) is actively refusing TCP connections.
From your description, it doesn't sound as if this was only a temporary issue.
Just to be sure, you wouldn't run a firewall that blocks outbound port 53/TCP connections?
If StrongDNS would generally refuse to accept TCP traffic, it would not comply with DNS standards, specifically with RFC 7766:
(…) support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation.
It is not a temporary issue. It has come up since pihole V6, coinciding with dig 9.18.
I am not behind a firewall blocking 53/TCP connections.
Again, I've raised a support ticket w StrongDNS, and I'm waiting to hear back.
My question is what has changed between v5 and v6 so that pihole can't use this server as an upstream DNS? Does pihole do a verification of the upstream DNS using dig before it starts passing queries?