Kısa cevap: DNS sağlayıcısı değiştikten sonra sitenin bazı ağlarda açılmaması yalnız A kaydı hatası olmayabilir. Kayıt kuruluşunda eski sağlayıcıya ait DS kalmışsa yeni bölgenin DNSSEC doğrulaması başarısız olabilir. Önceki ve yeni DNS yönetim bilgilerini birlikte incelemek gerekir.
Hangi katmanı değiştirdiğinizi yazın
Yalnız hosting IP'si mi değişti, nameserver adresleri mi değişti, yoksa alan adı başka kayıt kuruluşuna mı taşındı? Bu üç işlemin tarihini ayrı kaydedin. Aynı gün yapılan değişiklikler nedeni gizleyebilir. Site taşıma rehberi geçişin görevlerini ayırır. Eski sağlayıcı hesabını tanı tamamlanmadan kapatmayın; mevcut ayarların kanıtına ihtiyaç duyabilirsiniz.
Eski DS ile yeni anahtarı karşılaştırın
Cloudflare'ın bekleyen nameserver belgesi, önceki sağlayıcıdan kalan DS'nin etkisini açıklar. DS genellikle alan adı kayıt kuruluşu üzerinden üst bölgeye yayınlanır; yeni DNS bölgesindeki sıradan kayıt listesinde görünmemesi bulunmadığını kanıtlamaz. Alan adı panelindeki DNSSEC ekranını ve dışarıdan görülen güncel DS cevabını yetkili yöneticiye kontrol ettirin.
İmza ve önbellek sırası önemlidir
DNSSEC geçiş belgesi, eski referansın önbellekte kalabileceğini ve yeni nameserver geçişinin buna göre planlanması gerektiğini anlatır. Geçişi tamamlamak için tüm güvenlik ayarlarını aynı anda kapatmayın. Hangi sağlayıcının hangi adımı yaptığı yazılı olsun. İmzanın kaldırılması, DS değişimi ve nameserver güncellemesi birbirinin yerine geçen düğmeler değildir; uzmanınız desteklenen sırayı izlemelidir.
Bir ağın çalışması yeterli sonuç değildir
Bir çözümleyici cevap verirken diğeri SERVFAIL döndürebilir. Test raporunda sorgulanan alan adı, kayıt türü, kullanılan çözümleyici ve zaman yer alsın. DNS ve uygulama ayrımı rehberi hata katmanını sınırlandırır. IP'ye doğrudan bağlanıp siteyi görmek alan adının güven zincirini test etmez. Aynı şekilde SSL uyarısını atlayarak açılan bir sayfayı başarılı geçiş saymayın.
Web dışında kalan hizmetleri de kontrol edin
DNSSEC yalnız bir web sayfasının adresi için düşünülmemelidir. MX ve e-posta geçiş kontrollerini yapın; posta kayıtlarının yeni bölgede eksiksiz olduğunu görün. Düzelme sonrası HTTPS sertifikasını doğru alan adıyla yeniden doğrulayın. Geri dönüş kararı gerekiyorsa eski DNS bölgesinin hâlâ güncel olduğundan emin olun. Birbirinden kopuk panellerde aceleyle ters işlem yapmak yerine tek sorumluyla kayıtlı bir değişiklik planı uygulayın.
Bu konunun diğer kontrolleri
- DNSSEC'te DS ve DNSKEY Nedir? Güven Zincirini Açmadan Önce Kontrol Edin
- SERVFAIL DNSSEC Kaynaklı mı? Doğrulamalı ve Doğrulamasız Sorguyu Karşılaştırma
Sıkça Sorulan Sorular
Nameserver doğruysa DNSSEC sorunu olamaz mı?
Olabilir. Nameserver yetkilendirmesi ile üst bölgedeki DS referansı ayrı kontrol edilir. Eski DS yeni sağlayıcının anahtarıyla uyuşmuyorsa doğrulama başarısız olabilir. Güncel kayıtları birlikte inceletin.
Her geçişte DNSSEC'i kapatmak şart mı?
Bütün ortamlar için tek yöntem yoktur. Koordineli çoklu imzalayıcı gibi yöntemler uzman planlaması gerektirir. Sağlayıcılarınızın desteklediği yöntemi kullanın; eski DS kaydını yeni anahtarla uyumluymuş gibi bırakmayın.
DS'yi kaldırınca sorun anında biter mi?
Önbelleğe alınmış üst bölge kayıtlarının yaşam süresi etkili olabilir. Her kullanıcı için anlık düzelme sözü verilmez. Kaldırmanın doğru yerde yapıldığını ve eski yanıtın hangi çözümleyicide kaldığını kontrol edin.
Yeni sağlayıcıda DNSSEC'i tekrar ne zaman açmalıyım?
Yeni nameserver ve kayıtların doğru çalıştığı doğrulandıktan sonra iki sağlayıcının desteklediği geçiş planını takip edin. Yeni DS değerlerini hangi kayıt kuruluşunun yayınlayacağı belirli olmalıdır. Bir önceki DS'nin kaldırılma veya değişim durumunu bilmeden yeni düğmeleri rastgele açmayın. Doğrulama yapan çözümleyicilerde test edin ve işlemin sonucunu alan adı yönetim notuna ekleyin.