That's a bit overblown. There's a lot there and some of it conflicts with itself but it's not unmeasurably large by any means. It's a knowable protocol (and yes, I'm aware of the camel meme[1]).
True - my bad of referring to DNSsec; there are other ways you can use encryption for DNS resolving (by using an external DNS server that encrypts using TLS or simply by using DNS-over-HTTPs). This way you get 100% encryption of your DNS traffic (and thus tamper checks that would detect bitflips). Again, not arguing against ECC, there are valid points to want it - I just see less and less reasons in the consumer market.
Encryption and signing don't protect against memory corruption.
For example, I download software from the internet then hash it. The hash matches. Before the bytes are written to disk locally, a bit flips in RAM. The corrupted data is written to disk and used.
Likewise, dnssec doesn't protect you against DNS bitsquatting attacks[1] because the domain name can be changed before the DNS request is made. So the DNS response your computer makes for a-azon.com might be totally valid and signed. It can come through DoH or whatever. The problem is that your browser thought it was the response for amazon.com and chrome send a bitsquatter your amazon cookies. (Oops).
I only know of proprietary tooling for this sort of thing. I'd imagine it'd be tough to sell as a product or service so it'd probably have to be someones labor of love.
I don't know why Cloudflare, like Amazon, often get a free-pass on HN for their DNS implementation bugs. Regardless of DNSSEC's merits or otherwise, this bug isn't inherent to DNSSEC.
Having had to troubleshoot a third-party service not so dissimilar to 1.1.1.1 and prove to them that their infrastructure was misbehaving in a similar manner, I'll take the error thank you.
1. https://powerdns.org/dns-camel/