DNSとは

DNSはしばしば「インターネットの電話帳」と呼ばれますが、より現代的な例えをするならば、スマートフォンが連絡先を管理するようにドメイン名を管理します。スマートフォンでは、簡単に検索できる連絡先リストに電話番号を保存することで、ユーザーが個々の電話番号を覚えておかなくても済むようにします。

同様に、DNSを使用すると、ユーザーはIPアドレスの代わりにインターネット・ドメイン名を使用してWebサイトに接続できます。例えば、Webサーバーが「192.0.2.1」にあることを覚えておく必要はなく、ユーザーは単にWebページ「www.example.com」にアクセスするだけで、目的の結果を得ることができます。

DNSの仕組みを理解するには、まず関連するコンポーネントを理解することが重要です。

DNSは当初から、急速に拡大するコンピューター・ネットワークに対応できる、ドメイン名解決へのより動的なアプローチを促進するために、階層的な分散データベース構造で設計されていました。階層は、ドット（.）で示されるルート・レベルから始まり、「.com」、「.org」、「.net」、または「.uk」や「.jp」のような国コードTLD（ccTLD）などのトップレベル・ドメイン（TLD）、そしてセカンドレベル・ドメインへと枝分かれしていきます。

DNSアーキテクチャーは、再帰サーバーと権威サーバーという2種類のDNSサーバーで構成されます。再帰DNSサーバーは、ユーザーをWebサイトに接続する情報を検索し、「問い合わせ」を行うサーバーです。権威サーバーは「回答」を提供します。

再帰サーバー（再帰リゾルバーまたはDNSリゾルバーとも呼ばれます）は、通常、インターネット・サービス・プロバイダー（ISP）またはサードパーティーのDNSサービス・プロバイダーによって管理されます。組織は独自のリゾルバーをホストして管理することもできます。

再帰リゾルバーは、エンド・ユーザーに代わってドメイン名をIPアドレスに解決します。また、再帰リゾルバーは、同じドメインへの将来のクエリーのシステム効率を向上させるために、リクエストに対する回答を一定期間（TTL（存続可能時間）の値で定義される）キャッシュします。

ユーザーがWebアドレスをWebブラウザーに入力すると、ブラウザーは再帰DNSサーバーに接続してリクエストを解決します。再帰サーバーに応答がキャッシュされている場合、ユーザーに接続してリクエストを完了できます。そうでない場合、再帰リゾルバーは、特定のドメインのIPアドレスを含むA（またはAAAA）レコードが見つかるまで、DNS階層をクエリーします。

権威ネーム・サーバーは、ドメインの最終的な記録を保持し、それぞれのゾーン内に格納されているドメイン名に関するリクエストに応答します（通常は、ドメイン所有者によって構成された回答で応答）。それぞれが名前空間の個別の部分を担当するさまざまな権威サーバーがあります。

ルート・ネーム・サーバーはDNS階層の最上位に位置し、ルート・ゾーン（DNSの中央データベース）にサービスを提供します。13のルート・ネームサーバーの「ID」または「権限」（ルート・サーバーの論理的なグループ）は、AからMの文字で識別されます。ルート・ゾーン内に格納されているレコードに対するクエリーに回答し、適切なTLDネーム・サーバーにリクエストを照会します。

TLDサーバーは、ジェネリック・トップレベル・ドメイン（gTLD）を含む、次のレベルの階層を管理する責任を負います。TLDネーム・サーバーは、そのTLD内の特定のドメインの権威ネーム・サーバーにクエリーを送信します。したがって、「.com」のTLDネーム・サーバーは「.com」で終わるドメインを送信し、「.gov」のTLDネーム・サーバーは「.gov」で終わるドメインを送信する、などとなります。

セカンドレベルのドメイン・ネーム・サーバー（ドメイン・ネーム・サーバーの大部分）は、完全なドメイン名（「ibm.com」など）のIPアドレスを含むゾーン・ファイルを保持します。

主要なサーバー・タイプに加えて、DNSはゾーン・ファイルといくつかのレコード・タイプを使用して、解決プロセスを支援します。ゾーン・ファイルは、DNSゾーン内の特定のドメインに関するマッピングと情報を含むテキストベースのファイルです。

ゾーン・ファイルの各行は、DNSリソース・レコード（特定のタイプまたはデータの性質に関する単一の情報）を指定します。リソース・レコードは、ユーザーがクエリーを送信すると、DNSがすぐにドメイン名を実行可能な情報に変換し、クエリーを正しいサーバーに転送できるようにします。

