03. DNS の仕組み - インターネットの電話帳

読了時間: 40-60分 ジャンル: 教養・読み物（手を動かさない） 想定読者: バックエンド学習中の人、インフラの「裏方」が気になる人前提: IP を軽く読んでいると入りやすい

この記事で持って帰れること

DNS の階層構造・権限委譲・キャッシュという3つの天才的発想を語れる

「DNS が原因かも?」を最初に疑える嗅覚を養える

dig コマンドの出力を見て、何が起きているか読み解ける

TTL の意味を理解し、ドメイン引っ越し時の「TTL 仕込み」が実務でできる

過去の有名 DNS 事件 (Dyn, Facebook BGP) から、自分のサービスの設計判断を引き出せる

前回 (02_HTTPの進化) との繋がり

前回は「URL を入力してからページが表示されるまでの旅」の中で、HTTP の話を中心にした。だがその旅の本当の始点は DNS の名前解決。HTTP が動く前に、www.example.com → 93.184.216.34 の変換が裏で起きている。今回はその「見えない最初の一歩」を覗き込む話。

はじめに: 「止まると全部止まる」やつ

普段、ブラウザに google.com と打つと Google が出る。アプリで「ログイン」を押すとサーバーに繋がる。スマホで通知が届く。当たり前のように動いている。

しかしこの裏には、毎回必ず一度は通っている見えない仕組みがある。DNS (Domain Name System) だ。

DNS は普段は完全に空気のように透明な存在で、ユーザーはおろかエンジニアでも「動いて当たり前」のものとして扱っている。だが、ひとたび止まると、

ウェブサイトが軒並み開けない
メールが届かない
スマホアプリは「サーバーに接続できません」を連発
社内システムは全滅
自社サービスの売上が秒単位で蒸発

という事態が、文字通り全世界で同時に起こる。

DNS は「インターネットの空気」

普段は意識しない。だが止まると、人間が窒息するように、サービスは即死する。

バックエンドエンジニアは「DNS は当たり前に動く」と思ってはいけない。むしろ、「障害が起きたらまず DNS を疑え」 という格言が業界にあるくらい、よく壊れる場所でもある。

「電気・水道・DNS」とまで言われることがある。インフラの一部だと思っていい。

この記事では、DNS がなぜ生まれ、どう動き、どう運用され、どう攻撃され、どう守られているかを通しで眺める。手を動かさなくていい。スマホでスクロールしながら、「インターネットの裏でこんなことが起きていたのか」を味わうための話だ。

第1章: なぜ DNS が必要だったのか

人間は数字を覚えられない

インターネット上のすべてのサーバーには、固有の住所がある。これが IP アドレス。

例えば Google の検索サーバーは、ある時点では 142.250.196.142 のような数字が振られている。スマホの通信キャリアから出ていく自分のスマホも、瞬間瞬間で割り当てられた IP を持っている。

問題は、人間がこの数字をまったく覚えられないことだ。

電話番号でさえ「家族の番号を3つくらいなら」というレベル。これが32ビットの数字（IPv4 で約43億通り）、しかも IPv6 になると128ビット（事実上無限）、そんなものを覚える人類はいない。

IP アドレスを覚える人類はいない

「3 と 7 と 11 のついた寿司屋にいつものメンバーで集合」と言われて行けるか？という話。寿司屋の名前ですら覚えないのに、43億通りの数字を覚えるのは無理だ。

だから「名前」と「住所」を対応させる電話帳が必要になった。これが DNS の原点。

ブラウザに google.com と打ったとき、コンピュータは「google.com という名前のサーバーの IP アドレスは何？」と DNS に聞きに行く。返ってきた IP に対して通信を始める。これがインターネットの最も基本的な動作だ。

hosts.txt の時代

DNS が生まれる前、1970年代後半から80年代前半のインターネットは、いま使っている google.com のような名前と IP の対応を、1つのテキストファイル で管理していた。

その名も HOSTS.TXT。

このファイルを保守していたのは、米国の SRI (Stanford Research Institute) という研究機関の NIC (Network Information Center)。世界中のサーバー管理者は、定期的に SRI から HOSTS.TXT をダウンロードして自分のマシンに置いていた。

HOSTS.TXT という共有スプレッドシート

想像してほしい。Google スプレッドシートに「世界中のサーバーの IP と名前」を全部書いて、世界中の人がそれをダウンロードしてローカルに保存して使う。それが当時のインターネットだった。

ARPANET（インターネットの原型）のホスト数が数百台のうちはこれで回った。皆で同じファイルを見ていれば、互いを名前で呼べる。

ちなみに今でも、各 OS には /etc/hosts（Windowsは C:\Windows\System32\drivers\etc\hosts）というファイルが残っていて、DNS より優先して参照される。ローカル開発で 127.0.0.1 myapp.local と書いて、ローカルホストに名前を付けたりするのに使う。hosts.txt はその名残。

限界が来る

このやり方には致命的な問題があった。

更新が間に合わない: ホストが増えるたびに SRI に申請、SRI が手作業で HOSTS.TXT を更新、世界中がダウンロードし直す。1日に何度も更新されるようになると追いつかない
名前の衝突: 「俺も mail ってホスト名にしたい」「いや俺が先だ」が世界規模で発生する
トラフィックが集中: 世界中が SRI のサーバーから定期的にダウンロード。ネットワークもサーバーも限界
一極集中の脆さ: SRI が落ちたら世界中が新規マシンを認識できない

中央集権の限界

インターネットが「数百台の研究機関ネットワーク」から「数万台、数十万台、数百万台」に成長していく中で、1つのファイルで全世界を管理するモデルは破綻が見えていた。

ここで必要になったのは「分散して、階層化して、それぞれの組織が自分のところだけ管理する」仕組み。

DNS の誕生（1983-1987）

この問題を解決するため、ポール・モカペトリス (Paul Mockapetris) という研究者が新しい仕組みを設計した。それが DNS (Domain Name System) で、1983年に RFC 882 / 883 で発表され、1987年に RFC 1034 / 1035 で現在の形がほぼ固まった。

DNS の発明は3つの天才的なアイデアでできている:

階層構造: 名前を . で区切って木構造にする (www.google.com → com → google → www)
権限委譲: 各階層の管理を、その階層の持ち主に任せる (google.com の中は Google が管理)
キャッシュ: 一度引いた結果は一定時間覚えておく (毎回根元から引かなくていい)

この3つを組み合わせると、世界中のホスト名を、世界中で分散して管理しつつ、誰もが一貫した結果を得られる という仕組みが成立する。

DNS は1980年代の傑作分散システム

いま流行りのマイクロサービスとか分散DBの議論をすると、必ず「整合性」「可用性」「分割耐性」みたいな話になる。

