ドメイン名とDNS｜なぜ人間用の名前と機械用の番号を分けるのか【情報Ⅰ第71講】

こんにちは、数強塾代表の藤原進之介です。『最強120講義』第71講は、共通テスト重要度Aの「ドメイン名とDNS」です。

この単元は「ドメイン名は覚えやすい名前、DNSはそれをIPアドレスに変換する仕組み」と一行で片付けられがちです。しかしそれだけなら、わざわざ世界規模の分散データベースを運用する必要はありません。 ブラウザのブックマークで足ります。この記事では、なぜ人間用の名前と機械用の番号をあえて分けたのか、その本当の理由から始めます。

1. 「覚えられないから」は理由の半分でしかない

名前とアドレスを分ける本当の理由はこうです。名前とアドレスを分けておくと、片方を変えても、もう片方は変えずに済む。

プログラミングでいえば、変数とその値の関係に似ています。値を直接あちこちに書き込んでしまうと、値を変えたいときに書いた場所を全部探して直すことになる。名前を1つ置いて、その名前が値を指すようにしておけば、指し先だけを差し替えれば済む。 これを間接参照といいます。DNSは、これをインターネット全体の規模でやっている仕組みです。

1-1. 公的機関のサイトで、実際にそれが起きている

抽象論に聞こえるでしょうから、実物を見てください。以下は私が2026年8月3日に手元で dig コマンドを実行した実際の出力です（再現手順は第4節に書きます）。

$ dig www.ipa.go.jp +noall +answer
www.ipa.go.jp.    2348  IN  CNAME  d2aiu9f88m0xez.cloudfront.net.
d2aiu9f88m0xez.cloudfront.net. 60 IN A  54.230.175.99
（以下、同じ名前に対して計4つのアドレス）

情報処理推進機構（IPA）のWebサイトの名前は www.ipa.go.jp ですが、その実体は cloudfront.net というクラウド事業者のサーバ群を指しています。同じことが政府統計ポータルでも起きています。

$ dig www.e-stat.go.jp +noall +answer
www.e-stat.go.jp. 8 IN CNAME www-e-stat-go-jp.o.waas.oci.oraclecloud.net.
（このあと2段の別名をたどって、最終的にIPアドレスへ）

利用者から見えている名前は、一度も変わっていません。 変わったのは、その名前が指している先だけです。もし世の中に「名前」という層が無く、利用者が直接IPアドレスを覚えていたら、クラウドへ移るたびに全国民へ「新しい番号はこちらです」と告知して回らねばなりません。

これが名前とアドレスを分けたことの本当の価値です。覚えやすさは副産物にすぎません。

2. なぜ1台の巨大な対応表にしないのか

では、名前とアドレスの対応表を、世界のどこかに1つ用意すればよいのではないか。初期のインターネットは実際にそれに近いことをしていました。しかしこれは3つの理由で破綻します。

• 更新が集中する。 世界中のドメインの追加・変更が1か所に集まる。誰が何を更新してよいかという権限管理まで1か所で背負う
• 検索が破綻する。 数億件の表を、世界中からの毎秒何百万回もの問い合わせに対して引き続けることになる
• 止まったら全部止まる。 単一障害点になる

そこで実際のDNSが採った解決は、木構造にして、管理の権限そのものを階層的に委譲するというものでした。日本ネットワークインフォメーションセンター（JPNIC）は、この仕組みをこう説明しています。

そして木構造であることによって、名前が重複しないことが自動的に保証されます。

ここが美しいところです。世界中の名前が重複しないことを、どこかで一括チェックしているわけではありません。 「自分の直下に同じラベルを2つ作らない」というローカルなルールを各階層が守るだけで、全体の一意性が出てくる。上の階層は、下の階層で何が起きているかを知る必要がないのです。

2-1. 第70講と、まったく同じ設計思想である

ここで第70講「IPアドレスとサブネット」を思い出してください。IPアドレスは32ビットを「ネットワーク部（まち）」と「ホスト部（番地）」の二段構えにしていました。目的は、ルータが世界中の全端末を1台ずつ覚えなくても済むようにすることでした。「このまち宛てはあっち」とだけ覚えておけば、まちの中の番地はそのまちのルータが知っている。

DNSがやっていることは、これと同じです。

