DNS-PERSIST-01: DNSベースのチャレンジ検証のための新しいモデル

 (letsencrypt.org)
4 ポイント 投稿者 GN⁺ 2026-02-20 | 1件のコメント | WhatsAppで共有
  • Let's EncryptのDNS-PERSIST-01は、従来のDNS-01方式の反復的な検証に代わり、永続的な認証レコードを使用する新しいACMEチャレンジモデル
  • この方式は、特定のACMEアカウントとCAにバインドされたTXTレコードを通じて、ドメインの管理権限を長期的に証明
  • DNS変更とAPI認証情報の配布負担を減らし、運用効率とセキュリティを同時に強化
  • ポリシーオプション(policy=wildcard)、有効期限(persistUntil)、複数CAの許可など、きめ細かな制御機能をサポート
  • 2026年第1四半期末にステージング、第2四半期に本格ロールアウト予定で、大規模・自動化環境における証明書管理の簡素化が期待される

DNS-01方式の限界

  • 従来のDNS-01チャレンジでは、証明書発行のたびに新しいトークンを生成し、_acme-challenge.にTXTレコードを追加する必要がある
    • 検証のたびにDNS更新が必要となり、伝播遅延と自動化の複雑さが発生
  • 大規模デプロイでは、DNS API認証情報が複数のシステムに分散し、セキュリティリスクが増加
  • 一部の利用者は、このような反復的なDNS変更を避けたいと考えている

DNS-PERSIST-01の構造と動作方式

  • 新方式は、**永続的な認可(persistent authorization)**の概念を導入
    • _validation-persist.にCAとACMEアカウントURIを含むTXTレコードを一度だけ設定
    • 以後の発行および更新では同じレコードを再利用可能
  • 例: 
    _validation-persist.example.com. IN TXT (  
  "letsencrypt.org;"  
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"  
)
  • これにより、DNS変更が発行経路から取り除かれ、運用効率が向上

セキュリティと運用上のバランス

  • DNS-01ではDNS書き込み権限が主要な資産だったが、DNS-PERSIST-01ではACMEアカウント鍵の保護が中核
  • 初期設定後はDNS書き込みアクセスを制限できるため、攻撃面を縮小可能
  • ただし、永続的な認証構造により、アカウント鍵が漏えいした場合のリスクは大きくなるため、アカウントのセキュリティ管理強化が必要

範囲および寿命の制御機能

  • 基本的に、検証済みのFQDNに対してのみ無期限で有効
  • policy=wildcardオプションで、ワイルドカードおよびサブドメインまで拡張可能 
    "policy=wildcard"
  • persistUntil属性で**有効期限(UTC秒単位)**を指定可能
    • 期限前の更新が必要で、監視体制が必須
    "persistUntil=1767225600"
  • 複数のCAを同時に許可するには、_validation-persist.にCAごとのTXTレコードを追加

導入スケジュールと実装状況

  • CA/Browser Forum SC-088v3の投票が2025年10月に全会一致で可決され、IETF ACMEワーキンググループが草案を採択
  • Pebble(Boulderの縮小版)ではすでにサポートされており、lego-cliクライアント実装も進行中
  • 2026年第1四半期末にステージング、第2四半期に本格展開予定
  • このモデルは、IoT、マルチテナント、大量証明書発行環境など、従来方式が非効率だった領域に適している

Let's EncryptおよびISRGの背景

  • Let's Encryptは、非営利団体ISRGが運営する無料・自動化・オープンな認証局(CA)
  • 2025年年次報告書で、ISRGのインターネットセキュリティ関連活動を公開

関連記事