DNS は1980年代に、「ゆるい整合性 (eventual consistency) を許容する代わりに、可用性とスケーラビリティを取る」 という設計判断をしている。これがインターネット全体を支えている。すごい先見性。

40年経った今も基本構造は当時のまま動いている。これだけ長く使われ続けている分散システムは、たぶん DNS と Git くらいしかない。

第2章: ドメイン名の階層構造

「読む順番」は右から左

www.google.com というドメイン名がある。これを「ダブリュー・ダブリュー・ダブリュー、グーグル、コム」と左から読むと思っている人は多い。

DNS の世界では、この順番は右から読む のが本質的な解釈だ。

www.google.com.
└─┴────┴───┴─→ ルート (省略可)
   │   │    └─→ TLD (Top Level Domain): com
   │   └──────→ セカンドレベル: google
   └──────────→ サードレベル / ホスト: www

末尾の . (ドット) は ルートドメイン を表す。普段は省略して書く（書かない）が、DNS が内部で扱っている本当の形は www.google.com. だ。

ルートドメインの .

「ドメインの一番てっぺん」を表す記号。www.google.com と www.google.com. は厳密には別物だが、ほぼすべてのアプリケーションで自動的に補完される。

dig コマンドや BIND の設定では明示的に . を書くことがある。「あれ、最後の点なに？」となったら「ルートドメイン」だと思えばいい。

階層構造の全景

イメージは、世界の住所体系に近い。

                       . (root)
                       │
       ┌───────────────┼───────────────┐
       │               │               │
      com             org             jp        ← TLD
       │               │               │
   ┌───┼───┐        wikipedia       co.jp
   │   │   │           │               │
google amazon apple   en.wikipedia   yahoo
   │   │   │
  www mail maps                     ← サブドメイン / ホスト

↓ DNS 名前空間の階層構造（Root → TLD → SLD → ホスト） ↓

flowchart TD
    Root["."] --> COM[com]
    Root --> ORG[org]
    Root --> JP[jp]
    COM --> Google[google]
    COM --> Amazon[amazon]
    COM --> Apple[apple]
    ORG --> Wikipedia[wikipedia]
    JP --> CoJp[co.jp]
    JP --> AcJp[ac.jp]
    Google --> WWW[www]
    Google --> Mail[mail]
    Google --> Maps[maps]
    Wikipedia --> EnWiki[en]
    CoJp --> Yahoo[yahoo]

    classDef root fill:#f9f,stroke:#333,stroke-width:2px
    class Root root

一番上に ルート (.)
その下に TLD (Top Level Domain): com, org, net, jp, uk など
その下に セカンドレベル: google, amazon, wikipedia など
さらに下に サブドメイン: www, mail, api, blog など

TLD の種類

TLD は主に3種類に分けられる。

TLD の分類

gTLD (汎用): 古典の .com .net .org .edu .gov .mil、新興の .app .dev .cloud .io .xyz .ai。2012年以降は ICANN の「新 gTLD プログラム」で大幅に増えた

ccTLD (国別): .jp (日本) .uk (英国) .de (ドイツ) など。ISO 3166-1 alpha-2 準拠。.tv (Tuvalu) や .ai (Anguilla) のように英単語と被って高値取引される国もある

その他: .arpa (インフラ用、逆引き)、国際化ドメイン .日本 .中国 (Punycode で ASCII に変換)

.io の正体

スタートアップ業界で大人気の .io は、実は British Indian Ocean Territory (英領インド洋地域) という、人口数千人の地域に割り当てられた ccTLD。

Input/Output に見えるから IT 業界が殺到し、年間数十万件レベルで登録されている。本来の土地の住民とは何の関係もない。

同様に .ly (リビア) は bit.ly で、.me (モンテネグロ) は個人サイトで、.tv (ツバル) は動画サイトで人気だ。国の運営費の重要な収入源 になっているケースも多い。

`com` と `co.jp` の構造的な違い

ここで日本のドメインを見てみる。

google.com → セカンドレベルが google
yahoo.co.jp → セカンドレベルが co、サードレベルが yahoo

co.jp の co は何かというと、「.jp ドメインの中の、会社 (company) 区分」を表す。

ドメイン	用途
`.co.jp`	株式会社、有限会社など
`.ac.jp`	教育機関 (academic)
`.go.jp`	政府機関 (government)
`.ne.jp`	ネットワークサービス
`.or.jp`	一般の法人
`.lg.jp`	地方公共団体

.jp を管理している JPRS (株式会社日本レジストリサービス) が、.jp 配下を区分けして運用している。

「うちは .co.jp です」が示すもの

.co.jp は、法人登記情報をもとにしか取得できない。1社1ドメインの制約もある。

つまり名刺で co.jp を見ると、それだけで「ちゃんと法人登記された企業ですよ」というシグナルになる。ある種の信用情報 として機能している。

一方 .com は誰でも年1000円程度で取得できる。お試しサービスもフィッシング詐欺も .com で平気で動く。これが「日本のサイトは .co.jp の方が信用される」風潮の根拠の一つ。

第3章: DNS 名前解決の流れ

全体像

ブラウザに www.example.com と打って Enter を押したとき、裏で何が起きているか。

ユーザー
  │
  │ ① www.example.com の IP 教えて
  ▼
[ローカルDNSキャッシュ (OS)]  ─→ あれば即返す
  │
  │ なければ
  ▼
[フルリゾルバ (再帰問い合わせサーバー)]
   契約ISPや Google DNS (8.8.8.8) や Cloudflare DNS (1.1.1.1)
  │
  │ ② . (ルート) の DNS に「.com の DNS 教えて」と聞く
  ▼
[ルート DNS サーバー]
  │ 「.com の DNS は a.gtld-servers.net とかだよ」
  ▼
[.com の DNS サーバー (TLD)]
  │
  │ ③ example.com の DNS を教えて
  ▼
[.com の DNS サーバー]
  │ 「example.com の DNS は ns1.example.com だよ」
  ▼
[example.com の権威 DNS サーバー]
  │
  │ ④ www.example.com の A レコード教えて
  ▼
[example.com の権威 DNS サーバー]
  │ 「www.example.com の IP は 93.184.216.34」
  ▼
フルリゾルバが結果をキャッシュ、ユーザーに返す
  │
  ▼
ユーザーのブラウザ: 93.184.216.34 に HTTP リクエスト

これを「再帰問い合わせ (recursive query)」と呼ぶ。

↓ ブラウザから権威 DNS までの再帰問い合わせシーケンス ↓

