DNS Deep Dive — Resolution、Caching、DNSSEC、DoH/DoT、Anycast、1.1.1.1 内部完全解説 (2025)

TL;DR

DNS は階層的分散 KV ストア。ドメイン (example.com) から IP (93.184.216.34) へのマッピングを担うが、実際には遥かに多様な Record 種別を扱う。
4 階層の参加者: Stub Resolver (クライアント OS) → Recursive Resolver (ISP/Cloudflare) → Root/TLD/Authoritative Server。
Recursive と Iterative: クライアントは通常 Recursive だけ行い、Recursive Resolver が Root から Iterative クエリを代行。
「13 個の Root Server」は誤解。13 個の IP アドレスだが、各 IP が BGP Anycast で世界数百箇所に分散。
TTL とキャッシュ: 各 Record に有効期間。長すぎれば変更反映が遅く、短すぎれば DNS トラフィック急増。
DNSSEC: Record に署名。DNSKEY → RRSIG → DS → 親 DNSKEY → Root DNSKEY の信頼チェーン。複雑で採用率は 30% 程度。
DoH / DoT: ISP の盗聴・改ざんを防ぐ暗号化。2020 年代の主流。
公共 Resolver: Cloudflare 1.1.1.1 (Knot Resolver)、Google 8.8.8.8、OpenDNS、Quad9。
CoreDNS: Kubernetes のデフォルト DNS。Go 製プラグインベース。

1. なぜ DNS が必要か

DNS 以前は SRI-NIC が単一の HOSTS.TXT を配布し、全ホストが毎日ダウンロードしていた。数万台規模で破綻 — 更新の嵐、名前衝突、ネットワーク分断による不整合。

Paul Mockapetris が RFC 882/883 (1983) で DNS を設計。階層化、委任、キャッシュ、UDP ベースが核心。BIND (1984) が最初の実装。40 年経った今も同じ骨格で動く。

2025 年のスケール:

世界の 1 日クエリ数: 約 10 兆。
登録ドメイン: 3.5 億。
TLD: 1,500 以上。
Cloudflare 1.1.1.1: 1 日 1 兆クエリ。
Google 8.8.8.8: 1 日 3 兆クエリ。

中央 DB なしで、分散・キャッシュ・委任のみで回っている。

2. ネームスペース構造

2.1 ツリー

DNS は逆さまのツリー。右から左に Root へ向かって読む:

                    . (root)
                   /   |   \
                com   org   uk    (TLD)
                /      |     \
           example    wikipedia   co
           /  |  \               /
         www  api mail      google    (2LD)

www.google.co.uk. は末尾のドットで Root を示す。

2.2 Zone と委任

Zone は管理単位。Root Zone (".")、.com (Verisign 管理)、example.com (オーナー管理) など。Zone 内では Authoritative Name Server が真実の源。

委任は NS Record で表現:

example.com.   IN   NS   ns1.example.com.
example.com.   IN   NS   ns2.example.com.

2.3 Glue Record

循環依存: ns1.example.com の IP を知るには example.com に問い合わせたいが、そのためには ns1.example.com の IP が必要。Glue Record が解決。

example.com.     IN   NS   ns1.example.com.
ns1.example.com. IN   A    192.0.2.1     ← glue

この A Record は親の .com Zone に置かれる。

3. 参加者

3.1 Stub Resolver

OS レベルのコンポーネント。/etc/resolv.conf の Resolver にクエリを送り、IP を返す。

cat /etc/resolv.conf
nameserver 1.1.1.1
nameserver 8.8.8.8

3.2 Recursive Resolver

ISP または公共サービス (1.1.1.1、8.8.8.8)。キャッシュを確認し、ミスなら Iterative に Root から辿り、結果をキャッシュして返す。

3.3 Root Server

最上位。Zone "."。TLD Server のリストのみ保有。

「13 個の Root Server」とは 13 個のレター (A-M)、各々 1 つの IP、ただし各 IP が BGP Anycast で数百箇所に分散。a.root-servers.net (198.41.0.4) は 60 箇所以上から広告される。総インスタンス数は 1,900 以上。13 の上限は Priming Query の UDP 512 バイト制約に由来。

3.4 TLD Server

.com (Verisign)、.org (PIR)、.uk (Nominet)、.kr (KISA)。2LD の NS 情報と Glue のみ保持。

3.5 Authoritative Server

実データを持つ。Route 53、Cloud DNS、Cloudflare DNS、NS1、セルフホストの BIND/Knot/PowerDNS。キャッシュしない — 自身の Zone データのみ応答。

4. Resolution Process

4.1 例: `www.example.com` の解決

Step 1: アプリが getaddrinfo("www.example.com") を呼ぶ。

Step 2: Stub Resolver が 1.1.1.1 に UDP クエリ送信:

