Domain ve DNS Bilgi Rehberi
Yerel depodan kıyı deposuna kasa taşıyan ekip, posta çantaları en sonda

Türk Hosting Şirketleri Arasında Geçişte DNS Süreci

Yerli bir hosting şirketinden Hetzner veya DigitalOcean gibi uluslararası bir sağlayıcıya geçiş, teknik açıdan pek çok adımı içerir. Sunucu tarafı genellikle daha kolay tamamlanır: dosyaları kopyalarsınız, veritabanını alırsınız, yeni ortamı test edersiniz. Asıl karmaşıklık DNS tarafında yaşanır. Hangi kayıtların nereye işaret ettiğini bilmeden nameserver değiştirirseniz e-posta trafiği kesilir, bazı sayfalar erişilemez hale gelir ve müşteri şikayetleri başlar.

Geçişte DNS'in üç temel sorunu vardır: propagasyon süresi önceden tahmin edilemez, eski nameserver'dan yeni nameserver'a geçiş sırasında bir ara dönem yaşanır ve bu süreçte farklı kullanıcılar farklı sunuculara ulaşır. Bunu baştan kabul edip planlarsanız kesinti kaçınılmaz olmaktan çıkar. Planlamazsanız, birkaç saatlik teknik sorunun aylarca süren itibar kaybına dönüştüğünü görebilirsiniz.

Aşağıdaki adımlar bu geçişi mümkün olan en az kesintili biçimde yönetmenizi sağlar. Sırası önemlidir.

Geçiş Öncesi Envanter: Hangi DNS Kayıtlarını Taşıyorsunuz?

Geçişe başlamadan önce mevcut DNS zone'unuzda ne olduğunu eksiksiz bilmeniz gerekir. Birçok yerli hosting şirketi yönetim panelinde DNS kayıtlarını toplu görmeyi zorlaştırır; cPanel veya Plesk tabanlı sistemlerde tek tek kayıt türlerine bakmanız gerekebilir. Şu kayıt türlerini listeleyin: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC dahil), NS, SRV ve varsa CAA.

Bu envanterin en kritik bölümü MX kayıtlarıdır. Bazı yerli hosting şirketleri kendi sunucularında e-posta barındırır; bazıları ise Google Workspace, Microsoft 365 veya Zoho Mail gibi dış servislere yönlendirir. Hangi senaryoda olduğunuzu bilmeden nameserver değişikliği yapmak e-posta kesintisinin kapısını aralar. MX kaydınız mevcut hosting şirketinin IP'sini gösteriyorsa bu adresi hedef sağlayıcıdaki yeni sunucu adresiyle değiştirmeniz gerekecek. Eğer MX'iniz Google veya Microsoft gibi üçüncü bir servise işaret ediyorsa bu kaydı yeni panelde aynen kopyalamanız yeterlidir; Workspace listesi Google Workspace DNS yazısında durur.

TXT kayıtları da göz ardı edilmez. Mevcut SPF kaydınız eski hosting şirketinin include değerini taşıyorsa, yeni sağlayıcıya geçtiğinizde bu değeri güncellemeniz gerekecek. DKIM selector'ları panel üzerinden alınamıyorsa, e-posta servis sağlayıcınızdan doğrudan istemeniz gerekir. Zoho Mail DNS kurulumunu anlatan yazıda bu tür kayıtların nasıl alındığına dair adımları inceleyebilirsiniz.

TTL Değerini Düşürmek: Ne Zaman, Kaça?

TTL (Time to Live) değeri, bir DNS kaydının resolver'lar tarafından ne kadar süre önbellekte tutulacağını belirler. Çoğu yerli hosting şirketi varsayılan olarak 3600 saniye (1 saat) veya daha yüksek bir TTL kullanır; bazılarında 86400 (24 saat) görmek mümkündür.

Geçiş tarihinden 24-48 saat önce tüm kritik kayıtların TTL'ini 300 saniyeye (5 dakika) indirin. Bu değişikliğin etkisi hemen başlamaz: mevcut TTL süresi dolmadan önce eski değer önbellekte kalmaya devam eder. Yani 24 saatlik TTL'i 300'e çektiğinizde, tam etkisini ancak 24 saat sonra görürsünüz. Erken başlamak bu yüzden zorunludur.

