PC やスマホでブラウザに google.com や toolcluster.app と打ち込むと、世界のどこかにあるサーバーから一瞬で Web ページが届きます。考えてみると、不思議なことが続けて起きています。
- ブラウザに
toolcluster.appと打つだけで、世界のどこかにあるサーバーから記事が届く。でも住所（IP アドレス）はどこでわかったの？ - スマホを Wi-Fi につなぐだけで Google も YouTube もすぐ見える。ドメイン名を IP アドレスに変換しているのは誰？
普段、私たちはこの仕組みを意識せずに使っています。けれど中身を辿ると、世界中に張りめぐらされた 分散型の電話帳 が裏で休まず働いているのです。
インターネット上の機器は IP アドレス（数字で書かれたネットワーク上の住所） がないと通信できません（前回記事 IPアドレスとは？ を参照）。けれど私たちは普段、
192.168.1.10のような数字ではなく、toolcluster.appのような 覚えやすい名前 で目的地を指定します。両者を繋いでいるのが DNS（ドメインネームシステム） です。
本記事では、
- そもそも DNS とは何で、なぜ必要 なのか（§1）
- ドメイン名はなぜ 右から左に意味 を持つのか（§2）
- 1 回の名前解決が裏で何をしているのか ─ 7 フェーズの旅路（§3）
- DNS が扱う レコード の正体（§4）
- インターネットの 9 割を支える DNS キャッシュ と TTL（§5）
- DNS が暗号化される DoH/DoT の時代（§6）
- CDN や Apple Private Relay と DNS の関係（§7）
- 自分の PC で DNS を観察する コマンド集（§8）
を、専門知識ゼロからでも追えるように図解で順を追って解いていきます。
本記事は「PC のしくみシリーズ」の第 4 弾です。インストールが OS とアプリの握手、再起動が OS が抱える状態のリセット、IP アドレスが ネットワーク側の住所 の話だとすれば、本記事は その住所を「人間が覚えられる名前」に変換する仕組み をテーマにします。
1. DNS とは何か ─ インターネットの “電話帳”
1-1. 名前と住所を結ぶ仕事
電話帳は「人の名前」から「電話番号」を引くための本です。インターネットの世界では、
- ドメイン名 = 人の名前にあたる、覚えやすい文字列（
toolcluster.app） - IP アドレス = 電話番号にあたる、機械が通信に使う数字（
203.0.113.5）
を結ぶための「電話帳」が必要です。それが DNS（ドメインネームシステム。インターネット全体で使われる「名前 → 住所」変換のしくみ） です。
1-2. なぜ DNS が必要なのか
純粋に通信するだけなら、IP アドレスを直接打てば済みます。それでも DNS が必要な理由は 3 つあります。
- 覚えにくい：
203.0.113.5よりtoolcluster.appのほうが圧倒的に覚えやすい - 変わりやすい：サーバー移転やクラウド事業者の変更で IP アドレスは変わる。名前だけ覚えておけば、裏側の住所が変わってもユーザーは何も意識せずに済む
- 複数サーバーへの分散：1 つの名前を複数の IP アドレスに紐づけて、世界各地のサーバーに振り分ける（後述の CDN がやっていること）
1-3. DNS は 1 つの巨大データベースではない
ここが最大の誤解ポイントです。「世界のどこかに DNS の本部があって、全ドメインを管理している」というイメージを持つ人は多いのですが、実際は世界中に分散した階層型のしくみ です。
あなたのブラウザ
↕
DNS リゾルバ（あなたの代わりに名前解決を引き受けてくれる代理人）
↕
世界中に分散した DNS サーバー群
├── ルートサーバー（"."）
├── TLD サーバー（".app" や ".com"）
└── 権威ネームサーバー（各ドメイン所有者が立てる）
たとえば toolcluster.app の住所を知っているサーバーは、世界の片隅にある「toolcluster.app の権威ネームサーバー」だけ です。それ以外のサーバーは「ここじゃない、こっちに聞いて」と教えるだけ。役割分担して、たらい回しにしながら答えを集める のが DNS の本質です。
2. ドメイン名の階層構造 ─ 右から左に読む
2-1. ドメイン名は “住所” のように右から大きい
www.toolcluster.app というドメイン名は、住所と同じく 右側ほど広い範囲 を表します。
www . toolcluster . app . └─┬─┘ └────┬─────┘ └┬┘ └← 末尾の "." は省略されているがルートを表す サブ セカンド TLD ドメイン レベル
英語の郵便住所が「番地 → 通り名 → 市 → 州 → 国」のように右に行くほど大きくなるのと同じイメージです。省略されがちな末尾のドット（.）が一番大きな単位 = ルート を表しています。
2-2. 4 つの階層と “責任者”
DNS の階層は次の 4 つです。
- ルート (
.)：インターネット全体の一番上。世界に 13 系統のサーバー群が運営している - TLD (Top Level Domain)：
.com.app.jpなど。Verisign や Google などが運営する - セカンドレベルドメイン：
toolcluster.appのうちtoolclusterの部分。ドメインを買った人が責任を持つ - サブドメイン：
www.toolcluster.appのうちwww。所有者が自由に切れる
各階層には 責任者（権威ネームサーバー。「自分の担当範囲のドメインの IP を本当の意味で知っている」サーバー） がいます。たらい回しの旅路は、上の階層から責任者を辿っていくことで答えに到達します。
. ← ルート（"."） ├── com ← TLD ├── app ← TLD ★ ここから ".app" の責任者へ問い合わせる │ └── toolcluster ← セカンドレベル ★ ここに権威 NS がある │ └── www ← サブドメイン ├── jp └── ...
3. ★ 名前解決の旅路 ─ 7 つのフェーズ
ここからが本記事の核心です。あなたが toolcluster.app を打ち込んでから、ブラウザが IP アドレスを得るまでに 何が起きているか。7 つのフェーズに分けて追っていきます。
3-1. 7 フェーズのタイムライン
各フェーズは数ミリ秒〜数百ミリ秒。1 〜 6 の途中でキャッシュにヒットすれば、それより下のフェーズは省略されます（後述の §5）。
- 1ブラウザキャッシュ確認直近に同じドメインを引いたか、ブラウザ内部の表を確認する。
- 2OS スタブリゾルバへ問い合わせブラウザに無ければ、OS の小さな DNS クライアント（スタブリゾルバ）に聞く。OS にもキャッシュがある。
- 3DNS リゾルバへ送信OS にも無ければ、外部の DNS リゾルバ（ISP 提供 / 8.8.8.8 / 1.1.1.1 など）に質問が飛ぶ。
- 4ルートサーバーに問い合わせリゾルバは「.app を担当するサーバーは誰？」とルートに尋ねる。
- 5TLD サーバーに問い合わせルートが教えてくれた .app 担当（TLD サーバー）に「toolcluster.app を担当するサーバーは誰？」と尋ねる。
- 6権威ネームサーバーに問い合わせTLD が教えてくれた toolcluster.app 権威 NS に「www.toolcluster.app の IP は？」と尋ねる。
- 7答えがブラウザに戻るリゾルバ → OS → ブラウザ の順に答えが返り、各層でキャッシュされる。
覚え方：「ブラ → OS → リゾルバ → ルート → TLD → 権威 → 戻る」。ブラウザを押した瞬間から答えが届くまで、毎回この 7 つを通っています（多くはキャッシュで途中省略されますが、フルパスはこれです）。
3-2. 反復クエリ vs 再帰クエリ ─ 「誰がたらい回されているか」
7 フェーズを観察すると、2 種類の問い合わせ方があることに気づきます。
- 再帰クエリ：あなた（ブラウザ／OS）が DNS リゾルバに「最終的な答えだけ返して」と頼むやり方。リゾルバが代わりに 4〜6 を全部やってくれる
- 反復クエリ：DNS リゾルバが各サーバーに「次に聞くべき相手だけ教えて」と尋ねるやり方。リゾルバが順にたらい回されながら答えを集めていく
| 区間 | クエリの種類 | 中身 |
|---|---|---|
| クライアント ↔ リゾルバ | 再帰 | 「最終的な IP を返して」 |
| リゾルバ ↔ ルート / TLD / 権威 | 反復 | 「次に聞くべき相手は？」 |
つまり たらい回されているのはリゾルバだけ。あなたは「リゾルバさん、よろしく」と頼むだけで済みます。これがインターネットの体感速度を支えている設計です。
4. DNS レコードの種類
DNS は単に「名前 → IP」だけを返すわけではありません。ドメイン名に紐づく情報を レコード として種類別に持っています。代表的なものを 8 種に絞ります。
| レコード | 一言で言うと | 例 |
|---|---|---|
| A | ドメイン → IPv4 | toolcluster.app A 203.0.113.5 |
| AAAA | ドメイン → IPv6 | toolcluster.app AAAA 2001:db8::1 |
| CNAME | ドメインの別名 | www.toolcluster.app CNAME toolcluster.app |
| MX | メールの受信先 | toolcluster.app MX 10 mail.example.com |
| TXT | 文字列のメモ（SPF / DKIM など） | toolcluster.app TXT "v=spf1 -all" |
| NS | このゾーンの権威 NS は誰か | toolcluster.app NS ns1.cloudflare.com |
| PTR | IP → ドメイン（逆引き） | 5.113.0.203.in-addr.arpa PTR toolcluster.app |
| SOA | このゾーンの管理情報 | （TTL や管理者メールなどメタ情報） |
A と AAAA は IPv4 / IPv6 で対になっており、現代のサイトはふつう両方を設定します。CNAME は「別名」なので、www.toolcluster.app を toolcluster.app の別名にしておけば、片方の IP を変えるだけで両方の宛先が更新されます。
MX TXT NS は Web 以外のサービスがドメインを使う ときに登場します。メールを使うなら MX、ドメイン認証や送信元偽装防止には TXT 内に SPF / DKIM / DMARC を書く、というのが定番です。
5. DNS キャッシュと TTL ─ インターネットを支える縁の下の力持ち
§3 で見た 7 フェーズを すべての通信で毎回フルにやっていたら、ルートサーバーは秒間数億回の問い合わせで壊れてしまいます。実際にはキャッシュが大量にヒットしているので、ほとんどのアクセスは 1〜3 で終わっています。
5-1. キャッシュは何層もある
ブラウザ内部キャッシュ
↓ ヒットしなければ
OS のスタブリゾルバキャッシュ
↓ ヒットしなければ
DNS リゾルバ（ISP / 8.8.8.8 / 1.1.1.1）のキャッシュ
↓ ヒットしなければ
ルート → TLD → 権威 まで本当に旅する
層が多いほど、上流（ルートや TLD）の負荷が劇的に減ります。
5-2. TTL ─ キャッシュをいつ捨てるか
各レコードには TTL（Time To Live。そのレコードを最大何秒キャッシュしてよいかの指定） が付いています。たとえば TTL = 300 なら 5 分間はキャッシュを使い回せ、それを過ぎたら捨てて再取得する、というルールです。
- TTL を 長く 設定する → 上流の負荷が減るが、IP 変更が反映されるまで時間がかかる
- TTL を 短く 設定する → 変更がすぐ伝わるが、上流に問い合わせが増える
サーバー移転前に「TTL を 60 秒に下げてから移行する」のは、この特性を利用した定番テクニックです。
5-3. 「DNS の浸透」は本当は浸透ではない
サイト引っ越しでよく聞く「DNS の浸透待ち」という言葉。誤解されがちですが、実は 「世界中のキャッシュが TTL 切れになるのを待っているだけ」です。新しいレコードが世界に広がって浸透していくわけではありません。
- ✗ よくある誤解：新しい IP が世界中の DNS サーバーに伝播していく
- ✓ 実際：各リゾルバは 古いキャッシュの TTL が切れた瞬間 に新しい権威 NS から取り直すだけ
なので、TTL を事前に短くしておけば「浸透」は速くなります。これは仕組みを知っていると当たり前ですが、知らないと運任せに見える典型例です。
ブラウザが「キャッシュをクリアしても直らない」のに、別の PC では正しく見えることがあります。これは多くの場合、お使いの DNS リゾルバ（ISP やルーター）のキャッシュがまだ古い、というだけです。ipconfig /flushdns（Windows）でも消えないキャッシュは、ルーターの再起動や別 DNS への切り替えで解決することがあります。
6. DoH / DoT ─ DNS が暗号化される時代
ここまでの説明では暗黙に「DNS の問い合わせは平文で飛んでいる」前提でした。実際、長らくそうでした。けれども 2020 年代から流れが変わっています。
6-1. 平文 DNS の問題
平文だと、あなたの DNS 問い合わせは 同じネットワーク上の誰でも覗ける 状態でした。
- 公衆 Wi-Fi の提供者は「あなたが何を見ようとしているか」（ドメイン名）が丸見え
- ISP もドメインレベルの履歴を取れる
- 中間者がレコードを偽造して、偽サイトに誘導する こともできる（DNS スプーフィング）
6-2. DoH と DoT の登場
これに対応するのが DoH（DNS over HTTPS） と DoT（DNS over TLS） です。どちらも DNS の問い合わせを暗号化します。
| 方式 | プロトコル | 見え方 |
|---|---|---|
| 従来 | UDP/53（平文） | 何を引いたか丸見え |
| DoT | TLS/853（専用ポート） | 暗号化されているが「DNS をやっている」ことは見える |
| DoH | HTTPS/443（Web と同じポート） | 普通の Web 通信に紛れて区別が難しい |
6-3. 現状の使われ方
主要ブラウザ（Firefox / Chrome / Safari）は条件次第で自動的に DoH を使います。一方、企業ネットワークでは 「DoH をどう統制するか」 が新しい課題になりました（ペアレンタルフィルタや侵入検知が DNS を見ていたから）。
このトピックは別記事で本格的に深掘りする予定なので、本記事では「こういう変化が起きている」という視野だけ掴んでおいてください。
7. CDN と DNS ─ “近くのサーバー” を返す賢い嘘
最後に、現代の Web 高速化を支える DNS の応用例を 2 つだけ。
7-1. CDN は “GeoDNS” で近くを返す
google.com を世界中で引くと、国によって違う IP が返ってきます。これは権威ネームサーバーが、問い合わせ元の地理位置やネットワーク経路を見て、最寄りのサーバーの IP を返す からです。これを GeoDNS（地理的に最適な答えを返す DNS の運用方法） と呼びます。Cloudflare や Akamai などの CDN（コンテンツ配信網）はこの仕組みを大規模に運用しています。
東京のあなた → 東京エッジサーバーの IP ニューヨークの誰か → ニューヨークエッジサーバーの IP
同じドメイン名でも答えが違う ─ これが「DNS は単なる電話帳」を超えた現代の使われ方です。
7-2. Apple Private Relay も DNS が肝
iOS / macOS の Apple Private Relay は、あなたの DNS 問い合わせと Web トラフィックを 2 段の中継で分離するサービスです。「Apple すら、あなたが何を見ているか分からない」という設計の出発点は、まさに DNS の暗号化と分離 にあります。
このように、DNS は単なる名前解決の枠を超えて、プライバシー と 配信の最適化 の両輪を担うようになっています。
8. 自分の PC で観察する
理屈をひととおり追ったら、最後に手を動かしてみましょう。本格的な使い方は別記事で扱う予定なので、ここでは 最小限のコマンド 2 つ だけ紹介します。
8-1. dig（Linux / macOS）
dig toolcluster.app返ってくる出力のうち、注目するのは ;; ANSWER SECTION: 以下です。
;; ANSWER SECTION: toolcluster.app. 300 IN A 203.0.113.5
300 が TTL、A がレコード種別、203.0.113.5 が IP。3 つの数字を読めるだけで、§4 と §5 の知識が一気に手に馴染みます。
8-2. nslookup（Windows / 共通）
nslookup toolcluster.appServer: の行に「いま使っている DNS リゾルバ」が、Address: の行に「ドメインに対応する IP」が表示されます。
8-3. キャッシュをクリアしたいとき
- Windows:
ipconfig /flushdns - macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux (systemd):
sudo systemd-resolve --flush-caches
dig の使い方や応用は奥が深いのですが、それは別記事の領域です。本記事は「1 行打って、答えの読み方を覚える」までで十分です。
まとめ ─ 4 行エッセンス
長い記事になりましたが、エッセンスは 4 行です。
- DNS = 名前から住所への変換装置。世界中のサーバーが分散して動いている
- ドメイン名は右から階層構造 で、各層に責任者（権威ネームサーバー）がいる
- キャッシュと TTL がインターネットの 9 割を支えている。「DNS の浸透」は浸透ではなく TTL 切れ待ち
- DoH/DoT と CDN を知ると、最近のネットの挙動がぐっと読める
この骨格を頭に入れれば、サイト移転の段取りも、変な遅延の切り分けも、ニュースで聞く DNS 関連の話題も、同じ視点で見渡せるようになります。
ネットワーク側の住所そのものについては IP アドレスとは？、ソフトウェアと OS の橋渡しは なぜインストールが必要なのか？、OS が抱える状態のリセットは なぜ再起動で直るのか？ を併せて読むと、PC とインターネットの “見えない仕組み” が立体的に繋がります。
FAQ
Q1. DNS が遅いと感じるとき、何ができる？
A. まず疑うのは キャッシュ と リゾルバの選択 です。ipconfig /flushdns（Windows）などでローカルキャッシュをクリアしても変わらない場合、使っている DNS リゾルバを 8.8.8.8（Google）、1.1.1.1（Cloudflare）、9.9.9.9（Quad9）などのパブリック DNS に切り替えると速くなることがあります。家のルーターの設定からも変更できます。なお、TTL が長く設定されたサイトは、サーバー側の事情で「全員が同じだけ遅い」こともあるので、自分だけが遅いのか他の人もそうなのかを切り分けると判断が早いです。
Q2. hosts ファイルって何？ DNS との関係は？
A. hosts ファイル は、OS が DNS より先に参照する ローカルの住所メモ帳 です。/etc/hosts（Mac/Linux）や C:\Windows\System32\drivers\etc\hosts（Windows）にあり、たとえば 127.0.0.1 myapp.local と書けば、myapp.local への通信は DNS を一切使わずに自分自身（127.0.0.1）に向かいます。開発時の動作確認や、特定サイトへのアクセス遮断にも使われます。DNS の前段にあるので、誤って書くと「なぜか繋がらない」原因になります。
Q3. ドメインを買ってから Web に出るまで何が起きるの？
A. 大きく 3 ステップです。① レジストラ（お名前.com / Cloudflare Registrar など）で ドメインを購入 すると、TLD のデータベースに登録されます。② レジストラの管理画面で 権威ネームサーバー (NS) を指定する（自前で立てるか、Cloudflare DNS や Route 53 などのマネージド DNS を使うか）。③ その権威 NS で A レコードや CNAME を設定して、目的のサーバー IP を紐づける。これで世界中のリゾルバが、TTL に応じて新しいレコードを取りに来るようになります。
Q4. 8.8.8.8 と 1.1.1.1、どっちを使うべき？
A. どちらも安定した無料パブリック DNS で、速度は地域差以外ほぼ互角です。違いはポリシーと付加機能です。8.8.8.8（Google）は 巨大インフラと長い実績、1.1.1.1（Cloudflare）は 「ログを 24 時間以内に削除する」と表明したプライバシー重視 が強み。フィルタリング付き（成人サイト遮断など）が欲しければ 1.1.1.3（Cloudflare for Families）や 9.9.9.9（Quad9、マルウェアドメイン遮断）も選択肢です。家庭・個人用途なら 1.1.1.1 が無難、業務でサポートや SLA を重視するなら ISP 提供の DNS や有料サービスを検討するのが現実的です。
Q5. DNS over HTTPS にすると会社のセキュリティが効かなくなる？
A. 半分本当、半分は対応済み です。古い時代の社内セキュリティは「DNS を覗いて怪しいドメインを遮断する」方式でしたが、DoH では DNS 通信が HTTPS に紛れてしまうので、この方式は効きづらくなります。一方で、最近の社内環境はエンドポイント側（PC エージェント）や DoH を社内リゾルバ経由で強制 する設定で対応しています。家庭で個人が DoH を有効にすることに大きなリスクはありませんが、会社支給 PC で勝手に DoH を有効化するのは避ける（社内ポリシーとぶつかる）のが無難です。
コメントを残す