DNS Round-Trip Time (RTT) Nedir ve Nasıl Ölçülür?

DNS sorgusu gönderildiği anda saat başlar. Yanıt geri döndüğünde geçen süre, DNS round-trip time (RTT) olarak adlandırılır ve bir web sayfasının ya da API çağrısının hız deneyimini doğrudan etkiler. Kulağa basit gelen bu ölçüm, aslında birden fazla katmanın sırayla devreye girdiği bir zinciri kapsar.

Pek çok ekip DNS sorunlarını yalnızca "çalışıyor mu, çalışmıyor mu" sorusuna indirger; oysa DNS hizmet verirken de yavaş hizmet verebilir. Milisaniye cinsinden ölçülemeyen bir gecikme, tarayıcıda görünmez bir bekleme süresi olarak birikir; sayfa head'indeki dns-prefetch bu beklemeyi kritik yoldan önceye alır. ve yüksek trafikli uygulamalarda kullanıcı deneyimini sessiz sedasız eritir.

Gecikme tek bir sayı değildir: stub, özyinelemeli çözümleyici ve otorite ayrı milisaniyeler ekler. dig +stats DNS turunu, curl -w ise tarayıcıya kadar uzanan zinciri gösterir.

DNS Çözümleme Zinciri ve Gecikme Noktaları

İstemci ornek.com adresini sorguladığında, yanıt tek adımda gelmez. İşletim sistemi önce yerel önbelleğe bakar; bulunamazsa stub resolver, ayarlı recursive resolver'a sorar. Recursive resolver da yanıtı önbellekte bulamazsa root nameserver'a, oradan TLD (üst düzey alan) sunucusuna, son olarak yetkili (authoritative) nameserver'a ulaşır. Resolver seçimi 1.1.1.1 / 8.8.8.8 bu zincirin ikinci halkasını değiştirir.

Her atlama kendi payını öder. Root sunucuları anycast ile dağıtıldığından ağ mesafesi genellikle düşük kalır; asıl değişkenlik TLD sunucuları ve authoritative nameserver aşamasında görülür, çünkü bu sunucular her sağlayıcıda farklı konumlarda barındırılır ve yük dağılımları çok çeşitlidir.

TTL süresi dolmamış bir kayıt recursive resolver'ın önbelleğinde yaşıyorsa bütün zincir devre dışı kalır ve gecikme birkaç milisaniyeye kadar düşer. Aynı domain için ölçüm yaptığınızda ilk sorgu ile sonraki sorgular arasında büyük fark görebilirsiniz; bu fark bir arıza değil, önbellek mekanizmasının beklenen davranışıdır.

dig +stats ile Resolver Ölçümü

dig, DNS sorgularını komut satırından çalıştırmanın en yaygın yoludur ve +stats bayrağıyla sorgunun tamamlandığı süreyi doğrudan raporlar.

dig ornek.com A +stats

Komut çıktısının sonunda şu satırları görürsünüz:

;; Query time: 42 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jun 13 09:23:00 2026
;; MSG SIZE  rcvd: 55

Query time değeri, sorunun gönderilmesinden yanıtın alınmasına kadar geçen süreyi milisaniye olarak gösterir. Önemli bir ayrıntı: bu ölçüm yalnızca istemci ile recursive resolver arasındaki RTT'yi kapsar. Resolver yanıtı önbellekte tutuyorsa sonuç sıfıra yakın çıkabilir; bu, authoritative nameserver'ın hızlı olduğunu değil, önbelleğin dolu olduğunu söyler.

Önbellek etkisini dışarıda bırakmak için authoritative nameserver'ı doğrudan sorgulamak daha güvenilir bir yöntemdir. Önce nameserver adresini öğrenin:

dig ornek.com NS +short

Ardından dönen nameserver adresine doğrudan sorgu gönderin:

dig @ns1.ornek.com ornek.com A +stats

Bu yöntemle ölçtüğünüz süre, recursive resolver'ın önbelleğinden bağımsız olarak authoritative sunucunun gerçek yanıt süresini yansıtır.

Farklı Resolver'larla Karşılaştırma

İlk sorgu her zaman yavaştır. Önbellek boşken tam zincir devreye girer; bu yüzden tek bir ölçüm yanıltıcı olabilir ve ortam bağımsız bir tablo oluşturmak için farklı resolver'lara aynı sorguyu göndermek gerekir.

