Web Sitesi Taşırken DNS Geçiş Planı Nasıl Yapılır?

Web sitesi taşıma, DNS değişikliği gerektiren en yaygın operasyonlar arasındadır. Ama DNS'in bu süreçteki rolü çoğunlukla ya göz ardı edilir ya da son dakikaya bırakılır. Oysa taşıma öncesinde DNS hazırlığı yapılmamışsa, yeni sunucu hazır olsa bile ziyaretçilerin bir kısmı saatlerce eski sunucuya ulaşmaya devam eder — ve bu süre zarfında oluşan tutarsızlık hem kullanıcı deneyimini hem de SSL sertifikasını olumsuz etkileyebilir.

DNS geçişinin iki temel yolu vardır: yalnızca A kaydını değiştirmek ya da nameserver'ları değiştirmek. Bu seçim, geçişin ne kadar hızlı tamamlanacağını, ne kadar kontrol imkânı sağladığını ve SSL sertifikasının nasıl davranacağını doğrudan belirler. Her iki yolun da farklı bir kullanım senaryosu vardır ve ikisini karıştırmak geçişi gereksiz ölçüde karmaşıklaştırır.

Nameserver değişikliği mi, A kaydı değişikliği mi?

Nameserver değişikliğinde domain'in tüm DNS yönetimi yeni sağlayıcıya devredilir. Eski sağlayıcıdaki tüm kayıtlar geçersiz hale gelir; yeni sağlayıcıda sıfırdan zone kurulması gerekir. Nameserver değişikliği genellikle 24-48 saat içinde yayılır; bu süre zarfında bazı sorgular eski nameserver'a, bazıları yenisine gidebilir.

Yalnızca A kaydı değişikliğinde ise nameserver'lar aynı sağlayıcıda kalır; yalnızca web sunucusunun IP adresi güncellenir. Bu yaklaşım daha hızlı yayılır çünkü TTL değerine bağlıdır — çoğunlukla birkaç dakika ile birkaç saat arasında. Ayrıca geri alma işlemi de hızlıdır: eski IP'yi geri yazmak yeterlidir.

; Yaklaşım 1 — Yalnızca A kaydı değişikliği:
; Nameserver aynı kalır, sadece IP güncellenir
sirket.com.  300  IN  A  203.0.113.10   ; yeni sunucu IP

; Yaklaşım 2 — Nameserver değişikliği:
; Registrar panelinde:
; NS1: ns1.eskisaglayici.com → ns1.yenisaglayici.com
; NS2: ns2.eskisaglayici.com → ns2.yenisaglayici.com
; Yeni sağlayıcıda tüm kayıtlar yeniden oluşturulur

Pratik kural şudur: yalnızca hosting sağlayıcısı değişiyorsa — domain registrar'ı ve DNS sağlayıcısı aynı kalıyorsa — A kaydı değişikliği yeterlidir. DNS sağlayıcısı da değişiyorsa (örneğin Cloudflare'e geçiş yapılıyorsa) nameserver değişikliği gerekir. Bu iki işlemi eş zamanlı yapmak propagasyon süreçlerini iç içe geçirir ve sorun gidermeyi zorlaştırır; mümkünse ayrı ayrı yapın.

TTL planlaması: geçiş öncesi hazırlık penceresi

Hangi yaklaşım seçilirse seçilsin, DNS kaydını değiştirmeden önce TTL değerini düşürmek standart prosedürdür. Yüksek TTL'li bir kayıt değiştirildiğinde, önbellekteki eski değer TTL süresi dolana kadar geçerliliğini korur. 86400 saniyelik (24 saatlik) TTL ile yapılan acil bir geçişte eski sunucuya trafik akmaya devam edebilir.

Geçişten 48 saat önce TTL'i 300 saniyeye düşürün. Düşürme işleminin yayılması için mevcut TTL kadar bekleyin. Mevcut TTL 3600 saniyeyse düşürme işleminden sonra en az 1 saat beklemeniz gerekir; 86400 saniyeyse 24 saat. Bu bekleme süresi sonunda önbelleklerin büyük çoğunluğu yeni (düşük) TTL ile çalışıyor olacak ve A kaydını değiştirdiğinizde değişiklik hızla yayılacaktır.

