最近、ネームサーバーの何パーセントがTTLを尊重していますか？

数年前、あるデータセンターから別のデータセンターに機器の一部を移動したため、数週間にわたっていくつかのDNSの変更を行う必要がありました。私がこれを行った時点で、世界のネームサーバーの約95％がTTL値を尊重しているようで、約5％が私たちのものを無視して独自のものを作り上げていました。つまり、トラフィックの95％は、定義した15分のTTL内で移動しました。最初の1時間でさらに3％、1日目に1％で成功し、ストラグラーの中には3日までかかった人もいました。

（はい、OK、トラフィックの割合とネームサーバーの割合を混同しています。手振りを挿入してください。）

しかし、これは2001年頃で、恐竜を使ってチューブを通してパケットを送信していました。私の推測では、今日のネームサーバーはより良い振る舞いをしており、ストラグラーの問題はそれほどないでしょう。最近、定義されたTTL内でトラフィックの何パーセントが切り替わるのかを誰もが感じていますか？TTLを無視するネームサーバーがまだたくさんありますか？

私たちは最近引っ越し、DNSにあらゆる種類の問題がありました。

私たちがスイングを行ったとき、ほとんどの顧客はすぐに新しいIPにアクセスし始めました。しかし、数週間はまだ古いIPを使用していました。サーバーを1か月ほど放置しました。最終的に、古いマシンのIISログを調べ、顧客に電話をかけて、そこにある会社またはISP DNSサーバーのDNSをフラッシュするように指示しました。それが彼らの最後を引っ越しました。

古いIPを保持しているのは少数の人々でした。20,000人の顧客のうち、最初の日以降に50人が問題を抱えていました。

（非常に）長いTTL値の週は、ほとんどのDNS解決ネームサーバーで最大2週間、2011年5月に尊重されます。

just-dnslookup.comを使用したテストでは、50個のグローバル分散アクティブ測定ポイントがあり、AレコードTTLが99.999.999 = 165週間（正確な場合：165週間2日9時間46分39秒）に設定され、デフォルトのTTLがあります2週間（= SOA + NS TTL）。

最初の検索結果：

• 50の測定点のうち3つに対して1週間のTTL
• TTL 165週間、50の測定ポイントのうち47

連続したルックアップが返されます（元のTTL値に変換されます）：

• 50の測定点のうち3つに対して1週間のTTL
• 50の測定点のうち46の場合、2週間のTTL
• TTL 165週間、50個の測定ポイントのうち1個

デフォルトTTLが4週間（= SOA + NS TTL）に設定されている2番目のテスト（別のドメインを使用）は以下のとおりです。

最初の検索結果：

• 50の測定点のうち3つに対して1週間のTTL
• 50の測定ポイントのうち1つに対して2週間のTTL
• TTL 165週間、50の測定ポイントのうち46

連続したルックアップが返されます（完全なTTL長に変換されます）：

• 50の測定点のうち3つに対して1週間のTTL
• 50の測定点のうち47の2週間のTTL
• TTL 165週間、50個の測定ポイントのうち0個

最もよく知られている/最もよく接続されているパブリックリゾルバサービスから：

• GoogleパブリックDNS [8.8.8.8および8.8.4.4]は1日に短縮されます。
• UltraDNS [rdns（1 | 2）.ultradns.net]は、完全な165週間を誇ります。
• Sprintlink [ns（1 | 2 | 3）.sprintlink.net]は、完全な165週間です。

私は最近、いくつかのドメインのDNSを移動することで、社内のDNSへのGoDaddyからホスト私の個人サイトやプロジェクトのサイト（ええ、文字通り私の家）。全体として、私がリモートアクセスできるすべてのサイトはTTLを尊重し、適切に移行しました。同じことが、固定電話と携帯電話の両方を介して確認するように頼むことができるすべての友人によって報告されました。皮肉なことに、唯一の問題は、私が働いている$ UniversityのメインキャッシュDNSサーバーであり、キャッシュされたクエリのTTLを完全に無視しているようです（さらに、キャッシュされた結果に割り当てていたTTL値を無視しているようです）。

全体的に、TTLは十分に尊重されるようです。.comおよび.netドメインに対して権限のあるサーバーの56％が BINDを実行しており、これは明らかに標準とうまく機能しています。Cablevision / Optimum（少なくともNJでは）は、TTLを尊重するNominum CNSを使用しているようです。

