雰囲気でDNSを設定していたので、仕組みを自分なりにまとめてみた

Posted at 2026-06-08

この記事は AI を利用して執筆しています。
内容は筆者が確認していますが、誤りや不正確な記述が含まれる可能性があります。お気づきの点があれば、コメントでご指摘いただけると助かります。

はじめに

ドメインの設定をするとき、A、CNAME、TXT などのレコードを「記事の手順通りに入力したら動いた」で済ませてきました。ただ、DNSの基本的な仕組みは昔から変わっていないのでは？と思い、今後もおそらく使い続けるものなので、一度ちゃんと理解しようと、調べたことを自分なりに整理しました。

この記事でわかること

A / AAAA / CNAME / NS / MX / TXT それぞれが「本当は何をしているのか」
TTLとキャッシュの仕組み。「DNSの浸透待ち」の正体
CloudflareなどCDNの「プロキシステータス」がDNSの何を変えているのか

1. 名前解決の全体像

調べる前の私の理解は、「レコードにはタイプがあり、値には向き先を書く」という程度でした。

たとえば example.com に app.example.com というサブドメインを生やすとき——名前に app、タイプに CNAME、値にホスティング先（Vercel なら cname.vercel-dns.com）を登録する。この操作自体は知っているけれど、登録したあとにサーバー同士が裏で何をしているのかは曖昧、という状態でした。

そこで最初にAIへ質問したところ、こう返ってきました。

DNSは単一のデータベースではなく、委任（delegation）で繋がった分散システムです。www.example.com を解決するだけで、役割の異なる複数のサーバーが関わっています。

最初はこの「委任」の意味が分からず、むしろ混乱しました。腑に落ちたのは、上位のサーバーは最終的な答えを持っておらず、持っているのは「次はどこに聞けばいいか」だけだと分かったときです。

その前に、用語を一つ。ドメインは www.example.com のようにドットで区切られ、右にいくほど大きな括りになっています。一番右の .com（ほかに .jp、.org など）を TLD（Top Level Domain＝トップレベルドメイン） と呼びます。.com の下に example.com、さらにその下に www.example.com、という入れ子の構造です。

この入れ子をたどって www.example.com を解決する流れを、「誰が答えを持っているか」で見ると、こうなります。

ルートサーバー：www.example.com の住所は知らない。でも「.com の担当サーバーはどれか」は知っている → そこへ案内するだけ
.com TLDサーバー：example.com の中身は知らない。でも「example.com の担当サーバーはどれか」は知っている → そこへ案内するだけ
example.com 権威サーバー：ここで初めて「www の A は 203.0.113.10」と答えを返す

ポイントは、上位サーバーは「責任を持っていない」のではなく、ごく狭い責任（次の担当は誰か）だけを確実に持っているということです。答え自体はちゃんと存在していて、ただ一番下の権威サーバーにしか無い。上の階層は答えへ案内する係、一番下は答えを持っている係、と役割が分かれているだけでした。

まず、レコードには種類がある

委任の話に入る前に、設定画面に出てくるレコードを一度顔見せしておきます。どれも「名前 → 値」の対応表という点は共通で、違うのは値が何を意味するかだけです。

レコード	値に書くもの	ひとことで言うと
A	IPv4アドレス	名前を住所（IP）に変換する。これが最終的な答え
AAAA	IPv6アドレス	Aのv6版
CNAME	別のドメイン名	「この名前は別名。本名はこっち」と転送する
NS	担当のDNSサーバー名	「この先は別のサーバーに聞いて」と委任する
MX	メールサーバー名	このドメイン宛メールの配送先
TXT	任意の文字列	所有者証明やメール認証などに使う

この表の中に、さっきの委任の話がそのまま入っています。ルートやTLDがやっていた「答えは知らないが、次の担当を案内する」——これが NS です。値に書いてあるのは答え（IP）ではなく、次に聞くべきサーバー名でした。逆に、一番下の権威サーバーが返していた「これが答え」が A で、こちらの値は最終的なIPそのものです。

同じ「名前 → 値」の表でも、NSの値は"次の宛先"、Aの値は"終点の答え"。この差が、委任（ルート → TLD → 権威）を繋ぐ NS と、最後に答えを出す A を分けています。まずは委任を担う NS を掘り下げ、残りのレコードは最後に「値が"答え"か"次の宛先"か」という同じ物差しで整理し直します。

