XEROTTA

TOP / 採用情報 / キャリア・教育 / DNS初級者 / レッスン2

DNS BASICS / LESSON 02

DNSと名前解決の流れ

端末から問い合わせた後、誰が何を調べ、何を返すのか。キャッシュがない場合の流れと、ある場合の違いを追います。

仕組みの図解仕事と日常のアニメ操作して学ぶ模型解説付き確認問題

まずは、図でつかもう

1 / 4

矢印を追い、各ポイントを押して確認しましょう。

01 / DNS BASICS

DNSの役割を分け、確認の道筋をつくる。

名前解決は、名前について必要な情報を得ることです。端末が全てのサーバーへ順に質問するとは限りません。端末の依頼を受けたリゾルバーが、必要な問い合わせやキャッシュの利用を行う流れとして理解します。

学習目標と確認ポイント詳しく見る
  • 問い合わせは名前と種類の組合せを説明できる。
  • 端末と再帰リゾルバーを具体例で説明できる。
  • 調べる名前・種類・問い合わせ先・時点を区別できる。
  • 模型の結果から、分かったことと未確認を言葉にできる。
初めて学ぶ方へ

知らない用語は、このページの用語表へ戻って確かめてください。詳細解説・図と手順アニメ・行ごとのコマンド解説を追加しています。本文→アニメ→操作する模型→確認問題→自分の言葉にするメモ、の順で進められます。

操作する模型は、実際の端末設定の変更、外部サービスへの要求、アカウント登録、ソフトのインストールを行いません。公式メニューと参考資料のリンクは外部サイトを開きます。模型は仕組みを簡略化したもので、実務の画面や全ての構成と同じとは限りません。アニメに音声はありません。自動再生はボタンで開始し、一時停止できます。回答・入力は外部へ送信せず、自動保存もしません。

DNSと名前解決の流れの学習内容を表した仕組みのイメージ図

02 / DNS BASICS

役割と違いを、一つずつ理解する。

考え方の道筋を示す模式図です。実際の機器構成や全ての処理を表す図ではありません。

はじめに知っておく言葉

名前解決
名前について必要な情報を得ること。
再帰リゾルバー
依頼に応じて情報を探し、結果を返す役割。
TLD
名前の上位の階層。comなどが例。
委任
ある範囲の管理を担当するサーバーへつなぐ仕組み。

1. 問い合わせは名前と種類の組合せ

詳しく見る

同じ名前でも、A、AAAA、MXなど、求める情報の種類が違えば問い合わせは異なります。まず何の目的で何を調べるかを明確にします。

具体例・確かめ方

www.training.testのAを調べることと、training.testのMXを調べることは違う質問です。「DNSを見た」だけでは条件が不足します。

2. 端末と再帰リゾルバー

詳しく見る

端末側の仕組みは、設定やアプリの方式に従って、リゾルバーへ名前の調査を依頼します。再帰リゾルバーは、利用者の代わりに必要な情報を探す役割を持ちます。

具体例・確かめ方

会社が指定するリゾルバー、OSやアプリの設定などで問い合わせ先が異なる場合があります。変更せず、確認先を担当者とそろえます。

3. ルート・TLD・権威DNS

詳しく見る

キャッシュがない基本の模型では、リゾルバーがルートからTLDの手がかりを得て、TLDから担当する権威DNSの手がかりを得て、必要なレコードへたどります。

具体例・確かめ方

端末がこの全ての問い合わせを直接行う図ではありません。実際には転送、追加の委任、CNAMEの追跡などがあり、模型は簡略化しています。

4. 紹介と最終的な答え

詳しく見る

途中のサーバーは、求めるアドレスそのものではなく、次にどこへ尋ねるかを示す場合があります。担当の権威DNSは、自分が管理する範囲についての情報を返します。

具体例・確かめ方

「ルートが全てのWebのIPを一覧で持っている」とは考えません。階層ごとの役割を分けます。

5. キャッシュから答える場合

詳しく見る

過去の応答を再利用できる状態なら、リゾルバーなどがキャッシュを利用して応答できます。毎回ルートから同じ順で全ての問い合わせを繰り返すとは限りません。

