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回の「委任」は、この後のすべての回で使うので、確実に押さえてください。

コマンドの詳しい使い方は第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の用語集）の用語、現場での呼び方を対応させておきます。

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

身の回りのDNS

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

特に最後のブラウザーは見落としがちです。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設計演習