2026年6月17日

CAAレコードとDNSKEYレコードを併用する設定｜CAAの署名と鍵更新・署名期限で証明書を止めない

DNS・名前解決

CAAレコードとDNSKEYレコードは同じゾーンの頂点（example.com）に並んで置かれ、CAAはDNSKEYに載っている鍵で署名されます。併用で気を付けるのは、CAAを書き換えたときに署名が作り直されているか、鍵を更新するときにCAAの署名が検証できる状態を保てているか、そして署名の有効期限が切れていないか、の3点です。どれかが崩れると、認証局はCAAを検証できず証明書を発行しません。この記事では、ゾーンの内側（署名と鍵）に焦点を当てて、CAAとDNSKEYの関係の確かめ方と、運用で事故を防ぐ手順を説明します。

なお、レジストラに登録するDSレコードとCAAの組み合わせ、つまり親ゾーン側の話は扱いません。ここではDNSSECがすでに有効になっているゾーンを前提にします。

CAAとDNSKEYの関係

DNSSECで署名されたゾーンでは、CAAレコードの集まり（同じ名前のCAAすべて）に対して1つの署名（RRSIG CAA）が付きます。この署名を作るのに使われた鍵の公開鍵が、ゾーン頂点のDNSKEYレコードに載っています。

DNSKEYのフラグ256: ゾーン署名鍵（ZSK）。CAAやAなど、通常のレコードの署名に使われる
DNSKEYのフラグ257: 鍵署名鍵（KSK）。DNSKEYの集まり自体に署名し、親のDSから指される
1つの鍵で両方を兼ねる構成（CSK）もあり、その場合はフラグ257の鍵がCAAにも署名します

認証局がCAAを検証するときは、親のDS → KSK → DNSKEYの集まり → ZSK → CAAの署名、の順にたどります。CAAの署名に書かれた鍵の番号（キータグ）が、今公開されているDNSKEYのどれかと一致し、署名の期限内であることが条件です。

CAAの署名を確かめる

まず、CAAとその署名、DNSKEYを並べて確認します。キャッシュの影響を避けるため、権威DNSサーバーに直接問い合わせます。

# 権威DNSサーバーを調べる
dig example.com NS +short

# CAA とその署名を権威サーバーから取得
dig @ns1.example.net example.com CAA +dnssec +multiline +norecurse

# DNSKEY を取得（+multiline で key id が表示される）
dig @ns1.example.net example.com DNSKEY +multiline +norecurse

RRSIG CAA の行には、署名の対象（CAA）、アルゴリズム、元のTTL、有効期限、署名開始日時、キータグ、署名者名が並びます。確認するのは次の点です。

キータグが、DNSKEYの出力にある key id のどれかと一致しているか
アルゴリズムの番号が、その鍵のアルゴリズムと同じか
有効期限が先の日付で、署名開始日時が現在より前か
権威サーバーが複数あるなら、すべてのサーバーで同じCAAと有効な署名が返るか

最後に、検証するリゾルバ側で検証が通るかを確かめます。BINDに付属する delv を使うと、結果が分かりやすく表示されます。

# "; fully validated" と表示されれば検証成功
delv @1.1.1.1 example.com CAA

CAAを書き換えるときの注意

Cloudflare や Amazon Route 53 のようなマネージドDNSでDNSSECを有効にしている場合、CAAを変更すると署名はサービス側で自動的に作り直されます。利用者が意識するのは、変更後に新しいCAAと署名が返っているかの確認くらいです。

自前のBINDなどで署名している場合は、ゾーンファイルを編集しただけでは署名が更新されない構成があります。BINDの dnssec-policy とインライン署名を使っていれば、ゾーンの再読み込みで変更分が署名されますが、手動で dnssec-signzone を実行する運用なら、署名し直してから公開する手順が必要です。変更後は上の dig で、新しいCAAの値と、署名開始日時が新しくなった RRSIG CAA が返ることを確認します。

古い署名が付いたまま新しいCAAが公開されると、署名と中身が一致せず検証に失敗します。CAAを書き換えたら、認証局で証明書を発行する前に delv で検証を確認する、という順番を習慣にしておくと安全です。

鍵の更新（ロールオーバー）とCAA