具体例・確かめ方

模型の「初回」と「再問い合わせ」を比べます。端末やブラウザー側のキャッシュなど、図で省略した層もあります。

6. 答えを得た後の通信

詳しく見る

DNSで必要な情報を得た後、アプリはその情報を使って接続などを進めます。DNSは、TLSの証明書の妥当性、Webの正常動作、ログイン権限までを全て確認する仕組みではありません。

具体例・確かめ方

DNSの応答が得られたか、接続できたか、Webの応答は何かを、別の段階として記録します。

03 / DNS BASICS

往復する質問と紹介を、通信単位で追う

「名前をIPへ変換する」の一言で済ませず、端末からの再帰的な依頼と、フルリゾルバーが担当を探す過程を区別します。図はキャッシュも転送先もない単純化した架空のDNS空間です。実際には途中の情報が既に保持され、問い合わせが短縮されることがあります。

1. 端末の依頼と、サーバー間の調査は別

詳しく見る

端末上のスタブリゾルバーは、通常、設定されたフルリゾルバーへ名前解決を依頼します。フルリゾルバーは答えを得るために必要な処理を行い、結果を端末へ返します。一方、権威サーバーからは最終的な答えだけでなく、次に問い合わせる担当の情報が返ることがあります。これを紹介応答として読み分けます。

現場に置き換えて考える

図の端末がルート、TLD、権威へ順番に直接問い合わせる、と覚えるのは避けます。ブラウザー独自のDNS over HTTPSや企業内転送など、環境で経路が変わる場合もあります。まず誰がどの相手へ質問したかを書き出します。

2. ルートは全てのWebのIPを覚えていない

詳しく見る

ルートは根のゾーンを管理し、TLDの担当へ進むための情報を返します。TLDの担当は、その配下の委任先へ進むための情報を返せます。最終的に対象ゾーンの権威へ到達し、求める種類のレコードを取得します。上位のサーバーは、毎回、最終的なIPを代理で探してくれるわけではありません。

現場に置き換えて考える

模型では「ルート役→test役→training.test役」と進みます。testは予約名で、この構成は教材内の架空の階層です。実際の公開DNSで.testへdig +traceを実行して、この順路が再現されると期待してはいけません。

3. 紹介に必要なNSとグルー

詳しく見る

紹介先はNSレコードで名前として示されます。そのサーバー名が委任される子の内部にあると、委任先へ行くためのアドレスを知るのに委任先へ行かなければならない循環が生じ得ます。親が補助のA・AAAAを添えるグルーは、その入口の情報です。グルーと、子ゾーンが権威として持つアドレス情報は役割を分けます。

現場に置き換えて考える

training.testをns1.training.testへ委任する模型では、親からns1.training.testのアドレスも手がかりとして得ます。NSの名前を書き換えるだけで十分とは限らず、登録側のホスト情報と子側の内容も確認する必要があります。

4. 質問と応答は同じ通信形式を使う

詳しく見る

DNSメッセージにはヘッダーとQuestion、Answer、Authority、Additionalなどの領域があります。質問の名前・種類と、応答の状態・レコードを分けて読みます。Additionalに値があるから最終的な答えが得られた、と判断するのは早計です。紹介先の情報やEDNSの情報が置かれる場合もあります。

現場に置き換えて考える

Answerが0件でもAuthorityにNSがある紹介応答、AuthorityにSOAがある否定的な応答では意味が異なります。件数だけで成功・失敗を決めず、状態・フラグ・各領域を一緒に読みます。

レッスン2の重要事項を比較する
往復質問する側 → 相手返ってくる情報の例
①端末 → フルリゾルバー対象名のAを調べてほしいという依頼
②フルリゾルバー → ルート役TLDのNSなどの紹介
③フルリゾルバー → TLD役子ゾーンのNS、必要なグルー
④フルリゾルバー → 子の権威対象名のAなどの情報
⑤フルリゾルバー → 端末取得・検証などを経た結果。キャッシュする場合もある

