ドメインネームシステム(DNS)レイテンシは、優れたオンライン体験を得るための重要な要素です。 また、DNS遅延を最小限に抑えるために、DNSサーバーと匿名化リレーを慎重に選択することが重要な役割を果たします。 しかし、待ち時間を最小限に抑える最善の方法は、無駄なクエリを送信しないようにすることです。 そのため、DNSは初日からキャッシュ可能なプロトコルになるように設計されていました。 個々のレコードには、もともとゾーン管理者によって設定されたtime-to-live(TTL)があり、リゾルバーはこの情報を使用してこれらのレコードをメモリに保持し、不要なトラキャッシュは効率的ですか？
私が数年前に行った簡単な研究では、改善の余地があることが示されました。 今日、私は情勢の現在の状態を新たに見てみたいと思います。これを行うために、暗号化されたDNSサーバーにパッチを適用して、受信クエリごとに、レコードの最小TTLとして定義された応答の元のTTLを格納しました。 これにより、実際のトラフィックのTTL分布の概要がわかりますが、個々のクエリの人気も説明されます。
そのパッチを適用したバージョンは、数時間のために実行するために残っていました。 結果のデータ-セットは、1,583,579(name、qtype、TTL、timestamp)タプルで構成されます。 これは全体的なTTL分布です（X軸は秒単位のTTLです）：
86,400（主にSOAレコードのための）で無視できるバンプに加えて、Ttlが低い範囲にあることはかなり明白です。 ズームインしましょう：
さて、1時間以上のTtlは統計的に重要ではありません。 のは、0–3,600の範囲に焦点を当ててみましょう：
大部分は0から5分の間です。
累積分布は、問題をさらに明白にする可能性があります:
インターネットの半分は1分以下のTTLを持ち、四分の三は5分以下のTTLを持っています。しかし、待って、これは実際には悪いです。
しかし、これは実際には悪いです。 これらは、権限のあるサーバーで定義されているTtlです。 ただし、クライアントリゾルバ(ルーター、ローカルキャッシュなど)から取得されたTtlは、上流リゾルバが毎秒デクリメントするTTLを取得します。 したがって、平均して、新しいクエリを要求する前にクライアントがキャッシュされたエントリを使用できる実際の期間は、元のTTLの半分です。
おそらく、これらの非常に低いTtlは、一般的なwebサイトやApiではなく、一般的なクエリにのみ影響します。 見てみましょう：
残念ながら、最も一般的なクエリもキャッシュするのが最も無意味です。 ズームインしてみましょう:P>
なぜですか？NSレコードがこのような低いTtlで設定されているのはなぜですか？
- 従来のロードバランサーはデフォルト設定のままです。
- DNSベースの負荷分散がTTLsに依存するという都市伝説（そうではありません）。
- 管理者は、計画作業を少なくする必要があるため、変更をすぐに適用したいと考えています。
- DNSまたはロードバランサー管理者として、あなたの義務は、webサイトやサービスを高速にするのではなく、人々が尋ねる構成を効率的に展開することです。
- 低TTLsは心の平和を与えます。
私はそのリストに’for failover’を含めていません。 他のすべてが燃えているときにfail whaleページを表示するためだけに、ユーザーを別のネットワークにリダイレクトすることを意図している場合は、1分以上の遅延が許容される可能性があります。
CDNsとロードバランサーは、特にCNAMEレコードと短いTTLsを組み合わせ、短い（しかし独立した）TTLsを持つレコードを組み合わせる場合、主に責任があります。
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
CNAMEまたはaレコードのいずれかが期限切れになるたびに新しいクエリを送信する必要があります。 彼らは両方とも30秒のTTLを持っていますが、位相はありません。 実際の平均TTLは15秒になります。
しかし、待ってください！
これは悪いです。 いくつかのリゾルバは、このような低TTL-CNAME+低TTL-recordsの状況ではかなりひどく動作します。
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
これはLevel3のリゾルバであり、BINDを実行していると思 そのクエリを送信し続けると、返されるTTLは常に1になります。 基本的に、raw.githubusercontent.com キャッシュされることはありません。非常に一般的な名前を特徴とするlow-TTL-CNAME+low-TTL-records状況の別の例を次に示します。
:
$ drill detectportal.firefox.com @1.1.1.1detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net.detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net.detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net.a1089.dscd.akamai.net. 10 IN A 104.123.50.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
三つ以上のCNAMEレコード。 痛い そのうちの一つは、まともなTTLを持っていますが、それは全く役に立たないです。 他のCnameに60秒の元のTTLがあります;akamai.net 名前の最大TTLは20秒であり、そのどれも位相にありません。どのようにあなたのAppleデバイスが常にポーリングするものはどうですか？
Firefoxと同じ設定で、Level3のリゾルバを使用する場合、TTLはほとんど1に固定されます。Dropboxはどうですか？
p>
$ drill client.dropbox.com @8.8.8.8client.dropbox.com. 7 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 59 IN A 162.125.67.3$ drill client.dropbox.com @4.2.2.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com TTLは60秒です。 Facebookの名前は60秒のTTLを持っています。 そして、もう一度、クライアントの観点から、これらの値は半分にする必要があります。
最小TTLを設定してみてはどうでしょうか？
最初に保存された名前、クエリタイプ、TTL、タイムスタンプを使用して、キャッシュリゾルバを通過する1.5万以上のクエリをシミュレートするスク クエリの47.4%は、既存のキャッシュされたエントリの有効期限が切れた後に行われました。 これは不当に高いです。
最小TTLが設定されている場合、キャッシュへの影響はどうなりますか？
X軸は設定された最小TTLです。 元のTTLがこの値よりも高かったレコードは影響を受けませんでした。 Y軸は、既にキャッシュされたエントリを持っていたが、新しいクエリが作成され、キャッシュされたエントリの有効期限が切れていたクライアント最小TTLを5分に設定するだけで、クエリの数は47％から36％に低下します。 最小TTLを15分に設定すると、必要なクエリの数は29%に減少します。 1時間の最小TTLは、それが17％に低下させます。 それは大きな違いです！
サーバー側では何も変更しないで、クライアントDNSキャッシュ（ルーター、ローカルリゾルバー、キャッシュ…）に最小TTLを設定させるのはどうですか？
必要なクエリの数は、最小TTLを5分に設定することで47％から34％に、最小TTLを15分に設定することで25％に、最小時間を13％に設定します。 40分はスイートスポットかもしれません。 その最小限の変更の影響は巨大です。
意味は何ですか？
もちろん、サービスは新しいクラウドプロバイダー、新しいサーバー、新しいネットワークに切り替えることができ、クライアントは最新のDNSレコードを使用す そして適度に低いTTLsを持っていることは転移を摩擦自由にさせるのを助ける。 ただし、新しいインフラストラクチャに移行する人は、クライアントが1分、5分、または15分以内に新しいDNSレコードを使用することを期待しません。
最小TTLを5分ではなく40分に設定しても、ユーザーがサービスにアクセスできなくなることはありません。 しかし、遅延を大幅に削減し、不要なクエリを回避することにより、プライバシー（より多くのクエリ=より多くの追跡機会）と信頼性を向上させます。もちろん、RfcはTtlは厳密に尊重されるべきだと言っています。 しかし、現実には、DNSが非効率的になっているということです。権限のあるDNSサーバーを運用している場合は、TTLsを再訪してください。 あなたは本当にこれらが途方もなく低くする必要がありますか？読む：DNS TTL値を選択する方法
確かに、低DNS TTLsを使用する正当な理由があります。 しかし、インターネットの75％が主に不変であるが、キャッシュするのは無意味なコンテンツを提供することはできません。 また、何らかの理由で、低DNS Ttlを本当に使用する必要がある場合は、キャッシュがwebサイトでも機能しないことを確認してください。 非常に同じ理由のために。最小Ttlの設定を許可するdnscrypt-proxyなどのローカルDNSキャッシュを使用する場合は、その機能を使用します。 これは大丈夫です。 悪いことは何も起こりません。 その最小TTLを40分（2400秒）から1時間の間のものに設定します。に登場した元の投稿から適応
00f.net