J:COM の DNS 障害｜名前解決の切り分けと設定変更の注意点

はじめに

2026 年 9 月 23 日、J:COM のインターネット接続サービス等で、利用できない、または利用しづらい状況が発生しました。J:COM は翌 24 日に、外部からの大量アクセスによって DNS サーバーに高負荷が発生したことが原因だったと公表しています。

DNS に問題が起きると、Wi-Fi にはつながっているのに Web サイトやアプリを利用できない、という症状になることがあります。在宅勤務者から「ネットが使えない」と連絡を受けた情シス担当者や小規模拠点の管理者にとっては、回線、名前解決、特定のサービスのどこに問題があるのかを分けて考えることが、次の対応を決める手がかりになります。

本記事は、2026 年 9 月 23 日に発生した J:COM の障害を対象事例とし、2026 年 9 月 28 日時点で確認できた公式情報をもとに整理しています。最新の障害状況を掲載するページではないため、現在の状況は J:COM の障害・メンテナンス情報で確認することをおすすめします。

J:COM は障害の原因を外部からの大量アクセスによる DNS サーバーの高負荷と公表し、9 月 23 日 20 時に全サービスの正常提供を最終確認しています。障害時に端末側で行えるのは、既定の DNS と比較先の DNS に同じ問い合わせを行い、DNS の問題か他の要因かを切り分けることです。DNS 設定の変更は一律の対処ではなく、端末の管理方針と社内の名前解決への影響を確認し、戻し方を決めてから検討することをおすすめします。

J:COM の DNS 障害で公表されたこと

この章では、J:COM のニュースリリースと障害情報ページの記載に限定して整理します。時刻、件数、対象範囲は公式本文の表現に沿って記載しています。

発生から原因公表までの経過

復旧作業の完了（18 時頃）と、正常提供の最終確認（20 時）は、別の時点として公表されています。表の時刻は J:COM が公表した時点を示すもので、利用者ごとの復旧時刻は利用環境によって異なる可能性があります。

影響地域と対象サービス

ニュースリリースでは、影響エリアを J:COM NET 提供エリア（北海道、九州を除く）と、J:COM がインターネットサービスを提供するケーブルテレビ事業者エリアの一部としています。最大影響対象件数は約 408 万件（J:COM サービス加入世帯）です。公式の表現は「最大影響対象件数」であり、すべての加入世帯で同じ症状が発生したことを示す数値としては公表されていません。

障害情報ページ（番号 55269）は、表の対象エリア欄を「全国」、本文を「一部エリア」とし、対象サービスには J:COM NET のインターネット接続を記載しています。影響地域と対象サービスは、内訳が詳しいニュースリリースを基準に確認することをおすすめします。

J:COM 障害の原因として公表された内容と未公表の事項

参考: J:COM ニュースリリース（2026 年 9 月 24 日更新）
「外部から大量のアクセスがあり、DNSサーバに高負荷が発生したことにより障害に至った」
https://newsreleases.jcom.co.jp/news/20260924_22551.html

J:COM はこの影響により、インターネット接続時に必要な処理が正常に行えなくなったと説明しています。再発防止策としては、アクセス集中対策の強化と、障害発生時の情報提供の改善を挙げています。

2026 年 9 月 28 日の確認時点では、大量アクセスの送信元や意図、DNS サーバーの構成、具体的な技術対策は公表されていません。公式発表は「外部からの大量アクセス」という表現にとどまっており、DDoS 攻撃や不正侵入と断定できる情報は確認できていません。本記事でも、J:COM の設備構成や攻撃手法の推測は行いません。

J:COM の公式案内と本記事の扱い

J:COM は、復旧後も利用しづらい場合の対応として、J:COM 機器の再起動を案内しています。再起動は機器の電源を入れ直す操作で、設定を工場出荷時の状態に戻す初期化とは異なります。初期化を行うと接続設定のやり直しが必要になる場合があるため、公式の再起動手順に沿って操作することをおすすめします。

障害当日は SNS などで DNS 設定の変更に関する投稿も見られましたが、J:COM の公式案内には DNS 設定の変更は含まれていません。次章以降の切り分けと設定変更の判断は、一般的な DNS 障害への備えとして整理したもので、今回の障害で J:COM が示した復旧手順ではありません。

DNS 障害を切り分ける確認手順

ここからは J:COM 固有の事実ではなく、一般的な DNS 障害の切り分けとして整理します。手順は Windows を例とし、コマンドは Microsoft Learn の公式リファレンスに基づく確認例です。障害時の実際の出力例は掲載していません。

Wi-Fi 接続・外部通信・名前解決は確認対象が異なる

「インターネットにつながらない」という症状には、確認対象が異なる 3 つの段階が含まれます。

Wi-Fi・LAN への接続

端末がルーターやアクセスポイントと接続し、IP アドレスを取得できているかを確認します。Wi-Fi のアイコンが接続状態でも、その先の通信ができるとは限りません。

外部との通信

ルーターから回線を経由して、インターネット上の宛先へ通信が届くかを確認します。回線や経路の問題はこの段階に現れます。

名前解決

端末が DNS サーバーに問い合わせ、FQDN に対応する IP アドレスを取得できるかを確認します。ここで失敗すると、回線が使える状態でも、名前で指定したサービスへ接続できません。

名前解決に成功した後の、通信先への接続は別の処理です。DNS の応答が返ることと、目的のサービスを利用できることは分けて確認することが重要です。FQDN の用語は『FQDN とサブドメイン・ホスト名の違い』で解説しています。

Windows で DNS 設定を変更する前に行う確認

