DNS 遅延が低いことは、高速インターネット ブラウジングの鍵です。 これを最小限に抑えるには、DNS サーバーとサーバーを慎重に選択することが重要です。 匿名リレー。 ただし、最初のステップは、無駄なクエリを削除することです。

DNS がもともとキャッシュ可能なプロトコルとして設計されたのはこのためです。 ゾーン管理者は個々のエントリの生存時間 (TTL) を設定し、リゾルバはエントリをメモリに保存するときにこの情報を使用して、不要なトラフィックを回避します。

キャッシングって効果あるの？ 数年前、私のちょっとした調査で、それが完璧ではないことがわかりました。 現在の状況を見てみましょう。

パッチを適用した情報を収集するため 暗号化されたDNSサーバー 応答の TTL 値を保存します。 これは、各受信リクエストのレコードの最小 TTL として定義されます。 これにより、実際のトラフィックの TTL 分布の概要がわかり、個々のリクエストの人気度も考慮されます。 パッチを当てたバージョンのサーバーは数時間動作しました。

結果のデータセットは、1 レコード (名前、qtype、TTL、タイムスタンプ) で構成されます。 全体的な TTL 分布は次のとおりです (X 軸は秒単位の TTL)。

86 という小さな上昇 (主に SOA レコードの場合) を除けば、TTL が低い範囲にあることは明らかです。 詳しく見てみましょう:

そうですね、1 時間を超える TTL は統計的に有意ではありません。 次に、0 ～ 3600 の範囲に注目してみましょう。

ほとんどの TTL は 0 ～ 15 分です。

大部分は 0 ～ 5 分です。

あまり良くないですね。

累積分布により、問題はさらに明らかになります。

DNS 応答の半分の TTL は 1 分以下、5 分の XNUMX の TTL は XNUMX 分以下です。

しかし、待ってください、実際にはもっと悪いです。 結局のところ、これは権威サーバーからの TTL です。 ただし、クライアント リゾルバー (ルーター、ローカル キャッシュなど) は上流のリゾルバーから TTL を受け取り、それは XNUMX 秒ごとに減少します。

したがって、クライアントは実際に、新しいリクエストを送信する前に、平均して元の TTL の半分の間、各エントリを使用できます。

おそらく、これらの非常に低い TTL は、一般的な Web サイトや API ではなく、異常なリクエストにのみ適用されるのでしょうか? 見てみましょう:

X 軸は TTL、Y 軸はクエリの人気度です。

残念ながら、最も人気のあるクエリはキャッシュに最も悪いものでもあります。

拡大してみましょう:

評決：本当にひどいです。 以前からひどい状態だったのですが、さらに悪化しました。 DNS キャッシュは事実上役に立たなくなりました。 ISP の DNS リゾルバーを使用する人が (正当な理由により) 減少するにつれて、遅延の増加がより顕著になります。

DNS キャッシュは、誰もアクセスしないコンテンツに対してのみ役に立ちます。

また、ソフトウェアによっては、 さまざまな方法で 低い TTL を解釈します。

これはなぜですか？

DNS レコードがこれほど低い TTL に設定されているのはなぜですか?

• 従来のロード バランサーはデフォルト設定のままになりました。
• DNS ロード バランシングは TTL に依存しているという誤解があります (これは真実ではありません。Netscape Navigator の時代以来、クライアントは RR のセットからランダムな IP アドレスを選択し、接続できない場合は透過的に別の IP アドレスを試してきました)。
• 管理者は変更をすぐに適用したいので、計画が立てやすくなります。
• DNS サーバーまたはロード バランサーの管理者は、サイトやサービスの速度を上げることではなく、ユーザーが要求する構成を効率的に展開することが自分の仕事であると考えています。
• TTL が低いため、安心感が得られます。
• 最初はテスト用に低い TTL を設定し、その後変更するのを忘れてしまいます。

「フェイルオーバー」の関連性はますます薄れてきているため、リストに「フェイルオーバー」を含めませんでした。 他のすべてが完全に壊れているときに、エラー ページを表示するためだけにユーザーを別のネットワークにリダイレクトする必要がある場合は、おそらく 1 分以上の遅延は許容されます。

さらに、1 分の TTL は、権威 DNS サーバーが XNUMX 分を超えてブロックされた場合、他の誰も依存サービスにアクセスできなくなることを意味します。 また、構成エラーやハッキングが原因の場合、冗長性は役に立ちません。 一方、適切な TTL を使用すると、多くのクライアントは以前の構成を使い続け、何も気付かないでしょう。

CDN サービスとロード バランサーが低い TTL の主な原因であり、特に CNAME と低い TTL を組み合わせ、同様に低い (ただし独立した) TTL を持つレコードを組み合わせた場合に顕著です。

$ drill raw.githubusercontent.com
raw.githubusercontent.com.	9	IN	CNAME	github.map.fastly.net.
github.map.fastly.net.	20	IN	A	151.101.128.133
github.map.fastly.net.	20	IN	A	151.101.192.133
github.map.fastly.net.	20	IN	A	151.101.0.133
github.map.fastly.net.	20	IN	A	151.101.64.133

CNAME またはいずれかの A レコードの有効期限が切れるたびに、新しいリクエストを送信する必要があります。 どちらも TTL は 30 秒ですが、同じではありません。 実際の平均 TTL は 15 秒になります。

