Obviously if you can sign a cert which is trusted by browsers, then you technically have the ability to impersonate anyone, but processes are used to fight against this.
PSL (https://publicsuffix.org/), DNS Certification Authority Authorization , and Certificate Transparency could be combined so browsers are allowed to know who can sign what, who's a registrar, and who's doing what.
PSL protects the other way around: it can only prevent whatever.has-a.name to compromise has-a.name or another.has-a.name
DNS Certification Authority Authorization assumes trust of the DNS server. Doesn't work if the DNS server itself is compromised / malicious. (Maybe with DNSSEC, but DNSSEC has its own problems and definitely doesn't work when your TLD itself is compromised.)
CT is really the only thing that works in this scenario (attackers/third party gaining write access to DNS records), but not every CA has CT and not everyone has the means to monitor CT logs. CT isn't even required for every browser/certificate (only EV certs (dead) for Chrome, and you need HPKP (dead) or Expect-CT (no browser support) for this to work reliably). Plus, what are you supposed to do when you find out there's a bad cert for your domain out there? Yell at someone on Twitter? It's going to be hard to convince a CA that you're not doing business with that someone with write access to DNS does not own the domain. Attackers are already impersonating you while it takes hours to sort things out.
... all of this is not to say that these security measures are bad, just not enough. We really put more trust on DNS servers than we ought to.
You're a little out of date on Certificate Transparency.
Chrome and Safari both require SCTs (the signed timestamps which prove a certificate was logged) for all new certificates, have done for quite some time. There are CAs which issue certs without logging but largely it's for applications which themselves know about SCTs so they can do the fix-up at runtime not issuance, because again if you just added these certs to a generic web server Chrome and Safari, two very popular browsers, will reject the certificates outright.
Since they'd be next to useless to lay people without, all the certs offered to the general public these days have SCTs baked in by the issuer. Let's Encrypt were ironically among the last to do this.
Wow, that's really good to hear. One of the chief complaints I have about CT is the lack of agency. Not that this solves all problems, but good on Chrome and Safari for enforcing it
PSL could/should also stop sub.has-a.name trusting signed certs such as wildcard.has-a.name, depending on the configuration of the PSL. I'm just not really sure any actual browsers implement it like this though, as reading the PSL "how this is used page" doesn't turn up any such thing.
CAA does rely on DNS working, which your registrar can probably hijack. Fair point.
CT would help protect against the registrar but not against a malicious CA who simply wouldn't log if they were going to sign a cert maliciously.
If a CA "forgets" to add a certificate to the CT log, they need a really good excuse to not get distrusted immediately. That's part of the reasoning: malicious certs are almost useless if you don't present them to a client. And if that client manages to exfiltrate the cert...
PSL (https://publicsuffix.org/), DNS Certification Authority Authorization , and Certificate Transparency could be combined so browsers are allowed to know who can sign what, who's a registrar, and who's doing what.