sequenceDiagram
    participant User as ユーザー(ブラウザ)
    participant Stub as スタブリゾルバ(OS)
    participant Resolver as フルリゾルバ
    participant Root as ルート DNS
    participant TLD as .com TLD DNS
    participant Auth as example.com 権威 DNS

    User->>Stub: www.example.com の IP 教えて
    Stub->>Resolver: 再帰問い合わせ
    Resolver->>Root: .com の DNS は誰?
    Root-->>Resolver: a.gtld-servers.net など
    Resolver->>TLD: example.com の DNS は誰?
    TLD-->>Resolver: ns1.example.com
    Resolver->>Auth: www.example.com の A レコード?
    Auth-->>Resolver: 93.184.216.34
    Resolver-->>Stub: 93.184.216.34 (キャッシュも保存)
    Stub-->>User: 93.184.216.34
    Note over User,Auth: 以降、ブラウザは 93.184.216.34 に HTTP 接続

登場人物の整理

DNS に出てくる5種類のサーバー

1. スタブリゾルバ (stub resolver)

ユーザー側のOSやアプリに組み込まれた最小限の解決機能

「とにかく上のフルリゾルバに丸投げ」する

2. フルリゾルバ / 再帰リゾルバ (full resolver / recursive resolver)

質問を受け取って、ルートから順に階層を辿って答えを取ってくる

結果をキャッシュする

代表例: Google Public DNS (8.8.8.8)、Cloudflare DNS (1.1.1.1)、各 ISP の DNS

3. ルート DNS サーバー

「. (ルート)」を管理。「.com の DNS は誰？」「.jp の DNS は誰？」だけ答える

4. TLD DNS サーバー

「.com の DNS は誰？」「.jp の DNS は誰？」を答える

例: .com は Verisign が運営、.jp は JPRS が運営

5. 権威 DNS サーバー (authoritative DNS server)

そのドメインの正解を持っている本元のサーバー

例: example.com の権威 DNS は、example.com の所有者が指定した ns1.example.com など

ここの設定が そのドメインの真の真実

「再帰」と「反復」の違い

実は DNS には2種類の問い合わせがある。

recursive と iterative

再帰問い合わせ (recursive)

「答えそのものを返してくれ」と頼む

「www.example.com の IP を教えて」「はい、93.184.216.34 です」

フルリゾルバが対応する

反復問い合わせ (iterative)

「答えを知っている人を教えてくれ」と頼む

「www.example.com の IP を教えて」「私は知らないが、.com の DNS を聞きにいけ。アドレスはこれだ」

ルート DNS や TLD DNS が対応する

ユーザー ─[再帰]→ フルリゾルバ ─[反復]→ ルート/TLD/権威

ルートサーバーは反復問い合わせしか受け付けない。「全部俺に聞きにくるな」 という設計。

キャッシュが全てを救う

仮にこの流れを、世界中の DNS 問い合わせで毎回フルにやっていたら、ルート DNS サーバーは即座にパンクする。実際には大半が キャッシュ で済む。

フルリゾルバは、過去に解決した結果を一定時間 (後述する TTL) 持っている
ユーザーのOS やブラウザも、結果を短時間キャッシュする
だから2回目以降の www.example.com は瞬時に解決される

DNS の99%はキャッシュヒット

大手フルリゾルバ (Google DNS, Cloudflare DNS) の統計では、問い合わせの90%以上がキャッシュで完結 している。フルリゾルバがルートまで問い合わせに行くのは少数派。

これがあるから、世界中のインターネット通信が DNS で詰まらずに動いている。

第4章: DNS レコードの種類

DNS は単に「名前 → IP」だけを引いているわけではない。名前に対して用途別の情報を持っていて、それを「レコード」と呼ぶ。

主要レコード一覧

よく使う DNS レコード

レコード意味例
A IPv4 アドレス www.example.com → 93.184.216.34
AAAA IPv6 アドレス www.example.com → 2606:2800:220:1::1
CNAME 別名 (canonical name) blog.example.com → www.example.com
MX メールサーバー example.com → mail.example.com
TXT テキスト情報 (検証や設定用) example.com → "v=spf1 -all"
NS 権威 DNS サーバー example.com → ns1.example.com
SOA ゾーン情報の起点 example.com → ns1, admin@example.com, serial, ...
PTR IP → 名前の逆引き 34.216.184.93.in-addr.arpa → www.example.com
SRV サービス情報 XMPP, SIP などサービス検索用
CAA 証明書発行制限「Let’s Encrypt 以外は証明書発行禁止」

レコード	意味	例
A	IPv4 アドレス	`www.example.com → 93.184.216.34`
AAAA	IPv6 アドレス	`www.example.com → 2606:2800:220:1::1`
CNAME	別名 (canonical name)	`blog.example.com → www.example.com`
MX	メールサーバー	`example.com → mail.example.com`
TXT	テキスト情報 (検証や設定用)	`example.com → "v=spf1 -all"`
NS	権威 DNS サーバー	`example.com → ns1.example.com`
SOA	ゾーン情報の起点	`example.com → ns1, admin@example.com, serial, ...`
PTR	IP → 名前の逆引き	`34.216.184.93.in-addr.arpa → www.example.com`
SRV	サービス情報	XMPP, SIP などサービス検索用
CAA	証明書発行制限	「Let’s Encrypt 以外は証明書発行禁止」

↓ 主要 DNS レコードの役割と関係性 ↓

flowchart LR
    Domain[example.com]

    Domain --> A["A レコード<br/>IPv4: 93.184.216.34"]
    Domain --> AAAA["AAAA レコード<br/>IPv6: 2606:2800::1"]
    Domain --> MX["MX レコード<br/>メール宛先"]
    Domain --> NS["NS レコード<br/>権威 DNS 指定"]
    Domain --> TXT["TXT レコード<br/>SPF/DKIM/DMARC"]
    Domain --> SOA["SOA レコード<br/>ゾーン起点情報"]

    CNAME["blog.example.com<br/>CNAME レコード"] -.別名として参照.-> Domain

    MX --> MailServer[mail.example.com]
    MailServer --> A2[A レコード<br/>メールサーバーのIP]
    NS --> NSServer[ns1.example.com]
    NSServer --> A3[A レコード<br/>権威DNSのIP]

    classDef record fill:#fff4d4,stroke:#333
    class A,AAAA,MX,NS,TXT,SOA,CNAME,A2,A3 record

A と AAAA

最も基本。A レコードは IPv4 アドレス、AAAA レコードは IPv6 アドレス。AAAA が4つ並んでいるのは IPv4 (32ビット = 4オクテット) に対して IPv6 (128ビット = 16オクテット = 4オクテットの4倍) という由来。

A と AAAA が両方ある時の挙動

現代のブラウザは、A も AAAA も両方問い合わせ、先に応答が返ってきた方を使う。これを Happy Eyeballs という。

