ホストにIPだけを使ってる公開XMPPサーバーってあるの？聞いたことないけど、内部ではそういうのがあるかもしれないね。

主に趣味でやってる人たちや、プロジェクトにホスト名を結びつけたくない一回限りのケースが多いんじゃないかな。

"オポチュニスティック" DoTLSをauthdnsサーバーに向けるのは面白いかもね。authdnsサーバーのパブリックIPに合ったSANを含む証明書でDoTLSポートをリッスンしてるかもしれないし。（今はauthdnsサーバーのホスト名でできるけど、1つのパブリックauthdns IPに対して色んな名前があるから、これでより明確に結びつけられるかも。）

インフラにDNSエントリーがない機器が結構あると思うから、これは仕事で活用できそう。

一般的ではないけど、バニティIPのケースはあるよ。https://1.1.1.1の証明書は、IPとドメイン名one.one.one.oneの両方に対して署名されてる。

DNSが大規模に再設計されている間に有効な証明書を持っていたいこともあるよね。例えば、ダッシュボードを使えるようにしたり、DNSの問題で古い自動化が失敗しないように三重に確認したり。場合によっては、DNSが全く必要ないこともある。シンプルさやDNSの伝播からの独立を重視するなら、テスト環境でCockpitをすぐに公開できるよね。ここでは想像力だけが制限だね。

他にも良いユースケースを持ったレスポンスがたくさんあるけど、NTSについては見なかったな。NTSを使いたいけどIP証明書が取れないなら、信頼できる時間を得るためにDNSが必要になるよね。DNSがダウンしていると、時間を取得できない。DNSSECの一般的な問題は、間違った時間を持つことで、検証失敗を引き起こすことだよ。DNSSECが強制されていて間違った時間を持っていると、NTSがDNSに依存している場合、回復する方法がなくて運が悪いことになる。証明書の一部としてIPを持つことで、DNSの要件なしに信頼できる時間を得られるから、壊れたDNSSECの強制を修正できるんだ。

ESNI/ECHだけでも大きな話だね。暗号化されたサーバー名インディケーション（ESNI）に対する主な反論の一つは、Cloudflareのような巨大なHTTPSプロキシサービスにしか効果がないってことだった。IP証明書のアイデアが提案されたけど、夢物語として却下されたんだ。IPアドレス証明書があれば、今やすべてのサーバーがESNIに参加できるようになるから、巨人だけじゃなくなる。もしクライアントがすべてのウェブサーバーがIP証明書を持っていると仮定して、すべての接続でESNIを使おうとするようになれば、インターネット全体のプライバシーにとって大きな恩恵になるかもしれないね。

ローカルや開発環境での作業には便利かもね。my-dev-env.staging.service.comとか設定しなくてもHTTPSをテストできるし。

一つの使い道は、ホスト名を使わずにDoT（TLS経由のDNS）サーバーに直接接続することだね。OpenSSLを使ってIPアドレスにTLS接続をすると、IP SANを検証して、そこにないと失敗するよ。