なぜ「繋がる」のか — 各段をNSが繋いでいる

誰も全体を把握していないのに、なぜ上から下まで必ずたどり着けるのか。理由は、各段に「次はここ」という引き継ぎ（＝NSレコード）が1本ずつ記録されているからです。

たとえば .com のサーバーが example.com の担当を知っているのは、ドメイン登録時に「example.com の担当は ns1.provider.net」というNSレコードが .com 側に書き込まれたから。各境目にこのNSが切れ目なく続いているので、上から順にたどれば必ず一番下の「答え（A）を持っている係」に着地します。

そして普段の作業と直結するのがここでした。レジストラの管理画面でネームサーバーを設定する操作は、まさにこの「次はここ」というNSを自分で書き込む行為です。自分のドメインの委任先を、親（.com）に対して登録しているわけです。

役割を整理する

ここまでの登場人物を表にまとめると、次の通りです。

登場人物	役割
スタブリゾルバ	OSに組み込まれたクライアント。問い合わせを投げるだけ
フルリゾルバ（キャッシュDNSサーバー）	再帰的に解決して結果をキャッシュする。`1.1.1.1` や `8.8.8.8` がこれ
ルートサーバー	「`.` ゾーン」の権威サーバー。TLD（`.com` など）のサーバーの場所を教える
TLDサーバー	「`.com` ゾーン」の権威サーバー。各ドメインのサーバーの場所を教える
権威DNSサーバー	「`example.com` ゾーン」のレコードを実際に持っている。普段設定画面で編集しているのはここ

言葉だけだと固いので、身近な例に置き換えます。www.example.com を右から左に読むと com → example → www という入れ子になっていて、これは大きな会社で社員の内線番号を調べるのに似ています。

あなたは代表番号（＝リゾルバ）に1回電話して「www.example.com さんにつないで」と頼むだけ
ルート：本人は知らない。でも「.com 担当の部署はあそこ」とだけ教える
.com TLD：やはり本人は知らない。「example 課はあそこ」とだけ教える
example.com 権威：ここで初めて「www さんは 203.0.113.10」と本人につなぐ

大事なのは2点だけです。

あなたは1回頼むだけ。部署から部署へのたらい回しは、代表番号側（リゾルバ）が代わりに歩いてくれる
各段は"本人"を知らない。知っているのは"次に聞く部署"だけ。下に降りるほど担当範囲が狭まり、最後の段で初めて本人にたどり着く

この「次はあの部署へ」という引き継ぎ1本1本が、さっき出てきた NSレコードです。

同じ流れを、正式な登場人物で図にするとこうなります（キャッシュが空の初回アクセスを想定）。

図でたとえに出てこなかったのが S（スタブリゾルバ）です。これは「名前を調べて」というブラウザの依頼を、設定済みのDNSサーバー R（8.8.8.8 など）へそのまま転送するだけのOSの機能で、自分では何も調べません。つまり B → S → R は「ブラウザ → OS → 外のDNSサーバー」、問い合わせがあなたのPCの中から外へ出ていくところを描いています。そこから先、ルート → TLD → 権威とたらい回しを歩くのが R で、これがたとえの"代表番号"にあたります。

Valueは「答え」がデフォルト、NSのときだけ「次の宛先」

ここまでで「NSのValueは"次の宛先"」と分かりました。すると逆に気になるのが、他のレコードのValueも"次の宛先"なのか？ という点です。実はここに、自分が最初に勘違いしていた点がありました。「レコードのValueは次の問い合わせ先で、そこへ聞きにいくものだ」と思っていたのですが、これは正確ではありません。Valueの役割は、レコードの種類で2つに分かれます。

A / AAAA / TXT のValue＝終点の答え。A 203.0.113.10 は「そこへ問い合わせる先」ではなく、これがゴール。問い合わせはここで止まる
NS のValue＝委任先。「次はこのサーバーに聞け」という引き継ぎで、ここでは止まらず、もう一段先へ聞きにいく

「Valueに向けて問い合わせる」が当てはまるのは、基本的にNSだけ。A や TXT のValueは、たどり着いた先にある中身そのものでした。

