No reasonable person would ever use DNSSEC to protect end-user PGP keys; that design would be incompetent on its face.
Don’t get it twisted.
Nobody suggested protecting end-user PGP keys with DNSSEC.
Because DNSSEC ensures the integrity of DNS records, a user that publishes their public key in the DNS using a CERT or PKA record (both defined in RFC 4398) or uses an OPENPGPKEY record as defined in RFC 7929, can be sure anyone who uses a DNSSEC-aware resolver (Google's 8.8.8.8, Cloudflare’s 1.1.1.1, Quad9’s 9.9.9.9) can confirm the integrity of these records.
Exporting public keys to be published in the DNS has been supported by GnuPG for at least 10 years.
Without DNSSEC, there’s no way to ensure the DNS records haven’t been tampered with. That seems particularly important for public keys.
You just said the same thing you said previously with more words and a bunch of RFC cites. If you store your PGP key in the DNS, then the entities that control the DNS can control your key. That they are "public keys" is immaterial; the point of a public key stored in a public ledger is that other people can rely on that key to safely send you a message, which they clearly cannot do with a key stored in the DNS.
Even if you believed DNSSEC is a good system --- nobody should; it's bad, and moribund --- a secure messaging system with end-user keys anchored in DNSSEC-protected records would be an incompetent design, on its face, simply due to the basic core architecture of the DNS and DNSSEC.
A different line of arguing may be helpful: not even GnuPG validates DNSSEC signatures (source: https://dev.gnupg.org/T4618 ). That's why DNS key discovery schemes are not enabled by default there (WKD is).
It’s not the job of GnuPG to validate DNSSEC signatures; that’s what a DNSSEC-aware resolver like BIND, Unbound or Knot does. If you’re not using such a resolver, all bets are off regarding trusting anything in the DNS.
But it’s certainly easy enough for GnuPG to check the DNS flags to verify the resolver has validated the DNSSEC signatures, therefore authenticating the openpgp record for its use, which is the point.
This is how DANE records work; SSH doesn’t validate DNSSEC signatures either but that doesn’t stop it from using SSHFP records in the DNS when they’ve been signed.
Don’t get it twisted.
Nobody suggested protecting end-user PGP keys with DNSSEC.
Because DNSSEC ensures the integrity of DNS records, a user that publishes their public key in the DNS using a CERT or PKA record (both defined in RFC 4398) or uses an OPENPGPKEY record as defined in RFC 7929, can be sure anyone who uses a DNSSEC-aware resolver (Google's 8.8.8.8, Cloudflare’s 1.1.1.1, Quad9’s 9.9.9.9) can confirm the integrity of these records.
Exporting public keys to be published in the DNS has been supported by GnuPG for at least 10 years.
Without DNSSEC, there’s no way to ensure the DNS records haven’t been tampered with. That seems particularly important for public keys.
RFC 4398: https://www.rfc-editor.org/info/rfc4398
RFC 7929: https://www.rfc-editor.org/info/rfc7929