DNS 設定を変更する前に、次の順序で状況を確認します。nslookup で問い合わせ先の DNS を指定する操作と、OS の DNS 設定を変更する操作は別のものです。nslookup で比較先を指定しても、端末の DNS 設定は変わりません。

ipconfig /all

Get-DnsClientServerAddress

nslookup -type=A -nosearch www.example.com
nslookup -type=A -nosearch www.example.com 8.8.8.8

確認結果と次の行動の対応表

1 回の確認結果だけで原因を断定せず、時間を置いた再確認や別端末での結果と合わせて判断します。表中のエラー表示は、Microsoft Learn の nslookup リファレンスに記載された名称に合わせています。

比較先への問い合わせは、企業のファイアウォールや DNS フィルタリングで遮断される場合があります。この場合のタイムアウトや Refused は、比較先 DNS の障害を示すとは限りません。

ping や IP アドレス指定だけで判断しない理由

ping の応答は ICMP の到達性を示すもので、DNS が正常かどうかを直接示すものではありません。宛先や経路上の機器が ICMP に応答しない設定の場合もあるため、ping の結果だけで DNS 障害と判断することは避けます。

Web サイトを IP アドレスで開けない場合も、回線障害とは限りません。HTTPS のサイトでは証明書の名前と一致しない、同じ IP アドレスで複数のサイトを提供しているなどの理由で、IP アドレス指定では表示できないことがあります。

また、ブラウザーの Secure DNS（DNS over HTTPS）が有効な場合、ブラウザーは OS の DNS 設定とは別の経路で名前解決を行うことがあります。ブラウザーでは表示できるのに nslookup では失敗する、またはその逆の場合は、ブラウザーの Secure DNS 設定も確認対象に加えます。

DNS 設定を変更する前の確認と復旧後の対応

DNS 設定の変更で名前解決が回復する場合はありますが、すべての環境で有効な対処ではありません。「8.8.8.8 に変更すれば直る」という一律の判断は避け、変更してよい端末かどうかを先に確認することをおすすめします。

変更可否を判断する 5 つの確認項目

次のいずれかに該当する場合、DNS 設定の変更によって、業務に必要な名前解決や通信制御に影響が出る可能性があります。

会社管理端末

設定変更が管理ポリシーで制限されている、または運用規程で認められていない場合があります。

Active Directory

ドメイン参加端末は、ドメインコントローラーの検出や認証に社内 DNS を利用します。外部 DNS へ変更すると、ログオンやドメイン関連の処理に影響する可能性があります。

VPN

VPN 接続時に社内 DNS を利用する構成では、アダプターの DNS 設定を変更すると、社内システムの名前解決に影響する場合があります。

社内限定名

社内でのみ解決できる名前は、外部 DNS では解決できません。

DNS フィルタリング

社内 DNS やセキュリティサービスで危険なドメインへの通信を遮断している場合、DNS を変更すると、その保護が適用されなくなる可能性があります。

参考: Microsoft Learn「Best practices for DNS client settings in Windows Server」
“Don’t configure the client DNS settings to point to your ISP’s DNS servers.”
（クライアントの DNS 設定を、ISP の DNS サーバーを指すように構成しないでください。）
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings

これは Windows Server のメンバーサーバーに対する推奨で、外部の名前は内部 DNS サーバーから ISP の DNS へフォワードする構成が示されています。同じ資料では、DNS クライアントは優先 DNS が応答しない場合に代替 DNS へ切り替え、誤った応答を受け取っても切り替えないと説明されています。代替 DNS に外部 DNS を追加する構成では、切り替え後に社内の名前を解決できなくなる可能性があります。企業環境の端末では、DNS 設定は管理者の運用方針に従うことをおすすめします。

一時的に変更する場合の進め方

個人で管理している端末など、変更が許可されている環境で一時的に変更する場合は、次の流れで進めます。企業環境では、管理者が指示した手順と比較先を優先します。

ipconfig /flushdns

一時変更した端末が複数ある場合は、端末名、変更日時、元の設定を一覧にしておくと、復旧後の戻し漏れを防ぎやすくなります。

復旧後も利用しづらい場合

回線事業者が復旧を公表した後も利用しづらい場合は、まず事業者の案内に沿って対応します。今回の障害では、前述のとおり J:COM 機器の再起動が案内されています。

端末の DNS 設定を一時変更していた場合は、元の設定へ戻してから確認します。端末の DNS キャッシュに障害中の結果が残っている可能性もあるため、ipconfig /flushdns の実行後に再確認します。それでも改善しない場合は、切り分けの記録を添えて回線事業者または管理者へ相談することをおすすめします。

まとめ

J:COM は、2026 年 9 月 23 日の障害の原因を外部からの大量アクセスによる DNS サーバーの高負荷と公表し、同日 20 時に全サービスの正常提供を確認しています。障害時は公式情報と端末側の切り分けを組み合わせ、DNS 設定の変更は条件と戻し方を決めてから検討することが重要です。

• 原因は外部からの大量アクセスによる DNS サーバーの高負荷と公表
• 約 408 万件は最大影響対象件数で、全世帯の同一症状を示す数値ではない。
• Wi-Fi 接続、外部との通信、名前解決は確認対象が異なる。
• 既定の DNS と比較先に同じ FQDN・レコード種別を問い合わせて比べる。
• 名前解決の成功だけでは、サービス全体の正常性を判断できない。
• 企業端末の DNS 変更は、管理者の運用方針に従うことが前提となる。
• 一時変更では元の設定を記録し、復旧後に元の状態へ戻す。

以上、最後までお読みいただきありがとうございました。