DNS yayılımı ne kadar sürer? TTL ve önbelleğin gerçeği

A kaydını değiştirdiniz, Nameserver'ları da yeni sunucuya yönlendirdiniz, ama tarayıcıda site adresini yazdığınızda yine eski sayfa açılıyor. Ya da daha kötüsü: sizde yeni site açılıyor, müşteriniz hâlâ eski sürümü görüyor. İşte bu, çoğu insanın "24 ila 48 saat beklememiz gerekiyor" dediği andır. Bu sayı neredeyse her zaman yanlıştır ve sorun gidermek yerine beklemek sadece zaman kaybıdır.

DNS yayılımı bir zaman aralığı değil, anlık bir olaydır. Kayıt yetkili sunucunuzda kaydedildiği anda yayılım tamamlanmıştır. Uzun süren şey, çözümleyicilerde ve aracı makinelerde önbelleğe alınmış sürümlerin süresinin dolmasıdır. Yani doğru soru "ne kadar sürer" değil, "eski sürümü hâlâ ne tutuyor"dur.

"24 ila 48 saat" neden neredeyse her zaman yanlıştır

Bu sayı, kayıtların varsayılan TTL'sinin 86400 saniye, yani tam olarak bir gün olduğu ve bazı sağlayıcıların tüm önbelleklerin süresinin dolduğundan emin olmak için bunun iki katını önerdiği dönemden geliyor. Bugün çoğu panelde varsayılan TTL 300 ila 3600 saniye arasındadır. Yani teorik en kötü durum bir saat. Pratikte gördüğünüz şey genellikle 5 ila 30 dakika içinde çözülür.

48 saat sayısı bir güvenlik payıydı, teknik bir gerçek değil. Bugün biri size bunu söylüyorsa, gerçek sorunuzu yanıtlamaktan kaçıyordur.

TTL tam olarak neyi kontrol eder

TTL, çözümleyiciye bu yanıtı kaç saniye bellekte tutabileceğini söyler. Çoğu kişinin bilmediği nokta: TTL yalnızca çözümleyicinin o kaydı önbelleğe aldığı andan itibaren geçerlidir, sizin onu değiştirdiğiniz andan itibaren değil. Çözümleyici kaydınızı 5 dakika önce TTL 3600 ile önbelleğe aldıysa, siz şu anda TTL'yi 60 saniyeye düşürmüş olsanız bile 55 dakika daha eski sürümü sunar.

Yani değişiklikten sonra TTL'yi düşürmek işe yaramaz. Değişiklikten önce yapılmalıdır.

Doğru yöntem: TTL'yi transferden önce düşürün

Yarın öğlen sunucuyu değiştireceğinizi biliyorsanız, bugün A ve AAAA ve CNAME kayıtlarının TTL'sini 300 saniyeye düşürün. Eski önbelleklerin eski TTL ile süresinin dolması için bir gün bekleyin. Sonra değişikliği yapın. Artık yayılım pencereniz bir gün değil, yaklaşık beş dakikadır.

İş sırası şöyledir:

1. 24 saat önce: TTL'yi 300'e ayarlayın ve eski önbelleğin süresinin dolmasını bekleyin.
2. A kaydını yeni sunucunun IP'sine değiştirin.
3. dig ile birkaç farklı noktadan yeni yanıtın döndüğünü doğrulayın.
4. Oturduktan sonra TTL'yi normal değerine döndürün.

Kontrol için yerel önbelleğe değil, yetkili çözümleyiciye sorun:

dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8
dig +trace example.com

1.1.1.1 ve 8.8.8.8 yanıtı aynıysa ve yeni IP'yi gösteriyorsa, genel düzeyde yayılım tamamlanmıştır. Biri hâlâ eski IP'yi döndürüyorsa, o çözümleyicinin hâlâ önbelleği vardır ve kalan TTL'inin dolması gerekir.

Bazı kullanıcılar neden hâlâ eski siteyi görüyor

Üç önbellek katmanı vardır ve çoğu sorun giderme yalnızca ilk katmanı görür:

• ISP çözümleyici önbelleği: bazı yerel ISP'ler TTL'i yok sayar ve saatlerce eski yanıtı tutar. Bu sizin kontrolünüzün dışındadır.
• İşletim sistemi önbelleği: Windows'ta ipconfig /flushdns ile, Linux'ta systemd-resolve --flush-caches ile temizlenir.
• Tarayıcı önbelleği: DNS'ten bağımsızdır ve kayıt değişikliğiyle temizlenmez.

İşte burada hata yapılıyor: kullanıcı dig ile yeni IP'yi görür, DNS'in düzeldiği sonucuna varır ve sonra müşterinin şikayetini görmezden gelir. Oysa müşteri inatçı bir çözümleyiciye sahip bir ISP'nin arkasındadır. Pratik çözüm, trafik her iki yoldan da gelsin diye bir süre her iki sunucuyu da ayakta tutmaktır.

Kesintisiz transfer: az söylenen nokta

