What is the cause for concern? I am trying to understand why DNS-over-HTTPS could be a bad thing from the user end.
If your router is linux, that might look like
/sbin/ip route add blackhole 9.9.9.9 2>/dev/null
/sbin/ip route add blackhole 1.1.1.1 2>/dev/null
/sbin/ip route add blackhole 1.0.0.1 2>/dev/null
/sbin/ip route add blackhole 8.8.8.8 2>/dev/null
/sbin/ip route add blackhole 8.8.4.4 2>/dev/null
Nothing stops anyone in the middle intercepting your queries and returning whatever they want, including your provider.
On the face of it, it seems like we're going to end up with a bunch of black box devices (from Google, Amazon etc) in our homes that are totally immune to most forms of network policing because between DoH, ESNI, TLS and CDN fronting, you can't see anything.
It's exactly as true to say that DANE gave Gaddafi ownership of bit.ly's CA as to say that today Boris Johnson owns the CA for slither.io - and as ridiculous. Back when you first started claiming this the Ten Blessed Methods weren't even a thing. You're complaining about the inadequate back door lock on a house that has the front door propped open.
I work for an outfit that buys passive DNS data (among other things) and all our suppliers agree that DoH makes no difference to their roadmaps - because they don't care who asked, only what the query and answer are. Is Vixie doing something vastly different? Maybe so but you've offered no evidence what that could be.
I can live with that.
You keep making these emotional appeals, but if I'm wrong, I don't see you actually rebutting me. "Your argument is so bad I will not deign to engage with it" is not a rebuttal.
OK, so first up I guess the problem is you've no idea what "escrow" is and so you ended up confused as to what key escrow could be. So let's fix that first.
Escrow is a service people or companies offer, the idea goes like this. Alice wants to do a deal with Bob, and Bob wants to make a deal with Alice, they're going to swap some of Alice's baseball cards for Bob's antique vase, but they don't trust each other. Fortunately they both trust Trent, a Third Party. Trent offers an Escrow service, both Alice and Bob agree with Trent that the baseball cards and the antique vase go to Trent, and then when he's got both things he'll send them to their new owners. If anything goes wrong, Trent gives back anything he received to the person who sent it and the deal is off.
In the tech industry the most likely set up you'll see is that investors are worried all the stuff they're spending a lot of money on at a startup is not material that a bunch of burly guys can pick up and put in a truck if the firm fails - instead it's in Git repos or Google Drives and if it falls apart they know it has residual value that could be realised but they're not technical people, they're money people. So an escrow firm says fine, pay us a bunch of money and make the startup sign this data escrow agreement, and then if they fail you activate this clause and we give you a bunch of USB drives full of source code and whatever else. The escrow firm has IT people who can do stuff like send over keys for access to a GitHub, who know the difference between an S3 bucket and a SD card, which the investors don't want to have to learn about.
In key escrow _your_ keys are held by a third party on your behalf. You can do end-to-end encryption if you want, but you're obliged to use this escrowed key. If the third party releases the key (e.g. because of a warrant, or an NSL, or because they're corrupt) then whoever gets it can now decrypt everything you've sent, or impersonate you seamlessly.
If your iPhone honors a secret Apple passphrase that's a _backdoor_. If instead Apple insists on keeping a copy of your passphrase in a safe at Apple HQ that Tim Cook promises not to open _that_ would be escrow.
Your objection that in DNSSEC "the roots can simply override that key with their own" also applies to any PKI, the whole _point_ of a PKI is that the trusted third party binds identity to keys, and if trust is misplaced they might falsely bind an identity to the wrong key. So the problem is - as I illustrated - that objections on the basis of DNSSEC being a PKI work just as well against the Web PKI. As a reason to prefer the Web PKI over DNSSEC they're ineffective.
Saying that backdoors are "the whole _point_" of a cryptosystem is not the devastating refutation you appear to think it is.
But that goes from being a relevant point about Vixie (his support of a system with key escrow - a false claim) to the irrelevant and vague (trusted people might betray your trust) that I guess if I squint I could read as sort of vague anti-establishment sentiment and otherwise is just pointless.
Here's a much shorter way to write what you meant without needing to slip in a false claim about DNSSEC:
"Paul Vixie is a smart guy but he's wrong about this"
Plenty of anti-TLS 1.3 stuff for example says that they "need" the plaintext Certificate message which in TLS 1.3 is now encrypted. But that message is literally just some public data - an X.509 certificate, if you're using it to "verify" anything your security is broken because a bad guy can send someone else's cert. They can't send a working CertificateVerify for it, but you don't know that because that message was never plaintext.
I wish it didn't have the overhead of TCP/HTTP (which is why I was a bigger fan of DNSCrypt). Anyone can stand up a resolver that can handle 50k UDP requests a second and operate a public resolver. It starts to get operationally dicey to stand up infrastructure that can do 50k HTTP requests a second. As a result you end up with a small handful of players who can operate medium to large scale public resolvers.
The NTP pool works quite well on this model. It would be a much larger commitment for participants had to manage stateful connections.
How does this work in your mind?
You can also just not run DoH if you trust your network. I'm saying DoH is a good thing, not that everyone has to use it.
I can see that there are problems with DNS; there always have been, and it's always been obvious. But for now, I think I prefer running my own resolver. Unbound is really easy to set up.