DNS とは — 名前解決の仕組みとレコード種別 のサムネイル

DNS とは — 名前解決の仕組みとレコード種別

⏱ 約 17 分 view 84 like 0 LOG_DATE:2026-05-09
目次 / TOC

Domain Name System (DNS) #

Domain Name System (DNS) は、人間が覚えやすい ドメイン名 (例 www.example.com) を、コンピュータが通信に使う IP アドレス (例 93.184.216.34) に変換するための、インターネットの根幹を支える分散データベースおよびプロトコルである。Web、メール、API 通信、CDN、SaaS など、現代のあらゆるネット利用は DNS の解決を経ている。デフォルトでは UDP/TCP のポート 53 番を使用する (近年の暗号化 DNS では 853 / 443 / 443-QUIC)。

1. DNS の歴史 #

1.1 HOSTS.TXT 時代の限界 #

ARPANET 初期、ホスト名と IP アドレスの対応は HOSTS.TXT という単一の中央管理ファイルで管理されていた。SRI-NIC (Stanford Research Institute Network Information Center) がマスターを保管し、各ホストはそれを定期的にダウンロードしていた。

しかし、ホスト数が数千を超えるとこの方式は破綻する:

  • 中央管理者がボトルネック化 (更新申請が滞る)
  • ファイル配布のトラフィック増加
  • 一貫性の担保が困難
  • ホスト名の重複問題

1.2 Paul Mockapetris による設計 (1983) #

1983 年、ポール・モカペトリス (Paul Mockapetris) が分散管理可能な名前解決システムとして DNS を設計し、RFC 882 / 883 として発表した。設計の鍵は次の 3 つ。

  1. 階層的名前空間 — ドメインを . 区切りの木構造として表現する
  2. 委譲 — 各サブツリーの管理を別の組織に委ねられる
  3. キャッシュ — 一度解決した結果を再利用して負荷を分散する

これによって組織ごとに自分のドメインを自由に運用でき、世界規模でスケールする仕組みが整った。

1.3 RFC 1034 / 1035 による標準化 (1987) #

1987 年に発行された RFC 1034 (概念とファシリティ) と RFC 1035 (実装と仕様) が DNS の現在の基礎となっている。30 年以上経った今もなお有効な仕様であり (拡張は数多く加わっているが、根本部分は変わっていない)、インターネットの中で最も長寿命な仕様の一つ。

1.4 BIND と運用の成熟 #

UC バークレーで開発された BIND (Berkeley Internet Name Domain) は、長らく DNS サーバー実装のデファクトスタンダードとなり、ほぼすべての主要な OS で採用された。後に NSD、Knot DNS、PowerDNS、Unbound といった代替実装が生まれ、現代では用途に応じて使い分けられる。

1.5 段階的な強化 #

その後、DNS は次のように強化されていく。

  • EDNS (RFC 6891, 1999) — UDP 512 バイト制限を拡張、DNSSEC や大きな応答に対応
  • DNSSEC (RFC 4033-4035, 2005) — 公開鍵暗号で応答の真正性を担保
  • DoT (DNS over TLS, RFC 7858, 2016) — TLS で暗号化
  • DoH (DNS over HTTPS, RFC 8484, 2018) — HTTPS で暗号化
  • DoQ (DNS over QUIC, RFC 9250, 2022) — QUIC で低遅延・暗号化

2. DNS の基本構造 #

2.1 階層的な木構造 #

DNS は逆木構造 (root が頂点) として表現される。4 層の階層と委譲 (delegation) の流れ、FQDN の組み立ては下の図のとおり。

DNS 階層構造 — 委譲 (delegation) によるグローバル管理 親ゾーンが NS レコードで子ゾーンの権威を指示する root layer 0 TLD layer 1 2nd-level layer 2 subdomain layer 3 . (root) ICANN / IANA NS 委譲 NS 委譲 com jp org Verisign JPRS PIR example co.jp ne.jp 企業/個人 (登録者) 企業 プロバイダ www mail api 委譲 (delegation) とは 親ゾーンが NS レコードで「ここから 先はあのサーバが権威」と示す仕組み。 これによって各組織が自分のゾーンを 独立に管理でき、世界規模で破綻しない。 FQDN (Fully Qualified Domain Name) は「.」区切りで右に向かって階層を上がる www subdomain . example 2nd-level . com TLD . root layer 0 階層を上がる 解決時に走査する向き root (黄) → TLD (青) → 2nd-level (緑) → subdomain (赤)、点線矢印 = NS 委譲 解決の走査は逆方向 — 右の root から始めて左の subdomain へ降りていく
  • 一番上の ルート (.) が起点
  • その下に トップレベルドメイン (TLD): com, org, jp, io など
  • さらにその下に セカンドレベル, サードレベル … と続く

