3-2. DNS - ドメインを VPS に向ける、と「インターネットの電話帳」の仕組み

所要時間: 40-60分 ゴール: ドメインを購入し、VPS の IP にレコードを向け、dig でデバッグできる コミット内容: ~/learn/infra/dns/ に dig 実行ログと、設定したレコード一覧を記録

このレッスンのゴール

DNS 解決の旅路（ルート→TLD→権威）を3行で説明できる
A / AAAA / CNAME / MX / TXT / NS レコードの役割を即答できる
TTL を意識した本番切替（事前短縮 → 切替 → 戻し）ができる
dig を使って3段階の切り分けデバッグができる
CNAME の制限（apex不可、他レコード併存不可）を知っている

なぜ学ぶか（実務悩みベース）

「ドメインを VPS に向ける」が止まらず10分で終わる
障害時に「DNS かな？」を即座に切り分けられる
メール送信が迷惑判定される DKIM / SPF / DMARC を設定できる
HTTPS 証明書の DNS-01 認証で詰まらない

前章とのつながり

3-1 で立てた VPS には IP アドレスしかない。それを 人間が覚えられる名前 で呼べるようにするのが DNS の役割。次の 3-3 でドメイン名を使って証明書を取るので、DNS が前提になる。

大前提: DNS が壊れると「インターネットが死ぬ」

「example.com にアクセスすると IP 203.0.113.42 のサーバーが返事をする」のは、間に DNS という巨大な分散システムが立っているおかげ。DNS は人間に見えないが、Web を動かしている。

バックエンドエンジニアにとって DNS は要所で必ず触る:

新しいサーバーにドメインを向ける（このレッスンの主題）
メール送信のために MX / SPF / DKIM / DMARC を設定する
HTTPS 証明書の DNS-01 認証
CDN（Cloudflare 等）の前段化
マルチリージョン構成での DNS ベース負荷分散
障害発生時の 「DNS かな？」 判断（DNS の不調はかなり多い）

そして DNS は 「設定したらすぐ反映」ではない。TTL（キャッシュ時間）の概念を知らずに本番ドメインを変更すると、ユーザーの半分が新サーバーへ、半分が旧サーバーへ という分裂状態が数時間続く。これを避けるための運用知識を身につける。

セッション①: DNS の仕組み（20-25分）

1. 「example.com → 203.0.113.42」の旅路

ブラウザに example.com と打った瞬間、裏で起きていること:

[ブラウザ]
   ↓ example.com の IP 教えて
[OS のリゾルバ（DNS クライアント）]
   ↓ キャッシュにある？ → 無ければ問い合わせ
[ISP / Cloudflare 1.1.1.1 / Google 8.8.8.8 などのキャッシュリゾルバ]
   ↓ キャッシュなければ「再帰問い合わせ」を開始
[ルート DNS サーバー（. ドット）]
   → 「.com のことは .com のサーバーに聞いて」
[.com の権威 DNS サーバー]
   → 「example.com のことは ns1.example.com に聞いて」
[example.com の権威 DNS サーバー]
   → 「example.com の A レコードは 203.0.113.42 です」
   ↑ ここまで来てやっと IP が分かる
[キャッシュリゾルバ]
   ↓ TTL 秒間キャッシュしつつ、OS に返す
[OS] → [ブラウザ] → HTTP 接続開始

再帰問い合わせ (recursive query) と反復問い合わせ (iterative query)

上の図の「キャッシュリゾルバ」が、根気よく問い合わせを繰り返してくれる。これを 再帰問い合わせ と呼ぶ。クライアント側（ブラウザ・OS）は「教えてください」と一度だけ聞けばよい。

一方、キャッシュリゾルバから上流の権威 DNS への問い合わせは 反復問い合わせ。「自分が知ってる範囲で答える、知らなければ次に聞くべきサーバーを教える」というルール。

権威 DNS (authoritative DNS): 特定ドメインの「正解」を持っているサーバー。example.com の権威 DNS は、example.com のレコードについて最終回答できる唯一の場所。 キャッシュ DNS (recursive DNS resolver): 自分は正解を持たないが、再帰問い合わせを代行してキャッシュする。1.1.1.1 や 8.8.8.8 はこちら。