for resolver in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo -n "$resolver: "
  dig @$resolver ornek.com A +stats +noall +comments | grep "Query time"
done

Kendi ISP resolver'ınızı da listeye ekleyebilirsiniz:

dig @$(grep nameserver /etc/resolv.conf | head -1 | awk '{print $2}') ornek.com A +stats

Fark belirginse, o resolver sizin konumunuza göre avantajlı ya da dezavantajlı konumda demektir. Türkiye'den yapılan sorgularda yakın anycast noktası olan bir sağlayıcı belirgin fark yaratabilir; ancak hangisinin size daha hızlı yanıt verdiğini ancak ölçüm yaparak görebilirsiniz. Bulut altyapısında zone yönetimini kurarken ya da Microsoft ekosistemi içinde DNS'i yapılandırırken bu karşılaştırma ölçümünü baştan almak, sağlayıcı seçimini somutlaştırır.

curl -w ile Gerçek İstek Zaman Çizelgesi

dig resolver düzeyinde ölçüm yapar. Gerçek bir web isteğinde DNS, TCP el sıkışması, TLS müzakeresi ve içerik transferi art arda işler. curl'ün -w seçeneği bu katmanları ayrı ayrı zamanlayabilir.

curl -o /dev/null -s -w \
  "dns_lookup: %{time_namelookup}s\nconnect: %{time_connect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" \
  https://ornek.com

Tipik bir çıktı şuna benzer:

dns_lookup: 0.032s
connect:    0.087s
ttfb:       0.231s
total:      0.245s

time_namelookup değeri DNS çözümlemesinin tamamlandığı ana kadar geçen süredir. time_connect ile time_namelookup arasındaki fark TCP bağlantı süresini verir; time_starttransfer ile time_connect arasındaki fark ise TLS müzakeresi ve sunucu işlem süresini kapsar. DNS'in toplam istek içindeki payını net görmek için bu üç değeri karşılaştırmak yeterlidir.

Daha okunabilir bir format için değerleri ayrı bir dosyada saklayabilirsiniz. curl-format.txt adlı bir dosya oluşturun:

     namelookup:  %{time_namelookup}
        connect:  %{time_connect}
     appconnect:  %{time_appconnect}
    pretransfer:  %{time_pretransfer}
  starttransfer:  %{time_starttransfer}
          total:  %{time_total}

Ardından çalıştırın:

curl -o /dev/null -s -w @curl-format.txt https://ornek.com

Bu format, özellikle özel domain kurulumunda sorun yaşanan platformlarda DNS katmanının toplam gecikme içindeki payını anlamak için kullanışlıdır; CDN önbelleği bazen TCP ve TLS süresini gizler, ancak DNS çözümleme kısmını etkilemez.

Yüksek RTT Ne Anlama Gelir?

Yüksek DNS RTT her zaman yapılandırma hatasından gelmez; durumu bağlamı belirler ve aynı sayı farklı katmanlarda farklı sorunları işaret edebilir.

Recursive resolver'dan gelen uzun yanıt süresi büyük olasılıkla önbellekte kaydın bulunmadığını, yani tam zincirin yeniden yürüdüğünü gösterir. TTL değeri çok düşükse, 60 saniye veya altındaysa, önbellek hiçbir zaman verimli dolmaz ve her sorgu zinciri baştan çalışır; bu durumda gecikme arttıkça resolver yükü de artar.

Authoritative nameserver'a doğrudan yapılan sorgularda da gecikme yüksekse sunucunun coğrafi konumu ya da o anki yükü etkendir. Tek konumdaki bir authoritative yapısı hem performans hem dayanıklılık açısından zayıf kalır; birden fazla coğrafi bölgede anycast destekli nameserver çalıştırmak yaygın çözümdür. Kendi nameserver'ınızı yönetiyorsanız sunucu tarafındaki nameserver yapılandırması sırasında coğrafi konumu da göz önünde bulundurmak gerekir.

