DNS lookup failing

[Nick Howitt]

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 at 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 at 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.