はじめに
ブラウザに example.com と入力してEnterを押す。たったこれだけで目的のページが表示されます。
でも、コンピュータが通信するには IPアドレス（数字の住所） が必要です。example.com という文字列のままでは、サーバーの場所はわかりません。
この 「ドメイン名 → IPアドレス」の変換 を担っているのが DNS（Domain Name System） です。
この記事では、DNSがどのように名前解決を行うのかを、図解で一歩ずつたどります。
この記事は 「図解でわかるWeb技術の仕組み」シリーズ の第4回です。
第3回：OAuth 2.0 の仕組みも合わせてどうぞ。
1. DNS とは
インターネットの「電話帳」
DNSは Domain Name System の略で、ドメイン名（人間が読みやすい名前）を IPアドレス（コンピュータが通信に使う数字）に変換するシステムです。
| 人間向け | コンピュータ向け | |
|---|---|---|
| 例 | www.example.com |
93.184.216.34 |
| 特徴 | 覚えやすい | 通信に必要 |
もしDNSがなかったら、私たちは 93.184.216.34 のような数字を覚えてWebサイトにアクセスしなければなりません。
2. DNSの階層構造
ドメイン名は「逆さまの木」
DNSは 階層的な分散データベース です。1台のサーバーが全世界のドメイン情報を持つのではなく、役割を分担しています。
| レベル | サーバー | 役割 | 数 |
|---|---|---|---|
| ルート | ルートDNSサーバー | 全体の起点。TLDサーバーの場所を知っている | 13系統（世界中に分散） |
| TLD | TLDサーバー | .com, .jp, .org などを管理 | TLDごとに存在 |
| 権威 | 権威DNSサーバー | ドメインの正式な情報（IPアドレス等）を持つ | ドメインごとに存在 |
ドメイン名の読み方
www.example.com.
↑ ↑ ↑ ↑
| | | ルート（普段は省略）
| | TLD（トップレベルドメイン）
| セカンドレベルドメイン
サブドメイン
ドメイン名の末尾のドット
正式には www.example.com. のように末尾にドット（ルートを表す）がつきます。普段は省略されていますが、DNSの設定画面では目にすることがあります。
3. DNS解決の流れ ― 再帰的問い合わせ
www.example.com のIPアドレスを調べるとき、裏側では何が起きているのか見ていきましょう。
再帰的問い合わせと反復的問い合わせ
ここで重要な概念が2つあります。
| 種類 | 誰が使う | 動作 |
|---|---|---|
| 再帰的問い合わせ | ブラウザ → フルリゾルバ | 「最終回答を教えて」（全部お任せ） |
| 反復的問い合わせ | フルリゾルバ → 各DNSサーバー | 「知ってたら教えて。知らなければヒントだけでOK」 |
つまり、ブラウザは「最終回答をちょうだい」と1回だけ聞く。フルリゾルバが代わりにルート → TLD → 権威サーバーと順番に聞いて回ってくれます。
フルリゾルバ（キャッシュDNSサーバー）
フルリゾルバは、ユーザーの代わりにDNSの階層を辿って最終回答を取得する 仲介者 です。
身近なフルリゾルバの例:
├── ISP（プロバイダ）が提供するDNSサーバー
├── Google Public DNS → 8.8.8.8 / 8.8.4.4
└── Cloudflare DNS → 1.1.1.1
4. DNSキャッシュ
毎回ルートDNSサーバーから問い合わせていたら遅くてたまりません。そこで キャッシュ が活躍します。
キャッシュの階層
① ブラウザキャッシュ → 最速。ブラウザ内部に保存
② OSキャッシュ → hostsファイル + OS内部のリゾルバ
③ フルリゾルバのキャッシュ → ISP/パブリックDNSが保持
④ フル解決 → キャッシュが全くない場合のみ実行
TTL（Time To Live）
TTLは 「このレコードをキャッシュしてよい秒数」 です。
example.com. IN A 93.184.216.34 TTL=3600
| TTLの値 | 意味 | 使いどころ |
|---|---|---|
| 60〜300 | 1分〜5分 | サーバー移行中（素早く切り替えたい） |
| 3600 | 1時間 | 一般的な設定 |
| 86400 | 24時間 | 変更が少ないドメイン |
サーバー移行時のTTL設定ミス
サーバーを移行する際、TTLが長いままだと古いIPアドレスがキャッシュに残り、新サーバーにアクセスできないユーザーが出ます。移行の24〜48時間前にTTLを短く（60〜300秒）しておく のが鉄則です。
5. DNSレコードの種類
DNSには「電話帳」の中に様々な種類の情報を格納できます。
実務でよく使うレコード
# Aレコード: ドメインにIPアドレスを設定
example.com. IN A 93.184.216.34
# CNAMEレコード: 別名（エイリアス）を設定
www.example.com. IN CNAME example.com.
# MXレコード: メールサーバーを指定
example.com. IN MX 10 mail.example.com.
# TXTレコード: テキスト情報（SPF, DKIM等）
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
dig コマンドで確認する
# Aレコードを確認
$ dig example.com A +short
93.184.216.34
# MXレコードを確認
$ dig example.com MX +short
10 mail.example.com.
# TTLも確認する場合
$ dig example.com A
;; ANSWER SECTION:
example.com. 3600 IN A 93.184.216.34
# ↑ TTL=3600秒（1時間）
nslookup コマンド
# Windows / macOS 共通で使える
$ nslookup example.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: example.com
Address: 93.184.216.34
6. DNSのセキュリティ
DNSは1983年に設計されたプロトコルで、元々は セキュリティが考慮されていません。
| 脅威 | 内容 | 対策 |
|---|---|---|
| DNSキャッシュポイズニング | 偽のIPアドレスをキャッシュに注入する | DNSSEC（署名による検証） |
| DNS盗聴 | DNSクエリが平文で送られるため内容が見える | DoH（DNS over HTTPS）/ DoT（DNS over TLS） |
| DDoS攻撃 | DNSサーバーを大量のリクエストで過負荷にする | Anycast / レートリミット |
DoH / DoT ― DNS通信の暗号化
従来のDNS: UDP/53 で平文通信
→ 通信経路上の誰でも「どのサイトにアクセスしたか」がわかる
DoH (DNS over HTTPS): HTTPS/443 で暗号化
DoT (DNS over TLS): TLS/853 で暗号化
→ 通信内容が暗号化され、盗聴・改ざんを防止
ブラウザのDoH対応
Chrome, Firefox, Safari, Edge はすべてDoHに対応しています。設定で有効にすると、DNSクエリがHTTPSで暗号化されます。
7. 実務での使いどころ
ドメイン取得後の設定フロー
1. ドメインレジストラでドメインを購入（例: example.com）
2. ネームサーバーを設定（NS レコード）
3. Aレコード or CNAMEレコードでサーバーのIPを設定
4. MXレコードでメールサーバーを設定（必要なら）
5. TXTレコードでSPF/DKIMを設定（メール認証）
6. SSL証明書の取得（DNS-01チャレンジでTXTレコードを使うことも）
トラブルシューティング
# DNSが反映されたか確認
$ dig example.com A @8.8.8.8 +short
93.184.216.34
# 特定のネームサーバーに直接聞く
$ dig example.com A @ns1.example.com +short
# DNSの全経路を表示
$ dig example.com +trace
「DNS浸透」という表現について
厳密には「DNSの浸透」という概念は存在しません。DNS変更後に反映が遅れるのは、各所のキャッシュがTTL切れになるまで古いレコードを返し続けるためです。正確には「キャッシュのTTL切れによる反映」です。
8. まとめ
| 項目 | ポイント |
|---|---|
| DNSの役割 | ドメイン名（人間向け）→ IPアドレス（コンピュータ向け）の変換 |
| 階層構造 | ルート → TLD → 権威サーバーの3階層で分散管理 |
| 再帰的問い合わせ | ブラウザはフルリゾルバに「最終回答を教えて」と頼むだけ |
| キャッシュとTTL | 問い合わせ結果をTTL秒間キャッシュして高速化 |
| DNSレコード | A（IPv4）, AAAA（IPv6）, CNAME（エイリアス）, MX（メール）, TXT（検証用） |
| セキュリティ | DNSSEC, DoH/DoT で改ざん・盗聴を防止 |
次回予告
第5回では 「HTTPS・TLS通信の仕組み」 を図解で解説します。ブラウザのアドレスバーに表示される鍵マークの裏側 ― 暗号化通信がどのように確立されるのかをたどります。
シリーズ目次
| # | テーマ |
|---|---|
| 1 | HTTPリクエスト/レスポンスの仕組み |
| 2 | Cookie・Session・JWTの違い |
| 3 | OAuth 2.0 の仕組み |
| 4 | DNS解決の流れ（この記事） |
| 5 | HTTPS・TLS通信の仕組み |
| 6 | CDN の仕組みと役割 |
| 7 | WebSocket ― 双方向リアルタイム通信 |
| 8 | キャッシュ戦略（ブラウザ・サーバー・CDN） |
| 9 | CORS ― クロスオリジンの壁を理解する |
| 10 | REST API 設計の基本原則 |
「この記事が役に立った」と思ったら、LGTM とストックをお願いします。
@kotaro_ai_lab
AI活用や開発効率化について発信しています。フォローお気軽にどうぞ！