低 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 分鐘或更短，四分之三的 DNS 回應的 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 合理，許多客戶端將繼續使用先前的配置並且不會注意到任何事情。
低 TTL 主要是 CDN 服務和負載平衡器的錯誤，尤其是當它們將具有低 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：
$drill 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
至少三筆 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？
$drill 用戶端.dropbox.com@8.8.8.8 用戶端.dropbox.com。 7 IN CNAME client.dropbox-dns.com。客戶端.dropbox-dns.com。 59 在 162.125.67.3 $drill client.dropbox.com @4.2.2.2 client.dropbox.com。 1 IN CNAME client.dropbox-dns.com。客戶端.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%。透過設定 15 分鐘的最小 TTL，這些請求的數量下降到 29%。最短 TTL 為 1 小時會將其減少至 17%。明顯差異！
為什麼不在伺服器端進行任何更改，而是在客戶端 DNS 快取（路由器、本機解析器）中設定最小 TTL？
當設定最小 TTL 為 47 分鐘時，所需請求的數量從 34% 減少到 5%，當設定最小 TTL 為 25 分鐘時，所需請求的數量從 15% 減少到 13%，當設定最小 TTL 為 1 小時時，所需請求的數量從 40% 減少到 XNUMX%。也許最佳值是XNUMX分鐘。
這微小變化的影響卻是巨大的。
後果是什麼？
當然，服務可以遷移到新的雲端供應商、新的伺服器、新的網絡，要求客戶端使用最新的 DNS 記錄。相當小的 TTL 有助於平穩且難以察覺地實現這種轉變。但是隨著向新基礎設施的過渡，沒有人期望客戶在 1 分鐘、5 分鐘或 15 分鐘內遷移到新的 DNS 記錄。將最短生存期設定為 40 分鐘而不是 5 分鐘不會阻止用戶存取該服務。
但是，透過避免不必要的請求，這將顯著減少延遲並提高隱私和可靠性。
當然，RFC 指出必須嚴格遵守 TTL。但現實情況是，DNS系統已經變得效率太低了。
如果您正在使用權威 DNS 伺服器，請檢查您的 TTL。你真的需要這麼低的價值嗎？
當然，為 DNS 記錄設定較小的 TTL 是有充分理由的。但對於 75% 幾乎保持不變的 DNS 流量來說則不然。
如果由於某種原因您確實需要對 DNS 使用低 TTL，也請確保您的網站上未啟用快取。出於同樣的原因。
如果您正在執行本機 DNS 快取，例如 ，它允許您設定最小 TTL，請使用此功能。這很好。不會發生任何不好的事情。將最小 TTL 設定為約 40 分鐘（2400 秒）和 1 小時。相當合理的範圍。
來源： www.habr.com
