Scribble at 2026-09-11 07:26:25 Last modified: unmodified
エラー 2026/09/11 6:15:34 Service Control Manager 7011 なし Dnscache サービスからのトランザクション応答を待機中にタイムアウト (30000 ミリ秒) になりました。
エラー 2026/09/11 6:15:04 Service Control Manager 7011 なし Dnscache サービスからのトランザクション応答を待機中にタイムアウト (30000 ミリ秒) になりました。
旧マシンを起動すると、インターネット接続と LAN 接続が正しく繋がっているにもかかわらず、暫くするとインターネットの接続だけ切れてしまい、5分後に復活するという妙な挙動を示していた。実は何年も前からのことなのだが、どのみち放っておけば通信できるようになるから、陸上部の部活でよくやる「アップ」みたいなものだと思って放っておいたのである。でも、そろそろ古いマシンは古いがゆえに遅いのは確かなので、普通に使っていても遅いマシンを更に遅く感じさせるようなことはトラブルシュートした方がいいだろうということで、さきほど Gemini と一緒にイベント・ビューアのログを眺めながら対策した。
Gemini の所見では、イベント・ビューアでエラーや警告のアイコンが付いた記録のうち(それらだけをテキスト・ファイルとしてフィルタリングして Gemini にアップロードしている)、怪しいのは上の DNS 関連のエラーだという話である。インターネットの接続だけがおかしいと思ったので、僕は NURO の古いルータの DHCP が腐ってるのかと思ったが、そうではないらしい。そして DNS 関連で重い処理が実行されてしまっている原因を考えると、恐らく一つしかない。巨大なhosts ファイルだ。
旧マシンは、現在は業務用に使っているので、可能な限りアド・ネットワークやソーシャル・メディアなどの FQDN を 0.0.0.0 に弾き飛ばすよう hosts ファイルに8万件ほどのドメインを登録している。たぶん、3 MB の hosts ファイルを運用する個人なんて少ないはずだ。そして、DNS のキャッシュとしては大きすぎるのであろう。ということで、これを Cryptometer で使うホスト名だけ(1件)に減らしてから、管理者権限で起動した PowerShell にて、
# ipconfig /flushdns
を実行してパソコンを再起動すると、無事に最初からインターネット接続が安定して確立された(通知領域のアイコンで分かる)。これで、数年来の問題も解決して、旧マシンも快適に使えるのだが、問題は hosts ファイルをクリアしてしまったから、アド・ネットワークやソーシャル・メディアからゴミくずを食わされないように別の対策を立てないといけない。
これは、Gemini から推薦してもらった AdGuard DNS を Primary / Secondary の DNS に設定して試している。ただし、最近はこういうのを擦り抜けるためにゴロツキ広告代理店どもも対策してきているらしい。それからもちろん、こういう対策には根本的な限界もある。なぜなら、これらはホスト名や FQDN と IP アドレスとの変換、つまり名前の解決というスキームの上でやっている対策でしかなく、ワームやフィッシングで使われることが多い、IP アドレスそのままで運用されているウェブ・サーバには無効だからだ。よって、やはりファイアーウォールなども活用しないといけない。