リゾルバ変更したのに元のサーバにクエリが行く

DNSサーバのIPアドレス変更を行ったので、担当のSEさんにそれを参照しているサーバ（RedHat5）でリゾルバの向き先（/etc/resolv.conf）を変更して頂いたのですが、Firewallで確認したところ変更前のIPに対してDNSのクエリが投げられている現象が出ていて、SEさんに確認をお願いしていたのですが

何時間か経っても回答が出ず、症状は治まらない。
実際のところサーバ上で動作しているサービスには何の支障も出ていなかったのですが、ワンポイントで切り替えという状況から、稼働日までには何とかしておくべき状況になっていたため、結局調べることに。。。

同サーバ上でnscdのサービスが動作していて、リゾルバの変更後にサービスを再起動していなかったのが原因だったのですが、、、ちょっと過程がお粗末だったので。
現象発生を連絡してから何時間も先方が調べていたのはGUI上でのネットワーク設定でリゾルバのの向き先が変わっていることの確認を繰り返していただけ。CLIからの確認すらしていませんでした。
設定変更後にサーバの再起動を行ったか聞いたのですが、再起動していますという答えだったので、内部でnamedのサービス動かしていませんか？とか色々問診していました。（もちろん、その時点でFirewallのアクセスログにクエリがかかれていたのことは確認していたので、サーバ上の設定に問題があることは明らかだった訳ですが。）

そうこうしているうちにかなり時間も無くなってきて流石にヤバイと思ったので、とりあえずtcpdumpをdst port 53で縛ってモニタしてサーバからDNSのクエリが出ていることを確認した後、netstat -anpで53番ポートにクエリを投げているプロセスを特定してnscdが原因と判明しました。あとはservice nscd restartでサービスを再起動して症状が収まりました。時間にして１０分〜２０分程度。

あれ？サーバ再起動したって言ってませんでした？と聞いたのですが、いやサービス再起動しただけです・・・と。それサーバ再起動じゃないやん。。。ま、そんな感じで原因究明までに多大な時間を費やしてしまいました。

結局何が問題だったかという話ですが、サーバ側で現象が起きている状況でサーバ上で実際に何が起きているかの確認をしなかった事と、原因として考えられる事のリストアップ→リスクを含めた実行可否の検討→試作の実施という改善の為の一連のプロセスが行われなかった事じゃないかと。

実際には上にのっているサービスを動作させることが目的ですが、得てしてシステム側のSEさんはそれがOSの設定であったとしてもネットワーク動作については自分の責任範囲ではないと暗黙の認識を持たれている場合があるようです。