🙍🏾 🍗 🚳 Chromiumの機能の1つは、ルートDNSサーバーに大きな負荷をかけます。 🤣 🎃 🎅🏽

急速に拡大しているGoogleChromeと新しいMicrosoftEdgeのオープンソースの親であるChromiumブラウザは、ユーザーのISPが存在しないドメインクエリ結果を盗んでいるかどうかをチェックする意図的な機能に対して深刻な否定的な注目を集めています。統計的に存在する可能性が低いランダムな「ドメイン」に対して偽のクエリを作成する

IntranetRedirect Detectorは、世界中のルートDNSサーバーが受信する総トラフィックの約半分を占めています。VerisignのエンジニアであるMattThomasは、APNICブログに、問題を説明し、その規模を評価する長い投稿を書きました。

DNSルックアップが通常行われる方法

これらのサーバーは、.com、.netなどを解決するために連絡する最終的な権限であるため、frglxrtmpufはトップレベルドメイン（TLD）ではないことがわかります。

DNS（ドメイン名システム）は、コンピューターがarstechnica.comなどの記憶に残るドメイン名を3.128.236.93などのあまり便利ではないIPアドレスに変換できるシステムです。 DNSがなければ、インターネットは人間に優しい形で存在することができません。つまり、トップレベルのインフラストラクチャへの不要な負荷が実際の問題になります。

単一の最新のWebページをロードするには、想像を絶する量のDNSルックアップが必要になる場合があります。たとえば、ESPNホームページを分析したところ、a.espncdn.comからz.motads.comまでの93の個別のドメイン名を数えました。ページを完全にロードするには、それらすべてが必要です。

DNSは、全世界にサービスを提供する必要があるこの種のワークロードを処理するためのマルチレベル階層として設計されています。このピラミッドの最上部にはルートサーバーがあります。.comなどの各トップレベルドメインには、その下の各ドメインの最終的な権限である独自のサーバーファミリーがあります。上記一つのノッチこれらのサーバーは、ルートサーバー自体からですa.root-servers.netへm.root-servers.net。

これはどのくらいの頻度で発生しますか？

DNSインフラストラクチャの階層化されたキャッシング階層により、世界のDNSクエリのごく一部がルートサーバーに到達します。ほとんどの人は、DNSリゾルバー情報をISPから直接取得します。ユーザーのデバイスが特定のサイトにアクセスする方法を知る必要がある場合、要求は最初にそのローカルプロバイダーによって管理されているDNSサーバーに送信されます。ローカルDNSサーバーが応答を知らない場合、ローカルDNSサーバーは要求を独自の「フォワーダー」（指定されている場合）に転送します。

ローカルISPのDNSサーバーもその構成済みの「フォワーダー」もキャッシュされた応答を持っていない場合、要求は、解決しようとしているドメインの上のドメイン内の権限のあるサーバーに直接ルーティングされます。いつ.comこの要求は、ドメイン自体の権威サーバに送信されることを意味しますcomに位置しています、gtld-servers.net。要求が行われた

システムgtld-serversは、domain.comドメインの権限のあるネームサーバーのリストと、そのようなネームサーバーの1つのIPアドレスを含む少なくとも1つのブリッジレコードで応答します。次に、応答はチェーンをたどります。各フォワーダーは、応答が最終的にローカルプロバイダーのサーバーとユーザーのコンピューターに到達するまで、これらの応答を要求したサーバーに渡します。同時に、高レベルのシステムを不必要に妨害しないように、それらはすべてこの応答をキャッシュします。

ほとんどの場合、ネームサーバーはdomain.comを記録しますこれらのフォワーダーの1つにすでにキャッシュされているため、ルートサーバーが妨害されることはありません。ただし、ここでは、通常のWebサイトに変換されるURLの通常の形式について説明します。Chromeクエリは、クラスター自体のラングで、それより上のレベルにありますroot-servers.net。

ChromiumおよびNXDomainの盗難チェック

Chromiumは「このDNSサーバーは私をだましているのですか？」をチェックします。 VerisignDNSルートサーバークラスターに到達するすべてのトラフィックのほぼ半分を占めます。

Google Chromeの親プロジェクトであるChromiumブラウザー、新しいMicrosoft Edge、および数え切れないほどのあまり知られていないブラウザーは、「オムニボックス」と呼ばれることもある単一のフィールドでの検索をユーザーに簡単に提供したいと考えています。つまり、ユーザーはブラウザウィンドウの上部にある同じテキストボックスに実際のURLと検索エンジンクエリの両方を入力します。単純化に向けてさらに一歩進んで、ユーザーにhttp://またはを使用してURLの一部を入力するように強制することもありませんhttps://。