IPv6 が遅い環境（経路が混んでる、ファイアウォールで詰まる）でも、ユーザー体感を下げないための工夫。RFC 8305 で定義。

CNAME の罠

CNAME は「別名」だ。「blog.example.com の中身は www.example.com を見てね」という指示。

CNAME の落とし穴

CNAME には強い制約がある: CNAME と他のレコードは同じ名前に共存できない。

たとえば example.com (ルートドメイン) に CNAME を設定すると、MX レコード（メール）も SOA も NS も全部無効になる。よって ルートドメインに CNAME は付けられない のが標準仕様。

これが運用上の地雷で、「CloudFront とか CDN を example.com (apex) に向けたい」というニーズに対して、各 DNS プロバイダが ALIAS レコード とか ANAME レコード という独自拡張で対応している。

AWS Route 53 の「Alias レコード」がその代表。これは A レコードの皮を被って、内部で動的に IP を解決してくれる。

MX レコードとメール

メールは送信時に「example.com 宛のメールはどこに送るの？」を MX レコードで引く。

example.com.   IN  MX  10 mail.example.com.
example.com.   IN  MX  20 mail2.example.com.

数字（10 と 20）は 優先度。小さい方を先に試す。ダメだったら次。メール冗長化の基本設計。

MX レコードを書き間違えると即メール全滅

ドメイン引っ越しの時に MX レコードを更新し忘れて、「気付いたら新規問い合わせメールが3日間全部届いてなかった」という事故は無数にある。

メールは TCP/SMTP で「送れなかったら再送」する仕組みがあるので、しばらく送信側のキューに溜まる。だから気付くのが遅れる。MX レコード変更は怖い作業。

TXT レコードと付随仕様

もともと「自由にテキストを書ける欄」だった TXT レコードは、いまやメールセキュリティの中核になっている。

SPF (Sender Policy Framework): そのドメイン名でメールを送る権限を持つサーバーを列挙
DKIM (DomainKeys Identified Mail): メールに公開鍵で電子署名するための公開鍵を公開
DMARC: SPF や DKIM の結果をどう扱うかのポリシー
ドメイン所有確認: Google Workspace や AWS や Slack を契約すると、TXT レコードに指定文字列を書かされる。「ドメイン所有確認」のため

TXT の例
example.com.   IN  TXT  "v=spf1 include:_spf.google.com -all"
example.com.   IN  TXT  "google-site-verification=ABCDEF..."
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:admin@example.com"
なんの脈絡もない文字列がたくさん並んでいるドメインは、いろんな SaaS と連携している証。

NS と SOA

NS (Name Server) レコードは、「このドメインの権威 DNS はこいつだよ」を示す。ドメイン取得後に最初に設定するのがこれ。

SOA (Start Of Authority) レコードは、そのゾーンの起点情報。シリアル番号、管理者メール、リフレッシュ間隔などが書かれている。1つのゾーンに必ず1つ存在。

SOA のシリアル番号

SOA レコードには シリアル番号 が含まれていて、変更があるたびに増やす慣習。

セカンダリ DNS（バックアップの権威 DNS）は、定期的にプライマリの SOA を見て、シリアル番号が増えていたら「更新されたな」と判断して同期する。

形式は YYYYMMDDNN (例: 2026051701 = 2026年5月17日の1回目) という日付ベースが慣例。

PTR と逆引き

PTR レコード は IP アドレスから名前を引く「逆引き」用。

普段あんまり使わないと思いがちだが、メールサーバーは PTR を厳しくチェックする。送信元の IP の PTR が、名乗っている FQDN と一致しないと「怪しい」と判定されてスパム扱いされる。自社メールサーバーを建てるなら、PTR の設定は必須。

「PTR が引けないからメール届かない」事件

AWS や GCP で EC2 を立ててメールサーバーを動かしても、デフォルトの PTR は ec2-xx-xx.compute.amazonaws.com みたいなクラウド業者の名前になっている。これが原因で、Gmail や Outlook にメールが届かない。

解決策: クラウド業者に依頼して PTR を自社ドメインに書き換えるか、メール送信は SendGrid や Amazon SES のような専用サービスに任せる。自前 SMTP の運用は地獄、というのが現代の通説。

第5章: TTL の意味と運用

TTL とは

TTL (Time To Live) はレコードの キャッシュ有効期限。秒単位で指定する。

www.example.com.  3600  IN  A  93.184.216.34
                  ────
                  TTL (秒) = 3600秒 = 1時間

このレコードを問い合わせたフルリゾルバは、「www.example.com は 93.184.216.34」を 1時間覚えている。1時間以内に同じ問い合わせが来たら、キャッシュから即答する。

↓ TTL によるキャッシュヒット/ミスの動き ↓

sequenceDiagram
    participant Client as クライアントA
    participant Client2 as クライアントB
    participant Resolver as フルリゾルバ
    participant Auth as 権威 DNS

    Client->>Resolver: www.example.com?
    Note over Resolver: キャッシュ無し
    Resolver->>Auth: 問い合わせ
    Auth-->>Resolver: 93.184.216.34 (TTL=3600)
    Resolver-->>Client: 93.184.216.34
    Note over Resolver: キャッシュ保存 (残り3600秒)

    Client2->>Resolver: www.example.com?
    Note over Resolver: キャッシュヒット!
    Resolver-->>Client2: 93.184.216.34 (即答)

    Note over Resolver: ...3600秒経過...

    Client->>Resolver: www.example.com?
    Note over Resolver: TTL 切れ → 再問い合わせ
    Resolver->>Auth: 問い合わせ
    Auth-->>Resolver: 最新の IP (TTL=3600)

TTL は「変更の反映速度」と「サーバー負荷」のトレードオフ

短い TTL (例: 60秒)

変更すれば1分後には全世界に伝わる

その代わり、フルリゾルバは1分ごとに権威 DNS に問い合わせる → 負荷が高い

長い TTL (例: 86400秒 = 1日)

変更しても1日経たないと全世界には伝わらない

フルリゾルバの問い合わせは少ない → 負荷が低い、応答が速い

普通は 1時間 (3600) ～ 1日 (86400) あたりが多い。

変更時のテクニック: TTL を一時的に短くする

DNS 変更（IP 引っ越し、CDN 切替など）をする時の 鉄板テクニック がある。

DNS 変更の3ステップ

変更の1日前: TTL を一時的に 60～300秒 に短くする

元の TTL が 86400 (1日) なら、1日前に 300 に下げておく

こうすると変更直前にはキャッシュが切れて短い TTL で再キャッシュされる

変更当日: 本来やりたい IP 変更を実施

