If Namecoin gains reasonably widespread adoption, and a Heartbleed-like event occurs which requires a large fraction of users to immediately revoke their TLSA records, it is plausible that blocks would be full for a while. While DNSSEC-delegated TLSA records aren't affected by this issue, they are vulnerable to replay attacks for much longer periods than on-chain TLSA records.
It might be interesting to allow a domain owner to conditionally enable and disable records based on the presence of a mass revocation emergency, which could be signaled via a Namecoin DNS software update. This would, among other things, allow an on-chain TLSA record to be automatically replaced with a NS+DS delegation if such an emergency were to occur. This would allow very quick revocation in emergency situations, but in non-emergency situations the domain is protected from DNSSEC replay attacks.
More research would be useful on the subject of exactly what usage levels would make this necessary. More research would also be useful on the subject of whether trusting mempool name transactions in combination with RBF would be sufficient, making this unnecessary.
If Namecoin gains reasonably widespread adoption, and a Heartbleed-like event occurs which requires a large fraction of users to immediately revoke their TLSA records, it is plausible that blocks would be full for a while. While DNSSEC-delegated TLSA records aren't affected by this issue, they are vulnerable to replay attacks for much longer periods than on-chain TLSA records.
It might be interesting to allow a domain owner to conditionally enable and disable records based on the presence of a mass revocation emergency, which could be signaled via a Namecoin DNS software update. This would, among other things, allow an on-chain TLSA record to be automatically replaced with a NS+DS delegation if such an emergency were to occur. This would allow very quick revocation in emergency situations, but in non-emergency situations the domain is protected from DNSSEC replay attacks.
More research would be useful on the subject of exactly what usage levels would make this necessary. More research would also be useful on the subject of whether trusting mempool name transactions in combination with RBF would be sufficient, making this unnecessary.