最初に、世界のルーツDNSサーバーからのトラフィックの半分近くを受け取る立場を立てています。そして、問題を詳細に説明するために、Verisignのエンジニアは以下の部分で説明します。
DNS 解決の動作
ドメイン ネーム システムは、208.80.154.224 のような単純な IP アドレスとしてwikipedia.orgのようなより複雑なドメイン名を変換して記憶するように動作します。DNSが存在しなければ、インターネットは人間が理解しやすくなった形で存在することはできませんでした。しかし、それはトップレベルのインフラストラクチャに不必要な負荷があり、問題を引き起こすことも意味します。
最新の Web ページを 1 つ読み込むと、目まぐるしい数の DNS ルックアップが表示されます。したがって、負荷を管理しやすい状態に保つために、DNS は階層システムで動作するように設計されています。最上位には、最上位ドメインのルート サーバーがあり、最終的には .com を持ち、その下のすべてのドメインに権限を与えるサーバー ファミリも存在します。その上には、m.root-servers.netをa.root-servers.netルートサーバーもあります。
問題が発生する頻度
構造の階層により、ルート DNS サーバーに到達する DNS クエリの比率は非常に小さいです。DNS リゾルバ情報の大部分は ISP から直接取得されます。
したがって、デバイスがwikipedia.comに到達したい場合は、最初のクエリがローカルの ISP DNS サーバーに送信され、応答しない場合は、独自の “フォワーダ” が役立ちます 。キャッシュに応答しない場合、クエリは、gtld-servers.netで、com自体である権限のあるサーバーに直接行きます。
その後、gtld-servers システムは、wikipedia.com ドメインに対する権限のあるネームサーバーのリストをクエリに応答し、そのうちの 1 つは、そのようなネームサーバーの IP アドレスを含む 1 つの “グルー” レコードを持ちます。
これで、その答えはチェーンに戻り、すべての転送がクエリを転送したサーバーに応答を渡し、最終的な回答はローカル ISP サーバーとユーザーのコンピュータの両方に到達します。
クエリの大多数は、転送サーバーの 1 つにキャッシュされ、ルート サーバーが応答に使用される可能性はまれです。しかし、これまでのところ、私たちは通常のURLについて話してきました – 通常のウェブサイトに関連付けられているもの。Chromeのクエリは、実際のroot-servers.netクラスタリング自体に対して、それ以上のレベルに達する可能性があります。
クロム&NXドメインハイジャック試験
クロムブラウザは、ユーザーが基本的にブラウザの上部にある同じ小さなテキストボックスに実際のURLと検索エンジンクエリを入力することを可能にする「Omnibox」と呼ばれるシングルボックス検索オプションをユーザーに提供することを使命としています。また、ユーザーはURLの一部http://入力したりhttps://したりしないように簡単に提供します。しかし、この方法は簡単に行えるから、URL と検索クエリの違いをブラウザ自身が理解するように強制します。スペースを含む 1 つのエントリは明らかに URL ではないため、これは明らかだと思うかもしれませんが、イントラネットが関与する場合は問題になります。
このケースをより良く説明するために、会社のイントラネット上の「ネットワーク」と入力した場合、会社のイントラネット上の「ネットワーク」とシステムに同じ名前の内部 Web サイトがある場合、情報バーが表示され、ユーザーがネットワークを検索したかどうかを確認するか、ユーザーをリダイレクトするかを尋ねられます。 https://networking.ほとんどのシナリオでは良いかもしれませんが、多くのISPと共有WiFiプロバイダは依然として誤って入力されたすべてのURLをハイジャックしています。
Chromiumの著者は、これらの一般的な環境のすべての検索にインフォバーが表示されるという意味を決して望んでいなかったので、テストを実施した解決策を提案しました。ネットワークの起動時または変更時に、Chromium はランダムに生成された 7 ~ 15 文字の最上位レベルの “ドメイン” に対して DNS ルックアップを発行し始めます。
2 つの要求が同じ IP アドレスで応答すると、Chromium は、ローカル ネットワークが現在受信する NXDOMAIN エラーを乗っ取りしていると自動的に見なします。したがって、その結果、すべての単一単語のエントリを検索の試みとして扱い始め、さらなる通知が出されるまで行われます。
しかし、運が悪く、ネットワークがDNSクエリ結果を乗っ取っていない場合、これらの3つのルックアップはルートネームサーバーまで行きます:ローカルサーバーはqwajuixkを解決する方法を知らず、クエリはa.root-servers.netまたはその兄弟の1人が「申し訳ありません」という通知を思い付くまで転送され続けます。、それはドメインではありません。
7 文字から 15 文字の偽のドメイン名の可能性が 1.67*10^21 あるため、正直なネットワーク上で発行されるプローブの大半は最終的にルート サーバーを悩ませてしまいます。これにより、ベリサインのroot-servers.netクラスタ部分の統計が真である場合、ルートDNSサーバーの総負荷の半分が合計されます。
しかし、解決はすぐに来ます!
これは、2000年代半ばからD-LinkとポールヘニングカンプのNTP(ネットワークタイムプロトコル)サーバーの悲しい話がすでに存在するので、よく作られたプロジェクトが不必要なトラフィックで公共リソースを圧倒した最初の例の1つではありません。
良い部分については、この問題を解決するためにイントラネットリダイレクトディテクタをデフォルトで無効にするよう既に要求しているクロムプロジェクトにはすでにオープンなバグがあり、VerisignのMatt Thomasがそれに注目を集める前にバグがすでに開かれていたことも意味します – バグは6月に実質的に開かれましたが、トーマスのAPNICブログ記事の後に毎日注目を集めました。
それにもかかわらず、この問題が解決されるという期待は高く、その結果、世界のルートDNSサーバーは毎日600億件の無駄なクエリに答える必要はありません。