[comex]

To be fair, “you controlled the DNS records for the domain at some point and your entry has yet to be deleted” could also describe the HTTP-01 challenge. Admittedly, having the A/AAAA record point to the wrong place is much more likely to be noticed than having a stray TXT record lying around. Perhaps more worrying is the possibility of having a keypair that is legitimately being used to sign certificate requests, but which an attacker also stole a copy of at some point. (Assume that the server owner doesn’t know they were compromised and hence didn’t rotate the key, but the attacker subsequently lost access for some reason.) Such an attacker would likely have also stolen the TLS private key, but that only stays valid for 90 days, whereas for this keypair approach to be useful, the keypair would have to stay valid for a long time or indefinitely…

[kelnos]

Does it? Under the approach of storing a public key in DNS, certs can be issued long after the person asking for one has lost access to the website, if the pubkey record hasn't been deleted.

With http-01, ownership has to be proven every time a new cert is issued.

> Such an attacker would likely have also stolen the TLS private key, but that only stays valid for 90 days

That doesn't have to be the case; the private key can be valid for as long as someone wants it to be, unrelated to the validation period of the cert that is issued. Yes, it does look like certbot generates a new keypair for every renewal, but in a world where we were putting a pubkey in a DNS record, the private key would certainly have a much longer validity, as otherwise there'd be no point to doing it this way in the first place.