這幾天 Google Public DNS 被炒的火熱,漂亮的 IP 位址 ( 8.8.8.8 , 8.8.4.4 ) 被瘋狂的宣傳,連我也一頭熱的研究了一番,一開始覺得速度還挺快的,網路延遲時間也很短,我猜也許已經有人開始將個人電腦的 DNS 切換過去了,但對於 168.95.1.1 的琵琶別抱真的是好事嗎,以下些許淺見供參。
Google Public DNS 官網中指出三個使用 Google Public DNS 最主要的理由:
關於 Google Public DNS 的介紹網路上已經一大堆,隨便 Google 一下就會查到許多資料,應該不用我多做一些基本的設定教學,但我可以分享一些這幾天研究的心得,對於「提升安全性」的部分無庸置疑,用國際大廠的服務真的有許多好處,此篇文章主要的著眼點在主要在於效能部分。
§ 關於 Google Public DNS 的效能 ( Performance Benefits )
DNS 的查詢速度著實會影響上網速度,主要影響 DNS 查詢速度的關鍵因素有兩項:
- 用戶端電腦 與 主要 DNS 伺服器 之間的網路延遲:這部分的網路延遲大多與 round-trip time (RTT) 的限制有很大的關係,例如:兩個端點間的距離、網路壅塞的程度、封包傳遞的品質、過載的伺服器、阻斷服務攻擊、…等等都會影響網路延遲的時間長度。
- 主要 DNS 伺服器 與 其他 DNS 伺服器 之間的網路延遲,這部分又包括三個成分:
- 快取失效(Cache misses):熟知 DNS 運作原理的人都知道當主要 DNS 沒有查詢目標的 DNS 快取紀錄時就會遞迴的向其他 DNS 伺服器解析網域名稱,這種狀況難以避免,當 DNS 的上層伺服器(權威伺服器)離主要伺服器很遠時,網路延遲就會一層一層的加上去,難保 DNS 的效率低落,導致上網速度降低,而「快取失效」這一點這也是 Google 認為是影響 DNS 查詢效率最關鍵的因素。
- 伺服器無法負荷要求(Underprovisioning):當 DNS 伺服器部署不夠數量無法負荷用戶端大量的 DNS 查詢時,通常會讓 DNS Client 等待過久,導致查詢失敗進而重新發送封包查詢 ( DNS 是走 UDP 協定 ),如果有這種狀況發生,也會大幅影響網域解析的時間。
- 惡意網路流量(Malicious traffic):即便 DNS 伺服器部署足夠,阻斷服務攻擊(DoS)也可能會造成現有的 DNS 伺服器大量的負載,以導致伺服器無法有效回應或回應惡意的 IP 位址。我去年寫的一篇文章【小心網域名稱伺服器快取毒害(DNS cache poisoning)攻擊 】就是其中一種 DNS 攻擊的形式,不但會癱瘓 DNS 伺服器,還有可能會導致 DNS 伺服器回應惡意的 IP 位址。
Google 認為 快取失效(Cache misses) 是影響 DNS 查詢效能最主要的因素,他們提供幾點改善的方案:
- 部署足夠的 DNS 伺服器 (Provisioning serving clusters adequately)
- 避免阻斷服務攻擊擴大規模 (Preventing DoS and amplification attacks)
- 有效利用負載平衡機制將 DNS 集中快取 (Load-balancing for shared caching)
- 將常用的 DNS 名稱解析集中處理快取,讓全球的 DNS 伺服器統一取得快取更新資料
- 將不常用的 DNS 名稱依據「DNS名稱」分散快取,以分散分享式快取的流量
- 積極的預先取得名稱解析 (Prefetching name resolutions)
- 在全球部署DNS伺服器以提供服務 (Distributing serving clusters for wide geographical coverage)
在台灣,也許你會用 HiNet 的 DNS 服務,眾所周知的 168.95.1.1 已經是家喻戶曉的 IP 位址,幾乎大部分 IT 人員都是用這個 IP 作為主要 DNS 伺服器,就連有些非 HiNET 的 IDC 甚至還會建議客戶直接使用 HiNet DNS 作為主要伺服器,相信我,用它準沒錯,他要是掛了,全台灣差不多有 80% 網路會斷線,這就跟大公司會買 IBM 伺服器或 Cisco 路由器的理由一樣:「他要是有問題我也沒輒」。
對於 Google 這種對於全球公開的 DNS 伺服器來說,那可沒那麼簡單,由於全球網路如此之大,Google 不可能在每一個國家、每一個地區都有機房,你確定你用的 8.8.8.8 真的離你很近嗎?或許是!但你確定在 Google Public DNS 中被快取的 IP 真的是離你最近的 IP 嗎?那可不一定!
CDN (Content delivery network) (內容傳遞網路) 機制是我最近研究的網路技術之一,CDN 利用許多機制降低 用戶端 與 伺服器端 之間的網路延遲,大多數 CDN 業者都至少會同時實做好幾種機制,例如 Anycast (BGP), Global Server Load Balancing, DNS-based request routing, Dynamic metafile generation, HTML rewriting, … 等等。( 備註:Google Public DNS 使用 Anycast routing ) 其中的 DNS-based request routing 機制最為常見,CDN 業者提供的 DNS 伺服器會利用 來源 DNS 解析伺服器 的 IP 位址判斷出來源 IP 的地理位置,再依據 IP 所在地理位置來選擇回應由來源 IP 位置連線到他們全球伺服器中最接近該位置的伺服器,以降低網路延遲時間。
由於這個機制會依據 來源 DNS 解析伺服器 的 IP 位址判斷出來源 IP 的地理位置,所以若採用 Google Public DNS 來解析 IP 位址時就不一定能得到離你最近的 IP 位址,因此連 Google 本身也無法保證在這種情況下你能得到的最有效率的瀏覽體驗!請看以下紅框標注的段落:
你覺得採用 CDN 機制的網站很少嗎?其實只要是跨國且超大流量的網站幾乎都會採用 CDN 機制,所以你常用的 Hotmail, Facebook, Plurk, Twitter, … 等網站全部都採用 CDN 分散網路流量,但若透過 Google Public DNS 來上網,難保你能得到最佳瀏覽體驗!
不過,這並非絕對,只能說「無法保證」而已,而且 CDN 能實做的機制非常多,不止 DNS-based request routing 而已,所以並非所有 CDN 網路都會因為 Google Public DNS 而導致瀏覽速度降低,還是有許多 DNS 以外的優化方案,不然你想想看全球採用單一 8.8.8.8 這個 IP 都可以讓各地的網路延遲時間都可以低於 50ms 是什麼道理,網路世界博大精深,不是一篇文章可以講完的 ^^
也許有些比較小咖的 CDN 業者或自行實做 GeoDNS 的網站,可能就會遭受 Google Public DNS 的荼毒,所以到底要推廣 Google Public DNS 還是不要推廣呢?這真是個難為的決定阿!不過至少我短期內不會採用。
相關連結