前回「(2/2)ちょっとした疑問:有線DNSと代替DNS設定」のつづき。
優先DNSに設定されたIPアドレスを持つDNSサーバに対しての名前解決が問題なく実行可能な状況であっても、代替DNSが参照され代替DNSから応答された名前解決情報をDNSクライアントが参照することもある、という点ご報告しました。
じゃあどんなケース？ってのを考えてみました。
ネットワークの障害
例えば、分かりやすいのはネットワーク障害です。優先DNSへの通信断となれば当然サーバへアクセスできなくなりますので、代替DNSが使われるのは当然の動作です。ここまでは想定できますが、応答遅延次第で代替DNSが使われるとなるとどうでしょう？通信ができるのにDNSサーバは代替DNSが使われる、ということになってしまいます。
応答遅延が長いためクライアント側で勝手に通信断と判断して代替DNSを利用する、というケースです。
ある程度の規模があると、ネットワークの状態によって（ないしネットワーク内のノードの状態によって）意外と応答遅延がタイムアウト値を超えるケースは割と起こります。一時的にpingがtime outしてしまう（俗に言うping抜け）ようなネットワークであれば、ネットワークの経路次第で優先DNSのアクセスに影響するケースはありそうです。
この時自動的に代替DNSに参照が移ってしまうと、「なんか変だな？」と思うことはあるのですが、わざわざ「ipconfig /displaydns」コマンドを実行して現在のDNSのリゾルバキャッシュを参照する人は少ないんじゃないかと。
閑話休題：コマンド備忘録
Windowsのコマンドプロンプトで使えるDNSクライアントが参照するDNSサーバを含めた状態確認をするのに役立つコマンドの解説。
- ipconfig /displaydns
コマンドを実行するコンピュータ上で、現在参照しているリゾルバキャッシュの情報を表示することができるコマンド。
いま参照しているDNSサーバ上から入手したレコード情報が（キャッシュと言う形で）参照できるので、DNSサーバの検証作業でも使えるコマンドです。
- ipconfig /flushdns
このコマンドを実行すると、現在コマンドを実行するコンピュータ上のリゾルバキャッシュを消去することができます。
消去されたキャッシュは当然再取得することになります。
このコマンドも検証でけっこう使えるコマンドです。DNSサーバ-Aの状況を確認していたクライアントでDNS-Bに切り替わったときの状況を確認するときに、キャッシュがあるとDNS-Bでは本来出来ない名前解決もキャッシュの力で名前解決できてしまいます。このため、DNS-Bを検証する前にこのipconfig /flushdnsコマンドでリゾルバキャッシュを消去した状態でDNSサーバの検証を実施する、と言う感じ。
DNSサーバの負荷向上
DNSサーバで何らかの要因で負荷が上がることによって、名前解決のリクエストに対して応答が遅れることもあります。
DNSクライアントから見れば、「応答が遅れる＝そのDNSサーバは断だ」という事しか判断しませんので、タイムアウト値以内に応答しないDNSサーバは全部落ちてるDNSサーバと判断してしまいます。
負荷が高い状態のDNSサーバだと、DNSクライアントは勝手に「このDNSサーバは使えない状態だから代替DNSに依頼しよう」と処理を変更することによって、意図せず代替DNSサーバが使われるというケースもあるようです。
けっきょく自動だから
あと、結局のところ、「名前解決はOSの制御下にある」と言う点です。人間が都度都度アレコレ指定できないので、DNSサーバの優先/代替の設定値をどう使うかはOSであるWindowsの裁量に任されています。
Windowsがいちいち名前解決の時にどう動くかなんて、人間があれこれ介在できません。実際のところ一番これが大きいのかもしれません。
長話になってしまいましたが、優先DNSと代替DNSの使い分け、まとめると…
- あくまで冗長化目的
- 常に優先DNSと代替DNSのレコード情報は同一であることが望ましい
- 別の目的（ゾーン）の名前解決を分担するものではない
ということですね。ここに行きつくまで長くなってしまいました。