「全部を1か所で持たず、階層に切って下へ権限を渡す」── インターネットは、アドレスでも名前でも同じ手を使っています。 この設計思想が見えると、第68講の階層モデルも含めて第4部が一本につながります。

3. ドメイン名は右から左に読む

www.mext.go.jp を例に取ります。JPNICはこう説明しています。

つまり読み方はこうです。

• jp … トップレベルドメイン（日本）
• go … 第2レベル（日本国政府機関）
• mext … 第3レベル（文部科学省）
• www … 第4レベル（その中のこのホスト）

▲ ドメイン名空間は、逆さまの木。名前は下から上へ、ラベルは右へ行くほど上位になる。

左が細かく、右が大きい。 郵便の住所とは順序が逆です（日本の住所は「東京都→千代田区→…」と大きいほうから書きます）。この向きは、共通テストでURLの構造を読ませる問題でそのまま問われます。

なお https://www.mext.go.jp/a_menu/ というURL全体のうち、DNSが解決するのは www.mext.go.jp の部分だけです。https はプロトコル名、/a_menu/ はそのサーバの中でのパスであって、名前解決には関与しません。ここを混同すると、URLの構造を問う設問で必ず落とします。

4. 木の根っこは誰が持っているのか

木構造には根が要ります。それがルートサーバです。JPNICはこう書いています。

13という数は「世界に13台しか機械が無い」という意味ではありません。同じ記事はこう続けています。

1つの名前・1つのアドレスの裏に、世界中に散らばった多数の実機がいる。 これもまた、名前と実体を分けたからこそできる芸当です。第1節で見た「引っ越しても名前は変わらない」の、極端な応用例だと思ってください。

5. キャッシュとTTL ── なぜ必要で、何を代償にしているか

もし世界中のパソコンが、ページを開くたびにルートサーバから順に聞き直していたら、13の名前で表されるルートサーバに全人類の問い合わせが集中します。 それでは絶対に持ちません。

だからDNSには、一度得た答えをしばらく覚えておく仕組みがあります。

この「ある時間」を秒数で指定するのがTTL（Time To Live）です。日本レジストリサービス（JPRS）の用語辞典は、TTLをこう定義しています。

第68講で扱ったIPヘッダのTTLとは別物です。IPヘッダのTTLはルータを通るたびに1減る「残りホップ数」、DNSのTTLは「あと何秒キャッシュしてよいか」。層が違えば、同じ語が別の意味を持ちます。

そしてキャッシュには代償があります。サーバを引っ越してアドレスを書き換えても、TTLが切れるまでは世界中のキャッシュに古い答えが残る。 だから引っ越しの前には、あらかじめTTLを短くしておく、という運用上の作法が生まれます。

速さと正しさのトレードオフ。 第68講でTCPとUDPを「信頼性 対 速さ」で選び分けたのと、まったく同じ構図がここにも現れています。

6. DNSは「名前が本物である」ことを保証しない

本講でいちばん誤解されている点を書いておきます。DNSが返すのは「この名前に対応するアドレスはこれです」という対応表の中身だけであって、その答えが本物のサーバから来たことも、そのサーバが名乗っている組織の本物であることも、DNSそのものは保証しません。

だからこそ、答えを偽装する攻撃が成立します。情報処理推進機構（IPA）の基本情報技術者試験シラバス（Ver.9.2）は、攻撃手法の用語例にDNSキャッシュポイズニングを、情報セキュリティ技術の用語例にDNSSECを挙げています。前者は偽の答えをキャッシュに覚え込ませる攻撃、後者はDNSの答えに電子署名を付けて改ざんを検知できるようにする拡張です。

そして私たちが日常的に使っている防御が、もう1つあります。HTTPSのサーバ証明書です。仮にDNSが偽のアドレスを返して偽サーバへ接続させられても、そのサーバは「本物のsukyojuku.comである」と証明する証明書を持っていないので、ブラウザが警告を出します。

名前解決（DNS）は「どこにあるか」を教える仕組み、サーバ証明書（HTTPS）は「本物か」を確かめる仕組み。 役割がまったく違うので、両方が要ります。この続きは第74講「Webの仕組み（HTTP・HTTPS）」で扱います。

7. 手で確かめる ── dig で名前解決を1段ずつ歩く

