效能優點
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
簡介：DNS 延遲的原因和緩解
當網頁變得較為複雜，參照多個網域的資源時，DNS 查詢可能會成為瀏覽體驗的一大瓶頸。當用戶端需要透過網路查詢 DNS 解析器時，視解析器必須查詢的名稱伺服器和名稱伺服器數量而定，延遲時間可能會十分重要 (超過 2 個很少見，但可能會發生這種情況)。舉例來說，以下螢幕截圖顯示 Page Speed 網站效能評估工具回報的時間。每個長條都代表從該頁面參照的資源；黑色區段表示 DNS 查詢。在這個頁面中，網頁載入的前 11 秒內會進行 13 次查詢。
雖然系統會同時完成多筆查詢，但螢幕截圖顯示需要 5 個序列查詢時間，也就是總 11 秒的頁面載入時間總共需要幾秒。
DNS 延遲時間包含兩個部分：
- 用戶端 (使用者) 和 DNS 解析伺服器之間的延遲時間。
在大多數情況下，這主要是因為網路系統的一般往返時間 (RTT) 限制所引起：用戶端與伺服器機器之間的地理距離、網路壅塞、封包遺失和長時間重新傳輸延遲時間 (平均為一秒)、超載伺服器、阻斷服務攻擊等。
- 解析伺服器與其他名稱伺服器之間的延遲時間。
此延遲來源主要由下列因素造成：
- 快取失敗。如果無法從解析器的快取提供回應，但需要以遞迴方式查詢其他名稱伺服器，增加的網路延遲時間就非常可觀，特別是當權威伺服器是遠端的遠端伺服器時。
- 佈建中。如果 DNS 解析器超載，這些解析器必須將 DNS 解析要求和回應排入佇列，也可能開始捨棄及重新傳送封包。
- 惡意流量。
即使超額佈建 DNS 服務，DoS 流量仍會在伺服器中放置超載。同樣地，Kminsky 式攻擊也可能涉及洪水解析器，透過查詢保證略過快取，且需要傳出要求才能解析。
我們認為快取失敗因素是 DNS 延遲最主要的原因，詳情如下。
快取失敗
即使解析器擁有豐富的本機資源，與遠端名稱伺服器之間的基本延遲卻很難避免。換句話說，假設解析器已佈建足夠的容量，讓伺服器端的快取命中無時時間，在延遲方面快取失敗仍非常高。如要處理失敗，解析器必須至少與一個通訊，但通常是兩個以上的外部名稱伺服器。我們執行 Googlebot 網路檢索器後，觀察到名稱伺服器回應要求的平均解析時間平均為 130 毫秒。
不過，由於 UDP 封包遺失率及伺服器無法連線，導致 4-6% 的要求只會逾時。如果我們考量封包遺失、無效名稱伺服器、DNS 設定錯誤等失敗情況，則「實際」的平均端對端解析時間為 300-400 毫秒。不過，差異很大且長尾都很長。
雖然快取失敗率可能因 DNS 伺服器而異，但快取失敗很難避免，原因如下：
- 網際網路的規模和成長。
簡言之，隨著網際網路不斷增加，無論是新使用者還是新網站，大多數內容都是邊緣利益。儘管有少數網站 (也是 DNS 名稱) 非常熱門，但大多數使用者僅適用於少數使用者，而且很少存取。因此，大多數要求都會導致快取失敗。
- 低存留時間 (TTL) 值。
DNS 存留時間值呈現較低的趨勢，代表解析需要更頻繁的查詢。
- 快取隔離。
DNS 伺服器通常是部署在負載平衡器後方，負載平衡器則會隨機將查詢指派給不同的機器。這會導致個別伺服器維護單獨的快取，而無法重複使用共用集區的快取解析度。
因應措施
在 Google 公用 DNS 中，我們實作了幾種方式來縮短 DNS 查詢時間。其中有些做法相當符合標準，有些則是實驗性質：
- 請適當佈建伺服器，以處理用戶端流量的負載，包括惡意流量。
- 防範 DoS 和擴大攻擊雖然這大多是安全性問題，而且會影響關閉的解析器數量少於開放解析器，但能消除 DNS 伺服器帶來的額外流量負擔，這麼做也能改善效能。如要瞭解我們採用哪些方法來盡量降低攻擊風險，請參閱安全性優點相關頁面。
- 共用快取的負載平衡：提高服務叢集的匯總快取命中率。
- 提供全球涵蓋範圍，以便觸及所有使用者。
適當佈建供應叢集
快取 DNS 解析器執行的作業必須比正式名稱伺服器更高，因為許多回應無法從記憶體提供，而是需要與其他名稱伺服器進行通訊，因此需要大量網路輸入/輸出。此外，開放式解析器很容易遭受快取毒害嘗試，進而提高快取中毒嘗試率 (例如攻擊專門針對無法透過快取解析的假名稱傳送要求)，以及增加流量負載的 DoS 攻擊。如果解析器未充分佈建，且無法跟上負載，可能會對效能產生嚴重負面影響。封包會遭到捨棄且需要重新傳輸、名稱伺服器要求必須排入佇列等。這些因素都會造成延誤。
因此，為高流量輸入/輸出佈建 DNS 解析器非常重要。這包括處理潛在的 DDoS 攻擊，唯一有效的解決方案就是超額佈建許多機器。但同時，您也不應在新增機器時降低快取命中率；這種做法需要實作有效的負載平衡政策，詳情請見下文。
共用共用快取的負載平衡
新增機器來調度解析器基礎架構資源，實際上可以執行反向作業，並在負載平衡未正確的情況下降低快取命中率。在一般部署作業中，負載平衡器位於負載平衡器後方，該負載平衡器會使用循環式等簡單的演算法，將流量平均分配給每部機器。這會讓每部機器都有各自的獨立快取，以便隔離不同機器間的快取內容。如果每個傳入的查詢都會分配至隨機機器，視流量的性質而定，有效快取失敗率可能會按比例提高。舉例來說，如果名稱的存留時間過長，且重複查詢，系統可能會依據叢集中的機器數量，提高快取錯誤率。(如果名稱的存留時間很短、經常查詢頻率極低，或導致無法快取回應 (0 存留時間和錯誤)，新增機器並不會影響快取失敗率。
如要提高可快取名稱的命中率，請務必採用負載平衡伺服器，以免快取無法分段。Google 公用 DNS 分為兩種層級。在單一機器中，與使用者之間的非常接近，每個機器的小型快取則包含最熱門的名稱。
如果無法從這項快取滿足某項查詢，系統會將查詢傳送至另一個機器集區，並按名稱分區快取。以這個第二層快取來說，相同名稱的所有查詢都會傳送至同一部機器，而此名稱可以快取或不會。
分配放送叢集以擴大地理區域涵蓋範圍
如果是已關閉的解析器，這不會造成問題。
對於開放解析器，伺服器的位置越接近使用者，用戶端經歷的延遲時間就越短。
此外，有足夠的地理涵蓋範圍可間接改善端對端延遲時間，因為名稱伺服器通常會根據 DNS 解析器的位置傳回最佳化結果。
也就是說，如果內容供應器託管了世界各地的鏡像網站，該供應商的名稱伺服器會傳回最靠近 DNS 解析器的 IP 位址。
Google 公用 DNS 託管於全球的資料中心，透過任一傳播轉送功能，將使用者傳送至距離地理位置最近的資料中心。
此外，Google 公用 DNS 支援 EDNS 用戶端子網路 (ECS)，這是解析器的 DNS 通訊協定擴充功能，可將用戶端位置轉送至名稱伺服器，系統可針對實際用戶端 IP 位址 (而非解析器的 IP 位址) 傳回位置機密的回應。詳情請參閱這份常見問題。
Google 公用 DNS 會自動偵測支援 EDNS 用戶端子網路的名稱伺服器。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-07-25 (世界標準時間)。
[null,null,["上次更新時間：2025-07-25 (世界標準時間)。"],[[["\u003cp\u003eDNS lookups significantly impact website loading speed, especially with resource-heavy pages referencing multiple domains.\u003c/p\u003e\n"],["\u003cp\u003eDNS latency stems from network factors between clients and resolvers and between resolvers and other name servers, with cache misses being a primary contributor.\u003c/p\u003e\n"],["\u003cp\u003eCache misses are difficult to avoid due to the Internet's vastness, short DNS record lifespans, and isolated caching systems across servers.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Public DNS employs strategies like global server distribution, load balancing, and security measures to mitigate DNS latency and enhance performance.\u003c/p\u003e\n"]]],["DNS latency, a significant factor in web browsing speed, is primarily caused by client-resolver latency and resolver-name server latency. Cache misses, due to internet growth, low TTL values, and cache isolation, are a dominant factor. Mitigations include adequately provisioning servers to handle traffic, preventing DoS attacks, load-balancing for shared caching, and ensuring global server coverage. Google Public DNS uses techniques such as two-level caching and EDNS client subnet support to minimize lookup times.\n"],null,["# Performance Benefits\n\nIntroduction: causes and mitigations of DNS latency\n---------------------------------------------------\n\nAs web pages become more complex, referencing resources from numerous domains,\nDNS lookups can become a significant bottleneck in the browsing experience.\nWhenever a client needs to query a DNS resolver over the network, the latency\nintroduced can be significant, depending on the proximity and number of\nname servers the resolver has to query (more than 2 is rare, but it can happen).\nAs an example, the following screen shot shows the timings reported by the\n[Page Speed](/speed/pagespeed) web performance measurement tool.\nEach bar represents a resource referenced from the page; the black segments\nindicate DNS lookups.\nIn this page, 13 lookups are made in the first 11 seconds in which the page is\nloaded.\nAlthough several of the lookups are done in parallel, the screen shot shows that\n5 serial lookup times are required, accounting for several seconds of the total\n11 seconds page load time.\n\nThere are two components to DNS latency:\n\n- Latency between the client (user) and DNS resolving server. In most cases this is largely due to the usual round-trip time (RTT) constraints in networked systems: geographical distance between client and server machines; network congestion; packet loss and long retransmit delays (one second on average); overloaded servers, denial-of-service attacks and so on.\n- Latency between resolving servers and other name servers. This source of latency is caused primarily by the following factors:\n - Cache misses. If a response cannot be served from a resolver's cache, but requires recursively querying other name servers, the added network latency is considerable, especially if the authoritative servers are geographically remote.\n - Underprovisioning. If DNS resolvers are overloaded, they must queue DNS resolution requests and responses, and may begin dropping and retransmitting packets.\n - Malicious traffic. Even if a DNS service is overprovisioned, DoS traffic can place undue load on the servers. Similarly, Kaminsky-style attacks can involve flooding resolvers with queries that are guaranteed to bypass the cache and require outgoing requests for resolution.\n\nWe believe that the cache miss factor is the most dominant cause of DNS latency,\nand discuss it further below.\n\n### Cache misses\n\nEven if a resolver has abundant local resources, the fundamental delays\nassociated with talking to remote name servers are hard to avoid.\nIn other words, assuming the resolver is provisioned well enough so that cache\nhits take zero time on the server-side, cache misses remain very expensive in\nterms of latency.\nTo handle a miss, a resolver has to talk to at least one, but often two or more\nexternal name servers.\nOperating the Googlebot web crawler, we have observed an average resolution time\nof 130 ms for name servers that respond.\nHowever, a full 4-6% of requests simply time out, due to UDP packet loss and\nservers being unreachable.\nIf we take into account failures such as packet loss, dead name servers, DNS\nconfiguration errors, etc., the **actual** average end-to-end resolution time is\n300-400 ms.\nHowever, there is high variance and a long tail.\n\nThough the cache miss rate may vary among DNS servers, cache misses are\nfundamentally difficult to avoid, for the following reasons:\n\n- Internet size and growth. Quite simply, as the Internet grows, both through the addition of new users and of new sites, most content is of marginal interest. While a few sites (and consequently DNS names) are very popular, most are of interest to only a few users and are accessed rarely; so the majority of requests result in cache misses.\n- Low time-to-live (TTL) values. The trend towards lower DNS TTL values means that resolutions need more frequent lookups.\n- Cache isolation. DNS servers are typically deployed behind load balancers which assign queries to different machines at random. This results in each individual server maintaining a separate cache rather than being able to reuse cached resolutions from a shared pool.\n\n### Mitigations\n\nIn Google Public DNS, we have implemented several approaches to speeding up DNS\nlookup times.\nSome of these approaches are fairly standard; others are experimental:\n\n- [Provisioning servers adequately](#provision) to handle the load from client traffic, including malicious traffic.\n- Preventing DoS and amplification attacks. Although this is mostly a security issue, and affects closed resolvers less than open ones, preventing DoS attacks also has a benefit for performance by eliminating the extra traffic burden placed on DNS servers. For information on the approaches we are using to minimize the chance of attacks, see the page on [security benefits](/speed/public-dns/docs/security).\n- [Load-balancing for shared caching](#loadbalance), to improve the aggregated cache hit rate across the serving cluster.\n- [Providing global coverage](#geography) for proximity to all users.\n\nProvisioning serving clusters adequately\n----------------------------------------\n\nCaching DNS resolvers have to perform more expensive operations than\nauthoritative name servers, since many responses cannot be served from memory;\ninstead, they require communication with other name servers and thus demand a\nlot of network input/output.\nFurthermore, open resolvers are highly vulnerable to cache poisoning attempts,\nwhich increase the cache miss rate (such attacks specifically send requests for\nbogus names that can't be resolved from cache), and to DoS attacks, which add to\nthe traffic load.\nIf resolvers are not provisioned adequately and cannot keep up with the load,\nthis can have a very negative impact on performance.\nPackets get dropped and need to be retransmitted, name server requests have to\nbe queued, and so on.\nAll of these factors add to delays.\n\nTherefore, it's important for DNS resolvers to be provisioned for high-volume\ninput/output.\nThis includes handling possible DDoS attacks, for which the only effective\nsolution is to over-provision with many machines.\nAt the same time, however, it's important not to reduce the cache hit rate when\nyou add machines; this requires implementing an effective load-balancing policy,\nwhich we discuss below.\n\nLoad-balancing for shared caching\n---------------------------------\n\nScaling resolver infrastructure by adding machines can actually backfire and\n**reduce** the cache hit rate if load balancing is not done properly.\nIn a typical deployment, multiple machines sit behind a load balancer that\nequally distributes traffic to each machine, using a simple algorithm such as\nround robin.\nThe result of this is that each machine maintains its own independent cache,\nso that the cached content is isolated across machines.\nIf each incoming query is distributed to a random machine, depending on the\nnature of the traffic, the effective cache miss rate can be increased\nproportionally.\nFor example, for names with long TTLs that are queried repeatedly, the cache\nmiss rate can be increased by the number of machines in the cluster.\n(For names with very short TTLs, that are queried very infrequently, or that\nresult in uncacheable responses (0 TTL and errors), the cache miss rate is not\nreally affected by adding machines.)\n\nTo boost the hit rate for cacheable names, it's important to load-balance\nservers so that the cache is not fragmented.\nIn Google Public DNS, we have two levels of caching.\nIn one pool of machines, very close to the user, a small per-machine cache\ncontains the most popular names.\nIf a query cannot be satisfied from this cache, it is sent to another pool of\nmachines that partition the cache by names.\nFor this second level cache, all queries for the same name are sent to the same\nmachine, where the name is either cached or it isn't.\n\nDistributing serving clusters for wide geographical coverage\n------------------------------------------------------------\n\nFor closed resolvers, this is not really an issue.\nFor open resolvers, the closer your servers are located to your users,\nthe less latency they will see at the client end.\nIn addition, having sufficient geographical coverage can indirectly improve\nend-to-end latency, as name servers typically return results optimized for the\nDNS resolver's location.\nThat is, if a content provider hosts mirrored sites around the world, that\nprovider's name servers will return the IP address in closest proximity to the\nDNS resolver.\n\nGoogle Public DNS is hosted in data centers worldwide, and uses anycast routing\nto send users to the geographically closest data center.\n\nIn addition, Google Public DNS supports [EDNS client subnet (ECS)](https://tools.ietf.org/html/rfc7871), a DNS\nprotocol extension for resolvers to forward client location to name servers,\nwhich can return location-sensitive responses optimized for the actual client\nIP address, rather than the resolver's IP address.\nPlease read [this FAQ](/speed/public-dns/faq#cdn) for details.\nGoogle Public DNS [automatically detects name servers](//groups.google.com/forum/#!topic/public-dns-announce/67oxFjSLeUM)\nthat support EDNS Client Subnet."]]