DNSゾーン・ファイルは2つの必須レコードで始まります。1つはドメインの権威ネーム・サーバーを示すネーム・サーバー（NS）レコードで、もう1つはDNSゾーンの一次権威ネーム・サーバーを指定するSOA（Start of Authority）レコードです。

ゾーン・ファイルには、2つのプライマリー・レコードの後に、いくつかの他のレコード・タイプを含めることができます。主なポイントは次のとおりです。

すべてのクエリー（DNSリクエストと呼ばれることもあります）は、同じロジックに従ってIPアドレスを解決します。クエリーが開始される方法はさまざまです。一般的な例として、Webブラウザーを使用しているユーザーを考えてみましょう。

ユーザーがWebブラウザーにURLを入力すると、ブラウザーはDNSリゾルバーにクエリーを送信し、リゾルバーは段階的に権威DNSサーバーにクエリーを実行し、関連付けられたIPアドレスを含むドメインのレコードを保持している権威ネーム・サーバーを見つけます。IPアドレスがブラウザーに返され、ユーザーはそのWebサイトに接続されます。

DNSのすべてのクエリー（DNSリクエストと呼ばれることもある）は、同じロジックに従ってIPアドレスを解決します。ユーザーがURLを入力すると、コンピューターは段階的にDNSサーバーにクエリーを実行し、ユーザーのリクエストに対応する適切な情報とリソース・レコードを探し出します。このプロセスは、DNSがそのドメインに関連付けられた権威DNSサーバーから正しい回答を見つけるまで続きます。

より具体的には、DNSにおけるクエリー解決には、いくつかの重要なプロセスとコンポーネントが含まれます。

• クエリーの開始
• 再帰リゾルバー
• ルート・サーバー
• TLDネーム・サーバー
• ドメイン・ネーム・サーバー（セカンドレベル・ドメイン・ネーム・サーバー）
• クエリーの解決

DNSルックアップには通常、3種類のクエリーが含まれます。

• 再帰クエリー
• 反復クエリー
• 非再帰クエリー

再帰クエリー

再帰クエリーは、再帰サーバーとDNSクライアントを接続し、ドメイン名を完全に解決するか、またはユーザーにエラー・メッセージを返し、ドメインを特定できないことを通知します。

反復クエリー

反復クエリーは、再帰リゾルバー（ローカルDNSサーバー）と非ローカルDNSサーバー（ルート、TLD、ドメイン・ネーム・サーバーなど）を接続し、ドメイン解決を必要としません。代わりに、サーバーは参照で応答する場合があります。つまり、ルート・サーバーは再帰リゾルバーにTLDを参照させ、TLDはリゾルバーに、回答を提供する権威サーバーを参照させます（回答が利用可能な場合）。したがって、反復クエリーは回答または参照のいずれかで解決されます。

非再帰クエリー

非再帰クエリーの場合、再帰リゾルバーはクエリーの回答がどこにあるかを既に知っているので、これらのクエリーは常に回答で解決されます。リゾルバは、再帰サーバーにキャッシュされた答えを見つけるか、DNSルートとTLDネーム・サーバーをスキップして、適切な権威サーバーに直接アクセスすることで、時間を節約します。例えば、再帰リゾルバーが以前のセッションでキャッシュされたIPアドレスを提供する場合、リクエストは非再帰クエリーとして認定されます。

DNSは基本的にパブリック・プロトコルです。パブリックDNSとプライベートDNSは必ずしも正確ではなく、普遍的に使用され、理解されている用語や概念ではなく、その使用法は不正確であることがよくあります。

パブリックDNSは、「標準的な」DNS解決プロセス、つまりパブリックDNSリゾルバーを指すために使用されることがよくあります。再帰リゾルバーは、公開されているDNSレコードを保持する一連の権威サーバーにクエリーを実行し、IPアドレスを特定し、最終的にユーザーとWebサイトを接続します。多くの場合、これはユーザーのISPまたはGoogleの「quad 8」パブリックDNSなどのDNS Servicesによって提供されるリゾルバーです。プライベート・リゾルバーは、パブリックDNSにクエリーを実行するように構成することもできますが、より一般的には制限されたネットワークや企業ネットワークで使用されます。

