Even in this case, you still don't need --force-renew; you could use --expand instead.
The difference in logic between then is that --expand automatically answers "yes" to the question about whether you'd like to replace the old certificate with an expanded one (covering a strictly larger set of names), while --force-renew also answers "yes" to the question about whether you'd like to re-issue the certificate even though there's no apparent reason to do so (when the certificate is not near expiry and no new names have been requested to be added to it).
You can certainly do that if you prefer. We've seen that, for most people, relying on a manual schedule like that makes it more likely, rather than less likely, that they'll eventually miss a certificate renewal (because they're on vacation, or sick, or dealing with some other urgent matter at that the time that they hoped to deal with the certificate renewal).
And people who habitually use --force-renewal without looking closely at the Certbot output are also likely to hit rate limits in case of certain minor errors.
But it doesn't violate any Let's Encrypt policies or anything to do it that way.
If you merely want the renewal to happen after 30 days without also doing your renewals manually, you can set renew_before_expiry = 60 days instead of the default renew_before_expiry = 30 days in the .conf file in your /etc/letsencrypt/renewal directory. (That time window for renewal attempts is user-configurable.)
It is a little worrying if both Cloudflare and Akamai users are encountering this problem. If finalization triggers a flood of DNS queries that is is too heavy (for some subjective measure of "too heavy") and we're seeing it across multiple notable providers, something's up.
It might be possible to prevent the CAA rechecking flood by deactivating existing authorizations every time you issue a certificate. The overall process will take longer, but it means the CAA checks will happen one by one for each authorization, not in rapid fire upon finalization. However, there is no way to force Certbot to do this, only with the --dry-run flag which discards the certificate. The other way to do it is to use a fresh ACME account every time.
The other way to do it is to use a fresh ACME account every time.
How can I do it?
If everybody was doing that, Let's Encrypts systems would have their load increased a LOT. IMO that's not something you should do.
Well, ok, I agree, but in current situation, as I can see there is no difference between manual renewing and automatic. I think error wil appear in both.
Yes, you are right. Not a long-term solution.
If I unregister account will current certificates be active or not?
Will wait for answer from CF, but as I think solution is only divide SAN
certificate for two with less number of names. It makes harder to my project,
but it may be only one solution.
Deactivating your ACME account won't affect the status of any certificates. Also if you have any rate limit exemptions from Let's Encrypt, you shouldn't deactivate your account.
I'd say the "design" flaw is in:
DNS + firewall/IPS
Something is "blocking" when it should not be.
Negative.
That may be ["common"].
But LE is simply following the rules [per RFCs].
So... the issue seems to be with the DNS implementation [and likely their allowed access rates].
Well then, "we're preaching to the choir".
The people that need to hear about this are the ones managing the DNS systems that may be causing this problem.