Alan adınızın nameserver'ını değiştirdiğinizde ya da A kaydını yeni bir IP'ye taşıdığınızda, değişikliğin dünyanın her köşesinde aynı anda görünmediğini fark edersiniz. Bir bilgisayardan site yeni sunucuya düşmüştür, yan masadaki cihazda hâlâ eski içerik gelir. İşte bu gecikme penceresine DNS propagasyonu deniyor ve aslında bir hata değil, sistemin tasarım gereği çalışma biçimidir.

DNS Kayıtları Nasıl Yayılır?

İnternette DNS, tek bir merkezde tutulan dev bir tablo değildir. Yetkili (authoritative) nameserver'larınızdan başlayıp, kullanıcının bağlandığı internet servis sağlayıcısının resolver'ına kadar uzanan dağıtık bir ön bellek zinciridir. Bir değişiklik yaptığınızda kaynak anında güncellenir, ama o güncellemenin zincirin her halkasına ulaşması için aradaki ön belleklerin süresinin dolmasını beklemek gerekir.

Bu yüzden "propagasyon" kelimesi biraz yanıltıcıdır. Aslında kayıt aktif olarak bir yere itilmez; eski kopyalar zaman aşımına uğradıkça yenisi çekilir. Yani sabırla beklenen şey, yayılma değil, eski verinin geçerlilik süresinin tükenmesidir.

Zincirin işleyişini kabaca şöyle düşünebilirsiniz: kullanıcının cihazı önce işletim sistemindeki yerel önbelleğe bakar, sonra ISS'nin recursive resolver'ına sorar, o da cevabı bilmiyorsa kök sunuculardan başlayıp TLD ve sizin yetkili sunucularınıza kadar iner. Bu yolculuğun her durağında bir önbellek bulunur ve her biri kendi TTL'i dolana dek eski cevabı saklamaya devam eder. Tek bir resolver bile geç güncellenirse, ona bağlı binlerce kullanıcı için site hâlâ eski sunucuda görünür.

TTL Değeri Neyi Belirler?

Her DNS kaydının yanında bir TTL (Time To Live) değeri saniye cinsinden tanımlıdır. Bu değer, resolver'lara "bu cevabı şu kadar saniye saklayabilirsin" der. TTL 3600 ise bir resolver kaydı bir saat boyunca yeniden sormadan kullanır. Dolayısıyla propagasyon süresinin en büyük belirleyicisi, değişiklikten önce geçerli olan TTL'dir. Kaydı bugün düşük bir TTL ile güncellemeniz, dünden kalma yüksek TTL'li kopyaların hemen silinmesini sağlamaz; o eski kopyalar kendi süreleri dolana kadar geçerli kalmaya devam eder.

  • Düşük TTL (300 sn): Hızlı değişim, ancak resolver'lar daha sık sorgu yapar.
  • Yüksek TTL (86400 sn): Daha az sorgu yükü, fakat değişiklik bir güne kadar görünmeyebilir.
  • Planlı geçişler: Taşıma yapmadan birkaç gün önce TTL'i düşürmek, kesinti penceresini ciddi ölçüde daraltır.

Neden Saatler, Bazen Günler Sürer?

Gecikmenin tek bir sebebi yok. Birkaç katman üst üste binince toplam süre uzar:

  • Nameserver değişikliği: NS kaydını değiştirmek, A kaydını değiştirmekten yavaştır. Üst seviye alan (TLD) sunucularındaki delegasyon bilgisi de güncellenmelidir.
  • ISP resolver önbellekleri: Bazı sağlayıcılar TTL'e tam uymaz, kayıtları kendi belirledikleri minimum süre kadar tutar.
  • Negatif önbellek (SOA minimum): Henüz var olmayan bir kayıt sorgulandıysa, "yok" cevabı da bir süre saklanır. Bu süre SOA kaydındaki son alandan gelir.
  • WHOIS / registry gecikmesi: Yeni tescil edilmiş bir alanda kök delegasyonun oturması ek zaman alabilir.

Kayıt Türlerine Göre Davranış Farkı

Kayıt TürüTipik KullanımÖnerilen TTLGeçiş Hassasiyeti
A / AAAAAlan adını IPv4 / IPv6'ya bağlar300 - 3600 snYüksek
CNAMEBir adı başka bir ada yönlendirir3600 snOrta
MXE-posta sunucusunu tanımlar3600 - 14400 snÇok yüksek
NSYetkili nameserver'ları belirtir86400 snEn yüksek
TXTSPF, DKIM, doğrulama kayıtları3600 snDüşük

Propagasyon Durumunu Komutla Kontrol Etme

