Yanlış DNS Değişikliği Yaptınız: Rollback Stratejisi ve Acil Müdahale

Bir DNS değişikliği yaptınız ve bir dakika sonra site yanıt vermiyor. Panel doğru görünüyor, kayıt girildi, kaydet tuşuna bastınız. Ama tarayıcı boş sayfa gösteriyor, SSH bağlantısı koptu, müşteriler e-posta gönderemiyor. Bu senaryo, yönetim panelinde geçirilen tek bir dikkatsiz dakikanın sonucudur.

İlk içgüdü paniğe kapılmak ya da derhal "geri al" düğmesine basmaktır. Ama DNS'te "geri al" o kadar basit çalışmaz: değişiklik zaten önbelleğe alınmış olabilir, resolver'lar eski değeri tutmaya devam edebilir ya da düzeltmeyi yapmak yeni bir propagasyon sürecini başlatabilir. Hızlı hareket etmek ile doğru hareket etmek, bu durumda aynı anlama gelmez. Yerel önbellek hâlâ eskiyse önce flush ile bakın.

Yanlış kaydı geri almak, yeni bir TTL saati başlatır. Hata tipi NS ise registrar paneline bakın; A veya CNAME ise zone'u düzeltmek yeter. Çift kayıt, bazı platformlarda sertifikayı bozar.

Hata Anını Tespit Etmek: İlk 5 Dakikada Ne Yaparsınız?

Hatanın türünü bilmeden müdahale planlayamazsınız. İki temel soru sormak gerekir: hangi kayıt tipini değiştirdiniz ve değişikliği ne kadar önce yaptınız?

Eğer A kaydını değiştirdiyseniz, site yanlış IP adresine yönleniyor demektir. DNS propagasyonu tamamlanmamış resolver'lar hâlâ eski adresi döndürüyor olabilir; bu durumda bazı kullanıcılar siteye ulaşırken bazıları ulaşamaz. Eğer NS (nameserver) kaydını değiştirdiyseniz, sorun daha köktendir: alan adı artık farklı bir otorite sunucusuna danışıyor, o sunucuda kayıt yoksa tüm sorgular hata döndürür.

Değişikliği yaptıktan sonraki ilk beş dakika çok değerlidir. Henüz TTL süresi dolmamışsa çoğu resolver eski değeri önbellekte tutar. Bu pencerede doğru değeri geri koyarsanız, birçok kullanıcı hiç kesinti yaşamadan geçiş sürecini atlatır. Bunu kontrol etmek için birkaç farklı resolver'dan sorgu yapabilirsiniz; ham okuma dig çıktısından yapılır:

dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
dig @9.9.9.9 example.com NS

Farklı resolver'lardan gelen farklı yanıtlar, propagasyonun hâlâ devam ettiğini gösterir. Hepsi yanlış değeri döndürüyorsa TTL süresi dolmuş demektir; bu noktada düzeltme yapmak tek çıkış yoludur ama propagasyon sürecinin başından sayılacağını da hesaba katmak gerekir.

TTL Değeri: Beklemek Zorunda mısınız?

TTL (Time to Live), bir DNS kaydının resolver önbelleklerinde ne kadar süre saklanacağını belirler. Değer 3600 saniyeyse, hatalı kaydı geri aldıktan sonra bile bazı resolver'lar bu değeri en fazla bir saat daha önbellekte tutabilir.

Duraksayın. TTL süresini beklemek mecburiyetinde değilsiniz; ama TTL değerini kısaltmak da anında etki yaratmaz. TTL değerini 60 saniyeye indirdiğinizde, bu değer ancak önbellek süresi dolup yeni bir sorgu yapıldığında geçerli olur. Eğer hata anında TTL zaten 3600 ise, bu bir saate kadar eski değer dönmeye devam eder.

TTL'nin işleyişini şöyle düşünebilirsiniz: resolver bir kaydı ilk aldığında TTL değerini sayaç olarak başlatır. Sayaç sıfırlanana kadar o resolver'a gelen her sorgu önbellekteki yanıtla karşılanır. Siz değişiklik yapsanız da resolver yeni değeri ancak sayaç bitince öğrenir. Bu nedenle, planlı bir DNS değişikliğinden 48 saat önce TTL'yi 300 saniyeye indirmek yaygın bir önlem olarak önerilir.

Acil bir rollback yapıyorsanız sıra şöyledir: önce doğru değeri girin, ardından TTL'yi düşürün. Mantığı şudur: ikinci bir hata ya da ikinci bir düzeltme gerektiğinde propagasyon çok daha hızlı tamamlanır. Birinci düzeltmenin yayılması içinse TTL değişikliği yerine zamana ihtiyacınız vardır.

Nameserver (NS) Kaydını Yanlış Girdiyseniz

