Alan adı taşıma kontrol listesi: DNS, e-posta, TLS ve yönlendirmeler

Hangi taşımayı yapıyorsunuz?

"Alan adı taşıma" başlığı altında birbirinden epeyce farklı projeler toplanır ve bunların her biri başka bir noktadan kırılır. DNS barındırmayı taşımak sorgulara kimin yanıt verdiğini değiştirir; kayıt kuruluşunu aktarmak delegasyonu kimin denetlediğini değiştirir; postayı taşımak MX kayıtlarının nereyi gösterdiğini değiştirir; yeniden adlandırma ise her URL'yi ve her e-posta adresini birden değiştirir. İşe koyulmadan önce bunlardan hangisini yaptığınızı açıkça belirleyin, çünkü her birinin kendine ait kritik bir adımı ve kendine ait bir geri dönüş yolu vardır.

1. adım: envanter

Mevcut DNS sağlayıcınızdan bölgenin tamamını, mümkünse doğrudan bir bölge dosyası biçiminde dışa aktarın. Birçok sağlayıcı otomatik olarak eklenmiş kayıtları arayüzünde göstermez; bu yüzden dışa aktardığınız listeyi mutlaka canlı sorgularla karşılaştırın. Kimsenin eklediğini hatırlamadığı kayıtlara ayrıca dikkat edin: bunlar çoğu zaman bir hizmetin sahiplik doğrulamasıdır ve kayıt ortadan kalktığında o hizmet hiçbir uyarı vermeden çalışmayı bırakır.

for name in example.com www.example.com _dmarc.example.com _mta-sts.example.com; do
  for type in A AAAA CNAME MX TXT CAA; do
    dig +noall +answer "$name" "$type"
  done
done

İşe başlamadan önce Alan Adı Sağlığı aracını çalıştırın ve çıkan sonucu bir yere kaydedin. Taşıma bittikten sonra aynı kontrol SPF, DMARC, MX, TLS, başlıklar ve yönlendirmeler için hızlı bir gerileme testi işini görür. İki çıktıyı yan yana koyduğunuzda hangi kaydın geride kaldığı ya da hangi ayarın yolda kaybolduğu bir bakışta ortaya çıkar.

2. adım: TTL değerlerini düşürün

Çözümleyiciler kayıtları TTL süresi boyunca önbellekte tutar. Bir kaydın TTL değeri bir günse ve siz o kaydı değiştirirseniz, bazı kullanıcılar eski değeri bir güne varan süre boyunca kullanmayı sürdürür. TTL değerlerini, değişiklikten en az bir eski TTL süresi önce 300 saniye civarına indirmek geçişin herkese dakikalar içinde ulaşması anlamına gelir; aynı hız, geri alma kararı vermeniz gereken durumda da geçerlidir.

Ad sunucusu değişikliği bu kuralın dışındadır: alan adınızın üst düzey alan bölgesinde tutulan NS kayıtlarının, kayıt otoritesi tarafından belirlenen ve çoğu zaman bir ya da iki gün olan kendi TTL değeri vardır ve bunu siz düşüremezsiniz. O yüzden bu süre boyunca hem eski hem de yeni ad sunucularının sorgu almasını baştan planlayın. Eski DNS sağlayıcısının bölgeyi bu süre tamamen geçene kadar sunmayı sürdürmesi gerekmesinin nedeni de tam olarak budur.

3. adım: DNS barındırmasını taşımak

1. Yeni sağlayıcıda bölgeyi oluşturun ve envanterde çıkardığınız her kaydı tek tek, eksiksiz biçimde içe aktarın.
2. Envanterdeki her ad ve her kayıt türü için eski ve yeni ad sunucularının verdiği yanıtları doğrudan karşılaştırın.
3. DNSSEC'i önceden planlayın: bölge imzalıysa ad sunucularını değiştirmeden önce DNSSEC rehberindeki yaklaşımı izleyin.
4. Ancak bu doğrulamalar tamamlandıktan sonra kayıt kuruluşunda alan adının ad sunucularını değiştirin.
5. Yeni sağlayıcıdaki sorgu günlüklerini ve hizmetlerinizin hata oranlarını ilk saatlerde yakından izleyin.
6. Eski bölgeyi en az NS TTL süresi artı bir güvenlik payı boyunca değiştirmeden sunmayı sürdürün, ancak ondan sonra silin.

dig @ns1.old-dns.example.net example.com MX +short
dig @ns1.new-dns.example.net example.com MX +short

