CAAレコードの検証手順｜digでの確認から証明書発行前のテストまで

CAAレコードが意図どおりに働いているかは、「どの名前のCAAが実際に使われるか」を dig で確かめ、権威DNSサーバーごとの応答をそろえ、最後に認証局のテスト環境で発行を試す、の3段階で検証できます。CAAは設定画面で値を入れただけでは正しさが分からず、証明書の更新日になって初めて失敗に気づくことが多いレコードです。この記事では、CAAの評価のされ方を押さえたうえで、検証の手順と、失敗したときの読み方を説明します。

CAAレコードはどう評価されるか

CAA（Certification Authority Authorization）は、そのドメインの証明書をどの認証局（CA）が発行してよいかを宣言するレコードです。仕様はRFC 8659で定められており、公的に信頼されたCAは発行前にCAAを確認することが業界ルールで求められています。

検証で大事なのは、CAが次の順にCAAを探すという点です。

1. 証明書に載せる名前そのもの（例: www.example.com）のCAAを問い合わせる
2. 見つからなければ親の名前（example.com）へ1階層ずつさかのぼる
3. 最初に見つかったCAAの組（RRset）だけを使い、それより上は見ない
4. どこにもCAAが無ければ、どのCAでも発行できる

つまり www.example.com にCAAを1件でも置くと、example.com 側のCAAは www には効かなくなります。設定は「足し算」ではなく「近いほうで上書き」です。また、名前がCNAMEになっている場合は、問い合わせはCNAMEの先をたどって行われます。CDNを使っていて www がCNAMEのときは、CDN側のドメインにCAAがあるかどうかで結果が変わることがあります。

よく使うタグは次の3つです。

• issue: 通常の証明書を発行してよいCA
• issuewild: ワイルドカード証明書を発行してよいCA（あれば issue より優先）
• iodef: ポリシー違反の依頼があったときの連絡先（対応するかはCAしだい）

値に書くCAの識別子は各CAが公開しています。Let's Encrypt は letsencrypt.org です。ほかのCAやクラウドの証明書サービスは複数の識別子を使う場合があるため、各CAの公式ドキュメントで確かめてください（2026年10月現在も、識別子が追加・変更されることがあります）。

ステップ1：証明書に載せる名前を洗い出す

最初に、検証の対象を決めます。今の証明書に含まれる名前は次のコマンドで分かります。

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

example.com と www.example.com のほか、*.example.com のようなワイルドカードや、ステージング用のサブドメインが入っていることがあります。ワイルドカードは issuewild の対象、それ以外は issue の対象として、名前ごとに検証します。

ステップ2：名前ごとに実際に効くCAAを確かめる

名前ごとに、自分の名前から親へ順に問い合わせます。

dig +short www.example.com CAA
dig +short example.com CAA

www.example.com で何も返らず、example.com で次のように返れば、www にも example.com のCAAが適用されます。

0 issue "letsencrypt.org"
0 issuewild ";"
0 iodef "mailto:security@example.com"

この例では、通常の証明書は Let's Encrypt だけが発行でき、ワイルドカードはどのCAも発行できません（";" は「許可するCAなし」の意味）。読むときは次の点を確認します。

• 使っている（または移行予定の）CAの識別子が issue に入っているか
• ワイルドカードを使うなら、issuewild があるときにそのCAが入っているか
• 先頭の数字（フラグ）が 0 か。128 は「理解できないタグがあれば発行しない」という意味で、意図せず付けると発行を止めることがあります
• 識別子の綴り（letsencrypt.org を letsencrypt.com にするなど）や、引用符の抜けが無いか

サブドメインを別のDNSに委任している場合や、www がCNAMEの場合は、dig www.example.com CAA の応答（ANSWERセクション）にCNAMEが含まれていないかも見てください。

ステップ3：権威DNSサーバーごとに応答をそろえる

キャッシュDNS経由の結果だけでは、変更が反映済みか、全サーバーで同じかが分かりません。ネームサーバーを調べ、1台ずつ直接問い合わせます。