ゾーン委任 (zone delegation) とは

DNS は階層構造。. （ルート）の下に .com .jp .org、その下に example.com google.com、さらに下に www.example.com mail.example.com。

各階層で 「ここから下は別のサーバーが管理してます」 という委任が行われる。これがゾーン委任。

具体的には NS レコードで委任先を指定する:

.com ゾーンに「example.com NS ns1.example.com」と書いてある

→ example.com の問い合わせは ns1.example.com に行く

→ ns1.example.com が example.com の全レコードを持っている

委任の意味: ドメインを買って Cloudflare に NS を向けたら、example.com の管理権限が Cloudflare の DNS に「委任」される。お名前.com 側にレコードを書いても効かない。

2. レコードタイプ早見表

タイプ	用途	例
A	ホスト名 → IPv4	`www.example.com A 203.0.113.42`
AAAA	ホスト名 → IPv6	`www.example.com AAAA 2001:db8::1`
CNAME	ホスト名 → 別のホスト名	`blog.example.com CNAME example.netlify.app`
MX	メール受信先	`example.com MX 10 mail.example.com`
TXT	任意テキスト（SPF, DKIM, ドメイン所有確認）	`example.com TXT "v=spf1 -all"`
NS	このゾーンの権威 DNS	`example.com NS ns1.example.com`
SOA	ゾーンの管理情報	`example.com SOA ns1.example.com admin.example.com ...`
CAA	証明書発行を許可する CA	`example.com CAA 0 issue "letsencrypt.org"`
SRV	サービスのエンドポイント	`_sip._tcp.example.com SRV 10 60 5060 sipserver.example.com`
PTR	IP → ホスト名（逆引き）	`42.113.0.203.in-addr.arpa PTR mail.example.com`

A vs AAAA

A: IPv4 アドレスへ。今でも 8 割以上のサービスはこれだけで動く

AAAA: IPv6 アドレスへ。モバイル回線では IPv6 が広く使われており、未対応だと遅延が出ることも

両方設定するのが現代の作法。VPS が IPv6 アドレスをくれる時代、AAAA を書かないのは機会損失。

CNAME の本質と落とし穴
CNAME = Canonical Name。「このホスト名は実は別の名前のエイリアスです」を意味する。
www.example.com CNAME example.com
blog.example.com CNAME myapp.herokuapp.com
CNAME の特殊ルール:

同じホスト名に CNAME と他のレコード（A, MX, TXT）を併存できない（RFC 規定）

apex（ゾーン頂点、example.com そのもの）に CNAME は張れない。MX や NS が必須なため

apex に CNAME を張りたい時の代替: Cloudflare の “CNAME flattening”、Route 53 の “Alias レコード” など、プロバイダ独自機能を使う。

CNAME チェーンの落とし穴
a.example.com CNAME b.example.com
b.example.com CNAME c.example.com
c.example.com CNAME d.example.com
d.example.com A 203.0.113.42
こういうチェーンを作ると、各段で DNS 問い合わせが追加発生してレイテンシが増える。

多くのリゾルバは深さ制限を持っており、5 段以上のチェーンは解決失敗する場合がある。実装依存。

対策: 中間ホストを省いて直接 A レコードを向けるか、CDN プロバイダの flattening 機能を使う。

MX レコードと優先度
example.com MX 10 mail1.example.com
example.com MX 20 mail2.example.com
数値が 小さいほど優先（10 が優先、20 はバックアップ）。

メール受信を Google Workspace に委任する例:
example.com MX 1  ASPMX.L.GOOGLE.COM
example.com MX 5  ALT1.ASPMX.L.GOOGLE.COM
example.com MX 5  ALT2.ASPMX.L.GOOGLE.COM
example.com MX 10 ALT3.ASPMX.L.GOOGLE.COM
example.com MX 10 ALT4.ASPMX.L.GOOGLE.COM

TXT レコードの実務用途

任意の文字列を入れられるレコード。用途は4つ覚えればOK:

SPF: メール送信元 IP の許可リスト。v=spf1 ip4:203.0.113.42 ~all

DKIM: メールに付ける署名の公開鍵。v=DKIM1; k=rsa; p=MIGfMA0G...

