The stuff about CAA is wrong.<p>CAA is NOT checked by browsers, the BRs do not say browsers should check CAA, and indeed it is specifically NOT designed to be checked by RPs at all. CAA tells the Issuers (Certificate Authorities) whether the name owner authorises them to issue at a moment in time.<p>If you think "that seems useless" it's probably because you completely misunderstood the security model it's written for. We don't want untrustworthy or incompetent CAs at all, this is not a guard against those. This is a guard against trustworthy, competent CAs that you've got your own reasons to disallow for your specific names.<p>Example: Facebook for years had a single preferred CA and their contract with that CA said everything gets signed off by the certificates team. After Let's Encrypt came on the scene a subcontractor developing example.facebook.com needed HTTPS, didn't read all the paperwork from Facebook and just got a cert from Let's Encrypt. Facebook security freaked out because their team hadn't authorised this weird new certificate. Let's Encrypt did nothing wrong, but it looked exactly like an attack. CAA lets Facebook tell every CA except the one that knows about their internal policy, "Thanks, but no thanks". Let's Encrypt would have checked CAA and told the subcontractor "Sorry, no, policy forbids, check CAA" and when they went to Facebook to ask why they'd have got an earful for not obeying policy.