Nameserver yerine tek tek DNS kaydı taşımak ne zaman daha güvenlidir?

Alan adını yeni bir altyapıya taşırken en hızlı görünen yöntem çoğu zaman nameserver değiştirmektir. Ancak her taşıma senaryosunda en güvenli seçenek bu değildir. Özellikle e-posta, alt alan adları, doğrulama kayıtları, mobil uygulama API uçları veya üçüncü taraf servisler aynı alan adına bağlıysa, DNS kayıtlarını tek tek taşımak kesinti riskini daha kontrollü yönetmenizi sağlar.

Nameserver değişikliği neden riskli olabilir?

Nameserver değişikliği, alan adının DNS yönetim yetkisini tamamen başka bir sağlayıcıya devretmek anlamına gelir. Yeni tarafta eksik kalan bir MX, TXT, CNAME ya da A kaydı; web sitesinden çok daha fazlasını etkileyebilir. E-posta teslimi durabilir, SSL doğrulaması başarısız olabilir, ödeme sistemi alan adı kontrolünü kaybedebilir veya Android uygulamanızın kullandığı API adresi yanıt vermeyebilir.

Bu nedenle kritik sistemlerde “önce tüm kontrolü devret, sonra eksikleri düzelt” yaklaşımı yerine, kayıtları doğrulayarak ilerlemek daha güvenlidir. Hosting değişikliği sırasında DNS’i tek tek taşımak, özellikle birden fazla servisin aynı alan adına bağlı olduğu yapılarda daha öngörülebilir bir geçiş sunar.

Tek tek DNS kaydı taşımak hangi durumlarda daha güvenlidir?

E-posta trafiği kesintiye uğramamalıysa

Kurumsal e-posta kullanılan alan adlarında MX kayıtları, SPF, DKIM ve DMARC gibi TXT kayıtları kritik öneme sahiptir. Nameserver değiştiğinde bu kayıtların biri bile eksikse gönderilen e-postalar spam klasörüne düşebilir veya tamamen reddedilebilir. Tek tek taşıma yönteminde önce mevcut DNS bölgesi incelenir, e-posta kayıtları birebir aktarılır ve doğrulandıktan sonra web trafiği yönlendirilir.

Birden fazla alt alan adı aktif kullanılıyorsa

sunucu, panel, api, cdn, mail, shop veya app gibi alt alan adları farklı servisleri işaret ediyor olabilir. Nameserver değişiminde bu kayıtların unutulması, yalnızca ana siteyi değil operasyonel araçları da etkiler. Tek tek kayıt taşıma, hangi alt alan adının hangi servise bağlı olduğunu görerek ilerlemenizi sağlar.

Üçüncü taraf doğrulama kayıtları varsa

Google Workspace, Microsoft 365, ödeme altyapıları, reklam platformları, CDN servisleri ve güvenlik araçları çoğu zaman TXT veya CNAME doğrulaması kullanır. Bu kayıtlar kaybolursa servis çalışmaya devam etse bile yönetim panelinde doğrulama hataları görülebilir. Yeni DNS alanında tüm doğrulama kayıtlarını önceden oluşturmak, sonradan yaşanacak erişim ve yetkilendirme sorunlarını azaltır.

TTL değerleri yüksekse

TTL, DNS bilgisinin istemciler ve ara sunucular tarafından ne kadar süre önbellekte tutulacağını belirler. Eski nameserver kayıtlarında TTL değeri yüksekse, yapılan değişikliklerin bazı kullanıcılara geç yansıması normaldir. Tek tek DNS taşıma yaparken kritik kayıtların TTL değerleri önceden düşürülebilir. Böylece yönlendirme gerektiğinde daha kısa sürede yayılır.

Bu yöntem nasıl planlanmalı?

İlk adım mevcut DNS kayıtlarının eksiksiz envanterini çıkarmaktır. Sadece görünen A kaydına bakmak yeterli değildir; MX, TXT, CNAME, AAAA, SRV ve gerekiyorsa CAA kayıtları da kontrol edilmelidir. Kayıtların hangi servis için kullanıldığı not alınmalı, gereksiz görünen bir kayıt silinmeden önce mutlaka doğrulanmalıdır.

İkinci adım, yeni DNS sağlayıcısında aynı kayıtları oluşturmaktır. Bu aşamada değerlerin sonundaki nokta işareti, tırnak kullanımı, öncelik değeri ve alt alan adı yazımı gibi küçük görünen detaylar önemlidir. Örneğin “mail” ile “mail.alanadi.com” bazı panellerde farklı yorumlanabilir.

Üçüncü adım testtir. Web sitesi yeni IP adresine yönlendirilmeden önce geçici kontrol yapılmalı, SSL sertifikası durumu incelenmeli ve e-posta gönderim-alım testleri gerçekleştirilmelidir. Özellikle yeni hosting ortamında site dosyaları hazır olsa bile veritabanı bağlantısı, yönlendirme kuralları ve uygulama yapılandırmaları kontrol edilmeden trafik taşınmamalıdır.

Nameserver değiştirmek ne zaman daha mantıklıdır?

Alan adı üzerinde yalnızca basit bir web sitesi çalışıyorsa, e-posta farklı bir alan adında yönetiliyorsa ve özel doğrulama kayıtları yoksa nameserver değişikliği daha pratik olabilir. Ayrıca DNS yönetimini tek bir panelde toplamak isteyen ekipler için de operasyonel kolaylık sağlar. Ancak bu karar, mevcut kayıtlar görülmeden verilmemelidir.

Yeni sağlayıcının DNS yönetimi daha güvenilir, hızlı ve kurumsal özelliklere sahipse nameserver geçişi uzun vadede doğru tercih olabilir. Yine de geçişten önce eski bölgedeki tüm kayıtların dışa aktarılması, ekran görüntüsü alınması veya yazılı envanter oluşturulması gerekir.

Sık yapılan hatalar ve hızlı kontrol listesi

DNS geçişlerinde en yaygın hata, yalnızca web sitesinin açılıp açılmadığına bakarak taşımanın tamamlandığını düşünmektir. Oysa e-posta, API, CDN, SSL ve doğrulama kayıtları ayrı ayrı kontrol edilmelidir.

• Mevcut DNS kayıtlarının tam listesini alın.
• MX, SPF, DKIM ve DMARC kayıtlarını özellikle doğrulayın.
• Alt alan adlarını tek tek servisleriyle eşleştirin.
• Taşıma öncesinde kritik kayıtların TTL değerini düşürün.
• Yeni ortamda web, e-posta ve API testlerini ayrı ayrı yapın.
• Eski DNS bölgesini hemen silmeyin; birkaç gün referans olarak saklayın.

Kesinti toleransı düşük projelerde DNS taşıma işlemi küçük, doğrulanabilir adımlarla yürütülmelidir. Nameserver değişimi tüm yetkiyi bir anda devrederken, kayıt bazlı taşıma her servisi ayrı ayrı kontrol etme imkânı verir. Bu yaklaşım özellikle kurumsal web siteleri, e-posta bağımlılığı yüksek işletmeler ve mobil uygulama servisleri bulunan yapılarda daha güvenli bir çalışma düzeni sağlar.