DNSとは?仕組みからセキュリティリスクまで知っておきたい基礎知識

DNSルックアップとは?

ドメイン・ネーム・システム(DNS)ルックアップとは、ユーザーがブラウザのアドレスバーにURLを入力してからページが読み込まれるまでの間に起こるプロセスのことです。技術的に言えば、URL(例：www.google.com)をIPアドレスへ変換する仕組みを指します。

IPアドレスは、私たちの住所のようなものです。手紙を届けるときに住所を使うように、コンピュータはIPアドレスを使って特定の場所へデータを送信します。IPアドレスは長い数字の羅列でとても覚えにくいため、コンピュータはDNSを利用して、覚えやすいURLとIPアドレスの相互変換を行っています。なお、インターネットに接続されているすべてのデバイスには、必ずIPアドレスが割り当てられています。

DNSはどのように機能するのか

インターネットの規模を考えると、一台のコンピュータがすべてのIPアドレスを記憶しておくことは不可能です。そのため、ブラウザにwww.google.comと入力すると、コンピュータはそのウェブサイトのIPアドレスを検索する動作を行います。

まず、コンピュータはローカルメモリである「キャッシュ」を確認します。ここには最近訪問したサイトのIPアドレスが保存されており、再検索の手間を省いてページを高速に表示できるようになっています。ただし、キャッシュには直近の少数のサイトしか残っていないため、目的のIPアドレスが見つからないケースがほとんどです。

ステップ1(番号は上の図に対応): 次に、コンピュータはISP(インターネットサービスプロバイダ)のローカル再帰ネームサーバーへ問い合わせます。ISPとは、Time Warner Cable、Spectrum、Verizonのようなインターネット接続事業者のことです。「ネームサーバー」と聞くと難しく感じますが、実態は「www.google.comのIPアドレスは何か?」といったDNSの問い合わせに答えるために設計されたサーバーソフトウェアにすぎません。

どのネームサーバーでもこの質問に答えることは可能です。答えを知っていればIPアドレスを返し、知らなければ「分からない」と応答して別のサーバーへ問い合わせるよう促します。再帰ネームサーバー(recursive nameserver)が特別なのは、答えを知らない場合に、単に問い合わせを転送するのではなく、自ら答えを探し出す作業まで行う点です。すべてのネームサーバーが再帰型というわけではありません。

ステップ2: 再帰ネームサーバーはまず自身のキャッシュを確認します。そこにIPアドレスがなければ、ルートネームサーバーへ問い合わせます。ルートネームサーバーはIPアドレスそのものを把握していませんが、リクエストを読み取り、次にどこへ問い合わせるべきかを再帰ネームサーバーに教えてくれます。すべての再帰ネームサーバーには、13個のルートネームサーバーのIPアドレスがあらかじめ設定されており、そのうちの一つを選んで同じ質問(「www.google.comのIPアドレスは何か?」)を投げかけます。

ステップ3: ルートネームサーバーはトップレベルドメイン(TLD/リクエストの末尾部分)を読み取ります。この場合「.com」です。そして、再帰ネームサーバーに対し、gTLD(Global Top Level Domain)サーバーへ問い合わせるよう指示します。gTLDは、.com、.net、.eduなどドメインの種類ごとの参照リストのような存在です。個々のウェブサイトのIPアドレスは知りませんが、どのネームサーバーがその情報を保有しているかは把握しています。

ステップ4: 再帰ネームサーバーは、gTLDネームサーバーに対してwww.google.comのIPアドレスを問い合わせます。

ステップ5: gTLDネームサーバーはリクエストの次の部分を右から左へ読み取ります(この場合はwww.google.comの「google」の部分)。そして、問い合わせ先となる権威ネームサーバー(authoritative nameserver)の情報を返します。権威ネームサーバーとは、そのドメインを管理し、一次情報源となるネームサーバーのことです。

ステップ6: 再帰ネームサーバーは、権威ネームサーバーに同じ質問(「www.google.comのIPアドレスは何か?」)を投げかけます。技術的には、サーバーはアドレスレコード(Aレコード)を要求しています。Aレコードとは、サーバーがIPアドレスを参照するときに用いる記録のことです。

ステップ7: このサーバーが答えを持っています! IPアドレスを再帰ネームサーバーへ返し、「権威ある回答」であることを示すフラグを付けます。再帰ネームサーバーは、近いうちに誰かが同じサイトへアクセスした場合に備えて、そのIPアドレスをキャッシュに保存します。キャッシュ内の各項目には「TTL(Time to Live)」と呼ばれる有効期限が付けられており、サーバーはその期間が経過すると情報を削除します。