DMARC: SPF/DKIM 不通過時のポリシー。v=DMARC1; p=reject; rua=mailto:dmarc@example.com

ドメイン所有権確認: Google Search Console / GitHub Pages などのサービスが「このドメインあなたのものですか」を確認するためのトークン。google-site-verification=xxxxx

3. TTL（Time To Live）と運用

www.example.com.    300    IN    A    203.0.113.42
                   ^^^
                   TTL（秒）

TTL の意味

リゾルバがこのレコードをキャッシュしておく秒数。

300 (5分): 変更がすぐ反映する。検証中・移行中に推奨

3600 (1時間): 一般的なデフォルト

86400 (24時間): 安定運用、問い合わせ負荷低減

トレードオフ: 短い TTL = 反映が早いが、リゾルバが頻繁に問い合わせるため権威サーバーの負荷が上がる。

TTL 86400 のまま緊急レコード変更する事故

本番障害でサーバーを切り替えたい、と思ってレコードを書き換えても、世界中のリゾルバが旧レコードを最大 24 時間キャッシュしている。一部ユーザーは新サーバー、一部ユーザーは旧サーバーを参照する分裂状態に。

正しい運用順序:

切替の数日前 に TTL を 300 などに短くする

その変更自体がキャッシュ経由で世界に行き渡るのを待つ（前の TTL ぶん）

本番切替: A レコードを新 IP に変更

移行完了後、TTL を 3600 / 86400 に戻す

これを「TTL を下げる」「下ろす」と呼ぶ。メンテナンス時の鉄則。

negative TTL（DNS 不在キャッシュ）

「このレコードは存在しない（NXDOMAIN）」という回答もキャッシュされる。これを negative TTL と呼ぶ。

新しいサブドメインを足した直後にアクセスすると 「存在しない」とキャッシュされて1時間つながらない事故がある。これは SOA レコードの最小 TTL に依存。

対策: ドメイン取得直後・新サブドメイン追加直後は 手元の dig ですぐ確認 → ローカル DNS キャッシュをクリア → ブラウザで確認 を急がない。

セッション②: dig で DNS をデバッグする（20-25分）

4. dig コマンドの基本

# A レコードを問い合わせ
dig example.com
 
# 短い出力（IP だけ欲しい時）
dig +short example.com
 
# 特定タイプ
dig example.com MX
dig example.com TXT
dig example.com NS
dig example.com AAAA
 
# 特定の DNS サーバーに直接問い合わせ
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com
 
# 権威 DNS に直接問う（キャッシュ無視で「真の値」）
dig @ns1.example.com example.com
 
# 再帰問い合わせの全段階を見る（劇的に役立つ）
dig +trace example.com

dig の出力の読み方
;; QUESTION SECTION:
;example.com.                  IN      A
 
;; ANSWER SECTION:
example.com.            300     IN      A       203.0.113.42
 
;; AUTHORITY SECTION:
example.com.            86400   IN      NS      ns1.example.com.
 
;; ADDITIONAL SECTION:
ns1.example.com.        86400   IN      A       192.0.2.1
 
;; Query time: 23 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
QUESTION: 何を聞いたか

ANSWER: 答え。ここに TTL も表示される

AUTHORITY: このゾーンを誰が管理しているか（NS レコード）

ADDITIONAL: ついでに送られてくる関連情報（NS の A レコードなど）

Query time: 応答までの時間。100ms 超えてたら遅い

+short は本当に便利
dig +short example.com
# 203.0.113.42
パイプで使いやすい。シェルスクリプトで「ドメインの IP を取得して比較」みたいな処理に最適。
# 例: 設定した IP と DNS が一致しているか確認
EXPECTED="203.0.113.42"
ACTUAL=$(dig +short example.com)
if [ "$EXPECTED" = "$ACTUAL" ]; then echo OK; else echo NG; fi

+trace の出力（抜粋）
dig +trace example.com
.                       <ルート DNS の応答>
com.    172800 IN NS a.gtld-servers.net.   <- .com のサーバー
...
 
example.com.    172800 IN NS ns1.example.com.   <- example.com の権威 DNS
...
 
