【DNS入門 第1回】DNSとは？名前解決の全体像と3つの登場人物

「Webサイトが開けないんですけど、DNSのせいですか？」
「DNSサーバーって、結局どのサーバーのこと？」
インフラの仕事をしていると、こういう質問は本当によく飛んできます。

DNSは、Webの閲覧、メールの配送、Active Directoryへのログオン、クラウドのサービス間の通信など、ほとんどすべての通信の最初に動いている仕組みです。普段は意識されませんが、止まったり、誤った答えを返したりすると、原因の分かりにくい障害として表に出てきます。

この連載では、名前を引いたときに裏側で何が起きているかを、登場人物と委任の流れから順に説明します。そのうえで、dig（WindowsではPowerShellのResolve-DnsName）で応答を読んで障害を切り分ける方法、ゾーンやTTLを安全に設計・変更する方法、DNSSECや暗号化DNSといった守り方、Route 53やAD統合DNSといったクラウド・社内環境での使い方までを扱います。仕様や数値は2026年9月時点の情報に合わせています。

第1回は、DNSの全体像です。

この図のとおり、どの通信もまず名前を引いて答え（IPアドレスなど）を得てから、本来の通信が始まります。裏を返すと、DNSが止まると、どの通信も入口で止まるということです。

---

この連載の進め方

全12回で、次の順に進めます。第1回〜第3回が土台です。特に今回の「登場人物」と、第2回の「委任」は、この後のすべての回で使うので、確実に押さえてください。

回	テーマ	主な内容
第1回	DNSとは・全体像	hostsからDNSへ、登場人物、名前解決の流れ
第2回	ドメイン名の階層と委任	ルート・TLD、ゾーン、NSとグルー、内部用ドメイン名
第3回	名前解決の流れ	再帰と反復、キャッシュとTTL、フォワーディング、OSの動き
第4回	DNSメッセージとトランスポート	ヘッダー、UDPとTCP、EDNS、応答コード
第5回	リソースレコード 前編	ゾーンファイル、SOA、NS、A/AAAA、CNAME
第6回	リソースレコード 後編	MX、SPF・DKIM・DMARC、SRV、PTR、CAA、HTTPS
第7回	権威DNSサーバーの運用	ゾーン転送、TTL設計、変更手順、スプリットホライズン
第8回	コマンドで調べる	dig、nslookup、Resolve-DnsName、resolvectl
第9回	DNSのセキュリティ	キャッシュポイズニング、DNSSEC、暗号化DNS
第10回	クラウド・社内環境のDNS	Route 53、AD統合DNS、Kubernetes
第11回	トラブルシュート	切り分けの手順、よくある障害、まとめ
第12回	設計演習	5つのケースで考える

コマンドの詳しい使い方は第8回にまとめ、それまでの回では説明に必要な範囲でdigの出力を示します。各回の最後にある「考えてみよう」は、自分の職場や自宅の環境を思い浮かべながら答えてみてください。

---

hostsファイルからDNSへ

コンピューター同士はIPアドレスで通信しますが、数字の並びは人間には覚えにくいものです。

そこで初期のインターネット（ARPANET）では、名前とアドレスの対応を1つのファイル（HOSTS.TXT）にまとめてSRI-NICが一元管理し、各ホストが定期的にダウンロードしていました。全員が同じ電話帳のコピーを持つ状態です。

しかしホストが増えると、更新の手間、ファイルの肥大化、名前の重複が限界に達しました。そこで1983年のRFC 882・883で生まれ、1987年のRFC 1034・1035で現在の形になったのがDNSです。

DNSは電話帳を分割し、各組織が自分の部分だけを管理する分散型のデータベースです。上の図の下半分のように、ルートの下のjpはJPRSが、comはVerisignが管理し、その下のexample.jpはA社が、example.comはB社が、それぞれ自分の部分だけを管理します。「1か所に集める方式」から「各組織が自分の部分を持つ方式」への転換が、DNSのいちばん大きな発想です。

hostsファイルは今も残っている

なお、hostsファイルは今もOSに残っています。

