CAAとは
CAA（Certification Authority Authorization）とはドメインの所有者が自身のドメインに対する証明書の発行ができるCAを制御するための仕組みです。具体的にはDNSのCAA RR（CAA リソースレコード）を使用して制御します。
CAAは2019年に公開されたRFC8659で記述されます。
ところで、原著では「CAAは証明書発行過程での検証への攻撃に対する 縦深防御（defense-in-depth）を意図して導入されました」 、とあります。 defense-in-depthは軍事用語なのですが、ITでは「多層防御」の訳を当てる事があるがこれは正しくない、と記載されています。 縦深防御は、前線が攻撃側に突破されることを前提にあらかじめ後方にも防御のためのリソースを配置する事、それによって敵攻撃の進行を遅らせる、反撃を可能とすることを意図したもの、対して「多層防御（multi-layered defense）とは単純に複数の防御層を設けるもの」で別な概念です、と書かれており妙に納得しました。
DNS CAAレコード の概要
ドメイン名の所有者はDNSのCAAレコード（CAA RR）を使用して証明書発行に関するポリシーを配布する事が出来ます。 CAAレコードは属性を表すタグとCAへの指示で構成されています。
CAAレコード issue タグ
特定のホストに対して証明書の発行を許可するCAのドメイン名を指定します。
certs.mydomain.com CAA 0 issue "letsencrypt.org"
複数のCAに対して証明書発行を許可する場合、複数の issue タグを作成することも可能です。
**CA名（CAのドメイン名）を指定せずにCAAレコードを作成すると、そのホスト名（（サブ）ドメイン名）に対する証明書の発行を禁止できます。
nocerts.mydomain.com CAA 0 issue ";"
CAAの照会は、対象FQDNからDNS名の階層を上へたどり、最初に見つかったCAAレコードの指定が有効になります。たとえばsub1.certs.mydomain.comのCAAを探す例では、まずsub1.certs.mydomain.comにCAAレコードの指定を探します。CAAレコードが見つからなかった場合は一つ上のcerts.mydomain.comのCAAレコードを探します。このFQDNにSAAレコードが見つかった場合、そのサブドメインであるsub1.certs.mydomain.comにもこの指定が適用されます。
また、ワイルドカード証明書だけに関係する issuewild という指定も可能です。issueタグと両方が見つかった場合はissueタグの指定が優先されます。
sub1.certs.mydomain.com CAA 0 issuewild "letsencrypt.org"
こちらのサイトが分かりやすいと思いますのでご紹介します。
ファネルAi CAAレコードとは？SSL証明書の発行先を制限するDNS設定と変更管理
CAにCAAレコードに反する証明書の発行リクエストがあった際、CAからドメイン名の保持者への連絡先を設定するタグがiodefです。
mydomain.com IN CAA 0 iodef "mailto:security@mydomain.com"
mydomain.com IN CAA 0 iodef "https://www.mydomain.com/"
上記の例ではメールとRID（Real-time Inter-network Defense）メッセージをHTTPS(TLS)でリアルタイム通知する方法の2つが指定されています。
CAAの普及経緯
CAAが実際的に有効となるには対応するCAが増えないといけません。さもないと攻撃者はCAA未対応のCAから偽の証明書を容易に?入手できるパスが残ることになります。
CAAは2017年3月 CA/Browserフォーラムの投票で同フォーラムに準拠するCAに対して必須になり2017年9月から必須になりました。CAAはDNSの新しいリソースレコードを利用するためDNSのソフトウェアが対応する必要もあり普及に時間を要したようです。
原著でも記載のある参考サイトから引用しますと、
SSL Mate : Who Supports CAA Records?
DNSについては、
メジャーなDNSは殆ど対応できているようです。
プロバイダーについては、
全部は引用しませんが目視で掲載の八割くらいはサポートOK、エラーや値を返さないなど非対応と思われるサイトが残り、という感じです。
原著ではDNSのCAAレコードを生成するツールとして SSL Mate の CAA レコードジェネレーターも紹介しています。これを使えばせってみすの可能性を減らせる、としています。
SSL Mate : CAA Record Generator
CAAではDNSSECの利用が強く推奨されています。DNSSECが無い状態ではCAがDNSスプーフィング攻撃への特別な対策が必要になります。具体的にはDNSの動作を測定するvantage pointというサーバーを複数用意しCAAレコードを確認する必要があります。
DNSSECを使用すれば「CAAの指示がドメインの所有者によって提示されたものであることを有効なデジタル証明書によって証明可能になる」ので監査実装が容易になります。
また、DNSSECを使用しない場合は、CAがCAAレコードをDNS検索して失敗した場合、1回以上再試行して証明書を発行してよいことになっていますが、DNSSEC使用時はCAAレコードの検索が失敗すると証明書は発行されなくなります。
CAA拡張
CAAは将来の拡張に備えて新しいタグを定義できまず。また既存の標準的なタグを拡張することも可能です。拡張されたタグにCAが対応していないケースを想定して、CAAレコードには critical フラグを追加することもできます。X.509での証明書の拡張と同様にCAAレコードが critical のフラグがある場合、そのタグは必ず評価しなければならず、もし未知のタグだった場合は証明書を発行してはいけない、としています。これらの拡張もCA/Browser FOrumのBaseline Requirements に規定されています。
CAAレコードの拡張の例
連絡先に関するCAAタグの拡張
証明書の発行に関する問題についてのドメイン所有者の連絡先をメールアドレス contactmail タグで、 電話場号 contactphone タグで指定できます。この拡張はWHOISデータベースからドメイン所有者の情報が削除されたことに対応して拡張されました。
※WHOISデータベースからのドメイン所有者情報削除は、2018年 EUのGDPR（一般データ保護規則）の規定に伴い実施されました。
accounturl と validationmethods
この2つはACME Working Groupによって規定されました。（issueタグ、issuewildタグに追加されました。）
accounturlパラメーターは例えばある企業全体であるCAを利用していて、その下の特定の部門に対して証明書を発行させたくない場合に利用できます。
validationmethodsパラメーターは証明書の検証手段を制限する目的で導入されました。こちらはACME(Automated Certificate management Environment)で利用されます。
CAA導入の考慮点について
CAAが稼働すると、即座に許可されないCAが証明書を発行をできなくなります。本来想定されていないルートではあるが必要な証明書が発行されていた場合などに問題になる可能性があるため、CAAの導入は段階的に行うべきです。
一例を紹介しますと、
1.現行の証明書の発行状況を確認する。
ドメイン、サブドメインなど管理単位にどのCAから証明書が発行されているかリストを作成する。
2.証明書の発行を許可するCAの一覧を作成する
組織にとって最重要な証明書の発行は複数のCAとすること。（何らかのトラブルが生じた際の代替を用意しておく）
3.テスト用のサブドメインを作成（決定）しCAAを試行する
実際に本番導入用と同様なCAAの設定を行い証明書発行を要求して動作を確認する。問題が無ければ次に進みます。
4.CAA移行の通知を実施する
基本的には自社サイドで証明書発行に関わる方々が対象だと思われますが、社外（外部）に証明書発行関連業務を依存している場合は社外にも通達対象があるかもしれません。
5.CAA移行を実施する
何らかの問題が発生した時を考慮してロールバックプランも準備しておく
CAAの普及状況について
CAAは証明書の発行をドメイン所有者の側に引き戻すことができます。ドメイン名に対する攻撃もCAAポリシーで許可したCAのみが考慮対象とできるメリットもあります。原著では執筆時点においてもCAAは有益な機能としてみなされ普及が始まっている、としています。原著では執筆時点でのCAAの課題点を以下の様に記載しています。