Chromium based browsers still send DNS requests via UDP port 53, but when blocked, it only causes 5 secs delay, then they work as expected, for another 5 mins.
I don't really bother changing DNS away from the ISP. Giving these large companies free DNS data doesn't sit right with me. Especially with all the privacy concerns and issues going around. An optimal solution to using DoH would be to set up Bind9 on a cloud server. It can be set up serve both DoH/DoT queries, and it has caching. It can't do upstream DoH/DoT, so for a minimal footprint I'd recommend simply using the host as upstream. You could test this using Oracle's free tier cloud server.
Encrypted DNS doesn't prevent detection of SNI or IP addresses. Just like any HTTPS, it also leaves cookies behind. The usefulness behind encrypted DNS queries over plaintext/cleartext DNS queries is prevention of redirection by a malicious DNS server or ISP's "non-malicious" redirection to deliver content in a more "targeted" way. Specifically, DNS-over-HTTPS (unlike DNS-over-TLS/QUIC) blends in with other traffic via TCP port 443 and unless you block IP's for every DNS-over-HTTPS server (not feasable), it is difficult to prevent it. Even specific Intrusion Detection/Prevention Systems set to detect and block inbound certificate delivery for common DNS-over-HTTPS servers end up not working when TLS is implemented correctly. You obviously can't block TCP port 443 and expect most of the Internet to work. Normally DNSCrypt, DNS-over-TLS, DNS-over-QUIC, and DNS-over-HTTP3 (DNS-over-HTTPS-over-QUIC) use ports other than TCP port 443 and can be blocked by blocking respective ports, but DNSCrypt, DNS-over-TLS, and DNS-over-QUIC do not include as much metadata as DNS-over-HTTPS and DNS-over-HTTP3.
Bump of the bump because fellow MDLers don't let other MDLers download Windows 11 just to see if one specific set of settings works if other MDLers with Windows 11 can test that set of specific settings and reply to topics. It simply isn't how MDLers roll.