DNS Yayılma Süresi Aslında Ne Anlama Gelir?
"DNS propagation" (DNS yayılma süresi) ifadesi biraz yanıltıcıdır: bir DNS kaydı değiştirildiğinde bu bilgi internet genelinde tek bir dalga hâlinde "yayılmaz". Bunun yerine, dünya genelindeki binlerce bağımsız DNS resolver'ı — ISP'nizin resolver'ı, Google'ın 8.8.8.8'i, Cloudflare'in 1.1.1.1'i, işletim sisteminizin önbelleği, tarayıcınızın önbelleği — eski kaydı kendi belirlediği süre boyunca önbellekte tutar ve bu süre dolduğunda authoritative nameserver'a tekrar sorup yeni değeri alır.
Bu yüzden bir DNS değişikliğinin "ne zaman tam yayılacağı" sorusunun tek bir cevabı yoktur; her resolver kendi önbellek süresine göre farklı bir zamanda güncellenir. Kaydı değiştirdiğiniz an bazı kullanıcılar yeni değeri anında görebilir (kendi resolver'ı kaydı hiç önbelleğe almamışsa), bazıları ise eski TTL süresi dolana kadar eski değeri görmeye devam eder.
TTL Nedir ve Nasıl Belirlenir?
TTL (Time-To-Live), bir DNS kaydının resolver'larda saniye cinsinden ne kadar süre önbellekte tutulacağını belirten değerdir ve alan adının yönetildiği DNS zone'unda kayıt bazında tanımlanır. Örneğin bir A kaydına 3600 saniyelik (1 saat) TTL verirseniz, bu kaydı sorgulayan bir resolver sonucu bir saat boyunca kendi önbelleğinde tutar ve bu süre içinde gelen aynı sorguları authoritative nameserver'a gitmeden doğrudan önbellekten yanıtlar.
Düşük bir TTL (ör. 300 saniye), değişikliklerin görece hızlı yayılmasını sağlar ama authoritative nameserver'a gelen sorgu sayısını artırır. Yüksek bir TTL (ör. 86400 saniye / 1 gün) sorgu yükünü azaltır ama bir değişiklik yapıldığında eski kaydın önbelleklerden temizlenmesi daha uzun sürer. TTL seçimi bu ikisi arasında bir dengedir ve planlı bir değişiklikten önce geçici olarak ayarlanabilir.
Farklı Kullanıcılar Aynı Değişikliği Neden Farklı Zamanlarda Görür?
Bir DNS sorgusu, kullanıcıdan authoritative nameserver'a giden yolda birden fazla bağımsız önbellek katmanından geçebilir: tarayıcının kendi DNS önbelleği, işletim sisteminin resolver önbelleği, yerel ağdaki router ve ISP'nin recursive resolver'ı veya kullanılan bir public resolver. Bu katmanların her biri kaydı kendi önbelleğe alma anına göre farklı bir sürede günceller; bu yüzden aynı anda iki farklı kullanıcı, aynı alan adı için hâlâ farklı IP adresleri görebilir.
| Katman | Kaydı Kim Önbellekler | Tipik Etki |
|---|---|---|
| Tarayıcı | İşletim sistemi üzerinden ayrı bir DNS önbelleği tutabilir | Sekme/tarayıcı yeniden başlatılana kadar eski kayıt görülebilir |
| İşletim sistemi | Yerel resolver önbelleği | TTL süresi boyunca eski kayıt döner |
| ISP / recursive resolver | Aynı ağdaki tüm kullanıcılar için ortak önbellek | TTL süresi boyunca, o ISP'nin tüm kullanıcılarını etkiler |
| Public resolver (8.8.8.8, 1.1.1.1 vb.) | Kendi coğrafi konumlarında dağıtık önbellek | TTL'e bağlı, bazen kendi minimum süresini uygular |
TTL Kayıt Tipine Göre Değişir mi?
Bir DNS zone'unda her kayıt satırının (A, AAAA, CNAME, MX, TXT gibi) kendi TTL değeri olabilir; TTL, zone'un tamamı için değil, kayıt bazında tanımlanır. Bu yüzden bir alan adının A kaydı 3600 saniyelik TTL'e sahipken, aynı alan adının MX kaydı farklı bir TTL ile tanımlanmış olabilir. Bir değişiklik planlarken yalnızca ilgili kaydın TTL'ine bakmak yeterlidir; diğer kayıt tiplerini etkilemez.
Planlı Bir Değişiklik Öncesi Pratik Öneriler
- Büyük bir değişiklikten (sunucu taşıma, IP adresi değiştirme) 24-48 saat önce ilgili kaydın TTL değerini düşük bir seviyeye (ör. 300 saniye) çekin; böylece eski kayıt resolver önbelleklerinden daha hızlı temizlenir.
- TTL'i düşürdükten sonra, eski (yüksek) TTL süresinin tamamının geçmesini bekleyip asıl değişikliği yapın; aksi hâlde düşürme işleminin kendisi de eski TTL süresince önbellekte kalmış olabilir.
- Eski sunucuyu, yeni kayıt tam yayılana kadar hemen kapatmayın; TTL düşük tutulsa bile bazı resolver'lar eski değeri fazladan tutabilir.
- Değişikliğin authoritative nameserver'a gerçekten işlendiğini doğrulamak için resolver önbelleğini atlayıp doğrudan nameserver'a soran bir sorgu aracı kullanın; bu, kullanıcıların ne göreceğinden bağımsız olarak kaydın sunucu tarafında doğru olduğunu teyit eder.
- Değişiklik tamamlandıktan ve doğrulandıktan sonra TTL'i normal seviyesine (ör. 3600 saniye veya daha yüksek) geri yükseltmeyi unutmayın; sürekli düşük TTL, authoritative nameserver'a gelen sorgu yükünü gereksiz yere artırır.
Sık Yapılan Hatalar
- DNS değişikliğinin anında ve global olarak etkili olacağını varsaymak: gerçekte her resolver kendi önbellek süresine göre güncellenir, tek bir "yayılma anı" yoktur.
- Planlı bir taşıma öncesinde TTL'i önceden düşürmemek: TTL yüksekken yapılan bir değişiklik, eski kaydın saatlerce hatta günlerce önbelleklerde kalmasına yol açabilir.
- DNS kaydı (A, CNAME gibi) değişikliğini nameserver (NS kaydı) değişikliğiyle karıştırmak: bir alan adının nameserver'larını değiştirmek, kayıt TTL'inden bağımsız olarak root ve TLD sunucularındaki NS kaydı önbelleğine bağlıdır; bu üst seviye kayıtların TTL'i genellikle alan adı sahibinin kontrolünde değildir, bu yüzden nameserver değişiklikleri sıradan kayıt değişikliklerinden daha uzun sürebilir.
- TTL'i her zaman olabildiğince düşük tutmayı "daha güvenli" sanmak: sürekli çok düşük bir TTL, sıradan kullanımda gereksiz sorgu yükü oluşturur ve bazı resolver'ların uyguladığı minimum TTL politikalarıyla çelişebilir.
Bir değişiklik yaptıktan sonra "ne zaman tam yayılmış olur" sorusuna kaba bir tahmin almak için, kaydın TTL değerini okunabilir bir süreye çeviren ve olası en kötü durumu hesaplayan aşağıdaki aracı kullanabilirsiniz.
TTL değerini saniye olarak girin, değişikliğin okunabilir yayılma süresini ve olası en kötü durum senaryosunu görün.