頻繁に変更されるDNSレコード？[閉まっている]

頻繁に変更できるドメインレコードを作成するにはどうすればよいですか？

をexample.org指すとしましょう203.0.113.0。2分後、それはを指す必要があり198.51.100.0ます。

ドメインの背後にある通常のWebサイト（一般的なWebブラウザを使用してアクセスされるという意味でのみ「通常」）ですが、寿命は非常に短くなります。ドメインは、切り替えられるかシャットダウンされるまで、最大で3〜4時間アドレスを指します。DNSサーバーを頻繁なクエリから保​​護する必要はありません。

私のアプローチは、TTLを60秒に設定し、切り替えが必要になったときにレコードを変更することです。最悪の場合、新しいサーバーにアクセスできるようになるまで最大60秒待機することになります。

どういうわけか私はこれを信用していません...一部のISPまたはブラウザは、TTLを無視またはオーバーライドできませんでしたか？有効な懸念事項である場合、予想される合理的なTTLはどうなりますか？

ありがとうございました！

これはFast Flux DNS Recordsと呼ばれます。そして、通常、マルウェア作成者がインフラストラクチャサーバーを隠す方法です。

これは計画には有効ですが、最適な計画ではありません。予備のサーバーまたはそれ以上のサーバーがオンラインで必要になる可能性が高く、ほとんど何もしません。メインサーバーに問題がある場合にのみ、次のサーバーに切り替えます。

TTLが1分の場合でも、1つのレコードはそれよりも長く有効である可能性が高くなります。

1. ブラウザーのキャッシュ

   ブラウザは通常、一定時間DNSレコードをキャッシュします。Firefoxは60秒、Chromeは60秒、IE 3.x以前は24時間、IE 4.x以上は30分間キャッシュします。

2. OSキャッシュ

   Windowsは通常TTLを尊重しません。DNDのTTLは、IPv4パケットのTTLとは異なります。必須のリフレッシュというよりも新鮮さを示しています。Linuxでは、DNS TTLを無視して、ユーザーが望む時間を設定するようにnscdを構成できます。たとえば、1週間分のエントリをキャッシュできます。

3. ISPキャッシュ

   ISPは、トラフィックを減らすためにアグレッシブキャッシングを使用できます（そして一部は使用します）。TTLを変更できるだけでなく、アップストリームDNSサーバーに問い合わせることなく、レコードをキャッシュしてクライアントに返すことができます。これは、モバイルISPがTTLを変更するため、モバイルISPでより一般的になり、モバイルクライアントがトラフィックの待ち時間について文句を言うことがなくなります。

ロードバランサーは、まさにあなたが望むことをするように作られています。ロードバランサーを配置すると、2つまたは4つまたは10のサーバーを同時にすべてオンラインにして、負荷を分割できます。それらの1つがオフラインになっても、サービスは影響を受けません。DNSレコードを変更すると、サーバーが停止してからDNSが変更されるまでの間にダウンタイムが発生します。ダウンタイムを検出し、レコードを変更し、それらが伝播するのを待つ必要があるため、1分以上かかります。

そのため、ロードバランサーを使用します。あなたがしたいことをするように作られており、あなたは何を期待するかを正確に知っています。高速フラックスDNSセットアップでは、結果が不整合になります。

DNSとその仕組みには、ITのあらゆる側面として、誤解、伝説、迷信、神話が含まれている可能性があります。

変更の「伝播」について話すとき、私たちが本質的に嘘をついている（または少なくとも劇的に単純化しすぎている）ことを知っている私たちでさえ、その用語を使用して、同時に、非常にシンプルで簡単なものを記述する傾向があります...まだ説明するのは難しい...と伝播自体とは関係ありませんが、キャッシングとネガティブキャッシングに関係するすべては、どちらもシステムの動作方法の重要なコンポーネントです（そしておそらく、それが完全な崩壊を避ける方法自重）-本質的に裏返しであり、実際の「伝播」の反対であり、引っ張るのではなく、引っ張る。

短いTTLについてのすべての心配と手間については、単純に試してみることがあなたの利益になるかもしれないという点まで、あまり頻繁に動作しない傾向があります。$ {day_job}で、サイトが「古い」プラットフォームから「新しい」プラットフォームに移行すると、多くの場合、インフラストラクチャ内で何も共有されないような方法で移行していることを意味します。このような移行の最初のステップは、古いTTLが複数の倍数を使い果たすように、TTLをカットの前に60秒に十分に落とすことです。 」カットの準備ができたら、古いバランサー¹を再設定して、インターネットを介してトラフィックを新しいシステムにヘアピンし、バランサーが複数の内部システムのバランスをとるのではなく、「

次に、DNSをカットオーバーし、新しいバランサーと古いバランサーを監視します。

移行がどれほど迅速に行われるかについて、私はいつも嬉しく驚いています。ホールドアウトは、ほとんどの場合、古い記録を不可解に把握する検索スパイダーおよびサードパーティの「ヘルスチェック」サイトであるようです。

