failed to send TCP(read_write) packet (Connection prematurely closed by remote server)

[seh2000]

Hi,
My first try to report an issue here.
I am having a couple of Raspberry Pi running Pi-hole and is using Unbound as a recursive DNS server.

I and others have seen this message WARNING Connection error (127.0.0.1#5335): failed to send TCP(read_write) packet (Connection prematurely closed by remote server) in the Pi-holes FTL.log, but often just disregarded this.
However, a few weeks ago I started a discussion around this at Pi-holes Beta 6 forum. Which lead to a deeper investigation by the people behind Pi-hole and my self (let me just say that I am not a software/developer person).

Yesterday one of the developer concluded this must most likely be an Unbound bug, here the link to the message https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/44?u=seh2000.

Unfortunately the log files especial the unbound.log are rather large, however in the link above there are extracts from different log files.

Kind regards - Steen

System:

• Unbound version: 1.17.1

• OS:
  Distributor ID: Debian
  Description: Debian GNU/Linux 12 (bookworm)
  Release: 12
  Codename: bookworm
  Kernel: Linux 6.6.74+rpt-rpi-v8
  Architecture: arm64

• HW: Raspberry Pi 4 Model B Rev 1.5

• unbound -V output:
  Version 1.17.1
  Configure line: --build=aarch64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/aarch64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-pythonmodule --with-pyunbound --enable-subnet --enable-dnstap --enable-systemd --with-libnghttp2 --with-chroot-dir= --with-dnstap-socket-path=/run/dnstap.sock --disable-rpath --with-pidfile=/run/unbound.pid --with-libevent --enable-tfo-client --with-rootkey-file=/usr/share/dns/root.key --disable-flto --enable-tfo-server
  Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.15 3 Sep 2024
  Linked modules: dns64 python subnetcache respip validator iterator
  TCP Fastopen feature available
  BSD licensed, see LICENSE in source package for details.
  Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues

• unbound conf:
  admin@Pi4-1:~ $ sudo grep -v '#|^$' -R /etc/unbound/unbound.conf*
  /etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
  /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
  /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf: auto-trust-anchor-file: "/var/lib/unbound/root.key"
  /etc/unbound/unbound.conf.d/remote-control.conf:remote-control:
  /etc/unbound/unbound.conf.d/remote-control.conf: control-enable: yes
  /etc/unbound/unbound.conf.d/remote-control.conf: control-interface: /run/unbound.ctl
  /etc/unbound/unbound.conf.d/pi-hole.conf:server:
  /etc/unbound/unbound.conf.d/pi-hole.conf: logfile: "/var/log/unbound/unbound.log"
  /etc/unbound/unbound.conf.d/pi-hole.conf: log-time-ascii: yes
  /etc/unbound/unbound.conf.d/pi-hole.conf: log-queries: yes
  /etc/unbound/unbound.conf.d/pi-hole.conf: log-replies: yes
  /etc/unbound/unbound.conf.d/pi-hole.conf: verbosity: 5
  /etc/unbound/unbound.conf.d/pi-hole.conf: interface: 127.0.0.1
  /etc/unbound/unbound.conf.d/pi-hole.conf: port: 5335
  /etc/unbound/unbound.conf.d/pi-hole.conf: do-ip4: yes
  /etc/unbound/unbound.conf.d/pi-hole.conf: do-udp: yes
  /etc/unbound/unbound.conf.d/pi-hole.conf: do-tcp: yes
  /etc/unbound/unbound.conf.d/pi-hole.conf: do-ip6: no
  /etc/unbound/unbound.conf.d/pi-hole.conf: prefer-ip6: no
  /etc/unbound/unbound.conf.d/pi-hole.conf: harden-glue: yes
  /etc/unbound/unbound.conf.d/pi-hole.conf: harden-dnssec-stripped: yes
  /etc/unbound/unbound.conf.d/pi-hole.conf: use-caps-for-id: no
  /etc/unbound/unbound.conf.d/pi-hole.conf: edns-buffer-size: 1232
  /etc/unbound/unbound.conf.d/pi-hole.conf: prefetch: yes
  /etc/unbound/unbound.conf.d/pi-hole.conf: num-threads: 1
  /etc/unbound/unbound.conf.d/pi-hole.conf: so-rcvbuf: 1m
  /etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 192.168.0.0/16
  /etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 169.254.0.0/16
  /etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 172.16.0.0/12
  /etc/unbound/unbound.conf.d/pi-hole.conf: private-address: 10.0.0.0/8
  /etc/unbound/unbound.conf.d/pi-hole.conf: private-address: fd00::/8
  /etc/unbound/unbound.conf.d/pi-hole.conf: private-address: fe80::/10

Additional information

[gthess]

Hi, this seems to be TCP related.
I don't have the complete log to see what is happening but my initial thoughts is why does Unbound get TCP queries in the first place? If that is an environment configuration and everything comes as a TCP query in you would need to bump the incoming-number-tcp option. Unbound will aggressively try to free resources if TCP usage reaches its limits (by closing idle connections) in an attempt to favor cache answer while resolution keeps going in the background.

If this is not the environment's configuration (everything over TCP), maybe only select queries are strictly over TCP, like the one from opera I see in the forum? But then the amount of said TCP traffic still pushes Unbound near its configured limits?

"Regular" TCP traffic for Unbound (at least for your configuration where I don't see TLS used) would be UDP queries that are retried over TCP because the answer would not fit in the UDP buffer. These would get an immediate cache response because Unbound would already have the data in the cache (it concluded that the answer would not fit in UDP already).

Actually I am pretty sure this is what is happening by looking at the log fragments from the forum:

debug: comm point start listening 12 (200 msec)

200 msec is the minimum amount of time Unbound will use under pressure. The default (starting) value is 30 secs.

So I would bump incoming-number-tcp and see how it goes.
Btw you can monitor tcp usage with something like:

while true; do date; unbound-control stats | grep total.tcpusage; sleep 1; done

Also, I see that this is mostly dnsmasq talking to Unbound?
Maybe dnsmasq can be configured to send multiple queries over a single TCP connection?

[seh2000]

Hi @gthess,
Many thanks for replying to my post.
Now, let me first say that I am just a normal user with limited Linux knowledge. Never-the-less I'll try to do my best to provide answers and additional information.

I can provide full logs - I am not too sure how to share as the unbound log is 215,400 KB and the FTL log from Pi-hole is like 69,021 KB. I could use a shared cloud location. Is there an address whereto I could send the password?

From the Pi-hole forum, which perhaps could throw more light on the the issue:
Okay, we got something now:
pihole.log:
Feb 7 13:14:46 dnsmasq[3013]: query[A] sync.opera.com from 192.168.1.40
Feb 7 13:14:46 dnsmasq[3013]: cached-stale sync.opera.com is
Feb 7 13:14:46 dnsmasq[3014]: query[HTTPS] sync.opera.com from 192.168.1.40
Feb 7 13:14:46 dnsmasq[3013]: cached-stale nl.sync.opera.com is 185.26.182.111
Feb 7 13:14:46 dnsmasq[3014]: cached-stale sync.opera.com is
Feb 7 13:14:46 dnsmasq[3013]: cached-stale nl.sync.opera.com is 185.26.182.112
Feb 7 13:14:46 dnsmasq[3014]: cached nl.sync.opera.com is NODATA
Feb 7 13:14:47 dnsmasq[3014]: forwarded sync.opera.com to 127.0.0.1#5335
Feb 7 13:14:47 dnsmasq[3014]: dnssec-query[DS] opera.com to 127.0.0.1#5335
Feb 7 13:14:47 dnsmasq[3014]: reply opera.com is no DS
Feb 7 13:14:47 dnsmasq[3014]: validation result is INSECURE
Feb 7 13:14:47 dnsmasq[3014]: reply sync.opera.com is
Feb 7 13:14:47 dnsmasq[3014]: reply sync.geo.opera.com is
Feb 7 13:14:47 dnsmasq[3014]: reply nl.sync.opera.com is NODATA
Feb 7 13:14:47 dnsmasq[3013]: Failed at receiving length, data_sent: true
Feb 7 13:14:47 dnsmasq[3013]: failed to send TCP(read_write) packet: Connection prematurely closed by remote server

and, indeed unbound never sent the reply to the A query downstream:
unbound.log
Feb 07 13:14:46 unbound[1989:0] info: 127.0.0.1 sync.opera.com. HTTPS IN
...
Feb 07 13:14:46 unbound[1989:0] info: 127.0.0.1 sync.opera.com. A IN
...
Feb 07 13:14:47 unbound[1989:0] info: subnetcache operate: query sync.opera.com. HTTPS IN
Feb 07 13:14:47 unbound[1989:0] debug: reply has edns subnet (null)
Feb 07 13:14:47 unbound[1989:0] debug: mesh_run: subnetcache module exit state is module_finished
Feb 07 13:14:47 unbound[1989:0] debug: comm point stop listening 12
Feb 07 13:14:47 unbound[1989:0] debug: comm point start listening 12 (200 msec)
Feb 07 13:14:47 unbound[1989:0] debug: startlistening 12 mode w
Feb 07 13:14:47 unbound[1989:0] debug: query took 0.165177 sec
Feb 07 13:14:47 unbound[1989:0] info: 127.0.0.1 sync.opera.com. HTTPS IN NOERROR 0.165177 0 135
Feb 07 13:14:47 unbound[1989:0] info: mesh_run: end 1 recursion states (1 with reply, 0 detached), 1 waiting replies, 1240 recursion replies sent, 0 replies dropped, 0 states jostled out
...
Feb 07 13:14:47 unbound[1989:0] info: subnetcache operate: query sync.opera.com. A IN
Feb 07 13:14:47 unbound[1989:0] debug: reply has edns subnet (null)
Feb 07 13:14:47 unbound[1989:0] debug: mesh_run: subnetcache module exit state is module_finished
Feb 07 13:14:47 unbound[1989:0] info: mesh_run: end 0 recursion states (0 with reply, 0 detached), 0 waiting replies, 1241 recursion replies sent, 0 replies dropped, 0 states jostled out

just before the last four lines, we see that the cache is populated with
Feb 07 13:14:47 unbound[1989:0] info: chased extract ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
;; flags: qr ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
sync.opera.com. IN A

;; ANSWER SECTION:
sync.opera.com. 60 IN CNAME sync.geo.opera.com.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
;; MSG SIZE rcvd: 55

Feb 07 13:14:47 unbound[1989:0] info: chased extract ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
;; flags: qr ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
sync.geo.opera.com. IN A

;; ANSWER SECTION:
sync.geo.opera.com. 120 IN CNAME nl.sync.opera.com.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
;; MSG SIZE rcvd: 58

Feb 07 13:14:47 unbound[1989:0] info: chased extract ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
;; flags: qr ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
nl.sync.opera.com. IN A

;; ANSWER SECTION:
nl.sync.opera.com. 60 IN A 185.26.182.112
nl.sync.opera.com. 60 IN A 185.26.182.111

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
;; MSG SIZE rcvd: 67

so unbound indeed has the necessary data to respond to your query.
This brings me to the final conclusion that is really an unbound bug. Despite being asked to resolve query sync.opera.com. A IN and having performed all the necessary steps and recursions, it falsely concludes the chain with "0 waiting replies", and, hence, does not think it has to reply.

For your question on "why does Unbound get TCP queries in the first place" I presume this is how the solution is put together. I'll post your question to the Pi-hole developers.

Likewise for your two last questions:
"Also, I see that this is mostly dnsmasq talking to Unbound?"
"Maybe dnsmasq can be configured to send multiple queries over a single TCP connection?"

I'll post your questions to the Pi-hole developers.

Regards - Steen

[gthess]

For now the logs are not necessary as I got a glimpse from the forum and I do believe it is the tcp usage that makes Unbound drop connections.

You can go ahead and configure Unbound with:

server:
    ...
    incoming-number-tcp: 100
    ...

100 is a bit excessive (and it will need more memory), but at least you can try and see if the problem keeps occurring or not.
(You can also bring verbosity's value back to what it was while you are at it since all this logging to file will make everything slower.)
You can monitor Unbound's tcp usage by running:

while true; do date; unbound-control stats | grep total.tcpusage; sleep 1; done

Then if the problem goes away, the monitoring script should tell you the maximum of incoming tcp connections in your environment.

[seh2000]

Hi,
Due to my lack of Unbound configuring options I could first not get it to work, but then I had a search and found it should be "incoming-num-tcp: 100" instead of "incoming-number-tcp: 100". :)

Reloaded and Restarted Unbound, but when running "while true; do date; unbound-control stats | grep total.tcpusage; sleep 1; done"
I get the below error:
Mon 10 Feb 18:55:53 GMT 2025
[1739213753] unbound-control[15146:0] error: connect: Permission denied for /run/unbound.ctl
Mon 10 Feb 18:55:54 GMT 2025
[1739213754] unbound-control[15150:0] error: connect: Permission denied for /run/unbound.ctl
Mon 10 Feb 18:55:55 GMT 2025
[1739213755] unbound-control[15158:0] error: connect: Permission denied for /run/unbound.ctl
Mon 10 Feb 18:55:53 GMT 2025
[1739213753] unbound-control[15146:0] error: connect: Permission denied for /run/unbound.ctl

Any help appreciated.
Steen

[gthess]

Sorry for the typo! (Which seemed to happened all over the issue 🤦 )

You are correct, incoming-num-tcp is the correct option.

I would assume that Unbound runs as the unbound user so you should run the unbound-control command as unbound as well. Maybe try:

while true; do date; sudo -u unbound unbound-control stats | grep total.tcpusage; sleep 1; done

The "script" runs in a loop and prints the date and the tcp usage from Unbound.
Ctrl-c (you may need to hit it several times) will terminate it.
If you want to also write to a file you can use:

while true; do date; sudo -u unbound unbound-control stats | grep total.tcpusage; sleep 1; done | tee -a tcp-usage.log

the script's output will be on the terminal and also written to the 'tcp-usage.log' file. I used -a which will append to the file if already there.

[seh2000]

Hi,
No worries about the typo got me to read about the unbound config. :)
while true; do date; sudo -u unbound unbound-control stats | grep total.tcpusage; sleep 1; done worked, thanks!
admin@Pi4-1:/var/log/unbound $ while true; do date; sudo -u unbound unbound-control stats | grep total.tcpusage; sleep 1; done
Mon 10 Feb 21:31:42 GMT 2025
total.tcpusage=0
Mon 10 Feb 21:31:43 GMT 2025
total.tcpusage=0
Mon 10 Feb 21:31:44 GMT 2025
total.tcpusage=0

So far no error...will continue...

[seh2000]

Hi,
Had no errors with the setting incoming-num-tcp: 100.
When I lowered to incoming-num-tcp: 20 I had a few errors, but with a long time between them.
With an increase to 30 and 40 nothing, will go back to 20.

[gthess]

Good to hear, so it seems it is related to the incoming tcp buffers. Maybe the LAN instance gets more clients, or has a slower connection to the outside, or both?
Did you get any useful numbers from the tcpusage script?

[seh2000]

Hi, I wish that would be the case. The LAN got 6 devices and the dl/ul bandwidth are stable (monitored) 24*7. No useful from the script as all tcpusage shows 0.

[gthess]

That's unfortunate, tcpusage is a value in time that probably with the 1 second granularity and the low number of clients(incoming queries) does not reveal the TCP spikes that could happen.
You can try the following oneliner that aggressively asks for stats and prints only the maximum for the duration of the script:

max=0; while true; do current=`sudo -u unbound unbound-control stats | grep total.tcpusage | cut -d '=' -f 2`; if test $current -gt $max; then max=$current; date; echo $max; fi; done

[seh2000]

Hi,
Will try the new stats.
Another Pi-hole user have seen similar issue, I have asked him to post here.

[seh2000]

Hi,
Not sure how much the tcp usage tell, because:

2025-02-14 19:46:16.039 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 19:46:16.046 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 19:46:58.763 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 19:46:58.763 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 19:46:58.978 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 19:58:16.490 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 19:58:16.490 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 19:59:35.239 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:00:02.810 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:00:02.810 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:03:50.439 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:03:50.439 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:04:29.943 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:07:31.310 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:07:31.319 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:07:35.631 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:09:44.463 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:09:44.467 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:10:02.483 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:14:23.870 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:14:23.970 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:17:30.742 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:21:11.202 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-14 20:21:11.210 WARNING Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)

