DoH as implemented in Chrome still queries the servers configured in /etc/resolv.conf. It just uses the DoH protocol rather than plain DNS if it recognizes the server as supporting DoH (according to its built-in whitelist). Firefox is the one forcing all DNS resolution through Cloudflare's DoH servers by default.
Personally I'm mostly OK with the Chrome approach for public domains but I still worry about applications bypassing the host resolution plugins configured in /etc/nsswitch.conf. In my case that means: files (/etc/hosts), mymachines (automatic local VM name resolution), mdns (*.local), and myhostname. If an app only looks at /etc/resolv.conf and doesn't use the system resolver then it won't be able to see any of these local names. In the end, domain resolution is a system function and not something applications should be implementing on their own.
> In the end, domain resolution is a system function
Then just put 127.0.0.1 in /etc/resolv.conf. nsswitch, particularly for hostname resolution, is fundamentally broken as it doesn't work well with asynchronous software architecture; nor does it work well in languages that don't depend on libc.
Systemd already supports being a local resolver, but see OpenBSD's unwind (https://man.openbsd.org/unwind) for an attempt to seamlessly handle DNSSEC, DoT (and eventually DoH), local Wi-Fi portals, and other issues.
Personally I'm mostly OK with the Chrome approach for public domains but I still worry about applications bypassing the host resolution plugins configured in /etc/nsswitch.conf. In my case that means: files (/etc/hosts), mymachines (automatic local VM name resolution), mdns (*.local), and myhostname. If an app only looks at /etc/resolv.conf and doesn't use the system resolver then it won't be able to see any of these local names. In the end, domain resolution is a system function and not something applications should be implementing on their own.