On 21/03/2024 09:56, Tuomo Soini via Unbound-users wrote:
On Thu, 21 Mar 2024 09:40:10 +0000
Nick Howitt via Unbound-users <unbound-users@lists.nlnetlabs.nl> wrote:
I've done a bit more digging. With tcpdump, I can see the request
coming from ClearOS into Unbound, going out onto the internet and
returning with a valid answer to Unbound, but this answer does not
then get back from Unbound to ClearOS.
Your domainkey is too big to fit into udp response. That means
there will be empty udp response with TC bit set on (requesting change
to TCP dns) new request should happen again with TCP.
Make sure tcp dns traffic is allowed for this to work. TCP dns is
really required nowadays. So if you have tooling which doesn't work
with tcp dns, that just means you need to upgrade.
Generally your dkim key can't be that big to work reliably. rsa
sha256 2048 bit key still fit to udp.
I strongly suggest against using nslookup as diagnostic tool, please
use dig.
I am using nslookup as a diagnostic tool, but I also have "amavisd
testkey" failing in a similar way which is what really kicked off this
investigation:
[root@server ~]# amavisd testkey
TESTING#1 howitts.co.uk: 202403._domainkey.howitts.co.uk => invalid
(public key: DNS error: FORMERR)
Yet dig works. Ultimately the goal is to get "amavisd testkey" working
so the start up of amavisd is clean. Nslookup is just a way of
reproducing the issue.
If I bypass Unbound, and go straight to an upstream resolver, the query
works from ClearOS so it is like ClearOS can handle long replies/TCP
unless the reply is of a marginal length do going direct to the internet
is OK, but going via Unbound is not. It also works from ClearOS without
Gateway Management via Unbound, so it is like Gateway Management is
inserting something into the query which Unbound does not like, but is
OK while going straight to an upstream resolver bypassing Unbound.
