Kısa cevap: Siteyi başka bir hosting'e taşımak iki ayrı işten biri olabilir: isim sunucularını (NS) değiştirip DNS yönetimini komple yeni sağlayıcıya devretmek, ya da yalnızca A ve AAAA kaydını yeni sunucuya çevirip DNS yönetimini olduğu yerde bırakmak. Kesintilerin büyük kısmı birinciyi yapıp ikincisini kastetmekten çıkar: isim sunucuları değişince kayıtlar artık yeni bölgeden okunur, eski bölgede kalan MX satırları devre dışı kalır ve e-posta durur. Doğru sıra şudur: site yeni sunucuda çalışır hâle gelsin, eski bölgedeki bütün kayıtlar birebir kopyalansın, TTL düşürülsün, en son NS değiştirilsin.
Taşımak istediğiniz şey tam olarak nedir
Bir alan adının arkasında birbirine karışan üç ayrı yer vardır. Alan adının kaydı bir kayıt kuruluşunda durur. Kayıtların kendisi, kök bölgedeki NS satırlarının işaret ettiği isim sunucularında tutulur. Site dosyaları ve veritabanı ise bir web sunucusunda, yani hosting'de yaşar. Günlük konuşmada “hosting taşıyorum” dediğinizde değiştirmek istediğiniz genelde yalnızca üçüncüsüdür.
Bu ayrımı görmek işin yarısıdır, çünkü üçü farklı yerden yönetilir ve biri değişirken diğerine dokunmak zorunda değilsiniz. Kayıtların nerede yönetildiğini bilmiyorsanız başlangıç noktası kök bölgedeki NS satırlarına bakmaktır; hangi kaydın ne işe yaradığını DNS kayıt türleri yazısında tek tek ele alıyoruz.
İkinci karışma noktası da şudur: hosting taşımak, alan adını başka bir kayıt kuruluşuna transfer etmekle aynı şey değildir. Transfer alan adının kaydının tutulduğu şirketi değiştirir ve kendi kuralları vardır; onu EPP kodu ve transfer kuralları yazısında ayrıca anlatıyoruz. Bu yazının konusu sitenin hangi sunucudan servis edildiğini değiştirmek.
NS değişikliği mi, A kaydı değişikliği mi
İki yol da sonunda ziyaretçiyi yeni sunucuya götürür, ama taşınması gereken satır sayısı ve riske giren hizmetler tamamen farklıdır. Aşağıdaki tablo kararı verirken bakılacak yerleri topluyor.
| Konu | İsim sunucusu (NS) değişikliği | Yalnızca A / AAAA değişikliği |
|---|---|---|
| Ne değişir | DNS yönetimi komple yeni sağlayıcıya geçer | Yalnızca sitenin hangi sunucuda olduğu |
| Ne taşınmak zorunda | Bölgedeki BÜTÜN satırlar: A, AAAA, CNAME, MX, TXT, SRV, CAA | Yalnızca A ve varsa AAAA satırı |
| Riske giren | Kopyalanmayan her satır: e-posta, doğrulama kayıtları, alt adlar | Yalnızca web; e-posta yerinde kalır |
| Yayılmayı belirleyen | Kök bölgedeki NS kaydının TTL değeri | Değiştirdiğiniz kaydın kendi TTL değeri |
| E-postaya etkisi | MX ve e-posta TXT kayıtları kopyalanmadıysa teslim anında durur | Yok; MX satırına hiç dokunulmaz |
| Geri dönüş | NS satırlarını geri almak gerekir, bu da yeni bir yayılma süresi demektir | Tek satırı eski değere döndürmek yeterli |
| Ne zaman seçilir | DNS yönetimini de yeni sağlayıcıya ya da bir CDN hizmetine devredecekseniz | Yalnızca sunucu değiştiriyorsanız; varsayılan tercih bu olmalı |
Tabloyu tek cümleye indirmek gerekirse: NS değişikliği bölgedeki her satırı, A kaydı değişikliği ise bir iki satırı ilgilendirir. Daha az satır daha az risk demektir, bu yüzden DNS yönetimini taşımak için ayrı bir sebebiniz yoksa yalnızca A ve AAAA kaydını çevirmek daha güvenli yoldur.
Adım adım: kesinti üretmeyen taşıma sırası
Sıra bu yazının en önemli kısmıdır. Adımların yeri değişirse taşıma teknik olarak gerçekleşir ama arada bir kesinti ya da veri kaybı penceresi açılır.
- Siteyi yeni sunucuda çalışır hâle getirin ve alan adı olmadan test edin. Dosyaları ve veritabanını kopyalayın, sonra sitenin yeni sunucudaki geçici adresi ya da yerel bir ad eşlemesi üzerinden her sayfayı açın. Ana sayfanın açılması yetmez; form gönderimi, giriş ekranı ve yönetim paneli de denenir.
- SSL sertifikasını yeni sunucuda baştan kurun. Sertifika sunucuya bağlıdır, alan adına değil; eski sunucudaki sertifika yenisinde kendiliğinden belirmez. Bu adım atlanırsa geçişten sonra ziyaretçi doğrudan tarayıcı uyarı ekranıyla karşılaşır. Ayrıntı için SSL kurulumu yazısına bakın.
- Eski bölgenin tam dökümünü alın. Mevcut panelde ne kadar kayıt varsa hepsini satır satır kaydedin. Burada en çok gözden kaçan satırlar MX kayıtları, SPF ve DKIM gibi e-posta TXT kayıtları, mülk doğrulama dizgileri ve yıllar önce bir hizmet için açılmış alt adlardır.
- Yazma işlemlerini durdurun ya da eski siteyi salt okunur yapın. Geçiş penceresinde bir süre iki sunucu da yayında olur: kimi ziyaretçi eski, kimi yeni cevabı görür. Veritabanlı bir sitede bu, form gönderimlerinin ve siparişlerin iki ayrı veritabanına düşmesi anlamına gelir. Bakım kipi ya da salt okunur mod, sonradan iki veritabanını elle birleştirmekten çok daha kolaydır.
- Kayıtları yeni bölgeye birebir kopyalayın. Bu adım yalnızca NS değiştirecekseniz geçerlidir. Yeni sağlayıcının bölgesini açıp eski dökümdeki her satırı aynı ad, aynı tür, aynı değer ve aynı öncelikle girin. Kopyalama bitmeden NS satırlarına dokunmayın.
- TTL değerlerini düşürün ve eski TTL kadar bekleyin. Değiştireceğiniz kayıtların TTL değerini 300 saniyeye indirin. Çözümleyiciler eski cevabı eski TTL süresi boyunca önbellekte tutacağı için bu bekleme gerçekten gereklidir; atlanırsa geçiş saatlerce yarım kalır.
- Değişikliği yapın. Yalnızca sunucu değiştiriyorsanız A ve AAAA satırlarını yeni adrese çevirin. DNS yönetimini taşıyorsanız kayıt kuruluşu panelinde NS satırlarını yeni isim sunucularıyla değiştirin. İkisini aynı gün içinde birbirine karıştırmayın.
- Doğrulayın ve eski hostingi hemen kapatmayın. Siteyi kendi cihazınızdan değil, bağımsız bir sorgulama aracından ve mobil veriden kontrol edin. E-posta için kendinize dışarıdan bir deneme iletisi gönderin. Eski sunucuyu, yayılmanın bittiğinden ve e-postanın aktığından emin olduktan sonra kapatın.
Birebir kopyalamak ne demek
Aşağıdaki örnekte alan adı ornekfirma.com ve parantez içindeki değerler YER TUTUCUDUR; kendi sağlayıcınızın verdiği adresleri yazmanız gerekir. Yapının kendisi gerçektir: taşımada değişen grup yalnızca en üstteki satırlardır, alttakiler aynı kalmak zorundadır.
; SITE, taşımada değişen satırlar @ 300 A (yeni sunucunun IPv4 adresi) @ 300 AAAA (yeni sunucunun IPv6 adresi) www 300 CNAME ornekfirma.com. ; E-POSTA, dokunulmaz ama NS değişiyorsa birebir kopyalanır @ 3600 MX 1 smtp.google.com. @ 3600 TXT "v=spf1 include:_spf.google.com ~all" google._domainkey 3600 TXT "v=DKIM1; k=rsa; p=(genel anahtar)" _dmarc 3600 TXT "v=DMARC1; p=none; rua=mailto:dmarc@ornekfirma.com" ; UNUTULMASI EN KOLAY SATIRLAR @ 3600 TXT "(mülk doğrulama dizgisi)" panel 3600 A (başka bir hizmetin IPv4 adresi) @ 3600 CAA 0 issue "letsencrypt.org"
Dikkat edin: TTL değeri yalnızca değiştirdiğimiz satırlarda düşürülmüş, e-posta satırlarına hiç dokunulmamış. İş bittikten sonra düşürülen TTL değerleri 3600 gibi makul bir değere geri yükseltilir; sürekli 300'de bırakmak gereksiz sorgu üretir.
Yaygın hatalar
- MX kayıtlarını kopyalamadan isim sunucusunu değiştirmek. NS değişir, kayıtlar yeni bölgeden okunmaya başlar ve o bölgede MX satırı yoksa gelen e-posta teslim edilemez. Bu, “site taşındı, mailler kayboldu” şikâyetinin birinci sebebidir.
- Eski hostingi geçişin ertesi günü kapatmak. Yayılma bitmemiş olabilir; kapatıldığı anda eski cevabı önbellekte tutan ziyaretçiler siteye hiç ulaşamaz. Üstelik eski sunucudaki e-posta kutuları ve son yedekler de gider.
- TTL değerini düşürmemek. Eski TTL bir günse, değişikliğin herkese ulaşması bir gün sürer. Bu sürenin tamamı boyunca kimi kullanıcı eski sunucuyu, kimi yenisini görür; veritabanlı bir sitede bu pencere doğrudan çift kayıt üretir.
- Yazma işlemlerini durdurmadan geçmek. İki sunucu da yayındayken gelen form gönderimleri ve siparişler ikiye bölünür. Hangisinin hangi veritabanına düştüğünü sonradan ayırmak, geçiş sırasında yarım saat bakım kipinde kalmaktan çok daha pahalıdır.
- SSL sertifikasını yeni sunucuda kurmadan geçiş yapmak. Alan adı yeni sunucuyu göstermeye başladığı anda ziyaretçi, geçerli sertifika bulunmadığı için tarayıcı uyarı ekranıyla karşılaşır. Sertifikayı taşımadan önce kurmak bu ekranı tamamen önler.
- E-posta kutularını taşımadan MX kaydını çevirmek. MX değişir, yeni iletiler yeni sunucuya düşer ama geçmiş yazışmalar eski kutularda kalır. Kutular önce kopyalanır, sonra MX çevrilir; sırası kurumsal e-posta kurulumu yazısında anlatılıyor.
- Yeni sunucuda yönlendirme kurallarını baştan yazmayı atlamak.
wwwtekilleştirmesi ve HTTPS yönlendirmesi sunucu yapılandırmasında durur; yeni sunucuya taşınmazsa aynı sayfa birden fazla adreste açılır. Bu konuyu www mi, www'suz mu yazısında ele alıyoruz.
Ne zaman uzmana bırakmalı
Tek sayfalık tanıtım sitesini yeni bir sunucuya almak çoğu zaman bir akşamlık iştir. Ama şu durumlarda bir hata doğrudan gelir kaybına döner: sitede sipariş ya da randevu alan bir veritabanı varsa, aynı alan adı üzerinde site ile birlikte kurumsal e-posta çalışıyorsa, ödeme sağlayıcısı veya muhasebe entegrasyonu belirli bir sunucu adresine bağlıysa, ya da bölgedeki kayıtların hangisinin hâlâ kullanıldığı bilinmiyorsa.
Bu işi biz web sitesi ve e-ticaret çalışmalarının bir parçası olarak yapıyoruz: taşıma öncesinde bölgenin dökümünü çıkarır, yeni sunucuyu alan adına dokunmadan hazırlar ve geçişi yazma işlemleri kapalıyken tamamlarız. Mevcut yapının genel fotoğrafını isterseniz teknik denetim sayfasına bakabilir ya da iletişim sayfasından yazabilirsiniz.
Devamını okumak için
Kayıt türlerinin tamamı ve örnek bir bölge için DNS kayıt türleri yazısına bakın. Alan adını başka bir kayıt kuruluşuna almak istiyorsanız EPP kodu ve transfer kuralları, adresleri tekilleştirmek için www mi, www'suz mu, taşıma sırasında protokolü de değiştirecekseniz HTTP'den HTTPS'e taşınma yazısı sırayı anlatıyor. Tüm başlıklar blog sayfamızda, çalışma alanlarımız ana sayfamızda.