• Linux / macOS：/etc/hosts
• Windows：C:\Windows\System32\drivers\etc\hosts

多くの場合、hostsはDNSより先に参照されます。検証のために一時的に書いた行を消し忘れると、DNSをいくら直しても、そのサーバーだけ古いアドレスに接続し続ける、ということが起きます。「このサーバーだけおかしい」ときは、まずhostsを疑う習慣をつけておくと役に立ちます。

ポイント
・昔は1つのファイル（HOSTS.TXT）を全員に配って使っていた
・DNSは名前の管理を分割し、各組織が自分の部分を持つ分散データベース
・hostsは今も残り、DNSより先に参照される。書き残しに注意

---

名前解決とは：通信は「2段階」で行われる

名前解決とは、www.example.jpのような名前から、通信に必要なIPアドレスなどの情報を求めることです。

• 正引き：名前 → アドレス（例：www.example.jp → 192.0.2.10）
• 逆引き：アドレス → 名前（例：192.0.2.10 → www.example.jp）

ブラウザーでWebサイトを開くときは、まず名前解決でアドレスを得て、次にそのアドレスへ接続するという2段階の通信が行われます。図の①②が名前解決、③が本来の通信です。

この2つは別々の通信です。そのため「つながらない」と言われたら、名前解決で失敗しているのか、その後の接続で失敗しているのかを最初に切り分けます。①②が失敗すると、③は始まりもしません。逆に、名前解決は成功しているのに③で失敗しているなら、DNSではなくネットワークやサーバー側の問題です。

DNSが答えるのはアドレスだけではない

DNSが答えるのはIPアドレスだけではありません。

• メールの配送先（MX）
• Active Directoryのドメインコントローラーの場所（SRV）
• 送信ドメイン認証の情報（TXT）

など、さまざまな情報（リソースレコード、第5回・第6回で解説）を引けます。

また、逆引きも軽視できません。SSHのログインが遅い、vSphereの構築が失敗するといった問題は、逆引きが引けないことが原因になっている場合があります（第10回・第11回）。

ポイント
・名前解決と、その後の本来の通信は別。まずどちらで失敗したかを見る
・正引き（名前→アドレス）と逆引き（アドレス→名前）がある
・アドレス以外に、メールの配送先やサービスの場所なども引ける

---

DNSの3つの登場人物

DNSを理解するうえで、いちばん大事なのがここです。DNSの登場人物は3種類です。

1. スタブリゾルバー（依頼者）
PCやサーバーのOSに組み込まれた、問い合わせを出す側の部品です。自分では答えを探さず、設定されたDNSサーバーに「調べてきて」と頼むだけです。

2. フルサービスリゾルバー（受付係）
一般にはキャッシュDNSサーバーと呼ばれます。頼まれた名前について、ルートから順に答えを持つサーバーを探し回り、得た答えを一定時間覚えておきます（キャッシュ）。「代わりに探します」という役です。

3. 権威DNSサーバー（台帳係）
自分が担当する範囲（ゾーン）の「正解」を持ち、その範囲についてだけ答えます。「担当の範囲だけ答えます」という役です。

たとえるなら、スタブリゾルバーは依頼者、フルサービスリゾルバーは調べ物を代行する受付係、権威DNSサーバーは各部署の台帳係です。

ここで大事なのは、PCのネットワーク設定に書く「DNSサーバー」は、原則としてフルサービスリゾルバー（キャッシュDNS）だということです。PCは権威DNSサーバーに直接は聞きません。必ず受付係を通して聞きます。

ポイント
・問い合わせる側（スタブ）、調べ回る側（フルサービス）、答えを持つ側（権威）
・PCに設定するDNSサーバーは、原則としてフルサービスリゾルバー
・権威DNSサーバーは、担当するゾーンについてだけ答える

---

1回の名前解決の全体の流れ

では、PCがwww.example.jpを初めて引く場合を追ってみましょう。

