ITインフラストラクチャ技術ガイド

第4章：名前解決とサービス発見

IPアドレスという数字の羅列を、人間が理解できる名前に変換するDNS。この一見単純な機能の背後には、インターネット規模での分散データベースという壮大な仕組みが存在している。なぜDNSは階層的な構造を採用したのか、なぜ単一の巨大なデータベースではいけなかったのか。

この設計選択を理解することで、分散システム設計の本質的な課題と解決手法が見えてくる。さらに、サイバー攻撃の標的となりやすいDNSのセキュリティ課題、クラウド時代に求められる動的サービス発見まで、名前解決システムは現代ネットワークの基盤技術として進化し続けている。

4.1 DNS階層構造の設計原理

分散データベースとしての本質

DNSは世界最大の分散データベースである。この事実を理解することが、DNS設計思想の出発点となる。単一のデータベースでインターネット上のすべてのホスト名を管理することは、技術的にも運用的にも不可能である。

階層化による責任分散

DNSの階層構造は、管理責任の分散を実現している：

ルートゾーン（.）
├─ .com（トップレベルドメイン）
│  ├─ example.com（セカンドレベルドメイン）
│  │  ├─ www.example.com
│  │  ├─ mail.example.com
│  │  └─ ftp.example.com
│  └─ google.com
└─ .jp
   ├─ co.jp
   │  └─ example.co.jp
   └─ ne.jp

各レベルでの責任分担：

  • ルート：トップレベルドメインの管理（13サーバー組織）
  • TLD：セカンドレベルドメインの管理（レジストリ）
  • 組織：自組織内のホスト名管理

分散の利点

  1. スケーラビリティ
    • 各レベルでの独立した管理
    • 負荷の自然な分散
    • 地理的分散による応答時間短縮
  2. 可用性
    • 単一障害点の排除
    • 部分的障害の局所化
    • 冗長化による信頼性向上
  3. 管理の自律性
    • 組織別の独立した運用
    • 更新手順の簡素化
    • 専門知識の活用

分散による課題

  1. 一貫性の確保
    • 複数サーバー間のデータ同期
    • 更新の伝播時間
    • 一時的な不整合の発生
  2. セキュリティの複雑化
    • 複数の信頼点の管理
    • エンドツーエンドの検証
    • 部分的な侵害の影響範囲

キャッシュ戦略とTTL設計の指針

DNSの性能は、効果的なキャッシュ戦略に大きく依存している。TTL（Time To Live）の設定は、性能とデータ鮮度のトレードオフを決定する重要な要素である。

キャッシュの階層構造

ユーザーアプリケーション
↓ (キャッシュ)
OS DNS リゾルバ
↓ (キャッシュ)
ローカル DNS サーバー（フルリゾルバ）
↓ (キャッシュ)
上位 DNS サーバー

TTL設定の考慮要素

  1. 変更頻度 
    静的レコード（Webサーバー等）：
A www.example.com. 86400 IN A 203.0.113.10
# TTL=86400秒（24時間）

動的レコード（CDN等）：
A cdn.example.com. 300 IN A 203.0.113.20  
# TTL=300秒（5分）
  2. 災害復旧時間 
    メインサイト障害時の切り替え：
TTL=300秒設定 → 最大5分で切り替え完了
TTL=3600秒設定 → 最大1時間で切り替え完了
  3. クエリ負荷 
    TTL短縮による影響：
TTL 86400秒 → 300秒（1/288に短縮）
DNS クエリ負荷：288倍に増加
権威サーバーへの負荷：大幅増加

最適化戦略

  1. レコード種別による差別化 
    A/AAAA レコード：3600-86400秒（安定性重視）
MX レコード：3600-21600秒（メール配送の安定性）
TXT レコード：300-3600秒（SPF/DKIM等の変更対応）
CNAME レコード：300-3600秒（柔軟性重視）
  2. 段階的TTL調整 
    変更予定の事前準備：
1週間前：TTL を 3600秒に短縮
1日前：TTL を 300秒に短縮
変更実施：新しいIPアドレスに更新
変更確認後：TTL を元の値に復旧
  3. プリフェッチング 
    TTL期限切れ前の自動更新：
