2026年6月17日
CAA レコードは「どの認証局が証明書を発行してよいか」を DNS で宣言する仕組みで、DNSSEC はその応答が改ざんされていないことを保証する仕組みです。併用すると、認証局が受け取る CAA の内容を偽装されにくくなり、ACME アカウントや認証方式まで絞り込む CAA の拡張（RFC 8657 の accounturi・validationmethods）を実質的な防御として使えるようになります。この記事では、CAA を書く、ゾーンを署名する、拡張で絞り込む、の順に設定し、各段階で何を確かめるかを説明します。
一方で、DNSSEC を有効にすると、署名の不備が証明書の発行停止に直結します。その運用上の注意もあわせて扱います。
併用すると何が変わるのか
認証局は証明書を発行する直前に、対象のドメインの CAA を DNS で問い合わせます。このとき、次のような違いが生まれます。
- DNSSEC なし：CAA の応答は途中で書き換えられる可能性があります。また、CA/ブラウザフォーラムの Baseline Requirements では、一定の条件のもとで CAA の問い合わせが失敗したときに発行を認める余地があり、その条件の1つが「ゾーンに DNSSEC の信頼の連鎖が無いこと」です。
- DNSSEC あり：認証局が検証を行えば、改ざんされた CAA は検証に失敗します。問い合わせの失敗を発行許可として扱う余地もなくなり、CAA が読めない状態では発行が止まる方向に働きます。
さらに、CA/ブラウザフォーラムでは、DNSSEC が有効なドメインについて、CAA の確認やドメイン認証の問い合わせで DNSSEC の検証を求める方向の改定が進められてきました（2026年10月現在）。適用の時期や範囲は最新の Baseline Requirements と各認証局の告知で確認してください。
つまり、DNSSEC は CAA の「書いた内容が認証局に正しく届く」ことを支え、CAA は「誰が発行できるか」を決めます。片方だけでは守れない部分を補い合う関係です。
手順1：署名する前に CAA を書いて発行を確かめる
先に CAA だけを設定し、証明書の発行や更新が問題なく通ることを確かめます。DNSSEC と同時に始めると、発行が止まったときにどちらが原因か分からなくなるためです。
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"1行目で Let's Encrypt に発行を許可し、2行目でワイルドカード証明書の発行を禁止し、3行目で違反の報告先を示しています。CAA はサブドメインに無ければ親をたどって適用されるため、この例では www.example.com などにも同じ制限がかかります。他の認証局から証明書を受け取っているサービス（CDN、メール配信、SaaS の独自ドメイン機能など）がある場合は、その認証局も issue に加えておきます。
dig +short CAA example.com登録した内容が返ることを確かめたら、次回の更新、または手動の発行で問題が無いことを確認します。
手順2：ゾーンを署名し、CAA に署名が付くことを確かめる
DNS サービスでゾーンの署名を有効にし、示された DS をレジストラに登録します。署名が有効になったら、CAA に RRSIG が付いて返ることを確かめます。
# CAA とその署名（RRSIG CAA）が返るか
dig CAA example.com +dnssec
# 検証を行うリゾルバーで、ad フラグが付くか
dig CAA example.com @9.9.9.9 +dnssec
# BIND 付属の delv で信頼の連鎖をたどって検証する
delv CAA example.comdelv の出力に fully validated と表示されれば、ルートから CAA の署名までの連鎖が通っています。dig で +cd を付けたときだけ引ける場合は、検証に失敗しています。この状態では、認証局も CAA を読めず、発行が止まる可能性があります。DS と DNSKEY の対応や署名の期限を確かめてから先へ進みます。
CDN などで CNAME をたどる構成では、認証局は CNAME の先でも CAA を探す場合があります。CNAME の先のゾーンが署名されていない、あるいは別の事業者が管理している場合の扱いも、念のため確かめておきます。
手順3：accounturi と validationmethods で絞り込む
RFC 8657 では、CAA の issue に次のパラメーターを付けられます。対応しているかは認証局ごとに異なりますが、Let's Encrypt は両方に対応しています。
- accounturi：発行を依頼できる ACME アカウントを、アカウントの URI で限定します。
- validationmethods：ドメインの認証に使える方式（
http-01・dns-01・tls-alpn-01）を限定します。
example.com. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"これにより、同じ Let's Encrypt でも、自分のサーバーのアカウント以外からの発行依頼や、指定外の認証方式による発行は拒否されます。Web サーバーへの一時的な侵入や、HTTP の経路の乗っ取りで証明書を取られる危険を小さくできます。
アカウントの URI は ACME クライアントの保存データから確認します。certbot の場合は、新しい版で certbot show_account コマンドが使えるほか、/etc/letsencrypt/accounts/ 配下の regr.json に記録されています。表示の形式は版によって異なります。
設定するときの注意点は次のとおりです。
- アカウントが複数ある場合：サーバーごとに ACME アカウントが違うなら、
issueの行をアカウントごとに分けて並べます。複数のissueは、いずれかに当てはまれば許可されます。 - ステージング環境での試験：certbot の
--dry-runは Let's Encrypt のステージング環境と、本番とは別のアカウントを使います。本番のアカウントだけに絞ると、試験の更新が CAA で拒否される場合があります。試験の結果だけで判断せず、拒否の理由を出力で確かめてください。 - アカウント鍵の更新：ACME のアカウント鍵を入れ替えてもアカウントの URI は変わりませんが、アカウントを作り直すと URI が変わります。サーバーを移設してアカウントを新しく作るときは、先に CAA に新しい URI を追加します。
運用で気をつけること
DNSSEC と CAA の併用で最も避けたいのは、署名の不備で証明書の更新が止まり、期限切れに気づかないことです。次の点を運用に組み込みます。
- 署名の期限を監視する：自前で署名している場合は、RRSIG の期限が近づいていないかを定期的に確かめます。DNS サービスに任せている場合も、鍵の更新や DS の差し替えの時期を把握しておきます。
- CAA の変化を監視する：期待する内容と違えば知らせる仕組みを用意します。
#!/bin/bash
# caa-check.sh: 検証付きで CAA を確かめる（例。期待値は自分の設定に合わせる）
expected='0 issue "letsencrypt.org'
out=$(delv CAA example.com 2>&1)
echo "$out" | grep -q "fully validated" || { echo "DNSSEC validation failed"; exit 1; }
echo "$out" | grep -qF "$expected" || { echo "CAA mismatch"; exit 1; }
echo "ok"- 証明書の期限も別に監視する：CAA や DNSSEC の不備は、更新が失敗して初めて表面化します。証明書の残り日数を外部から監視しておけば、原因が DNS 側でも早く気づけます。
- 変更前にバックアップを取る：CAA や DNSSEC の設定を変える前に、ゾーンの内容を書き出して保存し、可能ならステージング用のドメインで同じ手順を試してから本番に反映します。
まとめ
- DNSSEC は CAA の応答が改ざんされていないことを保証し、CAA は発行できる認証局を決める。併用で互いの弱点を補える。
- 先に CAA だけで発行を確かめ、その後にゾーンを署名して、CAA に RRSIG が付き検証が通ることを delv などで確かめる。
- accounturi と validationmethods を使うと、ACME アカウントと認証方式まで絞り込める。アカウントが複数ある場合や dry-run の扱いに注意する。
- DNSSEC の不備は発行停止に直結するため、署名の期限・CAA の内容・証明書の期限を監視する。
- Baseline Requirements の改定は進んでいるため、適用範囲は最新の文書と認証局の告知で確かめる。