おれのIT日記
2025/10/22 (水)
Linux
トラブルは突然に。名前解決ができなくなってたサーバ1号機
■ 10/20 未明2:00過ぎ、我が家のホームゲートウェイでリンクエラー
今のプロバイダの光接続を導入して10年近くなるが、あまり起きた覚えのないエラーである。
ホームゲートウェイのリンクエラーはすぐ復旧し、同機が備える簡易DNS機能も、正常に使えるようにすぐ戻ったようなのだが、DNSクライアントのひとつに、異常が残った。よりによってサーバ1号機に、だ。
サーバ1号機は、上記事象でDNS設定が上書きされ異常になり、正常状態に戻れなくなっていた。結果、1号機上のすべてのプロセスは、実質、外部の名前解決が不能になっていた。
何もしらないおれは、二日以上経過した本日夜になって、まったく別件でスクリプトを組んでいて、
unreachable host
と出て、んなバカな、と、のんきに、ケーブルのゆるみが無いか調べたりしていたのだが、だんだん、大事故が起きていることを認識した次第。
よ～くサーバ内を調べると、知らないうちにここ48時間近くの、ラジオ録音・曲目リスト取得がぜんぶ失敗していた。
ちょっと、顔が蒼ざめるほどビビった。
こんなことは初めてなので、攻撃か、とまず思ったのですね。
ある程度状況がわかってきってホッとしたところで、今度は、なんでこんなに長い時間気づかなかったのか、と悔やまれた。
それは、サーバ1号機「だけ」DNSを利用できない状況になっていたから、なんですね。
1号機にsmb接続するスマホやPCなどのクライアントたちには何の問題も起きなかった。
ファイルサーバも兼ねる1号機上のファイルには、スマホやWindowsPCから、頻繁に参照・書換しているのだが、クライアント側のDNSは正常なもんだから、いつもと同様に使えており、1号機内部でそのような重大な事故が起きているとは、気づかなんだ。
光ルータの「障害ログ」をWebで眺め、ChatGPTにも各種情報を伝え、どうやら攻撃ではなく、冒頭の推定どおり、と自信を持てた。
振り返ると、事象発生の数時間後に、DNS解決がエラーになり始めていた。DNSキャッシュと再取得までの時間的スパンを考えると、そんなもんですかね？
我が家では非常に珍しい、というより、たぶん1号機運用開始後、初めての事故である。
おかげで、24時間もれなくとっているラジオ放送リスト系に、久々に空白が生じることとなってしまった。
（2号機はじめサーバは複数用意してるんだけど、節電のため(笑)、該当時間帯は、電源切ってたのだ）
■ 具体的な症状
・ping 8.8.8.8 はとおるが、名前アクセスすると、
と言ってくる。
また、先に書いた通り、1号機以外は何の問題も起きていない。
DNSだな、とまではおれでもすぐ判ったが、さてどこから手を付けたものか。
ちなみに、2号機ほか、Windowsも含め、何の問題もないことを確認してから、ChatGPTに相談。
■ 調べたところ
1. /etc/resolv.conf を確認
ふだん見ないよね。
(2025/10/23追記) 誤った理解で書いていました。上記内容は、Linux Mintでは正常です。ChatGPTは、この内容がおかしいと言いたかったのではなく、「ここには問題がないことを確認したので、次の2.に行ってみよう」と言いたかったのでしょう。
素人目にも「？」と言う内容である。
127.0.0.53はローカルstubというものらしいが、名前解決能力は限りなくゼロに近い。
つまり名前解決できない。
(WindowsでDHCPに出会えなくて168～のヘンなIPアドレスになることがあるでしょう。あれと同じで、実際の意味はないんじゃないかな、だって、末尾の53って、DNSのサービスポートと同じ番号つけただけだろ？)
ちなみに2号機の同ファイルはどうなってるかなと思って見てみたら、こうだった。
だいたいおわかりと思いますが、192.168.1.1というのは我が家のホームゲートウェイであり、簡易DNSを備えております。
これでいいじゃん、って感じです。
ちなみに2号機は、わざと1号機と違うディストリビューションにしており、おれが作る拙いシェル程度なら共通で動かせますが、内部で採用されている構成が微妙に違います。
これは、不便なようですが、勉強のためにそうしています。
(2025/10/23追記) これも上と同様に、MX Linuxでは正常です。
2. systemd-resolvedの状態を確認
ここで確認したいのは、
・「DNS Servers:」が空欄ではないか
・Current Scopes に DNS が含まれているか
・どのインターフェイス（例：eth0, enp3s0 など）でDNSを扱っているか
なのであるが、おれの場合そもそも、DNS Serversという行自体が出ない。
「DNS Servers:」が 空欄 だった場合、上位DNSが設定されていません、とChatGPTくんに断言された。
systemd-resolvedが何に問い合わせればいいかわからない状態なんだそうだよ。
3. 一時設定してテスト＋恒久設定
ChatGPTの回答ではよくあることだが、1号機のLinux Mintではコマンド体系が違う。
たとえば、ChatGPTはいつも、systemctlを使ったコマンドを詳しく助言してくれるものの、1号機は service コマンドしか動かんので、いちいち自力で翻訳せにゃならん。
このことは、もう100回ぐらい伝えたが、ChatGPTくん、覚えてくれる気配なし。
上記も、似たようなもんだろうと思う。オプションの指定方法まで違うから、調べるのも面倒。
おれしか使わないおれのサーバだから、遠慮なく、恒久設定というか、設定ファイル
/etc/systemd/resolved.conf
を、直接書き換えましたよぉ！
注) 192.168.1.1はホームゲートウェイ、イコール、プロバイダ提供のDNS依存。こいつを最初に指定し、以下は、Google提供のやつを保険として設定。
ちなみに上記ファイルは、重要な行だけ掲げたが、実際には30行ぐらい、コメントのオンパレードだった。
4. 名前解決サービスを再起動して確認
以上で、修復完了。
■ 再発防止策
ChatGPTの提案はこんな感じ。注釈だけ加えてそのまま載せるが、下記スクリプトをcronで定期実行すれば、検知と、名前解決サービスの再起動が自動化できる、とのこと。
でもさあ？
sudo をcronで実行したらマズいんじゃないか、対話式に待っちゃうんじゃないか？
それに、今回起きた事象のように、DHCPによるDNS上書きが起きたなら、サービス再起動しても、何も改善しないのでは？
今回のresolved.conf書き換えで同じ事象の再発が防げたのか、防げてないのか、ChatGPTが言うことを聞いても、よくわからんのだ。
(2025/10/23追記) 下記参照
もう少し、自分で勉強する必要がありそうだ。
まずは当面、ログだけでも取って、こまめに見るとする。何かわかったら続きを書きます。
(2025/10/23追記)
次の手順で、DHCPによる/etc/resolv.confの上書更新を避け、固定できるとChatGPTは言っている。
一応やったけどサ、まだ言ってることおかしいんだよな。だって、/etc/resolv.confは、書き換えられた形跡はなかったんだから。
ま、復旧手順が有効だったのは確かだから、引き続き、実地で経験を積んでから反論してみよう。