04 / DNS BASICS

図と動きで、変化する状態を確かめる。

手順アニメ:再帰的な依頼から順に追う

5段階の手順図です。矢印は学習の進行順で、サーバー間の物理的な配線や直列接続ではありません。「再生」では約8秒ごとに進み、手動でも選べます。

通信経路はリゾルバーを中心に往復する

端末・リゾルバー・各権威の通信端末とリゾルバー、リゾルバーとルート役、TLD役、権威DNSがそれぞれ往復する星形の図。端末リゾルバールート役TLD役権威DNS

上の手順と連動して、質問と応答の往復の区間を強調します。キャッシュも転送もない教材の基本経路です。ルート→TLD→権威へ質問が自動転送される図ではありません。

グラフ:キャッシュが調査回数に与える影響

1,000件の依頼があり、ヒットは上流調査0回、ミスはルート役・TLD役・権威への3回と固定した計算模型です。委任情報のキャッシュや同時問い合わせの集約等は省略しています。実際の問い合わせ量や応答速度の予測ではありません。

端末からの依頼
1,000
上流への調査

棒の共通目盛り:全幅3,000回。通信バイト数や待ち時間の比較ではありません。

05 / DNS BASICS

コマンド画面を、一行ずつ読み解く。

下の表示は学習用に独自に作成した架空の出力です。.testや192.0.2.xへ実際の問い合わせを送りません。各行はボタンになっています。行を選ぶと説明が変わり、矢印キーでも移動できます。

キーボード:Tabで各行へ移動、Enterで選択。行の中では↑↓でも前後の行へ移れます。

06 / DNS BASICS

仕事のアニメ:新人の「なぜ?」を一緒に考える。

架空の新人・アオイさんと先輩・ミナトさんの場面です。用語を覚えるだけでなく、何を確かめ、どこで判断するかに注目して読んでください。

調査を依頼1 / 6
アオイ

www.training.testのAを調べたいです。

架空のDNS空間で、キャッシュがない基本の流れを見ます。

約12秒ごとに場面が切り替わります。再生中も一時停止でき、「前へ」「次へ」で自分のペースで読めます。最終場面で停止します。

アニメの内容をまとめて文章で読む

1. 調査を依頼

アオイ:www.training.testのAを調べたいです。

架空のDNS空間で、キャッシュがない基本の流れを見ます。

2. 依頼を受ける

リゾルバー:必要な情報がキャッシュにないので、担当するサーバーをたどります。

端末の代わりに情報を探す役割です。

3. 次の担当を紹介

ルート・TLD:それぞれの担当範囲で、次に尋ねる先の手がかりを返します。

.testは模型の中の仮想的な階層です。公開DNSの実際の委任を示しません。

4. 担当が答える

権威DNS:模型のレコードとして、A 192.0.2.80を返します。

担当する範囲の情報に基づいて答えます。

5. 端末へ返す

リゾルバー:得た情報を端末へ返し、条件に応じてキャッシュします。

答えが返ったことと、その後のWeb通信は別です。

6. もう一度調べる

アオイ:キャッシュを利用できる場合は、同じ調査の繰り返しを減らせるのですね。

再利用の条件と期間はTTLのレッスンで詳しく扱います。

思い込みと、仕組みに沿う見方を比べる。詳しく見る

07 / DNS BASICS

端末が調べる図

思い込みで進める例

端末が必ずルート、TLD、権威DNSへ全て直接問い合わせると考える。

役割を分けて確かめる例

端末の依頼と、リゾルバーが必要に応じて行う調査を分けて図にします。

考えるポイント

役割と通信の主体を分けます。

毎回の問い合わせ

思い込みで進める例

一度開いたページでも、必ず最初から全て同じ通信をすると思う。

役割を分けて確かめる例

キャッシュの有無と、どの層で再利用しているかを考え、問い合わせ条件を記録します。

考えるポイント

図の初回の流れを、全ての実際の通信へ当てはめません。

08 / DNS BASICS

日常のたとえで、もう一度考える。