Tarayıcıyı yenileyip durmak yerine, doğrudan sorgulama araçlarıyla hangi sunucunun ne döndürdüğünü görebilirsiniz. dig komutu Linux ve macOS üzerinde en güvenilir yöntemdir:

# Yetkili sunucudan doğrudan sor, önbelleği atla
dig +short ornek.com A @8.8.8.8

# TTL ve tam cevap zincirini gör
dig ornek.com A

# Nameserver delegasyonunu kontrol et
dig ornek.com NS +trace

# Cloudflare resolver ile farklı bir noktadan teyit
dig ornek.com A @1.1.1.1

Windows tarafında ise nslookup ornek.com 8.8.8.8 ile aynı mantıkla farklı resolver'ları sorgulayabilirsiniz. Farklı DNS sunucularından gelen cevaplar tutuyorsa propagasyon büyük ölçüde tamamlanmış demektir.

Geçiş Sürecini Hızlandırmanın Yolları

Süreci sıfırlayamazsınız ama yönetebilirsiniz. yeni bir alan adı tescili sırasında nameserver'ları en baştan hedef panelle eşleştirmek, sonradan yapılacak ikinci bir değişikliği gereksiz kılar ve toplam bekleme süresini kısaltır.

  • Önceden TTL düşürün: Taşımadan 24-48 saat önce kritik kayıtların TTL'ini 300 saniyeye çekin.
  • Eski sunucuyu hemen kapatmayın: Geçiş penceresi boyunca iki sunucu da yayında kalsın ki kimse kesinti görmesin.
  • Lokal önbelleği temizleyin: Kendi makinenizde eski cevap görüyorsanız sudo systemd-resolve --flush-caches veya Windows'ta ipconfig /flushdns çalıştırın.
  • Yerel testte hosts dosyası: Yeni sunucuyu propagasyonu beklemeden test etmek için /etc/hosts dosyasına geçici bir satır ekleyin.

Bogahost Önerisi: Yüksek trafikli bir siteyi taşıyorsanız, geçişten birkaç gün önce TTL'i düşürün ve değişikliği gece yarısı gibi düşük yoğunluklu bir saatte yapın. Eski kaynağı en az bir gün açık tutarak, geç güncellenen resolver'lardan gelen ziyaretçilerin kesinti yaşamasını önlersiniz.

Sunucu Tarafında Nelere Dikkat Etmeli?

Propagasyon yalnızca DNS'le sınırlı değildir; hedef sunucunun yeni alan adını tanıyacak şekilde hazır olması gerekir. Bir sanal sunucu üzerinde barındırma yapıyorsanız, alan adı henüz yeni IP'ye düşmeden önce sanal host yapılandırmasını, SSL sertifikasını ve gerekli yönlendirmeleri tamamlamış olun. Aksi halde kayıt yayılır yayılmaz ziyaretçiler eksik bir kurulumla karşılaşır.

Özellikle SSL tarafında dikkatli olun: Let's Encrypt gibi otomatik sertifika sağlayıcıları doğrulama için alan adının yeni sunucuya çözümlenmesini bekler. DNS henüz oturmamışsa certbot ile yapılan HTTP-01 doğrulaması başarısız olabilir. Bu durumda DNS-01 yöntemi tercih edilebilir, çünkü doğrulama bir TXT kaydı üzerinden yapıldığından sitenin yeni IP'ye düşmüş olması şart değildir.

E-posta tarafında da MX kaydını taşırken eski ve yeni posta sunucusunu bir süre paralel çalışır tutmak önemlidir. Propagasyon bitene kadar bazı gönderenler hâlâ eski MX'e teslimat denemesi yapacağından, eski sunucuyu erken kapatmak teslim edilemeyen e-postalara yol açar.

Özetle

DNS propagasyonu, dağıtık önbellek mimarisinin doğal bir sonucudur ve genellikle birkaç saat içinde, çoğu durumda 24 saat dolmadan tamamlanır. Süreci öngörülebilir kılmanın anahtarı, değişiklikten önce TTL'i kısaltmak, geçiş boyunca eski kaynağı açık tutmak ve dig gibi araçlarla farklı noktalardan teyit almaktır. Planlı bir geçişte propagasyon bir engel değil, yönetilebilir bir bekleme penceresine dönüşür.

Reklam Alanı

İçerik Altı (728x90)

Etiketler:
alan adı dns Nameserver TTL Propagasyon dig DNS Kayıtları
İlgili İçerikler

Yorumlar (0)

Henüz yorum yapılmamış. İlk yorumu siz yapın!

Yorum Yap

Maksimum 2000 karakter

İlgili Yazılar