However, the OP wrote this:
> but keep in mind that the operator can also get SSL certs for your site
Which made it sound as if they can get a cert for your domain, which they cannot.
Why? They own and operate the DNS server for has-a.name, so (if they wish to) they can just add any record that they wish, to any domain, right?
Of course this is true for any registrar, but that's also why not anyone can just become a registrar.
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.
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.
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.
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.
You're generally right though.
1. They complete a DNS challenge and get a certificate for "\\*.has-a.name" - which obviously includes your subdomain.
2. They sneakily point "your-address-here.has-a.name" to an IP they control, get a certificate issued, then point it back to where it should go.
The second option is more hassle, and easier to notice, but the first makes it needlessly complex.
Of course if your actual domain is "bob.com" then this is just a distraction. We're using "your domain" in this case to refer to the subdomain that points to your IPv6 address.