ネームサーバーの変更と伝播は部分的に機能します：米国では成功し、インドでは失敗します
私たちのドメインはEnomでホストされています。 DNSレコードは、Pugmarksと呼ばれるEnomのインドの再販業者の下で管理されています。 DNSレコード管理サービスをEnom/ResellerからAWSRoute53に切り替えたいと考えていますが、Enomをドメインレジストラとして保持しています。
ドメインのDNSレコードのTTLは300（5分）です。ネームサーバーのTTL）を確認したところ、3600（1時間）であることがわかりました。
EnomネームサーバーをRoute53サーバーに置き換えると、Enomはドメインの解決を即座に停止しました。 TTLの有効期限が切れた後、ISP DNSサーバーがそれに続きました。GoogleAnalyticで観察されたように、当社のWebサイトのトラフィックは減少しました。この影響は理解されています。
しばらくして、次のようなパブリック/オープンネームサーバーを介してドメインのNSレコードをクエリすると、4.2.2.2-4.2.2.6および8.8.8.8＆8.8.4.4が得られます。 Route53を指す更新されたレコード：すなわち
Dig NS <domain.com> @8.8.4.4.
上記のコマンドは、Route53ネームサーバーレコードを表示します。同様に、他のすべてのレコード（A、CNAMEなど）が正常に表示され、ネームサーバーの変更がこれらのDNSサーバーによって正常に取得されたことを示します。この時点で、GoogleAnalyticで米国のトラフィックスケーリングを観察します。
しかし、インドのトラフィックは依然としてゼロのままです。 2つの異なるインドのISP（一般公開されていない/ ISPユーザーに制限されている）からいくつかのDNSサーバーに問い合わせました。これらはレコードを返しません。 ISPが記録の変更に追いつくのを4時間待ちましたが、無駄でした。
米国の地域が新しいレコードを取得できたのは奇妙ですが、私たちが試したインドのISPのどれも（少なくとも5つは）変更を選択できませんでした。 Web上の他のすべてのDNSテストツールは、ここのISPを除いて変更を選択できました。サイトがターゲットとしているのはオーディエンスであるため、トラフィックが大幅に減少することが大きな懸念事項になります。
4時間の待機と監視の後、エントリをEnomネームサーバーに戻しました。インドのISPは、TTLが1時間であるにもかかわらず、常にEnomサーバーにレコードを照会しているかのように、ほんの数秒でレコードを解決できました（Route53は引き続き解決されるため、米国トラフィックは変更されませんでした）
私には2つの疑問があります：
- インドのISPは、ドメインのNSを1時間以上、おそらく48時間キャッシュしています
- 私にはわからないインド地域に関するいくつかの問題。
ポイント1は、私に関する限り、主な容疑者です。これが link で、ドメインの詳細を示しています。親ネームサーバーは48時間TTL、ローカルネームサーバーは1時間TTL）と表示されます。これが問題の原因である可能性がありますか？
DNS管理をRoute53に移行したいのですが、6時間以上ダウンタイムが発生することはありません。私たちは4時間まで無駄に試しました。
なぜこれが起こっているのですか、そしてその方法は何ですか？
おそらく、1つの代替手段は、すべてのDNSレコードを49時間に保持することですTTL（TTLがTTL for NS record at親）そして、このTTL変更のレコード伝播後にネームサーバーを切り替えます。ただし、これは絶対確実ではありませんが、試すことができます。
（これは古い質問ですが、それでも回答に値します）
どうやらあなたがしたことはこれでした：あなたはあなたのドメインの質問に権威を持って答えるために新しいネームサーバーを準備しました。次に、登録を切り替えました（つまり、comを担当する親DNSサーバーのdnsindia.comのNSエントリを新しいDNSサーバーを指すように変更しました）。同じ瞬間に、古いネームサーバーはdnsindia.comに関するクエリへの応答を停止しました（またはNXDOMAINなどで応答しました）。
結果として、特に主な対象者にとっての影響は次のとおりでした。1時間後、インドのISPのDNSリゾルバーにキャッシュされたデータはすべて古くなりましたが、www.india.comのAレコードなどのエントリのデータのみでした。 。したがって、リゾルバーは適切なネームサーバーに新しいデータを照会しようとします。ただし、情報whichクエリするサーバーはまだエージングアウトしていません：その情報はcomゾーンから取得され、48時間のTTL）でした（したがっておそらくまだ最大47時間、たとえば平均24時間）。これは古いプロバイダーで現在は機能していないDNSサーバーを指しているため、観察したとおりに障害が発生します。一方、リモートリゾルバーのクエリは、成功する可能性が低いため成功します。親NSレコードのキャッシュされたコピーがあります。
それを正しく行う方法は？次の戦略が可能です（優先度の高い順に）。
a）古いDNSサーバーが移行後少なくとも48時間（親TTL）ゾーンにサービスを提供し続けることを確認しますが、それより長くはなりません。実際、これは私がほとんどの時間使用している方法です。古いサーバー管理者は、後日ゾーンを削除することを忘れないでください。
b）古いDNSサーバーが再帰クエリを許可していることを確認します（少なくともゾーンに対して、少なくとも48時間）。一部のゾーンの「公式」DNSサーバーであるサーバーは、通常、再帰クエリを許可することに注意してくださいnot
c）ゾーンを移動する前に、たとえば、すべてのレコードのローカルTTLを96時間に変更します。次に、移動を行う前に48時間待ちます。このように、リゾルバーは通常、DNSレコードのコピーをキャッシュに保持する必要があります。これは、廃止されたNSレコードよりも長く存続します。この方法は完全ではなく、ドメイン間に「相互参照」がある場合、またはメインよりもクエリの頻度が少ないレコードがある場合は特に問題になります。記録。
d）または、ゾーンを移動する前に親 TTLを1時間（または許容できると思われるダウンタイム）に）、48時間待ってから移動します。Howevre、親ゾーンでTTLをこのような低い値に変更することはできない場合があります（頻繁に照会されることは望まない）。その場合でも、変更する必要があります。ゾーンの更新スケジュールを検討する