DNS を GD からルート 53 に移動しようとしていますが、両方の場所に同一のゾーン ファイルがあっても、ダウンタイムを回避するのは不可能のようです。私の実験では、GoDaddy で「カスタム」ネーム サーバーに変更するとすぐに DNS 要求への応答が停止し、ルート 53 も応答しません (応答する前に、権限があることを確認するのを待っているのでしょうか?)。dig でテストしたところ、次のようになりました。AWS の内部テスト ツールを使用する場合は問題ありませんが、ルート 53 ネーム サーバーの 1 つを @ にして dig を使用すると、結果が返されません。
私の考えでは、ネームサーバー レコードの TTL を低く設定し、他のすべてには TTL を長く設定します。これが問題の解決に役立つという経験のある方はいらっしゃいますか?
これは、特定の解決ネームサーバーが比較的最近レコードを照会した場合にのみ効果があることは理解していますが、実際には、すべての TTL を低く設定するよりも良いようです。TTL を低く設定すると、解決ネームサーバーが伝播ウィンドウ中に権威ネームサーバーを必要とする可能性が高くなります。
答え1
切り替える前に、新しいネームサーバーがレコードを提供していることを確認してください。まだ権限のないサーバーで DNS を構成することは許可されています。正しいデータを提供していることを確認したら、ドメイン構成のネームサーバーのリストにそれらを追加します。その後、元のネームサーバーを削除できます。
すべてのホストの TTL はすでに長くなっているはずです。これにより、ネームサーバーの変更に問題がある場合のリスクが軽減されます。ドメインのネガティブ TTL を減らして、ルックアップの失敗が長期間キャッシュされないようにすることもできます。NS レコードの TTL を減らすと、変更が簡単になります。元のネームサーバーが、そのネームサーバーを指す NS レコードの有効期限が切れる前にレコードの提供を停止すると、ネガティブ応答の提供を開始する可能性があります。
GD での私の経験からすると、GD 側で見かけ上の停止を回避することはできないかもしれません。ドメイン構成で NS レコードの TTL を短くすると、影響が軽減されます。
答え2
これは、特定の解決ネームサーバーが比較的最近レコードを照会した場合にのみ効果があることは理解していますが、実際には、すべての TTL を低く設定するよりも良いようです。TTL を低く設定すると、解決ネームサーバーが伝播ウィンドウ中に権威ネームサーバーを必要とする可能性が高くなります。
DNSリゾルバ（DNSサーバまたはDNSサーバのクライアント）が以前にDNSレコードを検索したことがある場合、それらのレコードはその時点で有効なTTLに従ってキャッシュされます。事後にTTLを増やしたり減らしたりしても、そのシナリオでは何も変わりません。新しいTTLは、新しいルックアップ。