dig @ns1.old-dns.example.net selector1._domainkey.example.com TXT +short
dig @ns1.new-dns.example.net selector1._domainkey.example.com TXT +short

Değişiklikten sonra delegasyonu iki ayrı yerden kontrol edin: kayıt otoritesinin elindeki ad sunucularını WHOIS Sorgulama aracıyla, çözümleyicilerin gerçekte gördüğü değerleri ise DNS Sorgulama aracıyla doğrulayın.

4. adım: kayıt kuruluşunu aktarmak

Kayıt kuruluşu transferinin DNS'e hiç dokunması gerekmez ve ideal olan da dokunmamasıdır. Ad sunucularını baştan sona kendi DNS sağlayıcınızı gösterecek şekilde bırakın; böylece transfer kullanıcılar açısından tamamen görünmez kalır. Transferi alan adının süre bitimine yakın bir tarihte başlatmayın ve kayıt sahibi iletişim adresinin gerçekten çalıştığından emin olun, çünkü transfer onay iletileri o adrese gider.

• Mevcut kayıt kuruluşunda alan adının kilidini açın, yani transfer kilidini kaldırın.
• Yetkilendirme kodunu (auth code, EPP kodu) alın ve güvenli bir yerde saklayın.
• Ad sunucularını ve varsa DS kayıtlarını doğrulayıp değerlerini bir kenara not edin.
• Transferi yeni kayıt kuruluşunda başlatın ve gelen onay iletilerinin hepsini onaylayın.
• Transfer tamamlandıktan sonra ad sunucularını, DS kayıtlarını, iletişim bilgilerini ve otomatik yenilemeyi doğrulayın; transfer kilidini ve kullanıyorsanız kayıt otoritesi kilidini yeniden etkinleştirin.
• Tamamlanan bir transferin ardından, ICANN transfer politikasının genel üst düzey alan adları için izin verdiği üzere 60 günlük yeni transfer kısıtlaması olacağını hesaba katın.

5. adım: e-postayı taşımak

Posta kısa kesintileri tolere eder, çünkü gönderen sunucular teslimatı çoğu zaman günler boyunca yeniden dener. Buna karşılık kimlik doğrulama hatalarını hiç tolere etmez; bu hatalar zorlayıcı bir DMARC politikası altında anında reddedilmeye yol açar. Bu nedenle yeni sağlayıcı üzerinden tek bir ileti bile akmadan önce o sağlayıcı için kimlik doğrulamasını eksiksiz kurun.

1. Yeni posta sağlayıcısında alan adını doğrulayın ve sağlayıcının DKIM kayıtlarını, eskileri silmeden onların yanına yayımlayın.
2. Eski sağlayıcıyı SPF kaydında tutmayı sürdürerek yeni sağlayıcıyı da ekleyin ve arama sayısını E-posta Güvenliği aracıyla kontrol edin.
3. MTA-STS kullanıyorsanız yeni MX sunucularını politika dosyasına ekleyin ve politika kimliğini MX değişikliğinden en az bir max_age süresi önce değiştirin.
4. Posta kutularını yeni sağlayıcıya taşıyın, ancak ondan sonra MX kayıtlarını değiştirin.
5. DMARC toplu raporlarını ve eski sağlayıcıya hâlâ ulaşmaya devam eden postaları birlikte izleyin.
6. Birkaç hafta sonra eski sağlayıcıyı SPF kaydından çıkarın, DKIM anahtarlarını iptal edin ve MTA-STS politikasını güncelleyin.

Değişiklikten sonra yeni MX kayıtlarını MX ve SMTP aracıyla kontrol edin. rua raporlamasını bu süre boyunca kesintisiz açık tutun; eski sağlayıcının aktarım sunucusunu hâlâ kullanmayı sürdüren bir gönderim sistemi kaldıysa raporlarda kendiliğinden ortaya çıkar.

6. adım: TLS sertifikaları

Trafik taşınmadan önce yeni sunucuda geçerli bir sertifika hazır olsun. Yeni platform sertifikalarını HTTP doğrulamasıyla alıyorsa bunu ancak DNS kendisini gösterdikten sonra yapabilir; bu da kısa süreli bir sertifika hatası penceresi açar. DNS tabanlı doğrulama ya da elinizdeki geçerli sertifikayı yükleme imkânı bu pencereyi tamamen ortadan kaldırır. HSTS etkinken sertifika hatası, siteye daha önce girmiş ziyaretçiler için kısmi bir aksama değil, doğrudan bir kesinti anlamına gelir.