ここからは実機で確認します。macOS・Linuxなら dig、WindowsならPowerShellの Resolve-DnsName か nslookup が使えます。以下はすべて私が2026年8月3日に手元で実行した実際の出力です。問い合わせ先は自社サイト（sukyojuku.com）と公的機関の公開ドメインに限り、自分の環境のDNSサーバのアドレスはマスクしました。

7-1. 名前からアドレスを引く

$ dig sukyojuku.com A +noall +answer
sukyojuku.com.    362  IN  A  163.44.185.200
$ dig www.mext.go.jp A +noall +answer
www.mext.go.jp.   195  IN  A  202.238.130.103

行の読み方は左から「名前 ／ TTL（秒）／ クラス ／ レコードの種類 ／ 値」です。A は「この名前に対応するIPv4アドレス」を表すレコード種別。362 は「あと362秒はこの答えを使い回してよい」という意味です。

7-2. ルートから順に降りていく

ふだんは自動でやってくれる名前解決を、手で1段ずつ歩いてみます。@サーバ名 で、聞きに行く相手を指定できます。

第1段：ルートサーバに「com は誰が管理している？」と聞く

$ dig @a.root-servers.net com NS +noall +authority
com.  172800  IN  NS  a.gtld-servers.net.
com.  172800  IN  NS  b.gtld-servers.net.
com.  172800  IN  NS  c.gtld-servers.net.
（以下 l.gtld-servers.net. まで計13行）

注目してほしいのは、ルートサーバは sukyojuku.com のアドレスを答えていないことです。答えたのは「com のことは gtld-servers.net に聞け」という委任先の案内だけ。 ルートサーバは世界中のドメインを知らないし、知る必要もありません。

第2段：comのサーバに「sukyojuku.com は誰が管理している？」と聞く

$ dig @a.gtld-servers.net sukyojuku.com NS +noall +authority
sukyojuku.com.  172800  IN  NS  uns01.lolipop.jp.
sukyojuku.com.  172800  IN  NS  uns02.lolipop.jp.

またしてもアドレスは返ってきません。返ってきたのは次の委任先です。ここまでで木を2段降りました。

第3段：権威サーバに聞く

$ dig @uns01.lolipop.jp sukyojuku.com A +noall +answer +comments
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25794
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
sukyojuku.com.  600  IN  A  163.44.185.200

ここで初めてアドレスが返ってきました。そして flags: の行に aa があります。これは authoritative answer（権威ある回答）の略で、「この答えは又聞きではなく、このドメインを管理している本人が出したものだ」という印です。

比較のために、ふだん使っているキャッシュDNSサーバに同じ質問をすると、こう返ってきます。

$ nslookup www.mext.go.jp
Server:   （自分の環境のDNSサーバ・マスク）
Address:  （同・マスク）#53
Non-authoritative answer:
Name:     www.mext.go.jp
Address:  202.238.130.103

Non-authoritative answer（権威のない回答） ── つまり「これは私が誰かから聞いてきて、キャッシュしていた答えです」という自己申告です。この一語の意味が分かるだけで、DNSの構造が見えたと言ってよいでしょう。

7-3. 再帰的な問い合わせを図で見る

上の3段の往復を、キャッシュDNSサーバを主語にして描くと次のようになります。

▲ 再帰的な問い合わせ。キャッシュDNSサーバがルートから順に委任をたどる。TTLが切れるまで、2回目以降は②〜⑦が丸ごと消える。

7-4. TTLが減っていくのを自分の目で見る

キャッシュが本当に働いていることは、同じ質問を時間を空けて繰り返すと確認できます。

$ dig www.mext.go.jp A +noall +answer
www.mext.go.jp.   176  IN  A  202.238.130.103
（5秒後）
www.mext.go.jp.   171  IN  A  202.238.130.103
（さらに10秒後）
www.mext.go.jp.   161  IN  A  202.238.130.103

176 → 171 → 161。 経過した秒数だけTTLが減っています。これは、キャッシュDNSサーバが「この答えはあと何秒使えるか」をカウントダウンしながら手元に持っていることの、動く証拠です。0になれば捨てて、また権威サーバに聞きに行きます。

7-5. 名前とアドレスは1対1ではない

「1つの名前に1つのアドレス」だと思っている人は多いのですが、実際は違います。

