DNS はインターネット通信の「住所録」の役割を持ち、企業ネットワークでも Web サービス、メール、API、社内システムなど、あらゆる通信の基盤となる重要コンポーネントです。DNS が停止するとサービスは即時停止し、業務が完全に麻痺するケースも少なくありません。
本記事では、以下の点を実務レベルで理解し、設計に活かせる内容として解説します。
- DNS 障害が発生する典型的な原因
- 企業における DNS 冗長化設計
- プライマリ／セカンダリの役割と注意点
- キャッシュ DNS（リゾルバ）の最適設計
- TTL 設計とフェイルオーバーの考え方
- クラウド DNS（Route53・Azure DNS）を使った多重化構成
DNS の冗長化・最適化は一度理解しておくと、ネットワーク設計・クラウド構築・オンプレ運用のすべてで応用できます。
1. DNS 障害の典型的な原因と企業における影響
DNS 障害はさまざまな要因で発生しますが、代表的なものは次の通りです。
1-1. ネームサーバ（Authoritative DNS）の単独運用
小規模環境でありがちな構成が「プライマリ DNS 1 台のみ」というものです。 この場合、OS 障害、ネットワーク断、メンテ中の停止などが即サービス停止につながります。
最低でもプライマリ＋セカンダリ（2 台構成）が必須であり、 できればクラウド DNS との併用が望まれます。
1-2. キャッシュ DNS（リゾルバ）の障害
社内クライアントは多くの場合「キャッシュ DNS（DNS Forwarder）」を利用します。 これが止まると、社内の PC / サーバはすべてインターネット解決ができなくなります。
特に Active Directory 環境では DNS 停止＝認証停止につながるため影響は甚大です。
1-3. TTL 設計ミスによる古いキャッシュ残留
DNS設定変更時に TTL を長く設定していると、 古い IP アドレスをキャッシュしたクライアントが大量に残り、フェイルオーバーが働きません。
可用性を考えると、運用中サービスの TTL は短め（300 秒前後）が推奨されます。
2. 企業 DNS の冗長構成（プライマリ・セカンダリ）
DNS の最も基本的な冗長化方法は、ゾーン転送によるプライマリ・セカンダリ構成です。
2-1. プライマリとセカンダリの役割
- プライマリ DNS：ゾーンの変更を行う書き込み可能 DNS
- セカンダリ DNS：プライマリからゾーン転送を受けた読み取り専用 DNS
クライアント問い合わせはどちらにも行えますが、 ゾーンの更新（レコード登録・変更）はプライマリのみ実施します。
2-2. ゾーン転送の注意点
セキュリティ面と可用性を考えると、以下を守ることが重要です。
- ゾーン転送は許可 IP を限定（AXFR を全公開しない）
- 可能なら TSIG（署名転送）を利用
- プライマリとセカンダリは別サブネットに配置する
- 経路障害に備え、異なるセグメント・ルータ配下に配置
※プライマリとセカンダリを同一スイッチ上に置くのは DR 対策として不十分です。
3. キャッシュ DNS（リゾルバ）の冗長化設計
社内ネットワークで DNS 経由の障害が最も多いのは「キャッシュ DNS の単独運用」です。
ベストプラクティスは以下です。
3-1. キャッシュ DNS は最低 2 台で冗長化
例えば以下のように、DHCP で 2 台配布します。
DNS1: 192.168.1.10
DNS2: 192.168.1.11Windows AD 環境であれば、DC を複数台用意し、 各 DC に DNS 役割を持たせるのが最も堅牢な方法です。
3-2. DNS フォワーダの冗長構成
キャッシュ DNS は問い合わせ先を複数設定できます。
- ISP DNS①
- ISP DNS②
- Google Public DNS（8.8.8.8）
- Cloudflare（1.1.1.1）
特定 ISP の障害に巻き込まれないよう、 異なる事業者の DNS を組み合わせるのが実務的です。
4. TTL 設計とフェイルオーバーの実践的な考え方
DNS フェイルオーバー設計で重要なのは「TTL と変更タイミング」です。
4-1. 本番運用中の TTL の目安
- 通常時：300〜600 秒（5〜10 分）
- 負荷分散・障害切替があるサービス：30〜120 秒
- DNS 切替前の準備期間：10〜60 秒
例えば新サーバへ移行する前日は TTL を下げ、 移行が終わったら TTL を戻すのがよくある運用方法です。
4-2. TTL が長すぎる際のトラブル例
TTL が 86400（1 日）のまま運用していた場合、以下の問題が起きます。
- 切り替え後も古い IP に接続し続けるクライアントが大量に発生
- 障害時に過去 IP へアクセスしてしまい復旧が遅れる
- 負荷分散が適切に実行されない
特に Web サービスでフェイルオーバーを行う場合、 TTL は短く運用することが重要です。
5. クラウド DNS を利用した冗長化（Route53 / Azure DNS）
オンプレ DNS のみで可用性を確保するのは限界があるため、 近年はクラウド DNS と併用するハイブリッド構成が一般化しています。
5-1. AWS Route53 を使う場合
- グローバルに冗長化された Authoritative DNS
- ヘルスチェックによる DNS フェイルオーバー
- Traffic Flow による遅延ベースルーティング
特にヘルスチェックと組み合わせると、 オンプレの Web サーバ故障を検知してクラウド側に即時切り替え、 といった構成が可能になります。
5-2. Azure DNS を使う場合
- Microsoft の Anycast ネットワークによる高速・高可用性
- Azure Traffic Manager や Front Door と組み合わせた冗長化
- Azure Private DNS で内部向け名前解決も統合
Azure AD / Microsoft 365 を利用している企業に特に相性の良い構成です。
5-3. クラウド DNS とのハイブリッド構成例
典型的な構成は次の通りです：
オンプレ DNS（プライマリ）
→ Route53 / Azure DNS（セカンダリ）クラウド側は「セカンダリ DNS」としてゾーンをホストし、 オンプレ DNS からゾーン情報を同期する形式です。
これにより以下が実現されます：
- オンプレ DNS 障害時もクラウド DNS が応答継続
- 大規模障害（回線断など）でも公開サービスを止めない
- グローバル配布が高速化（Anycast）
6. 内部 DNS と外部 DNS を分ける「スプリットブレイン」設計
セキュリティ強化のため、内部と外部で表示する DNS 情報を分ける構成を Split DNS（スプリット DNS）と呼びます。
6-1. なぜ内部と外部の DNS を分けるのか？
- 内部 IP を外部に公開しない
- サービス内部向けレコード（DB・内部API）を隠蔽
- 外部公開 DNS の障害が内部システムへ影響しない
- 内部では短い TTL、外部では長め TTL など運用を分離できる
セキュリティと可用性の両面で非常にメリットがあります。
6-2. 実務的なスプリット DNS 例
内部 DNS → internal.example.local（内部 IP）
外部 DNS → example.com（公開 IP）外部 Web ページと内部システムが同じ名前解決に依存しないため、 障害耐性が格段に向上します。
7. DNS 障害を減らす実務チェックリスト
DNS の可用性を高めたい場合、以下を守れば堅牢性は大幅に向上します。
7-1. 冗長化チェック
- プライマリ＋セカンダリ DNS を必ず用意
- キャッシュ DNS（リゾルバ）は 2 台以上
- ゾーン転送の許可 IP を限定
7-2. 運用チェック
- TTL を 300 秒前後に設定
- メンテ前に TTL を短くする運用
- DNS ログ（Query Log）を定期的に確認
- 外部監視（ヘルスチェック）を設定
7-3. クラウド併用チェック
- Route53 や Azure DNS をセカンダリとして利用
- グローバル Anycast のメリットを活用
- クラウドのヘルスチェックと連携してフェイルオーバー
まとめ：DNS の可用性は「冗長化＋キャッシュ設計＋クラウド併用」で大きく改善
DNS はネットワーク基盤の中でも最も障害影響が大きいコンポーネントであり、 「止めない設計」が最重要です。
本記事で紹介した以下のポイントを押さえておくと、 DNS 障害のほとんどを予防できます。
- プライマリ＋セカンダリで冗長化
- キャッシュ DNS の多重化
- TTL を短めに設定しフェイルオーバー可能にする
- 内部 DNS と外部 DNS を分離する（スプリット DNS）
- クラウド DNS（Route53 / Azure DNS）を併用
DNS は「単純に見えるが奥深い」分野であり、 適切な設計と運用によって、システム全体の安定性を大幅に高めることができます。
