Her hosting sağlayıcısının destek sayfası aynı şeyin bir versiyonunu söyler: "DNS değişiklikleri yayılması 24 ila 48 saat sürebilir."
Bu, ağ teknolojilerindeki en dayanıklı yanlış bilgi parçalarından biridir. Zamanlama her zaman yanlış olduğu için değil — bazen gerçekten bu kadar sürer — ama yarattığı zihinsel model tamamen tersine döndüğü için, ve bu yanlış model, insanların var olmayan sorunları saatlerce hata ayıklamak için harcamasının ve gerçek olanları kaçırmasının nedenidir.
DNS yayılmaz. Hiçbir şey dışarı doğru yayılmaz. İnternet üzerinde dalgalanan bir güncelleme dalgası yoktur. Gerçekte ne olduğunu anladığınızda, zamanlama öngörülebilir, kontrol edilebilir ve genellikle 48 saatten çok daha hızlı hale gelir.
Kimsenin size söylemediği şey: değişikliğiniz zaten yayında
Bir DNS kaydını güncellediğinizde, yetkili sunucu — bölgeniz için gerçek doğruluk kaynağı — yeni değere neredeyse anında sahip olur. Sağlayıcınıza bağlı olarak, bir bölge yeniden yüklemesi birkaç saniye, ya da ikincil ad sunucularının bir bölge aktarımı yoluyla bunu alması bir dakika sürebilir. Ama yayındadır. Şu anda. Gidip sorgulayabilir ve yeni değeri görebilirsiniz.
Peki dünyanın geri kalanı neden hâlâ eskisini görüyor?
Çünkü kimse yetkili sunucuya sormuyor. Çözümleyicilere soruyorlar, ve çözümleyiciler hatırlıyor.
Bir çözümleyici on dakika önce kaydınızı aradığında, yanıtı bir geri sayımla birlikte hafızasında tuttu — kayıtta ayarladığınız TTL, yaşam süresi. Bu geri sayım sıfıra ulaşana kadar, çözümleyici kimseye sormadan zaten sahip olduğu yanıtı vermeye devam edecektir. Tembel ya da bozuk değildir. Bu, DNS'in tüm tasarımıdır: internetin herkesin sürekli aynı soruları tekrar sormasının ağırlığı altında çökmemesi için agresif bir şekilde önbelleğe almak.
Yani değişiklik dışarı doğru yayılmıyor. Eski yanıtlar sona eriyor — bağımsız olarak, farklı anlarda, her biri geri sayımına farklı bir zamanda başlayan milyonlarca ayrı önbellekte.
Neden bazıları görürken bazıları görmüyor
İşte "yayılımı" gerçek hissettiren kısım, ve bu sadece aritmetik.
Diyelim ki kaydınızın TTL'si bir saat, ve öğlen değiştiriyorsunuz.
- Eski değeri 11:10'da önbelleğe alan bir çözümleyicinin on dakikası kalmıştır. Yeni değeri 12:10'da gösterir.
- Onu 11:59'da önbelleğe alan bir çözümleyicinin elli dokuz dakikası kalmıştır. Yeni değeri 12:59'da gösterir.
- Onu hiç aramamış bir çözümleyici, birisi sorguladığı anda yetkili sunucuya sorar ve yeni değeri anında alır.
Üç çözümleyici, üç tamamen farklı geçiş zamanı, bir kayıt. Hiçbir şey hiçbir yere yayılmadı. Her önbellek, kendi zamanlayıcısı bittiğinde basitçe sona erdi.
Bu yüzden kaydınızı farklı ağlardan kontrol etmek size çelişkili yanıtlar verir, ve telefonunuz mobil veride yeni siteyi görürken ofis wifi'sindeki dizüstü bilgisayarınız görmez. Farklı önbellek yaşlarına sahip farklı çözümleyicilerle konuşuyorlar. Farklı ağlardaki çözümleyiciler arasında bir yayılım kontrolü çalıştırmak bunu doğrudan gösterir — ve yararlı içgörü "ne kadar ilerledi" değil, bölünmenin kendisidir. Eski ve yeni yanıtların karışımı önbellekleme anlamına gelir. Her yerde, hatta önbelleğe alınmış olmaması gereken çözümleyicilerden bile tek tip olarak eski yanıtlar, değişikliğinizin gerçekte yayınlanmadığı anlamına gelir.
Maksimum bekleme sizin TTL'inizdir. 24 saat değil, 48 değil. TTL'iniz 300 saniyeyse, en kötü durum beş dakikadır. Kuralın tamamı bu.
Peki "48 saat" nereden geliyor?
Tamamen uydurma değil — insanların daha sonra yanlış duruma uyguladığı gerçek bir şeyden geliyor.
İki farklı DNS değişikliği türü vardır, ve tamamen farklı davranırlar:
Bölgeniz içindeki bir kaydı değiştirmek (bir A kaydı, bir CNAME, bir MX). Bu, kontrol ettiğiniz kendi TTL'iniz tarafından yönetilir. 300'e ayarlayın ve değişiklikler beş dakika sürer.
Kayıt kuruluşunuzdaki ad sunucularınızı değiştirmek. Bu bir delegasyon değişikliğidir, ve sizin bölgenizde değil, TLD'nin bölgesinde yaşar. Bu TTL'i siz kontrol etmezsiniz — kayıt otoritesi kontrol eder. .com için, TLD bölgesindeki NS kayıtları 172800 saniyelik bir TTL taşır. Bu tam olarak 48 saattir.
İşte efsanenin geldiği yer burası. Ad sunucusu değişiklikleri gerçekten iki güne kadar sürebilir, çünkü çözümleyiciler delegasyonun kendisini o kadar süre önbelleğe alır. Bir noktada, nadir, yavaş işlem için olan zamanlama, yapılan her DNS değişikliğine uygulanmaya başladı ve hosting destek sayfaları o zamandan beri bunu tekrarlıyor.
Bir A kaydını değiştiriyorsanız, 48 saat saçmalıktır. Ad sunucularını yeni bir sağlayıcıya taşıyorsanız, bu gerçektir — ve bunu hızlandırmak için yapabileceğiniz hiçbir şey yoktur, çünkü TTL sizin değildir.
Herkesin biraz yanlış yaptığı numara
Bir geçiş planlamak için standart tavsiye şudur: değişiklikten önce TTL'inizi düşürün. Bu doğrudur, ve neredeyse herkes bunu yanlış uygular.
Hata, TTL'i değişiklikten bir saat önce düşürmektir. İşte neden başarısız olduğu:
Çözümleyiciler sadece kaydı önbelleğe almaz — kaydı aldıkları anda eklenmiş olan TTL ile birlikte önbelleğe alırlar. TTL'iniz 86400 (24 saat) idiyse ve bir çözümleyici kaydınızı altı saat önce önbelleğe aldıysa, o kaydı saatte 18 saat kalmış olarak tutuyor demektir. TTL'i şimdi 300'e düşürmek, o çözümleyicinin hafızasına ulaşıp bir şey değiştirmez. Hâlâ 18 saati vardır, ve süresi dolup tekrar sormadan yeni kısa TTL'inizi öğrenmeyecektir.
TTL'i değişiklikten en az bir tam eski-TTL süresi önce düşürmelisiniz. TTL'iniz 24 saatse, 24 saat önceden düşürün. Bu, her önbelleğe süresinin dolması ve kaydı yeni, kısa TTL ile yeniden alması için zaman tanır. Sonra değişikliğinizi yapın, ve beş dakika içinde her yerde görünür olacaktır.
Tam sıra:
- TTL'i 300'e düşürün. Bir tam eski-TTL süresi bekleyin (24 saatse 24 saat).
- Gerçek değişikliğinizi yapın. Artık her yerde 5 dakika içinde görünür.
- Her şeyin çalıştığını onayladıktan sonra, TTL'i makul bir şeye geri yükseltin.
Bu son adım göründüğünden daha önemlidir. Kalıcı olarak düşük bir TTL, her çözümleyicinin ad sunucularınızı sürekli yeniden sorgulaması anlamına gelir — daha fazla yük, kullanıcılarınız için daha fazla gecikme, ve DNS sağlayıcınızda bir kesinti olursa çok daha büyük bir etki alanı, çünkü kimsenin geri dönebileceği önbelleğe alınmış bir yanıtı yoktur.
Yayılım gibi görünen ama olmayan beş şey
TTL süresi dolduktan sonra ve hâlâ yanlışsa, artık normal önbelleklemeyle uğraşmıyorsunuzdur. İşte olağan suçlular:
İşletim sisteminizin kendi önbelleği var. Çözümleyiciden ayrı, makinenizde oturan, kendi kurallarıyla. Windows'ta ipconfig /flushdns, macOS'ta sudo dscacheutil -flushcache, çoğu modern Linux'ta resolvectl flush-caches. Kaydınız telefonunuzda çalışıp dizüstü bilgisayarınızda çalışmıyorsa, üst tarafı suçlamadan önce bunu kontrol edin.
Tarayıcınızın da kendi önbelleği var. Chrome, işletim sisteminden tamamen bağımsız bir DNS önbelleği tutar, chrome://net-internals/#dns adresinde görülebilir. Geliştiricilerin, tüm komut satırı araçları doğru raporlarken bayat sonuçlar görmesinin sık bir nedenidir.
Uygulamanız dil çalışma zamanı seviyesinde önbelleğe alır. Klasik örnek, varsayılan olarak süreç ömrü boyunca DNS aramalarını tarihsel olarak önbelleğe alan JVM'dir — yani uzun süre çalışan bir Java hizmeti, TTL'lerden tamamen etkilenmeden haftalarca ölü bir IP adresi tutabilir. Herhangi bir uzun ömürlü süreç, başlangıçtan itibaren çözümlenmiş bir adresi tutuyor olabilir.
Genel çözümleyiciler tek bir önbellek değildir — yüzlercedir. Bu incelikli olandır. 8.8.8.8'i sorguladığınızda, bir sunucuyla konuşmuyorsunuz. Google'ın birçok çözümleyici örneğinden size en yakın olana yönlendirilen bir anycast adresiyle konuşuyorsunuz, ve her örneğin kendi bağımsız önbelleği var. Farklı şehirlerden "aynı" çözümleyiciyi sorgulayan iki kişi, farklı önbellek durumlarına sahip farklı makinelere ulaşır. Aynı konumdan iki kez sorgulamak bile farklı örneklere düşebilir. Bu yüzden genel bir çözümleyici eski ve yeni yanıtlar arasında ileri geri gidip geliyormuş gibi görünebilir — çırpınmıyor, sadece size farklı makineler tarafından hizmet veriliyor.
Bazı çözümleyiciler TTL'inizi yok sayar. TTL bir istektir, bir sözleşme değil. Birçok ISS çözümleyicisi kendi minimum tabanını dayatır — beş dakikalık bir TTL otuz dakika olur çünkü politikaları budur. Ayrıca, çözümleyicilerin yetkili sunucularınıza ulaşamadıklarında süresi dolmuş kayıtları verebilmelerine izin veren standartlaştırılmış bir mekanizma (serve-stale) da vardır, ki bu esneklik için gerçekten yararlıdır ve bir geçiş sırasında kafa karıştırıcıdır.
Bunu gerçekte nasıl hata ayıklarsınız
Tüm teşhis tek bir karşılaştırmaya indirgenir. Doğrudan yetkili sunucuya sorun, sonra bir çözümleyiciye sorun, ve aynı fikirde olup olmadıklarına bakın.
- Yetkili yeni değere sahip, çözümleyici eskiye sahip. Her şey çalışıyor. Bu önbellek. TTL'i kontrol edin, bekleyin. Hiçbir şey bozuk değil ve düzeltilecek bir şey yok.
- Yetkili hâlâ eski değere sahip. Değişikliğiniz asla yayınlanmadı. Sorun DNS'te değil, sağlayıcınızın kontrol panelinde — kayıt kaydedilmedi, yanlış bölgeye kaydedildi, ya da ad sunucularınız beklemediğiniz bir yere işaret ediyor. Bu gerçek bir hatadır, ve hiçbir bekleme onu düzeltmez.
Doğrudan yetkili sunucuyu sorgulamak tüm numaranın kendisidir, ve hangi sunucuya soracağınızı belirtmenize izin veren bir DNS sorgulama aracı ihtiyacınız olan tek şeydir. O tek kontrol size fiziği mi beklediğinizi yoksa bir hataya mı baktığınızı söyler — ve efsanenin önerdiği bir buçuk günlük beklemeye karşı yaklaşık on beş saniye sürer.
Saklamaya değer yeniden çerçeveleme: DNS yavaş değildir. Önbellekler sabırlıdır, ve onlara ne kadar sabırlı olacaklarını siz söylediniz. Bu sayının sizin olduğunu ve onu önceden ayarladığınızı içselleştirdiğinizde, gizemin çoğu buharlaşır — ve "48 saat bekleyin" kabul ettiğiniz bir tavsiye olmaktan çıkar.