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,["最后更新时间 (UTC)：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."]]
