DNS（ドメイン・ネーム・システム）とは

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

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

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

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）が管理するようになりました。

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

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

再帰サーバー（再帰リゾルバーまたはDNSリゾルバーとも呼ばれます）は、通常、インターネット・サービス・プロバイダー（ISP）、大企業、またはその他のサードパーティーのDNSサービス・プロバイダーによって管理されます。これらはエンド・ユーザーに代わってドメイン名をIPアドレスに解決します。また、再帰リゾルバーは、同じドメインへの将来のクエリーのシステム効率を向上させるために、リクエストに対する回答を一定期間（TTL（存続可能時間）の値で定義される）キャッシュします。

ユーザーが検索ブラウザーにWebアドレスを入力すると、ブラウザーは再帰DNSサーバーに接続してリクエストを解決します。再帰サーバーに応答がキャッシュされている場合、ユーザーに接続してリクエストを完了できます。そうでない場合、再帰リゾルバーは一連の権威DNSサーバーに問い合わせてIPアドレスを検索し、ユーザーを目的のWebサイトに接続します。

権威サーバーは「回答」を提供します。権威ネーム・サーバーは、ドメインの最終的な記録を保持し、それぞれのゾーン内に格納されているドメイン名に関するリクエストに応答します（通常は、ドメイン所有者によって構成された回答で応答）。権威ネーム・サーバーにはさまざまな種類があり、それぞれがDNS階層内で特定の機能を果たしています。

権威DNSネーム・サーバーには以下のものがあります。

ルート・ネーム・サーバーはDNS階層の最上位に位置し、ルート・ゾーン（DNSの中央データベース）の管理を担当します。ルート・ゾーン内に格納されているレコードに対するクエリーに回答し、適切なTLDネーム・サーバーにリクエストを照会します。

13の異なるルート・サーバー・ネットワーク（AからMの文字で識別）を照会するために使用される13のIPアドレスがあります。これらは、TLDのリクエストを処理し、適切なTLDネーム・サーバーにクエリーを送信します。Internet Corporation for Assigned Names and Numbers（ICANN）は、これらのルート・サーバー・ネットワークを運営しています。

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

ドメイン・ネーム・サーバー（セカンドレベル・ドメイン・ネーム・サーバーと呼ばれることもあります）は、「ibm.com」などの完全なドメイン名のIPアドレスを含むゾーン・ファイルを保持します。

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

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

ユーザーがブラウザーやアプリに「ibm.com」などのドメイン名を入力すると、そのリクエストが再帰DNSリゾルバーに送信されます。通常、ユーザーのデバイスには、インターネット・サービス・プロバイダー（ISP）によって提供された定義済みのDNS設定があります。これにより、クライアントがどの再帰リゾルバーにクエリーを実行するかが決定されます。

再帰リゾルバーは、キャッシュ（Webブラウザーやオペレーティング・システム（macOS、Windows、Linuxなど）内の一時記憶装置で、過去のDNSルックアップを保持しているもの）をチェックし、ドメインに対応するIPアドレスを探します。再帰リゾルバーのキャッシュにDNSルックアップ・データがない場合、リゾルバーは権威DNSサーバーからデータを取得するプロセスをルート・サーバーから開始します。再帰リゾルバーは、最終的なIPアドレスが見つかるまでDNS階層にクエリーを実行します。

再帰リゾルバーはルート・ネーム・サーバーにクエリーを実行し、ルート・ネーム・サーバーは該当ドメインの適切なTLDサーバー（この例では「.com」ドメインを担当するTLDネーム・サーバー）への参照で応答します。

リゾルバーは「.com」TLDネーム・サーバーにクエリーを実行し、ネーム・サーバーは「ibm.com」の権威ネーム・サーバーのアドレスで応答します。このサーバーは、セカンドレベル・ドメイン・ネーム・サーバーと呼ばれることもあります。

リゾルバーはドメインのネーム・サーバーにクエリーを実行し、ネーム・サーバーはDNSゾーン・ファイルを検索し、指定されたドメイン名の正しいレコードで応答します。

再帰リゾルバーは、レコードのTTLで指定された時間の間だけDNSレコードをキャッシュし、IPアドレスをユーザーのデバイスに返します。ブラウザーまたはアプリは、そのIPアドレスのホスト・サーバーへの接続を開始して、要求されたWebサイトまたはサービスにアクセスできます。

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

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