UDP、port 53
Query: www.example.com, type=A, class=IN, id=0x1234, RD=1

RD (Recursion Desired) = 1。

Step 3: Recursive Resolver がキャッシュ確認。ミス時は Iterative:

3.1 Root:

1.1.1.1 → a.root-servers.net (198.41.0.4)
Response:
  AUTHORITY:  com. IN NS a.gtld-servers.net.
  ADDITIONAL: a.gtld-servers.net. IN A 192.5.6.30

3.2 TLD:

1.1.1.1 → a.gtld-servers.net
Response:
  AUTHORITY:  example.com. IN NS a.iana-servers.net.
  ADDITIONAL: a.iana-servers.net. IN A 199.43.135.53

3.3 Authoritative:

1.1.1.1 → a.iana-servers.net
Response:
  ANSWER: www.example.com. IN A 93.184.216.34

Step 4: Recursive Resolver がキャッシュし Stub に返す。

Step 5: アプリが connect(93.184.216.34:80)。

4.2 キャッシュの威力

90% 以上のクエリは Recursive Resolver のキャッシュヒット。
7% は 1-2 Hop (.com は通常キャッシュ済み)。
3% 未満が Root まで Full Iterative。

1 日 10 兆クエリでも Root Server は秒数万クエリで済む。

5. DNS メッセージ形式

5.1 ヘッダ

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      ID                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       QDCOUNT / ANCOUNT / NSCOUNT / ARCOUNT                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ID: 16 bit ランダム。
QR/AA/TC/RD/RA: Query/Response、Authoritative、Truncated、Recursion。
RCODE: 0=NOERROR、2=SERVFAIL、3=NXDOMAIN、5=REFUSED。

Section は Question、Answer、Authority、Additional。

5.2 EDNS(0)

基本 DNS は UDP 512 バイト制限。EDNS(0) (RFC 6891) は OPT Pseudo-RR で 4096 バイトペイロードと DNSSEC 対応 (DO bit) を広告。UDP Fragment が Firewall で落とされる問題が運用上よく発生。

6. Record 種別

A: IPv4。example.com. IN A 93.184.216.34 AAAA: IPv6。 CNAME: エイリアス。同名で他 Record と共存不可。 NS: Zone を管理する Name Server。 SOA: Zone メタデータ (Serial、Refresh、Retry、Expire、Minimum TTL)。 MX: メールサーバと優先度。 TXT: 自由テキスト — SPF、DKIM、所有証明。 SRV: Service 所在地 (Port 含む)。 PTR: IP から名前への逆引き。 CAA: 証明書発行可能な CA の制限。

DNSSEC 型: DNSKEY (公開鍵)、RRSIG (署名)、DS (親 Zone のハッシュ)、NSEC / NSEC3 (Authenticated Denial)。

HTTPS / SVCB (2020 年代): HTTP/3 接続ヒント。

example.com.  IN  HTTPS  1  .  alpn="h3,h2" port="443"

7. TTL とキャッシュ

各 Record に有効秒数:

www.example.com.  300  IN  A  93.184.216.34

トレードオフ

短い TTL (60 秒): 変更反映早い、Resolver 負荷大。 長い TTL (86400 秒): 負荷軽い、反映が 1 日。

典型値:

A Record (Web): 300-3600 秒。
MX: 3600-86400 秒。
NS: 172800 秒。
CDN トラフィック管理: 30-60 秒。

Negative Caching: NXDOMAIN もキャッシュ。SOA minimum で制御。

デプロイ時の罠

デプロイ当日に TTL を下げても遅い — 古い TTL のキャッシュがまだ残っている。正しい順序: デプロイの 2 日前に TTL 短縮 → デプロイ当日 IP 変更 → 60 秒で反映。

8. DNSSEC

8.1 問題

プレーン DNS は検証なし。2008 年 Dan Kaminsky が Cache Poisoning 攻撃を発表 — 16 bit ID を推測して偽応答を注入。DNSSEC は Record に電子署名を付与。

8.2 概念

example.com.  IN  A     93.184.216.34
example.com.  IN  RRSIG A  <example.com ZSK で署名>

RRSIG は ZSK (Zone Signing Key) で生成。ZSK は DNSKEY Record として公開。DNSKEY 自体は KSK (Key Signing Key) で署名。KSK のハッシュは親 Zone の DS Record に置かれる。

8.3 信頼チェーン

Root KSK (Trust Anchor — 手動配布)
  ↓ Root ZSK に署名
  ↓ .com DS Record に署名
  ↓ .com KSK を検証
  ↓ .com ZSK に署名
  ↓ example.com DS に署名
  ↓ example.com KSK 検証
  ↓ example.com ZSK に署名
  ↓ www.example.com A Record に署名

8.4 NSEC / NSEC3

