Error in diagnostic since v6 with pfsense as upstream

Hello,

I have a pfsense router that is used as my upstream dns on my piholes. I still work but the log are now spammed with that message (and also seen in diagnostic).

Connection error (x.x.x.x#853 ): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server )

I'm unsure how to fix that.

Thank you!

As Pi-hole only uses Do53, usage of port 853 would indicate that message isn't from pihole.log?

What's the DNS server on your pfsense that is receiving inbound DNS from Pi-ole?

my upstream DNS is connected to port 853 in upstream DNS setting (x.x.x.x:853).

pfsense use ubound and work both on 53 and 853 for dns over tls. didn't had that message on v5. I don't see any message on pfsense side

edit: I did just found out that unbound seems to restart quite frequently, which wasn't the case before. That might be the issue

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or if you run your Pi-hole as a Docker container:

docker exec -it <pihole-container-name-or-id> pihole -d

where you substitute <pihole-container-name-or-id> as required.

https://tricorder.pi-hole.net/4L3VTscz/

So you've configured Pi-hole to use your router as its upstream:

   [dns]
     upstreams = [
       "192.168.0.1#853"
     ] ### CHANGED, default = []

As I understand it, unbound is listening on port 853 on your router.

Pi-hole only talks plain DNS/Do53, i.e. it does not encrypt its DNS requests. Configuring it to use an upstream port 853 does not change this.

As port 853 is indeed reserved for DoT usage, you should consider to change your upstream to 192.168.0.1#53.

As for your observation:

You wouldn't, as Pi-hole v5 didn't log that message, so that doesn't mean that the reported TCP connection failure hasn't happened already with v5.

As for the potential causes, we've intensively analysed and identified that as being caused by specific behaviour of unbound, see Two Pi-hole instances, One with "failed to send..." - #44 by DL6ER.

There is currently nothing that Pi-hole could do to improve this.

The condition has been reported to unbound, where some potential measures are currently explored. Increasing unbound's incoming-num-tcp (e.g. to 20) is reported to mitigate the issue.

You may consider to contribute your observation over at failed to send TCP(read_write) packet (Connection prematurely closed by remote server) · Issue #1237 · NLnetLabs/unbound · GitHub.