That's not a fair summary of what's happening at all. DNSSEC advocates would certainly like to accelerate DNSSEC adoption. Unfortunately, they've fallen into a design that:
* failed architecturally twice before reaching its current state (it is being, as Richard Stallman would put it, debugged into existence)
* required signin from multiple huge corporations to begin deployment, so much so that some (well known) DNSSEC proponents have unironically proposed alternate privately run roots just to get things kickstarted
* requires the maximum amount of re-education from DNS operators everywhere, being as it is a standard that imposes even greater levels of config complexity than HTTPS/TLS, but on a DNS record by DNS record basis
* is effectively a no-op in the current DNS architecture, where your desktop doesn't run a bona fide cache but instead delegates that task to a cache server (the thing you call a "DNS Server" in your Internet configuration, but which on reflection turns out to be something no Internet host actually needs if they're willing to run their own cache) --- because it only protects server-to-server traffic, and architecturally can't protect stub-to-server traffic.
* Will require upgrades to every "sockets"-style program ever written to properly function.
If a magic wand existed that could dispel any of these issues, I assure you that the IETF working group would wave that wand right away.
* failed architecturally twice before reaching its current state (it is being, as Richard Stallman would put it, debugged into existence)
* required signin from multiple huge corporations to begin deployment, so much so that some (well known) DNSSEC proponents have unironically proposed alternate privately run roots just to get things kickstarted
* requires the maximum amount of re-education from DNS operators everywhere, being as it is a standard that imposes even greater levels of config complexity than HTTPS/TLS, but on a DNS record by DNS record basis
* is effectively a no-op in the current DNS architecture, where your desktop doesn't run a bona fide cache but instead delegates that task to a cache server (the thing you call a "DNS Server" in your Internet configuration, but which on reflection turns out to be something no Internet host actually needs if they're willing to run their own cache) --- because it only protects server-to-server traffic, and architecturally can't protect stub-to-server traffic.
* Will require upgrades to every "sockets"-style program ever written to properly function.
If a magic wand existed that could dispel any of these issues, I assure you that the IETF working group would wave that wand right away.