レジストラが失敗しましたか、それともネームサーバーの伝播がどのように機能するのですか？
そのため、私の会社には、名前のない大規模なレジストラを持つドメインがいくつかあります。 DNSインフラストラクチャにいくつかの変更を加えています。最初の変更は、セカンダリDNSをオンサイトの1台のサーバーからオフサイトの4台のサーバーに移動することです。そこで、古いセカンダリネームサーバーのエントリを削除し、4つの新しいネームサーバーを追加することで、レジストラの各ドメインのネームサーバーを更新しました。古いセカンダリサーバーのリクエストを監視し、24時間新しいリクエストが行われなかったのを確認したら、サーバーをシャットダウンしました。それは今朝でした。この時点で、すべてが良かったと思いました。残念ながら、これは私の間違いでした。行って、ネームサーバー全体が正しいNSレコードを返していることを確認する必要がありました。
そのため、今日の午後、プライマリDNSサーバーのメンテナンスを実行し、シャットダウンしました。これは、外部モニタリングからアラートを受け取り始めたときです。確認したところ、そこで使用されたDNSサーバーは、プライマリドメインのNSレコードはプライマリネームサーバーのみでした。新しいセカンダリサーバーはリストされておらず、古いセカンダリもリストされていませんでした。
更新がからだったので、それを仮定するのは私には不合理ですか？
ns1.mydomain.com
ns2.mydomain.com
に
ns1.mydomain.com
ns1.backupdns.com
ns2.backupdns.com
ns3.backupdns.com
ns4.backupdns.com
レジストラでの1つのステップで、NSレコードがns1.mydomain.com用であった中間状態があってはなりませんか？
安全を確保するために、新しいネームサーバーが伝播したことを100％確認するまでは、古いネームサーバーをそのままにして、レジストラから古いネームサーバーを削除します。ただし、レジストラが失敗したのか、それとも期待が無理だったのかを知りたいのですが。
更新が<...トリミングされた...>からのものであると想定するのは私には不合理ですか？
[〜＃〜] yes [〜＃〜]。
一般的に言って、[〜＃〜] any [〜＃〜]についての仮定をすることは不合理です- [〜＃〜] any [〜＃〜]コントロールパネルソフトウェアを介して実行される変更（ねじ込むという標準的な仮定を除く）どういうわけか）。
これには、DNSレジストラ管理インターフェイスが含まれます（通常、バックエンドではかなりひどいです）。
行った変更は、おそらく2つの別々のトランザクション（1つは古いサーバーの削除、もう1つは新しいサーバーの追加）として処理され、誰かが最初のトランザクションの後、2番目のトランザクションの前にDNS情報を取得しました。
私たちの多くがそうしている方法ではありますが、あなたは一種の間違っていたので、ここで少し得ました。
将来的には、DNSサーバーを廃止する/新しいサーバーに置き換える場合の安全なワークフローは次のとおりです。
- 新しいDNSサーバーを構築して展開します。それらが正しく機能していることを確認します。
- 新しいDNSサーバーをレジストラのネームサーバーのリストに追加します。
- 待機（変更がインターネット全体で取得されるまで）
TTLに依存しますが、通常は24〜48時間が適切なルールです。- この時点で、新しいサーバーでクエリが表示されるようになります。
- レジストラのネームサーバーのリストから古いDNSサーバーを削除します。
- 待機再び（変更がインターネット全体で取得されるまで）
廃止されたサーバーへのクエリの表示を停止する必要があります。
（3）と同様に、24〜48時間は適切なルールです。 - 古いサーバーのプラグを抜き、会社のポリシーに従って廃棄してください。
そのワークフローは、最悪のシナリオでは、「ステップ2」の情報を使用しているため、誰かが余分な（不完全な）NSをリストすることになるが、alwaysにはすべての新しいセカンダリがあるので、alwaysは少なくとも1つの動作するものを見つけることができるはずですドメインのネームサーバー。
ステップ2、3、4、および5を1つのステップに結合し、バックエンドで、追加（2）の前に削除（4）が行われました。
変更の「追加」部分に全員が追いつく前にメンテナンスが行われることを除いて、問題が発生することは決してない可能性があります。それは古典的なエッジケースであり、あなたはそれに着陸しました。
今、あなたは知っています、そして知ることは戦いの7/16です。