期限切れ30%前：バックグラウンドで更新開始
期限切れ後：古いレコードで応答継続
更新完了後：新しいレコードに切り替え

4.2 DNS実装のセキュリティ課題

キャッシュポイズニングの原理と対策

DNSキャッシュポイズニングは、偽造されたDNS応答により、正しくない情報をキャッシュに保存させる攻撃手法である。この攻撃が成功すると、ユーザーを悪意のあるサイトに誘導することが可能となる。

攻撃の基本原理

正常なDNS解決：
1. クライアント → ローカルDNS：www.example.com のIPアドレス問い合わせ
2. ローカルDNS → 権威DNS：www.example.com のIPアドレス問い合わせ
3. 権威DNS → ローカルDNS：203.0.113.10 応答
4. ローカルDNS → クライアント：203.0.113.10 応答

攻撃シナリオ：
1. 攻撃者：ローカルDNSに大量の偽造問い合わせを送信
2. 攻撃者：偽造応答を大量送信（正しいTransaction IDを推測）
3. ローカルDNS：偽造応答を正当と判断してキャッシュに保存
4. 結果：ユーザーが悪意のあるサイトに誘導される

従来の脆弱性

  1. Transaction ID の予測可能性
    • 16ビット（65536通り）の識別子
    • 連番や時刻ベースの生成アルゴリズム
    • 総当たり攻撃による推測
  2. 送信元ポートの固定
    • 53番ポートからの問い合わせ
    • 応答の送信先ポートも予測可能
    • 偽造応答の精度向上

DNS Source Port Randomization

2008年のDan Kaminsky攻撃発覚後、DNSの実装は大幅に強化された：

改善前：
送信元ポート：53番固定
Transaction ID：16ビット（予測可能）
攻撃成功率：高

改善後：
送信元ポート：ランダム（16ビット追加エントロピー）
Transaction ID：真の乱数（16ビット）
攻撃成功率：32ビット（約43億分の1）に低下

現代的な対策技術

  1. 0x20エンコーディング 
    問い合わせ：www.ExAmPlE.CoM （大文字小文字をランダム化）
応答確認：同じ大文字小文字パターンでの応答を要求
追加エントロピー：ドメイン名の文字数分
  2. DNS Cookies（RFC 7873） 
    問い合わせ時：
www.example.com IN A
OPT: Cookie=クライアント_クッキー

応答時：
OPT: Cookie=クライアント_クッキー + サーバー_クッキー
   
検証：サーバークッキーによる正当性確認

DNSSEC：実装コストと効果の評価

DNSSEC（DNS Security Extensions）は、DNSに暗号学的検証機能を追加する技術である。理論的には完璧なセキュリティを提供するが、実装と運用の複雑性から普及が進んでいない。

DNSSECの動作原理

DNSSECは公開鍵暗号を使用したデジタル署名により、DNS応答の完整性を保証する：

DNSSEC レコード構成：
example.com.    86400 IN A    203.0.113.10  （通常のAレコード）
example.com.    86400 IN RRSIG A 7 2 86400... （Aレコードの署名）
example.com.    86400 IN DNSKEY 256 3 7...    （公開鍵）
example.com.    86400 IN DNSKEY 257 3 7...    （鍵署名鍵）
example.com.    86400 IN RRSIG DNSKEY 7 2...  （公開鍵の署名）

信頼の連鎖：

ルート（.）→ .com → example.com → www.example.com
各レベルで上位から署名により信頼性を保証

実装コストの詳細

  1. 設備投資 
    HSM（Hardware Security Module）：500万-2000万円
DNSSEC対応権威サーバー：既存設備の更新必要
監視・管理ツール：新規導入・設定
  2. 運用コスト 
    鍵管理作業：月40-80時間
署名更新作業：週10-20時間
障害対応：平均2-4時間/件（従来の2-3倍）
研修・教育：年100-200時間
  3. 性能影響 
    DNS応答サイズ：2-5倍に増加
権威サーバー負荷：CPU使用量20-50%増
ネットワーク帯域：30-80%増加

