CAAレコードの「重複」は、多くの場合それ自体がエラーなのではなく、同じ名前に並んだ複数の行、親子の名前に分かれた設定、複数のDNSサービスの食い違いが原因で、どのCAが許可されているのか分かりにくくなっている状態です。解消するには、今の応答を全部書き出し、最終的に許可したいCAの一覧を決め、それを1か所にまとめる順で進めます。この記事では、重複のパターンの見分け方と、証明書の発行を止めずに整理する手順を説明します。
「重複」に見える4つのパターン
最初に、手元の状態がどれに当たるかを見分けます。対処が違うためです。
1. 同じ名前に複数のCAA行がある
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "pki.goog"
example.com. 3600 IN CAA 0 issue ";"同じ名前・同じ型のレコードは1つの組（RRset）として扱われ、CAはその中のどれか1行が自分を許可していれば発行できます。上の例では Let's Encrypt も Google Trust Services も発行でき、";"（許可するCAなし）の行は他の行を打ち消しません。「全面禁止のつもりで ";" を足したのに発行される」「1行足したら他のCAが使えなくなると思っていた」という誤解の多くはここから来ます。複数行があること自体は正常で、整理の目的は「意図と合っているか」を確かめることです。
まったく同じ内容の行が2つ見える場合、DNSの仕組み上、同一のレコードは1つにまとめられるのが普通です。管理画面に2行表示されているのに dig では1行しか返らないなら、管理画面側の表示上の重複と考えられます。
2. 親と子の名前の両方にCAAがある
example.com と www.example.com の両方にCAAがあると、www の証明書には www 側だけが使われます。CAAは名前から親へさかのぼって最初に見つかった組だけを使うため、親子の設定は合算されません。親で3つのCAを許可していても、子に1つしか書かなければ、子の名前で使えるのは1つだけです。
3. DNSサービスやサーバーによって値が違う
権威DNSを複数のサービスで運用している場合や、セカンダリDNSへの転送が止まっている場合、問い合わせ先によって別のCAAが返ります。CAがどのサーバーに問い合わせるかは選べないため、発行が成功したり失敗したりします。
4. DNSサービスが自動でCAAを足している
CDNやDNSサービスの中には、自社の証明書発行に必要なCAAを自動で追加するものがあります。たとえば Cloudflare は、利用者がCAAを設定すると、自社の証明書に使うCAの行を自動で加える仕組みを案内しています（2026年10月現在。対象のCAや表示のされ方は変わることがあります）。管理画面に無い行が dig に出るときは、このパターンを疑います。自動で足された行を消すと、サービス側の証明書の更新が止まるおそれがあるため、各サービスのドキュメントを確認してから判断します。
ステップ1：現状をすべて書き出す
証明書に載せている名前（example.com、www.example.com、ワイルドカード、サブドメイン）ごとに、権威DNSへ直接問い合わせます。
for name in example.com www.example.com shop.example.com; do
for ns in $(dig +short NS example.com); do
echo "== $name @ $ns"
dig @"$ns" +norecurse +noall +answer "$name" CAA
done
done結果は表計算などに「名前・サーバー・タグ・値」の形で写しておくと、比較が楽になります。あわせて、www などがCNAMEになっていないかも確認します。CNAMEの名前のCAAはCNAMEの先で決まるため、自分のゾーンでは整理できない場合があります。
次に、いま実際に使っている証明書の発行元を確かめます。
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
| openssl x509 -noout -issuerサーバーが複数あるなら、それぞれで確認します。メインサイトは Let's Encrypt、ロードバランサーはクラウドの証明書サービス、というように、名前によって発行元が違うことはよくあります。
ステップ2：許可したいCAの一覧を決める
書き出した内容から、名前ごとに「今使っているCA」「近く使う予定のCA」を決めます。使っていないCAの行は、残しても発行には害がありませんが、許可範囲が広いままになるので整理の対象です。
決めるときの目安は次のとおりです。
- 今の証明書の発行元と、自動更新で使うCAは残す
- CDNやロードバランサーなど、サービス側で証明書を出しているCAは残す（識別子は各サービスの資料で確認）
- 乗り換えが済んで不要になったCAは削除候補にする
- ワイルドカードを使うなら
issuewildの扱いも決める（issuewildがあると、ワイルドカードにはそちらが優先される）
方針として、CAAはできるだけ親（example.com）に集め、子の名前には置かないのが管理しやすい形です。子に別の許可が本当に必要なときだけ、子に「必要なCAをすべて」書きます。
ステップ3：追加してから削除する順で直す
整理の途中で発行可能なCAがゼロになる時間を作らないよう、次の順で変更します。作業前に、DNSの管理画面のエクスポートやゾーンファイルのコピーでバックアップを取っておきます。
- CAAのTTLを確認し、長ければ短くしておく（変更後の反映待ちを短くするため）
- 親の名前に、決めた一覧どおりの
issue/issuewild/iodefをそろえる - 子の名前にあるCAAのうち、親と同じ内容のものを削除する
- 権威DNSサーバーごとに、ステップ1と同じコマンドで応答が一致したかを確認する
- 不要になったCAの行を削除する
- 証明書の更新テストを行う
BINDなどゾーンファイルで管理している場合は、編集後にSOAのシリアル番号を上げ、構文を確認してから読み込みます。
named-checkzone example.com /var/named/example.com.zone
sudo rndc reload example.com複数のDNSサービスで運用している場合は、すべてのサービスに同じ変更を入れます。片方だけ直すとパターン3の状態が続きます。
ステップ4：発行できるかを確かめる
最後に、実際のCAで判定させます。Let's Encrypt なら、certbot の --dry-run でステージング環境に発行を試せます。
sudo certbot renew --dry-runクラウドの証明書サービスやCDNの証明書は、管理画面で証明書の状態や次回更新の予定を確認し、更新時期が近ければ注意して見ておきます。CAAの確認は発行の直前にも行われるため、整理した直後の数日は、更新の通知やログに気を配ってください。
つまずきやすい点
- **
";"を足しても禁止にならない**: 同じ組に他のissue行があれば、そちらが有効です。発行を全面的に止めたいなら、その名前のissueを";"の1行だけにします。 - 管理画面とdigの結果が合わない: 自動追加の行か、別のDNSサービスの応答を見ている可能性があります。
dig +short NS example.comで、実際に委任されているネームサーバーを先に確かめます。 - 子のCAAを消したら発行できなくなった: 親のCAAに、その子で使うCAが入っていなかった状態です。親に追加します。
- 識別子の違い: 同じ会社でも、ブランドや製品によって識別子が複数あることがあります。CAの公式ドキュメントで確かめてください。
まとめ
- 同じ名前の複数行は「どれか1行が許可すれば発行できる」組として扱われ、それ自体は正常
- 親子の名前のCAAは合算されず、近いほうだけが使われる
- 権威DNSサーバーごと・名前ごとに応答を書き出し、今の証明書の発行元と照らし合わせる
- CAAはなるべく親に集め、追加してから削除する順で直す
- 最後に
certbot --dry-runなどで発行を試し、更新時期のログを見守る