NS kaydı hatası, en kritik senaryodur. Nameserver kaydı, tüm DNS sorgularının hangi otorite sunucusuna gideceğini belirler. Yanlış bir nameserver girdiğinizde, alan adınız için yapılan her A, MX, CNAME sorgusu artık başka bir sunucuya gider; o sunucu bu alan adını tanımıyorsa NXDOMAIN hatası döner.

Bu durumda müdahale, DNS yönetiminizden değil, domain kayıt şirketinizin panelinden yapılmalıdır. Nameserver değişikliği, zone dosyasında değil, kayıt şirketinin (registrar) sisteminde tutulur. Hosting panelinize girip zone dosyasını düzenlerseniz yanlış yere bakıyorsunuz demektir; değişikliğin etkisi olmaz.

NS değişikliği genellikle 24-48 saat propagasyon süresi ister; bu süre, TTL değerinizden bağımsız olarak root zone güncellenmesine bağlıdır. Eski nameserver'larınız geçiş boyunca hâlâ cevap veriyorsa zone dosyasını güncel tutmak yararlıdır; böylece kullanıcılar hizmet almaya devam eder.

Eski nameserver'larınız çalışmaya devam ediyorsa, yanlış nameserver'ı silmeden önce eski sunuculardaki zone dosyasının güncel olduğundan emin olun. Kendi nameserver'ını işletenler için bu doğrulama kritiktir; böyle bir yapının nasıl kurulduğunu özel nameserver kurulumu konusunda görebilirsiniz.

Bir ayrıntı daha: bazı kayıt şirketleri nameserver değişikliğini onay mekanizmasına bağlar. Değişikliği kaydettiğinizde hemen aktif olmayabilir; registrar kontrol panelinde "beklemede" durumunu gösteren bir bildirim olabilir. Bu onay adımını atlamak, değişikliğin hiç işlenmemesine neden olur.

A Veya CNAME Kaydında Hata: Daha Yönetilebilir Bir Senaryo

A kaydında yanlış IP girmek, nameserver hatasına kıyasla çok daha hızlı çözülür. Doğru IP adresini geri girip kaydetmek genellikle birkaç dakika ile birkaç saat arasında etkisini gösterir, mevcut TTL değerine bağlı olarak.

CNAME kaydında hata biraz farklı davranır. Bir subdomain'i yanlış bir hedefe yönlendirdiyseniz ve o hedef hiç yanıt vermiyorsa kullanıcılar doğrudan bağlantı hatası görür. Hedef yanıt veriyorsa ama yanlış içerik sunuyorsa sorun daha sinsidir; kullanıcılar siteye ulaşıyor gibi görünür ama yanlış içerik görürler. Bu durum, hata fark edilmeden saatlerce sürebilir.

A kaydı rollback adımları:

1. DNS yönetim paneline girin.
2. Hatalı A kaydını bulun, mevcut yanlış IP değerini not alın.
3. Doğru IP adresini girin ve kaydedin.
4. TTL değerini geçici olarak 300 saniyeye indirin.
5. En az üç farklı resolver'dan sorgu yaparak yayılımı izleyin.

Yönetilen DNS servisleri kullananlar, değişiklik geçmişini (audit log) görüntüleyebilir. Google Cloud DNS gibi platformlarda yapılan her kayıt değişikliği zaman damgasıyla loglanır; hatalı değeri hızla belirlemek için bu log'a başvurmak doğru adımdır.

Çift Kayıt Stratejisi: Önleyici Kullanım

Rollback stratejisinin en etkili biçimi, hatayı yapmadan önce uygulanandır. Çift kayıt (dual record) ya da geçiş dönemi stratejisi, yeni bir hedef devreye almadan önce eski kaydı koruyarak her iki hedefe de geçici olarak ulaşılabilmesini sağlar.

Strateji şöyle çalışır: yeni sunucuyu ya da hizmeti DNS'e eklemeden önce eski kaydı silmeden bırakırsınız. Önce yeni hedefe küçük bir trafik yönlendirip doğrularsınız; her şey doğruysa eski kaydı kaldırırsınız. Hata varsa yeni eklediğiniz kaydı silmek yeterlidir; kullanıcılar eski hedeften hizmet almaya devam eder.

Peki bu strateji her zaman işe yarar mı? Hayır. SSL sertifikası doğrulaması yalnızca bir IP üzerinden yapıyorsa, çift A kaydı sertifikayı geçersiz kılabilir. Bazı uygulamalar ise aynı domain'in iki farklı hedefe dönmesini hata olarak yorumlar. Vercel veya Netlify gibi platformlarda CNAME düzleştirme (CNAME flattening) nedeniyle çakışmalar yaşanabilir; bu platformlar çift kayda izin vermez.