example.com.    300 IN A 203.0.113.42   <- 最終回答
再帰問い合わせの各段階を全部見せてくれる。「どこで詰まっているか」が一目瞭然。DNS 移管トラブル調査の最強コマンド。

nslookup と dig の比較

古い記事には nslookup がよく出てくるが、dig を覚える方が良い。

項目 nslookup dig
出力情報量少ない多い（TTL、応答時間、各セクション）
スクリプト適性 △ ◎（+short でパイプ向き）
標準性廃止予定 BIND 標準、現役
macOS デフォルト入っている入っている

host コマンドもあるが、dig の上位互換ではないので「短く一発」用途のみ。実務では dig 一本でよい。

項目	nslookup	dig
出力情報量	少ない	多い（TTL、応答時間、各セクション）
スクリプト適性	△	◎（`+short` でパイプ向き）
標準性	廃止予定	BIND 標準、現役
macOS デフォルト	入っている	入っている

5. ローカル DNS キャッシュを意識する

# macOS のキャッシュクリア
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
 
# Linux (systemd-resolved の場合)
sudo systemd-resolve --flush-caches
# または
sudo resolvectl flush-caches
 
# Linux (nscd の場合)
sudo systemctl restart nscd

ブラウザ独自の DNS キャッシュ
Chrome は OS とは別に独自の DNS キャッシュを持っている。「dig では新 IP が見えるのに、Chrome では古いまま」の時は:
chrome://net-internals/#dns
から「Clear host cache」を実行する。

「DNS が反映しない！」と騒ぐ前に
「30 分経つのに反映しない」の 9 割は次のどれか:

手元のローカルキャッシュ（OS or ブラウザ）が古い → 上記コマンドでクリア

権威 DNS にはまだ反映していない（プロバイダ側の伝播に時間がかかる）

dig @<権威DNS> example.com で直接確認

キャッシュリゾルバ（1.1.1.1 / 8.8.8.8 等）が旧 TTL の間キャッシュ中

旧 TTL ぶんは仕様上避けられない

設定したつもりが「下書き保存」のままで公開されていない（プロバイダ管理画面の罠）

デバッグ手順:
dig @ns1.example.com example.com       # 権威に直接 → ここで新 IP が見えなければ設定漏れ
dig @1.1.1.1 example.com               # 第三者キャッシュ → 旧 IP なら TTL 待ち
dig example.com                         # 手元 → ローカルキャッシュなら flush

セッション③: ドメイン購入から VPS 接続まで（20-25分）

6. ドメインを買う

主要レジストラ:

レジストラ	強み	注意点
お名前.com	国内最大手、最初は安い	更新時に大幅値上げ、メールがしつこい
ムームードメイン	国内、料金安定	機能はベーシック
Cloudflare Registrar	卸値で更新もそのまま、現代的	一部 TLD のみ、米国法準拠
Google Domains / Squarespace Domains	UI 良し	一時期 Google Domains は閉鎖されて移管必要
Route 53	AWS と統合、API 完備	月数百円かかる

2026 年現在のおすすめ

学習用ならどこでもよい。長期運用なら Cloudflare Registrar が事実上の最適解（卸値固定、UI 良し、DNS も同じ画面で管理）。

一方で .jp ドメインを買いたい場合は Cloudflare 非対応なので、国内レジストラを使う。

WHOIS 情報公開

ドメインを取得すると、登録者の氏名・住所・電話番号が WHOIS DB に公開される。

各レジストラは「Whois 代理公開」「Privacy Protection」サービスを提供（多くは無料）。個人で取得する時は必ず有効化。本名と自宅住所が世界中の bot に見える状態は危険。

一部 TLD（.jp 等）は代理公開を許可していないため、組織情報を入れる必要がある。個人事業主は屋号で対応。

7. ネームサーバーを切り替える

ドメイン購入時点では、レジストラのデフォルト DNS が設定されている。多くの実務では:

ドメインをお名前.com で買う
ネームサーバーを Cloudflare のものに変更
DNS レコード管理は Cloudflare の画面で行う

という構成にする。

[お名前.com（レジストラ）]
   ↓ NS レコードを Cloudflare へ
[Cloudflare（DNS ホスティング）]
   ↓ A / MX / TXT 等を管理
[各種サービス]

