DynamicDNSはどのようにすぐに機能しますか？

Question

DNSのコア機能についての私の理解は、ドメイン名（例：blah-whatever.com）とIPアドレス（例：100.2.3.4）の間にネーミング/マッピングサービスを提供することです。

さらに、インターネットDNSサーバーがどのように機能するかについての私の理解は、ドメイン/ IPマッピングレコードが変更されたとき（たとえば、blah-whatever.comを105.2.3.4を指すように変更すると、など）、この変更が「完全」であると言える前に、この変更を世界中のすべてのDNSサーバーに伝播する必要があります。この伝播期間は、最大24時間続く場合があります。

そもそも、これまでに私が言ったことが間違っていたり間違っていたりした場合は、まず訂正してください！

私が多かれ少なかれ正しいと仮定すると、CloudFlareやDynamicDNSのような企業がDNSレコードを変更する「インスタントロールオーバー」タイプのサービスをどのように提供できるのか理解できません---ブーム-変更即座に影響します。

このインスタントロールオーバー機能で役割を果たす "TTL"（存続時間、私は推測します？！？）これはTTLであるか、それがどのような目的に役立つかです。

だから私は尋ねます：ダイナミックDNSとその競合他社がDNSマッピングを即座に変更できるのは何ですか（他の人のようにDNS変更を伝播するのに24時間かかることはありません）、そしてTTLはどのように適合しますか？このプロセス？よろしくお願いします。

Der Hochstapler · Accepted Answer

DNSの変更がどのように伝播されるかについていくつかの誤解があったため、以前の回答には誤った情報が含まれていました。それで、ここに2番目の試みがあります。詳細な説明については、 Alex answer をお読みになることをお勧めします。

私の理解では、DNSの変更がどれだけ速く伝播するかに関係する2つの要因があります。

ゾーンに対して権限のあるDNSサーバー間のゾーン転送。
TTLそのゾーンの単一レコードに設定されます。

ゾーン転送

ゾーンを管理するために2つの異なるネームサーバーが必要な場合、これらのサーバーでそのゾーンの最新バージョンをすぐに利用できるようにする必要があります。

これは、ゾーンの最新バージョンを一定の間隔でプルするか、承認されたネームサーバーから [〜＃〜] notify [〜＃〜] を待機することで実現されます。

このメカニズムは、ネームサーバーを実行するユーザーの完全な制御下にあるため、この領域での遅延は完全に制御できます。

TTL

[〜＃〜] ttl [〜＃〜] は、ゾーン内のすべての単一リソースレコードに指定されたタイムアウトです。この値は、権限のないDNSプロバイダーがレコードをキャッシュする期間を定義します。

この値は、既存のレコードが変更された場合にのみ機能することに注意してください。新しいレコードはまだキャッシュできません。

TTLもゾーンを制御する人の完全な制御下にあることを考えると、遅延も完全に制御できます。

Alex · Answer

あなたはいくつかの誤解を持っているので、プロセス全体を説明しようと思います。（私はパブリックダイナミックDNSサービスの運用に関わっていたので、詳細に満足しています）。

ドメインがexample.comであるとしましょう。動的DNS会社でホストされているexample.comドメインを、たとえばlightfastdns.net（架空の名前）としましょう。ドメインにDNSレコード-somehost.example.comが含まれています。これは現在1.1.1.1をポイントしています。

DNSレコードに変更を加えると、この変更はまずlightfastdns.netによって運営されている中間サーバーに送信されます。 pdates.lightfastdns.net。これはほぼ瞬時に発生します（数分の1秒）。 Webインターフェース、動的更新クライアント、または一部のAPIを介して更新を送信できます。それは問題ではありません。いずれにしても、この更新はDNS更新を処理するサーバーに到着します。
この更新サーバーは、更新されたレコード（たとえば、1.2.3.4）をドメインの "master" DNSサーバーにプッシュします。このDNSサーバーはlightfastdns.netによっても運用されています。発生速度：DNSプロバイダーによるソフトウェアの設計方法によって異なります。（これは瞬時に行うことも、24時間ごとにすることもできます。たとえば、gandi.netはDNS更新を1時間に1回プッシュします。）もちろん、lightfastdns.netは即座に実行します。
このmaster DNSサーバーは、更新をslave DNSサーバーにプッシュしますexample.comドメイン。このサーバーも同じlightfastdns.net会社によって運営されています。これが発生する速度：最新のソフトウェアではmasterは即座にNOTIFYメッセージをslavesに送信し、マスターから更新されたレコードを即座に取得します。古いソフトウェアでは、SOAレコードにREFRESHとRETRYの値がありましたが、今日はほとんど関係ありません。もちろん、lightfastdns.netはNOTIFYを実装し、更新は即座に反映されます。

