Performansın Avantajları
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Giriş: DNS gecikmesinin nedenleri ve çözümleri
Web sayfaları daha karmaşık hale geldikçe ve çok sayıda alandan gelen kaynaklara referans verilebilir. Bu nedenle, DNS aramaları göz atma deneyiminde önemli bir dar boğaz haline gelebilir.
Bir istemcinin ağ üzerinden bir DNS çözümleyiciyi sorgulaması gerektiğinde, ortaya çıkan gecikme, çözümleyicinin sorgulaması gereken ad sunucularının yakınlığına ve sayısına bağlı olarak önemli olabilir (2'den fazla sunucu bulunur ancak nadiren de olsa bazen yaşanabilir).
Örnek olarak, aşağıdaki ekran görüntüsünde Page Speed web performansı ölçüm aracı tarafından bildirilen zamanlamalar gösterilmektedir.
Her çubuk, sayfadan referans verilen bir kaynağı temsil eder; siyah segmentler, DNS aramalarını gösterir.
Bu sayfada, sayfanın yüklendiği ilk 11 saniyede 13 arama yapılır.
Aramalardan birkaçı paralel olarak yapılsa da ekran görüntüsünde, toplam 11 saniyelik sayfa yükleme süresinin birkaç saniyesine karşılık gelen 5 seri arama süresinin gerekli olduğu görülüyor.
DNS gecikmesinin iki bileşeni vardır:
- İstemci (kullanıcı) ve DNS çözümleme sunucusu arasındaki gecikme.
Çoğu durumda bu, ağa bağlı sistemlerdeki olağan gidiş dönüş süresi (RTT) kısıtlamalarından kaynaklanır: istemci ile sunucu makineleri arasındaki coğrafi mesafe; ağ tıkanıklığı, paket kaybı ve uzun aktarım gecikmeleri (ortalama bir saniye); aşırı yüklenen sunucular, hizmet reddi saldırıları vb.
- Sunucular ile diğer alan adı sunucuları arasındaki gecikme.
Bu gecikmenin nedeni esas olarak aşağıdaki faktörlerdir:
- Önbellekte yok.
Bir yanıt çözümleyicinin önbelleğinden sunulamasa da diğer ad sunucularının tekrar tekrar sorgulanmasını gerektiriyorsa eklenen ağ gecikmesi, özellikle yetkili sunucular coğrafi olarak uzaktan olduğunda önemli ölçüde olur.
- Temel hazırlık yapılıyor.
DNS çözümleyicileri aşırı yüklüyse DNS çözümleme isteklerini ve yanıtlarını sıraya eklemeleri gerekir. Ayrıca bu çözümleyiciler, paketleri bırakıp iletmeye başlayabilir.
- Kötü amaçlı trafik.
Bir DNS hizmeti gereğinden fazla temel hazırlığı yapılmış olsa bile, DoS trafiği sunuculara gereğinden fazla yük bindirebilir.
Benzer şekilde, Kaminsky tarzı saldırılar, önbelleği atlaması garanti edilen ve çözüm için giden istekler gerektiren sorgulara sahip su baskını çözümleyicileri içerebilir.
Önbellek kaçırma faktörünün, DNS gecikmesinin en yaygın nedeni olduğuna inanıyoruz. Bu konuyu aşağıda daha ayrıntılı olarak ele alıyoruz.
Önbellekte yok
Çözümleyicinin bol miktarda yerel kaynağı olsa bile uzak alan adı sunucularıyla konuşmayla ilgili temel gecikmelerden kaçınmak zordur.
Diğer bir deyişle, çözümleyicinin, önbellek isabetlerinin sunucu tarafında sıfır zaman alması için yeterince iyi bir şekilde sağlandığı varsayıldığında, önbellekte kayıplar gecikme açısından çok pahalı olmaya devam eder.
Bir çözümleyicinin eksikleri halletmek için en az bir, ancak genellikle iki veya daha fazla harici alan adı sunucusuyla konuşması gerekir.
Googlebot web tarayıcısını kullanırken, yanıt veren alan adı sunucuları için ortalama 130 ms çözüm süresinin uzandığını gözlemledik.
Ancak UDP paket kaybı ve sunuculara erişilememesi nedeniyle isteklerin %4 ila %6'sı zaman aşımına uğrar.
Paket kaybı, ölü alan adı sunucuları, DNS yapılandırma hataları gibi hataları hesaba kattığımızda, gerçek ortalama uçtan uca çözüm süresi 300-400 ms'dir. Bununla birlikte, büyük farklar ve uzun bir kuyruk vardır.
Önbellek kaçırma oranı DNS sunucuları arasında farklılık gösterse de önbellekte kaybolma durumlarından kaçınmak temel olarak aşağıdaki nedenlerle zordur:
- İnternetin boyutu ve büyümesi.
Basitçe ifade etmek gerekirse, hem yeni kullanıcıların eklenmesi hem de yeni sitelerin eklenmesiyle İnternet büyüdükçe içeriğin büyük bir kısmı ilgi görüyor.
Birkaç site (ve dolayısıyla DNS adları) çok popüler olsa da çoğu site yalnızca birkaç kullanıcının ilgisini çeker ve nadiren erişilir. Bu nedenle isteklerin çoğu önbellekte eksikliklere yol açar.
- Düşük geçerlilik süresi (TTL) değerleri.
Daha düşük DNS TTL değerlerine doğru eğilim, çözümlerin daha sık arama yapılması gerektiği anlamına gelir.
- Önbellek izolasyonu.
DNS sunucuları genellikle sorguları farklı makinelere rastgele atayan yük dengeleyicilerin arkasına dağıtılır.
Bu, paylaşılan bir havuzdaki önbelleğe alınmış çözümleri yeniden kullanmak yerine her bir sunucunun ayrı bir önbellek tutmasıyla sonuçlanır.
Çözümler
Google Açık DNS'te, DNS arama sürelerini kısaltmak için çeşitli yaklaşımlar uyguladık.
Bu yaklaşımlardan bazıları oldukça standarttır, bazıları ise deneyseldir:
Sunum kümelerinin temel hazırlığını uygun şekilde yapma
DNS çözümleyicilerinin önbelleğe alma, yetkili alan adı sunucularından daha pahalı işlemler gerçekleştirmesi gerekir. Bunun nedeni, birçok yanıtın bellekten sunulamamasıdır. Bunun yerine, diğer alan adı sunucularıyla iletişim kurulmasını ve dolayısıyla çok sayıda ağ girişi/çıkışı gerektirir.
Ayrıca açık çözümleyiciler, önbellek zehirlenmesi girişimlerine karşı son derece savunmasızdır. Bu durum önbellekleri kaçırma oranını (bu tür saldırılar özellikle önbellekten çözülemeyen sahte adlar için istekler gönderir) ve trafik yüküne katkıda bulunan DoS saldırılarına karşı savunmasızdır.
Çözümleyiciler yeterli şekilde sağlanmazsa ve yüke yetişemezlerse bu durum performans üzerinde çok olumsuz bir etkiye neden olabilir.
Paketler bırakılır ve bu paketlerin yeniden iletilmesi, alan adı sunucusu isteklerinin sıraya alınması vb. gerekir.
Tüm bu faktörler gecikmelere neden olur.
Bu nedenle, DNS çözümleyicilerin yüksek hacimli giriş/çıkış için temel hazırlığının yapılması önemlidir.
Bu, olası DDoS saldırılarının ele alınmasını da içerir. Bu saldırılar için etkili tek çözüm, çok sayıda makineye gereğinden fazla temel hazırlık yapmaktır.
Bununla birlikte, makine eklerken önbellek isabet oranını azaltmamanız önemlidir. Bunun için aşağıda ele aldığımız etkili yük dengeleme politikasının uygulanması gerekir.
Paylaşılan önbelleğe alma için yük dengeleme
Makine ekleyerek çözümleyici altyapısını ölçeklendirmek, yük dengeleme düzgün yapılmazsa geri tepebilir ve önbellek isabet hızını düşürebilir.
Tipik bir dağıtımda birden fazla makine, çevrimsel sıralı gibi basit bir algoritma kullanarak trafiği her makineye eşit şekilde dağıtan bir yük dengeleyicinin arkasında bulunur.
Bunun sonucunda her makine, kendine ait bağımsız bir önbellek bulundurur ve böylece önbelleğe alınan içerik makineler arasında izole edilir.
Gelen her sorgu rastgele bir makineye dağıtılırsa trafiğin yapısına bağlı olarak etkin önbellek kaçırma oranı orantılı olarak artırılabilir.
Örneğin, tekrar tekrar sorgulanan uzun TTL'leri olan adlar için önbellek eksiklik oranı, kümedeki makine sayısı ile artırılabilir.
(TTL'leri çok kısa olan, çok nadir sorgulanan veya önbelleğe alınamayan yanıtlarla (0 TTL ve hata) sonuçlanan adlar için önbellek kaçırma oranı, makine eklenmesinden gerçekten etkilenmez.)
Önbelleğe alınabilir adların isabet oranını artırmak amacıyla, önbelleğin parçalara ayrılmayacak şekilde yük dengelemesi sunucularının kullanılması önemlidir.
Google Açık DNS'te, iki önbelleğe alma düzeyimiz vardır.
Kullanıcıya çok yakın bir makine havuzunda, makine başına küçük bir önbellek en popüler adları içerir.
Bu önbellekten yanıtlanamayan bir sorgu, önbelleği adlara göre bölümleyen başka bir makine havuzuna gönderilir.
Bu ikinci düzey önbellek için aynı ada sahip tüm sorgular aynı makineye gönderilir. Burada ad önbelleğe alınır veya taşınmaz.
Geniş coğrafi kapsam için sunum kümelerini dağıtma
Çözümü kapalı olan kişiler için bu gerçekten bir sorun değildir.
Açık çözümleyiciler için sunucularınız kullanıcılarınıza ne kadar yakın olursa istemci tarafında o kadar az gecikme görürler.
Ayrıca, alan adı sunucuları genellikle DNS çözümleyicisinin konumu için optimize edilmiş sonuçlar döndürdüğünden, yeterli coğrafi kapsama sahip olmak uçtan uca gecikmeyi dolaylı olarak iyileştirebilir.
Yani bir içerik sağlayıcı, dünyanın her yerinde yansıtılmış siteler barındırıyorsa bu sağlayıcının ad sunucuları, IP adresini DNS çözümleyiciye en yakın mesafede döndürür.
Google Açık DNS, dünya genelindeki veri merkezlerinde barındırılır ve kullanıcıları coğrafi olarak en yakın veri merkezine göndermek için her noktaya yayın yönlendirmesini kullanır.
Ayrıca Google Açık DNS, EDNS istemci alt ağını (ECS) destekler. Bu, çözümleyicilerin istemci konumunu ad sunucularına yönlendirmesini sağlayan bir DNS protokolü uzantısıdır. Bu sayede, çözümleyicinin IP adresi yerine gerçek istemci IP adresi için optimize edilmiş konuma duyarlı yanıtlar döndürebilir.
Ayrıntılar için lütfen bu SSS sayfasını okuyun.
Google Açık DNS, EDNS İstemci Alt Ağını destekleyen alan adı sunucularını otomatik olarak algılar.
Aksi belirtilmediği sürece bu sayfanın içeriği Creative Commons Atıf 4.0 Lisansı altında ve kod örnekleri Apache 2.0 Lisansı altında lisanslanmıştır. Ayrıntılı bilgi için Google Developers Site Politikaları'na göz atın. Java, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-25 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