なぜ Cloudflare 経由にするか

DNS API が無料で使える（cert-manager, Terraform 連携）

管理画面が秒で反映（一部レジストラの DNS 管理画面は変更に数分かかる）

DDoS 緩和 / WAF / CDN を後から有効化できる（オレンジクラウドアイコン）

DNS query 計測が無料で見られる

DNSSEC をワンクリックで有効化

Cloudflare へのネームサーバー切替手順

Cloudflare に登録、ドメインを追加

Cloudflare が既存の DNS レコードを自動インポート

Cloudflare が割り当てる NS（例: aria.ns.cloudflare.com, kirk.ns.cloudflare.com）を控える

レジストラ（お名前.com 等）の管理画面で NS をその 2 つに変更

反映待ち（数分〜数時間、長くて24時間）

Cloudflare 側で “Status: Active” になれば完了

8. VPS にドメインを向ける

# Cloudflare の DNS 画面で追加するレコード
example.com           A      203.0.113.42    TTL: Auto (Cloudflare 任せ) or 300
www.example.com       A      203.0.113.42
# または
www.example.com       CNAME  example.com

# 設定後、すぐ確認
dig +short example.com
dig +short www.example.com

「apex (example.com) と www の両方を向ける」が標準

apex (example.com): A レコードで IP を直接指定

www.example.com: CNAME で example.com を指す（または A レコードで同じ IP）

ユーザーが example.com でも www.example.com でもアクセスできる状態を作るのが現代の作法。Web サーバー側で www. 付きを www. なしへリダイレクトする（または逆）構成は次の HTTPS の章で扱う。

Cloudflare の「プロキシ」アイコン

Cloudflare の DNS 画面で、各レコードに「オレンジ雲（Proxied）」「グレー雲（DNS only）」のトグルがある。

Proxied (オレンジ): Cloudflare が間に立つ。CDN, DDoS 防御, WAF が有効。ただし HTTPS 証明書は Cloudflare のものになり、自前 SSH も Cloudflare 経由になる

DNS only (グレー): 単なる DNS リレー。サーバー IP が直接見える

初期は グレー雲（DNS only） で進めると素直。Let’s Encrypt 取得・SSH も自分の VPS に直接届く。Cloudflare の機能を後から有効化したくなったらオレンジにする。

DNS プロパゲーションの真実

ググると「DNS は反映まで 24-48 時間かかる」とよく書いてあるが、現代では大半が数分以内に終わる。

24-48 時間は最悪ケース（TTL 86400 の旧設定がリゾルバにキャッシュされている場合）。新規ドメインのレコード追加なら数秒。

「2 日待たないと反映しない」と信じて待ち続けるのは時間の無駄。dig @<権威DNS> で 権威に答えが入っている ことを確認したら、あとは TTL の問題でしかない。

アンチパターン総まとめ

TTL 86400 のまま緊急変更

障害発生 → 急いで別 IP にレコード変更 → 半数のユーザーが依然として旧サーバーへ → 半日経っても完全切替されない。TTL は事前に下げる。

CNAME を apex に張ろうとする
example.com CNAME mywebsite.netlify.app    # NG（RFC 違反）
プロバイダ側でエラーが出るか、ALIAS / CNAME flattening の独自対応が必要。素直に A レコードで直接 IP を向けるか、www. を使う。

CNAME チェーンを作る
a CNAME b
b CNAME c
c CNAME d
d A 1.2.3.4
リゾルバの実装次第で解決失敗、解決できてもレイテンシ増。中間ホストを省く。

同じホスト名に CNAME と他レコード併存

mail.example.com CNAME other.example.com    # NG
mail.example.com MX    10 mailhost...        # NG（CNAME と併存不可）

DNS 反映していないのに証明書取得を連打

certbot を DNS 未反映で実行 → 失敗 → 連打 → Let’s Encrypt の rate limit に引っかかる（同一ドメイン週 5 回まで）。dig で名前解決を確認してから証明書取得。

削除すべき古いレコードを残す

過去のサービスで使った A レコードをそのまま放置 → 別人が同じ IP の VPS を借りる → そのサーバー上にあなたのドメインの A レコードが向き続けている = サブドメインテイクオーバー攻撃の温床。使わないレコードは消す。