現在、ドメインのすべての「権限のある」サーバーが更新されたレコードを受信しました（1.2.3.4）。 lightfastdns.netの場合、約2秒かかりました。

ここで、ロシアのIvanの家に移動します。Ivanは、ブラウザで「somehost.example.com "」を開きたいと考えています。彼が以前にそれを開いたことがない場合、彼のブラウザはアドレスを知らないので、ブラウザは尋ねる彼のオペレーティングシステムになります。ただし、最近サイトにアクセスした場合は、アドレスがブラウザ内に保存されている可能性があり、古い（廃止された）アドレスを使用します。どれだけの時間？ -ブラウザによって異なりますが、Google ChromeはDNSレコードを最大60秒間のみ保存します。最大60秒の遅延があります。このため、私はDNSの変更はまだこのブラウザに伝播しなかったと言います。
いずれにせよ、60秒後、またはすぐに、ブラウザは最終的にオペレーティングシステムにアドレスの取得を要求します。オペレーティングシステムは既に（古い、廃止された）回答を知っていて、それを返す可能性があります。この場合、新しいレコードはIvanのOSにまだ伝播しなかったと思います。 OSが古い値を保存する期間-これは[〜＃〜] ttl [〜＃〜]パラメータによって制御されます。 [〜＃〜] ttl [〜＃〜] DNSでは、レコードをキャッシュに保存できる期間を定義します。 lightfastdns.net非常に低い使用が許可されていますTTL-30秒なので、全体で最大30秒の新しい遅延が発生しました-90秒）これまでのところ。
OSが回答を知らない場合、または認識していた回答がTTLによって古くなった場合、OSはDNSリゾルバーを要求します（IvanのISPは彼にDNSリゾルバーを割り当てましたdns.moscow-telecom.r）。ここで、古いレコードは最大でTTL=秒、またはdns.moscow-telecom.rがアドレスを認識していない可能性があります。次のように、さらに30秒取得します。 dns.moscow-telecom.r DNSもTTL値。120秒遅延があります。これが呼ばれるものです。新しいDNSレコードがMoscow-Telecom's DNSサーバーにまだ伝達されていないこと。
ISPのDNSサーバーが回答を認識していない場合、またはTTL期限切れ-dns.moscow-telecom.rであるため、ISPが知っていた回答がすでに廃止されている場合of [〜＃〜] authoritative [〜＃〜] DNSサーバーexample.net（覚えていますか？）約118秒前に変更が加えられました。彼らは新しい答えを返します。この答えは、チェーンによってDNSリゾルバー、OS、およびIvanのブラウザーにすぐに送信されます。

したがって、さまざまなキャッシュの状態に応じて、レコードの伝播には2〜120秒かかりました。長いTTL-長い遅延が発生する可能性があります。

完全にするために--some ISPは標準に違反し、レコードを長期間キャッシュします。一部の古いOSは長い間古い記録を保持しており、古いブラウザもそうです。ただし、ほとんどのユーザーにとっては、期待どおりに機能します。

Hennes · Answer

いいえ。変更はないに伝播する必要があります世界中のすべてのDNSサーバー。

何かを変更し、誰かがDNSサーバー上の変更されたレコードを照会した場合、結果は即座に発生します。

問題は、以前にこの名前を照会したときにキャッシュされた場合です。次に、キャッシュが期限切れになるまで古いIPを取得します。 DNSでは、古いクエリの有効期間を設定でき、その期間は多くの場合数日に設定されます。 DynDNSの場合、通常は低く設定されますが、すべてのDNSリゾルバーがそれを受け入れるわけではありません。