🖥️

DNSの名前解決を雰囲気でしか理解していないので調べてみた URLを入力してからIPアドレスが返るまで〜

に公開
2026/03/22

はじめに(なぜこの記事を書いたか)

「資格勉強で名前解決という単語が出てきてなんとなく知っているが、流れを説明しろと言われると凄く怪しい....」

このようなことがきっかけで、不安を覚えたので一度勉強し整理しました。

本記事のゴール

DNS名前解決の全体像を一連の流れで説明できるようになる ←今回はここまで

dig の結果を見て「何が起きているか」を理解できる。


DNSとは(ざっくり)

まず大前提として、ネットワークに繋いでいるコンピューターなどをホストと呼びインターネットで通信するためには、相手先を決めるため何らかの形で特定する必要があり、IPアドレスを使うことで相手と通信をすることができます。

192.0.0.67

しかし、数字の羅列だけでは覚えにくいし、どこにアクセスするんだろうって疑問になりますよね。

名前で表現すると

api.prod.example.com
db.internal.example.com

これだと、数字の羅列よりは直感的で覚えやすいです。

また、IPアドレスのみで管理すると、元々のIPアドレスがルータ等の再起動で変更になることをユーザーは意識しなければなりません。変更したことを知らずにアクセスすると繋ぎたい相手とは別の相手に繋がってしまう可能性があります。なので名前(文字列)関連づけてサーバー側で情報を更新すれば、IPアドレスの変更をユーザーが意識しなくてもユーザーは同じ名前でアクセスし続けられます。

名前を分解すると

example.co.jp
│        │   │
│        │   └─ jp  ── トップレベルドメイン (TLD)
│        └──── co  ── セカンドレベルドメイン (2LD)
└──────── example ── サードレベルドメイン (3LD)

TLD どのDNSがこのTLDを管理しているかを示す
2LD 組織・用途単位の管理
3LD 実際のサービス・ホスト名
こんな風に分解することができます。本当は最後のjpに「ドット.」がついていますが通常は省略され見えないです。後に解説しますがドットは重要であり、階層構造のルート(頂点)を示しています。

DNSの階層化と委任

昔は、hostsというIPアドレスとホスト名の正式名、別名が書かれたhostsファイルがありました。
Windowsの場合C:\Windows\System32\drivers\etc\hostsにあります。

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost

インターネット全体で一つの管理者が、このhostsファイルを使い名前やIPアドレスが重複しないように管理していましたが、ホスト名が多くなると、新しいホストを追加するたびに管理者へ申請が必要なり、修正・削除もすべて対応しなければならないため、ホスト数に比例して作業量が増加していきました。

解消するための方法が階層化と委任です。

会社に例えると

営業部、開発部、総務部といった部門(階層)を作ります。社長 → 部門長 → メンバーという構造になりこれが階層化 です。
委任は、社長は営業部長は誰かだけを把握し、営業部の中身(人事・業務)は営業部長が管理する。つまり、上位の管理者は「誰に任せたか」だけ管理し実際の責任は任された側(営業部長)が持つこれが委任です。
規模の小さい会社であれば、社長が社員を直接かつフラットに管理することも可能であり、そのほうが運営しやすい場合もあります。しかし、会社の規模が拡大すると、社長一人で全体を把握し指揮管理するのは難しいです。
階層化と委任を採用することで、各部門の役割、責任を階層レベルに明確にした組織体制を構築することが可能になります。そうして従業員はそれぞれの部門長のもとで管理され業務に専念します。この二つの仕組みを適切に活用することで、企業はより柔軟で効率よく運営できるようになります。

DNS に当てはめると

DNS では、名前空間(例:example.com)呼ばれる空間を全体で共有し、会社組織のように扱います。

ルート(最上位)
→ .com を管理する組織に委任

.com
→ example.com を管理する組織に委任

example.com
→ www.example.com や mail.example.comを管理

それぞれが任された自分の範囲(ゾーンという)だけ責任を持つことで、責任の範囲が明確で負担も軽減でき管理もしやすくなりました。

インターネットの名前が一意の理由

インターネットの名前が一意の理由は階層化と委任をもとに理解するとわかりやすいです。
被らないように管理できることがhostsファイルのメリットでした。
管理の仕方が階層化と委任になってもメリットが失われないように、頂点を1つにする形で設計されました。このような頂点から枝分かれしていく木のような構造を「木構造」といいます。

