2026年6月16日

DANE（TLSAレコード）の鍵を安全に更新する手順

DNS・名前解決

DANE の鍵更新は、「新しい鍵の TLSA レコードを先に追加し、DNS のキャッシュが入れ替わるのを待ってから証明書を差し替え、最後に古いレコードを消す」という順番を守れば、メール配送を止めずに行えます。この記事では、メールサーバー（SMTP）で DANE を使っている人向けに、鍵を変えるべきかの判断、TLSA の値の作り方、切り替えの順序、検証コマンドまでを説明します。

DANE の鍵更新でなぜ配送が止まるのか

DANE は、DNSSEC で署名された TLSA レコードに「このサーバーが使う証明書（または公開鍵）のハッシュ」を載せ、接続する側がそれと照合する仕組みです。現在、実運用で広く使われているのは SMTP のサーバー間通信で、Web ブラウザは DANE を検証していません。

送信側の MTA（例: Postfix で DANE を有効にしている場合）は、TLSA に一致しない証明書を提示されると、そのサーバーへの配送を見送ります。つまり、TLSA を更新しないまま鍵を変えると、DANE を検証する相手からのメールが届かなくなります。しかも送信側では再送キューに積まれるだけなので、受信側からは気づきにくいのが厄介な点です。

鍵を変える必要があるかを先に確認する

まず、今の TLSA がどの形式かを確認します。

dig +short _25._tcp.mail.example.com TLSA

3 1 1 ... という値が返ってくる場合、これは「サーバー証明書の公開鍵（SubjectPublicKeyInfo）の SHA-256」を意味します。この形式では、証明書を更新しても同じ秘密鍵を使い続けていれば TLSA は変わりません。

Let's Encrypt と certbot を使っている場合、certbot は既定では更新のたびに新しい秘密鍵を作ります。3 1 1 で運用するなら、通常の更新では --reuse-key を指定して鍵を維持し、鍵の更新は計画的に行う、という分け方が扱いやすいです。

# 更新時に既存の秘密鍵を再利用する例（反映状況は /etc/letsencrypt/renewal/ の設定ファイルで確認）
sudo certbot renew --cert-name mail.example.com --reuse-key

鍵を変えるのは、定期的なローテーションの時期が来たとき、鍵の漏えいが疑われるとき、鍵の種類（RSA から ECDSA など）を変えたいときです。漏えいが疑われる場合は、下記の待ち時間を短縮してでも早めに切り替え、古い証明書の失効も検討してください。

手順1: 次の鍵を作り、TLSA の値を計算する

作業前に、DNS ゾーンと現在の証明書・秘密鍵のバックアップを取っておきます。新しい秘密鍵は、現行の鍵とは別のファイルとして作ります。

# ECDSA P-256 の鍵を作る例
sudo openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out /etc/ssl/private/mail-next.key
sudo chmod 600 /etc/ssl/private/mail-next.key

# 公開鍵（SPKI）の SHA-256 を計算する（3 1 1 用）
sudo openssl pkey -in /etc/ssl/private/mail-next.key -pubout -outform DER | sha256sum

表示された 64 桁の16進数が、新しい TLSA の値になります。現在の鍵の値も同じ方法で計算し、dig で見えている値と一致することを確かめておくと、計算方法の誤りに気づけます。

手順2: 新旧2つの TLSA を並べて公開する

DNS に、現在の TLSA を残したまま、新しい鍵の TLSA を追加します。

_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 (現在の鍵のハッシュ)
_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 (新しい鍵のハッシュ)

TLSA は複数あってよく、どれか1つに一致すれば検証は通ります。この状態にしておけば、切り替えの前後どちらの証明書でも配送が止まりません。

追加したら、ゾーンが DNSSEC で正しく署名されていることを確認します。検証を行うリゾルバに問い合わせ、応答のフラグに ad が付いていれば署名の検証に成功しています。