2.2 ドメイン名の表記 #

www.example.com. のように . 区切りで表記する (右にあるラベルほど上位)。一番右の . (ルート) は省略されることが多いが、厳密には付ける。

  • ラベル (label): . で区切られた各部分。最大 63 オクテット。
  • FQDN (Fully Qualified Domain Name): ルートまで含めた完全形。例 www.example.com.
  • 名前全体は最大 253 オクテット。
  • 大文字小文字は区別されない (Example.COM = example.com)。

2.3 委譲モデル #

各組織は自分のゾーンの管理権限を委譲される。.com の管理は Verisign、.jp は JPRS、それぞれの傘下のドメイン (example.com, example.jp) はそのドメインの所有組織が管理する。

委譲は NS レコード によって表現される。「example.com の権威サーバーは ns1.example.com です」と上位ゾーン (com) が示すことで、解決時の参照先が決まる。

3. DNS の主要コンポーネント #

3.1 ルートサーバー #

ルートゾーン . を提供するサーバー群。世界に 13 系統 (a.root-servers.net 〜 m.root-servers.net) あり、各系統はさらに anycast で世界中に多数のインスタンスが配置されている (実体は 1000 台以上)。

ルートサーバーはルートゾーンを返すだけで、最終的な答えそのものは持たない。「.com の権威サーバーはここです」と次の参照先を返す役目。

3.2 TLD サーバー #

.com、.jp、.io などの TLD ゾーンを管理するサーバー。レジストリ (Verisign、JPRS、ICANN 認定の他事業者) が運用する。これも最終的な答えではなく、「そのドメインの権威サーバーはここです」と返す。

3.3 権威 DNS サーバー (Authoritative) #

特定のゾーン (例: example.com) のレコードを保持し、最終的な答えを返すサーバー。ドメイン所有者が自前で立てるか、外部 DNS ホスティング (Cloudflare、AWS Route 53、Google Cloud DNS、Akamai 等) に委ねるのが一般的。

3.4 リゾルバ (Resolver) #

ユーザー側で名前解決を行うコンポーネント。

  • スタブリゾルバ (Stub Resolver) — OS に組み込まれた軽量クライアント。常に上位のフルリゾルバに問い合わせる (getaddrinfo() 等の API 経由)。
  • フルリゾルバ / 再帰リゾルバ (Full / Recursive Resolver) — ルートから順に問い合わせて最終的な答えを取得し、結果をキャッシュする本格的な解決機能を持つ。ISP・社内・パブリック (8.8.8.8, 1.1.1.1, 9.9.9.9 など) が提供。

3.5 キャッシュ DNS サーバー / フォワーダ #

組織内に置かれ、社員のスタブリゾルバからの問い合わせを受ける。自分でキャッシュを持ち、ヒットしないものは外部のフルリゾルバに転送 (フォワード) する。社内ドメインの解決を内部に閉じる役割も担う。

4. 名前解決の仕組み #

4.1 完全な再帰解決の流れ #

www.example.com の A レコードを問い合わせる場合の典型的な流れ。アクター間の query / referral / answer の往復を下のシーケンス図で示す。

DNS 再帰解決のシーケンス — www.example.com の A レコードを問う 緑 = query, 青 (点線) = referral, 桃 = authoritative answer Client stub resolver Full Resolver 8.8.8.8 / 1.1.1.1 Root Server a.root-servers.net .com TLD a.gtld-servers.net Authoritative ns1.example.com 1 www.example.com の A? (RD=1) 2 www.example.com を教えて 3 referral: .com TLD は a.gtld-servers.net 4 www.example.com を教えて 5 referral: example.com の権威は ns1.example.com 6 www.example.com の A? 7 A: 93.184.216.34 (AA=1, 権威回答) 8 A: 93.184.216.34 ▲ CACHE 保存 example.com → 93.184.216.34 TTL の秒数だけ保持 凡例 query (再帰/反復問い合わせ) referral (次の参照先案内) authoritative answer (AA=1) CACHE

テキストでも書くと:

[1] クライアント → スタブリゾルバ:
    「www.example.com の A レコードは?」

[2] スタブリゾルバ → フルリゾルバ (例 8.8.8.8):
    「再帰解決お願い」 (RD=1)

