名前解決の流れ｜基礎を学ぶ

名前解決の流れ

このレッスンで分かること

名前解決はクライアント → リゾルバ → ルート → TLD → 権威、という多段問い合わせで進みます

再帰問い合わせ (クライアント→リゾルバ) と反復問い合わせ (リゾルバ→各権威) を組み合わせる構造

DoH / DoT で通信を暗号化、DNS プリフェッチで体感速度を改善できます

名前解決の流れとは

ブラウザに URL を入れてから IP が返るまでの再帰問い合わせを学びます。本レッスンでは、名前解決の流れの基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。

この章のポイント

名前解決の流れ (要約)

ブラウザ → スタブリゾルバ → フルサービスリゾルバ → (ルート → TLD → 権威) → 結果返却。リゾルバが「反復問い合わせ」を裏で多段で行い、クライアントには「再帰問い合わせ」で 1 回の応答だけが返ります。各段でキャッシュが効くので、実運用では権威サーバーに 1 回問い合わせるだけで済むケースが大半です。

解決過程の主要ステップ

ステップ	問い合わせ先	取得情報
1	ブラウザ / OS キャッシュ	過去にキャッシュした A レコード (ヒットすれば終了)
2	フルサービスリゾルバ (例: 1.1.1.1)	リゾルバが反復問い合わせを開始
3	ルートサーバー	TLD (`.com`) の権威 NS
4	TLD サーバー (`.com`)	ドメイン (`noimancode.com`) の権威 NS
5	権威サーバー	A レコード (実 IP)

このレッスンで学ぶこと

ブラウザに URL を入れてから IP アドレスが返るまでの、DNS 名前解決の流れを 1 ステップずつ追います。

登場人物

DNS 解決には複数の役者が関わります。

スタブリゾルバ — クライアント (ブラウザや OS) 内蔵の小さな問い合わせクライアント
フルサービスリゾルバ (キャッシュサーバー) — プロバイダや 8.8.8.8 が運営する代表問い合わせ役
ルートサーバー — . の権威。13 系統
TLD サーバー — .com, .jp などの権威
権威サーバー — 実際の A / AAAA レコードを持つサーバー

解決の 5 ステップ

ブラウザに https://noimancode.com を入れたときの流れを追ってみます。

ブラウザ/OS のキャッシュ確認 — 以前引いた結果が残っていればそれを使う
フルサービスリゾルバへ問い合わせ — 通常はプロバイダ DNS や 8.8.8.8/1.1.1.1
リゾルバ → ルートサーバー — 「.com を扱う TLD サーバーは?」
リゾルバ → TLD サーバー (.com) — 「noimancode.com の権威サーバーは?」
リゾルバ → 権威サーバー — 「noimancode.com の A レコードは?」

最後にリゾルバが結果をクライアントに返し、ブラウザはその IP に対して TCP 接続を始めます。

再帰問い合わせと反復問い合わせ

DNS にはふた通りの問い合わせ方法があります。

再帰問い合わせ — クライアント → リゾルバ。1 回問い合わせれば最終結果が返る。クライアントは楽。
反復問い合わせ — リゾルバ → ルート → TLD → 権威。リゾルバが頑張って何回も問い合わせる。

エンドユーザーから見れば「リゾルバに 1 回投げれば良い」ですが、その裏でリゾルバは反復問い合わせを多段で行っています。

この章のポイント

実際は超キャッシュ前提

ステップ 3-5 を毎回行うと負荷が大きすぎるので、リゾルバは TLD やよく使われるドメインの NS をキャッシュしています。実運用では「権威サーバーに直接 1 回問い合わせるだけ」で済むケースが大半です。

どこに問い合わせるか

クライアントが使う DNS サーバーは、下記のいずれかです。

プロバイダから DHCP で配られた DNS (家庭の Wi-Fi)
VPN や企業 LAN で指定された内部 DNS
自分で指定したパブリック DNS (1.1.1.1 / 8.8.8.8 / 9.9.9.9)

