Google 和 OpenDNS 改進了 DNS 協定

Google和OpenDNS，這是網絡上兩個最受歡迎的公共名稱解析服務，已經提出並實施了 DNS協議擴展 這將允許 提高速度 使用來自內容分發網絡的資源時的導航。

大型內容分發公司的服務器在稱為“內容分發網絡（CDN）”的系統中遍布全球。一個很好的例子是Akamai，它是第三方公司的文件存儲。

如果我們假設CDN擁有為所有國家/地區復制了所有可用內容的國家/地區的專用服務器，則與將所有內容集中在一個位置相比，所獲得的巨大優勢是，從理論上講，對內容的訪問時間得以最小化。例如，塞維利亞的用戶將與其在西班牙的服務器通信，而不是與美國的總部進行通信。

為此，CDN使用DNS系統，該DNS系統基於發出請求的計算機的IP地址可以找出其來源，並以最接近該國家或地區的內容服務器的IP進行響應。

但是，當沒有越來越多的網絡用戶不使用其運營商提供的DNS並在其計算機上配置公用的公共用戶（例如Google或OpenDNS）時，這不再是理想的選擇，例如，將這兩個示例命名為參與本文。

我們在瀏覽器欄中編寫網頁loquesea.eu。
不知道該名稱對應哪個IP的計算機從其已配置的DNS服務器（1）（運營商或其他運營商）請求轉換。
如果我們假定該服務器的緩存為空，則您將不得不向所謂的根服務器尋求幫助，該服務器將告訴您哪個服務器負責所有尋址.eu空間（2）。
然後重複該操作。在這種情況下，我們已配置的DNS服務器將詢問（3）有關名稱為loquesea.eu及其子域受其控制的服務器的所有.eu名稱的負責人（例如，linebenchmark.loquesea.eu）。
最後，向該最後一個服務器發出最後一個DNS請求，該服務器將返回loquesea.eu的IP地址（4），並將其傳遞到第一個實例中發起查詢的計算機（5），以最終打開HTTP會話並下載網站（6）。

如您所見，這是一個相當複雜的過程，儘管它在網絡用戶看來是透明的。

我們提到的用於傳統CDN的DNS系統的問題如下：由於DNS協商是由中間服務器進行的，以獲取所需目的地的IP，因此CDN會將Google DNS服務器檢測為請求的來源，在美國。鑑於此，CDN會以其美國（而非西班牙）的服務器IP進行響應。我們會因為延遲增加而失去性能。

為解決此問題，已設計出DNS協議的一種修改形式，以利用在 RFC 2671 使名稱解析更智能。

這個想法叫做全球互聯網加速它仍然在草稿階段，它有助於提供客戶端的原始地址，並將其作為另一個數據字段添加到請求中（“ edns-client-subnet”）。

儘管實際上，為了維護用戶的隱私，發送的內容是用戶的公共IP地址的一部分（從末尾消除了比特），因此將其截斷而不是發送1.2.3.4（如果這是用戶的公共IP）。 1.2.3.0（所有中間DNS服務器將能夠讀取此信息），並附帶一個24位網絡掩碼。

這樣，使用Google的DNS沒關係，因為當用戶信息作為請求中的數據附加時，如果目標服務器與此新計劃兼容，它將能夠正確地確定您真正想要從哪裡開始使用最接近客戶端的服務器訪問其內容並進行回答，從而最大程度地減少了等待時間，從而提高了瀏覽速度。

對於那些對自己的隱私更加懷疑的人，可以對其進行配置，以便不發送用戶IP地址的任何部分（發送0.0.0.0/0）。在這種情況下，我們知道該服務將像CDN中的傳統DNS一樣工作。這就是說，CDN不知道其真實來源，將以最接近發出請求的DNS服務器的IP進行響應。

目前，Google和OpenDNS都已經在其係統上安裝了此新功能，它們是與CDNetworks，EdgeCast，BitGravity和Akamai本身一起開發的，這對草稿的編寫有所幫助。

儘管目前尚不清楚這將對網絡的實際性能產生多大影響，但IETF最終採用這種技術作為運營商也可以採用的標準（在其當前的草案版本中）還是完全不合理。在決賽中。

來源：寬帶

Google和OpenDNS對DNS協議進行了改進