Yavaş bir DNS sorgusu nasıl düzeltilir

Yavaş bir sorgu neyi ölçer

Bir sayfayı yüklemek bir isim sorgusuyla başlar, sonra bir TCP bağlantısı, sonra bir TLS el sıkışması, sonra sunucunun kendi düşünme süresi gelir. Bunlardan yalnızca ilki DNS'tir, ve genellikle siteye hiç dokunmadan iyileştirebileceğiniz tek şeydir.

Burada iki sayı karıştırılır. Önbelleğe alınmış bir sorgu neredeyse hiçbir şeye mal olmaz, çünkü yanıt zaten makinenizde veya bir atlama uzaklıktadır. Soğuk bir sorgu köke bir sorgu, üst düzey alan adına bir başka sorgu, ve alan adının kendi ad sunucularına bir başka sorguyu içerebilir; her biri sizinle o sunucular arasındaki mesafe kadar bir gidiş-dönüş içerir. Sıcakken 20 ms altı ve soğukken 100 ms altı sıradandır. Bir saniyeye yaklaşan herhangi bir şey, atlamalardan birinin uzakta olduğu, aşırı yüklü olduğu, veya zaman aşımına uğrayıp yeniden denendiği anlamına gelir.

Modern sayfalar birçok ana bilgisayar adına sahip olarak bunu kötüleştirir. Yazı tipleri, analitikler, görseller ve ödeme widget'larının her biri kendi sorgusuna ihtiyaç duyar, ve on ana bilgisayar adını her biri 300 ms'de çözen bir tarayıcı, herhangi bir yararlı şeyi işlemeden önce DNS'e üç saniye harcamıştır.

Yavaş olanın DNS olduğunu doğrulayın

Bir şey değiştirmeden önce ölçün. En temiz tek komut, bir isteği aşamalarına ayırır:

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

time_namelookup toplamın küçük bir kesriyse, DNS sorununuz değildir ve bunun yerine sunucu yanıt süresi hakkında okumalısınız. Üçte bir veya daha fazlaysa, devam edin. Yalnızca sorgu için, dig geçen süreyi sizin için yazdırır:

dig example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

Windows'ta PowerShell aynı okumayı verir:

Measure-Command { Resolve-DnsName www.example.com }
Measure-Command { Resolve-DnsName www.example.com -Server 1.1.1.1 }

Varsayılanınızı genel çözümleyicilerle karşılaştırın. Büyük bir fark, düzeltmenin sizin tarafınızda olduğunu söyler. Her yerde benzer süreler, alan adının kendi ad sunucularına işaret eder.

Bir sonuç bu rehberi tamamen dışarıda bırakır. Bir çözümleyici anında NXDOMAIN ile yanıt verirse, isim yayınlanmamıştır ve DNS_PROBE_FINISHED_NXDOMAIN sayfasında açıklanan farklı bir soruna bakıyorsunuzdur.

Neden olur

• Uzak bir çözümleyici. Genel hizmetler anycast çalıştırır, bu yüzden aynı adres yakın bir konumdan yanıt verir. Bir İSS çözümleyicisi veya tek bir ofis sunucusu bunu yapmaz, ve her sorgu tam gidiş-dönüşe mal olur.
• Listedeki ilk sunucu çöktür. İstemci zaman aşımını bekler, sonra ikinciyi sorar. glibc sistemlerinde varsayılan, ilk yeniden denemeden önce 5 saniyedir, ki bu tam olarak insanların "takılıyor, sonra yükleniyor" diye tarif ettiği duraklamadır.
• Çok düşük TTL'ler. 30 veya 60 saniyelik bir TTL, neredeyse her ziyaretçinin taze bir sorgu için ödediği anlamına gelir, çünkü önbelleğe alınmış kopya zaten süresi dolmuştur.
• Uzun CNAME zincirleri. Her bağlantı başka bir sorgudur. CDN'lerin ve pazarlama araçlarının arkasında üç veya dört zincir yaygındır.
• Yavaş yetkili ad sunucuları. Az konumu olan bir DNS sağlayıcısı, dünyanın bazı yerleri için hızlı, geri kalanı için yavaş yanıt verir.
• DNSSEC doğrulaması. Bir zinciri doğrulamak sorgu ekler. Normalde ucuzdur, ama kısmen bozuk bir zincir yavaşlık gibi görünen yeniden denemelere neden olur.
• Arama alan adları. Sonekli yapılandırılmış bir çözümleyici, example.com'dan önce example.com.corp.local dener, önce her sonek için başarısız bir sorguya harcayarak.
• IPv6 olmadan AAAA sorguları. Sistem her iki kayıt türünü de ister ve kullanamayacağı yanıtı bekler.
• Her sorguyu bir tünel üzerinden başka bir kıtadaki bir çözümleyiciye gönderen bir VPN veya filtreleme proxy'si.
• Küçük bir önbelleği ve güçsüz bir CPU'su olan yönlendirici gibi davranan bir yönlendirici.

Nasıl düzeltilir