/etc/resolv.conf (Linux/macOS) や Windows のネットワーク設定で確認できます。

ブラウザ側のキャッシュ

OS の前に、ブラウザ自身も小さな DNS キャッシュを持っています。Chrome なら chrome://net-internals/#dns で中身を確認できます。

ブラウザキャッシュは OS キャッシュより短く、TTL を尊重します。これにより、DNS 変更を比較的早く反映できます。

ハッシュ的にイメージしてみる

下記のような順で問い合わせが流れます (@ は問い合わせ先)。

プレーンテキスト

client  -> resolver (1.1.1.1)   "noimancode.com の A?"
resolver -> root                 "com の権威は?"
resolver -> com TLD              "noimancode.com の NS?"
resolver -> Cloudflare ns        "noimancode.com の A?"
client  <- resolver              "104.21.50.100"

各段でレスポンスを受け取るたびにリゾルバはキャッシュし、次回からは経路が大幅に短くなります。

DoH と DoT

通常の DNS は UDP/TCP 53 番ポートを平文で使うので、第三者に問い合わせ内容が筒抜けです。これを暗号化する仕組みが下記の 2 つです。

DoH (DNS over HTTPS) — HTTPS の中に DNS クエリを乗せる。普通の Web 通信に紛れるので検閲を回避しやすい。
DoT (DNS over TLS) — TLS 上で DNS を運ぶ。853 番ポート。

Firefox や Chrome は DoH をデフォルトで有効にしつつあり、プライバシー向上が進んでいます。

この章のポイント

DNS の応答時間が体感を左右する

DNS 解決は Web リクエストの起点なので、ここが遅いとすべての通信が遅く感じます。DNS プリフェッチ (<link rel="dns-prefetch">) で重要なドメインを先に解決させたり、CDN ベースの DNS で応答を高速化したりするのが定番の最適化です。

まとめ

このレッスンの要点は、スタブリゾルバとフルサービスリゾルバ / 再帰と反復 / DoH と DoT の 3 点です。実務でこれらを切り分けて説明できるようになると、設計レビューや障害対応の精度が一段上がります。

理解度チェック

Q. DoH (DNS over HTTPS) の主な目的はどれ？

DNS の応答を高速化する
DNS クエリを HTTPS で暗号化し、第三者から内容を見えなくする
DNS の TTL を 0 に固定する
IPv6 を有効化する

答えを見る

正解は 2。従来の DNS は 53 番ポートを平文で使うため傍受や検閲が可能でした。DoH は HTTPS 内に DNS クエリを乗せ、プライバシーと検閲耐性を高めます。

出典 (References)

最終更新: 2026-05-28

よくある質問

Q. このトピックは実務でどう役立ちますか？

A. DB のクエリ最適化、API 設計、データ構造の選択など、設計判断の根拠になります。表面的にライブラリを使うだけでなく「なぜそれが速いのか」を理解できると、性能問題を未然に防げます。コーディング面接でも頻出のテーマです。

Q. 計算量はどう求めれば良いですか？

A. ループのネストごとに掛け算する、再帰なら漸化式から解く、というのが基本です。Big-O 表記は定数倍と低次の項を無視するため、n の指数（n²、n log n など）に注目してください。最悪・平均・最良の 3 つを意識すると説得力が増します。

Q. 覚えるべき定番アルゴリズムは何ですか？

A. 二分探索、クイックソート/マージソート、BFS/DFS、ダイクストラ、DP の基本問題（フィボナッチ・ナップサック）が必修です。これらを「白紙から書ける」状態にすると、応用問題が一気に解けるようになります。

次のレッスン

次は DNS キャッシュと TTL で、ブラウザに URL を入れてから IP が返るまでの再帰問い合わせを学びますを学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

名前解決の流れの要点を自分の言葉で説明できる
このレッスンの最小コード (または操作手順) を見ずに書ける
練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. 名前解決の流れとは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン