TCP connection error to upstream DNS servers

General
1

Team,

See also the error messages below: I have this randomly once or twice per 24-hours.

From what I can make of it it has something to do with DNS requests that switched(?) from UDP to TCP - for example because of packet loss, a connection reset, no response from the upstream server, etc.

Does this ring any bells? Anyone an idea where to start troubleshooting this (if-at-all)?

With warm regards - Will

=====

2026-07-07 10:42:09.967 WARNING Connection error (195.121.97.203#53): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2026-07-07 10:42:09.967 WARNING Connection error (195.121.97.203#53): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2026-07-07 10:42:09.968 WARNING Connection error (195.121.97.203#53): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2026-07-07 10:42:20.207 WARNING Connection error (195.121.97.202#53): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2026-07-07 10:42:20.207 WARNING Connection error (195.121.97.202#53): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2026-07-07 10:42:20.207 WARNING Connection error (195.121.97.202#53): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2026-07-07 10:42:30.447 WARNING Connection error (1.1.1.2#53): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2026-07-07 11:21:13.903 WARNING Connection error (195.121.97.203#53): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2026-07-07 11:21:24.143 WARNING Connection error (195.121.97.202#53): TCP connection failed while receiving payload length from upstream (Resource temporarily unavailable)
2

This is normal.

DNS uses UDP by default, but when the packages are too big for UDP, it changes to TCP.

The issue is Unbound closes the connection without warning and nothing is returned. dnsmasq (embedded in FTL) keeps waiting until it timesout and then logs a warning.

Unbound developers consider normal to ignore these timed out connections. They said this is normal and they won't change the code.
dnsmasq developers think TCP requests should be answered or closed. They think the current behavior should always be logged.

FTL uses dnsmasq internally and Pi-hole team doesn't want to change dnsmasq code.

Important:

  1. These messages are harmless. They are only informative. These errors always happened, but you are seeing them now, because only recently (after Pi-hole v6.0) dnsmasq decided to expose this warning (a few years ago this was a silent error and no one noticed, but it always happened).

  2. There is nothing we can do about it. These errors always happened and cannot be fixed (for the reasons explained above).

  3. If you don't want to see these messages on the web interface, you can disable them using this option:

    image
    image552×344 8.3 KB

3

Thank you the detailed explenation.

Would the story be different if there is no unbound involved? At least not local?

4

This message will always be generated when a TCP request is not answered or closed.

With unbound this happens a lot, specially if you have DNSSEC enabled. I also saw it happening with other upstream servers (not that often), even when using public servers, like Google.

If you don't like to see these messages, you need to use the option to hide them.

5

I also use unbound and have DNSSEC enabled. I rarely see these messages. In fact, none in a few months. I have applied a few config tweaks that I found in the forums here, namely incoming-num-tcp, but YMMV. I also build unbound from sources for latest fixes/features.