編集長の佐藤（@akihirosato1975）です。
この一つ前の記事（DNS Summer Day 2017）で、DNSレコードの一つとして新たに追加される「CAA」レコードの話が出ましたが、本記事ではそれについて色々書いてみたいと思います。ただCAAレコードそのものの話は既に他のサイトでいろいろ解説が出てるので、本記事ではどちらかというと「じゃ具体的に何を設定すりゃいいのよ？」というところを中心にします。
CAAの概要
まずそもそも「CAAって何よ？」という話を簡単に。正式名称は「DNS Certification Authority Authorization」と言いまして、DNSのリソースレコードタイプの一つとして、2013年にRFC化されてます。
目的は「ドメイン所有者の方で指定した認証局（CA）以外が、勝手にSSL/TLS証明書を発行するのを防止する」というもので、具体的には「issue」「issuewild」「iodef」という3つのプロパティが定義されてます。内訳は以下の通り。（実際の書式はDNSサーバソフト等で多少異なるので、お使いの環境に合わせたドキュメントをお読みください）
・issue: 通常の証明書を発行しても良いCAを列挙する（パラメータ等の追加もOK）
・issuewild: ワイルドカード証明書を発行しても良いCAを列挙する（同上）
・iodef: 上記issue/issuewildで指定されていないCAが証明書を発行しようとした場合の通知先URL ※ただし通知は任意
当初はこのレコードを使用するかどうかはCA側の任意という話だったんですが、今年3月にCA/Browser Forumの投票があり、その結果として、今年9月8日から各CAは必ず証明書発行時にCAAレコードを（設定されていたら）参照しなければいけないことになりました。あくまでCA側に義務が課されるだけなので、各ドメインの所有者側には義務はないわけですが、今後証明書を取得する際にCAAレコードがないと証明書の発行が遅延する等の事態が起きることも考えられなくはないので、対応するに越したことはないという状況です。
ただCAAレコードに対応しているDNSサーバは比較的最近のバージョンに限られることや、クラウド型のDNSサービスではまだ未対応のところが多い（とりあえず本記事の執筆時点では、AmazonのRoute 53はまだ対応してなかった）という問題もあるので、そこまで急いで設定しないとダメというわけではなさそうです。
あと当然といえば当然ですが、CAAレコードの中身自体をMITM等で書き換えられては意味が無いので、CAAレコードの使用にあたってはDNSSECに対応していることが事実上前提になってます。今年3月の投票でも「ドメインのゾーン情報について、ICANNのルートサーバからDNSSECチェーンがつながってない」場合は、CAA情報の取得に失敗したとみなして良いとされてます。
じゃ何を設定すればいいの？
理屈は以上のとおりとして、現場としては「じゃDNSに何設定すればいいのよ？」というところの情報が欲しいわけですが、意外とこの情報がまとまってません。なので今回は、主要なCAのサイトを漁って、CAAレコードへの対応状況と「issueに何を設定すればいいのか」をまとめてみました（あくまで本記事執筆時点です。あと一応CA名のところから根拠としたドキュメントにリンク張ってみました）。
| CA名 | issue名 |
|---|---|
| Let’s Encrypt | letsencrypt.org |
| Comodo | comodoca.com |
| GeoTrust | geotrust.com |
| RapidSSL | rapidssl.com |
| Symantec | symantec.com |
| Thawte | thawte.com |
| Entrust | entrust.net |
| DigiCert | digicert.com |
残念ながら国内勢（確認したのはGMOグローバルサイン、セコムトラスト、サイバートラスト、JPRS）はまだCAAの設定情報が開示されてません（あと2ヶ月あるのでその間に出てくるとは思いますが…）。
あと海外勢でもGoDaddy(StarField)や、Amazon Trust Services（AWSのCertificate Managerで発行される証明書のCA）あたりも情報が未開示です。
DNSの設定変更ってミスるとクリティカルな事態になりやすいので、できればこの辺の情報は早めに欲しいわけですが。
今後時間があればこの辺の情報もupdateしていければと思います。