DNS：名前をアドレスに変える

13のルートネームサーバーは、12の組織が世界中の2047台の機械で運用しています（root-servers.org、2026年10月17日）。

背景DNSができる前は、ARPANETのどのコンピューターも、すべてのホスト名とアドレスを並べた一つのテキストファイルHOSTS.TXTの写しを持っていました。スタンフォード研究所のネットワーク情報センターがこれを管理し、各サイトが新しい写しをダウンロードしていました。ネットワークが大きくなるとファイルも大きくなり、変更が広まるのに時間がかかるようになり、名前もぶつかるようになりました。RFC 1034はこの問題と、それに代わった設計を説明しています。名前の木で、その一部分ずつをそれぞれのサーバーが受け持つしくみです。DNSは1987年にRFC 1034とRFC 1035として公開されました。

今ではだれもそのファイルをダウンロードしません。198.51.100.20ではなくexample.comと入力し、名前は必要になったその時に調べられます。それでもルーターにわかるのは数だけなので、ブラウザーがWebサイトにパケットを一つ送る前に、名前をアドレスに変えなければなりません。それをするのがドメインネームシステム（DNS）で、Cloudflareのガイドはこれをインターネットの電話帳と呼んでいます。

名前は木をたどる道

www.example.comは右から読みます。いちばん上は、見えない点で表されるルートです。その下に、com、org、krのようなトップレベルドメイン（TLD）があります。comの下にexample、その下にwwwがあります。一つ一つの部分をラベルと呼びます。RFC 1035は、ラベル一つにつき63バイトまで、名前全体で255バイトまでを認めています。木の枝ごとに別の組織が運用しているので、すべての名前を知っているコンピューターが一台ある必要はありません。どの機械にもある一つのファイルが全部を抱えこもうとしたHOSTS.TXTで、まさにうまくいかなかったのはそこでした。

DNSの木。www.example.comは、www → example → com → ルートという道で、左から右に読みますが、調べるときはルートから下へたどります。

四つのサーバー、八つのステップ

Cloudflareは、名前を調べるときに出てくる4種類のサーバーを挙げています。フルサービスリゾルバーは、ふつうISPか公共のDNSサービスが運用していて、あなたの代わりに走り回ります。ルートサーバーは、TLDサーバーがどこにあるかを知っています。comのようなTLDサーバーは、その下の各ドメインをどのサーバーが持っているかを知っています。ドメインの権威サーバーは実際のレコードを持ち、最終的な答えを返します。何もキャッシュされていなければ、調べるのに8ステップかかります。コンピューターがリゾルバーに尋ねます。リゾルバーはルートに尋ね、ルートはcomを指し示します。comに尋ねると、ドメインのネームサーバーを指し示します。そこに尋ねるとアドレスが返り、リゾルバーがそのアドレスをあなたに渡します。

読み込み中

ドラッグで回転、スクロールまたはピンチで拡大・縮小。

「次のステップ」を8回押すか、「再生」を押しましょう。次に「もう一度問い合わせる」を押すと、ブラウザーのキャッシュがすぐに答え、コンピューターからメッセージは一つも出ていきません。「1分待つ」を押してもう一度問い合わせると、ブラウザーの写しは期限切れですが、OSのキャッシュにはまだ残っています。「1時間待つ」を押すと、3600秒のTTLがどこでも切れ、最初から全部調べ直します。

2回目の問い合わせがすぐ終わる理由

問い合わせのたびに8ステップかかっていたら、DNSは遅く、ルートサーバーは質問でおぼれてしまいます。だから答えはとっておかれます。ブラウザー、オペレーティングシステム、リゾルバーにキャッシュされるのです。どのレコードにも、ドメインの持ち主が決めた秒単位の生存時間がついています。TTLが3600なら「この答えは1時間使い回してよい」という意味です。TTLが短ければ持ち主はサイトをすばやく移せ、長ければ問い合わせが減ります。ルートサーバーも分散しています。aからmまでの名前がついた13のルートサーバーは、2026年10月17日の時点で2047の別々のインスタンスとして動いていました。

2種類の質問、一つのポート

一回の問い合わせには2種類の質問がまじっています。コンピューターはリゾルバーに再帰問い合わせを送ります。「最終的な答えか、エラーをください」という意味です。するとリゾルバーはルート、TLD、権威サーバーに反復問い合わせを送り、それぞれが持っている最善のものを返します。多くの場合、それは次のサーバーの指し示しだけです。DNSメッセージは53番ポートへ送られ、ふつうはUDPを使います。質問も答えも一つのパケットに収まるからです。大きな答えやサーバー間の転送にはTCPを使い、RFC 7766はTCPを完全なDNS実装の必須の部分としています。自分で試すこともできます。たいていのコンピューターでは、nslookup example.comというコマンドが、使ったリゾルバーと返ってきたアドレスを表示します。

レコードが持つのはアドレスだけではない

レコード	持っているもの	例
A	IPv4アドレス	www.example.com → 198.51.100.20
AAAA	IPv6アドレス（RFC 3596）	www.example.com → 2001:db8::20
CNAME	代わりに調べる別の名前	shop.example.com → example.com
MX	ドメインのメールサーバー	example.com → mail.example.com
NS	権威ネームサーバー	example.com → ns1.example.com