[3] フルリゾルバ → ルートサーバー:
    「www.example.com を教えて」
    → ルート: 「.com の権威は a.gtld-servers.net など、ここに聞いて」 (referral)

[4] フルリゾルバ → .com TLD サーバー:
    「www.example.com を教えて」
    → TLD: 「example.com の権威は ns1.example.com など、ここに聞いて」 (referral)

[5] フルリゾルバ → example.com 権威サーバー:
    「www.example.com の A は?」
    → 権威: 「93.184.216.34」 (authoritative answer)

[6] フルリゾルバ → スタブリゾルバ → クライアント:
    「93.184.216.34」
    キャッシュにも保存 (TTL の間)

4.2 反復問い合わせ (Iterative) と再帰問い合わせ (Recursive) #

  • 再帰問い合わせ: クライアント → リゾルバ間。クライアントは最終回答だけを期待する。
  • 反復問い合わせ: リゾルバ → 各権威サーバー間。各権威は「次に聞くべき相手」を返すだけ。

公開リゾルバを開放しすぎる (open recursive) と DNS Amplification 攻撃に悪用されるため、外部から再帰問い合わせを受け付けない構成にすることが運用の鉄則。

4.3 キャッシュと TTL #

各レコードには TTL (Time To Live) が設定されており、リゾルバはこの秒数だけ結果をキャッシュできる。

  • 短い TTL (60-300 秒): フェイルオーバー・移行が早い反面、上位サーバーへの問い合わせが頻繁になる
  • 長い TTL (86400 秒 = 1 日): キャッシュ効率が高い反面、変更反映に時間がかかる

CDN や DDoS 保護サービスの A レコードは短く (60 秒等)、組織の MX や NS は長め (3600-86400 秒) にするのが一般的。

4.4 DNS メッセージの構造 #

DNS のクエリ/応答は同じフォーマットで、固定 12-byte ヘッダ + 可変長 4 セクション。

DNS メッセージ構造 (RFC 1035) — クエリ/応答共通 12-byte 固定 Header + 可変長 4 セクション Header (固定 12 bytes / 6 × 16-bit フィールド) ID 2 bytes offset 0 Flags (QR / OPCODE / AA / TC / RD / RA / Z / AD / CD / RCODE) 2 bytes ↓ 下で展開 offset 2 QDCOUNT (Question 数, 通常 1) 2 bytes offset 4 ANCOUNT (Answer RR 数) 2 bytes offset 6 NSCOUNT (Authority RR 数) 2 bytes offset 8 ARCOUNT (Additional RR 数) 2 bytes offset 10 Flags 16-bit の内訳 (RFC 1035 + RFC 4035 DNSSEC 拡張) bit 0 bit 15 QR 1 OPCODE 4 bits AA 1 TC 1 RD 1 RA 1 Z 1 AD 1 CD 1 RCODE 4 bits QR=0 query / =1 response AA=権威, TC=切詰, RD=再帰希望, RA=再帰可能 AD=DNSSEC 検証済 (RFC 4035), CD=検証スキップ 本体セクション (各 RR は可変長, セクションごとの個数は header の COUNT が指定) Question QNAME (例: www.example.com) / QTYPE (例: A) / QCLASS (IN) QDCOUNT 個 問い合わせ内容。クエリ・レスポンス両方に同じものが入る Answer RR (NAME / TYPE / CLASS / TTL / RDLENGTH / RDATA) ANCOUNT 個 A / AAAA / CNAME / MX / TXT などの実際の応答 Authority NS RR ほか — referral 時はここに次の参照先が入る NSCOUNT 個 フルリゾルバはこれを見て次の問い合わせ先を決める Additional 補助 RR — NS の Glue (A/AAAA), EDNS OPT 疑似 RR 等 ARCOUNT 個 EDNS OPT を使うと UDP 512 byte 制限を拡張できる

テキストでも書くと:

+---------------------+
|  Header (12 bytes)  |  ← ID, フラグ (QR, OPCODE, AA, TC, RD, RA, AD, CD), 各セクション数
+---------------------+
|  Question           |  ← 問い合わせ内容 (名前, タイプ, クラス)
+---------------------+
|  Answer             |  ← 回答 RR
+---------------------+
|  Authority          |  ← 権威 NS など
+---------------------+
|  Additional         |  ← 補助情報 (Glue レコード等)
+---------------------+

主要フラグ:

