DNS yayılımı neden bu kadar sürüyor?

"DNS yayılımı" aslında ne demek?

DNS'in kendisi merkezi olmayan bir sistemdir; bir kaydı güncellediğinizde bu bilgi anında "yayılmaz", sadece alan adınızın yetkili ad sunucusunda (authoritative nameserver) güncellenir. Dünyadaki milyonlarca çözücü (resolver) bu yeni cevabı ancak kendisine sorulduğunda öğrenir. Aradaki gecikme, çözücülerin eski cevabı önbelleklerinde tutmaya devam etmesinden kaynaklanır — yani "yayılma" değil, önbelleklerin süresinin dolmasını beklemektir.

Bu ayrım önemlidir çünkü "yayılım" kelimesi bir ilerleme çubuğu çağrıştırır; oysa gerçekte olan şey, her çözücünün kendi TTL saatinin ayrı ayrı işlemesidir. Aynı anda bir kullanıcı yeni IP'yi görürken bir başkası -kullandığı çözücü hâlâ eski kaydı önbellekte tuttuğu için- eski sunucuya bağlanmaya devam edebilir. İkisi de "doğru" çalışıyordur; sadece farklı önbellek yaşındadırlar.

TTL nedir, süreyi nasıl belirler?

TTL (Time To Live), bir DNS kaydına yetkili sunucu tarafından iliştirilen ve saniye cinsinden ifade edilen bir sayaçtır (RFC 1035). Bir çözücü kaydı ilk sorduğunda cevabı TTL süresi boyunca önbelleğe alır ve bu süre boyunca aynı soruyu tekrar yetkili sunucuya sormaz. TTL değeri 3600 olan bir A kaydı, cevabı önbelleğe alan her çözücüde en az bir saat boyunca değişmeden kalır.

Farklı kayıt tipleri farklı TTL taşıyabilir: A/AAAA kayıtları genelde 300-3600 saniye, NS ve SOA kayıtları genelde çok daha uzun (12-48 saat) tutulur çünkü nadiren değişirler. DNS Sorgulama aracıyla bir alan adının tüm kayıtlarını TTL değerleriyle birlikte görebilir, hangi kaydın ne kadar önbellekte kalacağını önceden tahmin edebilirsiniz.

Bir de "negatif önbellekleme" vardır: bir kayıt hiç yoksa (NXDOMAIN) veya sorulan tipte kayıt bulunamıyorsa, çözücüler bu "yok" cevabını da bir süre önbelleğe alır. Bu sürenin uzunluğu RFC 2308'e göre alan adının SOA kaydındaki "minimum" alanından belirlenir; yeni eklediğiniz bir alt alan adı veya kayıt tipi, siz onu oluşturduktan sonra bile bir süre "yok" olarak önbellekte kalabilir, bunun nedeni de aynı mekanizmadır.

• "dig example.com A +noall +answer" komutunun çıktısındaki ikinci sütun TTL'dir (saniye cinsinden).
• TTL 300 ise en kötü ihtimalle 5 dakika içinde, TTL 86400 ise 24 saate kadar eski cevap görülebilir.
• Yetkili sunucudaki TTL değiştiğinde bile, önbellekte duran eski kayıt kendi eski TTL süresiyle bitene kadar önbellekte kalmaya devam eder.

Peki neden bazı yerlerde hâlâ eski cevap geliyor?

Bir değişiklik yaptığınızda güncellenen tek yer yetkili ad sunucunuzdur; oradan itibaren cevap zincirdeki her noktada ayrı ayrı önbelleğe alınır: internet servis sağlayıcınızın çözücüsü, ofis ağınızdaki DNS sunucusu, işletim sisteminin kendi önbelleği, hatta tarayıcının DNS önbelleği. Her biri kaydı farklı anda sorduğu için farklı anda süresi dolar.

Ayrıca bazı genel çözücüler (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) TTL'e tamamen sadık kalırken, bazı ISP çözücüleri yük azaltmak için TTL'i göz ardı edip kaydı daha uzun tutabilir — bu, yayılım süresinin beklenenden uzun sürmesinin en sık nedenlerinden biridir ve sizin kontrolünüzde değildir.

Bir de NS (ad sunucusu) değişimi var: alan adının ad sunucularını değiştirirseniz, üst kayıt (registry, örneğin .com için Verisign) seviyesindeki NS kaydının kendi TTL'i genelde 24-48 saat olduğundan, tam geçiş bu süreyi de kapsayabilir ve iki nameserver setinin bir süre paralel doğru cevap vermesi gerekebilir.

Değişikliği dig/nslookup ile nasıl kontrol edersiniz

En güvenilir yöntem, kaydı doğrudan yetkili ad sunucusuna sormaktır; böylece herhangi bir ara önbelleği devre dışı bırakmış olursunuz. Önce NS kayıtlarını bulun: "dig example.com NS +short". Ardından dönen sunucu adreslerinden birine doğrudan sorun: "dig @ns1.ornekdns.com example.com A +noall +answer". Bu komut size yetkili sunucunun o an verdiği, en güncel cevabı gösterir.

