CAAレコードとDSレコードは同時に使えますし、組み合わせると「この認証局だけが証明書を発行できる」という指定を、DNSの偽装から守れるようになります。ただし、DNSSECの信頼の連鎖が一か所でも切れると、認証局はCAAを読めなくなり、証明書の新規発行も更新も止まります。この記事では、2つのレコードがそれぞれどこに置かれ、どう関係するのかを整理したうえで、安全に併用するための作業順序と、発行が止まったときの確認方法を説明します。
CAAとDSは置き場所も役割も違う
最初に押さえておきたいのは、2つのレコードが別のゾーンに載るという点です。
- CAAレコード: 自分のゾーン（
example.comの権威DNS）に置きます。「どの認証局に発行を許可するか」を書くレコードで、認証局は証明書を発行する前にこれを問い合わせます。 - DSレコード: 親ゾーン（
.comや.jpのレジストリ）に置かれます。自分では直接書けず、ドメインを管理しているレジストラの画面から登録します。中身は自分のゾーンの鍵（DNSKEY）のハッシュ値で、「このゾーンは署名されていて、正しい鍵はこれ」と親が保証する役割です。
DSが登録されると、検証するリゾルバは親のDS → 子のDNSKEY → CAAの署名（RRSIG）の順にたどって、CAAの応答が本物かを確かめます。認証局はDNSSECを検証するリゾルバでCAAを引くので、併用すると、途中で応答を書き換えてCAAの制限をすり抜ける攻撃を防げます。
連鎖が切れたときに発行が止まる理由
認証局の運用ルールを定めるCA/ブラウザフォーラムのBaseline Requirementsでは、CAAの問い合わせに失敗したとき、一定の条件を満たせば「CAAなし」として発行してよいとされています。その条件の一つが「そのゾーンにルートからのDNSSECの連鎖が無いこと」です。言い換えると、DSが登録されている署名済みのゾーンでCAAの問い合わせが失敗すると、認証局は発行を断ります。
さらに、CAAとドメイン認証の問い合わせでDNSSECの検証を認証局に求める改定が進められ、2026年から適用されています（2026年10月現在）。適用日や細かな条件は改定が続くことがあるため、最新のBaseline Requirementsで確認してください。Let's Encrypt のように以前から検証している認証局もあります。
Let's Encrypt で連鎖が切れていると、次のようなエラーで更新が失敗します。
DNS problem: SERVFAIL looking up CAA for example.com - the domain's nameservers may be malfunctioningエラー文に「CAA」とあっても、原因がCAAの値ではなくDNSSECの側にあることが多いのが、この組み合わせのつまずきどころです。
併用するときの作業順序
CAAとDNSSECを一度に有効にすると、失敗したときにどちらが原因か分からなくなります。1つずつ進めて、そのたびに確認します。
1. 署名なしの状態でCAAを設定して発行を確かめる
まずCAAだけを設定します。使っている認証局の識別子は、各認証局の公式ドキュメントに書かれています。ホスティング会社の無料SSLを使っている場合は、そのサービスがどの認証局から発行しているかを先に確認してください。許可していない認証局を使っていると、自動更新がそこで止まります。
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"issuewild ";" はワイルドカード証明書の発行をどの認証局にも許可しない、という意味です。ワイルドカード証明書を使っているなら、この行は書かずに issuewild で認証局を指定します。設定したら、テスト環境（Let's Encrypt なら certbot renew --dry-run など）で発行が通ることを確かめます。
2. DNSサービス側でゾーンの署名を有効にする
DNSサービスの管理画面でDNSSECを有効にします。この時点ではまだDSを登録しないので、署名されていても検証には使われず、失敗しても影響はありません。CAAの応答に署名が付いているかを確認します。
# CAA と、その署名（RRSIG CAA）が返るか
dig example.com CAA +dnssec +multiline応答に RRSIG CAA の行があれば、CAAも署名されています。サブドメインの証明書を使う場合は、www.example.com など実際の名前でも問い合わせます。CAAが無い名前では、「存在しない」ことの証明（NSECまたはNSEC3）に署名が付いて返ります。
3. レジストラにDSを登録する
DNSサービスが表示するDS情報（キータグ・アルゴリズム・ダイジェスト種別・ダイジェスト）を、レジストラの画面に登録します。登録の形式や画面はレジストラによって異なり、DSではなく公開鍵そのものの入力を求めるところもあります。
4. 検証するリゾルバでCAAが引けるかを確認する
ここが併用でもっとも大切な確認です。Aレコードが引けるだけでは十分ではありません。認証局が問い合わせるのはCAAなので、CAAそのものを検証付きで確かめます。
# 検証するリゾルバで CAA を問い合わせる（ad フラグが付けば検証成功）
dig @1.1.1.1 example.com CAA +dnssec
dig @8.8.8.8 www.example.com CAA +dnssec
# 失敗したら、検証を外した（+cd）結果と比べる
dig @1.1.1.1 example.com CAA +cd通常の問い合わせが SERVFAIL で、+cd を付けると答えが返る場合は、DNSSECの検証失敗です。最後に、もう一度テスト環境で証明書の発行を試します。
「Aは引けるのにCAAだけ失敗する」ケース
サイトは表示されるのに証明書の更新だけ失敗する場合は、CAAの問い合わせに限って検証が失敗していることを疑います。考えられる原因を、よくある順に挙げます。
- CAAが無い名前の「不在の証明」が正しく署名されていない: CAAを設定していないサブドメインでは、DNSサーバーが署名付きの「この種類のレコードは無い」という応答を返す必要があります。DNSサーバーのソフトウェアやサービスの不具合でこの応答がおかしいと、CAAの問い合わせだけが失敗します。
+cdとの比較で切り分け、DNSサービスに問い合わせるか、CAAを明示的に設定して回避します。 - 委任先のサブドメインで連鎖が切れている:
shop.example.comを別のDNSサービスに委任している場合、そのゾーンにも独自のDSとDNSKEYが必要です。認証局は証明書の名前から親へ向かってCAAを探すため、途中のどのゾーンが失敗しても発行は止まります。 - 古いDSが残っている: DNSサービスを移行したのに旧サービスのDSを消していないと、すべての問い合わせが失敗します。この場合はAも引けなくなるので、症状で見分けられます。
DNSViz のような可視化ツールにドメインを入力すると、どのゾーンのどの段階で連鎖が切れているかを図で確認できます。
DNSサービスを移行するときの注意
CAAとDNSSECを併用しているドメインで一番事故が起きやすいのは、DNSサービスの移行です。旧サービスのDSが親に残ったままネームサーバーを切り替えると、新しいサービスの鍵と一致せず、証明書の更新を含めてすべてが止まります。安全な順序は次のとおりです。
- レジストラでDSを削除し、親ゾーンのDSのTTLが過ぎるまで待つ
- 新しいDNSサービスにCAAを含むレコードを移し、内容を照合する
- ネームサーバーを切り替え、署名なしの状態でCAAの応答と証明書の発行を確認する
- 新しいサービスで署名を有効にし、新しいDSを登録する
証明書の有効期限が近い時期にこの作業を重ねると、DNSの問題で更新が止まったときに余裕がなくなります。期限まで日数があるときに作業するか、作業前に手動で更新しておくと安心です。
まとめ
- CAAは自分のゾーン、DSは親ゾーン（レジストラ経由）に置く。併用するとCAAの応答が改ざんされていないことを認証局が確かめられる
- 署名済みのゾーンでCAAの問い合わせが失敗すると、認証局は発行を断る。DNSSECの不具合が証明書の更新停止として表に出る
- CAAの設定 → 署名の有効化 → DSの登録の順に1つずつ進め、そのたびにCAAを検証付きで問い合わせて確かめる
- 「Aは引けるがCAAだけ失敗」は、不在の証明の署名や委任先ゾーンの連鎖を疑い、
+cdとの比較で切り分ける - DNSサービスの移行では、先にDSを外してから切り替え、最後に新しいDSを登録する