Systems Approach先週、systemsapproach.org ドメインで DNSSEC（Domain Name System Security Extensions）を有効化しました。称賛する必要はありません。この技術について学びながら、導入の障壁となる可能性のあるものを理解しようとしただけです。
大手プロバイダー（私たちはGoDaddyを使用しています）でドメインをホストしている場合、DNSSECの有効化は簡単です。しかし、DNSSECの有効化にこれほど長い時間がかかったこと（そして新しいセキュリティ関連書籍の執筆という刺激があったこと）は、多くのことを物語っていると思います。対照的に、2025年にHTTPSなしでウェブサイトを運営することは考えられません。
ここ数ヶ月、私は新著の執筆においてインフラストラクチャセキュリティに焦点を当ててきました。これらの技術はエンドユーザーを直接対象としていないため、導入の実態に関する情報を収集するのは困難でした。数週間前に報告したように、インターネットルーティングのセキュリティ確保に向けた長く緩やかなプロセスには、いくつかの明るい兆しが見えています。特に、ルートオリジン検証（ROV、現在50%以上）の導入と、ASプロバイダー認証（ASPA [PDF]）の導入が挙げられます。しかし、ドメインネームシステムもまた、攻撃に対する脆弱性が広く知られている重要なインフラストラクチャです。私たちは、そのセキュリティ確保をどのように進めているのでしょうか？
DNSSECの問題の核心はユーザーの可視性の欠如である
インターネット協会は、インターネットを支える様々な「基盤技術」の導入状況を示す便利なダッシュボードを公開していますが、DNSSECは34%と、おそらく最も普及率の低い技術と言えるでしょう。HTTPバージョン3の普及率はわずか25%ですが、DNSSECに関する最初のRFCが公開されてから28年が経過しているのに対し、HTTPバージョン3はわずか4年で普及を達成しました。一方、DNSSECとほぼ同じくらいの年数であるHTTPSは、世界の上位1,000ウェブサイトの96%で導入されています。
ダッシュボードに加えて、DNSSEC の失敗を明らかにする 2 つのブログも見つけました。APNIC の Geoff Huston 氏は「DNSSEC の終焉か?」と書き、インターネット協会の Edward Lewis 氏はそれに続いて「DNSSEC はどこで失敗したのか?」と書いています。これら 2 つのブログで列挙されている欠点と最適ではない設計上の決定の累積リストを見ると、私自身が展開リストにもう 1 つのドメインを追加したにもかかわらず、DNSSEC 展開の大きな増加はすぐには見られないと確信しました。
ヒューストン氏は、DNSSECの開発時期がSSL/TLSやHTTPSと類似していること、そしてそれらが実現する信頼モデルが異なることを指摘しています。どちらも1990年代半ばに登場し、Webがインターネットをより広範なユーザーに普及させ始めた頃でした。DNSへの攻撃は1990年代から存在が知られています。DNSSECの目的は、DNSの名前からアドレスへの変換機能が攻撃者の干渉を受けることなく正しく実行されたことをクライアントに保証することです。言い換えれば、DNSSECは、入力したドメイン名に対応するIPアドレスと実際に通信していることを保証するのです。
対照的に、TLSは、証明書に記載されているエンティティによって管理されているサーバーと通信していることを保証します。もちろん、ほとんどの人はIPアドレスも証明書も確認しません。標準的なTLS実装では、問題がない場合、ブラウザに南京錠アイコンが表示されます（証明書が無効な場合は警告が表示されます）。通常、これだけでユーザーはサイトのセキュリティが確保されていると安心できます。
これはDNSSECの核心、つまりユーザーへの可視性の欠如に繋がっていると思います。DNSSECでは、ユーザーが接続したいサイトに接続していることを直接的に認識させることができません。systemsapproach.orgではDNSSECが無料で簡単に有効化できたので有効化できましたが、サイト訪問者の体験は変わりませんでした。もしDNSプロバイダーが有料サービスだとしたら、私はそのサービスにいくら支払ってもいいと思うでしょうか？
近い将来、DNSSECの導入が大きく増加することはないだろう。
対照的に、数年前に私が管理する別のドメイン（地元のランニングクラブ用）のためにTLS証明書を実際に購入しました。これは、サイトが検索エンジンでより見つけやすくなり、ユーザーにとってより「信頼できる」と感じられるようになるという真の価値をもたらすと信じていたからです。DNSSECから、追加料金を支払うだけの価値があるかどうかは分かりませんが、幸いなことに、実際には支払う必要はありませんでした。
DNSSEC検証
DNSSECが正しく動作しているかどうかを示す小さな南京錠アイコンが見当たらなかったので、DNSSECの動作を検証できるツールを探してみたところ、VerisignのDNSSECデバッガーとオープンソースのDNSvizツールという優れたツールがいくつか見つかりました。どちらも、ルートゾーンから.orgゾーンを経由してsystemsappproach.orgゾーンに至るまで、信頼チェーンが確立されていることを示しています。
DNSvizというウェブサイトは、あらゆるウェブサイトの信頼チェーンを非常に詳細にグラフ化して表示してくれます。以下は、systemsappproach.org向けにDNSvizが作成したものです。
dnsviz.net で作成された systemsapproach.org の DNSSEC 認証チェーンの図 - クリックして拡大
トランスポート層セキュリティ (TLS) の認証局によって信頼チェーンがどのように確立されるかを知っていれば、これは非常に馴染み深いものになるはずです。
しかし、この信頼チェーンとTLSを区別する興味深い点は、鍵の署名を取得する際に認証局（CA）を選択できないことです。私たちのドメインは.orgドメインに属しているため、鍵の署名は.orgドメインに依存しています。もし、DNSSECを実装していない親ドメイン（例えば、国レベルドメインの約30%がこれに該当します）の配下にあった場合、私たちは運が悪くなります。ルートからリーフまでDNSSECの実装に依存しているという点が、DNSSECがHTTPSほど発展していないもう一つの理由です。
TLSとDNSSECのこれまでの比較から、ブラウザとウェブサイト間のセキュリティはTLSを使って処理すれば安心できると思われがちですが、DNSのセキュリティについては依然として懸念すべき理由が数多くあります。DNSトラフィックの改ざんは、検閲の手段として日常的に利用されており、「DNS検閲の付随的被害」でも詳しく報告されています。この論文で驚くべき点の一つは、中国国内のDNS検閲が、中国国外で発信・着信したものの、運悪く中国のISPを経由するクエリにどれほど影響を与えているかということです。
- エンジニアとしてキャリアアップするには、優れたコミュニケーション能力を身につける
- 根本からセキュリティを組み込むとはどういう意味ですか?
- 一部の人とは異なり、トレースルートは非常に現実的です。私はそれが機能するのを手伝ったのでよく知っています。
- パスキーがパスワードに取って代わることはあるでしょうか？本当にあるのでしょうか？
これは中国に限った話ではありません。（例えば、米国は中国版TikTokへのアクセスを阻止するために独自のグレートファイアウォールを必要とするのでしょうか？）DNSがどのように検閲に利用されているかについては、より最近の報告書「The Lock Net」が発表されています。検閲の回避策は、それ自体で記事（あるいは書籍）を書くほどの大きなテーマです。私がこの問題を提起したのは、DNSのセキュリティ確保を決して諦めるべきではないことを示唆するためです。
TLSが広く普及している今日では、DNSクエリと応答をTLSで保護されたチャネル経由で送信するための標準的な方法が存在するのも当然のことです。この目的を達成するための類似の提案がいくつかあり、IETFはDNS over TLS（DoT）とDNS over HTTPS（DoH）の両方をRFC 8484で標準化しています。それぞれのメリットについては議論がありますが、この記事の目的においては、その違いはそれほど重要ではありません。DoHはほとんどのウェブブラウザで設定できます。
これらのアプローチは、目的のDNSリゾルバへの安全なチャネルを確保しますが、リゾルバから提供されるDNS情報が正しいという保証はありません。接続先のリゾルバの身元はTLS証明書によって確認できるため、また、リゾルバから送信されたクエリと応答は暗号化され認証されているため、中間者によって改ざんまたは傍受されていないことも確認できます。しかし、DNS階層の上流からリゾルバに提供された情報が破損しているなど、リゾルバ自体が誤った情報を提供している場合、クライアントはそれを知ることができません。
したがって、階層の上位までDNSSECを導入する必要があることは導入の障害となるものの、クライアントとリゾルバ間のチャネルを単に保護するだけでは得られないレベルのセキュリティを提供します。実際、DNSSECとDoH/DoTは補完的なものと考えることができます。DNSSECはリゾルバ内の情報の正当性を保証し、DoH/DoTはクライアントからリゾルバへの安全なチャネルを確保します。
完全性を期すために、DoHを拡張してDNSトラフィックの監視をより困難にするOblivious DNSについても触れておきたいと思います。これはAppleのプライベートリレーで使用されている複数の技術の一つであり、Cloudflareのブログにも掲載されています。
では、これは一体どういうことなのでしょうか？DNSSECの導入率の低さは、私にとっては一種の障害のように思えますが、インターネットユーザーのほとんどは、DNS解決よりもHTTPSによって提供されるアプリケーションレベルのセキュリティを重視しています。しかし、DNSはインターネットの運用にとって依然として基盤であり、攻撃は続くため、DNSSEC自体が多少失敗に終わったとしても、セキュリティ向上に向けた取り組みが継続されることを願っています。®
