Alan Adı Transferi Neyi Değiştirir?
Alan adı transferi, alan adının kayıt kuruluşunu değiştirmektir. Web sitesi dosyaları, veritabanı ve e-posta kutuları bu işlemle yeni sunucuya taşınmaz. Kayıt kuruluşu, yetkili DNS hizmeti ve hosting ayrı bileşenlerdir; aynı firmadan alınmış olsalar bile geçiş planında ayrı ele alınmalıdır.
Bu rehber EPP/AuthInfo kodunu, transfer kilidini, onay akışını ve DNS bağımlılıklarını açıklar. Amaç kesinti riskini azaltan, doğrulanabilir bir geçiş planıdır. İsim sunucularını korumak tek başına kesintisizlik garantisi değildir: eski firmanın DNS, e-posta veya yönlendirme hizmetinin alan adı transferinden sonra da devam edeceği doğrulanmalıdır.
Neden Alan Adını Taşırız? Zamanlama Neden Bu Kadar Kıymetli?
Transfer isteği genellikle iki şeyden doğar: mevcut yerde yaşanan bir memnuniyetsizlik veya daha iyi bir teklif. Kimi zaman destek ekibine ulaşmak zordur, kimi zaman kontrol paneli kasıntıdır, bazen de fiyatlar günden güne artıyormuş gibi hissedersiniz. Bazen hiç beklemediğiniz bir anda, yenileme döneminde gelen bir e-posta karar anını hızlandırır, “tamam, taşınalım” dersiniz ve top yuvarlanmaya başlar.
Yalnız kayıt kuruluşu değişecekse hosting dosyaları ve veritabanı yerinde kalır. Mevcut DNS hizmetinin devam koşullarını, alan adının sona erme tarihini, hesap erişimini ve bekleyen kısıtlamaları önceden kontrol edin. Son güne sıkıştırılmış bir işlem, kod veya onay sorunu için zaman bırakmaz; transferin tamamlanması ile DNS ve hosting hizmetlerinin kapanması arasında bağımlılık kurmayın.
Örneğin bir şirket alan adlarını tek hesapta toplamak, fakat web ve e-posta hizmetlerini mevcut sağlayıcılarında tutmak isteyebilir. Bu senaryoda transfer, kayıt yönetimini değiştirir; NS, DS, DNS kayıtları ve servis abonelikleri korunur. Ücretsiz DNS’in eski kayıt hesabına bağlı olduğu bir hizmette ise önce DNS’in devam edeceği yazılı olarak doğrulanmalı veya DNS geçişi ayrıca hazırlanmalıdır.
EPP Kodu Nedir, Nerede Saklanır, Nasıl Alınır?
EPP/AuthInfo kodu, transfer sürecinde kullanılan alan adına özgü gizli bir koddur; şifrelenmiş sahiplik belgesi veya hesaba tam erişim sağlayan parola değildir. Mevcut kayıt kuruluşundan alınır ve yalnız transfer edeceğiniz yeni kuruluşun doğrulanmış paneline girilir. Panelde “EPP”, “Auth Code” veya “Transfer Code” adıyla bulunabilir; görünmüyorsa sağlayıcının kimlik doğrulamalı destek sürecini kullanın.
Önce kayıt hesabınızdaki iletişim kanalına erişebildiğinizi doğrulayın. Kamuya açık kaydın gizlenmiş olması, hesabın iletişim adresinin yanlış olduğu anlamına gelmez. Kodun nasıl teslim edildiği ve ne zaman yenilendiği sağlayıcıya bağlıdır; yalnız görüntülemenin her zaman kodu değiştirdiğini varsaymayın. Kodu ekran görüntüsüne, açık destek kaydına veya sohbete eklemeyin; açığa çıktıysa mevcut kuruluştan yenilenmesini isteyin.
EPP kodunu alamıyorum, şimdi ne olacak?
Panelde kod üretme olanağı yoksa mevcut kayıt kuruluşuna yetkili hesap üzerinden talep iletin. ICANN politikasının kapsadığı gTLD’lerde, self servis sağlanmayan ilgili durumda AuthInfo kodunun ve uygulanabilir clientTransferProhibited kaldırma işleminin ilk talepten itibaren beş takvim günü içinde sağlanması gerekir. Başka bir politika, mahkeme veya uyuşmazlık kısıtlaması yine geçerli olabilir. Yanıt gelmezse talep tarihini ve verilen gerekçeyi kaydedip resmi destek/şikâyet yolunu izleyin; kodu tekrar tekrar paylaşmayın.
Transfer Kilidi, 60 Gün Kuralı ve Onaylar
Olağan transfer kilidi, genellikle clientTransferProhibited durumuyla transferi engeller. Transfer hazırlığı tamamlandığında panelden kaldırılabilir; işlem bitince yeniden etkinleştirilmelidir. serverTransferProhibited gibi kayıt işletmecisi tarafındaki durumlar farklıdır ve sağlayıcının müdahalesini gerektirir. Bir anahtarın panelde “açık” görünmesi, alan adının bütün transfer koşullarını sağladığını kanıtlamaz.
Onay ve bildirim adımları mevcut ve yeni kuruluşun uygulanabilir akışına göre değişir; her transferde aynı iki e-postanın geleceğini varsaymayın. Gizlilik hizmetini otomatik olarak kapatmak gerekmez. Önce sağlayıcının doğrulanmış panelinden iletişim ve onay yöntemini kontrol edin. E-postadaki alan adını ve işlem ayrıntısını doğrulayın; tanımadığınız bir transfer bildirimini bekleyerek onaylamış sayılmayın, hemen mevcut kuruluşla iletişime geçin.
ICANN kapsamındaki gTLD’lerde ilk kayıttan sonraki 60 gün ve önceki transferden sonraki 60 gün içinde, politikanın belirttiği koşullarla transfer reddedilebilir. Kayıt sahibi adında, kuruluşunda veya e-posta adresinde esaslı değişiklik ayrı bir 60 günlük kilit doğurabilir. Kuruluşun sunduğu vazgeçme seçeneği varsa değişiklik talebinden önce kullanılmalıdır; sonradan olağan kilit anahtarını çevirmek bu engeli aşmaz. Eski e-postaya erişemiyorsanız doğru bilgileri sağlayıcıyla güvenli biçimde düzeltin ve olası beklemeyi plana katın. ccTLD kuralları ayrıca kontrol edilmelidir.
DNS ve İsim Sunucularını Geçişe Hazırlama
Yalnız kayıt kuruluşu değişecekse mevcut isim sunucuları ve DNS kayıtları korunabilir. Ancak önce DNS hizmetinin transferden sonra kapanmayacağını, yeni kuruluşun mevcut DS kayıtlarını yönetebildiğini ve alan adının etkin kalacağını doğrulayın. Özel isim sunucuları kullanıyorsanız bunların adresleri ve gerekli glue kayıtları da envantere dahil olmalıdır. NS listesini aynı tutmak, arkasındaki hizmetin devamını tek başına sağlamaz.
DNS de taşınacaksa kayıt kuruluşu transferinden ayrı bir aşama planlayın; sıra hizmet bağımlılıklarına göre belirlenir. Eski DNS transferle kapanıyorsa yeni DNS önceden hazır olmalıdır. A, AAAA, CNAME, MX, TXT, SRV, CAA, alt alan adları ve doğrulama kayıtlarını envantere alın; yeni sağlayıcının SOA/NS ve özel kayıt biçimlerini kendi kurallarına göre oluşturun. DNS kayıtları ve yaygın hatalar rehberi kayıt türlerini karşılaştırmanıza yardımcı olur.
Değişecek kayıtların TTL değerini, önceki TTL’nin dolmasına zaman bırakacak kadar erken düşürün. Yeni değer daha önce önbelleğe alınmış yanıtları temizlemez; negatif önbellek ve yenileme başarısızken eski yanıt kullanımı ayrıca etkili olabilir. Alan adının A kaydı TTL’si, üst bölgedeki NS veya DS TTL’sini değiştirmez. Geçişten sonra kararlılık doğrulanınca uygun normal TTL’ye dönün; “birkaç dakika sonra herkes yeni sunucuda” varsayımı yapmayın.
DNSSEC açıksa yalnız kayıt kuruluşu transferi için imzalamayı kapatmayın; mevcut DS zincirini ve yönetim desteğini doğrulayın. DNS işletmecisi değişirken sağlayıcılar destekliyorsa koordineli anahtar/DS geçişiyle imzalı zincir korunabilir. Geçici imzasız geçiş seçilmişse önce üst bölgedeki DS kaldırılmalı, kaldırma doğrulanıp eski DS’nin önbellek süresi dolarken eski imzalı hizmet korunmalı, sonra uyumsuz anahtar veya NS değişimi yapılmalıdır. Yeni bölge doğru imzalanıp delegasyon doğrulandıktan sonra yeni DS yayımlanır; arada DNSSEC doğrulama koruması yoktur. Anycast DNS ve failover ile DDoS korunma yöntemleri ayrı dayanıklılık konularıdır; bozuk DS zincirini düzeltmez.
Adım Adım Transfer: Başlat, Onayla, Takip Et
Yeni kuruluştaki transfer ekranında alan adını, güncel EPP kodunu, uzantı koşullarını ve ücreti kontrol ederek işlemi başlatın. Gereken yetkilendirme adımlarını tamamlayın; mevcut kuruluşun bildirimlerini ve iki paneldeki durumu izleyin. ICANN kapsamındaki uygun talepte, kayıt işletmecisinin bildirimi sonrası eski kuruluş beş takvim günü içinde ret iletmezse varsayılan onay akışı vardır. Bu süre, ödeme anından itibaren toplam işlemin kesin bitiş süresi değildir; erken onay sunulması ve hazırlık süreleri sağlayıcıya bağlıdır.
Transferi sona erme tarihinden yeterince önce planlayın. Sona erme tek başına her durumda geçerli ret gerekçesi değildir; fakat silinme, geri alma dönemi, önceki dönem borcu ve diğer kayıt durumları işlemi etkileyebilir. Gerekliyse yenileme veya kurtarma adımlarını mevcut kuruluşla doğrulayın. Transferi yeni panelde görünmesine ek olarak kayıt durumundan ve iki kuruluşun tamamlanma bildirimlerinden teyit edin; DNS, web ve e-postayı ayrı test edin.
ICANN politikasının kapsadığı normal transfer, toplam kalan kayıt süresi on yılı aşmayacak şekilde bir yıl ekler. ccTLD koşulları ile yakın zamanda yapılan otomatik yenilemenin süre/ücret hesabı farklı olabilir; toplamı ve yenileme tarihini faturayla birlikte doğrulayın. İşlem tamamlandığında transfer kilidini yeniden etkinleştirin, iki aşamalı doğrulamayı ve hesap kurtarmayı kontrol edin, otomatik yenileme ile gizlilik tercihlerini yeni hesapta gözden geçirin.
E-posta, SPF-DKIM-DMARC ve SSL: Küçük Dokunuşlar, Büyük Rahatlık
DNS veya e-posta sağlayıcısı değişmiyorsa MX ve doğrulama kayıtlarını sırf alan adı transferi yapıldı diye değiştirmeyin. DNS taşınıyorsa MX hedefleri, hedeflerin adresleri, SPF politikası, DKIM seçicileri ve DMARC kaydı eksiksiz korunmalıdır. Kullanılmıyor sanılan bir TXT kaydını sahibi ve amacı bilinmeden silmeyin. Bu kayıtların doğruluğu tek başına gelen kutusu garantisi sağlamaz; e-posta teslim edilebilirliği rehberi kimlik doğrulama ve diğer etkenleri açıklar.
Kayıt kuruluşu değişikliği mevcut TLS sertifikasını kendiliğinden geçersiz kılmaz. Hosting veya DNS değişiyorsa sertifikanın yeni uçta doğru sunulduğunu, CAA politikasını ve otomatik yenilemenin HTTP/DNS doğrulama yolunu kontrol edin. DNS-01 kullanılıyorsa yeni DNS API erişimi veya challenge delegasyonu ayrıca hazırlanmalıdır. E-posta da taşınacaksa kutuları ve geçmiş iletileri eşitleyin, geçiş boyunca gelen postayı iki uçta izleyin; MX değiştirmek eski kutudaki iletileri taşımaz.
Sorun Çıkarsa: Sık Takılınan Noktalar ve Sakin Çözümler
Başlamayan transferde önce tam durum kodunu ve kayıt kuruluşunun gerekçesini alın. clientTransferProhibited olağan kilidi gösterebilir; serverTransferProhibited kayıt işletmecisi kısıtlamasıdır, sahiplik değişikliği kilidi ise farklı biçimde uygulanabilir. Güncel gTLD durumunu ICANN Lookup/RDAP veya kuruluşun kayıt verisi hizmetinden inceleyin. IANA WHOIS hizmeti üst düzey kayıt/yönlendirme bilgisi sağlar; özel hesap iletişim adresinizi doğrulayacağınız panelin veya bütün alan adlarına ait ayrıntılı durum sorgusunun yerine geçmez.
Onay mesajı gelmiyorsa önce o adımın kuruluşun akışında gerekli olup olmadığını, panel durumunu, spam klasörünü ve iletişim kanalına erişimi kontrol edin. Bir kayıt sahibi e-posta değişikliğinin 60 günlük kilit doğurabileceğini hesaba katmadan adresi değiştirmeyin. Erişim kaybı varsa sağlayıcının hesap kurtarma/doğrulama yolunu kullanın; sorunu çözmek için gizli kodu açık ekran görüntüsüne eklemeyin.
ICANN transfer politikası sayfasındaki güncel sürüm ve yürürlük bağlantılarını esas alın; geçmiş metnin tarihi tüm güncel koşulları anlatmaz. Bu rehberdeki beş takvim günü ve 60 gün açıklamaları ICANN kapsamındaki gTLD politikası içindir. Ülke uzantılarının süreçleri, kodları ve süreleri farklı olabilir. Reddedilen talepte uygulanmış kuralı ve bekleme bitişini yazılı olarak istemek, aynı işlemi körlemesine tekrarlamaktan daha yararlıdır.
Transfer Sonrası Doğrulama ve Dayanıklılık
Geçiş sonrası kayıt kuruluşunu, sona erme tarihini, kilidi, NS/DS değerlerini ve hesap güvenliğini kaydedin. Web sayfası açılmasının yanında alt alan adlarını, dışarıdan gelen ve dışarı giden e-postayı, HTTPS’i ve sertifika yenileme yolunu kontrol edin. DNS temizliği ayrı bir değişiklik olarak yapılmalı; DNS kayıtları rehberindeki kayıt türlerini inceleyip yalnız amacı ve kullanım dışı kaldığı doğrulanan kayıtları kaldırın.
Hosting de değiştiyse son dosya/veritabanı eşitlemesi ve tek yazıcı düzeni gerekir; iki sunucunun ayrı sipariş veya kullanıcı verisi kabul etmesine izin vermeyin. Eski ucu gerektiğinde yeni uygulamaya güvenli biçimde yönlendirin ya da yazıları durdurun. DNS geri alma işlemi anlık değildir ve yeni sunucudaki veriyi geri taşımaz. Anycast DNS ve otomatik failover planı da veri tutarlılığı, hedef sağlığı ve kapasiteyle birlikte tasarlanmalıdır.
Alan Adı Transferi İçin Son Kontrol Listesi
Önce hesabı ve iletişim erişimini doğrulayın; kayıt tarihini, son transferi, sahiplik değişikliklerini, sona erme tarihini ve engelleri kontrol edin. DNS’in devam koşullarını netleştirin, gerekiyorsa ayrı DNS/hosting geçişini hazırlayın. Uygun alan adında olağan kilidi kaldırıp EPP koduyla transferi başlatın; gereken onayları ve iki kuruluşun bildirimlerini takip edin. Yalnız kayıt kuruluşu değişiyorsa gereksiz NS, DS veya hosting değişikliği eklemeyin.
Tamamlandıktan sonra kayıt bilgilerini, hizmetleri ve yenileme tarihini doğrulayın; transfer kilidini yeniden etkinleştirip kodu gereksiz kopyalarda tutmayın. E-posta sorunu varsa SPF, DKIM ve DMARC incelemesini MX yönü, kutu erişimi ve gönderici IP’siyle birlikte yapın. Yapılan değişiklikleri, geri dönüşün veri koşullarını ve sorumlu kişiyi kaydetmek sonraki yenileme veya geçişi daha öngörülebilir kılar.