Farklı genel çözücülerde karşılaştırma yapmak isterseniz "dig @1.1.1.1 example.com A", "dig @8.8.8.8 example.com A" ve "dig @9.9.9.9 example.com A" komutlarını art arda çalıştırıp cevapları ve TTL değerlerini karşılaştırabilirsiniz. Windows'ta eşdeğeri "nslookup example.com 1.1.1.1" şeklindedir. Bunu elle dokuz farklı çözücü için tekrarlamak yerine DNS Yayılım Kontrolü aracı, yetkili sunucunuzla birlikte dokuz genel çözücüyü (Cloudflare, Google, Quad9, AdGuard, CleanBrowsing, Yandex, Control D, Level3, UltraDNS) aynı anda sorgulayıp hangisinin güncel, hangisinin hâlâ eski cevabı önbellekte tuttuğunu tek ekranda gösterir.

"dig +trace example.com" komutu ise farklı bir açıdan yardımcı olur: kök sunuculardan başlayarak TLD sunucularına, oradan da alan adının kendi yetkili sunucularına kadar tüm çözümleme zincirini adım adım gösterir. Bu, bir NS değişikliğinden sonra üst kayıt (registry) seviyesinin gerçekten güncellendiğini, yani sorunun sizin ad sunucunuzda değil daha üst bir seviyede olup olmadığını ayırt etmek için kullanışlıdır.

Yayılımı gerçekten hızlandırmanın tek yolu: önceden TTL düşürmek

Bir kaydı değiştirmeden önce TTL'i kısaltırsanız (örneğin 3600'den 300'e), bu düşük TTL'in önbelleğe düşmesi için mevcut TTL kadar (bu örnekte en fazla bir saat) beklemeniz gerekir; ama bu bekleme bittikten sonra asıl değişikliği yaptığınızda, çözücüler artık kaydı sadece 5 dakika önbellekte tutacağından geçiş çok daha hızlı tamamlanır. Değişiklikten sonra TTL'i tekrar normal seviyesine (ör. 3600 veya 86400) yükseltmek performans ve yetkili sunucu yükü açısından mantıklıdır.

TTL'i değişiklik anında düşürmenin bir faydası yoktur — eski kayıt zaten eski TTL süresiyle önbelleklerde durmaya devam eder; TTL güncellemesinin etkili olması için işlemi değişiklikten en az bir TTL süresi önce yapmanız gerekir. Bu yüzden planlı bakımlarda (sunucu taşıma, e-posta sağlayıcısı değişimi gibi) TTL düşürme adımını takvime birkaç gün önceden eklemek iyi bir pratiktir.

Büyük siteler bazen bunun ötesine geçip anycast tabanlı DNS sağlayıcılara veya çok kısa TTL'lerle (60 saniye civarı) çalışan yönetilen DNS hizmetlerine geçer; bu, olağan trafik için gecikmeyi artırmadan acil bir geçişte (örneğin bir saldırı sırasında trafiği başka bir sunucuya yönlendirmek gibi) dakikalar içinde etkili olabilmeyi sağlar. Ancak bu yaklaşımın bedeli, yetkili sunucuya düşen sorgu sayısının önemli ölçüde artmasıdır; çoğu orta ölçekli site için 300-3600 saniyelik bir TTL, planlı düşürme stratejisiyle birlikte yeterlidir.

Sık karıştırılan noktalar

Yayılım süresi hakkında birkaç yaygın yanlış anlama, aşağıdaki maddelere bakarken kafa karışıklığının çoğunu ortadan kaldırır.

• "DNS yayılımı 24-72 saat sürer" genellemesi yanlıştır; süre tamamen o kaydın TTL değerine ve ara çözücülerin davranışına bağlıdır, çoğu zaman TTL kadar sürer.
• Tarayıcınızda hâlâ eski siteyi görmek DNS'ten değil, tarayıcının veya işletim sisteminin kendi DNS önbelleğinden kaynaklanabilir; bunu temizlemek genelde yeterlidir.
• NS (ad sunucusu) değişimi, A kaydı değişiminden daha uzun sürebilir çünkü üst kayıt (registry) seviyesindeki NS TTL'i genelde daha yüksektir ve sizin kontrolünüzde değildir.
• Aynı kaydı farklı cihazlarda farklı görmeniz bir hata değildir; her çözücünün kendi önbellek yaşı farklıdır, hepsi TTL süresi dolduğunda aynı cevaba yakınsar.

Ne zaman gerçekten bir sorun var demektir?

TTL süresinin birkaç katı geçtiği hâlde (örneğin TTL değeri 3600 olan bir kayıt için 6-8 saat sonra) hâlâ eski cevap alınıyorsa, bu artık normal önbellek gecikmesi değil, muhtemelen bir yapılandırma hatasıdır: kayıt yanlış ad sunucusuna eklenmiş olabilir, yanlış bölgede (zone) durabilir ya da yetkili sunuculardan biri güncellenmemiş olabilir. Bazı DNS sağlayıcılarında değişikliği kaydettikten sonra ayrıca "yayınla" (publish) adımını tıklamayı unutmak da aynı belirtiyi verir; kayıt panelde doğru görünse bile hiçbir sunucuya gerçekten yazılmamış olabilir.

Bu durumda önce NS Sorgulama ile alan adının gerçekten hangi ad sunucularını kullandığını doğrulayın, ardından her ad sunucusuna ayrı ayrı sorarak (dig @ns... ile) hepsinin aynı, güncel cevabı verip vermediğine bakın. Sadece bir ad sunucusu eskiyse, o sunucudaki bölge dosyasının senkronize olmadığı anlaşılır.