; 1. Mevcut durum (geçiş öncesi):
sirket.com.  86400  IN  A  93.184.216.34   ; eski sunucu

; 2. TTL düşürme (geçişten 48 saat önce):
sirket.com.  300    IN  A  93.184.216.34   ; eski sunucu, düşük TTL

; 3. Propagasyon bekleme (mevcut TTL kadar: 86400 sn = 24 saat)

; 4. A kaydı geçişi:
sirket.com.  300    IN  A  203.0.113.10    ; yeni sunucu

; 5. Geçiş stabil olduktan sonra TTL yükseltme:
sirket.com.  3600   IN  A  203.0.113.10   ; yeni sunucu, normal TTL

Nameserver değişikliğinde TTL planlaması farklı çalışır. Nameserver TTL'i (NS kaydı üzerindeki değer) registrar düzeyinde kontrol edilir ve çoğunlukla değiştirilemez. Bu nedenle nameserver geçişlerinde propagasyon süresi daha az kontrol edilebilirdir; çoğunlukla 24-48 saat olarak kabul edilir ama bazen daha kısa, bazen daha uzun sürebilir.

Geçiş penceresinde eski ve yeni sunucunun eş zamanlı çalışması

A kaydı değiştirildiğinde tüm trafik anında yeni sunucuya geçmez. TTL 300 saniyeye düşürülmüş olsa bile bazı önbellekler değişikliği biraz geç alır. Bu geçiş penceresinde — çoğunlukla 10-30 dakika — bazı kullanıcılar eski sunucuya, bazıları yeni sunucuya yönlendirilir.

Bu durum iki gereksinim doğurur. Birincisi, yeni sunucu A kaydı değişmeden önce hazır ve erişilebilir olmalıdır. İkincisi, geçiş penceresi boyunca eski sunucu da çalışmaya devam etmelidir. Eski sunucuyu A kaydı değişikliğiyle eş zamanlı kapatmak, değişikliği henüz almamış kullanıcıların 404 ya da bağlantı hatası almasına neden olur.

Geçiş penceresinin uzunluğunu izlemek için farklı DNS sunucularından periyodik sorgular yapmak yeterlidir. Tüm sorgular yeni IP'yi döndürmeye başladığında geçiş tamamlanmış demektir.

# Geçiş sırasında periyodik kontrol:
$ for ns in 8.8.8.8 1.1.1.1 9.9.9.9; do
    echo -n "$ns: "
    dig @$ns sirket.com A +short
  done

8.8.8.8: 203.0.113.10    # yeni sunucu ✓
1.1.1.1: 93.184.216.34   # hâlâ eski sunucu — bekle
9.9.9.9: 203.0.113.10    # yeni sunucu ✓

# Birkaç dakika sonra tekrar:
8.8.8.8: 203.0.113.10    # yeni sunucu ✓
1.1.1.1: 203.0.113.10    # yeni sunucu ✓
9.9.9.9: 203.0.113.10    # yeni sunucu ✓
# Geçiş tamamlandı

SSL sertifikası ve DNS geçişinin kesişimi

SSL sertifikası geçiş planlamasını doğrudan etkiler. Let's Encrypt gibi ücretsiz sertifika sağlayıcıları, sertifika verme ve yenileme sürecinde domain doğrulaması yapar. Bu doğrulamanın en yaygın yöntemi olan HTTP-01 challenge, doğrulama sunucusunun domain'in A kaydının işaret ettiği IP'ye erişebilmesini gerektirir.

Pratikte bu şu anlama gelir: yeni sunucuda SSL sertifikası almak istiyorsanız, A kaydının yeni sunucuya işaret etmesi gerekir. Ama A kaydı değişmeden önce eski sunucu aktiftir ve sertifika doğrulaması eski sunucuya gidecektir. Bu döngüyü çözmenin en temiz yolu şudur: A kaydını değiştirmeden önce yeni sunucuda eski sunucunun geçici bir kopyasını çalıştırın, sertifikayı alın, ardından A kaydını değiştirin.