「このドメインは存在しない」を改ざん防止で証明。

NSEC: 「foo.example.com と qux.example.com の間には名前がない」を提示。Zone Walking (名前の列挙) が可能になりプライバシー漏洩。

NSEC3: 名前をハッシュ化して列挙を困難に。

8.5 なぜ 30% 止まりか

運用の複雑さ: 鍵管理、署名失効、Rollover。
署名失効 = ドメイン完全停止。
署名検証の CPU コスト、応答サイズ増加。
UDP Fragmentation による Firewall 問題。
DDoS Amplification リスク。

8.6 2018 年 Root KSK Rollover

史上初の Root KSK 交換。OS 更新で自動追従したが、古いシステムは DNSSEC 全失敗 → インターネット切断。次回は 5 年周期で予定。

9. DoH / DoT

9.1 問題

プレーン DNS は平文 UDP — ISP が記録可、WiFi 盗聴可、国家検閲可、中間者偽造可。

9.2 DNS over TLS (DoT、RFC 7858)

Port 853 で TLS に包んで DNS 送信。識別しやすくフィルタリング可能。Android 9+ Private DNS が DoT 利用。

9.3 DNS over HTTPS (DoH、RFC 8484)

POST https://cloudflare-dns.com/dns-query
Content-Type: application/dns-message

Port 443 で HTTPS に擬装 — 通常の Web トラフィックと区別不能、検閲極めて困難。Firefox はデフォルト有効、Chrome と Windows 10 22H2+ も対応。

9.4 論争

賛成: プライバシー向上、検閲回避。反対: 企業ネットワークが DNS 制御不能 (マルウェアブロック、ペアレンタルコントロール)。

9.5 ODoH (Oblivious DoH)

プロキシ層を挟み Resolver にクライアント IP を見せない。Cloudflare と Apple が初期実装。

10. 1.1.1.1 内部

10.1 アーキテクチャ

Cloudflare 1.1.1.1 は世界 300 以上の PoP に配備。IP 1.1.1.1 を全 PoP が BGP Anycast で広告、BGP 経路で最寄りへルーティング。

10.2 Knot Resolver

チェコ NIC Labs 開発の Knot Resolver を大幅改造して使用。モジュール式 (Lua 拡張)、マルチコアスケール、DNSSEC 検証デフォルト。Cloudflare は DoH/DoT フロントエンド、DDoS 防御、最小ログに加え 1.1.1.2 (マルウェアブロック)、1.1.1.3 (マルウェア + アダルト) を提供。

10.3 プライバシー

クエリログは 24 時間で削除、個人識別情報なし、KPMG 等第三者監査。

10.4 8.8.8.8 (Google)

Google 独自実装 (非 OSS)、グローバル Anycast、ECS (EDNS Client Subnet) 対応で CDN のジオルーティングを最適化、DoH/DoT 対応。

10.5 Quad9

9.9.9.9 — スイス非営利。マルウェアドメインをデフォルトブロック、GDPR 準拠、DNSSEC 検証。

11. CoreDNS — Kubernetes の DNS

11.1 なぜ必要か

Pod が Service を名前解決:

curl http://my-service.default.svc.cluster.local

11.2 構造

Go 製、プラグインアーキテクチャ。Corefile:

.:53 {
    errors
    health
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
    }
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

11.3 Service Discovery

Service 作成時に自動で A Record を生成。my-service.default.svc.cluster.local. IN A 10.96.0.42。/etc/resolv.conf の search で短縮名も利用可。

11.4 Headless Service

ClusterIP なし — DNS が全 Pod IP を返す。StatefulSet でよく使う。

11.5 NodeLocal DNSCache

各 Node に CoreDNS ローカルキャッシュを配置。Pod は 127.0.0.1:53 を参照。大規模クラスタ (数千 Node) では必須。

12. DNS ベースロードバランシング

Round Robin DNS: 複数の A Record。Resolver がランダム選択。単純だがキャッシュの影響で厳密な分散は不可。

Geo DNS: ユーザ位置で応答を変える。Route 53 GeoDNS、Cloudflare Load Balancing、NS1。ECS (EDNS Client Subnet) で Resolver がユーザのサブネットを Authoritative に伝達することで精度向上。

Health-Check DNS: プロバイダが定期ヘルスチェックで失敗サーバを自動除外。短 TTL で Fail-over。

Weighted Routing: カナリアデプロイで新バージョンに 5% だけ送り段階的増加。

13. セキュリティ脅威

13.1 Cache Poisoning

緩和策: Source Port Randomization、DNSSEC、0x20 Encoding (クエリ名の大小ランダム化)。

13.2 Amplification 攻撃

小さなクエリで大きな応答を引き出し (DNSSEC で 4096 バイト可) 被害者に向けて 70 倍増幅。緩和: Open Resolver 撲滅、BCP38 (Ingress Filtering)、Response Rate Limiting。