TTL'i düşürmek her senaryoda yararlı değildir. Değişiklik planlamayan, yüksek trafikli ve CDN katmanlı siteler için gereksiz yere resolver yükü artışına neden olabilir. Geçiş söz konusu olduğunda ise propagasyon süresini kısaltmanın tek pratik yoludur.

TTL Kontrol Listesi (Geçişten 48 Saat Önce)

Yeni Nameserver'da Zone Hazırlamak

Nameserver'ı değiştirmeden önce yeni panelde zone'u eksiksiz hazırlayın. Hetzner DNS Console ve DigitalOcean DNS, zone dosyasını BIND formatında içe aktarmayı destekler. Eski hosting şirketinizden zone export alabiliyorsanız bu yolu tercih edin; alınamıyorsa kayıtları tek tek girin.

Zone hazırlarken dikkat edilmesi gereken birkaç nokta var. Eski nameserver'ın otomatik eklediği varsayılan SOA ve NS kayıtlarını yeni panele taşımaya çalışmayın; yeni sağlayıcı bunları kendisi oluşturur. Wildcard kayıtlar (*.domain.com) varsa bunları bilinçli olarak ekleyin ya da dışarıda bırakın. Eski hosting şirketlerinin zamanla biriktirdiği kullanılmayan subdomain kayıtlarını temizlemek için bu iyi bir fırsattır.

Yeni zone hazır olduğunda, nameserver değişikliği yapmadan önce kayıtların doğruluğunu teyit edin. dig aracıyla yeni nameserver'ı doğrudan sorgulayarak beklenen değerlerin dönüp dönmediğini kontrol edebilirsiniz.

dig @ns1.your-new-provider.com example.com A
dig @ns1.your-new-provider.com example.com MX
dig @ns1.your-new-provider.com example.com TXT

Kendi nameserver'ınızı işletmeyi düşünüyorsanız, glue kaydı ve reverse delegation yapılandırması da devreye girer. CyberPanel'de özel nameserver kurulumu bu yapılandırmanın teknik adımlarını açıklar.

Nameserver Değişimini Yapmak

Zone hazırsa ve TTL'ler düşüktür, geçiş zamanı gelmiştir. Domain registrar panelinize girin ve nameserver kayıtlarını yeni sağlayıcının NS adreslerine güncelleyin. Bu değişikliğin TLD nameserver'larına yansıması birkaç dakika ile 48 saat arasında sürer; çoğu durumda 4-12 saat içinde tamamlanır.

Geçiş zamanlaması önemlidir. Sabahın erken saatlerini veya mesai başlangıcını tercih edin; sorun çıktığında müdahale edebilmek için gün içinde yeterli zaman olması gerekir. Cuma öğleden sonra veya uzun hafta sonu tatillerinin arifesinde geçiş yapmak, sizi gece yarısı kriz yönetimiyle baş başa bırakabilir.

Nameserver değiştirilir değiştirilmez beklemeniz gerekir. Değişikliği zorlayacak bir kısayol yoktur; propagasyon internet altyapısının normal işleyişidir. Propagasyonu izlemek için dnschecker.org gibi araçlar farklı coğrafi konumlardan sorgu sonuçlarını gösterir; hangi bölgelerin yeni NS'e geçtiğini anlık olarak takip edebilirsiniz.

E-posta Kesintisini Önleme: MX, SPF ve DKIM

E-posta, DNS geçişlerinde en sık kesintiye uğrayan servistir. Bunun nedeni MX kayıtlarının önbellekte kaldığı süre ile yeni sunucunun kullanıma hazır olup olmadığı arasındaki zamanlama farkıdır.

Eski sunucuyu hemen kapatmayın. Geçiş sırasında MX kayıtlarınıza hem eski hem yeni sunucuyu öncelik farkıyla ekleyebilirsiniz: yeni sunucuya öncelik 10, eski sunucuya öncelik 20 vererek propagasyon tamamlanana kadar eski sunucuyu yedek olarak aktif tutabilirsiniz. Bu yaklaşım eski hosting maliyetini bir süre daha uzatır; karar verirken bunu göz önünde bulundurun.