Cihazınızda

1. Ölçümlerinizin dürüst olması için önbellekleri temizleyin: Windows'ta ipconfig /flushdns, macOS'ta sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, Linux'ta sudo resolvectl flush-caches.
2. Hangi sunucuların hangi sırayla yapılandırıldığına bakın: Get-DnsClientServerAddress, scutil --dns, veya resolvectl status. Artık yanıt vermeyen herhangi bir girdiyi kaldırın, çünkü çöktür bir ilk girdi, her soğuk sorguda size zaman aşımına mal olur.
3. Linux'ta, araştırırken bekleme süresini kısaltmak için /etc/resolv.conf dosyasına options timeout:2 attempts:2 ekleyin, ve kullanılmayan search soneklerini kırpın.
4. VPN'i kesin ve yeniden ölçün. Sayı yarıya inerse, tünel nedendir ve değiştirilmesi gereken onun çözümleyici ayarıdır.

Ağınızda

1. Çözümleyiciyi cihaz cihaz yerine yönlendiricide DHCP üzerinden ayarlayın, böylece her istemci aynı hızlı çifti alır.
2. Yönlendiricinin kendi yönlendiricisine İSS varsayılanı yerine akış yukarı genel bir çözümleyici verin, veya istemcilere genel adresleri doğrudan vererek yönlendiriciyi tamamen atlayın.
3. Kendi DNS sunucusu olan bir iş ağında, tek bir siteden tam özyineleme yapmak yerine yönlendirdiğini, ve önbelleğinin çalışma gününü atlatacak kadar büyük olduğunu kontrol edin.

Kendi alan adınızda

1. Nadiren değişen kayıtlarda TTL'leri yükseltin. Hızlıca taşımanız gerekebilecek bir kayıt için beş dakika makul bir tabandır; kararlı olan her şey için bir saat veya bir gün uygundur.
2. Mümkün olduğunda CNAME zincirlerini düzleştirin. Kaydı bir takma ad zinciri yerine son hedefe işaret ettirin: dig www.example.com CNAME +short sizinkinin ne kadar derine indiğini gösterir.
3. Anycast ad sunucuları olan bir DNS sağlayıcısı kullanın, ve ayrı ağlarda en az iki ad sunucusu tutun.
4. DNSSEC'in doğrulandığını kontrol edin. Normal bir sorguyu doğrulamayı atlayan biriyle karşılaştırın: dig example.com @1.1.1.1 ile dig +cd example.com @1.1.1.1. Büyük bir fark, veya yalnızca ilkinde bir SERVFAIL, zincirin bozuk olduğu anlamına gelir.

Dışarıdan kontrol edin

Kendi zamanlamalarınız bir ağın bir anda ne olduğunu tarif eder, ki bu alabileceğiniz en az yararlı örnektir. Sizden 8 ms uzaklıktaki bir çözümleyici, başka bir bölgedeki bir müşteriden 400 ms uzaklıkta olabilir, ve şikayet eden de o müşteridir.

Sizinle kaynak arasındaki her önbelleği kaldıran yetkili sunucuları doğrudan ölçerek başlayın:

dig NS example.com +short
dig @ns1.example-dns.net example.com | grep "Query time"
dig example.com +trace

+trace çıktısı devri bir seferde bir adım yürür, bu yüzden takılan bir atlama ortalamaya karışmadan görünür olur. Sonra ismi farklı ülkelerdeki kontrol noktalarından çözen ve her birini ayrı ayrı bildiren DNS sorgu kontrolünü çalıştırın. Bu, bir dizüstü bilgisayardan alamayacağınız ölçümdür: ad sunucularınızın her yerde yavaş olup olmadığını gösterir, ki bu sağlayıcıya işaret eder, veya tek bir kıtadan yavaş olup olmadığını, ki bu onların ağ ayak izine işaret eder. Bazı konumlar daha yavaş değil de farklı bir yanıt döndürüyorsa, soru bunun yerine DNS yayılımı nasıl kontrol edilir sayfasında ele alınan yayılımdır.

Bozulmak yerine sürüklenen gecikme

DNS gecikmesi nadiren belirgin bir şekilde bozulur. Sürüklenir; bir ad sunucusu bir konumu kaybeder, bir geçiş sırasında bir TTL düşürülür ve bir daha asla yükseltilmez, ve altı hafta sonra site kimsenin işaret edemediği nedenlerle ağır hissettirir. Tek bir ölçüm bir eğilim gösteremez, bu yüzden sorgu süresini ziyaretçilerinizin bulunduğu bölgelerden bir programa göre kaydetmeye değer. HostTracker, 2004'ten beri web sitelerini izliyor ve şu anda 158 şehirdeki kontrol noktalarından 500.000'den fazla web sitesini izliyor, yavaş bir sürüklenmeyi görünür kılan geçmişi tutuyor. Buradaki diğer rehberler düzeltme kümesindedir, ve hiçbir şeyin hiç geri gelmediği hata durumu DNS server not responding sayfasıdır.