キャッシュのない状態でwww.example.comを調べます。リゾルバーはどのサーバーにどの順で尋ねますか？
www.example.comの最終的な答えを返すのはどのサーバーですか？
- example.comの権威サーバー
- ルートサーバー
- comのTLDサーバー
- Webサーバー
Cloudflareの説明では、キャッシュのない問い合わせは何ステップかかりますか？
IPv6アドレスを持つのはどのレコードですか？
- AAAA
- A
- MX
- CNAME
レコードのTTLは3600です。キャッシュはそれを何分間使い回せますか？
RFC 1035で、一つのラベル（exampleなど）の長さの上限はいくつですか？
名前のついたルートサーバーはいくつありますか？
10秒前にある名前を調べ、ブラウザーのキャッシュはそれを60秒間保ちます。今もう一度調べると、コンピューターからDNSメッセージはいくつ出ていきますか？
MXレコードは何のためにありますか？
- ドメインのメールサーバーを示すため
- Webページを保存するため
- IPv6アドレスを持つため
- ほかのレコードのTTLを決めるため
DNSは何に代わるものでしたか？
- すべてのコンピューターに写された一つのHOSTS.TXTファイル
- 電話網
- IPアドレス
- ルーター

よくある間違い

「DNSはWebページを保存している。」 DNSが答えるのは、アドレス、メールサーバー、別の名前といったレコードだけです。ページそのものは、DNSが返したアドレスにあるWebサーバーから来ます。
「サイトがアドレスを変えると、すぐに全員が新しいアドレスを見る。」 ブラウザー、オペレーティングシステム、リゾルバーは、TTLが切れるまで古い答えを持っています。TTLが3600なら、最長1時間は古いアドレスに送られる訪問者がいることがあります。
「ルートサーバーのコンピューターはちょうど13台ある。」 aからmの13の名前があり、12の組織が運用しています。2026年10月17日には、世界中の2047のインスタンスから答えていました。
「わたしのコンピューターが自分でルートサーバーに尋ねる。」 コンピューターはフルサービスリゾルバーに一度尋ねるだけです。リゾルバーがルートからTLDサーバー、権威サーバーへとたどり、結果だけを返します。

先生からひとこと何かをかく前に、いくつかの名前をいっしょに右から左へ読みましょう。最初に身につけさせたいのはこの読み方です。学習者の図からよく抜け落ちるのがリゾルバーです。コンピューターとは別にかき、コンピューターから出る矢印はすべてそこで止めましょう。シミュレーターの8ステップを一度動かし、すぐに「もう一度問い合わせる」を押します。何も送らない2回目の問い合わせは、定義よりもよくキャッシュを説明してくれます。ターミナルが使えるなら、クラスがすでに知っているサイトでnslookupを使うと、図が本物になります。

ポイント

DNSは名前をアドレスに変える。名前は右から左へ、木を下りるように読む。
フルサービスリゾルバー → ルート → TLD → 権威サーバー：キャッシュがなければ8ステップ。
答えはレコードのTTL（秒）の間、ブラウザー、OS、リゾルバーにキャッシュされる。
A = IPv4、AAAA = IPv6、CNAME = 別名、MX = メール、NS = ネームサーバー。

このコースの出典 (28)

(checked 2026-10-17; reordered 2026-10-19: standards first, then official documentation, then operators and papers, history sources last)
IETF RFCs (rfc-editor.org): RFC 768 UDP (1980, 8-byte header)
RFC 791 IPv4 (1981, 32-bit addresses, "does not provide a reliable communication facility", TTL field "measured in units of seconds" but every module must decrease it by at least one, so it is only an upper bound)
RFC 792 ICMP (Time Exceeded)
RFC 801 NCP/TCP transition plan (1 January 1983)
RFC 894 Ethernet (1500-byte payload)
RFC 1034 and RFC 1035 DNS (1987, HOSTS.TXT kept by SRI-NIC, labels up to 63 octets and names up to 255, TTL in seconds)
RFC 1122 (127.0.0.0/8 loopback)
RFC 1918 private addresses (10/8, 172.16/12, 192.168/16)
RFC 2131 DHCP, RFC 3022 NAT, RFC 3596 AAAA records, RFC 3849 and RFC 5737 documentation addresses, RFC 4271 BGP-4, RFC 4291 IPv6 text form, RFC 6298 TCP retransmission timer (initial RTO 1 second)
RFC 6335 port ranges (0-1023, 1024-49151, 49152-65535)
RFC 7766 DNS over TCP, RFC 8200 IPv6 (128-bit addresses, Hop Limit)
RFC 8446 TLS 1.3 (one round-trip handshake)
RFC 9000 QUIC and RFC 9114 HTTP/3, RFC 9110 HTTP semantics (status code classes)
RFC 9293 TCP (three-way handshake, sequence numbers)
IANA: ip-parameters registry (recommended default TTL 64)
IPv4 free pool depleted 3 February 2011 (NRO and ARIN announcements)
Official documentation: MDN Web Docs "How does the Internet work?" (45 cables for 10 computers, switches, routers, MAC and IP addresses, internet and web)
"What is a URL?", "HTTP response status codes" (developer.mozilla.org)
Cloudflare Learning Center: "What is DNS?" (four kinds of DNS server, 8 steps of an uncached lookup, browser and OS caches, TTL)
"What is HTTP/3?" (cloudflare.com/learning)
Google Chrome Help, "Browse in Incognito mode" (support.google.com/chrome/answer/95464, checked 2026-10-19: Incognito limits what is saved to the device; websites and organisations that manage your network, like your school, employer or internet service provider, may be able to observe your activity)
Operators and papers: root-servers.org (13 root name servers run by 12 organisations, 2047 instances on 2026-10-17)
Jacobson and Karels 1988, Congestion Avoidance and Control (loss mostly congestion)
History blocks only: UCLA Samueli School of Engineering, Internet50 (first ARPANET message "LO", UCLA to SRI, 29 October 1969, 22:30)
historyofinformation.com and Wikipedia ARPANET (Kline)
Spiceworks/SRI history (HOSTS.TXT kept by SRI-NIC)
Numbers (2^32, 2^96, 45 and 6 cables, packet counts, round-trip times)

確認日: 2026-10-17