I have the same logs.
I can't say for sure if DoH is actually working.
Seems like it works properly for me. I don't have regular DNS set up at all, and have disabled "Use peer DNS" in every WAN config, so it definitely has no way to fall back to regular DNS. Instead I have dns.quad9.net manually mapped to 9.9.9.9 and 149.112.112.112 in static DNS entries. Though I also get a lot of these DoH server response not OK: 0: warnings.
What I did to clean up my logs was to set up a separate logging memory action named dns, and logging rules dns, info, dns, error, dns, warning with the dns action, then add !dns to the default rules, and filter the log with "buffer is not dns". Though it would be better if Mikrotik fixed this.
For some time I had been intending to try the DNS-over-HTTPs (DoH) proxy DNS service of Quad9, a local Swiss organization. I had hoped to use my MikroTik RB4011 for that purpose, but Quad9 requires the modern HTTP/2 protocol, which MikroTik didn't support. (Other DoH providers such as Google and Cloudflare continue to support HTTP/1.1).
So I was delighted that the recently-released RouterOS 7.23 included DoH HTTP/2 support. A couple of frustrating hours later I was less delighted to read the fine print in the release notes that arm32 were not included. But I have a lot of MikroTik devices, so I could set it up instead in one of my cAP ax'es, which has an arm64.
So I set it up on a cAP ax and configured my main LAN DHCP server to offer that cAP ax as DNS server. And it worked ... almost. Over hours I noticed that things were sometimes laggy, and sometimes hostnames like www.google.com couldn't resolve, at least temporarily.
So my buddy Claude and I had a discussion, which yielded the hypothesis that the new MikroTik code might still need tuning as well as an experiment to validate that. The experiment was to install the mature dnsdist DNS proxy package on an Ubuntu server in my LAN, configure dnsdist to use Quad9's DoH service just as the cAP ax was doing, reconfigure the main LAN DHCP server to offer that dnsdist instance as DNS server, and watch what happens. And what happened was ... perfect.
So I now have empirical evidence that when using Quad9's DoH over HTTP(s)/2, the Linux dnsdist package (I'm using an older version 1.8.3 that's in the standard distros of my Ubuntu 24.04) works considerably better than MikroTik's RouterOS v7.23 DoH over HTTP(s)/2 implementation.
What did you expect - to find that Quad9 was at fault and that MikroTik's implementation was perfectly RFC-compliant?
In my view, Quad9 is working correctly and is a reliable DNS service. MikroTik's HTTP/2 implementation appears to be in a very early stage of development, even though it has been included in a stable release. If you follow the release discussions, you will see that many users still report numerous warnings in the logs when using the DoH resolver over HTTP/2.
A mature HTTP/2 implementation should not produce these kinds of issues. HTTP/2 has been widely used and refined for over a decade, whereas MikroTik has only recently started implementing it. As a result, there are likely still several early-stage issues that need to be resolved.
Unfortunately these warning log messages are still an issue on 7.23.1 