ZSKやKSKを新しくする作業中は、CAAの署名を作る鍵が切り替わります。リゾルバは古いDNSKEYの集まりをTTLの間キャッシュしているため、手順を誤ると「新しい鍵で作った署名なのに、キャッシュされたDNSKEYにその鍵が無い」状態になり、CAAの検証が失敗します。

ZSKの更新では、一般に次のような事前公開の順序を取ります。

新しいZSKをDNSKEYに追加して公開し、DNSKEYのTTLが過ぎるまで待つ
新しいZSKで署名を作り直す（CAAの署名も新しい鍵に切り替わる）
古い署名のTTLが過ぎるのを待ってから、古いZSKをDNSKEYから外す

マネージドDNSでは鍵の更新もサービスが行いますが、自前で署名している場合はこの待ち時間を守ることが大切です。BINDの dnssec-policy を使っていれば、待ち時間を含めて自動で管理されます。

運用上の注意として、鍵の更新中にCAAの変更や証明書の発行を重ねないことを勧めます。問題が起きたときに、鍵の更新とCAAの変更のどちらが原因か切り分けにくくなるからです。アルゴリズム自体を変える更新（たとえば8から13へ）はさらに手順が複雑なので、DNSサーバーソフトウェアの公式ドキュメントに沿って進めてください。

署名の有効期限切れを監視する

自前で署名している場合に見落としやすいのが、署名の有効期限です。署名を更新する仕組みが止まると、期限が来た時点でCAAを含むすべてのレコードの検証が失敗し、サイトの名前解決も証明書の発行も止まります。

次のスクリプトは、CAAの署名の有効期限までの残り日数を表示する例です。cronで定期実行し、残りが少なくなったら通知するように組み込むと、署名の更新漏れに早く気付けます。

#!/bin/bash
# CAA の署名（RRSIG CAA）の有効期限までの残り日数を表示する（GNU date 前提）
zone="example.com"
ns="ns1.example.net"   # 自分の権威DNSサーバー

exp=$(dig +short +dnssec +norecurse @"$ns" "$zone" CAA | awk '$1=="CAA"{print $5; exit}')
if [ -z "$exp" ]; then
  echo "RRSIG CAA が見つかりません"
  exit 1
fi

exp_epoch=$(date -u -d "${exp:0:8} ${exp:8:2}:${exp:10:2}:${exp:12:2}" +%s)
now=$(date -u +%s)
echo "残り $(( (exp_epoch - now) / 86400 )) 日"

マネージドDNSでは署名の更新は自動ですが、署名の有効期間が短く設定されていることがあります。数日単位の期限が表示されても異常とは限らないため、残り日数の閾値は運用に合わせて決めてください。

検証に失敗したときの切り分け

CAAの検証が失敗したら、原因を次の順に確かめます。

署名のキータグに対応する鍵がDNSKEYに無い: 鍵の更新で古い鍵を早く外しすぎた可能性があります。署名を作り直すか、外した鍵を一時的に戻します。
署名の期限が切れている: 署名を更新する仕組み（BINDのプロセス、cronなど）が止まっていないかを確認し、署名し直します。
権威サーバー間で応答が違う: セカンダリへのゾーン転送が遅れ、古い署名が返っているサーバーがあります。ゾーンのシリアル番号をサーバーごとに比べます。
DNSKEYの集まり自体が検証できない: KSKと親のDSの対応が崩れています。この場合はCAAに限らずすべての問い合わせが失敗するので、DSの照合に進みます。

検証の流れを図で見たい場合は、DNSViz のような可視化ツールが役に立ちます。

まとめ

CAAはZSK（またはCSK）で署名され、その公開鍵がDNSKEYに載っている。署名のキータグ・アルゴリズム・期限がDNSKEYと合っていることが検証の条件
CAAを変更したら、新しい値に新しい署名が付いているかを dig +dnssec と delv で確認してから証明書を発行する
鍵の更新では、新しい鍵の事前公開とTTLの待ち時間を守る。更新中にCAAの変更や証明書の発行を重ねない
自前で署名しているなら、CAAの署名の有効期限を監視する。マネージドDNSでは署名と鍵の更新はサービス側で自動化されているのが一般的（2026年10月現在）
失敗時は、鍵の不在 → 期限切れ → 権威サーバー間の不一致 → DSとの対応、の順に確かめる