Chromium の機能の XNUMX つは、ルート DNS サーバーに大きな負荷を引き起こします

Google Chrome と新しい Microsoft Edge の親である人気のオープンソースである Chromium ブラウザは、善意で意図された機能、つまりユーザーの ISP が存在しないドメイン クエリ結果を「盗んでいるかどうか」をチェックする機能のために、大きな否定的な注目を集めています。 。

イントラネット リダイレクト検出器は、統計的に存在する可能性が低いランダムな「ドメイン」に対して偽のクエリを作成し、世界中のルート DNS サーバーが受信する総トラフィックの約半分を占めています。 ベリサインのエンジニア、マット・トーマスは長文を書いた。 投稿する APNIC ブログで問題について説明し、その規模を評価しています。

DNS 解決は通常どのように実行されるか

これらのサーバーは、.com、.net などを解決するために連絡する必要がある最高機関であるため、frglxrtmpuf がトップレベル ドメイン (TLD) ではないことがわかります。

DNS (ドメイン ネーム システム) は、コンピュータが arstechnica.com などの記憶に残るドメイン名を、3.128.236.93 などのあまり利便性の低い IP アドレスに解決できるシステムです。 DNS がなければ、インターネットは人間にとって役立つ形で存在しません。つまり、上位レベルのインフラストラクチャに不必要な負荷がかかることが大きな問題となります。

最新の Web ページを 93 つ読み込むには、膨大な数の DNS ルックアップが必要になる場合があります。 たとえば、ESPN のホームページを分析したとき、a.espncdn.com から z.motads.com に至るまで、XNUMX の個別のドメイン名が数えられました。 ページを完全に読み込むには、これらはすべて必要です。

全世界にサービスを提供する必要がある検索エンジンのこの種のワークロードに対応するために、DNS はマルチレベルの階層として設計されています。 このピラミッドの最上位にはルート サーバーがあり、.com などの各トップレベル ドメインには、その下の各ドメインの最高権限を持つ独自のサーバー ファミリがあります。 ワンステップアップ これらの サーバーはルートサーバーそのものであり、 a.root-servers.net до m.root-servers.net.

これはどのくらいの頻度で起こりますか?

DNS インフラストラクチャのマルチレベル キャッシュ階層のおかげで、世界中の DNS クエリのうちルート サーバーに到達するのはごくわずかです。 ほとんどの人は、DNS リゾルバー情報を ISP から直接取得します。 ユーザーのデバイスが特定の Web サイトにアクセスする方法を知る必要がある場合、まずそのローカル プロバイダーが管理する DNS サーバーにリクエストが送信されます。 ローカル DNS サーバーが答えを知らない場合、要求を独自の「フォワーダー」 (指定されている場合) に転送します。

ローカル プロバイダーの DNS サーバーにも、その構成で指定された「転送サーバー」にもキャッシュされた応答がない場合、要求は権限のあるドメイン サーバーに直接送信されます。 上記 変換しようとしているもの。 いつ домен.com これは、リクエストがドメイン自体の権威サーバーに送信されることを意味します。 comにあります。 gtld-servers.net.

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

ほとんどの場合、ネームサーバーのレコードは ドメイン.com これらのフォワーダーの XNUMX つにすでにキャッシュされているため、ルート サーバーが妨害されることはありません。 ただし、ここでは、私たちがよく知っているタイプの URL、つまり通常の Web サイトに変換される URL について話します。 Chrome リクエストはレベルにあります 上記 これはクラスター自体のステップ上にあります root-servers.net.

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

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

Google Chrome、新しい Microsoft Edge、および無数のあまり知られていないブラウザの親プロジェクトである Chromium ブラウザは、「オムニボックス」とも呼ばれる単一のボックスでの検索の容易さをユーザーに提供したいと考えています。 言い換えれば、ユーザーは実際の URL と検索エンジンのクエリの両方をブラウザ ウィンドウの上部にある同じテキスト フィールドに入力します。 簡素化へのもう XNUMX つのステップとして、ユーザーが URL の一部を次のように入力する必要はありません。 http:// または https://.

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