実例: ドメインを VPS に向ける一連の流れ

# 1. ドメインを購入（お名前.com or Cloudflare Registrar 等）
#    例: example.com を取得
 
# 2. Cloudflare にドメイン追加、表示された 2 つの NS を控える
#    aria.ns.cloudflare.com
#    kirk.ns.cloudflare.com
 
# 3. レジストラ管理画面で NS を上記に変更
 
# 4. 数分待ち、NS が切り替わったか確認
dig +short NS example.com
# → aria.ns.cloudflare.com.
# → kirk.ns.cloudflare.com.
 
# 5. Cloudflare 画面で A レコード追加
#    Type: A, Name: @, Content: 203.0.113.42, TTL: Auto, Proxy: DNS only
#    Type: CNAME, Name: www, Content: example.com, TTL: Auto, Proxy: DNS only
 
# 6. 名前解決を確認
dig +short example.com
# 203.0.113.42
dig +short www.example.com
# example.com.
# 203.0.113.42
 
# 7. ブラウザで http://example.com にアクセスしてみる
#    (まだ HTTPS じゃないので nginx の welcome ページが出るはず)
#    HTTPS 化は次のレッスン

セキュリティ: CAA レコードと DNSSEC

CAA レコード

example.com CAA 0 issue "letsencrypt.org"
example.com CAA 0 issuewild "letsencrypt.org"
example.com CAA 0 iodef "mailto:security@example.com"

CAA とは何か

CAA (Certification Authority Authorization) = 「このドメインの証明書は、どの認証局（CA）が発行してよいか」を DNS で宣言する仕組み。

上の例なら「Let’s Encrypt 以外の CA は example.com の証明書を発行するな」と宣言している。

狙い: 攻撃者が別の CA で不正に証明書を発行する攻撃（過去に Symantec で実例あり）を防ぐ。CA は発行前に CAA を確認することが規程で義務付けられている。

設定なしでも特に問題ないが、ある方が一段堅い。Let’s Encrypt 運用なら 1 行入れておく価値がある。

DNSSEC

DNSSEC とは

DNS の応答に署名を付け、改竄を検出可能にする拡張。

狙い: DNS キャッシュポイズニング（攻撃者が偽の応答を注入する）を防ぐ。

現実: 全 DNS の数十パーセントしか有効化されていない。一般 Web 用途では HTTPS が同等の保証を提供しているため、優先度は低め。

設定: Cloudflare なら DNSSEC タブからワンクリック有効化。ただし レジストラ側にも DS レコードを登録する必要あり。両方やらないと無効。

練習課題

学習用ドメインを 1 つ取得する（年 1,000-2,000 円）
NS を Cloudflare（または好きな DNS ホスティング）に切り替える
apex と www に A レコードを設定し、前回立てた VPS の IP を向ける
dig +short example.com で正しい IP が返ることを確認
dig +trace example.com を実行して、ルート → TLD → 権威の各段階を眺める
TTL を 300 に変更してみて、dig の出力でカウントダウンを確認（短い時間で再問い合わせ）
CAA レコードを 1 行追加してみる
試しに存在しないサブドメイン dig nonexistent.example.com の応答を観察（status: NXDOMAIN）

締め: git で証跡を残す

cd ~/learn/infra/dns
# DNS レコード一覧を Markdown で記録
cat > records.md <<EOF
# example.com の DNS レコード（2026-05-14 時点）
 
| Type | Name | Content | TTL |
|---|---|---|---|
| A | @ | 203.0.113.42 | Auto |
| CNAME | www | example.com | Auto |
| CAA | @ | 0 issue "letsencrypt.org" | Auto |
EOF
 
# dig の出力も保存
dig example.com > dig_example.log
dig +trace example.com > dig_trace.log
 
git add .
git commit -m "feat(dns): example.com のレコード初期設定と dig 検証ログ"

チェックリスト

ドメインを取得した
NS を DNS ホスティング（Cloudflare 等）に切り替えた
A レコードで VPS の IP を向けた
dig +short で名前解決を確認した
dig +trace で再帰問い合わせの全段階を観察した
TTL の意味と、変更時の運用順序を説明できる
CNAME の制限（apex に張れない、他レコードと併存不可）を覚えた
CAA レコードの目的を説明できる
「DNS が反映しない」時の切り分け 3 ステップが分かる