効果の定量的評価

  1. 防御できる攻撃
    • キャッシュポイズニング：完全防御
    • 中間者攻撃：DNS層での防御
    • DNSハイジャック：検出可能
  2. 防御できない攻撃
    • DDoS攻撃：影響軽減なし
    • アプリケーション層攻撃：守備範囲外
    • ソーシャルエンジニアリング：技術的対策外

普及の障壁

DNSSEC普及率（2024年）：
.com：約2%
.jp：約15%
.gov：約85%
企業全体：約5%

普及を阻む要因：
- 実装・運用の複雑性
- コストと効果のバランス
- 既存システムとの互換性
- 障害時の影響の大きさ

DoH/DoT：プライバシーとパフォーマンスのトレードオフ

DNS over HTTPS（DoH）とDNS over TLS（DoT）は、DNS通信の暗号化によりプライバシーを保護する技術である。しかし、この保護は性能と運用性とのトレードオフを伴う。

従来のDNSプライバシー課題

平文DNS通信の問題：
1. ISPによる通信監視
   - 訪問サイトの完全な記録
   - 行動パターンの分析
   - 商用利用の可能性

2. 中間者による盗聴
   - カフェ等の公共Wi-Fi
   - 悪意のあるホットスポット
   - 企業内ネットワーク監視

3. DNS情報の商用利用
   - 広告ターゲティング
   - 市場調査データ
   - 競合分析

DoH vs DoT の技術比較

要素 DoH DoT
暗号化プロトコル HTTPS/TLS TLS
通信ポート 443（HTTP） 853（専用）
ファイアウォール通過 容易 制限される場合あり
パフォーマンス HTTPオーバーヘッド 軽量
実装複雑性 高（HTTPスタック必要） 中（TLSのみ）
キャッシュ効果 HTTPキャッシュ活用可 DNS専用キャッシュ

パフォーマンス影響の定量化

通信オーバーヘッド比較：
平文DNS：約50-100バイト/クエリ
DoT：約150-200バイト/クエリ（TLSヘッダー）
DoH：約300-500バイト/クエリ（HTTPヘッダー込み）

レイテンシ影響：
平文DNS：ベースライン
DoT：+5-15ms（TLSハンドシェイク初回のみ）
DoH：+10-30ms（HTTPプロトコル処理）

接続確立コスト：
平文DNS：接続不要（UDP）
DoT：TLSハンドシェイク（2RTT）
DoH：TLS + HTTPハンドシェイク（3-4RTT）

企業環境での導入課題

  1. セキュリティポリシーとの競合 
    従来：企業DNSでの全通信監視
DoH/DoT：暗号化により監視困難
   
対策オプション：
- DoH/DoTの企業内禁止
- プロキシによる復号・監視
- ログベースの監視に移行
  2. トラブルシューティングの困難化 
    平文DNS：パケットキャプチャで詳細分析可能
DoH/DoT：暗号化により分析困難
   
必要な対策：
- ログレベルの向上
- アプリケーションレベルでの監視
- 新しいトラブルシューティング手法の確立

実装戦略

  1. 段階的導入 ``` フェーズ1：DoTの限定導入
    • 外部接続のみ
    • 特定用途（BYOD等）

    フェーズ2：DoHの検証

    • パフォーマンス測定
    • セキュリティ影響評価

    フェーズ3：全面展開

    • ポリシー整備
    • 監視体制確立 ```

4.3 内部DNSと外部DNSの分離設計

スプリットDNSの実装パターン

スプリットDNS（分割DNS）は、内部ネットワークと外部ネットワークで異なるDNS応答を返す技術である。セキュリティの向上、内部リソースの隠蔽、性能の最適化を実現する。

スプリットDNSの基本パターン

  1. 完全分離型 
    内部DNS（192.168.1.10）
├─ 内部ゾーン：example.local
│  ├─ server1.example.local → 192.168.1.100
│  └─ server2.example.local → 192.168.1.101
└─ 外部転送：8.8.8.8へフォワード

外部DNS（203.0.113.10）
└─ 外部ゾーン：example.com
   ├─ www.example.com → 203.0.113.20
   └─ mail.example.com → 203.0.113.21
  2. 同一ドメイン分離型 
    内部ビュー：example.com