キャッシュは5分で全世界に伝わる

変更後 (数日後): TTL を元の長さに戻す

短い TTL のままだと負荷が高いので、安定したら 86400 に戻す

このパターンを 「TTL 仕込み」 と呼ぶ。本番ドメイン引っ越しの基本作法。

TTL を下げ忘れて変更したら

1日前に TTL を下げ忘れて、いきなり IP を変えると、世界中のフルリゾルバの中に古い IP がキャッシュとして残り続ける。

「俺の家からはアクセスできるけど、客先からは旧 IP に行ってるから繋がらない」みたいな現象が、最大で 元の TTL の長さ分 起き続ける。1日の TTL なら丸1日。

CDN を切り替えるような大きな変更の前は、必ず1日以上前に TTL を下げる。これは儀式と思っていい。

第6章: ルート DNS サーバー13台の謎

「DNS には13台のルートサーバーがある」

DNS の入門書でよく見る。「ルート DNS サーバーは世界に13台ある」。

これは半分正しくて、半分間違っている。

13台の本当の意味

13という数字は、1台のサーバーの数ではなく、IP アドレスの数を指している。a.root-servers.net から m.root-servers.net まで、A から M までの13の名前と13のIPアドレスがある。

ところが、この13個の IP アドレスにそれぞれ「数百台のサーバー」がぶら下がっている。実際の物理サーバー数は、2024年時点で 世界中に1500台以上 ある。

どうやってこれを実現しているか？ Anycast (エニーキャスト) という仕組み。

Anycast: 同じ IP が世界中に

Anycast は「同じ IP アドレスを、世界中の複数のサーバーが名乗る」という仕組み。BGP (Border Gateway Protocol) という経路制御プロトコルで、ユーザーは自動的に「ネットワーク的に最も近いサーバー」に振り分けられる。

日本のユーザー → 198.41.0.4 → (実際は)東京のサーバーに到達
ドイツのユーザー → 198.41.0.4 → (実際は)フランクフルトのサーバーに到達
ブラジルのユーザー → 198.41.0.4 → (実際は)サンパウロのサーバーに到達

これによって:

低遅延: 世界中どこからアクセスしても、近くのサーバーに繋がる
耐障害性: 1拠点が落ちても、他の拠点が同じ IP で応答する
DDoS 耐性: 攻撃が来ても、世界中に分散しているので1拠点に集中しにくい

なぜ13個に制限されたか

DNS は当初、応答パケットを UDP 512バイト以内 に収める設計だった (RFC 1035)。これは初期のネットワーク機器の都合。

512バイトの中に13個のルートサーバー情報を入れるのが限界だった、というのが13という数字の歴史的な理由。今は EDNS0 という拡張でもっと大きなパケットも扱えるが、慣習として13は変えにくくなっている。

13台はどこにある？

A, J は Verisign。B は USC-ISI、C は Cogent、D はメリーランド大学、E は NASA、F は ISC、G/H は米軍系、I は Netnod (スウェーデン)、K は RIPE NCC (欧州)、L は ICANN、そして M は日本の WIDE プロジェクト。村井純先生が中心になって動いているやつで、インターネット基盤への日本の貢献の象徴。

ルート DNS は「政治」でもある

ルート DNS の運営は、技術であると同時に 国際政治 でもある。

もしどこか1国が「ルート DNS を停止しろ」と命令できると、インターネット全体を支配できる。これを避けるため、運営組織は意図的に分散していて、特定国の管轄下に置かれていない。

各国の政府は何度か「ルート DNS を国家管理にしよう」という案を出しているが、技術コミュニティが抵抗してきた歴史がある。インターネットの中立性を支える、見えない努力がここにある。

第7章: DNS が攻撃される時

DNS キャッシュポイズニング

DNS は1980年代の設計なので、セキュリティ上の弱点がいくつもある。代表的なのが DNS キャッシュポイズニング (DNS Cache Poisoning)。

キャッシュポイズニングの仕組み

攻撃者はフルリゾルバに www.target.com の問い合わせを誘発する

フルリゾルバが権威 DNS に問い合わせている途中で、攻撃者は権威 DNS のフリをして偽の応答パケットを送りつける

本物の応答より早く届いた偽応答を、フルリゾルバが正しいと信じてキャッシュする

キャッシュされている間、そのフルリゾルバを使う全ユーザーが偽のサイトに誘導される

例: 偽のオンラインバンキングサイトに誘導 → ID/パスワード窃取 → 預金窃盗

偽サイトは見た目が本物そっくりなので、ユーザーは気付かない。DNS は「URLは本物なのに、繋がる先だけ偽物」という攻撃ができてしまう。

↓ キャッシュポイズニング攻撃の流れ ↓

sequenceDiagram
    participant Attacker as 攻撃者
    participant Resolver as フルリゾルバ
    participant RealAuth as 本物の権威 DNS
    participant Victim as 被害ユーザー

    Attacker->>Resolver: bank.example.com の問い合わせを誘発
    Resolver->>RealAuth: bank.example.com の IP は?
    Attacker-->>Resolver: 偽応答 (偽IP, トランザクションID推測)
    Note over Resolver: 本物の応答より先に偽応答が到着
    RealAuth-->>Resolver: 本物の応答 (時すでに遅し)
    Note over Resolver: 偽IPをキャッシュ

    Victim->>Resolver: bank.example.com?
    Resolver-->>Victim: 偽IP (キャッシュから)
    Victim->>Attacker: 偽サイトへアクセス
    Note over Victim,Attacker: ID/パスワード窃取

Kaminsky 攻撃 (2008)

2008年に ダン・カミンスキー (Dan Kaminsky) という研究者が、DNS キャッシュポイズニングを桁違いに簡単に成功させる手法を発見した。

旧来のキャッシュポイズニングは、応答の トランザクション ID (16ビット) を当てる必要があり、最大 65536 通りを当てる「総当たり」が必要だった。Kaminsky は、これを 大幅に短時間で成功させる仕組み を発見し、業界に衝撃が走った。

Kaminsky 攻撃への業界対応

Kaminsky は発見してすぐ公表せず、主要 DNS 実装の開発者（BIND, Microsoft, Cisco など）を集めた秘密会議 を開いた。一斉にパッチを作り、世界中に展開してから公表する、という前代未聞の調整をした。

その後の対策が 送信元ポートのランダム化。トランザクション ID 16ビットだけでなく、UDP 送信元ポート (約16ビット) も毎回ランダムにすることで、攻撃者が当てる組み合わせを 32ビット級に増やす。これでだいぶマシになった。

ただし根本対策ではない。それが次に出てくる DNSSEC。

DNSSEC