DNSゾーン・ファイルは2つの必須レコードで始まります。1つはローカルDNSキャッシュにレコードをどのように保存するかを示すグローバルTTL（存続可能時間）で、もう1つはDNSゾーンの一次権威ネームサーバーを指定するSOA（Start of Authority）レコードです。

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

AレコードはIPv4アドレスにマッピングされ、AAAAレコードはIPv6アドレスにマッピングされます。

MXレコードは、ドメインのSMTPメール・サーバーを指定します。

CNAMEレコードは、ホスト名を別名から別のドメイン（「正規ドメイン」）にリダイレクトします。

NSレコードは、ドメインの権威ネーム・サーバーを示します。

PTRレコードは、IPアドレスをドメイン名にマッピングする、逆DNSルックアップを指定します。

TXTレコードは、電子メール認証のSender Policy Frameworkレコードを示します。

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

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

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

組織はDNSを使用する際に、パブリックDNSとプライベートDNS、またはその2つの組み合わせなど、さまざまな選択肢があります。パブリックDNSとプライベートDNSはまったく別のものです。組織のニーズを満たすためにDNSを最適に使用する方法を理解するには、それぞれのタイプがどのように機能するかを理解することが重要です。

マネージドDNSソリューションは、基本的にサーバー管理とオーケストレーション・プロセスをアウトソーシングします。マネージド・システムでは、DNSプロバイダーが組織のDNSサーバーのすべての設定、メンテナンス、セキュリティー・プロトコルを処理し、クライアントはプロバイダーのインフラストラクチャーを使用してドメイン名を管理します。この場合、ユーザーが企業のURLを入力すると、企業のドメイン・ネーム・サーバーからプロバイダーのサーバーにリダイレクトされ、プロバイダーのサーバーがすべてのリソースを取得してユーザーに応答します。

マネージドDNSは、専用DNS、グローバルなサーバーの負荷分散、アップタイム保証、APIファースト・アーキテクチャー、DNSSECサポート、グローバル・エニーキャスト・ネットワーク、伝搬時間の短縮、モニタリングおよびヘルス・チェック・ツール、DDoS保護などのサービスやメリットも提供できます。

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

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

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

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

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

ドメイン・ハイジャックは、攻撃者がドメイン登録者のアカウントに不正アクセスし、ドメインの登録詳細を変更することで発生します。ハイジャックにより、悪意のある攻撃者はトラフィックを悪意のあるサーバーにリダイレクトしたり、Eメールを傍受したり、ユーザーのオンライン ID を制御したりすることができます。

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

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

• DNSセキュリティー拡張機能（DNSEC）と仮想プライベート・ネットワーク（VPN）の導入：DNSSECは、DNS応答にデジタル署名を要求することで、DNSルックアップにセキュリティー・レイヤーを追加します。具体的には、DNSSECは、リクエストの発信元を認証し、DNSデータの完全性を検証することで、DNSスプーフィング攻撃から保護できます。
  
  VPNは、暗号化によってIPアドレスを不明瞭にすることで秘匿性を確保し、（中でも）位置情報や閲覧履歴などのデータを追跡できないようにします。
  
  
• レート制限の導入：DNSサーバーのレート制限により、指定された期間内に1人のリクエスターに対する応答の数、またはサーバーが応答を送信するレートを制限することで、DDoS攻撃を緩和できます。
  
  
• ドメイン・レジストラーへの二要素認証（2FA）の義務付け：ドメイン・レジストラー・アカウントに2FAを確立することで、攻撃者がサーバーへの不正アクセスを行うことがより困難になり、ドメイン・ハイジャックのリスクが軽減されます。
  
  
• 冗長構成の使用：地理的に分散した複数のサーバーにDNSを冗長構成で配置することで、攻撃や障害が発生した場合でもネットワークの可用性を確保できます。プライマリー・サーバーがダウンした場合、セカンダリー・サーバーがDNS解決サービスを引き継ぐことができます。
  
  
• DNSフラッシュの実装：DNS キャッシュを定期的にクリアすると、ローカル・システムからすべてのエントリーが削除されます。これは、ユーザーを悪意のあるサイトに誘導する可能性のある無効なDNSレコードや侵害されたDNSレコードを削除するのに役立ちます。
  
  
• DNSの脅威に関する最新情報の入手：攻撃者とセキュリティーの脅威は、侵害されるシステムと同じように進化します。最新のDNSの脆弱性と脅威を常に把握することは、チームは悪意のある攻撃者に先んじて対処するのに役立ちます。