13.3 DNS Hijacking

ISP の NXDOMAIN 書き換え、マルウェアによる /etc/hosts や Resolver 改変、国家検閲 (Great Firewall)。防御: DoH/DoT、DNSSEC、VPN。

13.4 DGA (Domain Generation Algorithm)

マルウェアがアルゴリズムで毎日新ドメインを生成し C&C と通信。防御: クエリ名エントロピー分析。

14. 実務デバッグ

14.1 dig

dig example.com
dig example.com MX
dig @1.1.1.1 example.com
dig +trace example.com
dig +dnssec example.com
dig +short example.com

+trace は Root からの Iterative を再現。どの段階で壊れたか特定できる。

14.2 よくある問題

「DNS 変更が反映されない」: 旧 TTL を確認。ローカルキャッシュを Flush (sudo killall -HUP mDNSResponder、ipconfig /flushdns)。Authoritative に直接問い合わせ。

「DNSSEC エラー」: dig +dnssec +cd で検証をバイパス。DNSViz.net で Chain 確認。署名失効が頻出。

「断続的 Timeout」: EDNS Fragmentation の可能性。+noedns でテスト。

15. 最新トレンド (2024-2025)

DoH デフォルト化: 主要ブラウザ・OS。
SVCB/HTTPS Record: DNS で HTTP/3 ヒント。
ECH (Encrypted Client Hello): TLS の SNI も暗号化、公開鍵を DNS SVCB で配布。
TLD 増加と IDN: .dev、.aws、한국.kr など。
DNS Abuse 対応: ICANN が Registrar 責任を強化。

16. 学習リソース

書籍: "DNS and BIND" (Albitz & Liu)、"Pro DNS and BIND 10"、"Managing Mission-Critical Domains"。 RFC: 1034/1035 (基本)、4033-4035 (DNSSEC)、6891 (EDNS0)、7858 (DoT)、8484 (DoH)。 サイト: ICANN、IANA Root Zone、DNS-OARC。 ツール: dig、drill、kdig、DNSViz、Wireshark。

17. クイズ

Q1. 「13 個の Root Server」が誤解である理由は?

A. 正確には 13 個の IP アドレス。各 IP が BGP Anycast で世界 1,900 以上のインスタンスから応答している。13 という数字は元々 Priming Query を UDP 512 バイトに収める制約に由来し、物理台数ではない。

Q2. Recursive と Iterative の違いは?

A. Recursive: 「答えまで全部見つけて」とクライアントが依頼。Iterative: 「知っていることだけ答えて、残りは自分で辿る」。Stub が Recursive Resolver に Recursive を送り、Recursive Resolver は上位サーバに Iterative を送る。

Q3. CNAME が同名の他 Record と共存できない理由は?

A. CNAME は「別名」。同名に A Record も存在すると、どちらに従うか解決不能になる。RFC 1034 で明示禁止。Zone Apex には SOA/NS が必要なので Apex CNAME は不可。Route 53 の ALIAS や CDN の Flatten が回避策。

Q4. DNSSEC 普及が 30% で止まる最大要因は?

A. 運用の複雑さと失敗時の致命性。鍵管理、署名失効、Rollover の負担が大きく、署名が切れるとドメインが解決不能になる。プレーン DNS は設定ミスでも部分的に動くが DNSSEC は動かない。「リスク大、メリット不明瞭」の構図。

Q5. DoT と DoH の主な違いは?

A. DoT は専用 Port 853、識別容易でネットワーク管理しやすい。DoH は Port 443 で HTTPS に擬装、通常 Web トラフィックと区別不能で検閲困難。プライバシー強度は DoH が上、運用管理性は DoT が上。

Q6. デプロイの 2 日前に TTL を短縮する理由は?

A. TTL 短縮という変更自体が旧 TTL キャッシュ期限後にしか Resolver に伝わらない。2 日前に下げれば、当日までに全キャッシュが新 TTL に置き換わり、IP 変更が 60 秒で反映される。

Q7. DNS Amplification 攻撃の仕組みは?

A. 攻撃者が被害者 IP を詐称した小さなクエリを Open Resolver に送信。Resolver は大きな応答 (DNSSEC で 4096 バイト) を被害者宛に送信。56 バイト → 4000 バイトで 70 倍増幅。防御: Open Resolver 廃止、BCP38 Ingress Filtering、Response Rate Limiting。

"BGP ルーティング Deep Dive" — DNS Anycast の基盤となる BGP。
"TLS/SSL Deep Dive" — DoT/DoH が使う TLS と ECH。
"CDN & Edge Caching Strategies" — DNS ベース CDN ルーティング。
"HTTP/3 & QUIC Deep Dive" — HTTPS Record が示唆する h3。