ある日、出社してしばらくすると、
「なんかメールが繋がらないんですけど」
と声をかけられた。
まずはいつものように監視を確認。Zabbix の ping 監視を見ると、サーバは普通に生きている。疎通も問題なし。
社内の共有フォルダも見えるし、Active Directory も普通に動いている。
「ん？ サーバは全部生きてるな…」
とりあえずその時点では、端末側の一時的な不具合かな、くらいに考えていた。
ところが、10分もしないうちに別の部署から
「Webが見られないんだけど」
「ネットに繋がらない」
と立て続けに問い合わせが来る。
あ、これはヤバいやつだ、とそこで一気に緊張感が上がった。
pingは通る。でもネットが使えない
改めて自分の端末で確認してみると、確かに社外サイトが開かない。
ただ、IPアドレス指定で ping を打つと普通に返ってくる。
「疎通は問題ない。でも名前解決が怪しい…」
ここでようやく DNS を疑い始めた。
Active Directory 環境だと、内部DNSで社内の名前解決はできるけど、外部ドメインの解決は DNS フォワーダ経由になる。
「あれ、フォワーダ先ってどこに向けてたっけ…」
設定を確認すると、フォワード先に登録していた外部DNSサーバが 1 台、応答していない。
正直この時点で、「これか…」と半分ホッとした。
フォワーダ先DNSが障害で死んでいた
調べてみると、フォワーダ先にしていた DNS サーバ側で障害が起きていたらしい。
そのDNSが応答しなくなったことで、社内からの外部名前解決がすべて詰まっていた。
ping が通る、ファイルサーバも見える、ADも動いている。
それなのに「ネットだけ使えない」という、かなり切り分けが面倒なパターンだった。
今思えば典型的な DNS トラブルなんだけど、実際の現場では一瞬判断が遅れる。
特に、
「サーバ生きてる」
「社内システムは普通」
という状態だと、どうしても端末側とか、ネットワーク機器側を疑いがちになる。
とりあえずフォワーダ先を増やす
原因が分かったので、対策は単純だった。
DNSフォワーダに複数の外部DNSを登録。
1台死んでも、別のDNSにフォールバックする構成に変更した。
正直、「最初からやっとけよ…」という話なんだけど、
こういうのって、トラブルが起きて初めて本気で見直すことが多い。
設定変更後、すぐに名前解決が復旧。
Webもメールも問題なく使えるようになり、社内の問い合わせも一気に収束した。
なぜ気づくまで時間がかかったのか
今回、一番時間を食ったのは、
「pingは通る」「サーバも動いている」という安心感だった。
これが完全に通信断なら、もっと早くDNSを疑っていたと思う。
DNSトラブルって、
・疎通はOK
・内部システムはOK
・外部通信だけNG
という、微妙に中途半端な症状になることが多い。
この「中途半端さ」が、切り分けを遅らせる。
今振り返ると、
「ping通る → でもWeb開かない → DNSだな」
と即座に反射的に考えられるようになっておくべきだった。
こういう障害を減らすために
社内サーバ運用をしていると、
DNS、NTP、証明書、ルーティング、この辺りは地味だけど本当に重要だと痛感する。
しかも、これらは
「壊れたときにしか存在感を出さない」
普段は完全に空気なのに、死ぬと全社業務が止まる。
最近は、社内にサーバを置かずに VPS やクラウド側に寄せる構成も増えてきて、
こういったインフラ基盤の冗長化や可用性設計を、ある程度サービス側に任せられるのは正直ありがたい。
実際、自分も今は VPS 側にサーバを寄せるケースが増えていて、
DNS 周りの冗長性やインフラ管理をある程度お任せできるのは、精神的にもかなり楽になった。
社内オンプレ全盛期のころと比べると、
トラブル対応のストレスは確実に減ってきている気がする。
今の正直な感想
DNSトラブルは、何度経験しても嫌だ。
症状が分かりづらく、問い合わせが一気に集中し、
しかも「ネット繋がらないんだけど？」という、ざっくりした相談ばかり飛んでくる。
ただ、この手のトラブルを何回か経験すると、
切り分けのスピードは確実に上がる。
「ping OK ＋ Web NG → DNS」
この反射ができるようになったのは、完全にこの時の失敗のおかげ。
情シスの仕事って、こういう地味な障害対応の積み重ねで、
少しずつ勘が鍛えられていくんだな、と改めて感じた出来事だった。
