Windows DNS weird behaviour

Question

Having a particularly odd issue with AD DNS where the Domain Controllers are resolving NETBIOS names and appending the wrong domain name.

Issue:

When I perform a DNS lookup using the NETBIOS name of a server the DNS server returns an FQDN for the wrong domain name.

DC01 is one of the Domain Controllers for MyDomain.local. No such server or A-record exists on PartnerDomain.local

nslookup DC01.MyDomain.local returns the correct IP

nslookup DC01.PartnerDomain.local returns the correct IP (despite this server not existing in this DNS zone)

nslookup DC01 returns DC01.PartnerDomain.local but with the correct IP address

If I use the nslookup command line tool and request 'DC01' from either domain controller I get back 2x different FQDNs DC01.MyDomain.local + DC01.PartnerDomain.local

But the A-record DC01 doesn't exist in PartnerDomain's zone, it only exists in MyDomain's zone

Background:

We discovered this problem after upgrading from 2008 DCs to 2019 DCs

We have 2x Domain Controllers on MyDomain.local and we have a trust setup to 2x DCs at PartnerDomain.local

There's a Secondary DNS zone for PartnerDomain.local replicated to MyDomain.local's Domain Controllers

The Domain trust works just fine, the issue is when we try to resolve NETBIOS names the DC appends the wrong suffix to it in the reply.

I checked all the usual suspects: DNS Suffixes on adapters, LMHOSTS, DNS cache, etc

But NSLOOKUP confirms that it's actually the domain controller responding with this wrong appended domain name, not the workstations.

Here's the kicker, we deleted the Secondary Zone entirely from MyDomain.local's DNS... same issue

I suspect that when whoever setup the trust in the past they had an issue where the DNS Suffixes weren't being appended automatically so servers at PartnerDomain.local weren't accessible using NETBIOS names. But instead of updating the DNS Suffix search list in a GPO like you should then found a way to change the DNS behaviour with a registry setting or something as a bandaid and it's only now that we are finding this mistake.

Scouring through the DNS + AD settings all day and no luck finding what's doing this.