ステップ8: 再帰ネームサーバーが、あなたのコンピュータにIPアドレスを伝えます。今回は「権威ある回答」のフラグは付きません。一次情報源ではないためで、単に情報を中継しているだけだからです。

ステップ9: コンピュータは、受け取ったばかりのIPアドレス宛てにwww.google.comへのリクエストを送信します。

ステップ10: そのアドレスにあるWebサーバーがGoogleのホームページを返し、ページが表示されます。

この一連のプロセス全体はわずか数ミリ秒で完了し、毎日何兆回も繰り返されています。

DNSはエンドユーザーにどんな影響を与えるのか

インターネットの機能に不可欠なDNSは、ハッカーにとって格好の標的となります。DNSの根本的な問題は、現代のテクノロジーにおける多くのセキュリティ課題と共通しています。インターネットや私たちが日常的に使う多くの技術は、もともと少数の研究者向けに設計されたものであり、時とともに全世界が利用するシステムへと拡大しました。DNS(HTTPやその他の主要プロトコルも同様)は、セキュリティを考慮して設計されたものではありません。そのため、後からさまざまなセキュリティ対策を追加せざるを得なくなりました。残念ながら、後付けのセキュリティ対策は、開発段階から組み込まれたものほど効果的ではありません。

これがDNSにもたらす問題の一つは、レスポンスを受信した際にネームサーバーの真正性を検証する仕組みがないことです。そのため、ハッカーはコンピュータのDNSクエリに対して悪意のある応答を送りつけ、それを本物のDNSネームサーバーからの回答だと誤認させることができます。言い換えれば、コンピュータが「www.chase.comのIPアドレスは何か?」と尋ねたとき、ハッカーはDNSサーバーより先に、自分が管理する悪意のあるサイトのIPアドレスを返すのです。すると、読み込まれたサイトは本物のchase.comそっくりに見えますが、実際はハッカーが制御しています。

これはフィッシングに非常によく似ています。ただし、ユーザーが悪意のあるリンクをクリックさせられるのではなく、ユーザーがアクセスしようとした正規のサイトが、DNSルックアップを通じて偽サイトへ誘導される点が異なります(こちらの方がはるかに危険で、防御も困難です)。この場合、ユーザー自身が警戒し、サイトが偽物であることに気づく必要があります(リンクの見た目が微妙に違う、スペルミスがある、ロゴの出来が粗いなど)。しかし、これを見抜くのは非常に難しく、ユーザーがある程度技術に精通していることが前提となります。

2016年には、DNS攻撃によって米国東海岸の広範囲でインターネットがほぼ丸一日にわたり麻痺しました。この障害の原因はDDoS攻撃でした。DDoS攻撃(Distributed Denial of Service:分散型サービス拒否攻撃)とは、インターネット上の数千台のマシンが同時に一つのシステムを攻撃する手法です。通常、これらのマシンは所有者に気づかれないままマルウェアに感染しており、一人またはグループのハッカーがすべてを遠隔操作しています。こうしたマシン群は、一括して利用される際に「ボットネット」と呼ばれます。

ボットネットは標的のサーバーへ大量のDNSリクエストを送りつけ、その膨大な量でシステムを圧倒し、正当なトラフィックを処理できない状態に陥れます。その結果、ハッカーがDNSサーバーを攻撃している間は、コンピュータがIPアドレスを要求してもサーバーが応答できず、そのサーバーが管理する(権威を持つ)サイトには、攻撃が止むまでアクセスできなくなります。

この種の攻撃への対策としては、余剰需要に耐えられるようサーバーを過剰にプロビジョニングする方法や、DNSファイアウォールを導入する方法があります。

DNSが抱える多くの問題に対する、より包括的な解決策がDNSSECです。DNSSECは、公開鍵暗号方式に基づくデジタル署名によって認証を強化します。要するに、要求されたデータの所有者がデジタル署名を行うことで、前述のようななりすまし応答が起こらないようにする仕組みです。これにより、データ発生源の認証(データが本当にリゾルバが想定する発生源から来たものであること)と、データ完全性の保護(転送中にデータが改ざんされていないこと)が実現されます。

残念ながら、DNSを根本的に改善するには、DNSSECの広範な普及が必要不可欠です。ネットワーク運営者が再帰リゾルバ上で、またドメイン名の所有者が権威サーバー上で、それぞれ明示的に有効化しなければなりません。これはまだ十分には実現していませんが、DNSが抱える問題への理解が深まり、より多くの人々が改善を求める声を上げることで、今後の普及が期待されています。