No, but admit it, you felt a certain glee in submitting it... (which is not to say you're wrong about that, and I write that as someone who once penned a public standard mandating DNSSEC -- which just goes to show we all make mistakes...)
I think the case against it, while extraordinarily strong, is actually pretty subtle, and I generally don't look at advocacy for it in the early days as a mistake at all. We learned a lot from the experience of trying to get it to work. I was a vocal advocate for key pinning, and I don't think I was mistaken to push for it, despite its ultimate non-viability and the success of the competing CT model.
Good point. I guess that any technology with a huge built-in "ah, yes, that one simple mistake you made, now means you'll have to completely rename your endpoint before anyone will be able to talk to it again" foot-gun requires a bit of a re-think prior to general availability.
The only way to get it right is to try. An issue I think people sleep on with DNSSEC is that the service model was designed in the mid-1990s, as a TIS Labs project for DoD, and was premised on the idea that cryptography would be far too expensive to do "live" on servers. That's why we have a DNSSEC architecture built around offline signers, which is one of the original sins of the protocol.
So I think a more precise meta-criticism of DNSSEC would be that it should have been obvious by the early-mid oughts, when the entire Internet was running off online TLS cryptography, and DNSSEC still wasn't even deployable (because roots weren't signed, and because we hadn't gotten to the typecode roll and DNSSECbis) let alone mired in the single digits where it is now, that it was time to scrap the original design and come up with something new.