DNSSEC (DNS Security Extensions) は、DNS 応答に電子署名を付けて、応答が改ざんされていないことを検証できるようにする仕組み。

DNSSEC の流れ

各 DNS 応答に、署名 (RRSIG レコード) が付く

その署名を検証するための公開鍵 (DNSKEY レコード) も DNS で配布される

公開鍵自体の正当性は、上位ゾーンの DS レコードでチェーン的に保証される

ルートゾーンの公開鍵が信頼の起点 (Trust Anchor) になる

これによって、応答が偽造されていれば「署名が合わない」と検出できる。

DNSSEC は技術的には正解の仕組みだが、運用がややこしいことで知られている。

鍵の管理 (定期更新が必要)
ゾーン署名の自動化
設定ミスでドメイン全滅 (署名期限切れで「正規だけど検証失敗」という事故)

DNSSEC を有効にしたら自社ドメインが見えなくなった事件

DNSSEC の運用ミスで自社ドメインが解決不能になる事故は何度も起きている。

2020年には Slack が DNSSEC 関連の事故で数時間ダウンしている。署名期限切れで、DNSSEC を有効にしているリゾルバから見ると、Slack が「存在しない」状態になった。

こういう事故が嫌で、DNSSEC を導入していない企業はまだ多い。

DoH と DoT

もう一つの問題: DNS は平文で流れる。

ユーザーが bank.example.com を引いたという情報は、ISP や経路上の中継機器に丸見え。「あ、この人銀行サイト見るんだ」がバレる。これはプライバシー問題。

DoH (DNS over HTTPS) と DoT (DNS over TLS)

DoH (DNS over HTTPS)

DNS 問い合わせを HTTPS で暗号化して送る

通常の HTTPS トラフィックに紛れるので、傍受も検閲も困難

Firefox や Chrome はデフォルトで Cloudflare DoH (1.1.1.1) や Google DoH (8.8.8.8) を使うようになった

DoT (DNS over TLS)

DNS 問い合わせを TLS で暗号化して送る (専用ポート 853)

HTTPS とは別経路、ファイアウォールで識別しやすい

Android はデフォルトで DoT 対応

DoH/DoT はユーザーのプライバシー保護としては大きな進歩。一方で、企業ネットワーク管理者からすると「ユーザーが何を見ているか分からない」「マルウェア通信を検知できない」となり、複雑な議論を呼んでいる。

↓ 通常 DNS と DoH/DoT の経路の違い ↓

flowchart LR
    subgraph Plain["通常 DNS (Port 53, 平文)"]
        A1[ブラウザ] -->|平文クエリ| A2[ISP/中継] -->|傍受可能| A3[DNS サーバー]
    end

    subgraph DoH["DoH (Port 443, HTTPS暗号化)"]
        B1[ブラウザ] -->|TLS 暗号化| B2[ISP/中継]
        B2 -.->|中身見えない| B3[DoH サーバー]
        B1 ==>|HTTPS 通信に紛れる| B3
    end

    subgraph DoT["DoT (Port 853, TLS暗号化)"]
        C1[ブラウザ] -->|TLS 暗号化| C2[ISP/中継]
        C2 -.->|中身見えない| C3[DoT サーバー]
        C1 ==>|専用ポートで識別可能| C3
    end

DoH と企業 IT のせめぎ合い

企業 IT は、社内ネットワークの DNS を監視して「マルウェアが C&C サーバーに通信していないか」を見ている。

社員のブラウザが勝手に Cloudflare DoH を使うようになると、この監視が利かなくなる。だから企業向けのブラウザ設定で「DoH を無効化」「DoH 先を社内 DNS に固定」といったポリシーを使う。

プライバシーと管理者のコントロール、永遠のトレードオフ。

第8章: ドメインを取得するということ

4つの登場人物

ドメインを買うとき、裏では4つの組織が関わっている。

ドメイン業界の関係者

1. ICANN (Internet Corporation for Assigned Names and Numbers)

インターネット全体の名前空間と IP アドレスを統括する非営利団体

米カリフォルニア州ベース、本社ロサンゼルス

「インターネット政府」と呼ばれることも

2. IANA (Internet Assigned Numbers Authority)

ICANN の内部機能。実務的な番号管理を行う

ルート DNS の運用、TLD の管理、IP アドレスの配分などの実作業

3. レジストリ (Registry)

特定の TLD を運営する組織。1 TLD = 1 レジストリ

.com .net は Verisign

.org は Public Interest Registry

.jp は JPRS (日本レジストリサービス)

4. レジストラ (Registrar)

一般のユーザーにドメインを販売する小売店

GoDaddy, Namecheap, お名前.com, ムームードメイン, Google Domains (Squarespace に売却), Cloudflare Registrar など

利用者と契約し、裏でレジストリに登録申請する

お金の流れ

ユーザーが example.com を年1500円で買うと、

ユーザー
  │ 年1500円
  ▼
レジストラ (お名前.com など) → 利益: 数百円
  │ 年1000円程度 (実コスト)
  ▼
レジストリ (Verisign for .com) → 利益: 大半
  │ TLD 全体の収益から一部支払い
  ▼
ICANN → 標準化や運営費用

Verisign は .com ドメイン1個につき年間 $9.59 (2024年時点) をレジストラから徴収している。.com の登録数は1.6億件以上。つまり Verisign は .com だけで年間1500億円規模の収益を生んでいる。インターネットのインフラを握っているということ。

↓ ドメイン登録における4組織の関係と金の流れ ↓

flowchart TD
    User[ユーザー<br/>例: 個人/企業]
    Registrar[レジストラ<br/>お名前.com / GoDaddy など]
    Registry[レジストリ<br/>Verisign / JPRS など]
    ICANN[ICANN / IANA<br/>名前空間統括]

    User -->|年1500円支払い| Registrar
    Registrar -->|年1000円程度| Registry
    Registry -->|運営費の一部| ICANN
    ICANN -.->|TLD 運営権の委任| Registry
    Registry -.->|登録代理権の委任| Registrar
    Registrar -.->|ドメイン提供| User

    classDef user fill:#e1f5ff,stroke:#333
    classDef icann fill:#ffe1e1,stroke:#333
    class User user
    class ICANN icann

ドメイン業界はインフラビジネス

.com の運営権は、米国商務省と Verisign の契約で2030年まで延長されている。事実上の独占ビジネス。

一方で、.com レジストリの安定運用責任も Verisign が負っている。ルート DNS の A と J も Verisign。「世界中のメールも Web も止めない責任を、1社が負っている」状況。

インターネットは民間企業の責任感に支えられた、思っているより脆い基盤の上に立っている。

Whois とプライバシー保護

ドメインを取得すると、Whois (フーイズ) という公開データベースに登録者の連絡先情報が登録される。本来は「ドメインの責任者と連絡を取るため」の仕組み。