身近な場面に置き換えると、役割の違いを考えやすくなります。たとえは理解のための補助で、実際の技術と全て同じではありません。

案内係へ相談1 / 4
日常のたとえ

施設の場所を、案内係に尋ねる場面を想像します。

利用者の代わりに探す役割を考えるたとえです。

約12秒ごとに場面が切り替わります。再生中も一時停止でき、「前へ」「次へ」で自分のペースで読めます。最終場面で停止します。

アニメの内容をまとめて文章で読む

1. 案内係へ相談

日常のたとえ:施設の場所を、案内係に尋ねる場面を想像します。

利用者の代わりに探す役割を考えるたとえです。

2. 担当へたどる

日常のたとえ:案内係が担当の部署へ確認します。

利用者自身が全ての部署へ行くとは限らない、という見方です。

3. 答えを返す

日常のたとえ:担当の情報を、案内係が利用者へ伝えます。

途中の紹介と、欲しい情報を分けます。

4. 覚えて再利用

日常のたとえ:条件が変わっていなければ、覚えた情報を使う場合があります。

実際のDNSキャッシュには有効期間などがあり、いつまでも使い続けるわけではありません。

09 / DNS BASICS

操作して、結果と理由をつなげよう。

三つの練習に取り組み、ボタンを押す前に「どう変わると思うか」を考えてください。結果を見たら、なぜそうなるかを自分の言葉で説明します。

キャッシュの有無で、道筋を比べる

この画面内だけの学習用の模型です。実際の端末・ファイル・認証設定は変更しません。

端末待機
再帰リゾルバー待機
ルートの役割待機
TLDの役割待機
権威DNS待機
ボタンや選択肢を使い、状態の違いを確かめてください。

架空のDNS空間を使った基本の模型です。追加の委任、別名の追跡、端末のキャッシュ、転送などは省略しています。

練習1:キャッシュがある条件を外して、最後まで進める。

確認ポイントを見る

リゾルバーが必要な問い合わせをたどり、答えを端末へ返す流れを確認します。

練習2:キャッシュがある条件へ戻し、最初から進める。

確認ポイントを見る

この模型では、ルートからの調査を繰り返さず答えを返せます。

練習3:誰が各問い合わせを行うか説明する。

確認ポイントを見る

端末の依頼と、再帰リゾルバーがたどる調査の役割を分けます。

10 / DNS BASICS

確認問題:仕組みを使って考えられるかな?

全10問です。選ぶと理由が表示され、何度でも選び直せます。点数は学習中の目安で、人事評価や正式な資格認定ではありません。

回答済み 0 / 10問

11 / DNS BASICS

覚えた言葉を、自分の説明に変える。

本当のパスワード、確認コード、顧客情報、個人情報、社内の秘密情報は書かず、学習用の内容に置き換えてください。

入力は自動保存されません。ページを閉じると消えます。残したい場合は自分でコピーしてください。

12 / DNS BASICS

名前・種類・問い合わせ先・時点をそろえる。

名前解決は、名前について必要な情報を得ることです。端末が全てのサーバーへ順に質問するとは限りません。端末の依頼を受けたリゾルバーが、必要な問い合わせやキャッシュの利用を行う流れとして理解します。

  • 問い合わせは名前と種類の組合せを説明できる。
  • 端末と再帰リゾルバーを具体例で説明できる。
  • 調べる名前・種類・問い合わせ先・時点を区別できる。
  • 模型の結果から、分かったことと未確認を言葉にできる。
自分で説明してみよう

名前解決とは何か。何と区別すると分かりやすいか。模型で見た結果を一つ使って、初めて聞く人へ説明してみてください。

13 / DNS BASICS

参考資料・用語の確認先

技術的な用語と仕組みの確認に使った公式資料です。教材の人物・会話・練習は独自に作成した架空の例です。実際の操作画面や利用条件は、利用する製品と会社の案内で確認してください。

書籍の公開目次を学習範囲の参考にしています。書籍本文の全体を参照・転載したものではありません。説明、図、表、アニメ、模型、コマンド出力例は本教材用に独自に作成しています。