$ dig www.dnc.ac.jp +noall +answer
www.dnc.ac.jp.  53  IN  A  3.175.227.121
www.dnc.ac.jp.  53  IN  A  3.175.227.120
www.dnc.ac.jp.  53  IN  A  3.175.227.110
www.dnc.ac.jp.  53  IN  A  3.175.227.8

大学入試センターのサイトは、1つの名前に4つのアドレスが対応しています。これが負荷分散です。 問い合わせるたびに違う順序で返すことで、アクセスを複数のサーバへ散らします。

$ dig www.soumu.go.jp +noall +answer
www.soumu.go.jp.  205  IN  CNAME  soumuweb.jp.
soumuweb.jp.       30  IN  A      210.149.82.7
soumuweb.jp.       30  IN  A      210.149.83.7

総務省のサイトは CNAME（別名）で soumuweb.jp を指し、そこに2つのアドレスがあります。TTLは30秒。短いTTLは「いつでも切り替えられる状態にしてある」という設計上の意思表示です。

名前は1つ、実体は複数、しかも差し替え可能。 第1節で述べた間接参照の利点が、公的機関のサイトでそのまま運用されています。

8. 共通テストではこう出る（重要度 A）

情報Ⅰの4領域のうち「(4) 情報通信ネットワークとデータの活用」からは毎年出題があります。ドメイン名とDNSは、単独の知識問題としても、Webの仕組みを扱う問題の前提としても顔を出します。出方は3つの型に整理できます。

型1：URLからドメイン構造を読む

URLを与えて、どこがトップレベルドメインか、どの組織を表すか、同じ組織のものはどれか、といった読み取りをさせる型です。右がいちばん大きいという向きさえ間違えなければ確実に取れます。

型2：名前解決の順序を問う

「ブラウザにURLを入力してからページが表示されるまで」の流れを並べ替えさせる、あるいは各段階で何が行われているかを選ばせる型です。押さえるべき順序は次のとおり。

• ドメイン名からIPアドレスを得る（DNS／アプリケーション層）
• 得たIPアドレス宛てにパケットを送る（IP／インターネット層）
• TCPで接続を確立する
• HTTPでページを要求する

名前解決が先、通信は後。 ここが逆になった選択肢が定番の誤答です。

型3：DNSの役割そのものを問う

DNSが何をする仕組みかを選ばせる型です。「ドメイン名とIPアドレスを相互に対応づける」が正しい説明になります。

落とし穴

DNSはアプリケーション層のプロトコル。「IPアドレスを扱うからインターネット層」は誤り。
DNSのTTLとIPヘッダのTTLは別物。 前者は秒数、後者は残りホップ数。
DNSは「本物であること」を保証しない。 保証するのはサーバ証明書。
URLのうち名前解決に使うのはホスト名の部分だけ。 パスやクエリは関係ない。
変更は即時には反映されない。 キャッシュがあるので「設定を変えたら直ちに世界中に反映される」は誤り。

私が作った類題

9. 情報Ⅱではこうなる

9-1. まず押さえるべき事実 ── 情報Ⅰの一次資料に、DNSは書かれていない

本講を書くにあたり、私は文部科学省の一次資料を機械的に検索しました。結果は次のとおりです（いずれも2026年8月3日取得）。

学習指導要領解説にある唯一の「DNS」は、共通教科の情報Ⅰ・情報Ⅱではなく、専門教科情報科の科目「ネットワークシステム」の記述です。

情報Ⅱ教員研修用教材 第4章にある唯一の「DNS」も、学習20のポート番号一覧表に「53 DNS」と1行あるだけ。「ドメイン」の1件は「ブロードキャストドメイン」であって、ドメイン名の話ではありません。

つまりDNSは、共通テストで問われるのに、国の共通教科向け一次資料の本文には出てこない項目です。 第70講のサブネットと同じ構図がここにもあります。検定教科書が独自に補っている領域だ、と理解しておくとよいでしょう。逆に言えば、この講は参考書の側が原理から書かないと、誰も原理を教えてくれない場所です。

9-2. 情報Ⅰでの扱い ── 「そういう仕組みがある」で終わる

情報Ⅰでの名前解決は、「ドメイン名とIPアドレスを対応づける仕組みがDNSである」という与えられた前提です。生徒はそれを使う側であって、設計する側ではありません。

