自宅に 2 番目の DNS サーバーを追加したところ、インターネットとは関係のない問題が修正されました

良くも悪くも、DNS の障害はインターネットの問題のように感じられます。つまり、Web サイトの読み込みに失敗した場合、それはインターネットに何らかの問題があることになりますが、たとえば ISP に障害が発生した場合とは異なります。 DNS に障害が発生すると、他のすべてがうまくいく可能性がありますが、Web サイトは苦戦することになります。

私はついに、何が私にとって問題なのかを理解しました。実際の弱点は、私が意図的にネットワークの真ん中にこっそりと設置した DNS サーバーでした。自分は正しいことをしていると思っていましたが、それ以上に間違いはありませんでした。

DNS は私が思っていたよりもはるかに多くのホーム ネットワークに関与していました

ローカル名はまだ解決する必要があります

DNS については、私たちの多くがあまり考慮していないことですが、DNS が機能するのは、インターネット上で何かにアクセスしようとする場合だけではありません。私もそうでした。当時は、この状況全体がネットワークのトラブルシューティングに追われることになるとは知りませんでした。

私もローカル ネットワーク上のデバイスとサービスにホスト名を使用していますが、そのトラフィックをどう処理するかを知るために、これらの名前を PC の IP アドレスに変換する必要があります。したがって、私の NAS はそこに設置されており、快適に動作しており、イーサネットも正常に動作している可能性がありますが、ホスト名でアクセスしようとすると、オフラインであるかのように見えます。それは煩わしかったので、最初は ISP のせいにし、次に NAS またはその接続のせいにしました。しかし、重要な違いがありました。

IP アドレスでサービスに直接アクセスできましたが、その名前を使用しようとするとサービスがなくなったため、ネットワーク パスはおそらく問題ありません (これを理解するのに少し時間がかかりました)。ただし、名前解決が問題でした。

そして、これらのリクエストに応答する役割をローカル DNS リゾルバーに設定したため、そのサーバーで問題が発生すると、そこに接続されているあらゆるデバイスに問題が波及する可能性がありました。すべてがかなり曖昧になってきましたが、結局のところ、私が完全に過小評価していたのは、それらがすべて同じインフラストラクチャに依存しているためでした。

誤って単一障害点を構築してしまいました

DNS が機能していない間、ルーターは正常に動作していた可能性があります

私が自分用に設定した DNS リゾルバーは、ネットワークをより詳細に制御するために設定されました。 ISP に関するさまざまな問題を考慮すると、私は手を放すよりも、物事をより細かく制御することを好む傾向があります。残念ながら、私の制御傾向により、そのネットワーク上のすべてのデバイスが、利用可能な 1 台のマシンに依存するようにしてしまいました。

リゾルバが稼働している限りは、すべて問題ありませんでした。しかし、何か問題が発生した場合、ルーターは引き続きトラフィックをルーティングし、インターネットは機能する可能性がありますが、DNS ルックアップが必要なものはすべて混乱してしまいます。

この (おそらくかなりニッチな問題だと思います) 問題の症状はかなり曖昧です。さまざまなアプリ、サイト、ローカル サービスの読み込みが遅い、または読み込みがまったく拒否されることが主な問題でした。根本的な問題が依然として存在するため、ルーターを再起動しても必ずしも解決するとは限りません。デバイスを再起動しても解決しません。

2 番目のサーバーは必ずしも順番を待っているわけではありません

「プライマリ」と「バックアップ」は便利なラベルであり、普遍的なルールではありません

この時点で、2 番目の DNS サーバーを追加するのが当然の選択であるように見え始めました。最初のリゾルバーが私を失望させた場合、2 番目のリゾルバーがギアを入れて引き継ぐだけですよね?

理論的には。

これらに「プライマリ」と「セカンダリ」という名前を付けると、一方がすべての作業を行い、もう一方が必要になるまで何もせずに待機しているように聞こえますが、クライアントすべてが複数の DNS サーバーをそれほどきちんと処理できるわけではありません。たとえば、最初の DNS サーバーが応答しない場合、Windows は別の構成済み DNS サーバーに移動できます。また、応答性に基づいてどのリゾルバーが「プライマリ」であるかを変更することもできます。

つまり、この 2 番目の DNS サーバーは実際にはセカンダリではなかったという事実になります。それはむしろ隣接しているようなもので、それがいくつかの問題を引き起こしました。同じローカル ホスト名について認識し、最初のホスト名と同じ種類の回答を提供する必要がありました。

推測せずに問題を証明できる

名前とアドレスを別々にテストする

嘘は言えませんが、非常に簡単なテストで必要な答えが得られました。目標は、基本的な接続を名前解決から分離することでした。

上で述べたように、IP アドレスを入力するとローカル サービスが応答したが、ホスト名に基づいてロードされない場合は、この問題に対処している可能性があるというかなり強力な兆候です。それがわかったら、DNS に直接クエリを実行して、リゾルバーが実際に応答を返しているかどうかを確認できるようになりました。

Windows では、必要なのは nslookup や Resolve-DnsName などのツールだけです。クエリを特定の DNS サーバーに向けることができるため、元のリゾルバーと新しいリゾルバーを個別にテストして、ローカル レコードを比較できます。両方のリゾルバーが独自に適切に応答したら、最初のリゾルバーをオフラインにして、通常の検索を繰り返します。大丈夫ですか？これは、2 番目のサーバーが実際に冗長性を提供していることを示しています。

2 番目の DNS サーバーは完全に独立している必要がありました

1 つの障害で両方が停止した場合、2 つの IP アドレスは役に立ちません

もちろん、ここにはもう 1 つの落とし穴があります。それは、DNS サーバー アドレスが 2 つある場合でも、冗長性が組み込まれていない可能性があるということです。

両方のリゾルバが同じデバイス上にある限り、それらの運命はそのデバイスに結びついています。再起動するかダウンすると、両方のリゾルバーも同様に動作します。最初に設定しようとしていたフェイルセーフがないため、そのような意味でコンセプト全体が少し役に立たなくなります。

私にとっての解決策は、2 番目のリゾルバーが別の場所に存在し、独自の IP アドレスを持ち、同じローカル レコードを持つ必要があるということでした。

考え方を変えたら、失敗も意味を持ち始めた

正直なところ、DNS は必ずしも「Web サイトが読み込まれるかどうか」だけの問題ではないことを理解したことが、ここでのゲームチェンジャーでした。ローカル DNS リゾルバーはネットワークの重要な部分になっていますが、私はそれを依然として過小評価しており、重要な障害点として扱っていませんでした。他のすべてのことをすぐに責めてしまい、私は実際に必要以上にこの問題のトラブルシューティングに多くの時間を費やしてしまいました。