├─ www.example.com → 192.168.1.100（内部サーバー）
├─ db.example.com → 192.168.1.200（内部のみ）
└─ mail.example.com → 192.168.1.150

外部ビュー：example.com  
├─ www.example.com → 203.0.113.20（DMZサーバー）
└─ mail.example.com → 203.0.113.21
  3. 階層分離型 
    外部：example.com（公開サービスのみ）
内部：
├─ example.com（外部と同じ+α）
├─ internal.example.com（部門別）
└─ dev.example.com（開発環境）

実装技術の選択

  1. BIND Views 
    acl internal {
    192.168.0.0/16;
    10.0.0.0/8;
};

view "internal" {
    match-clients { internal; };
    zone "example.com" {
        type master;
        file "/var/named/internal/example.com.zone";
    };
};

view "external" {
    match-clients { any; };
    zone "example.com" {
        type master;
        file "/var/named/external/example.com.zone";
    };
};
  2. 物理分離 
    内部DNS：192.168.1.10（内部ネットワークのみ）
外部DNS：203.0.113.10（DMZ配置）
   
利点：完全な分離、セキュリティ向上
欠点：管理コストの増大、複雑性

ビューによるアクセス制御

DNSビューは、クライアントのIPアドレスや特定の条件に基づいて、異なるDNS応答を提供する機能である。細粒度のアクセス制御と情報隠蔽を実現する。

ビュー設計の指針

  1. 地理的分離 
    acl asia-office {
    203.0.113.0/24;    # 東京オフィス
    198.51.100.0/24;   # シンガポールオフィス
};

acl america-office {
    192.0.2.0/24;      # ニューヨークオフィス
    100.64.0.0/24;     # ロサンゼルスオフィス
};

view "asia" {
    match-clients { asia-office; };
    zone "example.com" {
        type master;
        file "/var/named/asia/example.com.zone";
    };
};
  2. 役割ベース分離 
    acl management {
    192.168.100.0/24;  # 管理部門
};

acl development {
    192.168.200.0/24;  # 開発部門
};

view "mgmt" {
    match-clients { management; };
    # 全てのレコードにアクセス可能
};

view "dev" {
    match-clients { development; };
    # 開発関連レコードのみアクセス可能
};

セキュリティ考慮事項

  1. 情報漏洩の防止 
    外部からの内部情報問い合わせ：
nslookup db.internal.example.com 8.8.8.8
→ NXDOMAIN（存在しない）

内部からの同じ問い合わせ：
nslookup db.internal.example.com 192.168.1.10  
→ 192.168.1.200（正常応答）
  2. DNSトンネリングの対策 ``` 異常なクエリパターンの検出：
    • 異常に長いドメイン名
    • 大量のTXTレコード問い合わせ
    • 非標準的なレコードタイプ

    対策：

    • クエリレート制限
    • パターンマッチングによるブロック
    • ログ監視とアラート ```

4.4 動的ホスト管理の実装

DHCP：スコープ設計とフェイルオーバー

DHCP（Dynamic Host Configuration Protocol）は、ネットワーク設定の自動配布を実現する。適切なスコープ設計とフェイルオーバー機能により、大規模環境での安定したIPアドレス管理を実現する。

スコープ設計の原則

  1. 利用率の最適化 
    算出式：
必要アドレス数 = 同時接続予測 × 安全係数（1.2-1.5）
   
例：200台の同時接続予測
必要アドレス数 = 200 × 1.3 = 260台
推奨スコープ：/23（510台分）または/24（254台分）
  2. リース時間の調整 ``` 環境別の推奨設定：
    • オフィス（固定端末）：24-72時間
    • ゲストネットワーク：2-8時間
    • イベント会場：30分-2時間
    • 開発・テスト環境：1-4時間 ```
  3. 予約アドレスの管理 
    アドレス配分例（/24ネットワーク）：
192.168.1.1-192.168.1.50    : 静的IP（サーバー等）
192.168.1.51-192.168.1.100  : DHCP予約（プリンター等）
192.168.1.101-192.168.1.200 : DHCP動的プール
192.168.1.201-192.168.1.254 : 将来拡張用

