ニュースソース：CASECURITY
以下は 2017年3月21日に公開されたThe Latest on Certification Authority Authorization の「Background」のセクションを要約したものです。
CA/ブラウザフォーラムがCAAを標準化した背景
RFC 6844ではドメイン管理者がドメイン・サブドメインへの証明書発行権限を持つ認証局（CA）を指定するためのメソッドとしてCAAレコードを作成しました。
証明書発行直前に認証局（CA）がCAAレコードを確認し、発行許可の決定をします。
確認の結果、CAAレコードが存在しない、もしくはCAAレコードに対象認証局（CA）への許可が記載されている場合に、証明書の発行が許可されます。
CAAレコードの利用により、ドメイン管理者はワイルドカード証明書や、誤った発行申請の報告といった、より細かいレベルでのポリシーのコントロールが可能となります。
また、CTログにCAAレコード確認のアクションが記録されます。
CAAレコード確認を組み込むことになったきっかけは、近年ブラウザに埋め込められたルート証明書が60以上に増えており、それらを利用できる認証局（CA）が、ドメイン所有者の十分な承認がなくても、パブリックに信頼される証明書を発行できているためです。
そのため攻撃者は同一のFQDNについて、証明書発行依頼を多数の認証局（CA）におこない、一つの認証局（CA）でも通過すれば（サーバー運用者によるミス、認証局（CA）の検証ミスに関係なく）その証明書を攻撃の材料として利用しています。
CAAレコード確認が正しく適用されたとしても、処理は複雑なものとなります。
例えば、CAAレコードはFQDNのどのラベル名でも指定出来るため、CAAレコードが見つかるまで認証局（CA）はFQDN内ラベル名のひとつひとつをチェックします。
ラベルチェックの際の最初のレコードがポリシーをコントロールすることになるので、DNSオペレーターによりCAAポリシーを細かいレベルで適用可能となってしまいます。
FQDNの例：
[randomID].[customerID].secure.IoT.domain.com.
この場合、認証局（CA）は[randomID]からチェックを始めます。
大抵はリストにないので、customerID、secure、IoT、そしてdomainと進んでいきます。
CAAレコードが見つかった場合、初めに見つかったレコードが権限付与を決定づけます。また、DNSから応答がない場合、認証局（CA）はレコードを再度確認しないといけません。
上の例からもわかるように、名前解決できない大きなラベルがあるドメイン名にとって、CAAレコード確認を組み込むことで無駄なサイクルが生まれてしまうことになります。
CAAレコードの確認によって、ドメイン管理者は証明書発行をよりコントロールできるようになりましたが、考えるべき懸念点もあります。