ちょっと待って！ それはさらに悪いことです。 一部のリゾルバーは、XNUMX つの低い TTL が関連付けられているこの状況では非常に悪い動作をします。

$ ドリル raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com。 1 IN CNAME github.map.fastly.net。 github.map.fastly.net。 1 で 151.101.16.133

Level3 リゾルバーはおそらく BIND 上で実行されます。 このリクエストを送信し続けると、常に TTL 1 が返されます。 raw.githubusercontent.com キャッシュされることはありません。

以下は、非常に人気のあるドメインでのこのような状況の別の例です。

$ drill detectportal.firefox.com @1.1.1.1
detectportal.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.106
a1089.dscd.akamai.net.	10	IN	A	104.123.50.88

少なくとも 60 つの CNAME レコード。 ああ。 XNUMX つは適切な TTL を持っていますが、まったく役に立ちません。 他の CNAME の初期 TTL は XNUMX 秒ですが、ドメインの場合は akamai.net 最大 TTL は 20 秒で、どれも同位相ではありません。

Apple デバイスを継続的にポーリングするドメインについてはどうすればよいでしょうか?

$ drill 1-courier.push.apple.com @4.2.2.2
1-courier.push.apple.com.	1253	IN	CNAME	1.courier-push-apple.com.akadns.net.
1.courier-push-apple.com.akadns.net.	1	IN	CNAME	gb-courier-4.push-apple.com.akadns.net.
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.84
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.85

Firefox と同じ問題が発生し、レベル 1 リゾルバーを使用すると TTL がほとんどの場合 3 秒で停止します。

ドロップボックス？

$ ドリル client.dropbox.com @8.8.8.8 client.dropbox.com。 7 CNAME client.dropbox-dns.com にあります。 client.dropbox-dns.com。 59 IN A 162.125.67.3 $ ドリル client.dropbox.com @4.2.2.2 client.dropbox.com。 1 CNAME client.dropbox-dns.com にあります。 client.dropbox-dns.com。 1 で 162.125.64.3

レコーディング中 safebrowsing.googleapis.com TTL 値は Facebook ドメインと同様に 60 秒です。 そして、やはりクライアントの観点から見ると、これらの価値は半分になります。

最小TTLを設定してみてはどうでしょうか？

名前、リクエスト タイプ、TTL、および最初に保存されたタイムスタンプを使用して、キャッシュ リゾルバーを通過する 1,5 万件のリクエストをシミュレートし、期限切れのキャッシュ エントリによって送信される不要なリクエストの量を見積もるスクリプトを作成しました。

リクエストの 47,4% は、既存のレコードの有効期限が切れた後に行われました。 これは不当に高いです。

最小 TTL が設定されている場合、キャッシュにはどのような影響がありますか?

X 軸は最小 TTL 値です。 この値を超えるソース TTL を持つレコードは影響を受けません。

Y 軸は、キャッシュされたエントリがすでにあるものの、有効期限が切れており、新しいリクエストを行っているクライアントからのリクエストの割合です。

最小 TTL を 47 分に設定するだけで、「余分な」リクエストの割合が 36% から 5% に減少します。 最小 TTL を 15 分に設定すると、これらのリクエストの数は 29% に減少します。 最小 TTL が 1 時間の場合、それらは 17% に減少します。 有意差！

サーバー側では何も変更せず、代わりにクライアント DNS キャッシュ (ルーター、ローカル リゾルバー) に最小 TTL を設定してはどうでしょうか?

必要なリクエストの数は、TTL が 47 分以上の場合は 34% から 5% に、25 分以上の場合は 15% に、13 時間以上の場合は 1% に低下します。 おそらく 40 分が最適です。

この小さな変化の影響は非常に大きいです。

どのような影響がありますか？

もちろん、サービスを新しいクラウド プロバイダー、新しいサーバー、新しいネットワークに移行すると、クライアントは最新の DNS レコードを使用する必要があります。 そして、かなり小さい TTL は、そのような移行をスムーズかつ気づかれないように行うのに役立ちます。 しかし、新しいインフラストラクチャへの移行に伴い、クライアントが 1 分、5 分、または 15 分以内に新しい DNS レコードに移行することを期待する人は誰もいません。 最小 TTL を 40 分ではなく 5 分に設定しても、ユーザーはサービスにアクセスできなくなります。

ただし、これにより、不要なリクエストが回避されるため、遅延が大幅に短縮され、プライバシーと信頼性が向上します。

もちろん、RFC では TTL に厳密に従う必要があると述べています。 しかし現実には、DNS システムは非効率になりすぎています。

権威ある DNS サーバーを使用している場合は、TTL を確認してください。 本当にそんな馬鹿げた低い値が必要なのでしょうか？

もちろん、DNS レコードに小さい TTL を設定するのには十分な理由があります。 ただし、実質的に変化しない DNS トラフィックの 75% についてはそうではありません。

また、何らかの理由で DNS に低い TTL を使用する必要がある場合は、同時にサイトでキャッシュが有効になっていないことを確認してください。 同じ理由です。

ローカル DNS キャッシュが実行されている場合は、次のようになります。 dnscrypt-プロキシ最小 TTL を設定できるようにするには、この機能を使用します。 これで大丈夫です。 何も悪いことは起こりません。 最小 TTL を約 40 分 (2400 秒) と 1 時間に設定します。 かなり妥当な範囲です。

出所： habr.com