Çift kayıt stratejisi en çok A kaydı değişikliklerinde ve subdomain geçişlerinde işe yarar. Subdomain yönetiminde bu yaklaşım hem test imkânı hem de geri dönüş güvencesi sağlar. Ama kendi sınırları olduğunu bilerek kullanmak, beklenmedik sorunların önüne geçer.

E-posta Kayıtları Etkilendi mi?

DNS değişikliği sırasında sık atlanan alan e-postadır. A kaydını değiştirirken MX kaydına dokunmadınız; ama NS kaydını değiştirdiyseniz yeni nameserver'larda MX kaydı tanımlı değilse e-posta da durur. Site çalışsa bile e-posta gelmeyebilir, ya da tam tersi.

MX kaydının etkilenip etkilenmediğini anlamak için şu sorguları kullanabilirsiniz:

dig MX example.com
dig TXT example.com

TXT sorgusunda SPF kaydı yoksa ya da yanlış değer dönüyorsa, giden e-postalar spam klasörüne düşmeye başlar. Bu gecikme, DNS propagasyonu tamamlanana kadar fark edilmeyebilir. E-posta deliverability sorunları çoğu zaman bir DNS değişikliğinin ertesi günü görünür hale gelir; kayıtların doğru göründüğü ama gönderimde sorun yaşandığı durumlarda DNS geçmişini incelemek gerekir.

MX kaydı, A kaydından bağımsız çalışır: site erişilmez olsa bile e-posta sunucusu ayakta kalabilir, ya da tam tersi. Bu iki sistemi ayrı izlemek, kesintinin kapsamını doğru tespit etmenizi sağlar.

Rollback Sonrası Doğrulama Adımları

Düzeltmeyi yaptınız. Şimdi ne kadarının çalıştığını doğrulamanız gerekiyor. Paneli kaydedip bırakmak yeterli değildir; propagasyon tamamlanmadan etki göremezsiniz ve bazı sorunlar ancak belirli bölgelerden gelen sorgularda ortaya çıkar.

Rollback sonrası kontrol listesi:

• En az üç farklı resolver'dan A ve NS sorgularını çalıştırın (8.8.8.8, 1.1.1.1, 9.9.9.9).
• MX kaydının doğru döndüğünü kontrol edin.
• SPF ve DKIM TXT kayıtlarının sağlam olduğunu doğrulayın.
• HTTPS üzerinden site erişimini test edin; sertifika uyarısı varsa not alın.
• Değişiklik geçmişinize (audit log) erişim varsa, hatalı girişin zaman damgasını kaydedin.

Sertifika uyarısı görmek, rollback sırasında sık karşılaşılan bir yan etkidir. Bazı sertifika sağlayıcıları IP değişikliklerini otomatik algılar ve yeniden doğrulama ister. Site teknik olarak erişilebilir olsa bile kullanıcılar güvensiz bağlantı uyarısı görebilir; sertifika yenilemesini ayrıca tetiklemek gerekebilir.

Domain portföyünüzde birden fazla alan adı varsa, bu tür olayların etkisini sınırlamak için standart değişiklik prosedürleri oluşturmak zamanla önemli bir kazanım haline gelir. Domain portföyü yönetimi bu prosedürlerin sistematik biçimde tutulmasını ve değişiklik geçmişinin izlenmesini kapsar.

DNS hatası, hangi deneyim seviyesinde olursa olsun herkese olabilir. Önemli olan, hatanın türünü hızla ayırt etmek, müdahalenin hangi sistemde yapılacağını bilmek ve panikle atılacak yanlış adımları önlemek. Nameserver değişikliği registrar panelinden yapılır; zone kaydı değişikliği DNS yönetim panelinden yapılır. Bu iki sistemi karıştıran müdahaleler sorunu büyütür.

Rollback sonrası en yaygın hata, işin bittiğini düşünüp izlemeyi kesmektir. DNS propagasyonu saatler alabilir; bu sürede farklı kullanıcılar farklı deneyim yaşayabilir. Değişiklikten sonraki ilk iki saat için basit bir izleme rutini kurmak, sessiz kalan sorunları yüzeye çıkarır; özellikle farklı coğrafyalarda kullanıcısı olan siteler için bu adım atlanmamalıdır.

Bir DNS değişikliği öncesinde mevcut zone dosyasının yedeğini almak, rollback sürecini kökten kolaylaştırır. Kayıtların tamamını bir metin dosyasına kopyalamak birkaç dakika alır. Ama bir hata anında bu birkaç dakikalık yatırım, saatlerce uğraşı önleyebilir; zone dosyası el altında olunca hangi değerin doğru olduğunu tartışmak yerine doğrudan eski değeri girebilirsiniz.