DNSをキャッシュすると、NSレコードに対してSERVFAILが返されますが、Dig + traceは同意しませんか？
この質問 は似ていますが、NSレコードを取得できない理由の紛らわしいケースについては詳しく説明していません。
キャッシュDNS環境の1つ（RHEL 5.8、BIND 9.3.6-20.P1.el5_8.4）は、ゾーンの有用なデータをまったく返さなくなりました。通常、この種の問題は古いNSまたはグルーレコードになりますが、この特定のケースでは、ゾーンのNSレコードを報告するキャッシュを取得することすらできないようです。
Dig @mycache somedomain NSはSERVFAILを返します。キャッシュされたネームサーバーレコードはまったくありません。Dig +traceは正常な委任パスを示し、最終的なネームサーバーが応答を返します。最終的なネームサーバーに対してDigクエリを手動で実行すると、有効なNSレコードが返され、対応するAレコードが存在し、接着剤などに同意します。
何が得られますか？ DNSキャッシュから取得するNSレコードがないのはなぜですか？悪いレコードでもありませんか？
NSレコードに対する信頼できる回答がない場合は、権限の決定に失敗する以外にキャッシュするものはありません。これはキャッシュされたものであり、不完全なネームサーバーに関するサーバーのメモリ内情報はDNSクライアントによって取得できません。 （というより、これはあなたが得ようとしているのと同じくらい近いです）
通常、キャッシュ内のNSレコードをインターネット上で見つけたものと比較することで、古いネームサーバーレコードの問題を特定できますが、この場合、キャッシュする権限のあるNSレコードはありません。接着剤の記録は、それ自体では信頼できません。信頼できる答えがない場合、単純に信頼できるネームサーバーはありません。
通常、ここでは次の2つのいずれかが発生しています。
Dig +traceは、ローカルキャッシュから中間ネームサーバーの古い回答を取得しており、現在、実際に問題が発生しています。 この動作については別の質問で説明しました。- 信頼できるネームサーバーを見つけるためにglueレコードを追跡しているときに、キャッシュサーバーで
NXDOMAINまたはSERVFAILが検出され、このイベントがキャッシュされました。問題が修正された場合、または接着剤が別の場所で指摘された場合でも、ネームサーバーは内部タイマーが期限切れになるまで再度要求を試みません。問題のゾーンのキャッシュパージを要求すると、通常はリセットされます。
後者の場合は通常、原因です。絶対に確認したい場合は、ネームサーバーのランタイムキャッシュをダンプして、メモリ内の接着剤を表示できる場合があります。 （つまり、BINDのrndc dumpdb）ダンプの範囲を単一のゾーンに制限できない限り、これは非常にコストのかかる操作であり、通常、高負荷のシナリオでは回避する必要があることに注意してください。