ただ、住所や電話番号が公開されるとスパム業者の餌食になるので、現代のレジストラはプライバシー保護サービス（Whois 情報の代理表示）を提供している。これも GDPR (EU の個人情報保護規制) 以降は必須に近い扱い。

第9章: 有名な DNS 事件

2016 Dyn DDoS - 米国西海岸全滅事件

2016年10月21日、DNS サービスを提供していた Dyn という会社が、史上最大級の DDoS 攻撃 を受けた。

Dyn DDoS 攻撃

Dyn を権威 DNS として使っていた企業:

Twitter

Netflix

Spotify

Reddit

GitHub

PayPal

Airbnb

The New York Times

これらがほぼ同時に米国西海岸から見えなくなった。

攻撃の正体は Mirai (ミライ) ボットネット。世界中の IoT 機器（防犯カメラ、家庭用ルーター、ベビーモニターなど）に感染したマルウェアが、いっせいに Dyn に DNS 問い合わせを浴びせかける。最大で 1.2 Tbps もの攻撃トラフィックが集中した。

Dyn の DNS サーバーがダウン → 上記企業のドメインが解決できなくなる → 「サービス自体は生きているのに、誰もアクセスできない」事態。

Dyn 事件から学んだこと

多くの企業が、この事件を機に DNS の冗長化 を考えるようになった。

「権威 DNS を1社に集中させない」「複数の DNS プロバイダを並列利用する」というベストプラクティスが広まる。今でも大手はだいたい複数 DNS を使っている。

また、IoT 機器のセキュリティ問題が一気に注目された。「あなたの家のルーターが、世界中のサービスを止める攻撃に加担しているかもしれない」という啓発が広まった。

2021 Facebook BGP 事件

2021年10月4日、Facebook (現Meta) が全世界で6時間ダウンした。Facebook 本体・Instagram・WhatsApp が同時に消えた。

直接の原因は BGP の設定ミスで、Facebook のネットワーク経路が世界から見えなくなったこと。だが、副次効果として DNS の権威サーバーまでアクセスできなくなり、フルリゾルバがキャッシュ切れと共に名前解決不能に陥った。

自社 DNS の罠

Facebook は自社の権威 DNS を自社ネットワーク内で運用していた。ネットワーク自体が消えた瞬間に、DNS も同時に消えた。「DNS だけでも生きていれば、原因究明と復旧の連絡もできた」 と言われている。

さらに皮肉なことに、社員が建物の認証システムにアクセスできなくなり、データセンター修復のために物理的に建物に入ることもできなくなった。インフラを内製化することの怖さを示す象徴的な事故。

インターネットは性善説で動いている

BGP も DNS も「みんなが嘘をつかない」前提で設計されている。1ヶ所が嘘や間違いを言うと、世界中が信じる構造。

2008年にはパキスタンの ISP が YouTube ブロック用 BGP 経路を国内向けに出すつもりが、世界中に漏れ出して YouTube が2時間世界から見えなくなる事故も起きている。1国の設定ミスが世界中のサービスを止める。

現代では RPKI などで BGP 認証も入りつつあるが、まだ完全ではない。「インターネットは奇跡的に動いている」と言われる所以。

第10章: 「DNS で名前解決できない」あるあるデバッグ

DNS は止まることがあるし、設定ミスもある。実務でよく出会う現象とその原因を並べる。

現象1: 「IP で繋がるが、ドメインで繋がらない」

$ ping 93.184.216.34
64 bytes from 93.184.216.34: time=15ms ...   ← 繋がる

$ ping example.com
ping: cannot resolve example.com: Unknown host  ← 繋がらない

これは典型的な DNS の問題。原因の候補:

/etc/resolv.conf のフルリゾルバ指定が壊れている (Linux)
- 「DNS サーバーが書いてない」「書いてある DNS サーバー自体が落ちてる」
VPN やファイアウォールで DNS ポート (53) が止められている
DNS サーバーまでは到達できるが、対象ドメインの権威 DNS が落ちている
DNSSEC の検証エラー

現象2: 「自分は繋がるけど、お客様からは繋がらない」

これも DNS あるある。原因:

TTL が長くて、世界中のキャッシュが古いまま
- 自分の環境はキャッシュをクリアしたが、世界のフルリゾルバには古い IP が残っている
権威 DNS の応答に Geolocation がかかっていて、地域ごとに違う IP が返る
- 「日本からは A 拠点、米国からは B 拠点」みたいな設定
特定の ISP の DNS だけが古い情報をキャッシュしている

現象3: 「dig で引けるけど ping で繋がらない」

$ dig example.com
;; ANSWER SECTION:
example.com.  3600  IN  A  93.184.216.34

$ ping example.com
PING example.com (93.184.216.34): 56 data bytes
Request timeout for icmp_seq 0

DNS は引けているので名前解決は問題ない。ネットワーク or ファイアウォール側の問題。ICMP (ping) だけ止められているケースが多い。HTTP は通るかも。

dig コマンドの読み方

エンジニアが DNS を調べるときの定番ツールが dig (Domain Information Groper)。

$ dig example.com

; <<>> DiG 9.10.6 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.           IN  A

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

;; Query time: 35 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sun May 17 12:34:56 JST 2026
;; MSG SIZE  rcvd: 56

dig の出力の読み方

HEADER

status: NOERROR → 問題なし。NXDOMAIN だと「存在しないドメイン」、SERVFAIL だと「サーバーが壊れてる」

id: 12345 → トランザクション ID。攻撃で使われるあれ

QUESTION SECTION: 何を聞いたか

ANSWER SECTION: 何が返ってきたか

3600 → TTL

IN → クラス (Internet。99%これ)

A → レコードタイプ

93.184.216.34 → 答え

SERVER: どこのフルリゾルバに聞いたか

Query time: 応答時間。キャッシュヒット時は1ms 未満、本気で引きにいくと数百ms

よく使う dig オプション

dig の便利オプション
dig example.com MX           # MX レコードだけ引く
dig example.com TXT          # TXT レコードを引く
dig example.com ANY          # 全タイプ (最近は応答しない権威 DNS も多い)
dig +short example.com       # 結果だけ短く表示
dig +trace example.com       # ルートから順に再帰問い合わせを可視化
dig @8.8.8.8 example.com     # Google DNS に直接聞く
dig -x 93.184.216.34         # 逆引き
特に dig +trace は、DNS の階層問い合わせの動きを目で見るのに最高。「DNS ってなんとなく分かったけど、動きを見たことがない」という人はぜひ一度試してほしい (これは手を動かす話だが、scrollしながら結果イメージを想像するだけでも価値ある)。

