低 DNS 延遲是快速網路瀏覽的關鍵。 為了最大限度地減少這種情況，仔細選擇 DNS 伺服器和 。 但第一步是擺脫無用的查詢。
這就是 DNS 最初被設計為高度可緩存協定的原因。 區域管理員為各個條目設定生存時間 (TTL)，解析器在將條目儲存在記憶體中時使用此資訊以避免不必要的流量。
快取有效嗎？ 幾年前，我的小研究顯示它並不完美。 讓我們來看看目前的情況。
收集我修補的信息 儲存響應的 TTL 值。 它被定義為每個傳入請求的記錄的最小 TTL。 這很好地概述了真實流量的 TTL 分佈，並且還考慮了各個請求的受歡迎程度。 伺服器的修補版本運行了幾個小時。
產生的資料集包含 1 筆記錄（名稱、qtype、TTL、時間戳記）。 以下是總體 TTL 分佈（X 軸是以秒為單位的 TTL）：
除了 86 的小幅波動（主要針對 SOA 記錄）之外，很明顯 TTL 處於較低範圍內。 讓我們仔細看看：
好的，大於 1 小時的 TTL 沒有統計意義。 然後我們關注 0−3600 的範圍：
大多數 TTL 為 0 到 15 分鐘：
絕大多數是 0 到 5 分鐘：
這不太好。
累積分佈使問題更加明顯：
一半的 DNS 回應的 TTL 為 1 分鐘或更短，四分之三的 TTL 為 5 分鐘或更短。
但等等，實際上情況更糟。 畢竟，這是來自權威伺服器的 TTL。 然而，客戶端解析器（例如路由器、本機快取）從上游解析器接收 TTL，並且每秒都會減少。
因此，在發送新請求之前，客戶端實際上可以平均使用每個條目的原始 TTL 的一半。
也許這些非常低的 TTL 只適用於不尋常的請求，而不適用於流行的網站和 API？ 我們來看一下：
X軸是TTL，Y軸是查詢流行度。
不幸的是，最受歡迎的查詢也是最難快取的。
讓我們放大一下：
結論：這真的很糟糕。 以前已經很糟糕了，但現在更糟了。 DNS 快取實際上已經變得毫無用處。 隨著使用 ISP 的 DNS 解析器的人越來越少（有充分的理由），延遲的增加變得更加明顯。
DNS 快取僅對無人存取的內容有用。
另請注意，該軟體可能 解釋低 TTL。
為什麼這樣？
為什麼 DNS 記錄設定為如此低的 TTL？
- 舊版負載平衡器保留預設設定。
- 有傳言稱 DNS 負載平衡取決於 TTL（事實並非如此 - 自 Netscape Navigator 時代以來，客戶端從一組 RR 中選擇一個隨機 IP 位址，如果無法連接，則透明地嘗試另一個 IP 位址）
- 管理員希望立即套用更改，以便更輕鬆地進行規劃。
- DNS 伺服器或負載平衡器的管理員將其任務視為有效部署使用者請求的配置，而不是加快網站和服務的速度。
- 低 TTL 讓您高枕無憂。
- 人們最初為測試設定了較低的 TTL，然後忘記更改它們。
我沒有將「故障轉移」包含在清單中，因為它變得越來越不相關。 如果您需要將使用者重新導向到另一個網路只是為了在其他所有內容損壞時顯示錯誤頁面，那麼超過 1 分鐘的延遲可能是可以接受的。
此外，一分鐘的 TTL 意味著如果權威 DNS 伺服器被阻止超過 1 分鐘，則其他人將無法存取相關服務。 如果原因是配置錯誤或駭客攻擊，冗餘也無濟於事。 另一方面，如果 TTL 合理，許多客戶端將繼續使用先前的配置，而不會注意到任何事情。
CDN 服務和負載平衡器在很大程度上要歸咎於低 TTL，特別是當它們將具有低 TTL 的 CNAME 和具有同樣低（但獨立）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 記錄過期時，都必須發送新的請求。 兩者都有 30 秒 TTL，但並不相同。 實際平均 TTL 將為 15 秒。
可是等等！ 情況更糟。 在這種情況下，一些解析器的行為非常糟糕，有兩個相關的低 TTL：
$ 鑽 raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com。 1 在 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
至少三個 CNAME 記錄。 哎呀。 一個有不錯的 TTL，但完全沒用。 其他 CNAME 的初始 TTL 為 60 秒，但對於域 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 相同的問題，使用 Level1 解析器時，TTL 大部分時間會卡在 3 秒鐘。
Dropbox？
$ 鑽 client.dropbox.com @8.8.8.8 client.dropbox.com。 7 在 CNAME client.dropbox-dns.com 中。 client.dropbox-dns.com。 59 在 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 值為 60 秒，如 Facebook 網域。 而且，從客戶的角度來看，這些價值又減半了。
設定最小 TTL 怎麼樣？
使用名稱、請求類型、TTL 和最初儲存的時間戳，我編寫了一個腳本來模擬透過快取解析器的 1,5 萬個請求，以估計由於快取條目過期而發送的不必要請求的數量。
47,4% 的請求是在現有記錄過期後提出的。 這是不合理的高。
如果設定最小TTL會對快取產生什麼影響？
X 軸是最小 TTL 值。 來源 TTL 高於此值的記錄不受影響。
Y 軸是來自已擁有快取條目但已過期並正在發出新要求的用戶端的請求的百分比。
只需將最小 TTL 設定為 47 分鐘，「額外」請求的比例就從 36% 減少到 5%。 透過將最小 TTL 設定為 15 分鐘，這些請求的數量會下降到 29%。 最小 TTL 為 1 小時會將其減少至 17%。 顯著差異！
如何不更改伺服器端的任何內容，而是在客戶端 DNS 快取（路由器、本機解析器）中設定最小 TTL？
所需請求數從 47% 下降到 TTL 至少為 34 分鐘的 5%、至少 25 分鐘的請求數量下降到 15%、至少 13 小時的請求數量下降到 1%。 也許 40 分鐘是最佳時間。
這個小小的變化的影響是巨大的。
後果是什麼？
當然，服務可以轉移到新的雲端供應商、新的伺服器、新的網絡，要求客戶端使用最新的DNS記錄。 相當小的 TTL 有助於平穩且不易察覺地進行這種轉換。 但隨著向新基礎架構的過渡，沒有人期望客戶端能夠在 1 分鐘、5 分鐘或 15 分鐘內遷移到新的 DNS 記錄。 將最小 TTL 設定為 40 分鐘而不是 5 分鐘不會阻止使用者存取服務。
然而，這將透過避免不必要的請求來顯著減少延遲並提高隱私性和可靠性。
當然，RFC 規定必須嚴格遵守 TTL。 但現實是DNS系統已經變得太低效了。
如果您使用權威 DNS 伺服器，請檢查您的 TTL。 你真的需要這麼低的值嗎？
當然，為 DNS 記錄設定較小的 TTL 有充分的理由。 但 75% 的 DNS 流量幾乎保持不變，情況並非如此。
如果由於某種原因您確實需要對 DNS 使用低 TTL，請同時確保您的網站未啟用快取。 出於同樣的原因。
如果您正在執行本機 DNS 快取，例如 它允許您設定最小 TTL，請使用此功能。 這可以。 不會有什麼不好的事情發生。 將最小 TTL 設定為約 40 分鐘（2400 秒）1 小時。 相當合理的範圍。
來源： www.habr.com