Don't worry about the forum placement at the moment. Just use Merlin in the future.
IMO, the problem w/ these online leak testing tools (at least when it comes to DNS) is rarely if ever do they expose their testing techniques, which makes them highly suspect as to their accuracy. Trying to determine the DNS used by the client is NOT easy. I assume they're using some sort of server and client-side Javascript "trickery" to deduce this information. But in the case where the client is behind a router, one which is providing DNSMasq as a local proxy, and contacting the public DNS server on their behalf, I have NO CLUE how that can be done reliably, if at all. Therefore, I *never* use such tools. I find them worthless.
As I've said many times in the forum, the *only* thing that matters is what connection tracking reports as far as port 53 (853 if using DoT) traffic, and which network interfaces that traffic is using. Once you know that information, and it's working as you expect/desire, it doesn't matter a lick what these online tools report.
One thing to keep in mind though. It's entirely possible (perhaps even likely) that when you configure your router's DNS, the *actual* DNS server doing the resolution is different from the configured servers. IOW, if you're configured to use Cloudflare (1.1.1.1 and 1.0.0.1), that will be obvious in connection tracking. But ultimately those may only be proxies which hand off DNS name resolution to secondary servers. THAT may be what's appearing in the reporting of online DNS leaking testing tools.
It's just another reason why determining how DNS is actually being handled is so difficult. We as end-users have limited information. And so do these online tools. In the end, all that matters is that your router's DNS is configured properly and working as expected. Once it leaves the router, it's out of your hands.
From an ssh session, you can dump connection tracking and easily tell what's happening.
Code:
egrep 'dport=(53|853) ' /proc/net/nf_conntrack
It may seem intimidating at first, but you can quickly learn what the various fields mean by doing a little research w/ Google.
Connection tracking is being constantly updated, so it can be useful to monitor it continuously using the watch command.
Code:
watch -n10 "egrep 'dport=(53|853) ' /proc/net/nf_conntrack"
In terms of network interfaces, the trick is to watch the second dst field. That's the destination IP of the expected reply, and will typically correspond to the IP assigned on either the WAN or VPN. That is how you know where those DNS queries are being routed. And therefore whether you do or don't have a DNS leak.