パフォーマンス上のメリット
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
概要: DNS レイテンシの原因と軽減策
ウェブページが複雑になり、多数のドメインからリソースを参照するようになると、DNS ルックアップがブラウジング操作の重大なボトルネックになる可能性があります。クライアントがネットワーク経由で DNS リゾルバにクエリを行う必要がある場合は、リゾルバがクエリする必要があるネームサーバーの数や近接性によっては、レイテンシが大幅に増加する可能性があります（2 台を超えることはまれですが、発生する場合もあります）。たとえば、次のスクリーンショットは、Page Speed ウェブ パフォーマンス測定ツールによって報告された速度を示しています。
各バーは、そのページから参照されるリソースを表しています。黒いセグメントは DNS ルックアップを示しています。このページでは、ページが読み込まれる最初の 11 秒間に 13 回のルックアップが行われています。いくつかのルックアップは並行して実行されていますが、スクリーンショットを見ると、合計 11 秒のページ読み込み時間のうちの数秒を占めている、5 つの連続したルックアップ時間が必要であることがわかります。
DNS レイテンシには次の 2 つの要素があります。
- クライアント（ユーザー）と DNS 解決サーバー間のレイテンシ。ほとんどの場合、これはネットワーク システムにおける通常のラウンドトリップ時間（RTT）の制約（クライアント マシンとサーバー マシン間の地理的距離、ネットワークの輻輳、パケットロスと長い再送信遅延（平均 1 秒）、サーバーの過負荷、サービス拒否攻撃など）に大きく起因します。
- 解決サーバーと他のネームサーバー間のレイテンシ。このレイテンシの原因は、主に次の要因です。
- キャッシュミス。リゾルバのキャッシュからレスポンスを提供できないが、他のネームサーバーに再帰的にクエリする必要がある場合、特に権威サーバーが地理的に離れた場所にいる場合、ネットワーク レイテンシが大幅に増加します。
- アンダープロビジョニング。
DNS リゾルバが過負荷状態になると、DNS 解決のリクエストとレスポンスをキューに入れる必要があり、パケットのドロップと再送信を開始することがあります。
- 悪意のあるトラフィック。
DNS サービスがオーバープロビジョニングされている場合でも、DoS トラフィックによってサーバーに過度の負荷がかかる可能性があります。同様に、Kaminsky スタイルの攻撃では、キャッシュのバイパスが保証され、解決のために送信リクエストが必要になるクエリで、リゾルバのフラッディングが行われる可能性があります。
Google は、キャッシュミスの要因が DNS レイテンシの最も大きな原因であると考えており、これについては後述します。
キャッシュミス
リゾルバに豊富なローカル リソースがある場合でも、リモートのネームサーバーとの通信に関連する基本的な遅延を回避することは困難です。つまり、サーバー側でキャッシュ ヒットがゼロになるようにリゾルバが十分にプロビジョニングされていると仮定した場合、キャッシュミスはレイテンシの点で非常に高コストのままです。ミスを処理するには、リゾルバが少なくとも 1 つ、通常は 2 つ以上の外部ネームサーバーと通信する必要があります。Googlebot ウェブ クローラーを操作したところ、応答したネームサーバーの平均解決時間は 130 ミリ秒でした。ただし、UDP パケットロスとサーバーにアクセスできないため、4 ～ 6% のリクエストは単にタイムアウトします。パケットロス、ネームサーバーの停止、DNS 構成エラーなどの障害を考慮すると、実際のエンドツーエンドの解決時間は 300 ～ 400 ミリ秒です。ただし、ばらつきが大きく、ロングテールもあります。
キャッシュミス率は DNS サーバーによって異なる場合がありますが、次の理由により、キャッシュミスを回避することは根本的に困難です。
- インターネットの規模と拡大。つまり、インターネットが成長し、新規ユーザーの追加と新しいサイトの増加によって、ほとんどのコンテンツが関心の対象にされているのはごく普通のことです。非常に人気のあるサイト（ひいては DNS 名）もいくつかありますが、ほとんどのサイトは限られたユーザーにしか関心がなく、アクセス頻度もめったにないため、リクエストの大半でキャッシュミスが発生します。
- 有効期間（TTL）が低い。DNS TTL 値は減少する傾向にあるため、解決にはより頻繁に検索を行う必要があります。
- キャッシュの分離。通常、DNS サーバーはロードバランサの背後でデプロイされ、異なるマシンにランダムにクエリを割り当てます。その結果、各サーバーが別々のキャッシュを保持するようになり、共有プールからキャッシュに保存されている解像度を再利用できなくなります。
リスクの軽減
Google Public DNS には、DNS ルックアップ時間を高速化するいくつかのアプローチが実装されています。これらのアプローチには、かなり標準的なものもあれば、試験運用版のものもあります。
- 悪意のあるトラフィックなどのクライアント トラフィックからの負荷を処理できるように、サーバーを適切にプロビジョニングする。
- DoS 攻撃と増幅攻撃の防止。これは主にセキュリティ上の問題であり、オープンなリゾルバよりもクローズド リゾルバに影響を及ぼしますが、DoS 攻撃を防ぐことで、DNS サーバーにかかる余分なトラフィックの負担が軽減され、パフォーマンスにもメリットがあります。攻撃の可能性を最小限に抑えるためのアプローチについては、セキュリティ上のメリットのページをご覧ください。
- 共有キャッシュのロード バランシング。サービス クラスタ全体で集計されたキャッシュ ヒット率を改善する。
- あらゆるユーザーと距離をグローバルにカバーする。
サービス クラスタを適切にプロビジョニングする
キャッシュ DNS リゾルバは、メモリからレスポンスを提供できないため、権威ネームサーバーよりも高コストのオペレーションを実行する必要があります。その代わりに、他のネームサーバーとの通信が必要になるため、ネットワークの入出力を大量に要求します。さらに、オープン リゾルバはキャッシュ ポイズニングの試みに対して脆弱で、キャッシュミス率を上昇させます（このような攻撃は、具体的にはキャッシュから解決できない偽名に対するリクエストを送信します）。また、トラフィックの負荷を増加させる DoS 攻撃に対しても脆弱です。リゾルバが適切にプロビジョニングされておらず、負荷に対応できない場合、パフォーマンスに大きな悪影響が生じる可能性があります。パケットがドロップされて再送信が必要な場合、ネームサーバーのリクエストをキューに入れる必要がある場合などです。こうした要因が遅延の原因となります。
したがって、DNS リゾルバを大容量の入出力用にプロビジョニングすることが重要です。これには、可能性のある DDoS 攻撃への対応も含まれます。この場合、唯一の効果的なソリューションは、多くのマシンでオーバープロビジョニングを行うことです。ただし、マシンを追加するときにキャッシュ ヒット率を低下させないことが重要です。そのためには、以下で説明する効果的なロード バランシング ポリシーを実装する必要があります。
共有キャッシュのロード バランシング
マシンを追加してリゾルバ インフラストラクチャをスケーリングすると、ロード バランシングが正しく行われない場合に、実際にはバックファイアが発生し、キャッシュ ヒット率が低下する可能性があります。一般的なデプロイでは、ロードバランサの背後に複数のマシンが配置され、ラウンドロビンなどの単純なアルゴリズムを使用して各マシンにトラフィックを均等に分散します。その結果、各マシンは独自のキャッシュを保持するため、キャッシュに保存されたコンテンツはマシン間で分離されます。受信クエリがランダムなマシンに分散される場合、トラフィックの性質に応じて、実質的なキャッシュミス率が比例して増加する可能性があります。たとえば、TTL が長い名前が繰り返しクエリされる場合、キャッシュミス率がクラスタ内のマシン台数だけ増加することがあります。（TTL が非常に短い名前、クエリの頻度が非常に低い名前、キャッシュできないレスポンス（TTL とエラー）が生じる場合）では、マシンを追加してもキャッシュミス率が実際には影響を受けません。
キャッシュ可能な名前のヒット率を高めるには、キャッシュが断片化されないようにサーバーのロード バランシングを行うことが重要です。Google Public DNS には、2 つのレベルのキャッシュがあります。ユーザーのすぐ近くにある 1 つのマシンプールに、よく使用される名前がマシンごとの小さなキャッシュに格納されています。このキャッシュでクエリを処理できない場合、キャッシュを名前でパーティショニングする別のマシンプールにクエリが送信されます。この 2 番目のレベル キャッシュでは、同じ名前のすべてのクエリが同じマシンに送信されます。名前はキャッシュに保存されるか行われません。
サービング クラスタを広範囲に分散させる
クローズド リゾルバの場合、これは特に問題にはなりません。オープン リゾルバの場合、サーバーとユーザーの距離が近いほど、クライアント側でのレイテンシが短くなります。さらに、ネームサーバーは通常、DNS リゾルバのロケーションに最適化された結果を返すため、十分な地理的範囲を確保することで、エンドツーエンドのレイテンシを間接的に改善できます。つまり、コンテンツ プロバイダがミラーリング対象サイトを世界中でホストしている場合、そのプロバイダのネームサーバーは、DNS リゾルバに最も近い IP アドレスを返します。
Google Public DNS は世界中のデータセンターでホストされており、エニーキャスト ルーティングを使用して、地理的に最も近いデータセンターにユーザーを誘導します。
また、Google Public DNS は EDNS クライアント サブネット（ECS）をサポートしています。これは、リゾルバがクライアントの位置情報をネームサーバーに転送するための DNS プロトコル拡張で、リゾルバの IP アドレスではなく、実際のクライアント IP アドレス向けに最適化された位置情報ベースのレスポンスを返すことができます。詳しくは、こちらのよくある質問をご覧ください。
Google Public DNS は、EDNS クライアント サブネットをサポートするネームサーバーを自動的に検出します。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-07-25 UTC。
[null,null,["最終更新日 2025-07-25 UTC。"],[[["\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."]]
