I had a conversation recently on a podcast which explored the requirement, particularly as it relates to DNSSEC. In short: this may be required for PFS against packet capture of contents, TLS sessions, you-name-it but for the signed state of the DNS, it's very unclear there is a risk here.
The reason it's unclear is that the defensive move by NIST is to maintain the 20-30 year forward secrecy intention. Move now, IN CASE PQC HAPPENS but also in case non Q methods weaken RSA2048. Well, fair enough. But the DNS doesn't have a 20-30 secrecy requirement: It's a different use case.
OTOH moving to ECC is good because it reduces packet size but at a cost of moving compute burdens into the client space. Stll, it makes sign-at-the-edge easier, and it makes IPv6 DNS work better.
Snarf packets now. Keep the dump. When pqc hits, decode the session. Since session key secrecy depends on the rsa alg key exchanges subsequent rekey is not protective. Each session will require a fresh rsa key exchange, but if the algorithm is broken under pqc, this isn't very special.
That's not what forward secrecy means, as a term of art. Forward secrecy is the property whereby compromising a key today doesn't allow you to recover all the plaintexts previously encrypted under that key (you normally get it by running a DH exchange for every session, so they have ephemeral keys).
"Harvest now, decrypt later" is how I've heard the attack described; there isn't really an engineering feature of protocols or ciphers that (a) has a name and (b) directly addresses this problem. But you're roughly right that the interactive nature of how DNSSEC (and signatures more generally) are used makes them of secondary importance in PQ upgrades.
I think there's approximately 0% of a chance that organizations are going to set an operational deadline for migrating off ECC by 2029, regardless of what Gartner says.
The reason it's unclear is that the defensive move by NIST is to maintain the 20-30 year forward secrecy intention. Move now, IN CASE PQC HAPPENS but also in case non Q methods weaken RSA2048. Well, fair enough. But the DNS doesn't have a 20-30 secrecy requirement: It's a different use case.
OTOH moving to ECC is good because it reduces packet size but at a cost of moving compute burdens into the client space. Stll, it makes sign-at-the-edge easier, and it makes IPv6 DNS work better.