もっと前に気付こうよ！

FQDNへのpingが、二回目以降失敗するときに･･･

ユーザーにどんな影響があるのか･･･

ユーザーへのサービスで何が出来なくなるのか･･･

想像しようね。

　「FQDNへのpingが出来ました。」
という報告だけでは、もの足りない。

目の前のタスクを片付けることだけでなく、全体を見よう。何を目的としているのかを考え、常に意識しよう。

何で、問題として取り上げられるのに、こんなに時間がかかったのか、ちょっと情けない。

残念ながら、これ以上は書けない。

23 Sep 2004：追記

ある程度、書ける時期になったので、すこ〜し説明する。

どんなことが起こったのか･･･

Windows XpでIPv6をEnableして、
ping FQDN
なんてやると、最初にIPv4のAAAAレコードクエリが出て、次にIPv4のAレコードクエリがでる。IPv6のAAAAクエリでないところが、Windows XPのお馬鹿なところだ。

で、あるネットワーク機器を通過させると、Windows PCに対してのDNSアンサーが変なふるまいをした。

1. 先に出たAAAAに対してポジティブアンサーが返り、pingが成功した。
2. Aに対してはアンサーが無かったが、コマンドプロンプト上では1.のpingが成功しているので、コマンドプロンプト内の表示としては現れない。
3. 二回目のpingをすると、「そんなホストはいない」というメッセージでpingが失敗する。
4. ipconfig /displaydns
   を実行すると、pingのターゲットホストの行で、「そんなホストとはいない」メッセージである。
   ※　通常、pingが成功すると「名前解決キャッシュ」として保持し、IPアドレスとホスト名がリスト表示されるはず。
5. ipconfig /flushdns
   を実行して、名前解決キャッシュをクリアすると、pingはまた一回のみ、成功する。

任意のホストに対して、pingをFQDNで実行すると、名前解決のプロセスが先にはしる。今回、一回目には成功したにもかかわらず、二回目に失敗することが、再現性を持って確認された。IPv4のAレコードが無いことが、何らかの影響でネガティブキャッシュとなってしまっている。WindowsはIPv6で利用するDNSサーバとIPv4で利用するDNSサーバは、同じものであっても、別のものであっても、本来かまわないはずである。※　→　参考

にもかかわらず、このようなふるまいをした。これはヤバイ！と思ったので、発見した06/16中に、夕方のミーティングに出席する人に対して、�@この症状とこれから起こる�A使用上の不便さ、を説明し、会議で発表するように求めた。

ところが、pingが成功するかどうかしか気にしていなかったようで、ミーティングでは、
　「pingが成功しました。」
のみの報告であった。（バカ！だな）このことを知って、さらにこれはヤバイ！と思ったので、今度は小隊長と（会議に出た方も含む）同室の実験メンバーに対して、今度はメールで説明文を送った。

翌日（06/17）に、このメールを読んでこれはヤバイ！と思った小隊長（流石だ！）は、再確認の実験を指示、しかし、その日の夕方ミーティングでは、データを読み誤ったのか、まだ問題として認識している人は増えなかった。

時間切れになった翌日06/18、誰でも納得できるシンプルなデータを取り直して提出、小隊長から通常は分隊長以上のみが出席する、つまり分隊長ではないぼくは出席できない夕方の会議に呼ばれ、�@この症状とこれから起こる�A使用上の不便さ、を説明して、やっとこれでみんなもこれはヤバイ！と思ったようだった。（でも時間切れなんだよ！）

不都合の説明

どのような不都合が起こるかを説明する。今あなたが見ているこのページには、ページ名のファイルのテキスト（文字列）以外に、さまざまなオブジェクトを見ている。GIFやJPEGである。HTMLドキュメントには、このようにさまざまなオブジェクトのアドレスが記述されている。当該ファイルが参照しているリンク先などもだ。

このような、参照先は参照元のアクセスの次にアクセスされる。つまり、二回目のpingのような感じで。一度解決した「名前解決結果」は、キャッシュとして保持され再利用される。このキャッシュが今回、ネガティブキャッシュとして作用し、二回目のpingが失敗した。これをHTMLドキュメントのブラウズに置き換えると、画像やリンク先といった参照先オプジェクトが全て参照できないということなのだ。

ipconfig /flushdnsでネガティブキャッシュはクリアされるが、ひとつオブジェクトを参照したとたん、この参照先解決の行為そのものが、またまた、ネガティブキャッシュを生成するので、またまたまたまた、ipconfig /flushdnsをしなければならない。つまり、任意のページ上の画像オブジェクトを表示するには、その画像オブジェクトの数だけ、ipconfig /flushdnsを実行しなければならないのだ。一般ユーザーにこの操作をさせながら、インターネットwebブラウズをさせるのが現実的か？こんなことをしてインターネットサーフィンを楽しめるか？

このたび、このページに追記をしたのは、6/18にも書いたこと、

FQDNへのpingが、二回目以降失敗するときに･･･

ユーザーにどんな影響があるのか･･･

ユーザーへのサービスで何が出来なくなるのか･･･

想像しようね。 と言うことを、未だに理解しない・心がけていない人々がいるからだ。自分の担当範囲だけ良ければ、その事がほかの方々の担当範囲にどのように影響するのかを考えていないのだ。「かつて遭った不具合」の無いことを確認しなければならないのにもかかわらず、そのことを確認しようとしないお馬鹿な検証項目や手順書の出て来たりしているのだ。管理する立場の人がお馬鹿な検証項目や手順書が出てこないように気をつけていなければならないのに、気を付けていないから、またまたお馬鹿な検証項目や作業手順書が出てきているのだ。

6月当時、理解できないで会議に報告した人もお馬鹿・会議出席者で理解しなかった人もお馬鹿だが、当時会議に出席していながら、3ヶ月たった現在でも理解していない人がいることが問題である。

しっかし、どうしてこの程度の事が判らないんだろうね、まったく！これで高スキル者ばかりだなんて、よく言うぜ！。