CAAレコードのTTLは、普段は3600秒（1時間）前後にしておき、認証局（CA）を追加・変更する前だけ300秒程度に下げるのが扱いやすい設定です。CAAは証明書を発行する瞬間に認証局が確かめるレコードなので、TTLは「CAAを書き換えてから、認証局が新しい内容を見るまでの遅れ」に効きます。この記事では、CAAのTTLが何に影響するのか、値の決め方、管理画面やBINDでの設定方法、変更後の確認までを説明します。
CAAのTTLが効く場面
CAAレコードは、そのドメインの証明書を発行してよい認証局を指定するものです。サイトを見に来る利用者のブラウザはCAAを参照しません。CAAを問い合わせるのは、証明書を発行しようとしている認証局です。
そのため、CAAのTTLが長すぎても短すぎても、サイトの表示速度や利用者側の動作には影響しません。影響が出るのは次の2つの場面です。
- 認証局を切り替える、または追加するとき: CAAに新しい認証局を書き足しても、認証局が使うキャッシュDNSに古いCAAが残っていると、TTLが切れるまで「許可されていない」と判断されて発行が止まることがあります
- CAAを初めて追加するとき、またはすべて消すとき: 「CAAが存在しない」という答えもキャッシュされます。その長さはTTLではなく、ゾーンのSOAレコードの値（ネガティブキャッシュのTTL）で決まります
業界の基準（CA/Browserフォーラムの Baseline Requirements）では、認証局は発行前にCAAを確かめることになっており、確かめた結果を使える時間についても定めがあります。具体的な扱いは版の改訂で変わることがあり、認証局ごとの実装も違うため（2026年10月現在）、利用している認証局のドキュメントで確かめてください。
値の決め方
普段は3600秒前後
CAAは頻繁に書き換えるレコードではありません。普段は他のレコードと同じく、1時間程度で困ることはほとんどありません。数日単位の長い値（86400秒など）にすると、急いで認証局を切り替えたいときに待ち時間が長くなります。
切り替え前は300秒程度に下げる
認証局を変えることが決まっていたら、作業の前日など、現在のTTL以上の時間を空けてTTLを300秒程度に下げておきます。古いTTLが切れてからCAAの内容を書き換えると、認証局側のキャッシュが短い間隔で新しい内容に入れ替わります。
短すぎる値にしない
CAAのTTLを数十秒にしても、利点はほとんどありません。認証局の問い合わせのたびに権威DNSへの問い合わせが増えるだけで、従量課金のDNSサービスでは費用につながることもあります。
同じ名前のCAAは同じTTLにする
CAAは1つの名前に複数行を置くことが多いレコードです（issue と issuewild、iodef など）。同じ名前・同じ型のレコードの組（RRset）は、1つのTTLを共有する決まりです。行ごとに違うTTLを入れても、サービス側で1つにそろえられるか、保存時にエラーになります。
設定する手順
作業の前に、現在のCAAとTTLを控えておきます。
dig example.com CAA +noall +answer
dig www.example.com CAA +noall +answer出力の2列目がTTL（秒）、末尾が許可されている認証局です。何も返らなければ、その名前にCAAはありません。CAAは名前ごとに確かめ、無ければ親の名前（www.example.com なら example.com）のCAAが使われます。サブドメインに個別のCAAがあるなら、そちらのTTLも合わせて見直します。
管理画面で設定する場合
多くのDNSサービスでは、CAAレコードの編集画面にTTLの欄があります。Cloudflareのように「自動」を選べるサービスでは、自動のときの実際の秒数がサービスの既定値になります。Route 53では、CAAの行がまとめて1つのレコードとして扱われ、TTLもそのレコードに1つだけ入れます。項目名や画面の配置はサービスの更新で変わることがあるため、ドキュメントと合わせて確かめてください。
BINDのゾーンファイルで設定する場合
TTLは各行の名前の後ろに書きます。省略すると、ゾーンファイル冒頭の $TTL の値が使われます。
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"編集する前にゾーンファイルのバックアップを取ります。編集後はSOAのシリアル番号を上げ、構文を確かめてから読み込み直します。
named-checkzone example.com /var/named/example.com.zone
sudo rndc reload example.com認証局を切り替えるときの流れ
TTLの役割が一番はっきりするのが、認証局の切り替えです。たとえばホスティング会社の無料証明書から、別の認証局の証明書に変える場合は次の順に進めます。
- 現在のCAAのTTLを確かめ、300秒程度に下げる
- 下げる前のTTLが切れるまで待つ
- CAAに新しい認証局を追加する（古い認証局はまだ消さない）
- 権威DNSで新しいCAAが返ることを確かめる
- 新しい認証局で証明書を発行し、サイトで有効になったことを確かめる
- 古い認証局の証明書が使われていないことを確かめてから、古い認証局をCAAから外す
- TTLを普段の値に戻す
手順3で古い認証局を残しておくのは、切り替え中に自動更新が走っても発行が止まらないようにするためです。WordPressサイトでは、ホスティング会社の管理画面が裏で証明書を自動更新していることがあります。CAAから発行元を消すと、更新の時期に初めてエラーに気づくことになりがちです。
変更後の確認
権威DNSに直接問い合わせると、キャッシュを通さない最新の値が分かります。ネームサーバー名は dig example.com NS +short で確かめられます。
dig @ns1.example-dns.net example.com CAA +noall +answer
dig @8.8.8.8 example.com CAA +noall +answer権威DNSのすべてで新しい内容とTTLが返り、公開DNSでも新しい内容が見えれば、CAAの変更は外から見える状態です。ただし、認証局が使うキャッシュDNSは外からは見えません。発行がCAAの理由で拒否された場合は、エラーメッセージに書かれた名前とCAAの内容を確かめ、変更前のTTL分の時間を待ってから再試行します。
DNSSECを有効にしているゾーンでは、CAAにも署名が付きます。署名の検証に失敗すると、認証局はCAAを確かめられず発行を止めることがあるため、dig +dnssec で署名が返っているかも合わせて見ておくと安心です。
まとめ
- CAAのTTLは、利用者ではなく認証局がCAAを確かめるときの遅れに効く
- 普段は3600秒前後、認証局を変える前だけ300秒程度に下げる
- CAAを初めて置く・消すときは、SOAのネガティブキャッシュの値も待ち時間に関わる
- 同じ名前のCAAは1つのTTLを共有する
- 切り替えでは新しい認証局を先に追加し、発行を確かめてから古い認証局を外す