なお MX は少し中間的です。値は IP ではなくメールサーバーの"ホスト名"なので、実際に配送するにはその名前をもう一度 A に解決し直す必要があります。終点の答え（IP）そのものではなく、「答えのある名前」を指している——この点では、次に出てくる CNAME に近い性質です。

この区別が分かると、「NSでずっと繋がっていくと無限に先があるのでは？」という疑問も解けます。終点がどこかで整理すると——

A / AAAA＝本物の終点。IPが入っていて、ここで完全に終わる
NS＝階層を下に降りる委任。ただし委任が起きるのはゾーンの境目だけで、その数は有限。最後のゾーンに着いたら、あとはそのゾーンが持つAレコードでおしまいなのでAに着地する
CNAME＝横にずれる転送（別名）。指された名前で解決をやり直し、最終的にAに着地する

NSは「下に」、CNAMEは「横に」ずれるだけで、最終的な行き先はどちらもA。終点を持っているのは実質 A / AAAA だけ、と捉えるとすっきりしました。

※ ここで一つ補足を。委任はラベルごとに毎回起きるわけではありません。com → example.com は委任（ゾーンの境目）ですが、example.com → www.example.com は普通は委任ではなく、www は example.com ゾーンの中のただのAレコードです。だから 1 章の図でも、権威サーバーが委任ではなく「www の A」を直接返していました。「段ごとに必ずNSがある」わけではなく、「NSはゾーンの境目にだけある」のが正確なところです。

ここまで図と言葉で追ってきた「委任の連鎖」は、dig +trace で実物として観察できます。各段で返ってくるNSレコードが、そのまま画面に出てきます。

$ dig +trace www.example.com

.                       518400  IN  NS  a.root-servers.net.      # ルートの場所
...
com.                    172800  IN  NS  a.gtld-servers.net.      # ルートが返したNS
...
example.com.            172800  IN  NS  a.iana-servers.net.      # TLDが返したNS
...
www.example.com.        300     IN  A   203.0.113.10             # 権威が返した答え

2. TTL とキャッシュ — 「浸透待ち」の正体

1章では、www.example.com を1回引くだけで、リゾルバがルート → TLD → 権威と何度も往復していました。もしアクセスのたびに毎回これを繰り返していたら、表示は遅いし、ルートやTLDのサーバーも世界中からの問い合わせで溢れてしまいます。

そうならないのは、**リゾルバが一度引いた答えを一定時間おぼえておく（キャッシュする）**から。その「おぼえておく秒数」が TTL（Time To Live） です。

1章の図で、権威サーバーが A 203.0.113.10 (TTL 300) と返していたのがこれでした。「この答えは300秒間は使い回していい」という意味です。最初のアクセスだけ全部歩いて、続く300秒間は同じ答えをリゾルバの記憶から即答する——だから2回目以降は速い。TTLが切れたら、また権威サーバーまで聞きにいって記憶を更新します。

ここで押さえたいのは、**TTLはレコードの"中身"ではなく"賞味期限"**だということ。203.0.113.10 という答え自体には影響せず、「何秒キャッシュしてよいか」だけを決めています。

「DNS浸透待ち」は、実は"浸透"していない

ここがずっと誤解していた点でした。レコードを書き換えると「反映に時間がかかる、DNSが浸透するまで待って」とよく言われます。新しい値が世界中にじわじわ広がっていくイメージを持っていましたが、実際は逆でした。

レコードを変更すると、あなたの権威サーバー上では即座に新しい値になる。そこに「広がるのを待つ」要素は無い
時間がかかるのは、世界中のリゾルバがまだ"古い値"をキャッシュに抱えているから。各リゾルバのキャッシュがTTLで切れて初めて、新しい値を取りに来る

つまり「浸透待ち」の正体は、新しい値が広がる時間ではなく、古いキャッシュが期限切れになるのを待つ時間でした。ユーザーごとに使っているリゾルバが違い、キャッシュの残り時間もバラバラなので、切り替え直後は「もう新しいサイトが見える人」と「まだ古いサイトの人」が混在します。

だから実務では、IPを変える予定があるなら、変更の数日前にTTLを短く（例: 300秒）しておくのが定石でした。こうしておくと、切り替え時には世界中のキャッシュが最長でも5分で切れるので、待ち時間が短くなります。逆に普段は長めのTTLにしておけば、無駄な問い合わせが減ってリゾルバにもサーバーにも優しい。