SPF kaydını güncellemeyi ertelemeyin. E-posta alan sunucular, gönderen IP'nin SPF kaydında yetkili olup olmadığını kontrol eder. Yeni hosting şirketinin IP aralığını SPF kaydına eklemeden e-posta göndermeye başlarsanız iletileriniz spam klasörüne düşebilir ya da reddedilebilir. DNS kaynaklı deliverability sorunları yazısında SPF, DKIM ve DMARC kayıtlarının geçiş sürecinde nasıl yönetilmesi gerektiğini bulabilirsiniz.

Microsoft 365 veya Google Workspace kullanıyorsanız bu servislerin MX ve SPF değerleri hosting sağlayıcısından bağımsızdır; nameserver değişikliğinden etkilenmezler. Yeni zone'a aynı değerleri kopyalamanız yeterlidir. Microsoft 365 için MX ve SPF kayıtları yazısı bu yapılandırmanın doğrulama adımlarını aktarır.

Propagasyon Süresinde Takip ve Geri Dönüş Planı

Nameserver değişikliği yapıldıktan sonra siteyi ve e-postayı aktif olarak izleyin. Basit bir uptime izleme aracı belirli aralıklarla HTTP isteği atarak sizi uyarır. E-posta için ise geçiş süresince hem eski hem yeni sunucuya test mesajı gönderin; her ikisi de iletileri teslim alıyorsa propagasyon henüz tamamlanmamış demektir.

Geri dönüş planı, panik anında net adımlar bilmektir. Eski hosting hesabını hemen kapatmayın; geçiş sonrası en az 72 saat, tercihen bir hafta boyunca eski sunucuyu aktif tutun. Ciddi bir sorunla karşılaşırsanız registrar üzerinden nameserver'ı tekrar eski değerlere alabilirsiniz. TTL'i 300'e çektiğiniz için bu geri dönüş de kısa sürede etkili olur.

Acil Geri Dönüş Adımları

  1. Registrar panelinde nameserver'ı eski değerlere alın.
  2. Eski nameserver'ın propagasyonunu bekleyin (TTL 300 saniyeyse resolver önbellekleri kısa sürede temizlenir).
  3. E-posta ve HTTP erişimini doğrulayın.
  4. Sorunun kaynağını tespit edip yeni zone'u düzeltin.
  5. Geçişi yeniden planlayın ve yukarıdaki adımları tekrarlayın.

Geçiş Sonrası Kontrol Listesi

Propagasyon tüm bölgelerde tamamlandıktan sonra yapılacaklar şunlardır:

Subdomain yönetimi daha karmaşık bir mimari gerektiriyorsa DigitalOcean DNS ile subdomain yönetimi yazısı bu konunun teknik ayrıntılarını sunar.

DNS geçişi en çok stresi belirsizlikten alır. Propagasyon süresi kesin değildir; bazı resolver'lar değişikliği birkaç dakikada yakalar, bazıları 24 saat bekler. Bununla birlikte TTL'i önceden düşürmüş, yeni zone'u hazırlamış ve geri dönüş planını belirlemiş bir ekip için bu bekleme süresi yönetilebilir hale gelir.

Türk hosting şirketlerinden uluslararası sağlayıcılara geçişin DNS tarafındaki en yaygın hatası aceleye gelmektir. Zone hazırlığı yapılmadan, TTL indirilmeden veya e-posta kayıtları gözden geçirilmeden yapılan nameserver değişiklikleri günlük trafiği keser ve teknik olmayan son kullanıcılar için ciddi sorunlar doğurur. Planlı bir geçiş ise çoğunlukla birkaç saat içinde, kullanıcıların fark etmediği bir süreç olarak tamamlanır.

Geçiş tamamlandıktan sonra da zone'unuzu düzenli aralıklarla gözden geçirin. Eski kayıtların temizlenmesi, TTL değerlerinin optimize edilmesi ve e-posta kayıtlarının güncel tutulması, uzun vadede sorunsuz bir altyapının temelidir. Domain yönetimini daha geniş bir çerçevede ele almak istiyorsanız domain portföyü yönetimi yazısı bu bakışı sağlar.

İlgili Yazılar