これは、特にあなたの質問に対する答えではありません。むしろ、あなたのテストに関係する追加の考慮事項：

連鎖DNSリカーサーとキャッシュデーモン

レコードをキャッシュするのは、エッジDNS再帰だけではありません。時々、人々は再帰を連鎖し、これは時間を追加します。これを行うべきかどうかは、人々が何を解決しようとしているかに基づく長い議論になる可能性があります。データセンターで3つのレベルの再帰を見てきました。TTLデクリメントが常に保持されるとは限らないため、再帰を混合すると結果が混在する可能性があります。一部のオペレーティングシステムはレコードをキャッシュします。一部のシステムではnscd、dnsmasqなどの方法を使用して、ローカルの再帰の問題の影響を最小限に抑え、再帰の負荷を軽減しています。OSの特性は、リリースバージョン、キャッシングデーモン、キャッシングデーモンのバージョンなどによって異なります。

[編集]繰り返しますが、これは再帰またはキャッシュデーモンの通常の動作ではありません。私はバグのあるものを恥ずかしく思っていませんが、多くのLinuxディストリビューションにバンドルされているにもかかわらず、そのうちの1つはメンテナンスされていないと見なされます。

アプリケーションDNSキャッシュ

一部のブラウザはレコードもキャッシュします。Javaおよびその他のアプリもDNSをキャッシュします。アプリケーション内で最大ttlを制限できる場合があります。

最終結果を歪めることができる

上記の項目により、15分間のTTLを60分以上、またはそれ以上に簡単に変更できます。

これが、アプリケーションまたはWebサイトがフォールトトレランス設計で複数のアクティブノードを使用することを検討することを頻繁に提案する理由です。これにより、サイトへの1つのエントリポイントが失敗したときにクライアントがより迅速に判断し、優雅で予測可能な方法で問題を自動的に処理できます、可能であれば。 エニーキャストは、一部の企業がフェイルオーバーをある程度透過的にするために使用する1つの方法であり、DNSの変更にそれほど依存しません。また、複数のDNSレコードを使用してJavaScriptで実行できる負荷分散の巧妙な方法もあります。

古い質問ですが、新しい回答（2017年、6年後）：

1. 世界中のほぼすべてのDNSサーバーが5分で更新されるようです
2. GoogleとOpenDNSを使用すると、DNSレコードを手動でフラッシュして、伝播の更新を高速化できます

以下の実験の前に、以前にTTLを14400（秒= 4時間）から300（秒= 5分）に変更しましたが、実験の2時間前に変更しました。以前のTTLは4時間だったので、変更がわかりませんDNSサーバーが独自の最小TTLを持っていなかった場合、外に出ていただろう。

私の実験：

実験1：

権限のあるサーバーで名前からIPへの変換（Aレコード）を変更し、チェックしました。

• https://www.whatsmydns.net
• https://dnschecker.org

5分（300秒）後、これらのサイトがチェックしたグローバルサーバーの約半分が更新されていました。

7分後、1を除くすべてが更新されました。

実験2：

GoogleとOpenDNSを使用すると、特定のドメインのDNSキャッシュを手動でフラッシュできます。リンク：

• ドメインのGoogleのDNSキャッシュエントリをフラッシュします：https : //developers.google.com/speed/public-dns/cache
• ドメインのOpenDNSのDNSキャッシュエントリをフラッシュします：https : //cachecheck.opendns.com/

別のAレコードを更新し、すぐにGoogleのDNSキャッシュをフラッシュしました。彼らは私に「サインのあるすべての正方形をクリックする」3回のキャプチャを持っているので、フラッシュを完了する前に1〜2分かかりました。

4分後、これらのサイトがチェックしたDNSサーバーのうち1つだけが古いIPアドレスを持ちました。その他はすべて更新されました。

そのため、GoogleのDNSキャッシュをクリアし、権限のあるサーバーに再クエリを強制すると、おそらく世界中のサーバー全体でキャッシュの更新をトリガーすることにより、グローバルDNSの伝播を高速化したようです。

ただし、Googleフラッシュがなくても、伝播は数時間または数日ではなく数分であるように見えます。