DNS lookup failing

[Nick Howitt]

On 21/03/2024 11:08, Tuomo Soini via Unbound-users wrote:
> 
> On Thu, 21 Mar 2024 10:47:37 +0000
> Nick Howitt via Unbound-users <unbound-users at lists.nlnetlabs.nl> wrote:
> 
>> 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.
> 
> Nslookup can resolve your key just fine through unbound 1.19.3.
> 
> I even verified with nslookup from c7 machine that querying works.
> 
> My guess is that gateway management does something ugly.
> 
Possibly, but Cloudflare DNS can cope with it.

Also 2048._domainkey.howitts.co.uk works with Gateway Management which 
suggests it may be something to do with long response handling. This is 
where I think packet sniffing would help but I don't know how to 
interpret the responses. I have pcap files with and without Gateway 
Management active and I can see in tcpdump there is something showing 
with [1au] suggesting there is extra data in the DNS request with 
Gateway Management. At that point my knowledge fails.