Bloga dönRehberler

Kesinti Olmadan Nameserver Değiştirme Rehberi

Alan adını yeni nameserver'lara taşımak için adım adım plan: TTL ayarı, DNS bölgesini kopyalama, DNSSEC, farklı çözümleyicilerden doğrulama ve geri dönüş.

Yayınlanma: · 5 dk okuma

Nameserver değişikliği, bir alan adını tümüyle erişilmez hale getirebilen az sayıdaki DNS işleminden biridir: web sitesi, e-posta, API, hepsi birden. Sorun çoğu zaman değişikliğin kendisinden çıkmaz. Yeni DNS bölgesi eksik kurulduğu, bir TTL değeri bir hafta olduğu ya da DNSSEC hâlâ eski sağlayıcıyı gösterdiği için çıkar.

Bu rehber, kendi alan adlarımızda izleyeceğimiz plandır. Örneklerde ayrılmış alan adları ve dokümantasyon IP adresleri kullanılmıştır.

Nameserver değiştirince gerçekte ne olur?

Alan adınızın NS kayıtları iki yerde durur:

  • Üst bölgede (.com, .org, .com.tr gibi uzantıların kayıt operatöründe). Buna delegasyon denir ve kayıt firmanızın panelinden değiştirilir.
  • Kendi DNS bölgenizin içinde, DNS sağlayıcınızın sunduğu kayıtlarda. Bunlar delegasyonla aynı olmalıdır.

Bir çözümleyici www.example.com adresini arar ve önbelleğinde bir şey yoksa önce üst bölgeye “bu alan adından kim sorumlu?” diye sorar, delegasyonu alır, sonra o nameserver'lardan birine sorar. Nameserver değiştirmek, üst bölgedeki bu delegasyonu değiştirmektir.

İnternete hiçbir şey “gönderilmez”. Dünyadaki çözümleyiciler önbelleklerindeki yanıtı süresi dolana kadar kullanır, sonra yeniden sorar ve yeni yanıtı alır. “DNS yayılması” (propagation) denen şey budur ve aslında yanıltıcı bir ifadedir: dışa doğru yayılan bir dalga yoktur, yalnızca farklı zamanlarda süresi dolan önbellekler vardır.

1. Adım — Eski bölgenin dökümünü çıkarın

Eski sağlayıcıdan DNS bölgesinin tamamını dışa aktarın. Dışa aktarma (BIND biçimi) seçeneği varsa onu kullanın, yoksa kayıtları tek tek listeleyin. En sık unutulanlar:

  • MX kayıtları ile SPF, DKIM seçicileri (secici._domainkey) ve _dmarc için TXT kayıtları
  • arama konsolları, SaaS araçları ve sertifika doğrulaması için eklenmiş TXT kayıtları
  • CAA kayıtları
  • SRV kayıtları (_sip, _autodiscover vb.)
  • kendi NS kayıtlarıyla başka yere devredilmiş alt alan adları
  • joker kayıtlar (*.example.com)

Dışarıdan yapılan bir DNS sorgusu yalnızca sorduğunuz adları gösterir, bu yüzden dışa aktarmanın yerini tutmaz. Yine de çapraz kontrol için işe yarar:

$ dig +short example.com MX
10 mx1.mail.example.
$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

2. Adım — Yeni bölgeyi kurun ve doğrudan test edin

Delegasyona dokunmadan önce tüm kayıtları yeni sağlayıcıda oluşturun. Ardından önbellekleri atlayarak yeni nameserver'lara doğrudan sorun ve eskileriyle karşılaştırın:

$ dig @ns1.olddns.example example.com A +short
192.0.2.10
$ dig @ns1.newdns.example example.com A +short
192.0.2.10

Dökümdeki her kayıt türü ve her ad için tekrarlayın. Bilerek değiştirdiğiniz bir şey yoksa yanıtlar birebir aynı olmalıdır. Nameserver taşımasını sunucu taşımasıyla birleştirmeyin: her seferinde tek bir şeyi değiştirirseniz, sorun çıktığında tek bir olası neden olur.

3. Adım — TTL değerlerini önceden düşürün

İki TTL önemlidir:

  1. Eski sağlayıcıdaki kayıtlarınızın TTL değerleri. Taşımadan en az bir eski TTL süresi kadar önce düşürün (300 saniye yaygındır). Eski TTL 86400 ise bunu en az bir gün önceden yapın.
  2. Üst bölgedeki delegasyon TTL'i. Bunu siz belirleyemezsiniz. Birçok uzantıda 48 saattir (172800 saniye). Taşıma pencerenizin gerçek uzunluğu budur.

İkinci madde yüzünden, her iki nameserver kümesinin de en az iki üç gün boyunca doğru yanıt vereceğini varsayarak plan yapın.

4. Adım — Önce DNSSEC'i çözün

