ニュースソース：CASECURITY
以下は 2017年3月21日に公開されたThe Latest on Certification Authority Authorization の「Concerns」のセクションを要約したものです。
CAA運用上の懸念
CA/ブラウザフォーラムは、2017年9月8日以降に証明書を発行するに当たってCAAレコード確認を義務付けましたが、CAAレコード確認にはいくつかの懸念点また潜在的な懸念点が存在します。
最も大きな懸念点はCAAレコードとCNAMEレコードが重なったときの明確な動作定義がないことです。
RFCのセクション4ではレコード確認がエイリアスをトレースするように記載されていますが、どのようにトレースが発生するかまでは書かれていません。
例えば、certificateAuthorityAのCAAレコードを所持しているmail.example.comに
mail.example.com CNAME secure.example.net
のレコードが作成され、example.netがcertificateAuthorityBのCAAレコードを所持している場合、どちらのCAAレコードがコントロールするか、仕様上明確ではありません。
2つ目の懸念は、CAAをサポートするソフトウェアがDNS、認証局（CA）両方において少ないことです。
CAAレコード確認の展開は、自身で自動化ツールをビルドするリソースを持たない小規模な認証局（CA）にとっては難しいことです。
CAAレコードを含むDNSレコードはとても少ないです。最近ではDNSプロバイダーがサポートを拡張して、BIND、NSD、Knot、 PowerDNSの最新版ではCAAレコードの作成が可能となっています。
CAAは拡大しているにも関わらずあまり多くは見かけず、企業にも使用されていません。設定されてない、また存在しないレコードの確認は認証局（CA）にとって時間の浪費であり、大きな負担となります。
さらに、DNSが通常の名前解決に失敗した際の問題として、稀なケースですが、認証局（CA）が確認のリトライをせずに中断して、証明書発行を遅らせてしまう可能性があります。
他の課題は、認証局（CA）が正しくレコードを確認しているかの判定です。
認証局（CA）がチェックをしているパブリックな記録は得ることができません。
最後の懸念点は、証明書オーダーの担当とDNSオペレータが異なる場合です。また、グローバルな大企業の内部で、どの認証局（CA）を使用するかのコミュニケーションが取れていない場合です。
これにより、すでにある契約の義務の制限、稼働中プロジェクトの停止、電子商取引で必要な証明書を取得できない、などの悪影響が生まれます。
CAAレコードは、それまでの組織と認証局（CA）の関係、コミュニケーションを無視し、DNS管理者が新たな交渉のために労力を要することになります。
それどころか、悪意、また不満のあるDNS管理者によってTTLレコードの値を大きく設定されたり、文字化けを入力されたりすることによって、どの認証局（CA）からもTTLが切れるまで証明書を取得できない状況が引き起こされる可能性もあります。