DNS sağlayıcınızı değiştirmeye karar verdiniz. İşlem panelde tek bir alan doldurmakla bitiyor gibi görünüyor — ama yanlış sırayla yapıldığında siteniz ve e-postanız saatlerce kesilebilir.
Bu yazı, ad sunucusu geçişinin doğru sırasını ele alıyor.
Transfer Değil, Sadece DNS
Önce sık karıştırılan iki işlemi ayırmak gerekir:
| Alan adı transferi | Ad sunucusu değişikliği |
|---|---|
| Kayıt kuruluşu değişir | Kayıt kuruluşu aynı kalır |
| Onay süreci gerekir | Anında yapılabilir |
| Günler sürer | Saatler içinde yayılır |
| Kilit açılması gerekir | Kilit engel değildir |
Bu ayrım önemlidir çünkü DNS sağlayıcınızı değiştirmek için alan adınızı transfer etmenize gerek yoktur — ad sunucusu alanını güncellemek yeterlidir.
Mevcut ad sunucularınızı ve kayıt bilgilerinizi domain kontrolü ile görüntüleyip başlangıç durumunuzu kaydedin.
Asıl Risk
Geçişin tehlikeli yanı şudur: ad sunucusu değiştiği anda, yeni sunucuların bildiği kayıtlar geçerli olur.
- Yeni sunucularda kayıt yoksa hiçbir şey çözümlenmez.
- Eksik kayıtlar sessizce kaybolur.
- Geri dönüş de anında olmaz.
İkinci madde en sinsi olanıdır: A kaydını taşıyıp MX kaydını unutursanız site çalışır ama e-posta durur — ve bunu kimse size haber vermez.
Bu yüzden geçişin en kritik adımı, yeni sağlayıcıda kayıtların eksiksiz oluşturulmasıdır.
Doğru Sıra
Kesintisiz geçiş için izlenecek adımlar:
- Mevcut tüm kayıtları dışa aktarın. Tam liste.
- TTL değerlerini düşürün. Geçişten günler önce.
- Yeni sağlayıcıda kayıtları birebir oluşturun.
- Yeni sunuculardan doğrudan sorgulayarak doğrulayın.
- Ad sunucularını değiştirin.
- Yayılmayı izleyin.
- Eski sağlayıcıyı bir süre kapatmayın.
Dördüncü madde geçişin güvenlik ağıdır ve atlanmamalıdır: yeni ad sunucularını doğrudan sorgulayarak, henüz kimse onlara yönlenmeden yanıtlarının doğru olduğunu test edebilirsiniz.
Bu test sayesinde eksik bir kaydı, canlıya geçmeden önce fark edersiniz. Sorgu araçlarında hedef sunucu belirtme özelliği bunun içindir.
Kayıt Listesini Eksiksiz Çıkarmak
Unutulan kayıtlar en yaygın sorun kaynağıdır. Kontrol listesi:
- Kök alan adının A kaydı
- www kaydı
- Tüm alt alan adları — test, panel, api, blog…
- MX kayıtları — öncelik değerleriyle
- SPF, DKIM ve DMARC kayıtları
- Sahiplik doğrulama kayıtları
- CAA kaydı — varsa
- IPv6 kayıtları
Beşinci ve altıncı maddeler en çok unutulanlardır: doğrulama ve kimlik kayıtları görünür bir hizmet sunmadığı için akla gelmez — ama kaybolduklarında e-posta teslimatı ve servis bağlantıları bozulur.
Üçüncü madde de dikkat gerektirir. Yıllar içinde eklenmiş alt alan adlarının tam listesini çıkarmak, panelde tek tek kontrol etmeyi gerektirebilir.
TTL Hazırlığı
Geçiş öncesi TTL düşürmenin bir sınırı vardır:
- Kayıt TTL'lerini siz kontrol edersiniz
- Ad sunucusu kaydının TTL'sini genellikle kontrol edemezsiniz
- Bu değer üst kuruluş tarafından belirlenir
- Genellikle uzun tutulur
İkinci madde önemli bir beklenti düzeltmesidir: ad sunucusu değişikliğinin tam olarak yayılması, kayıt TTL'lerinizden bağımsız olarak uzun sürebilir.
Bu yüzden geçiş anında bazı kullanıcılar eski sunuculara, bazıları yeni sunuculara yönlenir. Her iki tarafın da doğru yanıt vermesi bu dönemde kritiktir.
Geçiş Dönemi Yönetimi
İki sağlayıcının aynı anda aktif olduğu dönem için:
| Kural | Nedeni |
|---|---|
| Eski kayıtları silmeyin | Bazı kullanıcılar hâlâ oraya gidiyor |
| İki tarafı senkron tutun | Değişiklik ikisine de yansımalı |
| Yeni kayıt eklemeyi erteleyin | Tutarsızlık riskini azaltır |
| Her iki taraftan sorgu yapın | Fark var mı kontrol edin |
İkinci satır sıkça ihmal edilir ve tuhaf sorunlar yaratır: geçiş döneminde yalnızca yeni sağlayıcıda yapılan bir değişiklik, eski sunuculara yönlenen kullanıcılar için görünmez.
Sonuç, bazı kullanıcıların yeni içeriği görüp bazılarının görmemesidir — ve bu, teşhisi çok zor bir tablodur.
Geçiş Sonrası Doğrulama
Kontrol edilecekler ve sırası:
- Site açılıyor mu? Hem kök hem www.
- Tüm alt alan adları çalışıyor mu?
- Test e-postası gönderip alın.
- SSL sertifikası geçerli mi?
- Bağlı servisler çalışıyor mu? Doğrulama kayıtları.
- Farklı ağlardan test edin.
Üçüncü madde en kapsamlı testtir çünkü tüm e-posta zincirini bir seferde kontrol eder — MX kaydından kimlik doğrulama kayıtlarına kadar.
Altıncı madde ise yayılmanın farklı yerlerde farklı hızda gerçekleştiğini hesaba katar. Kendi bağlantınızdan çalışıyor olması, herkes için çalıştığı anlamına gelmez.
Sonuç
Ad sunucusu değişikliği transfer değildir — kayıt kuruluşunuz aynı kalır ve işlem anında yapılabilir. Asıl risk, eksik taşınan kayıtların sessizce kaybolmasıdır: A kaydını taşıyıp MX'i unutursanız site çalışır ama e-posta durur. Geçişin güvenlik ağı dördüncü adımdır — yeni ad sunucularını doğrudan sorgulayarak, henüz kimse onlara yönlenmeden yanıtlarını test edin. Geçiş sonrası eski sağlayıcıyı hemen kapatmayın ve bu dönemde yapılan her değişikliği iki tarafa birden uygulayın.
Sıkça Sorulan Sorular (SSS)
DNS değiştirmek için alan adımı transfer etmeli miyim?
Hayır. Ad sunucusu değişikliği ile alan adı transferi farklı işlemlerdir. Kayıt kuruluşunuz aynı kalarak DNS sağlayıcınızı değiştirebilirsiniz — panelde ad sunucusu alanını güncellemek yeterlidir ve transfer kilidi buna engel değildir.
Geçişte kesinti yaşar mıyım?
Doğru yaparsanız yaşamazsınız. Kritik adım, ad sunucularını değiştirmeden önce yeni sağlayıcıdaki kayıtları doğrudan sorgulayarak doğrulamaktır. Böylece eksik bir kaydı canlıya geçmeden önce fark edersiniz.
Hangi kayıtlar en çok unutuluyor?
Görünür bir hizmet sunmayanlar: SPF, DKIM, DMARC ve sahiplik doğrulama kayıtları. Kaybolduklarında site çalışmaya devam eder ama e-posta teslimatı bozulur ve bağlı servislerle bağlantı kopar. CAA ve IPv6 kayıtları da sık atlanır.
Eski sağlayıcıyı ne zaman kapatabilirim?
Hemen değil. Ad sunucusu kaydının TTL değerini genellikle siz kontrol edemezsiniz ve uzun tutulur — bazı kullanıcılar günlerce eski sunuculara yönlenmeye devam edebilir. Bu dönemde her iki tarafın da doğru yanıt vermesi ve senkron tutulması gerekir.
