DNS は「インターネットの電話帳」
ブラウザに https://example.com と入れると、あなたの PC は「example.com って実際どの IP アドレスにあるの？」を調べないと通信できません。この「ドメイン名 → IP アドレス」の変換を担うのが DNS（Domain Name System）です。
この記事では、URL を入れてから IP アドレスが返ってくるまでの流れと、よく出てくる用語（権威サーバー、フルリゾルバ、TTL、A/AAAA/MX 等）を整理します。
名前解決の主役: 4 種類のサーバー
DNS の世界には役割の違うサーバーが4種類あります。
- スタブリゾルバ: あなたの OS / ブラウザに組み込まれた小さなクライアント。実際の問い合わせはフルリゾルバに丸投げする
- フルリゾルバ（キャッシュサーバー）: 複数の権威サーバーを辿って最終回答を取りに行く。ISP、Google Public DNS（
8.8.8.8）、Cloudflare（1.1.1.1）等 - 権威 DNS サーバー: あるドメインの「公式回答」を持つ。Route 53、Cloudflare DNS、ConoHa DNS 等
- ルート DNS サーバー: ドメイン名階層の頂点。
.comや.jp等の TLD（Top Level Domain）の場所を教える
名前解決の流れ（フルリゾルバの旅）
www.example.com を引く場合の典型的な流れ：
1. PC「www.example.com の IP は？」 → フルリゾルバ
2. フルリゾルバ→ ルート「.com を担当する権威サーバーは？」
3. ルート → ".com の権威は a.gtld-servers.net …"
4. フルリゾルバ → .com 権威「example.com の権威は？」
5. .com 権威 → "example.com の権威は ns1.example.com"
6. フルリゾルバ → example.com 権威「www.example.com の A は？」
7. example.com 権威 → "93.184.215.14"
8. フルリゾルバ → PC「93.184.215.14 だよ」実際にはフルリゾルバが結果を キャッシュ するので、毎回これだけのやり取りが発生するわけではありません。同じドメインへの 2 回目以降は数ミリ秒で返ります。
TTL: キャッシュの有効期限
各 DNS レコードには TTL（Time To Live）が秒単位で設定されています。フルリゾルバや OS はこの時間だけ結果をキャッシュし、過ぎたら再問い合わせします。
- TTL を長くする（例: 86400 秒 = 1 日）: クエリ数が減りパフォーマンス◎ / 障害復旧時のフェイルオーバーが遅い
- TTL を短くする（例: 60 秒〜300 秒）: 切替が早い / クエリ負荷増
本番運用ではドメインの引っ越し直前に TTL を短くしておき、移行後に長く戻す、という運用が一般的です。
代表的なレコードタイプ
| タイプ | 用途 | 例 |
|---|---|---|
| A | ドメイン → IPv4 アドレス | example.com → 93.184.215.14 |
| AAAA | ドメイン → IPv6 アドレス | example.com → 2606:2800:21f:cb07:6820:80da:af6b:8b2c |
| CNAME | 別名（実際の名前を指す） | www.example.com → example.com |
| MX | メールサーバーの場所 | example.com の MX → mail.example.com (priority 10) |
| TXT | 任意の文字列（SPF / DKIM / 検証用） | v=spf1 include:_spf.google.com ~all |
| NS | そのドメインの権威 DNS サーバー | example.com の NS → ns1.example.com |
| SOA | ゾーンの基本情報 | シリアル番号、TTL、責任者メールアドレス |
| PTR | 逆引き（IP → ドメイン） | 93.184.215.14 → example.com |
| CAA | 証明書発行の許可制御 | 0 issue "letsencrypt.org" |
セキュリティ視点での DNS
DNS スプーフィング / キャッシュポイズニング
フルリゾルバのキャッシュに偽の回答を仕込まれると、ユーザーは正しいドメイン名を打っても偽サイトへ誘導されます。これに対抗する仕組みが DNSSEC（電子署名で回答の正当性を検証）ですが、対応している権威サーバー・フルリゾルバ両方で初めて有効です。
DNS over HTTPS / DNS over TLS
従来の DNS は平文 UDP で流れるため、ISP や中間者にクエリ内容が筒抜けでした。これを暗号化するのが DoH（DNS over HTTPS）と DoT（DNS over TLS）です。Firefox や Chrome は DoH をデフォルトで使う方向に動いています。
権威 DNS の乗っ取り
ドメインのレジストラ・権威 DNS の管理アカウントが侵害されると、攻撃者は任意の IP を A レコードに設定できます。レジストラのアカウントは特に強固に守る（ハードウェアキー必須等）べき領域です。
困ったときに使うコマンド
DNS のトラブルシュートで頻出するコマンド：
dig example.com A: A レコードを直接問い合わせ（Linux/macOS 標準）dig example.com MX +short: MX のみ簡易表示dig @8.8.8.8 example.com: 特定の DNS サーバーに問い合わせnslookup example.com: Windows 標準host example.com: 簡易版
「ブラウザでは見えるが API 経由だとつながらない」のようなトラブル時、まず dig で名前解決の段階で問題があるかを確認すると切り分けが進みます。
おわりに
DNS は普段は意識しませんが、「サイトがつながらない」障害の4 割は DNS が原因と言われるくらい、ハマると厄介な領域です。フルリゾルバ・権威・キャッシュ・TTL の関係を一度きちんと押さえておくと、後で必ず役に立ちます。