That’s not really the issue. The hard problem isn’t making a bunch of DoH competitors but getting OS level support so that browsers can drop their own logic.
An app running on the system needs to be able ask the OS for an encrypted DNS lookup or where it should perform such a lookup and get be able to decide what to do when it can’t.
The UI needs to be there to accept DoT or DoH networks from DHCP on trusted network profiles but the a user-chosen default on untrusted networks.
It is well known that OS vendors move slowly. How long will it take for all major OSes to standardize on an encrypted DNS protocol? I'm pretty sure it won't happen before 2030.
Should application vendors simply do nothing until then, even when they can do something now? Should programmers always wait for the perfect solution to come along and only then ship the definitive version? What happened to building what we can now and incrementally improving over time?
There isn't even a consensus on how best to implement encrypted DNS. How do we decide which proposal to standardize on if we're so reluctant to test them in the wild? Without successes and failures to learn from, there is even less chance that OS vendors will deviate from the status quo.
Absolutely not! I'm firmly in the camp that browsers should do this until OS support arrives.
However, the "centralization problem" isn't solved by more competitors existing because widely deployed applications will still have to choose a single option for all but a tiny segment of users that will change it.
If the default comes from the OS vendor then we're in a slightly better place since the default for macOS and iOS will be Apple's servers, Windows will be MS, Android will be Amazon or Google. Competition in this space comes from the people who decide what DNS service to use, not the people standing up the service.
I dunno, I would much rather retain the ability to download a new browser that promises improved privacy (i.e. by integrating with their own DNS service that includes pi-hole) than be limited to one of four well-known American OS vendors.
Alternatively, I see no reason why someone can't write a small application that runs a resolver on localhost, adjusts your hosts file accordingly, and forwards queries to any third party or distributed network of your choice. Wait a sec, I already have dnsmasq and/or systemd-resolved doing this on some of my machines. It can be done right now with no need to wait for the OS vendor to change things.
You really wouldn't be limited, it would be no different than time.microsoft.com being the default on Windows or rhel.pool.ntp.org being the default on RHEL.
The local resolver that proxies DoH or DoT is nice (I'm using it right now too!) but it doesn't solve the problem of applications wanting to be sure they're getting an encrypted connection.
An app running on the system needs to be able ask the OS for an encrypted DNS lookup or where it should perform such a lookup and get be able to decide what to do when it can’t.
The UI needs to be there to accept DoT or DoH networks from DHCP on trusted network profiles but the a user-chosen default on untrusted networks.