偽のウェブサイトを可能にした静かなDNSの欠陥
ウェブサイトにアクセスする際、コンピュータは「example.com」のような名前に接続するわけではありません。その代わりに、IPアドレスが必要です。コンピュータは、通常ルーターやISPであるリゾルバにリクエストを送信し、リゾルバがさまざまなDNSサーバーに問い合わせて正しいIPアドレスを見つけます。
初期のDNS応答は、リクエストと応答を照合するために単純な16ビットのトランザクションIDに依存していたため、脆弱でした。このIDはクエリの整理には役立ちましたが、送信者の身元を証明する暗号学的な証拠は提供しませんでした。攻撃者は偽の応答でリゾルバを氾濫させ、65,536通りのIDを推測し、正規の応答よりも先に偽の応答が到着すれば、リゾルバはそれを受け入れて悪意のあるデータをキャッシュしてしまいました。
この根本的な欠陥は、2008年にKaminsky attackが発見されたことで明白になりました。Dan Kaminskyは、存在しない任意のサブドメインを標的にすることで、ドメインの権威ネームサーバーレコードを迅速に汚染できることを実証しました。これにより、DNSキャッシュポイズニングの広範なリスクが露呈し、より安全なDNSアーキテクチャの緊急の必要性が強調されました。
長期的な解決策であるDNSSECは、2005年にすでに策定されていました。これは暗号化認証を導入し、ルートサーバーから個々のドメインサーバーに至るまで、DNSルックアップチェーンの各ステップが次のステップの真正性を検証できるようにしました。このシステムは信頼の連鎖を確立し、攻撃者が不正な情報を注入してユーザーを悪意のあるサイトへ誘導することを防ぎます。
信頼の連鎖は一つのルートキーで終わる
DNSの脆弱性に対する長期的な解決策であるDNSSECは、公開鍵暗号を使用してルックアップを保護します。各署名者は、DNSデータにデジタル署名を生成するためのプライベートキーと、検証用の対応するパブリックキーを持っています。リゾルバはこれらのパブリックキーを使用して、DNSデータが転送中に改ざんされていないことを確認し、その真正性を保証します。
信頼の連鎖はDNSルートから個々のドメインへと広がります。リゾルバが example.com をルックアップする際、まずルートサーバーに問い合わせ、ルートサーバーが .com トップレベルドメイン（TLD）サーバーを保証します。次に .com サーバーが example.com 自身のDNSサーバーを保証します。各親ゾーンは子ゾーンのパブリックキーに暗号学的に署名し、途切れることのない検証パスを作成します。
ルートゾーンの Key Signing Key (KSK) はユニークであり、それを認証するより上位のDNS権限は存在しません。そのため、そのパブリックキーはDNSSECを検証するすべてのリゾルバにおいて、トラストアンカーとして事前に設定されている必要があります。KSKのプライベートキーを制御する者は誰でも偽のルートデータに署名でき、DNSの信頼の連鎖全体を損なう可能性があります。この重要なプライベートキーは、非常に安全なエアギャップ環境にあるHardware Security Moduleに保持されており、厳密に管理された多人数参加型のキーセレモニーの間にのみアクセスされます。
一つのキーを秘密に保つために構築されたセレモニーの内部
ルートキーの秘密を維持するには、バージニア州カルペパーの安全な施設で実行される、精巧で多層的なセキュリティプロトコルが必要です。ICANNとPublic Technical Identifiers (PTI) によって運営されるこの施設は、プライベートキーを生成および保存する Hardware Security Modules (HSMs) を保護しています。セレモニーが行われる部屋へのアクセスには、複数のセキュリティチェックポイント、ロックされたケージ、そしてHSM自体を収めた金庫を通過する必要があります。
署名プロセスは複数人によるセーフガードです。ICANNから独立したグローバルなインターネットコミュニティから選出された7名のCrypto Officerが、それぞれの貸金庫のセキュリティキーを保持しています。HSMを起動して保護された操作を実行するには、最低3名のCrypto Officerが物理的に立ち会い、それぞれの固有のセキュリティキーを挿入する必要があります。
セレモニーは一般公開され、記録されることで透明性が確保されています。参加者は信頼された読み取り専用のオペレーティングシステムからラップトップを起動し、その暗号学的フィンガープリントを声に出して検証します。3つのセキュリティキーが挿入されると、単一のコマンドによってエアギャップ環境にあるHSM内でキー生成プロセスが開始されます。秘密鍵は、暗号化されたバックアップとして以外、この安全な環境から外に出ることはありません。2024年のキーにおける「38696」のような新しいキーの識別子が記録され、最後に全参加者がペーパースクリプトに署名してプロセスが完了します。これらの手順の詳細については、IANA Root KSK Ceremoniesのドキュメントを参照してください。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
ルートキーのロールオーバーで何が変わるのか
キーのロールオーバーでは、新しいKey Signing Key (KSK)が導入され、ルートゾーンのDNSKEYレコードセットの有効な署名鍵として古いものと置き換わります。新しいキーは数ヶ月前に生成・認証されますが、実際の「ロールオーバー」は、それが主要な署名鍵となり、その公開鍵コンポーネントがすべてのDNSSEC検証リゾルバーにとってのトラストアンカーとして利用可能になった時点で発生します。
このトラストアンカーの更新に失敗すると、重大な障害が発生する可能性があります。古い公開鍵を持つリゾルバーは、新しいKSKによって生成された署名を検証できず、署名済みドメインに対するすべてのDNS応答を拒否します。その結果、ユーザーにはSERVFAILエラーが表示され、サーバーが完全に稼働していてもウェブサイトにアクセスできないように見えてしまいます。
ISPやCloudflareの1.1.1.1、Googleの8.8.8.8といったパブリックサービスが提供する最新のDNSSEC検証リゾルバーは、通常、自動化されたトラストアンカー更新を採用しており、リスクの大部分を軽減しています。しかし、古いルーターのファームウェアや手動で設定されたシステムでは対応が遅れる可能性があり、明示的な更新が必要になる場合があります。ロールオーバーと同時期にDNS障害が発生した場合は、ルーターのファームウェアやリゾルバーソフトウェアを更新することが最初の対策として有効です。DNSSECによる保護は、署名済みドメインと検証リゾルバーの両方に依存していることを忘れないでください。
よくある質問
インターネットのDNSSECマスターキーとは何ですか？
これはルートゾーンのKey Signing Key (KSK)の秘密鍵部分であり、ルートゾーンのDNSSECキーに署名するために使用されます。その公開鍵部分は、検証リゾルバーが検証を行うためのトラストアンカーとなります。
なぜDNSにDNSSECが必要なのですか？
DNSSECは暗号学的署名を追加することで、検証リゾルバーがDNSデータが本物であり変更されていないかを確認できるようにし、偽造された回答が受け入れられるのを防ぐのに役立ちます。
ルートキーのロールオーバーによってインターネット接続が切断されることはありますか？
新しいトラストアンカーを学習していない検証リゾルバーを使用しているユーザーにおいて、DNSの混乱を引き起こす可能性があります。リゾルバーが応答を拒否し、多くの場合SERVFAILを返すことがあります。
ルートキーはどのように保護されていますか？
秘密鍵は安全なハードウェア内に保持されており、キー操作には複数の権限を持つ参加者が必要です。セレモニーでは、管理された施設、文書化された手順、および公開記録が使用されます。