Resolver hızlı yanıt verirken curl çıktısında time_namelookup hâlâ yüksek çıkıyorsa, işletim sistemi veya uygulama önbelleğinin devreye girmediğini düşünebilirsiniz. Node.js veya Python gibi çalışma ortamlarının genellikle yerleşik DNS önbelleği yoktur; her yeni bağlantıda işletim sistemi çözümleyicisi çağrılır ve yüksek eşzamanlılıklı uygulamalarda DNS beklenmedik bir darboğaza dönüşebilir.

Periyodik İzleme ve Örüntü Yakalama

Tek seferlik ölçüm anlık durumu gösterir; eğilimi göstermez. Belirli aralıklarla tekrarlanan sorgular, gün içinde değişen yük ya da coğrafi farklılıkları ortaya koyar. Basit bir döngüyle saatlik log tutabilirsiniz:

while true; do
  ts=$(date +"%Y-%m-%dT%H:%M:%S")
  qt=$(dig @8.8.8.8 ornek.com A +stats +noall +comments | grep "Query time" | awk '{print $4}')
  echo "$ts $qt ms"
  sleep 3600
done >> dns-rtt-log.txt

Saatlik log birkaç günde örüntü verir. İş saatlerinde süre tutarlı kalıyorken gece artıyorsa recursive resolver tarafında gece saatlerinde farklı bir yük dağılımı var olabilir; bu, resolver seçimini yeniden değerlendirme nedenidir. Tersine, gece düşük ve iş saatlerinde yüksek çıkıyorsa kullanıcı trafiğinin önbelleği dolu tuttuğu ama bir noktada kapasiteyi zorladığı görülür.

Birden fazla domain yönetiyorsanız bu tür izlemeyi her domain için ayrı ayrı uygulamak yerine, kritik domain'leri ön plana alıp diğerlerini haftalık toplu kontrolle kapatmak daha sürdürülebilir bir yaklaşımdır.

TTL Değeri RTT'yi Dolaylı Olarak Etkiler

RTT'yi düşürmenin en çok gözden kaçan yolu TTL optimizasyonudur. TTL, recursive resolver'ların bir kaydı önbellekte ne kadar tutacağını belirler; düşük TTL önbellek isabet oranını düşürür ve her sorgu zincirine tam ağırlığını taşıtır. Yüksek TTL ise değişiklik anında propagation süresini uzatır.

Dengeli bir yaklaşım şöyle çalışır: Stabil kayıtlar için - örneğin A kaydı veya MX kaydı - 3600 saniye (bir saat) veya üstü tercih edilebilir. Yakın zamanda değişecek kayıtlar için değişiklikten birkaç gün önce TTL'i 300 saniyeye indirin, değişikliği yapın, propagation tamamlandıktan sonra tekrar yükseltin. Subdomain düzeyinde sık güncelleme yapılan ortamlarda bu pratik, DNS RTT üzerindeki kontrolü anlamlı biçimde artırır.

Çok düşük TTL kullanmanın bir maliyeti vardır: Resolver'lar sizi daha sık sorgular, bu da authoritative nameserver üzerindeki yükü artırır ve yüksek trafikli domainlerde ölçek sorununa yol açabilir. TTL değeri yalnızca esneklik değil, sunucu kaynakları ve ağ yüküyle de dengelenmelidir.

DNS round-trip time, altyapı performansının görünmez kısmında yaşayan ama etkisi birikimli olan bir ölçümdür. dig +stats resolver düzeyini, curl -w ise gerçek bir HTTP isteğindeki DNS payını gösterir; ikisi birlikte kullanıldığında gecikmenin tam olarak nerede oluştuğu netleşir.

Ölçüm yaparken önbellek durumunu aklınızda tutun: İlk sorgu her zaman daha yavaştır ve bu normaldir. Asıl soru, önbellek ısındıktan sonraki sürenin beklentinizi karşılayıp karşılamadığıdır. Authoritative nameserver'a doğrudan sorgu atmak, önbellek gürültüsünü ortadan kaldırır ve sağlayıcıdan gerçekte ne aldığınızı gösterir.

Düzenli ölçüm yapmak, ani bir değişikliği erken fark etmenizi sağlar; bir nameserver geçişi, TTL düşürme ya da sağlayıcı değişikliği sonrasında RTT'deki etkiyi sayıyla görmek hem karar almanızı kolaylaştırır hem de beklenmedik gerilemeler için somut bir referans noktası oluşturur.