Nameservers respond over TCP

DNS over TCP is not a fallback for exotic cases. RFC 7766 makes support mandatory for every implementation: a response too large for the UDP payload comes back truncated with the TC bit set, and the resolver immediately re-asks the same question over TCP. A server answering on UDP/53 and not on TCP/53 gives that resolver nothing, and the query simply fails.

What overflows UDP is not unusual traffic. DNSSEC signatures, DKIM public keys in TXT records, a long SPF record, a large MX or NS set, and any answer carrying a lot of addresses all get there routinely. EDNS0 raised the ceiling, but the practical advice since the 2020 DNS flag day has been to keep the advertised UDP payload near 1232 bytes to avoid IP fragmentation — which sends more traffic to TCP, not less.

The failure is intermittent by construction. Small answers work and large ones do not, so the domain behaves perfectly until somebody enables DNSSEC or adds a DKIM key, and then breaks for the subset of queries that need the bigger answer. The usual cause is a firewall rule written for UDP/53 alone.

Permit inbound TCP/53 on every nameserver address, IPv4 and IPv6 alike, in the host firewall and in the network one. Check that the DNS software is listening on TCP as well — most do by default, but a hardened configuration may have turned it off.

Verify from outside with dig +tcp @ns1.example.net example.com SOA. Test each address separately: this fails per address, and a set where one of three refuses TCP looks fine to any test that stops at the first answer.

Leave the connection limits generous enough to be useful. RFC 7766 expects servers to hold TCP connections open for reuse rather than closing after a single query, and a very low idle timeout or connection cap turns "supports TCP" back into "fails under load".