フラグ 意味
QR 0 = query, 1 = response
AA Authoritative Answer (権威回答)
TC Truncated (UDP 512 バイトを超えて切られた → TCP 再試行が必要)
RD Recursion Desired (再帰希望)
RA Recursion Available (再帰可能)
AD Authentic Data (DNSSEC で検証済み)
CD Checking Disabled (DNSSEC 検証スキップ依頼)

5. 主要なリソースレコード (RR) #

Type 用途
A ドメイン名 → IPv4 アドレス
AAAA ドメイン名 → IPv6 アドレス
CNAME エイリアス (www → apex.example.com)
NS このゾーンの権威 DNS サーバー
MX メール配送先サーバー (Priority + Hostname)
TXT 任意のテキスト。SPF / DKIM / DMARC / ACME challenge / 認証検証で大量に使われる
PTR IP → ドメイン名 (逆引き)。in-addr.arpa ゾーン
SOA Start of Authority。ゾーンの管理情報 (シリアル, refresh, retry, expire, minimum TTL)
SRV サービス位置情報 (_sip._tcp.example.com 等)
CAA 証明書発行できる CA を制限 (HTTPS 証明書発行ポリシー)
DNSKEY DNSSEC の公開鍵
RRSIG DNSSEC の署名
DS DNSSEC の Delegation Signer (上位ゾーンに置く子ゾーンの鍵情報)
HTTPS / SVCB HTTPS / 一般サービスバインディング (RFC 9460, 2023)

6. 主要コマンドと使用例 #

6.1 dig (Domain Information Groper) #

最も実用的・診断的な DNS クエリツール。BIND の付属。

# 基本: A レコード
dig example.com

# タイプ指定
dig example.com MX
dig example.com NS
dig example.com TXT
dig example.com AAAA
dig example.com ANY        # 一括 (権威によっては拒否される)

# 特定のリゾルバ・権威サーバーに問い合わせ
dig @8.8.8.8 example.com
dig @ns1.example.com example.com SOA

# 反復解決の全ステップを表示 (トレース)
dig +trace example.com

# 短い出力 (回答のみ)
dig +short example.com

# 逆引き
dig -x 93.184.216.34

# DNSSEC の RRSIG/DNSKEY も含める
dig example.com +dnssec

# DoT 経由 (kdig もしくは dig 9.18+)
kdig -d @1.1.1.1 +tls example.com

dig 出力の見方:

;; ANSWER SECTION:
example.com.        86400   IN  A   93.184.216.34

;; AUTHORITY SECTION:
example.com.        86400   IN  NS  a.iana-servers.net.
example.com.        86400   IN  NS  b.iana-servers.net.

;; Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

6.2 nslookup #

古典的な DNS クエリツール。Windows ではこれが既定。診断目的では dig の方が情報量は多い。

nslookup example.com
nslookup example.com 8.8.8.8
nslookup -type=MX example.com

6.3 host #

シンプルな簡易クエリ。

host example.com
host -t MX example.com
host -a example.com         # ANY 相当
host 93.184.216.34          # 逆引き

6.4 drill / kdig #

drill は NLnet Labs の DNS クエリツール、kdig は Knot DNS 付属。DoT/DoH 等のモダンな機能の確認に強い。

# DoT (DNS over TLS) 経由のクエリ
kdig -d @1.1.1.1 +tls example.com

# DoH (DNS over HTTPS) 経由のクエリ
kdig -d @1.1.1.1 +https example.com

6.5 whois #

直接 DNS のコマンドではないが、ドメイン登録情報・ネームサーバー設定を確認するために併用される。

whois example.com

7. DNS のセキュリティ拡張 #

平文 UDP/53 の DNS は、長らく改ざん・盗聴・偽応答の温床だった。これを段階的に補強していく拡張が以下。

7.1 DNSSEC (DNS Security Extensions) #

応答が本物の権威サーバーから来た改ざんされていないものであることを、公開鍵暗号で検証できるようにする仕組み。RFC 4033-4035 (2005)。

  • DNSKEY: ゾーンの公開鍵
  • RRSIG: 各 RR への署名
  • DS: 親ゾーンに置かれる子ゾーンの鍵フィンガープリント
  • NSEC / NSEC3: 「存在しない名前」の証明 (NXDOMAIN の改ざん防止)

検証の連鎖はルートゾーン → TLD → 権威ゾーンと上位から下位へ続く (Chain of Trust)。リゾルバで AD フラグが立てば検証成功。

DNSSEC は通信の暗号化はしない (中身は見える)。中身まで隠したいなら DoT/DoH/DoQ と組み合わせる。