• CAA kayıtlarının, yeni platformun kullandığı sertifika otoritesine sertifika vermesi için izin verdiğini kontrol edin.
• www dahil olmak üzere taşınan bütün ana bilgisayar adlarını ve alt alan adlarını sertifikanın kapsamına alın.
• Geçişten önce yeni sunucuyu, doğru ana bilgisayar adıyla doğrudan onun IP adresine bağlanarak test edin.
• Geçişten sonra sonucu TLS Kontrolü aracıyla doğrulayın ve sertifika süresinin dolması için bir izleme kurun.

curl -sS -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' --resolve example.com:443:192.0.2.80 https://example.com/

7. adım: alan adını yeniden adlandırmak

Yeniden adlandırma taşımaların en büyüğüdür, çünkü her bağlantı, her yer imi, her arama sonucu ve her e-posta adresi eski adı göstermeye devam eder. Amaç, hiçbir şeyin hiçbir zaman kırılmamasıdır: eski URL'ler kalıcı olarak yeni karşılıklarına yönlenir, eski adresler bir geçiş dönemi boyunca posta almayı sürdürür ve eski alan adı kayıtlı kalmayı sürdürür. Her sayfayı ana sayfaya değil, kendi yeni karşılığı olan sayfaya yönlendirin.

server {
    listen 443 ssl;
    server_name example.org www.example.org;
    return 301 https://example.com$request_uri;
}

• Yolu değişen sayfalar için bir URL haritası çıkarın ve bu haritayı Yönlendirme Kontrolü aracıyla tek tek test edin.
• 301 yönlendirmesi kullanın ve bunları aylarca değil, yıllarca yerinde bırakın.
• Arama motorlarına kendi araçları üzerinden haber verin; örneğin Google Search Console'daki adres değişikliği özelliğiyle.
• OAuth yönlendirme adreslerini, SSO ayarlarını, webhook'ları, API istemcilerini ve uygulamalara gömülü sabit bağlantıları güncelleyin.
• Eski adreslere gelen postayı bir geçiş dönemi boyunca yönlendirmeyi sürdürün ve yeni adresleri düzenli yazıştığınız kişilere ayrıca duyurun.
• Eski alan adını yenilemeyi hiç aksatmayın; süresi dolan eski bir alan adını bir başkası kaydettirip sizin trafiğinizi ve postanızı alabilir.

Geri dönüşü işe başlamadan önce planlayın

Her geçiş adımının yazılı bir geri dönüş yolu ve bu yolu ne zaman kullanacağına karar verecek belirli bir sorumlusu olmalıdır. TTL değerleri düşükken bir kayıt değişikliğini geri almak dakikalar sürer; ad sunucusu değişikliğini geri almak ise NS TTL süresi kadar sürer ve eski DNS sağlayıcısına dokunulmamasının nedeni tam olarak budur. Geri dönüş planını olayın ortasında değil, değişiklik penceresi açılmadan önce yazıya dökün.

Geri dönüşü tetikleyecek sinyalleri, pencere açılmadan önce ortak kararla belirleyin; örneğin postaların on beş dakikadan uzun süredir geri dönmesi ya da ana sitenin belirli bir bölgede hata vermesi. Net ölçütler hem sağlıklı bir değişikliğin paniğe kapılıp gereksiz yere geri alınmasını hem de kullanıcılar etkilenmeyi sürdürürken bozuk bir kurulumun saatlerce kurcalanmasını önler.

Kalıcı yönlendirmeler, geri alınması gerçekten zor olan tek değişikliktir, çünkü tarayıcılar 301 yanıtlarını uzun süre önbelleğe alır. Bir URL eşlemesinden emin değilseniz kısa bir süre boyunca 302 ile test edin ve eşlemenin doğru olduğu kesinleştikten sonra 301'e geçin.

Taşımadan sonra

Eski DNS bölgesini, eski posta kiracısını veya eski barındırmayı ancak bu kontrollerin hepsi geçtikten sonra kapatın. İptal edilmiş ama DNS kayıtları hâlâ kendilerini göstermeye devam eden hizmetler, klasik alt alan adı devralma kurulumudur; bu yüzden geride kalan kayıtları da temizliğin ayrılmaz bir parçası olarak silin.

SSS

Kaynaklar

• RFC 1034: Alan adları, kavramlar ve olanaklar (önbellekleme ve TTL)
• RFC 8659: DNS sertifika otoritesi yetkilendirmesi (CAA)
• ICANN: Transfer politikası
• Google Search Central: URL değişikliği içeren site taşımaları
• RFC 8461: MTA-STS