مزایای عملکرد
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
مقدمه: علل و کاهش تأخیر DNS
با پیچیده تر شدن صفحات وب و ارجاع منابع از دامنه های متعدد، جستجوی DNS می تواند به یک گلوگاه مهم در تجربه مرور تبدیل شود. هر زمان که یک کلاینت نیاز به پرس و جو از یک حل کننده DNS از طریق شبکه داشته باشد، تأخیر معرفی شده می تواند قابل توجه باشد، بسته به مجاورت و تعداد سرورهای نامی که حل کننده باید پرس و جو کند (بیش از 2 نادر است، اما ممکن است رخ دهد). به عنوان مثال، تصویر زیر زمان‌بندی گزارش‌شده توسط ابزار اندازه‌گیری عملکرد وب سرعت صفحه را نشان می‌دهد. هر نوار نشان دهنده منبعی است که از صفحه ارجاع داده شده است. بخش های سیاه نشان دهنده جستجوهای DNS هستند. در این صفحه 13 جستجو در 11 ثانیه اول بارگذاری صفحه انجام می شود. اگرچه چندین جستجو به صورت موازی انجام می شود، عکس صفحه نشان می دهد که 5 زمان جستجوی سریال مورد نیاز است که چند ثانیه از کل زمان بارگذاری صفحه 11 ثانیه را شامل می شود.
تأخیر DNS دو مؤلفه دارد:
- تأخیر بین کلاینت (کاربر) و سرور رفع DNS. در بیشتر موارد این امر عمدتاً به دلیل محدودیت‌های معمول زمان رفت و برگشت (RTT) در سیستم‌های شبکه‌ای است: فاصله جغرافیایی بین ماشین‌های سرویس گیرنده و سرور. تراکم شبکه؛ از دست دادن بسته و تأخیر طولانی ارسال مجدد (به طور متوسط یک ثانیه). سرورهای پربار، حملات انکار سرویس و غیره.
- تأخیر بین سرورهای حل و فصل و سایر سرورهای نام. این منبع تأخیر عمدتاً توسط عوامل زیر ایجاد می شود:
- حافظه پنهان از دست می رود. اگر پاسخی را نتوان از حافظه پنهان یک حل‌کننده ارائه کرد، اما نیاز به جستجوی بازگشتی از سرورهای نام دیگر داشته باشد، تأخیر شبکه اضافه‌شده قابل توجه است، به‌ویژه اگر سرورهای معتبر از نظر جغرافیایی از راه دور باشند.
- تامین کم اگر حل‌کننده‌های DNS بیش از حد بارگذاری شوند، باید درخواست‌ها و پاسخ‌های رزولوشن DNS را در صف قرار دهند و ممکن است بسته‌ها را رها کرده و دوباره ارسال کنند.
- ترافیک مخرب حتی اگر یک سرویس DNS بیش از حد ارائه شود، ترافیک DoS می‌تواند بار غیرمجاز را روی سرورها وارد کند. به طور مشابه، حملات به سبک Kaminsky می‌توانند شامل flooding resolers با کوئری‌هایی باشند که تضمین شده‌اند که حافظه پنهان را دور بزنند و به درخواست‌های خروجی برای حل نیاز دارند.
ما معتقدیم که عامل از دست دادن حافظه پنهان اصلی‌ترین علت تأخیر DNS است و در ادامه بیشتر درباره آن بحث می‌کنیم.
حافظه پنهان از دست می رود
حتی اگر یک حل‌کننده منابع محلی فراوانی داشته باشد، اجتناب از تاخیرهای اساسی مرتبط با مکالمه با سرورهای نام راه دور دشوار است. به عبارت دیگر، با فرض اینکه حل‌کننده به‌اندازه کافی فراهم شده باشد تا زمان بازدید از حافظه پنهان در سمت سرور صفر باشد، از دست دادن حافظه پنهان از نظر تأخیر بسیار گران باقی می‌ماند. برای رسیدگی به خطا، یک حل کننده باید حداقل با یک، اما اغلب دو یا چند سرور نام خارجی صحبت کند. با استفاده از خزنده وب Googlebot، ما میانگین زمان وضوح 130 میلی‌ثانیه را برای سرورهای نامی که پاسخ می‌دهند مشاهده کرده‌ایم. با این حال، 4-6٪ کامل از درخواست ها به دلیل از دست دادن بسته UDP و غیرقابل دسترس بودن سرورها، به سادگی به پایان می رسند. اگر خرابی هایی مانند از دست دادن بسته، سرورهای نام مرده، خطاهای پیکربندی DNS و غیره را در نظر بگیریم، میانگین زمان واقعی تفکیک انتها به انتها 300-400 میلی ثانیه است. با این حال، واریانس بالا و دم بلند وجود دارد.
اگرچه نرخ از دست دادن حافظه پنهان ممکن است در بین سرورهای DNS متفاوت باشد، اما به دلایل زیر جلوگیری از از دست دادن حافظه پنهان اساساً دشوار است:
- اندازه و رشد اینترنت خیلی ساده، با رشد اینترنت، هم از طریق افزودن کاربران جدید و هم از طریق سایت‌های جدید، بیشتر محتواها مورد توجه حاشیه‌ای قرار می‌گیرند. در حالی که تعداد کمی از سایت‌ها (و در نتیجه نام‌های DNS) بسیار محبوب هستند، اکثر آنها فقط برای تعداد کمی از کاربران مورد علاقه هستند و به ندرت به آنها دسترسی پیدا می‌کنند. بنابراین اکثر درخواست ها منجر به از دست رفتن حافظه پنهان می شود.
- مقادیر کم زمان برای زندگی (TTL). گرایش به سمت مقادیر کمتر DNS TTL به این معنی است که رزولوشن ها به جستجوهای مکرر بیشتری نیاز دارند.
- جداسازی کش سرورهای DNS معمولاً در پشت بار متعادل کننده ها مستقر می شوند که پرس و جوها را به صورت تصادفی به ماشین های مختلف اختصاص می دهند. این باعث می‌شود که هر سرور جداگانه به جای اینکه بتواند از وضوح‌های کش شده از یک استخر مشترک استفاده مجدد کند، یک کش جداگانه نگهداری می‌کند.
اقدامات کاهشی
در Google Public DNS، ما چندین رویکرد را برای سرعت بخشیدن به زمان جستجوی DNS پیاده سازی کرده ایم. برخی از این رویکردها نسبتاً استاندارد هستند. دیگران تجربی هستند:
- تهیه سرورها به اندازه کافی برای مدیریت بار ناشی از ترافیک مشتری، از جمله ترافیک مخرب.
- جلوگیری از حملات DoS و تقویت اگرچه این عمدتاً یک مسئله امنیتی است و بر حل‌کننده‌های بسته کمتر از موارد باز تأثیر می‌گذارد، اما جلوگیری از حملات DoS با حذف بار ترافیک اضافی روی سرورهای DNS برای عملکرد مفید است. برای کسب اطلاعات در مورد رویکردهایی که برای به حداقل رساندن احتمال حملات استفاده می کنیم، به صفحه مزایای امنیتی مراجعه کنید.
- تعادل بار برای حافظه پنهان مشترک ، برای بهبود نرخ ضربه حافظه پنهان انبوه در سراسر خوشه خدمات.
- ارائه پوشش جهانی برای نزدیکی به همه کاربران.
تهیه خوشه های خدماتی به اندازه کافی
حل‌کننده‌های DNS ذخیره‌سازی باید عملیات گران‌تری نسبت به سرورهای نام معتبر انجام دهند، زیرا بسیاری از پاسخ‌ها را نمی‌توان از حافظه ارائه کرد. در عوض، آنها نیاز به ارتباط با سایر سرورهای نام دارند و بنابراین ورودی/خروجی شبکه زیادی را می طلبند. علاوه بر این، حل‌کننده‌های باز در برابر تلاش‌های مسموم کردن حافظه پنهان بسیار آسیب‌پذیر هستند، که نرخ از دست دادن حافظه پنهان را افزایش می‌دهد (چنین حملاتی به طور خاص درخواست‌هایی را برای نام‌های جعلی ارسال می‌کنند که نمی‌توانند از حافظه پنهان حل شوند) و حملات DoS، که به بار ترافیک می‌افزایند. اگر حل کننده ها به اندازه کافی تهیه نشده باشند و نتوانند با بار همراه باشند، این می تواند تأثیر بسیار منفی بر عملکرد داشته باشد. بسته ها حذف می شوند و نیاز به ارسال مجدد دارند، درخواست های سرور نام باید در صف قرار گیرند و غیره. همه این عوامل به تاخیر می افزایند.
بنابراین، برای حل‌کننده‌های DNS مهم است که برای ورودی/خروجی با حجم بالا تدارک دیده شوند. این شامل مدیریت حملات احتمالی DDoS می‌شود که تنها راه‌حل مؤثر برای آن، تأمین بیش از حد بسیاری از ماشین‌ها است. با این حال، در عین حال، مهم است که هنگام اضافه کردن ماشین‌ها، نرخ ضربه حافظه پنهان را کاهش ندهید. این امر مستلزم اجرای یک سیاست موازنه بار موثر است که در زیر به آن می پردازیم.
تعادل بار برای ذخیره مشترک
اگر متعادل‌سازی بار به‌درستی انجام نشود، زیرساخت‌های حل‌کننده مقیاس‌پذیری با افزودن ماشین‌ها می‌تواند نتیجه معکوس داشته باشد و نرخ ضربه حافظه پنهان را کاهش دهد . در یک استقرار معمولی، چندین ماشین در پشت یک متعادل کننده بار قرار می گیرند که با استفاده از یک الگوریتم ساده مانند دور روبین، ترافیک را به طور مساوی بین هر ماشین توزیع می کند. نتیجه این است که هر ماشین حافظه پنهان مستقل خود را حفظ می کند، به طوری که محتوای کش شده در بین ماشین ها ایزوله می شود. اگر هر درخواست ورودی به یک ماشین تصادفی توزیع شود، بسته به ماهیت ترافیک، نرخ موثر از دست رفتن حافظه پنهان را می توان به نسبت افزایش داد. به عنوان مثال، برای نام‌هایی با TTL طولانی که به طور مکرر مورد پرسش قرار می‌گیرند، نرخ از دست دادن حافظه پنهان را می‌توان با تعداد ماشین‌های موجود در خوشه افزایش داد. (برای نام‌هایی با TTL بسیار کوتاه، که به ندرت مورد پرسش قرار می‌گیرند، یا منجر به پاسخ‌های غیرقابل ذخیره‌سازی می‌شوند (0 TTL و خطا)، نرخ از دست دادن حافظه پنهان واقعاً با افزودن ماشین‌ها تحت تأثیر قرار نمی‌گیرد.)
برای افزایش نرخ ضربه برای نام‌های کش، مهم است که سرورها را با تعادل بارگذاری کنید تا کش تکه تکه نشود. در Google Public DNS، ما دو سطح کش داریم. در یک مجموعه از ماشین‌ها، بسیار نزدیک به کاربر، یک کش کوچک برای هر ماشین حاوی محبوب‌ترین نام‌ها است. اگر یک پرس و جو از این کش برآورده نشود، به مجموعه دیگری از ماشین ها ارسال می شود که کش را بر اساس نام ها تقسیم می کنند. برای این حافظه نهان سطح دوم، همه پرس و جوهای مربوط به یک نام به یک دستگاه ارسال می شوند، جایی که نام یا در حافظه پنهان است یا نه.
توزیع خوشه های خدمت برای پوشش جغرافیایی گسترده
برای حل‌کننده‌های بسته، این واقعاً مشکلی نیست. برای حل‌کننده‌های باز، هرچه سرورهای شما به کاربران شما نزدیک‌تر باشد، تأخیر کمتری را در انتهای کلاینت مشاهده خواهند کرد. علاوه بر این، داشتن پوشش جغرافیایی کافی می تواند به طور غیرمستقیم تأخیر پایان به انتها را بهبود بخشد، زیرا سرورهای نام معمولاً نتایج بهینه شده برای مکان حل کننده DNS را برمی گردانند. یعنی اگر یک ارائه‌دهنده محتوا میزبان سایت‌های آینه‌ای در سراسر جهان باشد، سرورهای نام آن ارائه‌دهنده آدرس IP را در نزدیکترین فاصله به حل‌کننده DNS برمی‌گرداند.
Google Public DNS در مراکز داده در سراسر جهان میزبانی می شود و از مسیریابی anycast برای ارسال کاربران به نزدیکترین مرکز داده از لحاظ جغرافیایی استفاده می کند.
علاوه بر این، Google Public DNS از زیرشبکه مشتری EDNS (ECS) پشتیبانی می‌کند، یک پسوند پروتکل DNS برای حل‌کننده‌ها برای ارسال مکان کلاینت به سرورهای نام، که می‌تواند پاسخ‌های حساس به مکان را بهینه‌سازی شده برای آدرس IP مشتری واقعی، به جای آدرس IP حل‌کننده، بازگرداند. لطفاً این سؤالات متداول را برای جزئیات بخوانید. Google Public DNS به طور خودکار سرورهای نامی را شناسایی می کند که از زیرشبکه مشتری EDNS پشتیبانی می کنند.
جز در مواردی که غیر از این ذکر شده باشد،محتوای این صفحه تحت مجوز Creative Commons Attribution 4.0 License است. نمونه کدها نیز دارای مجوز Apache 2.0 License است. برای اطلاع از جزئیات، به خطمشیهای سایت Google Developers مراجعه کنید. جاوا علامت تجاری ثبتشده Oracle و/یا شرکتهای وابسته به آن است.
تاریخ آخرین بهروزرسانی 2025-07-24 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-24 بهوقت ساعت هماهنگ جهانی."],[[["\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."]]
