今日は興味深い問題に直面しました。誰かがxxx1.ptとxxx2.ptという2つのドメインの別の状況に対する一時的な方法として、DNS / BINDで2つのMXレコードを急速に変更しました。
したがって、このレコードの特定のTTLを事前に減らすためのアクションは取られません。
2週間TTL以内に変更が行われました。
興味深いことに、Google DNSパブリックサーバーへの答えはまったく同じではないことが私に指摘されています。
8.8.8.8 でテストすると、まだ古いアドレスの問題が解決され、新しいアドレスに奇妙な答えが返されます。
SOAシリーズは確かに更新されました。これは、ローカルプロセス/構成を通じて人々が更新するのを忘れないように自動的に更新されるためです。
だから誰かが私になぜこのような奇妙な答えが出てくるのか、何かをすることができるのか尋ねました。BIND側から。
しかも非常に緊急Google側のキャッシュのトラブルシューティングに関しては、原因はこの問題とは関係ありません。
BIND側では何ができますか？
答え1
ここで明らかなのは、BIND側でできることは何もないということだ。
RRレコードのTTLが2週間の場合、DNSサーバーがまだキャッシュにアドレスを保持するリスクが常にあります。
Googleも漠然と暗示しているようです。一部のヘルプページでは、長いTTLに準拠しています。少なくとも3日以上。
もっと興味深いのは、新しいアドレスへの奇妙な答えは、Google DNS CDN /クラスタの一部のDNSサーバーがキャッシュをフラッシュし、新しいアドレスを取得したか、ドメインを見たことがないか、変更している可能性があることです。以前の住所は実際に見たことがありません）。あるいは、時にはCDN /他のDNSクラスタ内の他のポイントが答えを返すからです。調査されていません。
8.8.8.8 DNSサービスは単一のサーバーで提供されておらず、その背後に複雑なインフラストラクチャがあるため、家に近い場合は、他の答えがあることは特に驚くべきことではありません。
Google DNSサーバーサイドのキャッシングに関しては、大衆がランダムなDNS RRレコードをグローバルに更新できる非常に興味深いページを見つけました。ここ
問題ドメインのMXレコードキャッシュを手動で更新し、テストGoogleパブリックDNSサーバーを再利用した後、digすでに新しいRRデータが応答しています。