1. ① PCのスタブリゾルバーは、設定されたキャッシュDNSサーバーに問い合わせます。
2. キャッシュに答えがなければ、キャッシュDNSサーバーは ② ルートサーバーに聞きます。
3. ルートは答えを持っていませんが、③「jpのことはjpのサーバーに聞いてください」と担当を紹介します（委任、第2回）。
4. 続いて ④ jpのサーバーに聞くと、⑤ example.jpのサーバーを紹介されます。
5. ⑥ example.jpの権威DNSサーバーに聞くと、⑦ ようやく「192.0.2.10です」という答えが返ります。
6. キャッシュDNSサーバーは ⑧ その答えをPCに返し、同時にキャッシュに保存します。

面白いのは、②④⑥はどれも同じ質問「www.example.jpのAレコードは？」だという点です。キャッシュDNSは同じ質問を投げ続け、答えが見つかるまで紹介をたどります。

電話のたとえでいえば、受付係が本部、支部、担当部署と順に電話をかけ、担当者の答えを依頼者に伝える流れです。図の青（①⑧）が再帰問い合わせ、オレンジ（②〜⑦）が反復問い合わせで、この違いは第3回で詳しく扱います。

そして、2回目以降はキャッシュから答えるため、②〜⑦は行われません。インターネット全体でDNSが軽快に動いているのは、このキャッシュのおかげです。

ポイント
・キャッシュDNSが、ルート→TLD→担当ゾーンの順に紹介をたどる
・各段階の「紹介」が委任。最後に権威DNSが答えを返す
・答えはキャッシュされ、2回目以降は②〜⑦が省かれる

---

用語の整理（RFC 9499）

DNSは歴史が長いので、同じものがいろいろな名前で呼ばれています。この連載での呼び方と、RFC 9499（2024年、RFC 8499を置き換えたDNSの用語集）の用語、現場での呼び方を対応させておきます。

この連載での呼び方	RFC 9499 の用語	現場での呼び方	役割
スタブリゾルバー	stub resolver	リゾルバー、DNSクライアント	問い合わせを出すだけ。答えは探さない
フルサービスリゾルバー（キャッシュDNSサーバー）	full-service resolver、recursive resolver	キャッシュサーバー、フルリゾルバー	再帰問い合わせを受け、答えを探してキャッシュする
権威DNSサーバー	authoritative server	権威サーバー、コンテンツサーバー	ゾーンの正解を持ち、そのゾーンについて答える
フォワーダー	forwarder	DNSプロキシ、DNSリレー	受けた問い合わせを別のサーバーへ転送する
再帰問い合わせ	recursive mode	—	「最後まで調べて」と頼む（第3回）
反復問い合わせ	iterative resolution	非再帰問い合わせ	「知っている範囲で答えて」と頼む（第3回）

注意したいのは、単に「DNSサーバー」と言うと、キャッシュDNSと権威DNSの両方を指してしまうことです。会話やチケットで「DNSサーバーを変更しました」と出てきたら、「キャッシュ」の話か「権威」の話かを必ず確かめましょう。ここを取り違えると、話がまったく噛み合いません。

---

身の回りのDNS

普段使っている端末は、どのキャッシュDNSに聞いているのでしょうか。場面ごとに整理してみます。

場面	端末が使うキャッシュDNS	設定の配られ方	注意点
社内	ADのドメインコントローラーなど社内のDNSサーバー	DHCP、または固定設定	社内と外部の名前を両方引く。外部はフォワーダー経由が多い
自宅	ブロードバンドルーター（DNSプロキシ）	ルーターのDHCP	ルーターはプロバイダーのキャッシュDNSへ転送する
スマホ（モバイル回線）	携帯事業者のキャッシュDNS	回線への接続時に自動	Androidの「プライベートDNS」などで暗号化DNSに変えられる（第9回）
パブリックDNS	8.8.8.8（Google）、1.1.1.1（Cloudflare）、9.9.9.9（Quad9）等	利用者が手動で設定	社内の名前は引けない。社内での利用はポリシーに従う
クラウド（AWS）	VPCのRoute 53 VPC Resolver（VPCのCIDR＋2、169.254.169.253）	DHCPオプションセット	プライベートホストゾーンを引ける（第10回）
ブラウザー	OSとは別の暗号化DNS（DoH）を使う場合がある	ブラウザーの設定	OSの設定と違うサーバーに聞くことがある（第9回）

