DNS障害から学ぶ実際のインシデント事例｜大規模障害で何が起きたのかを理解する
KoAN
目次
DNS障害から学ぶ実際のインシデント事例
DNSはインターネットを支える重要な基盤技術です。
しかし、普段は意識されることが少なく、正常に動作していることが当たり前と思われています。
ところが一度DNS障害が発生すると、Webサイト閲覧、メール送受信、クラウドサービス利用など、多くのシステムが同時に利用できなくなります。
実際に過去には世界規模のDNS障害が何度も発生しており、多くの企業が大きな影響を受けました。
本記事では実際に発生したDNS障害事例を紹介しながら、障害の原因や教訓について解説します。
なぜDNS障害は影響が大きいのか
DNSはインターネットの電話帳とも呼ばれます。
www.example.com
↓
IPアドレス
↓
接続
という流れで通信が行われます。
そのためDNSが停止すると、サーバ自体が正常でも利用者は接続できなくなります。
事例① Dyn DNS障害（2016年）
DNS障害として最も有名な事例の一つです。
Dynは大規模DNSサービス事業者でした。
2016年に大規模なDDoS攻撃を受けました。
影響を受けたサービス
- Netflix
- GitHub
- Spotify
- PayPal
多数の有名サービスが利用できなくなりました。
何が起きたのか
DNSサービスそのものが攻撃を受けました。
利用者
↓
Dyn DNS
↓
応答不能
結果として名前解決ができなくなりました。
教訓
単一DNS事業者への依存は危険です。
現在では複数DNSサービスを利用する企業も増えています。
事例② Facebook障害（2021年）
Facebook、Instagram、WhatsAppが同時停止した障害です。
世界中で大きなニュースになりました。
原因
BGP設定変更ミスが原因でした。
しかし利用者からはDNS障害のように見えました。
DNS応答不能
↓
サービス利用不可
という状況になりました。
教訓
DNSだけでなくネットワーク全体の設計が重要です。
BGPやルーティング障害もDNS障害に見えることがあります。
事例③ Google Cloud DNS障害
クラウドサービスでもDNS障害は発生します。
設定ミスやソフトウェア不具合によって名前解決が失敗した事例があります。
影響範囲
- クラウドサービス接続不可
- API利用不可
- 管理画面接続不可
DNSの重要性が再認識されました。
事例④ Active Directory DNS障害
企業内で非常に多い障害です。
Windows Server環境ではDNSがActive Directoryの中核機能になっています。
発生する問題
- ログオン失敗
- 共有フォルダ利用不可
- グループポリシー適用失敗
- LDAP接続失敗
DNS障害がドメイン全体へ波及します。
事例⑤ セカンダリーDNS未同期
企業環境で非常に多い事例です。
プライマリDNSだけ更新しています。
Primary DNS
↓
新IP
Secondary DNS
↓
旧IP
利用者によって異なる結果が返されます。
原因
- シリアル番号更新忘れ
- ゾーン転送失敗
- allow-transfer設定ミス
が主な原因です。
事例⑥ DNSキャッシュによる障害
サーバ移転時によく発生します。
DNS変更後も利用者が古いサーバへ接続します。
旧IP
↓
キャッシュ保持
↓
接続継続
DNS自体は正常でも障害に見えるケースです。
事例⑦ MXレコード設定ミス
メール障害として頻繁に発生します。
例です。
MX
↓
mail.example.com
しかしAレコードがありません。
メール配送が失敗します。
事例⑧ split-brain DNS障害
内部DNSと外部DNSの情報が異なるケースです。
内部DNS
↓
旧サーバ
外部DNS
↓
新サーバ
社内だけ障害が発生します。
事例⑨ DNSループ構成
フォワーダ設定ミスです。
DNS-A
↓
DNS-B
↓
DNS-A
問い合わせが循環します。
SERVFAILが発生します。
事例⑩ オープンリゾルバ化
誤設定により外部から再帰問い合わせ可能になった事例です。
結果として次の問題が発生します。
- DDoS踏み台
- 高負荷
- 情報漏えい
セキュリティ事故につながります。
障害時の調査手順
実務では次の順番で確認します。
ネットワーク確認
↓
DNS確認
↓
権威DNS確認
↓
ログ確認
↓
ゾーン確認
いきなり設定変更しないことが重要です。
まず確認するコマンド
$ dig www.example.com
$ dig @8.8.8.8 www.example.com
$ dig @ns1.example.com www.example.com問い合わせ先を変えて比較します。
ログ確認
# journalctl -u namedBIND障害調査の基本です。
設定確認
# named-checkconf構文エラーを確認します。
ゾーン確認
# named-checkzone example.com /var/named/example.com.zoneゾーンファイルを確認します。
DNS障害から学ぶ設計原則
- DNSサーバを冗長化する
- 複数拠点へ配置する
- TTLを適切に設定する
- 監視を行う
- ゾーン転送を確認する
- 定期的に障害訓練を実施する
監視すべき項目
- DNS応答時間
- DNS応答可否
- SOAシリアル番号
- ゾーン転送状態
- CPU使用率
- メモリ使用率
これらを継続的に監視します。
実務で覚えておきたいポイント
- DNS障害はサービス全体へ影響する
- 設定ミスが原因のことが多い
- キャッシュが障害を複雑化する
- セカンダリーDNSの確認が重要
- digとログ確認が基本
- 冗長化と監視が重要である
まとめ
DNS障害はWebサイト、メール、クラウドサービスなど多くのシステムへ影響を与える重大な障害です。
実際のインシデントを見ると、設定ミス、キャッシュ、ゾーン転送失敗、DDoS攻撃など様々な原因が存在します。
しかし多くの障害は適切な設計と監視によって防ぐことが可能です。
DNS運用では障害事例から学び、同じ失敗を繰り返さないことが安定運用への近道と言えるでしょう。