Alan adı imzalıysa üst bölgede eski sağlayıcının anahtarını gösteren bir DS kaydı vardır. Bu DS yerinde dururken nameserver değiştirirseniz ve yeni sağlayıcı farklı bir anahtarla imzalıyorsa (ya da hiç imzalamıyorsa), doğrulama yapan çözümleyiciler tüm yanıtları geçersiz sayar. Alan adı, kullanıcıların büyük bir bölümü için tamamen erişilmez olur ve TTL düşürmek bunu kurtarmaz.

Önce kontrol edin:

$ dig +short example.com DS

DS kaydı varsa iki yoldan birini seçin:

  • Taşıma süresince imzayı kaldırın. Kayıt firmasından DS kaydını silin, üst bölgedeki DS TTL'inin dolmasını bekleyin (çoğu zaman 24 saat ya da daha fazla), nameserver'ları değiştirin, ardından yeni sağlayıcıda DNSSEC'i açıp yeni DS kaydını yayınlayın.
  • Her iki sağlayıcı da destekliyorsa çoklu imzalayıcı (multi-signer) geçişi yapın: geçişten önce her sağlayıcı diğerinin açık anahtarını yayınlar. Alan adı baştan sona imzalı kalır, ancak iki tarafın da iş birliği gerekir.

5. Adım — Delegasyonu değiştirin

Kayıt firması panelinde eski nameserver'ları yenileriyle değiştirin. Adları yeni sağlayıcının verdiği biçimde, harfi harfine girin. Bazı kayıt operatörleri teknik kontrol yapar ve yeni sunucular bölge için yetkili yanıt vermiyorsa değişikliği reddeder. 2. adımı önce bitirmek için bir neden daha.

Eski bölgeyi çalışır ve değişmemiş halde bırakın. Sonraki günlerde bazı çözümleyiciler hâlâ eski sunuculara soracaktır. Bu sırada bir kaydı değiştirmeniz gerekirse iki tarafta da değiştirin.

6. Adım — Birden fazla noktadan doğrulayın

Üst bölgenin ne dediğine doğrudan bakın:

$ dig +trace example.com NS

Ardından birkaç açık çözümleyiciye sorup karşılaştırın. Bir süre karışık yanıtlar görmeniz normaldir. İki bölge de aynı veriyi sunduğu sürece bu bir arıza değildir.

Bakmanız gerekenler:

  • Her konum hangi NS kümesini döndürüyor: eski mi, yeni mi? Kısmi bir küme (biri eski, biri yeni) başarı sayılmaz.
  • A, AAAA ve MX yanıtları eski ve yeni tarafta aynı mı?
  • HTTPS hâlâ geçerli sertifika sunuyor mu, e-postalar geliyor mu?

“%85 yayıldı” gibi iddialara temkinli yaklaşın. Hiçbir araç internetteki tüm çözümleyicileri ölçemez. Dürüst ifade daha dardır: “İzlenen 12 konumdan 9'u yeni nameserver'ları döndürüyor, 2'si eskileri döndürüyor, 1'i kontrol edilemedi.”

7. Adım — Eski bölgeyi dikkatle kapatın

Eski bölgeyi silmeden önce en az üst bölgedeki delegasyon TTL'i kadar, üstüne bir güvenlik payı ekleyerek bekleyin (üç gün makul bir alt sınır, bir hafta rahat bir süredir). Sonra kayıt TTL'lerinizi normal değerlere (3600 ve üzeri) geri yükseltin. Bu, sorgu yükünü azaltır ve dayanıklılığı artırır.

Geri dönüş planı

Başlamadan önce eski nameserver adlarını not edin ve eski bölgeyi olduğu gibi bırakın. Geçişten sonra bir sorun çıkarsa:

  1. Sorun eksik ya da hatalı bir kayıtsa, kaydı yeni sağlayıcıda düzeltin. Neredeyse her zaman en hızlı çözüm budur.
  2. Sorun yeni sağlayıcının kendisindeyse delegasyonu eski nameserver'lara geri alın. Geri dönüşün de aynı önbelleklere takılacağını, yani anında olmayacağını unutmayın.

Sık yapılan hatalar

  • Önce nameserver'ı değiştirip kayıtları sonradan oluşturmak.
  • DKIM seçicilerini unutmak. E-postalar günler sonra DMARC'tan kalmaya başlar.
  • Aynı anahtarla imzalamayan bir sağlayıcıya geçerken DS kaydını yerinde bırakmak.
  • Eski bölgeyi aynı gün silmek.
  • Kendi bilgisayarınızdan yapılan tek bir başarılı sorguyu taşımanın bittiğinin kanıtı saymak.

OrbitProbe ile kontrol edin

DNS sorgulama aracıyla açık çözümleyicilerin alan adınız için şu anda hangi kayıtları ve nameserver'ları döndürdüğünü görün. Whois sorgulama ile kayıt operatöründe görünen nameserver'ları ve DNSSEC durumunu doğrulayın. OrbitProbe çalışma alanında ayrıca beklediğiniz nameserver kümesi için bir izleme oluşturabilirsiniz. İzleme, izlenen konumlardan kaçının eşleştiğini, hangilerinin hâlâ eski değeri gösterdiğini ve hangilerinin kontrol edilemediğini bildirir.