ISP 可以進行 DHCP 等網路設定基礎架構，以傳回 Google 公用 DNS 位址 (8.8.8.8、8.8.4.4 和 IPv6)，讓網路上的用戶端直接使用 Google 公用 DNS。這是最簡單可靠的方法。藉由讓網路用戶端直接將 DNS 查詢傳送至 Google 公用 DNS，每個用戶端都會受到個別用戶端的頻率限制，非濫用用戶端不太可能受到節流影響。
透過本機解析器使用 Google 公用 DNS
ISP 也可能使用本機解析器進行用戶端查詢，並要求本機解析器將查詢轉送至 Google 公用 DNS。這可能是出於法規原因或營運的 ISP 的要求。
家用路由器或其他網路裝置
大部分的本機解析器都是在由 ISP 管理的路由器、防火牆或 DSL/有線數據機上執行。
其中，單一客戶具備專屬的 IP 位址，其運作方式就像直接使用 Google 公用 DNS 的用戶端。
共用快取解析器
如要減少 DNS 查詢的延遲時間，尤其是距離 Google 解析器位置較遠的 ISP，網際網路服務供應商 (ISP) 可以使用為許多用戶端提供服務的快取 DNS 解析器。
這可減少傳送至 Google 公用 DNS 的 DNS 查詢量，但專注於幾個 IP 位址，就更有可能進行節流作業。具備共用解析器將查詢轉送至 Google 公用 DNS 的 ISP 應監控 DNS 查詢率，並在比率超出限制時，要求提高頻率限制，或是超過 1% 的查詢未獲得回應。
[null,null,["上次更新時間：2025-07-25 (世界標準時間)。"],[[["\u003cp\u003eGoogle Public DNS is a free service offered to everyone but utilizes rate limits to maintain service quality, which may result in throttling for high query volumes from a single IP address.\u003c/p\u003e\n"],["\u003cp\u003eBefore utilizing Google Public DNS, it is advised to determine your peak DNS queries per second and the number of routable IP addresses to ensure compliance with the default rate limits or to request a rate limit increase if needed.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Public DNS can be implemented directly by configuring clients to use it or via local resolvers, with direct use offering individual rate limiting and greater resilience to throttling.\u003c/p\u003e\n"],["\u003cp\u003eISPs using shared resolvers or CG-NAT may require rate limit increases and should monitor their query rates, potentially requesting an increase if they exceed the limit or encounter significant unresponsive queries.\u003c/p\u003e\n"],["\u003cp\u003eFor enhanced reliability and to mitigate against single points of failure, Google Public DNS can be used in conjunction with other resolvers, or as an emergency fallback, although the latter requires careful configuration to avoid throttling during surges.\u003c/p\u003e\n"]]],["Google Public DNS, a free service with rate limits, may throttle high query volumes from single IPs (or IPv6 /64). Users should measure their peak DNS query rate and compare it to the 1500 QPS default limit. If exceeding, they can use direct queries or request a limit increase. ISPs can configure direct DNS queries or use local/shared resolvers. For increased reliability, they should use alternative resolvers, configure Google Public DNS as a fallback, and establish network peering with Google.\n"],null,["# Google Public DNS for ISPs\n\nAnyone, including Internet Service Providers (ISPs) and large organizations,\nis free to use Google Public DNS, but we apply rate limits to each client\nto protect our service.\nHigh query volumes from a single IPv4 address (or IPv6 /64 network prefix)\nmay be throttled if they exceed these limits.\n| **Important:** Google Public DNS is a free service with no SLA. If you are using Google Public DNS for critical services or functionality, you should configure alternative DNS resolvers and be prepared to switch automatically or with fast manual reconfiguration when your monitoring detects any reachability or resolution issues with Google Public DNS.\n\nBefore you start using Google Public DNS\n----------------------------------------\n\nIf you plan for clients to send queries to Google Public directly,\nand are not using carrier-grade NAT (CG-NAT) to map clients to IPv4 addresses,\nyou can skip these steps and follow instructions in the\n[\"Using Google Public DNS directly\"](#direct) section.\n\n1. Find your peak DNS queries per second (QPS) rate.\n\n You can measure this with NetFlow or sFlow data from your network devices,\n or with the statistics or query logs of your resolvers.\n If you cannot do any of these, just estimate the DNS query rate.\n\n The peak rates should not count instantaneous bursts,\n but average traffic over one or two seconds at the busiest time of day.\n Google Public DNS allows short traffic bursts that briefly exceed the limit.\n2. Find the number of routable IP addresses that send DNS queries.\n\n If you use shared resolvers to aggregate (and perhaps cache) DNS queries,\n just count how many external IP addresses the resolvers use.\n\n If devices will send DNS queries directly to Google Public DNS,\n count the number of external IP addresses the devices would use,\n accounting for any NAT or carrier-grade NAT address mapping.\n3. Compare your per-IP address rate(s) to the default rate limits.\n\n Ideally you should have specific rates for each IP address, but it is okay\n to simply divide the overall QPS rate by the number of IP addresses.\n - Your per-IP address QPS rate is less than 1500 QPS\n\n You can configure Google Public DNS however you like;\n you do not need to request a rate limit increase.\n - Your per-IP address QPS rate exceeds 1500 QPS\n\n If devices on your networks can query Google Public DNS directly,\n and doing so reduces the per-IP address QPS rate below the limit,\n you can choose to use that approach without a rate limit increase.\n\n Otherwise, you need to [request a rate limit increase](#ratelimit).\n4. Configure use of Google Public DNS\n\n Use one of the methods in the following section.\n\nConfigure Google Public DNS\n---------------------------\n\n### Using Google Public DNS directly\n\nISPs can configure network configuration infrastructure such as DHCP\nto return Google Public DNS addresses (8.8.8.8, 8.8.4.4, and IPv6)\nso that clients on their networks will use Google Public DNS directly.\nThis is the simplest and most reliable approach.\nBy having network clients send DNS queries directly to Google Public DNS\neach client is rate limited individually and non-abusive clients are very\nunlikely to be affected by throttling.\n| **Caution:** ISPs using CG-NAT are more likely to be throttled in this case, and should monitor DNS query rates and [request a rate limit increase](#ratelimit) if rates exceed their limit, or more than 1% of queries do not get a response.\n\n### Using Google Public DNS from local resolvers\n\nIt is also possible for ISPs to use local resolvers for client queries,\nand to have the local resolvers forward the queries to Google Public DNS.\nThis may be necessary for regulatory reasons or operational ISP requirements.\n\n#### Home routers or other network devices\n\nMost local resolvers run on ISP-managed routers, firewalls, or DSL/cable modems.\nWhere these are for a single customer and have their own IP address\nthey work just like clients using Google Public DNS directly.\n\n#### Shared caching resolvers\n\nTo reduce latency for DNS queries, especially for ISPs located far from\n[Google resolver locations](/speed/public-dns/faq#locations),\nISPs can use caching DNS resolvers that serve many clients.\nThis can reduce the volume of DNS queries sent to Google Public DNS,\nbut concentrating it to a few IP addresses makes it more likely to be throttled.\nISPs with shared resolvers forwarding queries to Google Public DNS should\nmonitor DNS query rates and [request a rate limit increase](#ratelimit)\nif rates exceed their limit, or more than 1% of queries do not get a response.\n\nOther actions ISPs can take\n---------------------------\n\n### Request a rate limit increase\n\nISPs using shared caching resolvers or IPv4 addresses with CG-NAT may need\nhigher rate limits to ensure consistent service. Before requesting an increase,\nISPs with caching resolvers should check their query logs and\nthose using CG-NAT should check their network traffic logs to confirm\nmore than 1500 QPS sustained for IP addresses in the request.\n\nYou can file a rate limit increase [request](//issuetracker.google.com/issues/new?component=191885&template=1024641) through the Google Public DNS\n[Issue Tracker](//issuetracker.google.com/bookmark-groups/77752).\n\nGoogle Public DNS can be configured to respond with REFUSED errors when clients\nwith increased rate limits are throttled.\nIf you need this signal, mention it in your rate limit increase request.\n\n### Use alternative resolvers together with Google Public DNS\n\nISPs can also configure Google Public DNS as one of several resolver services\nfor their clients or shared caching resolvers.\nThis can increase DNS reliability and eliminate single points of failure.\nThe [FAQ](/speed/public-dns/faq#services) highlights issues to consider when\nconfiguring multiple DNS resolvers.\n| **Note:** For DNSSEC protection to be effective, **all** configured resolvers must validate DNSSEC.\n\n### Use Google Public DNS as an emergency fallback\n\nISPs can configure Google Public DNS as an emergency fallback,\nbut if the DNS query volume is high, queries are likely to be throttled\nwhen switching over to Google Public DNS if the sustained query volume per\nclient IP exceeds the default rate limits (1500 QPS).\n\nTo properly provision the Google Public DNS service to handle surges in demand,\nwe rely on accurate baseline traffic levels.\nWe cannot provide rate limit increases for clients that are not sending\ntraffic volume that does not even approach the default rate limits.\n\nA better approach for ISPs with high query volume, that want to use Google\nPublic DNS as an emergency fallback only, is to configure Google Public DNS\nresolvers together with several [alternative resolver addresses](#alternative)\nas fallbacks. If the fallbacks are activated, this would spread your DNS\ntraffic across multiple providers, reducing the risk of hitting rate limits.\n\n### Peer with Google\n\nMedium to large ISPs using Google Public DNS for their DNS resolution should set\nup [network peering with Google](https://peering.google.com/#/options/peering).\nDoing this establishes a relationship with the Google NOC that can be used for\nescalation if there are connectivity or reachability issues from the ISP network\nto Google's networks, including the Google Public DNS IP addresses."]]