しかし、予想どおりに壊れるシナリオが1つあります。ユーザーのブラウザーウィンドウが開いたままの場合、ユーザーは既に検出されたアドレスにラッチする傾向があり、多くの場合、すべてのブラウザーウィンドウが閉じるまで保持されます。

しかし、上記の説明では、問題の解決策が見つかります。「ロードバランサー」、具体的にはより正確にはリバースプロキシが、公開されたDNSレコードが指すシステムになります。

次に、リバースプロキシは正しいターゲットIPアドレスに要求を転送します。これは、短いTTLを持つ2番目の「ダミー」ホスト名を使用して解決し、実際のバックエンドサーバーを指します。ダミーDNSエントリを使用すると、迅速かつ完全なスイッチオーバーが保証されます。

欠点は、不要な追加インフラストラクチャを介してトラフィックをルーティングしたり、複数のネットワーク境界を越えたトランスポートに余分な費用をかけたりする可能性があることです。

この種の機能を世界規模で提供するサービスがありますが、私が最もよく知っているのはCloudFrontです。（ほとんどの場合、Cloudflareはまったく同じ目的に役立つでしょう。これは、私が行ったテストのわずかな量が、正しく動作することを示しており、他にもあるはずです。）

主にCDNとして販売されていますが、CloudFrontは、オプションで応答をキャッシュする機能を備えたリバースプロキシのグローバルネットワークです。場合www.example.comCloudFrontのとCloudFrontをするポイントは、これらの要求を転送するように構成されbackend.example.com、およびのためのDNSレコードbackend.example.comの用途短いTTLそれは短いTTLという名誉をしているため、その後、CloudFrontをは、正しいことを行います。バックエンドレコードが変更されると、TTLが停止するまでにトラフィックがすべて移行されます。

CloudFrontを指しているフロントサイドレコードのTTL、およびブラウザーとキャッシュリゾルバーがそれを尊重しているかどうかは重要ではありませんwww.example.com。は、www.example.comバックエンドシステムがどこにあるかに関係なく、正しいターゲットに関して一貫しています。

私にとって、これは、オリジンサーバーのIPに対する変更を「追跡」する必要性をブラウザから解放することにより、問題を完全に解決します。

tl; dr：リクエストを実際のWebサーバーのプロキシとして機能するシステムにルーティングします。これにより、プロキシ設定のみが、オリジンサーバーIPの変更に対応する必要があります。ブラウザ側のDNSではありません。

CloudFrontは、フロントサイドに課すDNSマジックによって遅延も最小化www.example.comするため、クエリを実行するブラウザーの場所に基づいて、最適なCloudFrontエッジの場所に解決されるwww.example.comため、トラフィックが不必要に迂回する可能性が最小限に抑えられます。ブラウザからエッジ、オリジンまで...しかし、この部分は透過的かつ自動であり、質問の範囲外です。

そしてもちろん、コンテンツキャッシングは、オリジンサーバーまたはトランスポートの負荷を減らすことによっても価値があります-オリジンサーバーがADSL回線上にあり、ADSLが本質的にアップストリーム帯域幅に制約されているCloudFrontでWebサイトを構成しました。コンテンツを取得するためにCloudFrontが接続するオリジンサーバーは、AWSエコシステム内のサーバーである必要はありません。

¹実際には複数のノードを持つバランサーを単一のエンティティーと呼んでいます。バランサーがELBの場合、バランサーの背後にあるマシンはダミーアプリサーバーとして機能し、ELBが単独でこれを行うことができないため、新しいプラットフォームのバランサーに実際のヘアピンを行います。

²古いバランサーに関する古いバランサーの唯一の知識は、古いバランサーのX-Forwarded-Forを信頼する必要があり、古いバランサーの送信元アドレスに対してIPベースのレート制限を行わないことです。

³プロキシが制御する1つ以上のサーバーである場合、バックサイドでDNSを使用せずに、プロキシ設定でIPアドレスを使用するだけのオプションがありますが、後で説明するホスト/分散シナリオではDNSの2番目の層が必要。

DNSレコードを変更すると、多くの場合、古いIPアドレスが数か月間使用されます。そうは言っても、ほんの数秒のTTLは、たとえばAmazonがフォールバックサービスを作成するために使用するものです。

DNSを変更する代わりに、その前にプロキシサーバー/ロードバランサーを配置できます。

ダイナミックDNSの使用を検討できます。これは、@ glglglが上記のコメントで言及したシナリオに正確に合わせて設計されています。以前に指摘したように、クライアントが自由に無視できるため、100％効果的ではない可能性がある低TTLを使用していると思います。しかし、それは「かなりうまく」動作します。

IPを頻繁に変更しない場合でも、TTLを合理的に保つことが重要です。何年も前、私が働いていた会社が変更されたISPで働いていたため、IPが変更されました。残念ながら、TTLを1か月などとんでもない値に設定していたため、古いDNSレコードが長い間保持されていました。