特に最後のブラウザーは見落としがちです。OSのDNS設定を確認して「正しいサーバーを向いている」と思っても、ブラウザーが独自にDoHで外部のサーバーに聞いていると、社内の名前が引けない、といったことが起きます。

自分がどのDNSサーバーを使っているかは、次のコマンドで確認できます（詳しくは第3回・第8回）。

# Windows
ipconfig /all

# Linux（systemd-resolved）
resolvectl status

# Linux（従来の設定ファイル）
cat /etc/resolv.conf

---

答えの出どころを確かめる

最後に、少しだけdigを使ってみます。同じ名前を引いても、キャッシュDNSに聞いた場合と、権威DNSに直接聞いた場合とで、応答の見え方が違います。

$ dig www.example.jp
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
www.example.jp.		259	IN	A	192.0.2.10

$ dig @ns1.example.jp www.example.jp +norec
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
www.example.jp.		300	IN	A	192.0.2.10

（出力は要所のみの抜粋です）

• 1つ目は、設定されたキャッシュDNSへの問い合わせです。flagsにaaがないので、キャッシュDNSが調べてきた答えだと分かります。
• 2つ目は、権威DNSに直接、再帰なし（+norec）で聞いた結果です。aa（Authoritative Answer）が立っています。
• TTLにも注目してください。権威DNSは設定値の300のまま、キャッシュDNSは残り時間（259）を返しています。

Windowsには標準でdigがないため、PowerShellのResolve-DnsNameを使います。

PS> Resolve-DnsName www.example.jp -NoRecursion -Server ns1.example.jp
Name              Type   TTL   Section    IPAddress
www.example.jp    A      300   Answer     192.0.2.10

Resolve-DnsNameではフラグは表示されませんが、TTLが設定値のままか、減っているかで同じように見分けられます。

なぜこれが大事かというと、出どころを取り違えると、切り分けの方向を誤るからです。

• 「権威DNSでは正しいのに、キャッシュDNSでは古い」→ キャッシュの問題
• 「権威DNSから間違っている」→ ゾーンの設定の問題

digの読み方は第8回で詳しく扱います。

---

考えてみよう

1. 自分のPCが使っているDNSサーバーを調べてください。それはキャッシュDNSですか、権威DNSですか。社内、VPN接続中、自宅で違いはありますか。
2. hostsファイルに何か書かれているサーバーはありませんか。書かれている理由と、消し忘れたときに起きることを説明できますか。
3. 「Webサイトが開けない」と言われたとき、名前解決の失敗とその後の通信の失敗を、どうやって見分けますか。

ヒント：この記事の「2段階の通信」、「身の回りのDNS」の確認コマンド、「答えの出どころを確かめる」のaaフラグとTTLが手がかりです。

---

まとめ

• DNSは、名前の管理を各組織に分担させた分散型のデータベース。hostsは今もDNSより先に参照される
• 通信は「名前解決」と「本来の通信」の2段階。障害時はまずどちらで失敗したかを見る
• 登場人物はスタブリゾルバー（依頼者）・キャッシュDNS（受付係）・権威DNS（台帳係）の3つ
• キャッシュDNSがルート→TLD→担当ゾーンと紹介をたどって答えを見つけ、キャッシュする
• 「DNSサーバー」と聞いたら、キャッシュか権威かを必ず確かめる

次回は、DNSの名前がどのような階層で管理され、委任によってどう分担されているかを扱います。

---

連載「DNS入門」全12回

1. DNSとは？名前解決の全体像と3つの登場人物（この記事）
2. ドメイン名の階層と委任
3. 名前解決の流れ
4. DNSメッセージとトランスポート
5. リソースレコード 前編
6. リソースレコード 後編
7. 権威DNSサーバーの運用
8. コマンドで調べる
9. DNSのセキュリティ
10. クラウド・社内環境のDNS
11. DNSトラブルシュート
12. DNS設計演習