詰まった時のチートシート

やりたいこと	コマンド
A レコード問い合わせ	`dig example.com`
値だけ取得	`dig +short example.com`
MX レコード	`dig example.com MX`
TXT レコード	`dig example.com TXT`
NS レコード	`dig example.com NS`
全段階を表示	`dig +trace example.com`
特定の DNS に直接	`dig @1.1.1.1 example.com`
権威に直接	`dig @ns1.example.com example.com`
macOS キャッシュクリア	`sudo dscacheutil -flushcache`
Linux キャッシュクリア	`sudo resolvectl flush-caches`
逆引き	`dig -x 203.0.113.42`

対比表: 主要レコード型

レコード	役割	例	注意
A	IPv4 を指す	`example.com → 203.0.113.42`	基本中の基本
AAAA	IPv6 を指す	`example.com → 2001:db8::1`	IPv6 対応で必要
CNAME	別名	`www → example.com`	apex 不可、他レコード併存不可
MX	メール送信先	`example.com → mail.ex.com (10)`	優先度数値が小さい程優先
TXT	任意テキスト	SPF / DKIM / DMARC	1ドメインに複数可
NS	権威 DNS サーバー	`example.com → ns1.cf.com`	ドメイン購入時に登録
CAA	証明書発行許可	`example.com → letsencrypt.org`	不正発行防止

「実務OK」基準

dig +short と dig +trace を使い分けられる
TTL を変更してから本番切替する運用順序を覚えている
CNAME の制限（apex 不可、他レコード併存不可）を即答できる
「DNS が反映しない」時に切り分けの 3 ステップを実行できる
MX レコードの優先度を読める / 設定できる
SPF / DKIM / DMARC が TXT レコードで実現されていると知っている

自己評価チェックリスト

知識レベル

DNS 解決の旅路（ルート→TLD→権威）を3行で説明できる
CNAME と A の使い分け基準を即答できる
TTL とキャッシュの関係を腹落ちした

実行レベル

ドメインを買って NS を移譲した
A レコードを VPS の IP に向けた
dig +trace で権威サーバーまで追跡した

メタ認知

「DNS が原因かも」の切り分け手順を3ステップでメモした
自分のドメインの SPF / DMARC が設定済みか確認した

さらに深掘りするなら

公式: RFC 1034 / 1035 (DNS の原典)
公式: Cloudflare Learning Center “What is DNS?”
書籍: 『Pro DNS and BIND 10』（重厚だが正典）
ツール: dnsviz.net - DNSSEC を含む全段階を可視化
ツール: intodns.com - 一発で多角的に DNS をチェック

次のレッスン

3-3_HTTPS化.md で、設定したドメインに Let’s Encrypt の HTTPS 証明書を入れる手順へ。

バックエンドマスター

エクスプローラー

3-2_DNS

3-2. DNS - ドメインを VPS に向ける、と「インターネットの電話帳」の仕組み

このレッスンのゴール

なぜ学ぶか（実務悩みベース）

前章とのつながり

大前提: DNS が壊れると「インターネットが死ぬ」

セッション①: DNS の仕組み（20-25分）

1. 「example.com → 203.0.113.42」の旅路

2. レコードタイプ早見表

3. TTL（Time To Live）と運用

セッション②: dig で DNS をデバッグする（20-25分）

4. dig コマンドの基本

5. ローカル DNS キャッシュを意識する

セッション③: ドメイン購入から VPS 接続まで（20-25分）

6. ドメインを買う

7. ネームサーバーを切り替える

8. VPS にドメインを向ける

アンチパターン総まとめ

実例: ドメインを VPS に向ける一連の流れ

セキュリティ: CAA レコードと DNSSEC

CAA レコード

DNSSEC

練習課題

締め: git で証跡を残す

チェックリスト

詰まった時のチートシート

対比表: 主要レコード型

「実務OK」基準

自己評価チェックリスト

知識レベル

実行レベル

メタ認知

さらに深掘りするなら

次のレッスン

グラフビュー

目次

バックリンク