1件のコメント

 
GN⁺ 2026-02-20
Hacker Newsのコメント

  • このニュースを見られて本当にうれしい
    自分は権威ネームサーバーとして bind を使う場合、各Webサーバーが自分に対応するTXTレコードだけを更新できるように hmac-secret を制限できるよう設定している
    こうしておけば「bob」サーバーが侵害されても、「bob」ドメインの証明書しか発行できない
    設定例としては、update-policy によって各キーが _acme-challenge 配下のサブドメインだけを変更できるよう制限している

    • bind の代わりに別のDNSサーバーを運用するつもりなら、acmedns が似た機能を提供している
      新しいアカウントを作ると固有のサブドメインが割り当てられ、チャレンジ用ドメインをそのサブドメインに CNAME しておけば、そのアカウントだけがそのゾーンを更新できる

  • この機能は実運用上の 大きな不便 を解消すると思う
    ただし管理アカウントの 識別子の露出 が気になる
    ユーザー名は認証情報そのものほど厳重には守られないが、攻撃者が標的を把握する手がかりになり得る
    Shodan のようなサービスがこうしたIDをインデックスして逆引きサービスを提供する可能性が高い

    • CAAレコードの accounturi もすでにアカウント識別子を露出しているので、ある程度はすでに公開されているとも言える
      むしろ CAA と persist レコードのフォーマットが一致しているほうがよいと思う
    • ユーザーに実際のアカウントではなく UUID のようなランダムIDを渡して accounturi に使わせるとよさそう
    • ACMEクライアントが作るアカウントと同じなので、逆引きのリスクはそれほど大きくないと思う

  • DNSSEC を要求していない点は意外
    昔は DNSSEC は面倒だと思っていたが、今では CAA、CERT、SSHFP、TXT など ルートの信頼を左右するレコード が増えており、MITM攻撃に弱くなっている
    とくに大企業でさえ DNSSEC をきちんと適用していないことが多く、最低でも推奨事項として明記すべきだと思う

    • RFCドラフトでも DNSSEC の利用を「SHOULD」として推奨している (リンク)
    • DNS はもともと TLS証明書発行における 単一障害点 だった
      攻撃者がDNSを掌握すれば、HTTP-01、TLS-ALPN-01、DNS-01 のどの方式でも証明書を偽造できる
    • 個人的には DNSSEC より TLSA のほうがよいアプローチだと思うが、ブラウザ対応がほとんどないのが残念

  • この機能のおかげで、インターネットに公開されていない LANサーバー用証明書 の発行がずっと簡単になりそう
    今後は多くの管理UIで、DNSレコードに貼り付ける文字列を自動生成して、そのまま Let's Encrypt 証明書を取得できるようになりそう

    • 自分も似た環境で試したが、headscale magic DNS の設定が思ったより複雑で、結局は手動更新に戻した

  • certbot ユーザーなら、この機能の対応状況を GitHub issue で追跡できる

  • 以前は短期証明書の発行に懐疑的だったが、IPアドレス証明書 と HTTP-01 検証を見て考えが変わった
    今では証明書をディスクに保存せず、バックグラウンドスレッドが24時間ごとに新しい証明書を確認している
    こうすると、ユーザーがVMにソフトウェアを配布して 5分以内に運用可能 なセルフホストソリューションを作れる
    checkip.amazonaws.com のようなサービスと組み合わせれば、完全自動化されたデプロイが可能

    • ただし Let's Encrypt の 発行制限 は交渉の余地がないので、あまり頻繁にリクエストすると待たされるリスクがある
    • 証明書をまったく保存しないと可用性が LEのアップタイム に依存してしまうため、最低限の保存は必要

  • ついに内部専用Webサービス用の証明書を 自動化しやすく なったように思う
    これまで最大の運用上の問題を解決してくれた感じで、とてもうれしい

  • ここで抜けているのは ACMEアカウント所有の検証 だ
    ほとんどの自動化ツールはアカウントを生成するので、ユーザーが直接扱うことは少ないが、これからはアカウント所有を証明する認証情報を ACMEプロバイダーに渡さなければならない
    Let's Encrypt がドメインごとに制限付きトークンを作れないなら、各ドメインごとに別アカウントを作る必要があるかもしれない

    • ただし ACMEアカウントにはすでに認証用の資格情報があり、DNS や HTTP チャレンジを通じてドメイン所有を検証しているので
      もしその資格情報やエンドポイントが奪われるなら、すでにもっと重大な問題が起きている状態だ

  • Dynamic DNS ユーザーにとっては本当にうれしい知らせ
    たとえば Namecheap のように変更リクエストが 固定IP からしかできなかった場合でも、これで一度設定すれば自動更新が可能になる
    ホームラボの近代化を進める中で、ぜひ試してみたい

  • もし自分の理解が間違っていなければ、自分のドメインのDNSサーバーを制御できる人や、
    Let's Encrypt と DNSサーバーの間のトラフィックを盗聴できる人は、自分のドメイン向けTLS証明書を発行できてしまうのではないかという疑問がある
    DNS-01 も同じだが、今回の方式は攻撃者が自分の LEアカウントをDNS応答に入れるだけでよいので、さらに簡単に見える
    いっそ自分の公開証明書をDNSに直接入れたほうがよいのではないかと思う

    • DNSプロバイダーを信頼できないなら、その関係自体が問題
      LE と DNSサーバー間のトラフィックを MITM できるなら、すでにもっと深刻な状況だ
    • DNS を制御できる人は、どのCAからでも証明書を発行できる
      DNS を変更できるなら、証明書を阻止する方法はない
    • DNS を支配しているなら HTTPチャレンジも実行できるので、事実上そのドメインはその人のもの
    • CA はこうした ネットワーク攻撃の緩和 のため、複数地点からDNSを参照している
      Let's Encrypt はすでに数年前からこの運用をしており、2024年からはすべてのCAの義務になっている
      CAB Forum規定リンク
    • このアプローチは実際には DANE が取っている方式でもある
      関連資料