Alternatif olarak DNS-01 challenge kullanılabilir. Bu yöntemde sertifika sağlayıcısı, domain'in TXT kaydına belirli bir değer yazılmasını ister; web sunucusuna erişim gerekmez. DNS-01 challenge, A kaydı değişikliğinden bağımsız olarak sertifika almayı mümkün kılar. Wildcard sertifikalar yalnızca DNS-01 ile verilebilir.

Cloudflare kullanıyorsanız ve Proxied moduna geçiş yapıyorsanız, Cloudflare kendi sertifikasını otomatik olarak yönetir. Bu durumda origin sunucuyla Cloudflare arasındaki bağlantı için ayrı bir sertifika gerekir ve "Full (strict)" SSL modunda bu sertifikanın geçerli olması beklenir. DNS güvenliği açısından HTTPS zorunluluğu, geçiş penceresinde de korunmalı; HTTP'ye geçici düşüş kabul edilmemelidir.

Geçiş sonrası DNS doğrulama adımları

A kaydı geçişi tamamlandıktan sonra yalnızca web sitesinin açılıp açılmadığını kontrol etmek yeterli değildir. DNS katmanında birkaç doğrulama adımı daha vardır.

İlk kontrol, A kaydının doğru IP'yi döndürdüğünü birden fazla DNS çözümleyicisi üzerinden teyit etmektir. İkinci kontrol, www alt domain'inin de doğru IP'ye çözümlendiğidir — hem sirket.com hem de www.sirket.com aynı ya da doğru sunucuya işaret etmelidir. Üçüncü kontrol SSL sertifikasının geçerliliğidir: tarayıcı adres çubuğundaki kilit simgesi ve sertifika detayları yeni sunucu için doğru düzenlenmiş olmalıdır. Nameserver değişikliği yaptıysanız, domain kayıt bilgilerini ve aktif nameserver'ları domain sorgulama aracıyla teyit etmek de geçişin tamamlandığını doğrulamak için hızlı bir yoldur.

# A kaydı kontrolü:
$ dig sirket.com A +short
203.0.113.10   ; yeni sunucu IP ✓

# www alt domain:
$ dig www.sirket.com A +short
203.0.113.10   ; veya CNAME → sirket.com ✓

# SSL sertifikası kontrolü:
$ curl -I https://sirket.com 2>/dev/null | grep -E "HTTP|Server"
HTTP/2 200
Server: nginx/1.24.0

# Eski IP'ye erişilebilirlik testi (opsiyonel):
$ curl -H "Host: sirket.com" http://93.184.216.34/ -o /dev/null -w "%{http_code}"
200   # eski sunucu hâlâ çalışıyorsa — henüz kapatmayın

Tüm doğrulamalar olumlu çıktıktan sonra eski sunucu kapatılabilir. Ancak aceleye gerek yoktur: eski sunucuyu geçiş sonrası 24-48 saat daha açık tutmak, önbellekte kalan eski IP'ye gelen kullanıcıların hata almak yerine içeriğe ulaşmasını sağlar. Bu süre zarfında eski sunucu üzerindeki form verileri, dosya yüklemeleri ya da dinamik içerikler yeni sunucuyla senkronize değilse bazı tutarsızlıklar yaşanabilir. Statik siteler için bu ek süre gereksizdir; dinamik içerikli siteler için değerlidir.

DNS geçişi, web sitesi taşımanın en az görünür ama en kritik aşamasıdır. A kaydı değiştirmek tek satırlık bir işlemdir; ama bu işlemin öncesinde TTL hazırlığı, yeni sunucu testi ve SSL planlaması yapılmamışsa geçiş sürecinde kontrol kaybı yaşanır. Sorun çıktığında DNS katmanını doğrulamak ile sunucu katmanını doğrulamak farklı araçlar gerektirir; bu iki katmanı ayırt etmek hem geçiş planlamasını hem de olası sorunların teşhisini önemli ölçüde kolaylaştırır.