CNAME'ing pool-ntp.tesla.com to something they do not control is already quite risky as it would allow someone to e.g. request pool-ntp.tesla.com certificate though it might take quite a few tries.
I thought about trying this, but MPIC makes it very very very difficult (the round-robin has some geolocation magic baked in regarding what server it connects you to).
> That points to a glaring hole in the modern-day automated web PKI, not Tesla's dangling DNS record.
It's not. They control a long-term high-value asset (the domain tesla.com). They decided to delegate part of that asset to a large number of "random" people that they do not have a contract or agreement with.
Being able to issue certs for cloud IPs has nothing to do with this since it is not a long term asset, and if it is you probably don't delegate it to random people to control unless you do not value that asset.
This is why IP certificates are limited to a max lifetime of 6 days.
> IP address certificates allow server operators to authenticate TLS connections to IP addresses rather than domain names. Let’s Encrypt supports both IPv4 and IPv6. IP address certificates must be short-lived certificates, a decision we made because IP addresses are more transient than domain names, so validating more frequently is important.
