There is a real alternative solution, and it has the virtue of being exceptionally simple: do nothing. The DNS doesn't need to be secured, just like raw IP isn't, nor every individual BGP4 update.

DANE (using DNS as an alternative to TLS CAs) is the primary real-world use case for DNSSEC.

No site in the world is secured purely using ECC DNSSEC, because the roots and TLDs rely on RSA. Moreover: find the most popular site that uses ECC DNSSEC and report back what it is. (It'll be tricky, because very few of the most popular sites use DNSSEC at all). And, of course, the ECC variants DNSSEC uses are already outmoded. Which is why I was careful to refer to modern deterministic Edwards-curve signature schemes. Also: did you really look at the links in that post and think it lacked even "minimal research"?

I don't see any other arguments in this response, but you can call me out if I missed any.

I'm using DANE on most of mine, but the public-key pinning + CA usage of it - so an MITM would need to either steal signing keys, or a pocket CA and to swap my DS record. Not impossible but it's an extra barrier (instead of a replacement for the PKIX). With free certs on the near horizon from Let's Encrypt as well, then the two together allow two independent barriers, one with certificate transparency, and that may work quite well for domain validation in practice.

The country that owns/operates the TLD I'm under, or the registrar, can already swap my DNS, but DNSSEC makes it harder for others to. I don't know what more we can do about that - probably more in the realms of I2P or Tor, etc.

DNSSEC has definitely got some problems. The reflection problem, for one, which needs careful mitigation. And yes, it could use modern crypto badly, but that's waiting on standardisation; signatures are a way off in CFRG and then there's all the HSMs. It may be better as part of a nutritious layering breakfast; DNSCurve on top, maybe?

You won't see me arguing for plaintext anything, however, so if unsigned plaintext is the alternative, bugger that. QUANTUMDNS is just way too easy as a man-on-the-side otherwise.

BGP is a total clusterfuck and needs a lot of security it doesn't have - that's about all I can say as to that.

IIRC when I crawled the alexa top million's DNSKEY records none of them used ECC. I did see a few using DSA.

DANE is not DNSSEC, and was not and is not the motivation behind it. That thought is incorrect.

As for algorithms, you're insulting DNSSEC as it's been implemented, not as a protocol. DNSSEC reserves purposely up to 255 slots for algorithms, and has added them as it's evolved. But claiming it depends on RSA and doesn't support modern eliptical curve schemes is at worst wholly false, at best half false depending on the definition of modern.

All I can say is that I've read, I believe, every dnsext and namedroppers post and the archives of the old mailing lists from the 1990s, when DNSSEC was a government funded project of my then employer, for whom I was busy writing DNS security testing tools, and I believe you're wrong: DANE is the motivating use case for DNSSEC.

It's a pretty weird rhetorical spot to put yourself in, by the way. Without DANE as a motivation for deployment, there is no reason to deploy DNSSEC. DNSSEC can't provide end-to-end security, and TLS and SSH already authenticate themselves without DNSSEC.

I don't know what your second paragraph means. You can see what I'm referring to empirically by playing with DNSviz. Like I said: go find the largest DNSSEC site that uses ECC records. Then, for fun, and not counting the TLDs themselves (sigh), the largest that use RSA-1024.

Note that only SHA-1 and RSA must be supported by conforming DNSSEC implementations; see RFC 4034. That's probably why support for other ciphers or hash algorithms is inconsistent at best.