フレッツ 光ネクストの一部ユーザーに、8時間にわたってWebページにアクセスできなくなるなどの障害が起こった。原因はNGN内部のDNS(Domain Name System)サーバーに発生した障害。本来、NGN内部に閉じたサービスだけに必要で、インターネット接続には使わないはずの仕組みがネックとなった。

 インターネット接続などに障害が起こった原因は、NGN内部のDNSサーバーの一部が、ユーザーからの接続先ホストのアドレス解決問い合わせに応答できなくなったためである。ユーザーからインターネットへのIPレベルの接続性は確保できていても、Webアクセスなど、ホスト名を指定するアプリケーションが利用できない状態になった。

作業ミスでセカンダリDNSに障害

 障害は、メンテナンス作業のミスによって生じた(図1)。一般にDNSサーバーは、ホスト名とIPアドレスをひも付けた情報「ゾーンファイル」のオリジナルを保持するプライマリと、プライマリからゾーンファイルをコピーして、情報を同期させるセカンダリの2系統で運用する。NGNでも同様の体制で運用していたようだ。

図1●NTT東日本が実施したDNSサーバーのメンテナンスの経緯<br>バージョンアップの際にゾーンファイルの形式変更に留意できなかったため、セカンダリサーバーの稼働に支障が出た。
図1●NTT東日本が実施したDNSサーバーのメンテナンスの経緯
バージョンアップの際にゾーンファイルの形式変更に留意できなかったため、セカンダリサーバーの稼働に支障が出た。
[画像のクリックで拡大表示]

 NTT東日本は10月6日の夜間に、プライマリであるDNSサーバーAのソフトウエアのバージョンアップ作業を実施した。だが、その際に作成したゾーンファイルが、セカンダリであるサーバーBに残した旧バージョンでは読み取れない形式であることに気付かなかった。「DNSのバージョンアップは、これまでのメンテナンスにはなかった大きな変更だった」(NTT東日本)ことも災いしたようだ。

 その後、サーバーBが10月7日の正午ころにサーバーAからゾーンファイルをコピーして自動更新。読み取れる形式のゾーンファイルに、読み取れない形式のファイルを上書きした。これによってサーバーBが、ユーザーからの名前解決の問い合わせに応答できない状況に陥った。

 サーバーBのバージョンアップをサーバーAと同時に行わなかったのは、「安定運用を確認できるまで、正常に動いているシステムを1系統は確保しておくべきと判断した」(NTT東日本)からだ。10月7日の午後には、サーバーBのバージョンもそろえる予定だったという。ゾーンファイル更新のタイミングをサーバーBのバージョンアップの後になるよう調整するか、あるいはサーバーA側にバージョンアップ前の形式のファイルも保存しておけば、障害は防げたはずだった。