dig +dnssec _25._tcp.mail.example.com TLSA @1.1.1.1

MX が複数ある場合は、MX ごとに _25._tcp.<各MXのホスト名> の TLSA が必要です。1台だけ更新して他を忘れる、というのもよくある見落としです。

手順3: TTL 分待ってから証明書を差し替える

新しい TLSA を追加しても、送信側のリゾルバには古い TLSA（現在の値だけ）がキャッシュされている可能性があります。そのため、TLSA の TTL の2倍程度は待ってから証明書を差し替えます。上の例で TTL が 3600 秒なら、2時間ほどです。

待ち時間が過ぎたら、新しい鍵で証明書を発行します。鍵を指定して発行する一般的な方法は、CSR を作って CA に渡すことです。

sudo openssl req -new -key /etc/ssl/private/mail-next.key -subj "/CN=mail.example.com" -out /root/mail-next.csr

certbot では certonly --csr で CSR から発行できますが、この方法で発行した証明書は certbot renew の自動更新の対象になりません。運用中の更新方法とどう組み合わせるかは、利用している ACME クライアントのドキュメントで確認してください。

発行した証明書と新しい鍵を Postfix の設定（smtpd_tls_chain_files など、使っている設定項目）に反映し、postfix check で確認してから postfix reload します。

手順4: 新しい証明書で検証が通るか確かめる

OpenSSL 1.1.0 以降の s_client は、TLSA の値を直接与えて照合できます。

openssl s_client -connect mail.example.com:25 -starttls smtp \
  -dane_tlsa_domain mail.example.com \
  -dane_tlsa_rrdata "3 1 1 (新しい鍵のハッシュ)" </dev/null

出力の Verification: OK と、DANE の TLSA が一致した旨の行を確認します。Postfix を使っている環境なら、付属の posttls-finger でも DANE を有効にした接続テストができます。外部の診断サービス（インターネット経由でメールサーバーの DANE を検査するサイト）も併用すると、自分のネットワーク以外からの見え方を確かめられます。

あわせて、送信側からの配送が滞っていないかをメールログで確認します。TLSA の不一致が起きていれば、送信元の MTA 側で TLS の検証失敗として記録されるため、自分で別ドメインから試験送信してみるのが手軽です。

手順5: 古い TLSA を削除する

新しい証明書で検証が通り、配送にも問題がなければ、古い鍵の TLSA を削除します。新しい証明書はすでに新しい TLSA と一致しているので、削除のタイミングで配送が止まることはありません。万一の切り戻しに備えて、数日ほど残してから消す運用でもかまいません。

古い秘密鍵は、切り戻しの必要がなくなった段階で安全に破棄します。

DANE-TA（2 1 1）を使う場合の注意

2 1 1 は、サーバー証明書ではなく発行元 CA（中間証明書など）の公開鍵を指定する形式です。サーバーの鍵を変えても TLSA を変えずに済む反面、CA が中間証明書を切り替えると一致しなくなります。Let's Encrypt は複数の中間証明書を使い分けており、構成も変わることがあるため（2026年10月現在）、2 1 1 を使う場合は CA が公開している中間証明書の一覧を確認し、変更の告知を追う必要があります。サーバー側で鍵を管理できるなら、3 1 1 の新旧併記で回すほうが仕組みを把握しやすいです。

まとめ

DANE の鍵更新は「新しい TLSA を追加 → TTL の2倍程度待つ → 証明書を差し替え → 古い TLSA を削除」の順で行う
3 1 1 なら鍵を変えない限り TLSA は不変。certbot では通常更新に --reuse-key を使い、鍵の更新は計画的に行う
TLSA の追加後は DNSSEC の検証（ad フラグ）と、MX ごとのレコード漏れを確認する
差し替え後は openssl s_client の DANE オプションや posttls-finger、外部診断で照合を確かめる
2 1 1 は CA の中間証明書の変更に左右されるため、使う場合は CA の告知を追う