文部科学省の授業用コンテンツのワークシートにも、端末の設定項目として「IPアドレス、サブネットマスク、デフォルトゲートウェイ（ルータ）、DNSの設定」を挙げてpingで通信確認をする実習が示されていますが、ここでもDNSは「設定する欄の1つ」として登場するにとどまります。

9-3. 情報Ⅱでの扱い ── 名前解決がシステム構成の設計要素になる

情報Ⅱの「情報システムとプログラミング」に入ると、立場が変わります。自分が情報システムを設計する側になるからです。文部科学省「情報Ⅱ」教員研修用教材 第4章の記述に当てながら見ていきましょう。

(1) 学習19 ── 処理をどこに置くかを決める

学習19「情報システム全体の情報の流れ」は集中処理と分散処理を対比し、分散処理を「1台のコンピュータが故障しても処理を継続できるため信頼性が高く、機能の拡張が容易ではあるが、保守やセキュリティ管理、運用管理が複雑になる」と評価したうえで、こう述べています。

そして学習19は、Webサーバ・データベースサーバ・メールサーバといったサーバの種類を役割ごとに列挙し、3層クライアントサーバシステムを扱います。

ここで本講が効いてきます。サーバを役割ごとに別の機械へ分ける、あるいはクラウドへ移す ── これを利用者に一切気づかせずに実行できるのは、間に「名前」という層が挟まっているからです。 第1節で見た www.ipa.go.jp → cloudfront.net、www.e-stat.go.jp → oraclecloud.net が、まさにこのクラウド移行の実物でした。情報Ⅰでは「そういう対応表がある」だった名前解決が、情報Ⅱでは「どこに何を置くかを後から変えられるようにしておくための仕掛け」になります。

(2) 学習20 ── 名前解決が制御の対象になる

学習20「情報システムの情報セキュリティ」には「ポート番号とプロトコルの例」の表があり、22（SSH）・53（DNS）・80（HTTP）・123（NTP）・443（HTTPS）が並びます。そして、送信元・宛先のIPアドレスとポート番号でルールを決めるパケットフィルタリングと、DMZが説明されます。

情報Ⅰでは「DNSはアプリケーション層のプロトコル」で終わっていたものが、情報Ⅱでは「53番を内から外へ通すか、社内のDNSサーバにだけ集約するか」という設計上の意思決定になります。名前解決が、知識から通す／通さないを決める対象へ格上げされるわけです。

(3) 学習24 ── 切り替えが動くことをテストする

学習24「分割したシステムの結合とテスト」は非機能テストを扱い、「多数のユーザーからアクセスされて負荷が高くなったときでも正常に動作するかどうかの性能テストは非常に重要になる」と述べます。さらに、

「二重化して、異常時に自動的に切り替わる」。 これがWebシステムで具体的にどう実装されるかを考えると、本講の内容に直結します。第7節で見たとおり、公的機関のサイトは1つの名前に複数のアドレスを持ち、TTLを30秒程度に短く設定していました。短いTTLは「切り替えを速く効かせるための設計値」です。

情報Ⅰでは「TTL＝キャッシュしてよい秒数」という定義で終わりますが、情報ⅡではTTLが可用性の設計パラメータになります。

(4) 学習22 ── 名前がインタフェースになる

学習22「情報システムの分割と設計」のソフトウェア詳細設計は、プログラムを「モジュールと呼ばれる単位に分割・階層化し、モジュール間のインタフェースを明確にする」ことを求めます。

ドメイン名は、システムの外向きのインタフェースそのものです。「この名前で呼べばこのサービスが応答する」という約束だけを外に見せ、中で何台がどう動いているかは隠す。学習23の実習でPythonから叩く図書検索のWeb APIも、プログラムから見ればホスト名という1つの約束であって、その裏のサーバ構成は知らなくてよいのです。

9-4. 情報Ⅰと情報Ⅱの違いを一言で

情報Ⅰの「名前を覚えやすくするため」は、情報Ⅱの「実体を隠して差し替え可能にするため」への助走です。 今日この講で持ち帰ってほしいのは、ドメイン名の階層の名前ではなく、「間に名前を1つ挟むと、後から中身を変えられる」という設計の考え方のほうです。