for ns in $(dig +short NS example.com); do
  echo "== $ns"
  dig @"$ns" +short +norecurse example.com CAA
done

すべてのサーバーが同じ値を返すことを確認します。1台だけ古い値を返す場合は、セカンダリDNSへのゾーン転送が止まっているか、複数のDNSサービスに別々に登録していることが考えられます。

あわせて、応答のステータスも見ます。

dig @ns1.example.net example.com CAA | grep status

NOERROR で値が返る、または NOERROR で値が空（CAAなし）なら正常です。SERVFAIL やタイムアウトはCAAの有無以前の問題で、CAによっては「確認できない」として発行を拒否します。古いDNSソフトウェアや一部の簡易DNSは、CAAのような比較的新しいレコード型の問い合わせにエラーを返すことがあるため、ここで見つけておく価値があります。DNSSECを使っているゾーンでは、署名の問題でも SERVFAIL になります。

ステップ4：発行前にテスト環境で試す

dig で問題が無さそうでも、最終的にはCA自身の判定で確かめるのがいちばん確かです。Let's Encrypt と certbot を使っている場合、--dry-run はステージング環境で発行を試し、本番の証明書には触れません。ステージングでもCAAは確認されます。

# 既存の証明書の更新をテスト
sudo certbot renew --dry-run

# 新しい名前を追加する前のテスト
sudo certbot certonly --dry-run --webroot -w /var/www/html -d example.com -d www.example.com

CAAが発行を止めている場合、エラーメッセージには「CAA record for 名前 prevents issuance」のような文言が含まれます。どの名前で止まったかが書かれているので、その名前からステップ2をやり直します。

他のCAを使う場合は、そのCAの管理画面や事前チェックの機能を使います。CAAの確認は申請時だけでなく発行直前にも行われるため、申請後にCAAを変えると発行に影響する点に注意してください。

検証で見つかりやすい問題と直し方

可能性の高い順に並べます。

1. CAを乗り換えたのにCAAが古いまま: 新しいCAの識別子を issue に追加します。旧CAの行は、新しい証明書が問題なく発行・配置できたのを確かめてから消します。
2. サブドメインにだけCAAを置いて親の許可が消えた: サブドメイン側のCAAにも必要なCAをすべて書くか、サブドメイン側のCAAを消して親の設定に任せます。
3. ワイルドカードだけ失敗する: issuewild があり、そこに使うCAが入っていない状態です。issuewild を追加・修正します。
4. DNSサーバーごとに値が違う: 権威DNSの構成を見直し、ゾーンの更新が全台に届くようにします。
5. CAA問い合わせ自体が失敗する: DNSサービスやソフトウェアの対応状況を確認し、必要なら移行を検討します。

変更する前にTTLを確認しておくと、反映待ちの時間を見積もれます。値を変えた直後はキャッシュDNSに古い応答が残るため、検証は権威DNSへの直接の問い合わせで行い、CAでのテストはTTLが切れた後に行うと混乱が減ります。

より踏み込んだ設定

RFC 8657 では、issue の値にパラメーターを付けて、許可する検証方法やACMEアカウントを絞り込めます。

0 issue "letsencrypt.org; validationmethods=dns-01"
0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789"

Let's Encrypt はこれらのパラメーターに対応していますが、CAによって対応状況は異なります。accounturi はアカウントを作り直すと発行できなくなるため、運用手順に組み込めるときだけ使うのが無難です。導入する場合も、ステップ4のテストを先に行ってください。

まとめ

• CAAは名前から親へさかのぼって探され、最初に見つかったものだけが使われる
• 証明書に載る名前ごとに dig で実際に効くCAAを確かめる
• 権威DNSサーバーを1台ずつ問い合わせ、値とステータス（SERVFAIL が無いか）をそろえる
• 最終確認は certbot --dry-run などCAのテスト環境で行う
• CAの乗り換えは「新CAを追加、発行を確認、旧CAを削除」の順に進める

• Let's Encrypt の証明書を自動更新する設定と確認方法
• digコマンドでDNSレコードを調査する方法