第11章: 現代の DNS と未来

CDN と DNS

現代の Web サービスは、ほぼ全て CDN (Content Delivery Network) を経由している。Cloudflare, Akamai, Fastly, CloudFront など。

CDN は 「ユーザーに地理的に近いキャッシュサーバー」 から配信する仕組みで、その振り分けに DNS を使っている。

CDN は DNS で動いている

example.com を引くと、CDN の権威 DNS は ユーザーの IP の位置を見て、最適な拠点の IP を返す。

東京のユーザー → CDN 東京拠点の IP

大阪のユーザー → CDN 大阪拠点の IP

シンガポールのユーザー → CDN シンガポール拠点の IP

同じドメインなのに、引く人によって違う IP が返る。これは DNS の本来の使い方からかなり拡張された応用例。

副作用として、「自分は東京で速いが、海外出張中の客先からは遅い」みたいな現象も発生する。CDN を疑う前に DNS を疑え、と言われる所以。

DNS-based Service Discovery

クラウドネイティブ / マイクロサービスの世界では、DNS は サービス間の名前解決 にも使われる。

Kubernetes 内部の DNS (my-service.my-namespace.svc.cluster.local)
Consul の DNS インターフェース
AWS の VPC 内 DNS

サーバーが動的に増減する世界で「今動いているサーバーはどこ？」を引くのに、DNS の仕組みを応用している。TTL を短くすればリアルタイム性も確保できる。

DNS over QUIC

DoH/DoT に続く次世代として、DoQ (DNS over QUIC) も実装が進んでいる。QUIC は HTTP/3 の下回りのプロトコルで、UDP ベースで TLS の暗号化を行う。

DNS は元々 UDP ベースだったので、UDP のまま暗号化できる QUIC は親和性が高い。今後、徐々に普及していくと予想される。

章の問い (考えるための小さなトリガー)

読みながら / 読み終わって考えてほしいこと

もし自社の権威 DNS が今この瞬間に落ちたら、どれくらいでユーザーへの影響が出始める? TTL を確認して答えられるか?

DoH (DNS over HTTPS) はユーザーのプライバシーを守る。一方で企業 IT からは「マルウェア検知が利かない」と嫌われる。あなたが社内 IT なら、DoH をどう扱う?

インターネットの「中央管理者がいない」という設計思想と、ICANN / IANA / レジストリの存在は矛盾しないか? どこまでが「分散」で、どこからが「集中」?

まとめ: DNS が支えるインターネット

ここまで読んだ人にとって、DNS は単なる「名前解決の仕組み」ではなくなっているはず。

DNS から見えてくること

インターネットは1980年代の天才的な設計判断の上に乗っている: 階層構造・権限委譲・キャッシュ

「ゆるい整合性」を許容することでスケールしている: 40年動き続ける分散システム

見えないインフラを誰かが運用している: WIDE プロジェクト、Verisign、ICANN、各レジストリ

政治・経済・技術が交差する場: ルート DNS の運営、TLD の利権、各国の検閲

セキュリティとプライバシーの闘い: キャッシュポイズニング、DNSSEC、DoH/DoT

止まると本当に全部止まる: Dyn 事件、Facebook 事件

普段「URLを打つだけ」で当たり前のように動いているけど、その裏には人類の積み上げてきた工夫が詰まっている。

バックエンドエンジニアになるなら、「DNS が原因かも？」を最初に疑える嗅覚は必須スキル。本番が止まったとき、慌てずに dig で状況を確認し、TTL を見て、フルリゾルバを切り替えて、原因を絞り込める。それができれば一流。

逆に、DNS をブラックボックスのまま放置していると、いつか必ず痛い目に遭う。「自分のドメインの設定が間違っていて、お客さんからメールが届かなかった」「TTL を下げ忘れて引っ越しに丸1日かかった」「DNSSEC を有効にして自社ドメインを落とした」。全部、現役エンジニアが普通に経験する事故だ。

「インターネットは奇跡的に動いている」と言われる。その奇跡の一翼を、DNS は確かに担っている。

次の読み物

04_暗号とTLS.md をまだ生成していなければ、Claude Code に依頼:

バックエンドマスター/読み物/04_暗号とTLS.md を、
03_DNS.md と同じフォーマットで作って。
主題は「暗号と TLS - HTTPS の中身」。
共通鍵 / 公開鍵 / ハッシュ / 証明書 / 認証局 / TLS ハンドシェイク /
有名なTLS事件 (Heartbleed, DigiNotar) などを含めて。
トーンは「インターネットの裏方」シリーズの3本目として揃えて。
600-900行、絵文字なし、Callout は info / note / abstract / example。

バックエンドマスター

エクスプローラー

03_DNS

03. DNS の仕組み - インターネットの電話帳

はじめに: 「止まると全部止まる」やつ

第1章: なぜ DNS が必要だったのか

人間は数字を覚えられない

hosts.txt の時代

限界が来る

DNS の誕生（1983-1987）

第2章: ドメイン名の階層構造

「読む順番」は右から左

階層構造の全景

TLD の種類

com と co.jp の構造的な違い

第3章: DNS 名前解決の流れ

全体像

登場人物の整理

「再帰」と「反復」の違い

キャッシュが全てを救う

第4章: DNS レコードの種類

主要レコード一覧

A と AAAA

CNAME の罠

MX レコードとメール

TXT レコードと付随仕様

NS と SOA

PTR と逆引き

第5章: TTL の意味と運用

TTL とは

変更時のテクニック: TTL を一時的に短くする

第6章: ルート DNS サーバー13台の謎

「DNS には13台のルートサーバーがある」

Anycast: 同じ IP が世界中に

13台はどこにある？

第7章: DNS が攻撃される時

DNS キャッシュポイズニング

Kaminsky 攻撃 (2008)

DNSSEC

DoH と DoT

第8章: ドメインを取得するということ

4つの登場人物

お金の流れ

Whois とプライバシー保護

第9章: 有名な DNS 事件

2016 Dyn DDoS - 米国西海岸全滅事件

2021 Facebook BGP 事件

第10章: 「DNS で名前解決できない」あるあるデバッグ

現象1: 「IP で繋がるが、ドメインで繋がらない」

現象2: 「自分は繋がるけど、お客様からは繋がらない」

現象3: 「dig で引けるけど ping で繋がらない」

dig コマンドの読み方

よく使う dig オプション

第11章: 現代の DNS と未来

CDN と DNS

DNS-based Service Discovery

DNS over QUIC

章の問い (考えるための小さなトリガー)

まとめ: DNS が支えるインターネット

関連

次の読み物

グラフビュー

目次

バックリンク

`com` と `co.jp` の構造的な違い