この標準的なDNSルックアップは、リゾルバーが公開されているため、またこれらの権威サーバー上のDNSレコードはインターネットにアクセスできる人なら誰でもアクセスできるため、パブリックDNSと呼ばれることもあります。

「プライベートDNS」の使用はさらに曖昧です。これは、DNS over TLS（DoT）やDNS over HTTPS（DoH）などの暗号化プロトコルの使用を説明するために使用されることもあります。ただし、これらは「プライベートDNS」ではなく、「プライバシー機能」または「プライバシー・プロトコル」とより正確に説明されます。解決プロセスは、リゾルバーが公開されているDNSを使用して必要なものを見つけるという点で、同じままです。この場合は、暗号化された転送で行われます

プライベートDNSは、アクセスが許可されたユーザーのみに制限される、企業ネットワークや仮想プライベートクラウドなどの閉じた内部ネットワーク内でのルックアップを指す場合もあります。このようなシステムでは、ローカルに構成されたプライベートのリゾルバーがプライベート・サーバーにクエリーを実行して、内部ネットワーク内のリソースとサイトを検索します。これらのサーバーは、プライベートゾーンと内部アドレスのみを提供するように構成されており、ネットワークは内部URLとアドレスをインターネットの他の部分から隠します。このタイプのプライベートDNSは、組織に優れた制御とセキュリティーを提供します。

この種のネットワークを構成する方法は数多くあります。1つの方法は、.localなどの特殊用途のドメインを使用することです。ローカル・ネットワークでの解決に使用されますもう1つは、インターネット上で一般に利用できるドメインのプライベート・サブドメインを設定することです。このプライベート・サブドメインは、内部ネットワーク内でリゾルバーを使用する個人またはエージェントのみが利用できます。

「パブリック」DNSと「プライベート」DNSの両方を組み合わせた一般的なエンタープライズ設定は、「スプリト・ホライズンDNS」または「スプリット・ブレインDNS」と呼ばれます。この構成では、内部リクエストについてはローカルのプライベート権威サーバーにクエリーを実行し、外部クエリーについては標準のDNSに依存するローカル・リカーサーが存在します。通常、ドメイン名のリスト、つまり一種の「許可リスト」があり、どのリクエストが内部サーバーに送信され、どのリクエストがパブリック・インターネットに転送されるかをサーバーに指示します。

マネージドDNSは、組織がDNSインフラストラクチャーのホスティング、オペレーション、管理をアウトソーシングできるようにするサードパーティー・サービスです。マネージドDNSでは、組織のドメインの権威DNSレコードは、プロバイダーのグローバルに分散されたサーバーネットワーク上でホストされます。多くの場合、マネージドDNSプロバイダーは、クライアントがDNSレコードやその他の設定を管理および自動化できるようにする集中コントロール・プレーン、ダッシュボード、またはAPIを提供しています。

マネージドDNSサービスは、多くの場合、エニーキャスト・ルーティング、ロードバランシング、アップタイムサービスレベルアグリーメント（SLA）、フェイルオーバー保護、DNSSEC、監視およびトラブルシューティングツールなどの機能を提供し、従来のセルフマネージドDNSセットアップよりも高速で信頼性が高く、より安全なドメイン解決を可能にします。

最近のDNSサーバーのほとんどは、パブリックDNSの場合でさえ、非常に安全です。ただし、最高のDNSシステムであっても、サイバーセキュリティーの問題には脆弱である可能性があります。ある種の攻撃はDNSの権威側を標的にし、ある種の攻撃は再帰側を標的にします。これらの攻撃には次のようなものがあります。

• DNSスプーフィング
• DNS増幅攻撃
• DNSトンネリング
• ドメイン・ハイジャック
• サブドメインの乗っ取り

DNSスプーフィング（キャッシュ・ポイズニングとも呼ばれる）は、攻撃者がDNSリゾルバーのキャッシュに偽のアドレス・レコードを挿入し、リゾルバーが不正なIPアドレスを返して、ユーザーを悪意のあるサイトにリダイレクトさせることで発生します。スプーフィングは、機密データを危険にさらし、フィッシング攻撃やマルウェアの配布につながる可能性があります。

DNS増幅は、攻撃者がDNSサーバーに小さなクエリーを送信し、その返信アドレスを被害者のIPアドレスに偽装するDDoS攻撃の一種です。これらの攻撃は、DNSプロトコルのステートレスな性質を悪用し、小さなクエリーで非常に大きな応答を生成できるという事実を利用します。