便利かもしれませんが、このアプローチでは、ブラウザがURLとして何をカウントし、検索クエリとして何をカウントするかを理解する必要があります。ほとんどの場合、これは非常に明白です。たとえば、スペースを含む文字列をURLにすることはできません。しかし、イントラネット（実際のWebサイトを解決するためにプライベートトップレベルドメインを使用することもできるプライベートネットワーク）を検討すると、事態はさらに複雑になる可能性があります。

ユーザーが会社のイントラネットで「マーケティング」と入力し、会社のイントラネットに同じ名前の内部Webサイトがある場合、Chromiumは、ユーザーに「マーケティング」を検索するか、にアクセスするかを尋ねる情報ボックスを表示します。https://marketing..。大丈夫ですが、多くのISPやパブリックWi-Fiプロバイダーは、スペルミスのあるURLをすべて「ハイジャック」し、バナー広告でいっぱいのページにユーザーをリダイレクトします。

ランダム生成

Chromiumの開発者は、通常のネットワークのユーザーが1つの単語を検索するたびに情報ウィンドウを表示して意味を尋ねることを望まなかったため、テストを実装しました。ブラウザを起動するとき、またはネットワークを変更するときに、Chromiumはランダムに生成された3つの「ドメイン」のDNSルックアップを実行します。トップレベル、7〜15文字の長さ。これらの要求のいずれか2つが同じIPアドレスで返される場合、Chromiumは、ローカルネットワークがNXDOMAIN受信するはずのエラーを「盗んでいる」と見なすため、ブラウザーは、同じ単語から入力されたすべてのクエリを、追って通知があるまで検索の試行と見なします。

残念ながら、そうでないネットワークではDNSクエリの結果を盗むと、これら3つの操作は通常、ルートネームサーバー自体の一番上に移動します。ローカルサーバーはqwajuixk解決方法を知らないため、この要求をフォワーダーに転送します。フォワーダーは、最終的に、a.root-servers.netまたは次のいずれかまで同じことを行います。彼の「兄弟」は「申し訳ありませんが、これはドメインではありません」と言わざるを得ません。

7〜15文字の長さの偽のドメイン名が約1.67 * 10 ^ 21ある可能性があるため、「公正な」ネットワークで実行されるこれらの各テストでは、ルートサーバーに到達するのが一般的です。これは、限りある半分クラスタの一部の統計によると、ルートDNS上の総負荷のroot-servers.netベリサインに帰属します。

歴史は繰り返す

善意のプロジェクトが公共のリソースを不要なトラフィックで溢れさせたり、ほぼ氾濫させたりしたのはこれが初めてではありません。2000年代半ばのD-LinkとPole-Henning CampNTPサーバーの長く悲しい歴史をすぐに思い出しました。バツ。

2005年、デンマークで唯一のStratum 1ネットワークタイムプロトコルサーバーも所有していたFreeBSD開発者のPoul-Henningは、送信されたトラフィックに対して予想外の高額な請求を受け取りました。つまり、D-Link開発者が、Campaサーバーを含むStratum 1 NTPサーバーのアドレスを、同社のスイッチ、ルーター、およびアクセスポイントのラインのファームウェアに登録したためです。これにより、Kampaサーバーのトラフィックが即座に9倍に増加し、デンマークのインターネット交換（デンマークのインターネット交換ポイント）の料金が「無料」から「年間9,000ドル」に変更されました。

問題は、D-Linkルーターが多すぎることではなく、「コマンドのチェーンに違反している」ことでした。DNSと同様に、NTPは階層的に機能する必要があります。Stratum0サーバーはStratum 1サーバーに情報を中継し、Stratum1サーバーはStratum2サーバーに情報を中継します。D-LinkがNTPサーバーアドレスを要求したような一般的なホームルーター、スイッチ、またはアクセスポイントは、Stratum2またはStratum3に要求を送信する必要がありました。Chromium

プロジェクトは、おそらく最善の意図を持って、NTPの問題を次の問題で繰り返しました。インターネットのルートサーバーに、処理する必要のないクエリをロードすることによるDNS。

迅速な解決策への希望があります

Chromiumプロジェクトには未解決のバグがあり、この問題を修正するには、デフォルトのイントラネットリダイレクト検出器を無効にする必要があります。私たちは、プロジェクトクロムへの敬意を払う必要があります：バグが発見された前に、ベリサインからマット・トーマスは彼に彼の大きな注目を集め、ポストAPNICブログインチバグは6月に発見されましたが、Thomasが投稿するまで忘れられていました。断食後、彼は注意深く見守られ始めた。

問題がすぐに解決され、ルートDNSサーバーが毎日約600億の偽のクエリに応答する必要がなくなることが期待されています。

Chromiumの機能の1つは、ルートDNSサーバーに大きな負荷をかけます。