* DV certificate issuance is based on a leap of faith (TOFU) by the CA. It is vulnerable to BGP hijack, DNS cache poisoning, ... as amply illustrated by the "domain control" "proofs" in ACME.
* The CA ecosystem is dying with Let's Encrypt's free certs removing the raison d'etre for most of the other CAs. Actual verification of identity does not scale, and DV "domain control" "verification" does not pay.
Crypto:
* The use of SHA1 in DNSSEC is not subject to collision attacks, only 2nd pre-image resistance is required, and there's no hint of SHA1 (or even MD5!) 2nd pre-images any time soon. While moving to SHA256 makes sense, there's no real problem with SHA1 in DNSSEC, it is adequately secure.
* The domains using 512-bit keys are a tiny minority hosted by a couple of DNS hosting providers (one of them "free", so you get what you pay for).
* Most zones have 2048-bit KSKs, and 1024-bit ZSKs. This can be addressed as more domains deploy ECDSA or 1280-bit and 1536-bit RSA keys (which have an estimated work-factor of 89 and 96 bits respectively, and there is ). The root zone keys are 2048 bits for both KSK and ZSK, and 1 in 3 TLDs has 1280-bit ZSKs, more will do that or switch to EC.
* Logjam researchers estimated the cost for a single widely used DH key (embedded as a constant in software): "The researchers calculated the cost of creating logjam precomputation for one 1024-bit prime at hundreds of millions of USD". This is somewhat specific to DH rather than RSA, and leverages the fact that many users used the same fixed DH groups. ZSKs are not fixed and vary across providers.
* Many estimates of RSA factoring cost ignore memory costs, for a more realistic analysis, see https://pdfs.semanticscholar.org/5f56/b7e3d8423cffa724d8037e...
Finally: the talk is about improving on unauthenticated opportunistic TLS in SMTP. The right comparison is with downgrades to cleartext, not with the latest fashionable crypto in browsers. The browsers moving from 1024-bit RSA directly to 2048-bit RSA is a bit of power-of-two numerology and was overkill (better optics more than better engineering). They did it because signing and verification are still adequately fast, so they can get away with turning it up to 11. That does not mean that more modest key sizes are not effective. Since DNSSEC is used only to authentication, not key agreement, there's no risk from future key compromise once a key is retired, so keys don't need to remain secure for decades, just a few months (for a ZSK) is enough.
Generally, real-world attacks bypass the crypto and attack far weaker defenses. Why break the crypto when you can subpoena the private key material, install malware on the end-systems, break TOFU certificate issuance...
Smug attacks on DNSSEC ignore many deficiencies of the alternatives, and are I suggest a case of letting the perfect be the enemy of the good.