Bir kaydı değiştirdiniz ve site kapandı. Hemen eski değeri geri yazdınız ama site hâlâ açılmıyor. Kayıt doğru — ama yanlış değer önbelleklere çoktan yayıldı ve orada bekliyor.
Bu yazı, hatalı bir DNS değişikliğinden dönmeyi ele alıyor.
Geri Alma Neden Anında Değil?
DNS'in temel çalışma biçimi burada aleyhinize döner:
- Yanlış değer sorgulanır.
- Çözümleyiciler önbelleğe alır.
- Süre değeri kadar tutulur.
- Düzeltme o süre sonunda görünür.
Üçüncü adım geri alma hızını tamamen belirler: kaydınızın süre değeri bir saatse, yanlış değeri okumuş bir çözümleyici o değeri bir saat boyunca vermeye devam eder — siz düzeltmeyi saniyeler içinde yapsanız bile.
Bu süre boyunca yapabileceğiniz hiçbir şey yoktur.
Bu nedenle DNS değişikliklerinde geri alma, kod dağıtımındaki gibi anlık değildir.
En Etkili Önlem
| Aşama | İşlem |
|---|---|
| Değişiklikten günler önce | Süre değerini düşürün |
| Eski değer yayılsın | Bekleyin |
| Değişikliği yapın | Kısa süreyle |
| Doğrulayın | Sorun yoksa devam |
| Süreyi geri yükseltin | Birkaç gün sonra |
Birinci satır tüm planın anahtarıdır ve zamanlaması kritiktir: süre değerini düşürmek de yayılması gereken bir değişikliktir — değişiklikten hemen önce düşürmek işe yaramaz, çünkü çözümleyiciler hâlâ eski uzun süreyi biliyordur.
Düşürme işlemi, eski süre kadar önce yapılmalıdır.
İkinci satır bu beklemeyi anlatır ve atlanmaması gerekir.
Beşinci satır ise normal duruma dönüşü sağlar; kısa süre kalıcı olursa sorgu yükü ve maliyet artar.
Süre Düşürülmediyse
Hata zaten yapıldıysa seçenekler sınırlıdır:
- Doğru değeri hemen yazın.
- Süre değerini düşürün.
- Beklemeyi kabul edin.
- Alternatif erişim yolu sunun.
Dördüncü madde tek gerçek çözümdür ve yaratıcılık gerektirir: yanlış adrese yönlenen ziyaretçileri kurtarmak için, o yanlış hedefte geçici bir yönlendirme kurmak mümkün olabilir — kontrolünüzdeyse orayı doğru sunucuya yönlendirin.
Örneğin yanlışlıkla eski sunucuya işaret eden bir kayıt varsa, eski sunucuda yeni adrese yönlendirme kurulabilir.
Bu, bekleme süresini kullanıcı açısından tamamen ortadan kaldırır.
İkinci madde ise sonraki denemeleri hızlandırır ama mevcut önbellekleri etkilemez.
En Riskli Kayıtlar
| Kayıt | Hata etkisi |
|---|---|
| Ad sunucusu | Tüm alan adı gider |
| Posta kaydı | E-posta durur |
| Adres kaydı | Site kapanır |
| Metin kayıtları | Doğrulamalar bozulur |
Birinci satır en tehlikelisidir ve geri alması en zorudur: ad sunucusu kaydı kayıt kuruluşu seviyesinde tutulur ve genellikle çok uzun bir süre değerine sahiptir — yanlış bir ad sunucusu tanımı, düzeltilse bile günlerce etkisini sürdürebilir.
Bu kayıt üzerinde yapılan değişiklikler en dikkatli planlanması gerekenlerdir.
İkinci satır ise sessiz bir kayıp üretir. E-postalar geri döner ve gönderenler tekrar denemez.
Dördüncü satır ise en az fark edileni ama gönderim itibarını etkileyenidir.
Değişiklik Öncesi Kontrol
- Mevcut değeri kaydedin.
- Yeni değeri doğrulayın.
- Hedefin çalıştığını test edin.
- Düşük trafik saati seçin.
Üçüncü madde çoğu kazayı önler: yeni IP adresine geçmeden önce o adreste sitenizin gerçekten çalıştığını doğrulamak, DNS'i değiştirdikten sonra öğrenmekten çok daha ucuzdur.
Bu test, adresi doğrudan çağırarak veya yerel bir ad çözümlemesiyle yapılabilir.
Birinci madde ise geri alma için gereklidir. Eski değeri hatırlamak zorunda kalmamalısınız.
Panelden alınacak bir ekran görüntüsü bile yeterlidir.
Kısmi Yayılma Sorunu
- Bazı kullanıcılar yeni değeri görür.
- Bazıları eskiyi.
- İkisi de bir süre çalışmalıdır.
Üçüncü madde bir geçiş kuralıdır ve sık ihlal edilir: sunucu taşırken eski sunucuyu hemen kapatmak, henüz yeni adresi görmeyen kullanıcıların siteye hiç ulaşamaması demektir — her iki sunucu da yayılma tamamlanana kadar açık kalmalıdır.
Bu süre en az kaydın eski süre değeri kadar olmalıdır.
Güvenli tarafta kalmak için birkaç gün beklemek yaygın bir uygulamadır.
Bu dönemde her iki sunucunun da aynı veriye erişmesi gerekir.
Yayılmayı İzlemek
| Yöntem | Gösterdiği |
|---|---|
| Yetkili sunucuya sorgu | Kayıt doğru mu |
| Farklı çözümleyicilere sorgu | Yayılma durumu |
| Çoklu lokasyon aracı | Coğrafi dağılım |
| Eski sunucu erişim kaydı | Hâlâ kim geliyor |
Dördüncü satır en kesin göstergedir ve az kullanılır: eski sunucunun erişim günlüklerini izlemek, kaç kullanıcının hâlâ eski adrese geldiğini gerçek trafikle gösterir — sorgu araçları yalnızca örnekleme yapar, bu ise gerçeği verir.
Trafik sıfırlandığında geçiş tamamlanmış demektir.
Bu, eski sunucuyu ne zaman kapatabileceğinizi kesin olarak söyler.
İkinci satır ise hızlı bir kontrol sağlar ve birkaç farklı çözümleyiciyle yapılır.
Değişiklik Kaydı
- Ne değiştirildi.
- Eski ve yeni değer.
- Kim ve ne zaman.
- Neden.
Bu kayıt bir sorun çıktığında ilk bakılacak yerdir: bir site kapandığında sorulacak ilk soru "son DNS değişikliği neydi" olmalıdır — kayıt tutulmuyorsa bu bağlantı kurulamaz ve saatlerce yanlış yerde aranır.
Çoğu DNS paneli bu kaydı otomatik tutmaz.
Basit bir tablo veya sürüm kontrolü bu boşluğu doldurur.
Dördüncü madde ise ileride gereksiz geri almaları önler; bir kaydın neden öyle olduğu bilinmelidir.
Kayıtlarınızın güncel durumunu ve geçmiş yapılandırmanızı karşılaştırmak için alan adı sorgulama ekranı üzerinden düzenli kontrol yapabilirsiniz.
Sonuç
DNS'te geri alma anlık değildir: süre değeri bir saatse, yanlış değeri okumuş bir çözümleyici o değeri bir saat boyunca vermeye devam eder — siz düzeltmeyi saniyeler içinde yapsanız bile. Bu yüzden asıl önlem değişiklikten günler önce süreyi düşürmektir; hemen önce düşürmek işe yaramaz çünkü eski uzun süre hâlâ önbelleklerdedir. Ve taşıma sırasında eski sunucuyu hemen kapatmayın; henüz yeni adresi görmeyen kullanıcılar siteye hiç ulaşamaz.
Sıkça Sorulan Sorular (SSS)
Kaydı düzelttim ama site hâlâ açılmıyor?
Yanlış değer önbelleklere yayılmış olabilir. Çözümleyiciler o değeri süre değeri kadar tutar ve siz düzeltmeyi saniyeler içinde yapsanız bile o süre boyunca eski yanıtı vermeye devam ederler. Bu süre boyunca yapabileceğiniz doğrudan bir şey yoktur.
Bunu nasıl önlerim?
Değişiklikten günler önce süre değerini düşürerek. Kritik nokta zamanlamadır: süre düşürme de yayılması gereken bir değişikliktir, hemen önce yapmak işe yaramaz çünkü çözümleyiciler hâlâ eski uzun süreyi biliyordur. Düşürmeyi eski süre kadar önce yapın.
Süreyi düşürmedim, ne yapabilirim?
Alternatif bir erişim yolu kurun. Ziyaretçilerin yönlendiği yanlış hedef sizin kontrolünüzdeyse, orada doğru sunucuya bir yönlendirme tanımlayabilirsiniz — bu, bekleme süresini kullanıcı açısından tamamen ortadan kaldırır.
Eski sunucuyu ne zaman kapatabilirim?
Erişim günlüklerinde trafik sıfırlandığında. Bu, sorgu araçlarından daha kesin bir göstergedir — araçlar örnekleme yapar, günlükler gerçek kullanıcıları gösterir. Yayılma tamamlanana kadar her iki sunucu da açık ve aynı veriye erişir durumda kalmalıdır.