Bir e-ticaret siteniz varsa, DNS yayılım penceresi yalnızca teknik bir mesele değildir. Ödeme işleminin ortasında olan ve aniden başka bir sunucuya giden kullanıcı, sepetini kaybeder. Çözüm, kaydı değiştirmeden önce veritabanını yeni sunucuda hazırlamak ve değişiklikten sonra bir süre her iki sunucuyu senkron tutmaktır. Bunun için WordPress'i eklentisiz taşıma, işin ortasında taşıma eklentilerine güvenmekten daha güvenli bir yoldur.

Bu yöntemin maliyeti: birkaç saat boyunca iki sunucuyu aynı anda ödemeniz ve manuel senkronizasyon yapmanız gerekir. Site kişisel veya küçük bir blogsa bu fazladır ve riski kabul edebilirsiniz. Mağaza için, hayır.

CNAME ve MX kayıtları farklı davranır

A kaydı hızlı yayılır çünkü yalnızca bir IP'dir. CNAME bir zincirdir ve her halkanın kendi TTL'i vardır; CNAME'iniz kendisi de CNAME'e sahip başka bir alan adına işaret ediyorsa toplam gecikme artar. E-posta için MX kaydı genellikle daha yüksek TTL'e sahiptir ve değiştirilmesi e-postaları birkaç saate kadar eski sunucuya gönderebilir. Site transferiyle aynı anda e-postayı da taşıyorsanız, bu ikisini ayrı ayrı ve aralıklı yapın.

Seçeneklerin karşılaştırması: TTL'i düşürmek mi yoksa beklemek mi

Benim tercihim birinci yöntemdir. İkinci yöntemi kabul edilebilir kılan tek koşul, sitenizin çok az trafiğe sahip olması ve kısa kesintinin sizin için önemsiz olmasıdır.

İşi hızlandıran araçlar

Yayılımı birkaç coğrafi noktadan kontrol etmek için DNS propagation checker servislerini kullanın, ancak dikkat edin: bu araçlar da yalnızca kendi çözümleyicilerine sorar, tüm dünyaya değil. Yeni sunucunun gerçekten doğru yanıt verdiğinden emin olmak istiyorsanız, kaydı değiştirmeden önce curl ve Host başlığıyla test edin:

curl -I -H "Host: example.com" http://192.0.2.10/

Yanıt 200 döndüyse, yeni sunucu hazırdır ve kaydı gönül rahatlığıyla değiştirebilirsiniz. Bu küçük bir adım, transfer sonrası sıkıntıların yarısını ortadan kaldırır.

WordPress üzerinde çalışıyorsanız, transferden sonra mutlaka nesne önbelleğini ve sayfa önbelleğini temizleyin, yoksa DNS doğru olabilir ama site hâlâ önbelleğe alınmış sürümü gösterebilir. Terminalden durumu hızlıca kontrol etmek için temel WP-CLI komutları, önbelleği temizlemek ve veritabanı durumunu kontrol etmek için birkaç hazır komut içerir.

Sık sorulan sorular

DNS yayılımı gerçekte ne kadar sürer?

Pratikte kaydın TTL'ine ve ISP çözümleyicisinin davranışına bağlı olarak 5 ila 60 dakika arasında. TTL'yi önceden 300 saniyeye düşürdüyseniz, genellikle 10 dakikanın altında tamamlanır. 24 ila 48 saat sayısı, varsayılan TTL'in bir gün olduğu döneme aittir.

Neden yeni siteyi ben görüyorum ama müşteri eski siteyi görüyor?

Çünkü kullanıcının veya ISP'sinin tarafındaki DNS önbelleğinin süresi henüz dolmamıştır. Bu durum kalan TTL bitene kadar devam eder ve sizin tarafınızdan hızlandırılamaz. Tek pratik yol, eski kullanıcıların da doğru yanıt alması için bu aralıkta eski sunucuyu ayakta tutmaktır.

Kaydı değiştirdikten sonra TTL'i düşürmek işe yarar mı?

Hayır. TTL, çözümleyicinin kaydı önbelleğe aldığı andan itibaren geçerlidir, sizin değişiklik anınızdan değil. Çözümleyici eski sürümü TTL 3600 ile önbelleğe aldıysa, TTL'i 60 saniyeye düşürmenin o önbelleğe hiçbir etkisi yoktur. TTL düşürme, değişiklikten en az bir gün önce yapılmalıdır.

DNS yayılımının bittiğini nasıl anlarım?

Birkaç genel çözümleyiciye doğrudan sorarak. dig +short A example.com @1.1.1.1 ve aynı komut @8.8.8.8 ile her ikisi de yeni IP'yi döndürüyorsa, genel düzeyde yayılım tamamlanmıştır. Daha fazla emin olmak için yeni sunucuyu curl -I -H "Host: example.com" ile test edin ve doğru HTTP yanıtı verdiğinden emin olun.

Özetle: TTL'i transferden önce düşürün, yeni sunucuyu kaydı değiştirmeden önce test edin ve değişiklikten sonra bir süre her iki sunucuyu da ayakta tutun. Bu geçişleri sık sık yaptığınız bir altyapı üzerinde çalışıyorsanız, DNS ve TTL üzerinde tam kontrole sahip Linux hosting bu döngüyü daha öngörülebilir kılar.