Day 6: DNS(ドメインネームシステム)
今日学ぶこと
- DNSの役割と重要性
- DNSの階層構造(ルート、TLD、権威、リカーシブリゾルバ)
- DNSレコードの種類(A、AAAA、CNAME、MX、NS、TXT、SOA、PTR)
- DNS名前解決の流れ(再帰クエリと反復クエリ)
- DNSキャッシュとTTL
- digとnslookupコマンド
- DNSセキュリティ(DNSSEC、DoH/DoT)
DNSとは何か
DNS(Domain Name System) は、人間が読みやすいドメイン名(例:www.example.com)をコンピュータが理解できるIPアドレス(例:93.184.216.34)に変換するシステムです。インターネットの「電話帳」とも呼ばれます。
flowchart LR
subgraph Human["人間が入力"]
A["www.example.com"]
end
subgraph DNS["DNS"]
B["名前解決"]
end
subgraph Machine["コンピュータが使用"]
C["93.184.216.34"]
end
A --> B --> C
style Human fill:#3b82f6,color:#fff
style DNS fill:#8b5cf6,color:#fff
style Machine fill:#22c55e,color:#fff
なぜDNSが必要なのか
| 観点 | IPアドレス直接 | DNS使用 |
|---|---|---|
| 覚えやすさ | 93.184.216.34 は覚えにくい |
example.com は覚えやすい |
| サーバー変更 | IPが変わると全員に通知が必要 | DNS側で更新すれば自動反映 |
| 負荷分散 | 1つのIPに固定 | 複数IPに振り分け可能 |
| 柔軟性 | 低い | 高い |
DNSがなければ、すべてのWebサイトにIPアドレスでアクセスする必要があり、インターネットの利用は非常に不便になります。
DNSの階層構造
DNSは分散型のデータベースであり、階層的な構造を持っています。
flowchart TB
subgraph Root["ルートDNSサーバー"]
R[".(ルート)"]
end
subgraph TLD["TLDサーバー"]
T1[".com"]
T2[".jp"]
T3[".org"]
end
subgraph Auth["権威DNSサーバー"]
A1["example.com"]
A2["example.jp"]
A3["example.org"]
end
R --> T1
R --> T2
R --> T3
T1 --> A1
T2 --> A2
T3 --> A3
style Root fill:#ef4444,color:#fff
style TLD fill:#f59e0b,color:#fff
style Auth fill:#22c55e,color:#fff
各階層の役割
ルートDNSサーバー
DNSの最上位に位置するサーバーです。世界に13のルートサーバー群(A~M)があり、エニーキャストにより実際には数百台のサーバーが稼働しています。TLDサーバーの場所を知っています。
TLD(Top-Level Domain)サーバー
.com、.jp、.org などのトップレベルドメインを管理するサーバーです。
| TLDの種類 | 例 | 説明 |
|---|---|---|
| gTLD(汎用) | .com, .org, .net | 用途を問わない |
| ccTLD(国別) | .jp, .uk, .de | 国・地域に紐づく |
| sTLD(スポンサー付き) | .edu, .gov, .mil | 特定組織向け |
| 新gTLD | .app, .dev, .tokyo | 2012年以降に追加 |
権威DNSサーバー
特定のドメインのDNSレコードを実際に保持しているサーバーです。example.com のIPアドレスなどの最終的な回答を返します。
リカーシブリゾルバ(キャッシュDNSサーバー)
クライアントからのクエリを受け取り、必要に応じて上位のサーバーに問い合わせを行うサーバーです。ISPやGoogle Public DNS(8.8.8.8)、Cloudflare DNS(1.1.1.1)などがこれにあたります。
DNSレコードの種類
DNSサーバーには、さまざまな種類のレコードが格納されています。
| レコード | 正式名称 | 内容 | 例 |
|---|---|---|---|
| A | Address | ドメイン → IPv4アドレス | example.com → 93.184.216.34 |
| AAAA | Quad-A | ドメイン → IPv6アドレス | example.com → 2606:2800:220:1:... |
| CNAME | Canonical Name | ドメインの別名 | www.example.com → example.com |
| MX | Mail Exchange | メールサーバー指定 | example.com → mail.example.com |
| NS | Name Server | 権威DNSサーバー指定 | example.com → ns1.example.com |
| TXT | Text | テキスト情報(SPF等) | "v=spf1 include:..." |
| SOA | Start of Authority | ゾーンの管理情報 | シリアル番号、TTL等 |
| PTR | Pointer | IPアドレス → ドメイン(逆引き) | 34.216.184.93 → example.com |
主要レコードの詳細
Aレコードは最も基本的なレコードで、ドメイン名をIPv4アドレスにマッピングします。
example.com. IN A 93.184.216.34
CNAMEレコードは、あるドメイン名を別のドメイン名のエイリアス(別名)として設定します。
www.example.com. IN CNAME example.com.
blog.example.com. IN CNAME example.com.
MXレコードは、メールの配送先を指定します。優先度(数値が小さいほど高い)を持ちます。
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
TXTレコードは、テキスト情報を格納します。SPF(メール送信元認証)やドメイン所有権の確認などに使われます。
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
DNS名前解決の流れ
ブラウザでURLを入力してからWebページが表示されるまでの間に、DNS名前解決が行われています。
再帰クエリと反復クエリ
sequenceDiagram
participant Client as クライアント
participant Resolver as リカーシブリゾルバ
participant Root as ルートサーバー
participant TLD as TLDサーバー
participant Auth as 権威サーバー
Client->>Resolver: www.example.com は?(再帰クエリ)
Note over Resolver: キャッシュ確認 → なし
Resolver->>Root: www.example.com は?(反復クエリ)
Root-->>Resolver: .com のTLDサーバーはこちら
Resolver->>TLD: www.example.com は?(反復クエリ)
TLD-->>Resolver: example.com の権威サーバーはこちら
Resolver->>Auth: www.example.com は?(反復クエリ)
Auth-->>Resolver: 93.184.216.34 です
Note over Resolver: 結果をキャッシュ
Resolver-->>Client: 93.184.216.34 です
| クエリの種類 | 動作 | 使用場面 |
|---|---|---|
| 再帰クエリ | リゾルバが最終回答を返すまで責任を持つ | クライアント → リゾルバ |
| 反復クエリ | 次の問い合わせ先を教えて段階的に解決 | リゾルバ → 各DNSサーバー |
名前解決の全体の流れ
- ブラウザがローカルキャッシュを確認
- OSのDNSキャッシュを確認
- hostsファイルを確認
- リカーシブリゾルバに問い合わせ(再帰クエリ)
- リゾルバがキャッシュを確認
- キャッシュになければ、ルート → TLD → 権威の順に問い合わせ(反復クエリ)
- 結果をキャッシュして返答
DNSキャッシュとTTL
TTL(Time To Live)
TTLは、DNSレコードがキャッシュに保持される時間(秒)です。
example.com. 3600 IN A 93.184.216.34
^^^^
TTL = 3600秒(1時間)
| TTL設定 | 秒数 | メリット | デメリット |
|---|---|---|---|
| 短い(60秒) | 60 | 変更が素早く反映 | DNSクエリが増加 |
| 中程度(1時間) | 3600 | バランスが良い | 変更反映に最大1時間 |
| 長い(24時間) | 86400 | DNSクエリ減少 | 変更反映が遅い |
キャッシュの階層
flowchart TB
subgraph Cache["DNSキャッシュの階層"]
A["ブラウザキャッシュ"]
B["OSキャッシュ"]
C["ルーターキャッシュ"]
D["ISPのリゾルバキャッシュ"]
end
A -->|miss| B -->|miss| C -->|miss| D
style Cache fill:#3b82f6,color:#fff
キャッシュを利用することで、DNSの問い合わせ回数が削減され、名前解決が高速化されます。
digとnslookupコマンド
nslookup
nslookupは、DNS問い合わせを行う基本的なコマンドです。
# Basic A record lookup
nslookup example.com
# Specify record type
nslookup -type=MX example.com
# Use a specific DNS server
nslookup example.com 8.8.8.8
出力例:
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: example.com
Address: 93.184.216.34
dig
dig(Domain Information Groper)は、より詳細なDNS情報を取得できるコマンドです。
# Basic query
dig example.com
# Query specific record type
dig example.com MX
# Short output format
dig +short example.com
# Trace the full resolution path
dig +trace example.com
# Query a specific DNS server
dig @8.8.8.8 example.com
# Reverse DNS lookup
dig -x 93.184.216.34
digの出力の読み方
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 3600 IN A 93.184.216.34
;; AUTHORITY SECTION:
example.com. 86400 IN NS a.iana-servers.net.
;; Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
| セクション | 内容 |
|---|---|
| QUESTION | 問い合わせた内容 |
| ANSWER | 回答(IPアドレス等) |
| AUTHORITY | 権威サーバーの情報 |
| ADDITIONAL | 追加情報 |
| Query time | 応答にかかった時間 |
DNSセキュリティ
DNSの脆弱性
従来のDNSには、いくつかのセキュリティ上の問題があります。
flowchart TB
subgraph Threats["DNSの脅威"]
A["DNSスプーフィング<br/>偽の応答を返す"]
B["DNSキャッシュポイズニング<br/>キャッシュに偽情報を注入"]
C["DNS増幅攻撃<br/>DDoSに悪用"]
D["盗聴<br/>クエリ内容の傍受"]
end
style Threats fill:#ef4444,color:#fff
DNSSEC(DNS Security Extensions)
DNSSECは、DNS応答にデジタル署名を追加することで、応答の改ざんを検知する仕組みです。
| 要素 | 説明 |
|---|---|
| RRSIG | リソースレコードのデジタル署名 |
| DNSKEY | 署名検証に使う公開鍵 |
| DS | 子ゾーンの鍵のハッシュ(信頼の連鎖) |
| NSEC/NSEC3 | レコード不存在の証明 |
flowchart TB
subgraph DNSSEC["DNSSECの信頼の連鎖"]
Root["ルートゾーン<br/>トラストアンカー"]
TLD[".com ゾーン<br/>DS + DNSKEY"]
Domain["example.com ゾーン<br/>DS + DNSKEY"]
Record["Aレコード<br/>RRSIG で署名"]
end
Root -->|DS| TLD -->|DS| Domain -->|RRSIG| Record
style DNSSEC fill:#22c55e,color:#fff
DNS over HTTPS(DoH)とDNS over TLS(DoT)
従来のDNSクエリは平文で送信されるため、盗聴のリスクがあります。DoHとDoTは、DNSクエリを暗号化する技術です。
| 項目 | 従来のDNS | DoT | DoH |
|---|---|---|---|
| ポート | 53(UDP/TCP) | 853(TCP) | 443(TCP) |
| 暗号化 | なし | TLS | HTTPS |
| ブロック検知 | 容易 | 可能(専用ポート) | 困難(HTTPS混在) |
| 対応サービス | 全DNS | Cloudflare, Google等 | Cloudflare, Google等 |
まとめ
今日学んだことの整理
| トピック | キーポイント |
|---|---|
| DNSの役割 | ドメイン名をIPアドレスに変換する「電話帳」 |
| 階層構造 | ルート → TLD → 権威サーバーの分散構造 |
| レコード種類 | A、AAAA、CNAME、MX、NS、TXT、SOA、PTR |
| 名前解決 | 再帰クエリ(クライアント→リゾルバ)と反復クエリ(リゾルバ→各サーバー) |
| キャッシュとTTL | TTLで保持期間を制御、複数階層でキャッシュ |
| コマンド | dig(詳細)とnslookup(基本) |
| セキュリティ | DNSSEC(改ざん検知)、DoH/DoT(暗号化) |
重要ポイント
- DNSはインターネットの基盤:ほぼすべての通信がDNSの名前解決から始まる
- 階層的で分散的:単一障害点を避け、スケーラブルな設計
- キャッシュが性能の鍵:TTLの設定は運用面で重要な判断
- セキュリティの進化:DNSSEC、DoH、DoTにより安全性が向上
練習問題
基礎レベル
- DNSの主な役割を説明し、なぜIPアドレスではなくドメイン名を使うのか理由を3つ挙げてください。
- 以下のDNSレコードの種類と用途を答えてください:A、CNAME、MX、TXT
- 再帰クエリと反復クエリの違いを説明してください。
中級レベル
dig +trace example.comの出力を読み、名前解決の各ステップで何が起きているかを説明してください。- TTLを60秒に設定した場合と86400秒に設定した場合のメリット・デメリットを比較してください。
- CNAMEレコードとAレコードの使い分けについて、CDNを利用する場合の例を挙げて説明してください。
上級レベル
- DNSSECの信頼の連鎖(Chain of Trust)の仕組みを、ルートゾーンから末端のレコードまで説明してください。
- DNS over HTTPSがネットワーク管理者にとって問題となる理由と、その対策を議論してください。
- 実際のドメイン(例:
google.com)について、digコマンドを使ってA、MX、NS、TXTレコードをすべて調べ、その結果を分析してください。
参考リンク
- RFC 1035 - Domain Names (Implementation and Specification)
- Cloudflare - What is DNS?
- Google Public DNS
- DNSSEC - How It Works
次回予告
Day 7: HTTPとWebの仕組み では、Webブラウジングの裏側で動いているHTTPプロトコルを学びます。HTTPメソッド、ステータスコード、ヘッダーの役割を理解し、HTTP/1.1からHTTP/3までの進化を追います。