Fri 14 Feb 19:59:35 GMT 2025
2
Fri 14 Feb 20:00:02 GMT 2025
4
Fri 14 Feb 20:02:15 GMT 2025
6

This I got with incoming-num-tcp set to 10

[bennor675]

Another user running Unbound who is facing this same "WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)" error in Pi-Hole v6.

System Details:
Headless Raspberry Pi 3B+
OS: 11 (bullseye)
Unbound
Version: 1.13.1
Pi-Hole: Core v6.0.3FTL v6.0.2Web interface v6.0.1

Pi-Hole was updated from v5 to v6 several days ago. Ever since then been receiving a Pi-Hole Diagnosis Error from time to time indicting (for example) the following:

2025-02-22 17:05:21	CONNECTION_ERROR	Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)

Like others with this issue since moving to Pi-Hole v6, have been experimenting with the incoming-num-tcp: (number) value in the /etc/unbound/unbound.conf.d/pi-hole.conf file. Restarting Unbound each time the incoming-num-tcp value is changed. Have tried the following values, one at at time: 10, 40, 50, 100. Each time a connection error message eventually shows up in the Pi-Hole Diagnostic Error section. Data from the Pi-Hole FLT.log file:

2025-02-21 05:59:55.182 EST [25823/F24244] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-21 06:07:11.535 EST [25926/F24244] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-21 06:08:28.462 EST [25951/F24244] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-21 10:18:05.747 EST [28023/F24244] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-21 10:19:35.564 EST [28041/F24244] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-21 10:23:38.939 EST [28119/F24244] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-21 10:27:13.462 EST [28179/F24244] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-21 11:19:47.784 EST [28923/F24244] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-21 11:21:06.204 EST [28942/F24244] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-21 11:23:59.455 EST [28973/F24244] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-21 11:29:06.254 EST [29061/F24244] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-21 12:05:17.529 EST [978/F561] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-21 16:47:24.753 EST [3721/F560] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-21 17:06:02.193 EST [4043/F560] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-21 17:56:21.061 EST [1250/F562] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-22 05:38:23.863 EST [759/F562] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-22 06:17:59.543 EST [1418/F562] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-22 06:33:16.663 EST [1741/F562] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-22 06:35:29.143 EST [1767/F562] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-22 06:38:48.183 EST [1813/F562] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-22 07:19:03.543 EST [2307/F562] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2025-02-22 16:00:05.952 EST [6759/F562] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
2025-02-22 17:05:21.143 EST [8099/F562] WARNING: Connection error (127.0.0.1#5335): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)

Are there any additional suggestions to try or troubleshooting steps to take?
Do not recall seeing these errors either in the Pi-Hole Diagnostic section or in the FTL.log file under Pi-Hole v5. The Pi-Hole forum seems to feel this is an Unbound issue and not a Pi-Hole issue.