If there's a CAA record for example.com that doesn't allow Let's Encrypt (CAA tag "letsencrypt.org") then this won't work. Let's Encrypt will check CAA (they will use DNSSEC if your domain has that) and verify that their tag is present before issuing if you have a CAA record.

If you're a larger outfit you should pick a trustworthy CA vendor or (two independent vendors according to your risk management profile), and lock CAA to those trusted vendors. You can then agree whatever terms suit your business on top of the Ten Blessed Methods, so as to avoid bad guys stealing your names. For example Facebook has an agreement with their chosen CA that all facebook.com and fb.com issuances get signed off by Facebook's network security people. No "But I'm the head of Asian marketing! I need this immediately" bullshit, it gets a sign off from netsec or it doesn't get issued.

this can easily be fixed by having some sort of mandatory waiting period (eg. 7 days) after issuance before a certificate can be considered valid. ct can be used to ensure no backdating occurs

or dns records validating the ca?

Great point. Ideally it would also be possible to track which certificate was used last time and if the certificate has changed, verify somehow whether the change was intentional.

This did exist in the form of HTTP Public Key Pinning (now deprecated).

Unfortunately, the mechanism which replaced it (Expect-CT) can only help after the fact - someone would have to notice the extra issuance, and you would have no idea whether your traffic was affected.