木構造では、.ドットを頂点として枝分かれした先のそれぞれの階層で名前が重複しないように管理することで、名前空間全体の名前が1つのみ、つまり、一意になることを保証できます。

名前解決の全体像

問い合わせと応答

名前解決の基本は問い合わせと応答で三つの決まりがあります。

  1. 問い合わせと応答は、必ず一対一で対応。

  2. 情報知りたい人はドメイン名と種類(例:IPv4ならAレコード) を指定して問い合わせる。

  3. 提供者は受け取った問い合わせに対し、自分が知っている情報を応答する。

依頼者

  • スタブリゾルバ
    DNSリクエストを送信のみのクライアントPC
    役割: google.com のIPアドレスを知りたいと依頼を出して、自分では答えを探し回らず、次の「解決する人」に依頼を出します。

提供者

  • フルリゾルバ(ISPなど)
    役割: スタブリゾルバから依頼を受け取り、必要に応じて複数のDNSサーバへ問い合わせ(反復問い合わせ)を行い、最終的な結果を取得して返却します。また「場所なら知ってますよ/ありませんよ」と即答したり、知らない場合は次の「提供する人」に聞きに行ったりします。

  • ルートDNSサーバ
    最上位に位置し、DNSにおける名前解決の起点となる重要なサーバ。知りたいIPアドレスを教えずに、次どこへ聞けばいいかを教えてくれます。会社における受付窓口に近い存在です。

  • 権威DNSサーバ
    別名 コンテンツサーバ ドメインを所有する企業や組織が管理しているサーバ。
    役割: 「google.com の住所はここです」という アンサーを持っている人です。
    あるゾーンに対して正式な情報を持つDNSサーバの総称であり、TLDを管理するDNSサーバもその一種です。


名前解決の流れ


ユーザーがブラウザにexample.comを入力し、Enterを押します。
ブラウザは直接名前解決を行わないため、スタブリゾルバを利用し解決してくれる人にexample.comを名前解決してほしいと依頼をします。

①~④のように、スタブリゾルバはフルリゾルバに再帰問い合わせを行い、フルリゾルバは必要に応じて権威サーバへ反復問い合わせを行ったうえで、最終的な結果をスタブリゾルバへ返します。

同じ名前解決を何度も繰り返すと非効率ですので、フルリゾルバは一度取得した結果をキャッシュに保存します。以降、同じ問い合わせがあった際は、外部のDNSサーバへ問い合わせることなく、キャッシュに基づいてIPアドレスを返します。
また、そもそもドメイン名が存在していない場合、いちいち聞いていると無駄な問い合わせとなるため存在していないことをキャッシュに蓄えます。存在していない結果をキャッシュすることを、ネガティブキャッシュといいます。

名前解決の詳細の流れ

フルリゾルバが問い合わせた情報をルートDNSサーバが答えますが、前述した階層化と委任より委任情報しか答えられません。例えば、example.comをフルリゾルバが問い合わせた際、ルートDNSサーバはexample.comの委任先の情報ではなく.com TLDの委任情報を返し、フルリゾルバは答えをキャッシュに蓄えます。
そうして今度は、得た情報をもとにTLDゾーンを管理する権威DNSサーバに問い合わせを行います。必要に応じてこのようなレコードが返ってきます。

example.com. NS ns1.example.net
example.com. NS ns2.example.net.

example.comというゾーンは、ns1.example.net と ns2.example.netが権威DNSサーバであるという意味です。
つまり、example.com 配下の名前解決は、ns1.example.net / ns2.example.netに問い合わせよという意味になり、フルリゾルバは答えをキャッシュに蓄えます。
得られた情報を今度はexample.comを管理している権威DNSサーバに問い合わせを行うことでIPアドレスを知ることができました。今度はフルリゾルバからIPアドレスを受け取ったスタブリゾルバは、その結果をWebブラウザに返し、Webブラウザは取得したIPアドレスを用いてWebサーバへ接続します。その結果、Webページが表示されます。


このような感じで、URLを入力してからIPアドレスが返るまでの流れを説明しましたが、いかがでしょうか。書いていると自分で何を書いているのか訳が分からないときがあります。(笑)また、ご指摘いただけますと幸いです。

参考文献

cloudflare
ネットワークエンジニアとして
DNSがよくわかる教科書

Discussion