CAA レコードとは — 証明書を発行できる認証局を制限する
CAA レコードは、そのドメインの TLS 証明書を発行してよい認証局（CA）を DNS で宣言する仕組みです。認証局は Baseline Requirements により、証明書を発行する前に対象ドメインの CAA を必ず確認する義務があり、許可されていない CA は発行を拒否します。設定すれば、許可外の CA が勝手に証明書を出す誤発行のリスクを下げられます。
CAA レコードとは何ですか？
CAA（Certification Authority Authorization）レコードは、そのドメインの TLS 証明書を発行してよい認証局（CA）を DNS で宣言する仕組みです。ドメイン所有者が「この CA にだけ発行を許す」と表明でき、認証局は発行前にこれを確認します。許可リストに載っていない CA は証明書を発行できなくなり、第三者による勝手な発行を防ぎます。
Web サイトを HTTPS で配信するには TLS 証明書が要り、その証明書は認証局（CA）が発行します。ところが仕組みのうえでは、世界中のどの CA も、原理的にはどのドメインの証明書でも発行できてしまいます。CAA（Certification Authority Authorization）は、この「誰でも出せる」状態に歯止めをかけるための DNS レコードです。 ドメイン所有者が「うちの証明書を出してよいのはこの CA だけ」と DNS 上で宣言しておく、いわば発行元の指名リストにあたります。
CAA は DNS レコードの一種なので、A レコードや MX レコードと同じくドメインの権威 DNS に登録します。 証明書そのものに埋め込まれる値ではなく、あくまでドメイン側が持つ宣言である点が重要です。 SPF・DMARC が メールの正当性を DNS で宣言するのと同じ発想で、CAA は証明書の正当な発行元を DNS で宣言します。
CAA はどのように機能しますか？
認証局が証明書を発行する直前に、対象ドメインの CAA レコードを DNS で問い合わせ、自分が許可されているかを確認します。これは業界標準の Baseline Requirements で義務づけられた手順で、許可されていなければ発行を中止します。つまり CAA は「発行の関門」であり、正しく設定した CA だけが証明書を出せる状態を作ります。
発行の流れはこうです。あなたが CA に「example.com の証明書がほしい」と申し込むと、CA は発行処理に入る直前に対象ドメインの CAA レコードを DNS で問い合わせます。そこに自分（その CA）を許可する記述があれば発行を進め、 無ければ発行を中止します。これは CA が任意で行う親切ではなく、CA/Browser Forum の Baseline Requirements で全 CA に義務づけられた手順です。 つまり公的に信頼される CA であれば、必ずこのチェックを通ります。
チェックは申し込まれたドメインだけでなく、レコードが見つかるまで上位のドメインへさかのぼって探索されます。www.example.com に CAA が無ければ example.com を、それも無ければさらに上位を確認する、という具合です。 そのため、多くの場合はドメイン頂点（apex）に 1 組の CAA を置けば、サブドメインにも同じ方針が及びます。
書式と issue・issuewild・iodef タグの意味は？
CAA は「フラグ・タグ・値」の 3 要素で書きます。issue タグは通常の証明書を発行してよい CA を、issuewild はワイルドカード証明書専用の CA を、iodef は違反を検知したときの報告先 URL を指定します。値には許可する CA のドメイン名を書き、たとえば issue に letsencrypt.org を指定します。
CAA レコードは フラグ・タグ・値 の 3 つの部分でできています。最初の数字がフラグで、通常は0 を使います。次がタグ（issue / issuewild / iodef）、最後が値（許可する CA のドメイン名や、報告先の URL）です。タグごとの役割を整理すると次のとおりです。
| タグ | 対象 | 値の例 |
|---|---|---|
issue | 通常証明書を発行してよい CA を指定 | issue "letsencrypt.org" |
issuewild | ワイルドカード証明書専用の許可 | issuewild "digicert.com" |
iodef | 違反検知時の報告先（URL / mailto） | iodef "mailto:sec@example.com" |
; 通常の証明書は Let's Encrypt にのみ発行を許可
example.com. IN CAA 0 issue "letsencrypt.org"
; ワイルドカード証明書は DigiCert にのみ許可
example.com. IN CAA 0 issuewild "digicert.com"
; 違反（許可外 CA の発行試行）を検知したら報告を受け取る
example.com. IN CAA 0 iodef "mailto:security@example.com"値に書く CA のドメイン名は、証明書サービスの URL ではなく各 CA が公式に指定している識別子を使います。 Let's Encrypt なら letsencrypt.org、DigiCert なら digicert.com といった具合で、正しい値は各 CA のドキュメントに書かれています。issuewild を書かなかった場合、ワイルドカード証明書の可否は issue の設定に従います。一方 issuewild を書くと、 ワイルドカードについては issue より issuewild が優先される点に注意してください。
すべての CA に発行を禁止するにはどう書きますか？
値をセミコロンだけにした issue のレコードを書くと、「どの認証局にも発行を許可しない」という意味になります。証明書を一切発行しないドメイン（メール専用やリダイレクト専用など）で有効です。逆に CAA レコードが 1 つも無い場合は制限なしと解釈され、どの CA も発行できる状態になる点に注意してください。
証明書をまったく発行しないドメインもあります。メール受信専用のドメインや、別ドメインへ 301 リダイレクトするだけのドメインなどです。 そうしたドメインでは、どの CA にも発行を許可しないと明示できます。書き方は、値を セミコロンだけにした issue レコードです。
; どの認証局にも発行を許可しない
; 証明書を一切出さないドメイン（メール専用・リダイレクト専用など）向け
example.com. IN CAA 0 issue ";"ここで取り違えやすいのが、「CAA を置かないこと」と「全 CA を禁止すること」はまったく違うという点です。 CAA レコードが 1 つも無いドメインは、RFC 上「制限なし」と解釈され、どの CA でも発行できる状態になります。 「何も設定していない＝安全」ではなく、「何も設定していない＝全許可」なのです。
| 設定状態 | 意味 | 発行できる CA |
|---|---|---|
| CAA レコードが無い | 制限なし（既定） | どの CA でも発行できる |
issue "letsencrypt.org" | 指定 CA のみ許可 | Let's Encrypt だけ |
issue ";" | 全面禁止 | どの CA も発行できない |
CAA は誤発行をどう防ぎますか？
許可した CA 以外は証明書を発行できなくなるため、第三者や不正な相手が勝手に証明書を取得する誤発行のリスクを下げられます。かつては認証局の設定ミスや検証の甘さで、無関係な相手にドメインの証明書が出てしまう事故がありました。CAA で発行元を絞り込めば、そうした攻撃の余地を狭められます。
CAA の狙いは誤発行（mis-issuance）の抑止です。証明書は「このサーバは確かに example.com である」と利用者に信じさせる土台なので、 もし攻撃者が正規の手続きを装って example.com の証明書を手に入れてしまえば、偽サイトを本物同然に見せかけられます。 過去には、CA 側の検証の甘さや設定ミスによって、ドメイン所有者と無関係な相手に証明書が出てしまう事故が実際に起きてきました。
CAA を設定しておけば、たとえ攻撃者が別の CA に申し込んだとしても、その CA は発行前に CAA を確認し、許可リストに載っていないため発行を拒否します。攻撃者が使える CA の選択肢をあなたが指定した数社に絞り込めるので、 突破のために乗り越えるべき壁が増えます。もちろん CAA は万能ではありませんが、低コストで攻撃面を確実に狭められる対策です。
さらに堅くしたい場合は、DNS 応答そのものの改ざんを防ぐ DNSSEC と組み合わせます。CAA は DNS レコードなので、 DNS 応答が偽装されれば許可リストごとすり替えられる余地が理論上残ります。DNSSEC で応答の真正性を保証すれば、CAA チェックの信頼性そのものが底上げされます。
CAA を設定するときの注意点は？
CAA は証明書の発行時にだけチェックされる仕組みで、ブラウザは接続時の検証に一切使いません。すでに発行済みの証明書にも影響しません。最大の注意点は、実際に使っている CA を許可し忘れると、次回の証明書更新で発行に失敗しサイトが止まりうることです。設定変更後は更新が通るか必ず確認してください。
CAA の性質から、実務では次の 3 点を必ず押さえてください。いずれも「知らずに設定すると事故になる」種類の注意点です。
- 発行時にしか効かない — CAA は CA が発行する瞬間だけ参照されます。すでに発行済みの証明書には一切影響しません。 後から CAA を厳しくしても、既存の証明書は有効期限まで生き続けます。
- ブラウザは CAA を見ない — 利用者の接続時、ブラウザは証明書の有効性は検証しますが、CAA は確認しません。 CAA はあくまで「発行を絞る」対策であって、「不正な証明書での接続を止める」対策ではありません。
- 許可漏れで更新に失敗する — 最も多い事故です。実際に使っている CA を許可リストに入れ忘れると、次回の証明書更新（自動更新を含む）で発行が拒否され、失効後にサイトが「保護されていない接続」になってしまいます。
自分のドメインの CAA をどう確認しますか？
dig や nslookup で CAA レコードタイプを問い合わせれば、現在の設定を確認できます。dig CAA example.com のように種別を指定するだけです。オンラインの DNS 参照ツールでも確認できます。設定後は、許可した CA が実際に発行・更新できるところまで確かめると、許可漏れによる更新失敗を未然に防げます。
現在の CAA 設定は、コマンドラインの dig や nslookup で確認できます。レコード種別に CAA を指定して問い合わせるだけです。 出力が空であれば、そのドメインに CAA は設定されていない（＝どの CA でも発行できる状態）ということです。
# dig で CAA を確認する
dig CAA example.com +short
# → 0 issue "letsencrypt.org"
# nslookup の場合（種別に CAA を指定）
nslookup -type=CAA example.com確認は「レコードが存在するか」だけでなく、実際に使っている CA が許可されているかまで見てください。 機械的に分かるのは書式の正しさとレコードの有無までで、「許可すべき CA を過不足なく書けているか」は運用者にしか判断できません。 設定を変えたあとは、証明書の更新が通ることを確かめ、あわせて セキュリティヘッダや 常時 SSL 化の状態も点検しておくと、証明書まわりの守りを一通り固められます。