J:COMは9月25日、前日に発生したインターネット接続サービスの障害について、「外部からの大量アクセスによりDNSサーバに高負荷が発生した」ことが原因だと公表した。最大約408万世帯に影響し、復旧まで9時間を要した。
DNSというインターネットの根幹が単一障害点となり、かつ障害時の情報公開が遅れた。ISP事業者におけるインフラ設計と危機管理の両面に課題が残る事案だ。
事案の概要
- 発生日時：2026年9月23日 08:55 〜 18:00頃（約9時間）
- 影響範囲：最大約408万世帯（北海道・九州を除くJ:COM NET提供エリア等）
- 対象サービス：J:COM NET、J:COM TVネット動画、J:COM MOBILE等
- 直接原因：外部からの大量アクセスによるDNSサーバの高負荷
- 特記事項：カスタマーセンターも繋がりにくい状態が継続
DNSサーバの高負荷がWeb、メール、モバイル回線に至るまで連鎖的にサービスを停止させた。DNSは名前解決を行うインターネットの住所録であり、ここがダウンすれば全ての通信が機能不全に陥る。408万世帯という規模は、DNSアーキテクチャの冗長性不足または過負荷対策の不備の可能性が高い。
DNSアーキテクチャの検証ポイント
「外部からの大量アクセス」でDNSサーバが高負荷になった背景には、いくつかの技術的要因が考えられる。
Anycast未導入または設定不備の可能性がある。Anycastは同一IPアドレスを複数の地理的に分散したサーバで応答する技術で、トラフィックを分散し単一拠点への集中を防ぐ。Unicast構成だった場合、特定データセンターへのアクセス集中で即座に飽和する。
権威サーバと再帰サーバの分離不足も疑われる。ユーザーからの問い合わせ（再帰検索）とドメイン情報の提供（権威応答）を同じサーバ群で処理していると、片方の過負荷が他方に波及する。物理的・論理的な分離がベストプラクティスとされる。
キャッシュTTLの設定問題もある。キャッシュ生存時間が短すぎると、クライアントやリゾルバが頻繁に権威サーバへ問い合わせを行い、負荷が増幅される。
DDoS Mitigationと監視体制
関連記事にある「広範囲で執拗、かつテスト的なDDoS攻撃」という有識者の指摘は示唆的だ。本格的な攻撃の前に、小規模なプローブ送信で防御体制の弱点を探る手法は近年常套化している。
同一IPからの過剰なDNSクエリを自動的に制限するRate Limitingの実装状況、異常トラフィックを特定し廃棄ルートに誘導するBlackhole RoutingやSinkholingの自動化、CloudflareやAWS Route 53 Resolver等のクラウド型DNSセキュリティサービスの活用状況などが検証ポイントになる。オンプレミス依存ではスケールアウトに限界がある。
「大量アクセス＝単純なDDoS」と決めつけず、攻撃前の偵察行為を検知できる監視体制が現代のネットワークセキュリティには求められる。
9時間の沈黙とコミュニケーション
障害発生から原因公表まで時間がかかり、カスタマーセンターも繋がりにくい状態だった。「技術的復旧」と並行して必要な「コミュニケーション体制の欠如」が浮き彫りになっている。
障害情報を一元公開する専用ページ（status.jcom.co.jp等）の有無、電話が繋がらない場合のバックアップチャネル（チャットボット、フォーム、X DM等）の整備状況、障害発生から30分以内の第一報の有無などが確認すべき点だ。
技術的復旧と同じくらい重要なのがユーザーへの誠実な情報提供だ。「わからない」という状況自体を伝えることが、結果として信頼を守る。
ISPとしての責任
DNSという見えないインフラが社会生活を支えている現実と、その脆弱性が露呈した時の破壊力が如実に示された事例だ。各ISP事業者だけでなく、自社ネットワークのDNS設計を見直すきっかけになる。
コメント