フェイルオーバー実装

  1. アクティブ・パッシブ構成 
    プライマリ DHCP サーバー：
scope 192.168.1.0 mask 255.255.255.0
range 192.168.1.100 192.168.1.200
failover partner "backup-server"
   
セカンダリ DHCP サーバー：
同一スコープをスタンバイで保持
プライマリ障害時に自動的にサービス開始
  2. スプリットスコープ構成 
    サーバーA：192.168.1.100-192.168.1.150（80%）
サーバーB：192.168.1.151-192.168.1.200（20%）
   
正常時：各サーバーが個別範囲を担当
障害時：生存サーバーが全範囲をカバー

DHCP Snooping によるセキュリティ

L2スイッチでの DHCP Snooping 設定：
ip dhcp snooping
ip dhcp snooping vlan 10,20
ip dhcp snooping trust interface GigabitEthernet0/1  # 正規DHCPサーバー
ip dhcp snooping limit rate 10  # 1秒あたり10パケットまで

効果：
- 不正DHCPサーバーの排除
- DHCPスターベーション攻撃の防御  
- IP-MACアドレスバインディングテーブルの構築

DHCPリレーとVLAN設計の統合

大規模ネットワークでは、各VLANにDHCPサーバーを配置することは現実的ではない。DHCPリレー機能により、集中化されたDHCPサーバーから複数のVLANにサービスを提供する。

DHCPリレーの動作原理

DHCPディスカバリーフロー（VLAN間）：

1. クライアント（VLAN 10）→ ブロードキャスト：DHCP Discover
2. L3スイッチ：ブロードキャストをユニキャストに変換
3. L3スイッチ → DHCPサーバー：DHCP Discover（リレー情報付加）
4. DHCPサーバー：クライアントのVLAN情報を基にスコープ選択
5. DHCPサーバー → L3スイッチ：DHCP Offer
6. L3スイッチ → クライアント：DHCP Offer

VLAN別スコープ設計

DHCPサーバー設定例：

VLAN 10（営業部）：
subnet 192.168.10.0 netmask 255.255.255.0 {
  range 192.168.10.100 192.168.10.200;
  option routers 192.168.10.1;
  option domain-name-servers 192.168.1.10;
  option domain-name "sales.example.com";
  default-lease-time 86400;
}

VLAN 20（技術部）：
subnet 192.168.20.0 netmask 255.255.255.0 {
  range 192.168.20.100 192.168.20.200;
  option routers 192.168.20.1;
  option domain-name-servers 192.168.1.10;
  option domain-name "tech.example.com";
  default-lease-time 28800;  # 8時間（開発環境）
}

Option 82（Circuit ID）の活用

L3スイッチ設定：
ip dhcp relay information option
ip dhcp relay information policy keep

効果：
- VLAN IDやポート情報をDHCPパケットに追加
- DHCPサーバーでの詳細な制御が可能
- セキュリティポリシーの実装支援

Option 82 情報例：
Circuit ID: "vlan-10-port-gi0/1"  
Remote ID: "switch-01.example.com"

4.5 サービス発見の現代的アプローチ

mDNS/DNS-SDの適用範囲

マルチキャスト DNS（mDNS）とDNS Service Discovery（DNS-SD）は、ゼロコンフィグレーションネットワーキングを実現する技術である。特に小規模ネットワークやホームネットワークでの自動サービス発見に威力を発揮する。

mDNSの動作原理

従来のDNS：
クライアント → DNS サーバー → 権威サーバー → 応答

mDNS：
クライアント → マルチキャスト（224.0.0.251）→ 該当ホストが直接応答

例：
ping myserver.local
→ マルチキャストクエリ送信
→ myserver.localを持つホストが応答
→ 直接通信開始

DNS-SD による自動サービス発見

サービス広告例：
_http._tcp.local.     PTR  "My Web Server._http._tcp.local."
_http._tcp.local.     PTR  "Another Server._http._tcp.local."

