【解説】DNSによる名前解決について解説します

インターネットを利用する上で、最も基本的でありながら、エンジニアとして避けては通れない技術が「DNS(Domain Name System)」です。

Webサイトの閲覧、メールの送受信、そしてクラウドサービスの利用など、あらゆる通信の裏側でDNSは稼働しています。しかし、その仕組みを「電話帳のようなもの」という理解だけで止めてしまってはいないでしょうか。

本記事では、インフラエンジニアの視点から、DNSの名前解決フローを詳細に解説します。また、昨今のセキュリティトレンドであるSASE(Secure Access Service Edge)におけるDNSの重要性についても触れていきます。

DNSとは何か:インターネットの基盤技術

DNSは、人間が理解しやすい「ドメイン名(例:https://www.google.com/search?q=google.com)」と、コンピュータが通信に使用する「IPアドレス(例:142.250.xxx.xxx)」を紐付けるシステムです。

インターネット上のサーバーはIPアドレスによって識別されますが、数字の羅列であるIPアドレスを人間がすべて記憶することは不可能です。そこで、意味のある文字列であるドメイン名を使い、それをIPアドレスに変換する仕組みが必要となりました。この変換プロセスを「名前解決(Name Resolution)」と呼びます。

ドメインの階層構造

DNSを理解するには、ドメイン名の階層構造(ツリー構造)を理解する必要があります。ドメインは右側から左側へと階層が深くなっていきます。

  • ルート(.): 全てのドメインの頂点。通常は省略されますが、ドメイン名の末尾には見えないルートが存在します。
  • トップレベルドメイン(TLD): com, jp, net, orgなど。
  • セカンドレベルドメイン(SLD): google, yahoo, exampleなど。
  • サードレベルドメイン: www, mailなど(ホスト名とも呼ばれます)。

この階層構造ごとに管理者が分担されており、分散型データベースとして機能していることが、DNSが30年以上インターネットを支え続けている理由です。

DNSを構成する4つの主要な登場人物

名前解決のフローを追う前に、登場する4つの主要なサーバー(役割)を定義します。ここを混同するとフローが理解できなくなります。

1. スタブリゾルバ(クライアント)

PCやスマートフォンなどの端末内に組み込まれているDNSクライアント機能です。ブラウザなどからの要求を受け、後述するDNSキャッシュサーバーへ問い合わせを行います

2. フルリゾルバ(DNSキャッシュサーバー)

社内ネットワークやISP(プロバイダ)に設置されているサーバーです。クライアントからの問い合わせを受け、実際にインターネット上の権威サーバーへ聞き回る役割を担います。一度聞いた結果は一定期間保存(キャッシュ)し、再利用することで高速化を図ります

3. 権威DNSサーバー(コンテンツサーバー)

ドメイン名とIPアドレスの対応情報を実際に保持しているサーバーです。「自分の管理するドメインの情報」のみを回答します

4. ルートサーバー

DNSの階層構造の頂点に位置するサーバーです。世界中に13の論理的なサーバーが存在し、TLD(comやjpなど)の権威サーバーの場所を知っています

DNS名前解決の詳細フロー

それでは、実際にクライアントPCが「www.example.co.jp」にアクセスしようとした際の、完全な名前解決フローを解説します。

ここでは、キャッシュが存在しない「初回アクセス」の状態を想定します。

ステップ1:クライアントからフルリゾルバへの問い合わせ

PC(スタブリゾルバ)は、ネットワーク設定で指定されたフルリゾルバ(DNSキャッシュサーバー)に対して、「www.example.co.jp のIPアドレスを教えてください」と問い合わせます。これを「再帰的問い合わせ(Recursive Query)」と呼びます。

ステップ2:フルリゾルバからルートサーバーへ

フルリゾルバは答えを知らないため、まずインターネットの頂点であるルートサーバーに「www.example.co.jp を知っていますか?」と尋ねます。これを「反復問い合わせ(Iterative Query)」と呼びます。

ステップ3:ルートサーバーからの回答

ルートサーバーは個別のドメイン情報は持っていませんが、「jp」を管理しているサーバーのIPアドレスは知っています。そこで、「私は知らないけれど、jpのDNSサーバーなら知っているから、そっちに聞いてみて」と回答します。

ステップ4:jpのDNSサーバーへの問い合わせ

フルリゾルバは、紹介されたjpのDNSサーバーに対して、再度「www.example.co.jp を知っていますか?」と尋ねます。

ステップ5:jpのDNSサーバーからの回答

jpのDNSサーバーは、「co.jp」を管理しているDNSサーバーのIPアドレスを教えます。「co.jp のサーバーに聞いてみて」という回答です。

ステップ6:co.jpのDNSサーバーへの問い合わせ

フルリゾルバは、次にco.jpのDNSサーバーへ問い合わせます。

ステップ7:co.jpのDNSサーバーからの回答

co.jpのDNSサーバーは、「example.co.jp」を管理している権威DNSサーバーのIPアドレスを教えます。

ステップ8:example.co.jpの権威サーバーへの問い合わせ

フルリゾルバは、ついに目的のドメインを管理する権威DNSサーバーへ辿り着きます。「www.example.co.jp のIPアドレスを教えてください」と尋ねます。

ステップ9:最終的な回答

権威DNSサーバーは、自身のゾーンファイル(設定ファイル)を参照し、「www.example.co.jp のIPアドレスは xxx.xxx.xxx.xxx です」と、最終的な正解(Aレコード)をフルリゾルバに返します。

ステップ10:クライアントへの回答

フルリゾルバは受け取ったIPアドレスをPC(スタブリゾルバ)に返却し、同時にその結果を自身のキャッシュメモリに保存します。これで名前解決が完了し、PCはWebサーバーへアクセスを開始します。

パフォーマンスを支える「キャッシュ」とTTL

上記のフローを毎回すべて実行していては、通信のたびに時間がかかり、ルートサーバーへの負荷も膨大になります。これを防ぐのが「キャッシュ」です

フルリゾルバは、一度取得した情報を一時的に記憶します。2回目のアクセス時には、ステップ2〜9を省略し、キャッシュから即座に回答します

このキャッシュの有効期限を決めるのが、権威サーバー側で設定される**TTL(Time To Live)**です。TTLが3600秒であれば、1時間はキャッシュが有効となります。DNSレコードの変更を行う際に、TTLを短く設定しておく必要があるのは、このキャッシュの影響を最小限にして新しい情報を早く行き渡らせるためです。

セキュリティ視点でのDNSとSASEの関連性

さて、ここまでが従来のインフラエンジニアとしての基礎知識ですが、ここからは現代のセキュリティトレンド、特にSASEとの関連性について解説します。

DNSはセキュリティの「最初の防衛線」

マルウェア感染やフィッシング詐欺の多くは、不正なドメインへの通信をきっかけに発生します。DNSリクエストは通信の最初に必ず発生するため、ここでセキュリティチェックを行うことは非常に効果的です。

従来は社内ネットワーク内のDNSサーバーでログを監視していましたが、テレワークの普及により、社員が社外から直接インターネットを利用するケースが増えました。これにより、社内のセキュリティ監視の目が届かなくなるという課題が生まれました。

SASEにおけるDNSセキュリティの役割

ここで登場するのがSASE(Secure Access Service Edge)です。SASEは、ネットワーク機能とセキュリティ機能をクラウド上で統合して提供するフレームワークです。

多くのSASEソリューションには「DNSセキュリティ」や「セキュアWebゲートウェイ」の機能が含まれています

  1. 通信の強制リダイレクト: ユーザーがどこにいても、DNSリクエストはSASEプロバイダのクラウドDNSに向けられます。
  2. 脅威インテリジェンスとの照合: SASE上のDNS機能は、リクエストされたドメインが「悪意あるサイト(C&Cサーバーやフィッシングサイト)」でないかを、最新の脅威データベースとリアルタイムで照合します。
  3. 接続前のブロック: もし危険なドメインであれば、名前解決の段階でブロック(IPアドレスを返さない、または警告ページのIPを返す)します。これにより、端末はそもそも不正なサーバーとTCPコネクションを確立することさえできません。

このように、DNSの仕組みを利用して、通信が発生する「前」の段階で脅威を排除するのが、SASEにおけるDNSセキュリティの強みです。

エンジニアが使うべき確認コマンド

最後に、DNSの挙動を確認するための基本的なコマンドを紹介します。トラブルシューティングの際に必須となります。

nslookup

Windowsでも標準で使用できる最も一般的なコマンドです。 nslookup www.google.com と打つだけで、使用しているDNSサーバーと解決されたIPアドレスが表示されます。

dig (Domain Information Groper)

LinuxやmacOSで標準的に使われる、より詳細な情報を取得できるコマンドです。 dig www.google.com と実行すると、フラグ情報、TTL、クエリ時間など、プロフェッショナルな解析に必要な情報が得られます。 dig +trace www.google.com オプションを使用すると、ルートサーバーから順に辿っていく様子(前述のステップ2〜9)を可視化できるため、学習用としても非常に優秀です。

まとめ

DNSはインターネットの根幹を支える技術であり、その名前解決フローは「階層構造」と「再帰・反復問い合わせ」によって成り立っています。

  • スタブリゾルバとフルリゾルバの役割分担
  • ルートから順に辿る反復問い合わせの仕組み
  • キャッシュとTTLによる負荷分散

これらの基礎を理解することは、ネットワークトラブルの解決だけでなく、SASEをはじめとする最新のセキュリティアーキテクチャを理解・設計する上でも不可欠な要素となります。

DNSは単なる「名前解決」の手段から、セキュリティの「コントロールポイント」へと進化しています。この機会に、ぜひご自身の環境で dig コマンドなどを叩き、実際のフローを体感してみてください。

より安全で快適なインフラ構築の一助となれば幸いです。