DNS-Persist-01：DNSベースのドメイン検証に新風？次世代の認証モデルが登場

DNS-Persist-01は、DNSベースのチャレンジ検証（DNS-01）の仕組みを刷新するために提案された新しいモデルです。従来の検証プロセスの課題を解決し、より効率的で信頼性の高いドメイン所有権の確認を実現することを目指しています。

これは実際の運用上の痛点を解消するものだと思う。間違いなく私も経験したことのある問題だ。一番引っかかるのは、管理用アカウントのIDが直接露出すること。アカウントのキーマテリアルを守る必要があるからというわけではなく、それは元々対策しなければならないことなんだけどね。

「ユーザー名」は一般的に認証情報ほど厳重に保護されていないとはいえ、重要ではある。実際の攻撃が始まる前の入り口として機能しているからだ。また、これによって、ランダムに見つかった認証情報を、同じアカウントを使っている場合に証明書を発行できるサイトと紐付けられるようになる。これは発生した侵害に対して、攻撃範囲をタダで拡大させるようなものだ。

Shodanのようなサイトが、これらIDを監視対象の全ドメインでインデックスし始めて、リバースルックアップサービスを提供するようになるのは確実だと思う。

満場一致で可決されたのは驚きだ！証明書の更新パイプラインにDNSの認証情報を保存するのが危険なのはわかる。ただ、多くのDNSプロバイダーは粒度の細かいAPIアクセス制御を提供しているから、キーが漏洩した場合でも影響範囲を限定することはすでに可能だ。それに、キーは簡単に失効できる。

ACMEアカウントの認証情報も、DNS API認証情報と同じ更新パイプラインからアクセスできてしまうので、これによって新しい分離が提供されるわけではない。

(このチャレンジをどう失効させるのか、ドメインの期限切れをどう扱うのかがはっきりしていない。DNSレコードの内容には最低でもアカウントキーのHMAC、FQDN、そしてドメインが他所に移管された場合に無効になるような何かが含まれているべきだった。リーフのDNSSECキーなら完璧だっただろうが、DNSSECキーのローテーション自体がかなり壊れているのでうまく機能しないだろう。)

CAAレコードでチャレンジの種類を制限する方法はないのかな？アカウント番号で制限することはできるし、それが今のところ一番堅いコントロールだと思う。

追記：このコメントへの返信のおかげで、DNSレコードを削除するだけで無効化できること、そして更新時にDNSレコードがより短い検証TTLでチェックされることを学んだ。

これが出て本当に嬉しい。

それまでの間、権威DNSサーバーとしてbindを使っているなら、hmac-secretを1つのTXTレコードに限定できる。そうすれば、rfc2136を使って証明書更新を行う各ウェブサーバーは、自分の特定のレコードしか更新できなくなる：

(設定コード例)

こうすれば「bob」が侵害されても「bob」用の証明書しか取れないから安心だ。サーバー側の設定はこんな感じ：

(設定コード例)

HTTP-01検証方式でIPアドレス証明書が何を可能にするかを見て、短命証明書についての考えが変わった。もうディスクに証明書を書き込むことすらしていない。現在インスタンスが保持している証明書がnullか24時間以上経過していないかを確認するバックグラウンドスレッドを走らせている。aspnetcoreの証明書セレクターはその参照先を見て、nullじゃなくなるまでブロックするだけだ。

VMにデプロイして5分以内に運用開始できるような、セルフホスト可能なソフトウェアをユーザーに提供できるのは大きなセールスポイントだ。初心者の段階ではドメイン登録とDNSはものすごく面倒なものだからね。これを https://checkip.amazonaws.com のようなものと組み合わせれば、きちんとしたターンキーソリューションを構築できる。

やった！これなら内部向けのウェブサービス用証明書も、ACME以前よりずっと簡単に管理できるようになるはず。Let's Encryptやモダンなウェブ証明書で一番苦労していた運用上の問題がこれで解決しそうだ。

関わったすべての人に感謝！

一つ欠けていることがある。それはACMEアカウントの所有権の検証についてだ。

たいていのユーザーはアカウントを作成してくれる自動化ツールに依存しているから、この辺りを意識することはないと思う。でも今後は、ACMEプロバイダーに対してアカウント所有権を検証するために、何らかの認証情報を展開する必要がある。この発表の中でその点について議論されていればよかったのにな。

Let's Encryptの認証モデルには詳しくないけど、ターゲットドメインごとに制限できるトークン作成機能がないのなら、ターゲットドメインごとに別々のアカウントを作成する必要があるはずだ。そうしないと、そのシークレットを知っている何者かが、アカウントが管理しているあらゆるドメインの証明書を作成できてしまうからね。

GeoIPブロックを行うVMホストを相手にする羽目になり、Let's Encryptなどがhttp-01/tls-alpn-01でドメインを適切に検証できないという問題に直面した。結局、CNAMEリダイレクトと、リダイレクトされたdns-01チャレンジを処理するカスタムの最小限のDNSサーバーを使うDIYソリューションに落ち着いた。本質的にはacme-dnsプロジェクトを大幅に簡略化して、自分のプロジェクトのニーズに合わせたもの（GoじゃなくてNode.jsで書いたやつ）だ。

残念ながらdns-persist-01ではDNSレコード自体にアカウント情報が含まれるため、私にとっては大きな障害になる。アカウント情報が変更されるたびにDNSレコードを変更しなければならなくなる。理由はどうあれ、クライアントにDNSレコードを更新させるのはずっと面倒な作業だったからね。

これでインターネットに公開されていないLANサーバー用にも、パブリックに信頼された証明書を取得するのがずっと楽になるな。

あらゆる管理UIで、DNSレコードに貼り付けるだけの文字列が生成できるようになって、すぐにLet's Encrypt証明書が取れるようになるのを楽しみにしてるよ。

俺が何か根本的に勘違いしているだけだろうか？ 理論上、これってドメインのDNSサーバーを管理している奴や、LEと自分のDNSサーバー間のトラフィックを制御できる奴なら誰でも、俺のドメインになりすませるTLS証明書を取得できるってことじゃないの？

DNS-01でも同じことが言えるんだろうけど、これなら攻撃者が俺の代わりに自分のLEアカウントをDNS応答に入れれば証明書が取れるから、より簡単になるよね。

いっそのこと、パブリック証明書をDNSレコードにそのまま置いてそれで完了、じゃダメなのかな？

certbotを使っている人向けの情報だけど、この機能のサポート状況の追跡はこちらで行われているよ: https://github.com/certbot/certbot/issues/10549