"My Web Server._http._tcp.local."  SRV  0 0 80 server1.local.
"My Web Server._http._tcp.local."  TXT  "path=/admin"

クライアントの発見手順：
1. "PTR _http._tcp.local" クエリ送信
2. 利用可能なHTTPサービス一覧を受信
3. 特定サービスのSRVレコードでポート番号取得
4. TXTレコードで追加情報取得

適用範囲と制限

適用が効果的な環境：

  • ホームネットワーク（プリンター、NAS等）
  • 小規模オフィス（<100台）
  • 開発・テスト環境
  • IoTデバイス間通信

制限事項：

ネットワーク規模：
- マルチキャストトラフィックの増大
- ルーター越えでの制限（TTL=1）
- 大規模環境での性能問題

セキュリティ：
- 暗号化機能なし
- アクセス制御機能なし
- 情報漏洩の可能性

サービスメッシュとの統合

現代のマイクロサービスアーキテクチャでは、動的なサービス発見が不可欠である。サービスメッシュと組み合わせることで、企業レベルでの高度なサービス発見を実現する。

従来の課題

静的DNS設定の問題：
- サービスのスケールアウト時の手動更新
- 障害サービスへの自動切り替え困難
- ロードバランシングの制限

例：マイクロサービス環境
user-service.example.com → 192.168.1.100:8080
→ サービス追加時に手動でDNS更新が必要

サービスメッシュ統合の利点

  1. 動的サービス登録 
    Consul + Envoy の例：
   
サービス起動時：
curl -X PUT http://consul:8500/v1/agent/service/register \
  -d '{
    "ID": "user-service-1",
    "Name": "user-service", 
    "Port": 8080,
    "Check": {
      "HTTP": "http://localhost:8080/health",
      "Interval": "10s"
    }
  }'
   
DNS解決：
dig user-service.service.consul
→ 健全なインスタンスのIPアドレスを自動返却
  2. ヘルスチェック統合 ``` 自動的な健全性監視：
    • HTTPエンドポイントでの応答確認
    • TCPポートでの接続確認
    • カスタムスクリプトによる詳細チェック

    結果：

    • 不健全なサービスを自動的にDNS応答から除外
    • 自動フェイルオーバーの実現 ```
  3. 高度なルーティング制御 
    Istio での例：
   
重み付きルーティング：
user-service → 90% v1.0インスタンス
             → 10% v2.0インスタンス
   
地理的ルーティング：
us-east クライアント → us-east-1 サービス
us-west クライアント → us-west-1 サービス

実装パターン

  1. ハイブリッドアプローチ 
    外部DNS：従来通りの静的設定
internal.example.com → Consul DNS
   
内部サービス：動的サービス発見
user-service.service.consul
order-service.service.consul
  2. 段階的移行 
    フェーズ1：新規サービスのみサービスメッシュ対応
フェーズ2：既存サービスの段階的移行
フェーズ3：レガシーDNSからの完全移行

まとめ

名前解決システムは、単なるアドレス変換機能を超えて、現代ネットワークの基盤インフラストラクチャとして進化している。DNSの階層的分散設計は、インターネット規模でのスケーラビリティを実現する一方で、セキュリティとプライバシーという新たな課題を提起している。

DNSSEC、DoH/DoTといったセキュリティ技術は理論的には優秀だが、実装と運用のコストから普及が限定的である。この現実は、技術選択において完璧性よりも実用性が重視されることを示している。

一方、クラウドとマイクロサービスの普及により、動的サービス発見の重要性が急速に高まっている。mDNS/DNS-SDのような従来技術から、サービスメッシュとの統合まで、用途と規模に応じた適切な技術選択が求められる。

名前解決システムの設計において重要なのは、要求される機能レベルと運用可能性のバランスを取ることである。最先端の技術を追求するのではなく、組織の技術レベルと運用体制に適した段階的な改善戦略を立案することが、持続可能なシステム構築の鍵となる。

次章では、これらの基盤技術の上で動作するトランスポート層以上の実装技術を探る。TCP/UDPの選択基準、ロードバランサーの設計、TLS実装における現実的課題を詳細に解析する。

Edit this page on GitHub