増幅攻撃の結果、DNSサーバーははるかに大量の応答を返し、ユーザー宛てのトラフィック量が増幅され、ユーザーのリソースが過大になります。これにより、DNSが機能しなくなり、アプリケーションがダウンする可能性があります。

DNSトンネリングは、HTTPのような非DNSトラフィックをDNSクエリーと応答内にカプセル化することで、セキュリティー対策を回避するために使用される技術です。攻撃者は、DNSトンネルを使用してマルウェア・コマンドを中継したり、侵害されたネットワークからDNS情報を窃取したりすることができ、多くの場合、検知を回避するためにDNSクエリーや応答内にペイロードをエンコードします。

廃止されたサービスを指すサブドメインの放置されたDNSエントリーは、攻撃者にとって格好の標的です。サービス（クラウド・ホストなど）が廃止されたにもかかわらず、DNSエントリーが残っている場合、攻撃者はサブドメインを要求し、その場所に悪意のあるサイトやサービスを立ち上げる可能性があります。

組織がどのDNSサービスを選択するかにかかわらず、セキュリティー・プロトコルを実装して、DNSアタック・サーフェスを最小化し、潜在的なセキュリティー問題を軽減し、ネットワーキング・プロセスにおけるDNSを最適化することが重要です。DNSセキュリティーを強化するために役立つ実践方法としては、次のようなものがあります。

• DNSセキュリティー拡張機能（DNSSEC）の導入。DNSSECは、DNS応答にデジタル署名を義務付けることで、DNSルックアップにセキュリティー層を追加します。DNSSECは、リクエストの発信元を認証し、DNSデータの完全性を検証することで、DNSスプーフィング攻撃から保護できます。

• レート制限の採用。DNSサーバーのレート制限により、指定された期間内に1人のリクエスターに対する応答の数、またはサーバーが応答を送信するレートを制限することで、DDoS攻撃を緩和できます。

• ドメインレジストラに二要素認証（2FA）を義務付ける。ドメイン・レジストラー・アカウントに2FAを確立すると、攻撃者がサーバーへの不正アクセスを行うことがより困難になり、ドメイン・ハイジャックのリスクが軽減されます。

• 冗長性の使用。DNSを地理的に分散した複数のサーバーに冗長構成でデプロイすることで、攻撃や障害が発生した場合でもネットワークの可用性を確保できます。プライマリー・サーバーがダウンした場合、セカンダリー・サーバーがDNS解決サービスを引き継ぐことができます。

• DNSフラッシュの実装DNSキャッシュをクリアすると、ローカル・ネットワークからすべてのエントリーが削除されます。これは、ユーザーを悪意のあるサイトに誘導する可能性のある無効なDNSレコードや侵害されたDNSレコードを削除するのに役立ちます。一般に、これはリゾルバー・オペレーターが提供するオンデマンド・サービスです。それ以外の場合、キャッシュはTTLの期限切れとともにクリアされます。
  
  
• DNSの脅威に関する最新情報の入手。攻撃者とセキュリティーの脅威は、侵害されるシステムと同じように進化します。最新のDNSの脆弱性と脅威を常に把握することは、チームは悪意のある攻撃者に先んじて対処するのに役立ちます。

DNSが登場する以前、インターネットは主に学術機関や研究機関が使用するコンピューターのネットワークとして成長していました。開発者は、SRI Internationalによって管理され、インターネット上のすべてのコンピューターに配布されたHOSTS.TXTと呼ばれる単純なテキスト・ファイルを使用して、ホスト名をIPアドレスに手動でマッピングしていました。しかし、ネットワークが拡大するにつれて、このアプローチは次第に通用しなくなっていきました。

HOSTS.TXTの限界に対処し、よりスケーラブルなシステムを構築するために、南カリフォルニア大学のコンピューター科学者Paul Mockapetrisは1983年にドメイン・ネーム・システムを発明しました。DNSの構築に貢献したインターネット先駆者たちの集団は、新システムの仕様を詳述した最初のRFC（Request for Comments）、RFC 882とRFC 883も作成しました。後にRFC 1034とRFC 1035が、以前のRFCに取って代わりました。

やがて、DNSの拡大に伴い、DNSの管理はIANA（Internet Assigned Numbers Authority）が担当するようになり、最終的には、1998年に非営利団体であるICANN（Internet Corporation for Assigned Names and Numbers）が管理するようになりました。