CAAレコードを初めて追加するときは、TTLを300秒程度の短い値にして登録し、証明書の発行や更新が通ることを確かめてから、3600秒以上の通常の値に延ばす進め方が安全です。CAAは「この認証局以外は証明書を発行しないでほしい」という制限なので、書き間違えると自分のサイトの証明書更新まで止まり、その誤った値がTTLの間キャッシュに残るからです。この記事では、追加前の確認、TTLの決め方、登録、確認、TTLの延長までを順に説明します。
CAAの書き方そのものや、Let's Encrypt・ワイルドカード証明書向けの具体的な値は別の記事でも扱っています。ここでは「追加するときにTTLをどう扱うか」に重点を置きます。
CAAとTTLの関係
CAAレコード（RFC 8659）は、ドメインの証明書を発行してよい認証局（CA）をDNSで宣言する仕組みです。認証局は証明書を発行する前にCAAを確認することになっており、許可されていない認証局は発行を断ります。
ここでTTLが関わるのは2か所です。
- キャッシュDNSでの保持時間: 認証局がCAAを調べるときも、通常のDNSと同じくキャッシュが使われます。誤ったCAAを登録して後から直しても、古い答えはTTLの間残る可能性があります。
- 認証局側の確認結果の扱い: CA/Browser Forum の基本要件（Baseline Requirements）では、認証局はCAAを確認したうえで、そのTTLの間、または8時間のどちらか長い方の時間内に発行することとされています（2026年10月現在の要件の趣旨。詳細は最新版を確認してください）。CAAを直した直後でも、少し前に確認した結果に基づいて判断される場合があるということです。
もう一つ見落としやすいのが、「CAAが無い」という答えのキャッシュです。CAAを追加する前に誰かがCAAを問い合わせていると、「この名前にCAAは無い」という否定の答えがキャッシュされています。否定の答えを保持する時間は、そのゾーンのSOAレコードの値（SOA自体のTTLと、SOAの最後の数値のうち短い方）で決まります（RFC 2308）。そのため、追加したCAAがすべてのキャッシュDNSで見えるようになるまで、SOAで決まる時間がかかることがあります。
追加する前に確認すること
今どの認証局の証明書を使っているか
CAAに書くべき認証局は、今使っている証明書の発行元です。ブラウザで証明書の詳細を開くか、コマンドで発行者を確かめます。
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -issuer -enddatewww やサブドメインで別の証明書を使っている場合は、それぞれ確かめます。レンタルサーバーやCDNが自動で証明書を発行している場合は、その事業者がどの認証局を使っているかを事業者の説明で確かめます。事業者が状況によって複数の認証局を使い分けることもあり、1つだけ許可すると更新に失敗する場合があります。
既存のCAAとSOAの値
すでにCAAがあるか、そして否定の答えがどれくらい残りうるかを見ます。
# 既存のCAA（権威ネームサーバーに直接）
dig example.com NS +short
dig @ns1.example-dns.jp example.com CAA +norecurse +noall +answer
# SOAの値（TTLと、最後の数値を確認）
dig @ns1.example-dns.jp example.com SOA +norecurse +noall +answerSOAの出力の2列目がSOA自体のTTL、行の最後の数値が否定の答えの保持時間の目安です。どちらかが3600なら、追加したCAAが行き渡るまでの待ち時間は最大1時間程度と見積もれます。
DNSサービスがCAAに対応しているか
CAAを登録できないDNS管理画面もあります。レコードの種類の選択肢にCAAが無い場合は、DNSサービスのヘルプで対応状況を確かめます。Cloudflare を使っている場合、CAAを追加すると、Cloudflare が証明書の発行に使う認証局のCAAを自動で補う動作が案内されています（2026年10月現在）。仕様は変わることがあるため、最新の説明を確認してください。
TTLの値を決める
追加する時点と、安定したあとで、値を分けて考えます。
| 段階 | TTLの目安 | 理由 |
|---|---|---|
| 追加直後〜更新を確かめるまで | 300〜600秒 | 誤りがあってもすぐ直せる |
| 証明書の更新を1回確かめたあと | 3600秒〜86400秒 | 変更の予定が少なく、問い合わせも減らせる |
CAAは頻繁に変えるものではありません。ただし、ホスティングやCDNを乗り換えると使う認証局が変わることがあるため、乗り換えの予定があるなら、長くしすぎない値（3600秒前後）にとどめておくと切り替えが楽になります。
CAAを追加する
Let's Encrypt の証明書を使っている例です。通常の証明書（issue）とワイルドカード証明書（issuewild）を許可し、ポリシーに反する発行依頼があったときの連絡先（iodef）を指定しています。
example.com. 300 IN CAA 0 issue "letsencrypt.org"
example.com. 300 IN CAA 0 issuewild "letsencrypt.org"
example.com. 300 IN CAA 0 iodef "mailto:security@example.com"DNSサービスの管理画面では、多くの場合「フラグ」「タグ」「値」が別の入力欄になっています。フラグは通常0、タグは issue などの小文字、値は認証局のドメイン名です。値を二重引用符で囲むかどうかは画面によって違うため、入力例に従います。TTLの欄には、ここでは300を入れます。
いくつか注意点があります。
- 同じ名前の複数のCAAは1つのまとまりとして扱われるので、TTLはすべての行で同じ値にします。
issuewildを書かない場合、ワイルドカード証明書にはissueの内容が使われます。issuewildを書くと、ワイルドカードについてはissuewildだけが見られます。- サブドメインにCAAが無い場合、認証局は親のドメインのCAAを見ます。ドメインの頂点に追加すると、CAAを持たないサブドメインすべてに効く点に注意します。
ゾーンファイルで管理している場合は、追加後にSOAのシリアル番号を上げ、named-checkzone で書式を確かめてから読み込み直します。作業前にはゾーンファイルのバックアップを取っておきます。
追加したCAAを確かめる
まず、すべての権威ネームサーバーが同じCAAを、指定したTTLで返しているかを見ます。
for ns in $(dig example.com NS +short); do
echo "== $ns"
dig @"$ns" example.com CAA +norecurse +noall +answer
done
# 公開DNSでの見え方（TTLは残り時間で表示される）
dig @8.8.8.8 example.com CAA +noall +answer公開DNSでまだ「答え無し」が返る場合は、否定の答えのキャッシュが残っている可能性があります。先ほど確かめたSOAの値の時間が過ぎるまで待ってから、もう一度問い合わせます。
次に、証明書の更新が通るかを確かめます。Certbot を使っている場合は、本番の証明書を書き換えずに試す方法があります。
sudo certbot renew --dry-run--dry-run はLet's Encrypt のテスト用の環境に対して更新を試すもので、本番の発行回数の制限を消費しません。テスト用の環境でもCAAは確認されるとされていますが、本番と細かな動作が異なる可能性もあるため、最終的には次回の本番の更新が成功するかを見届けます。レンタルサーバーやCDNの自動発行に任せている場合は、管理画面で証明書の状態や次回の更新予定を確かめ、更新後に有効期限が延びたかを見ます。
もし更新でCAAのエラーが出たら、エラーの内容にある認証局の名前を確かめ、CAAの値を直します。TTLを短くしてあるので、修正は数分程度で行き渡ります。
TTLを通常の値に延ばす
証明書の更新が1回成功したら、CAAのTTLを3600秒以上に変更します。すべてのCAAの行を同じ値にそろえて書き換え、権威ネームサーバーで新しいTTLが返るかを確かめれば作業は完了です。
Let's Encrypt の証明書は有効期間が短く、更新の頻度が高いため、追加から最初の更新までの期間が短い傾向があります。一方、有効期間の長い証明書では次の更新まで間が空くため、TTLを延ばす前に、更新予定日を記録しておき、その日に結果を確かめる運用にしておくと安心です。
まとめ
- CAAを初めて追加するときは、TTLを300〜600秒にして登録し、証明書の更新が通ってから3600秒以上に延ばします。
- 追加前に、今使っている認証局、既存のCAA、SOAの値（否定の答えの保持時間）を確かめます。
- 同じ名前のCAAはTTLをそろえ、頂点に置いたCAAがサブドメインにも効くことに注意します。
- 確認は全権威ネームサーバーへの問い合わせと、
certbot renew --dry-runや実際の更新結果で行います。 - 認証局がCAAの確認結果を一定時間使うことがあるため、直した直後に結果が変わらない場合もあります。