会社のイントラネット上のユーザーが「マーケティング」と入力し、会社のイントラネットに同じ名前の社内 Web サイトがある場合、Chromium はユーザーに「マーケティング」を検索するか、次のサイトにアクセスするかを尋ねる情報ボックスを表示します。 https://marketing。 これは当てはまらないかもしれませんが、多くの ISP や公衆 Wi-Fi プロバイダーは、スペルミスのある URL をすべて「ハイジャック」し、ユーザーをバナーだらけのページにリダイレクトします。

ランダム生成

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

残念なことに、ネットワークでは、 ノー DNS クエリの結果を盗む場合、これら XNUMX つの操作は通常、ルート ネーム サーバー自体に至るまで最上位に到達します。ローカル サーバーは解決方法を知りません。 qwajuixkしたがって、このリクエストをフォワーダーに転送し、最終的にフォワーダーも同じことを行います。 a.root-servers.net そうでなければ、彼の「兄弟」の一人が「申し訳ありませんが、ここはドメインではありません」と言う必要はありません。

長さが 1,67 ～ 10 文字の範囲の偽のドメイン名は約 21*XNUMX^XNUMX 個存在する可能性があるため、最も一般的なのは それぞれ 「正直な」ネットワーク上で実行されるこれらのテストにより、ルート サーバーに到達します。 これは同じくらいの金額になります 半分 クラスターのその部分からの統計に従って、ルート DNS の総負荷から root-servers.net、Verisign が所有しています。

歴史は繰り返される

最善の意図を持って作成されたプロジェクトはこれが初めてではありません 失敗した または、パブリック リソースが不必要なトラフィックで溢れかえるところでした。これはすぐに、2000 年代半ばの D-Link と Poul-Henning Kamp の NTP (Network Time Protocol) サーバーの長く悲しい歴史を思い出させました。

2005 年、デンマークで唯一の Stratum 1 Network Time Protocol サーバーを所有していた FreeBSD 開発者 Poul-Henning は、送信トラフィックに対して予期せぬ多額の請求書を受け取りました。 端的に言えば、その理由は、D-Link 開発者が、Kampa サーバーを含む Stratum 1 NTP サーバーのアドレスを、同社のスイッチ、ルーター、およびアクセス ポイントのファームウェアに書き込んだためです。 これにより、Kampa のサーバー トラフィックは即座に 9 倍に増加し、Danish Internet Exchange (デンマークのインターネット交換ポイント) は料金を「無料」から「年間 000 ドル」に変更しました。

問題は、D-Link ルーターが多すぎることではなく、それらが「ラインから外れている」ことでした。 DNS と同様に、NTP は階層形式で動作する必要があります。Stratum 0 サーバーは Stratum 1 サーバーに情報を渡し、Stratum 2 サーバーは情報を Stratum 2 サーバーに渡し、以下同様に階層を下っていきます。 D-Link が NTP サーバー アドレスをプログラムしたような一般的なホーム ルーター、スイッチ、またはアクセス ポイントは、リクエストを Stratum 3 または Stratum XNUMX サーバーに送信します。

Chromium プロジェクトは、おそらく最善の意図を持って、DNS 問題で NTP 問題を再現し、インターネットのルート サーバーに、処理するつもりのなかったリクエストをロードしました。

迅速な解決が期待されています

Chromium プロジェクトにはオープンソースがあります 虫この問題を解決するには、デフォルトでイントラネット リダイレクト ディテクタを無効にする必要があります。 Chromium プロジェクトの功績を認めなければなりません: バグが見つかりました 前にVerisign の Matt Thomas 氏がどのようにして彼の作品で多くの注目を集めたか 役職 APNICブログで。 このバグは XNUMX 月に発見されましたが、トーマスの投稿まで忘れられたままでした。 断食後、彼は厳重な監視下に置かれ始めた。

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

広告の権利について

エピックサーバー - です Windows 上の VPS または、強力な AMD EPYC ファミリ プロセッサと非常に高速な Intel NVMe ドライブを搭載した Linux。 急いで注文してください！

出所： habr.com