補足として、「存在しない」という答えもキャッシュされます（ネガティブキャッシュ）。レコードを新規追加したのに、しばらく NXDOMAIN（そんな名前は無い）が返り続けることがあるのはこれが原因です。追加する前にうっかり一度問い合わせてしまうと、「無い」という答えが先にキャッシュされてしまうためでした。

3. Cloudflare の「プロキシステータス」— DNS の何が変わるのか

最後に、CloudflareでDNSを設定すると必ず出てくる、レコード横のオレンジ色の雲マークの話です。あれをオン/オフすると何が変わるのか、ずっと雰囲気で切り替えていました。

結論から言うと、変えているのは A / AAAA レコードが返すIPアドレスそのものです。

DNS only（灰色の雲・プロキシOFF）：Aレコードはあなたのサーバーの実IPをそのまま返す。ブラウザはその実IPへ直接つなぎにいく。Cloudflareは1章でいう「答えを返す権威サーバー」の役だけを果たし、通信そのものには関わらない
Proxied（オレンジの雲・プロキシON）：Aレコードはあなたの実IPではなく、CloudflareのIPを返す。ブラウザはまずCloudflareにつなぎ、Cloudflareが裏であなたのサーバー（オリジン）へ取り次ぐ

この「いったん自分で受けて、裏のサーバーへ取り次ぐ」役回りをリバースプロキシと呼びます。通信がCloudflareを通るようになるからこそ、CDNのキャッシュ・WAF・DDoS防御・TLS終端といった機能が効くわけです。同時に、返すIPがCloudflareのものに置き換わるので、あなたのサーバーの実IPが外から見えなくなるという効果もあります。

1章の枠組みで言えば、名前解決の道のり（ルート → TLD → 権威）は何も変わっていません。変わるのは一番最後、権威サーバー（＝Cloudflare）が返す A の値が「あなたのIP」か「CloudflareのIP」か、それだけ。プロキシのオン/オフは、結局最後に返す1個のレコードの答えを差し替えているだけでした。

オン/オフを切り替えると、何が起きる・何が詰まるのか

押さえるべきは「オン＝通信がCloudflareを通る／オフ＝サーバーに直接つながる」の一点だけで、実際の問題はすべてここから派生します。

オンにしたとき

Webアクセス（HTTP/HTTPS）以外は通らなくなる。Cloudflareがプロキシするのは基本的にWebの通信だけです。そのレコードをSSH接続・メールサーバー・ゲームサーバーなど"Web以外"に使っていると、オンにした瞬間に値がCloudflareのIPへ化け、つながらなくなります。こういうレコードは灰色（DNS only）のままにする必要があります
HTTPSの証明書が2区間に分かれる。「ブラウザ ↔ Cloudflare」と「Cloudflare ↔ あなたのサーバー」で別々にTLSが張られます。この設定（CloudflareのSSL/TLSモード）がサーバー側の挙動と噛み合わないと、リダイレクトが無限ループする（ERR_TOO_MANY_REDIRECTS）といった典型的な詰まりが起きます
サーバーから見た接続元がCloudflareのIPになる。アクセスログやIP制限を実IPで見ているなら、CF-Connecting-IP などのヘッダから本物のIPを取り直す必要があります

オフにしたとき

サーバーの実IPがまた世界から見える。プロキシの売り（DDoS防御・WAF・実IP隠し）がそのまま無くなります
HTTPS証明書を自前で持っていないと、証明書エラーになる。オン時はCloudflareの証明書で見えていたものが、オフにするとブラウザはあなたのサーバーへ直接つなぐため、サーバー自身に正しい証明書が無いと警告が出ます

そして切り替え自体も一瞬では終わりません。やっているのは結局「Aレコードが返すIPを、自分のIP ↔ CloudflareのIP で差し替える」操作なので、2章のキャッシュの話がそのまま効きます。ただしプロキシ中のレコードはTTLを自分で設定できず Auto（ごく短い値）に固定されるので、切り替えは比較的すぐ反映されることが多いです。

なお、ルートドメイン（example.com そのもの）はDNSの仕様上CNAMEを置けません。それでもCloudflareでは「ルートをVercelなどに向ける」設定ができますが、これは裏で CNAMEフラットニング（CNAME flattening） という仕組みが働き、CNAMEの指す先を解決して、その結果をその場でAレコードとして返しているからでした。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up