7.2 DoT (DNS over TLS, RFC 7858) #

DNS のクエリ/応答を TLS で暗号化して TCP/853 で送る。中継 ISP・公共 Wi-Fi の盗聴・改ざんから守る。Android 9+ ("Private DNS") や iOS 14+ で実装されている。

7.3 DoH (DNS over HTTPS, RFC 8484) #

クエリを HTTPS の POST/GET でカプセル化する。HTTPS と同じ TCP/443 を使うので、ファイアウォール越しの追跡が困難。Firefox / Chrome / Edge で利用可能。

DoT と DoH は競合より補完: DoT は OS 全体での透明な置き換えに、DoH はブラウザ単体での暗号化に向く。

7.4 DoQ (DNS over QUIC, RFC 9250) #

QUIC (HTTP/3 の基盤プロトコル) 上で DNS を運ぶ。0-RTT 接続再開と多重ストリームで DoT より低遅延。AdGuard、NextDNS など先進リゾルバが対応中。

8. 主な攻撃と歴史 #

8.1 Cache Poisoning (Kaminsky attack, 2008) #

ダン・カミンスキー が 2008 年に公表した、当時すべてのリゾルバに影響した重大な脆弱性。

  • リゾルバが上位サーバーに問い合わせている間に、攻撃者が偽の応答を大量に送りつける
  • 当時の DNS は 16 bit のトランザクション ID だけで応答を識別していたため、誕生日攻撃で偽応答を成功させやすかった
  • 一度キャッシュが汚染されると、TTL が切れるまでそのリゾルバを使う全員が偽 IP に誘導される

対策: ソースポートのランダム化 (16 bit → 16+16 bit のエントロピー)。すべての主要リゾルバが対応済み。根本対策は DNSSEC。

8.2 DNS Spoofing #

ローカルセグメント上の中間者 (ARP スプーフィング後など) が 偽の DNS 応答を返す 攻撃。一般 ISP は信頼している前提が崩れるため、フリー Wi-Fi で深刻。

対策: DoT/DoH によるエンドツーエンド暗号化、信頼できるリゾルバの利用、VPN 併用。

8.3 DNS Amplification Attack #

短い問い合わせに対して大きな応答が返る DNS の特性を悪用した DDoS。

  • 攻撃者が送信元 IP を被害者に偽装して open recursive リゾルバへクエリ送信
  • リゾルバが大きな応答 (DNSKEY など、増幅率 100 倍超もある) を被害者に返す
  • 結果的に被害者の帯域が一斉に飽和

対策: open recursive を作らない (内部限定で運用)、Source Address Validation (BCP 38) で送信元偽装を排除、Response Rate Limiting (RRL)。

8.4 DNS Tunneling #

DNS クエリ/応答にデータをエンコードして埋め込み、ファイアウォールが許可している DNS チャネルを通じて C2 通信やデータ持ち出しを行う手法。dnscat2, iodine 等のツールがある。低速だが検出が難しい。

対策: DNS クエリの長さ・頻度・パターンを監視 (異常なほど長い TXT 応答や、特定ドメインへの大量クエリは要注意)、DPI、Response Policy Zone (RPZ) で既知 C2 ドメインを遮断。

8.5 サブドメインテイクオーバー #

old-blog.example.com のようなサブドメインが CNAME で外部サービス (GitHub Pages, Heroku, S3, Azure 等) を指したまま、サービス側のリソースは削除されているケース。攻撃者が同名のリソースを作成してサブドメインを乗っ取れる。

対策: 退役 CNAME を必ず削除、定期的な棚卸し、自動検出ツール (subjack, nuclei)。

8.6 NXDOMAIN attack / Random Subdomain attack #

ランダムな存在しないサブドメイン (xyz123.example.com) を大量に問い合わせる。リゾルバはキャッシュヒットせず、毎回権威サーバーに問い合わせるため、権威サーバーが過負荷になる。

対策: 権威サーバーへのレート制限、上流リゾルバの NXDOMAIN キャッシュ、Anycast による分散吸収。

DNS は「単なる名前解決」ではなく、インターネットの信頼の基盤そのものである。一見地味だが、ここが汚染されればその上のすべて (HTTPS、メール、API、CDN) が崩れる。本記事の流れ — 階層構造 → 名前解決 → RR → 暗号化拡張 → 攻撃史 — を 1 度通しで掴んでおくと、dig +trace の出力やインシデントログに向かったときに、自分が今どの段階を見ているのかが具体的に分かるようになる。