Tek bir domaini taşımak on dakikalık bir iştir. Üç yüz tanesini taşımak bir projedir. Yıllar içinde büyüyen portföyler genelde üç dört farklı kayıt kuruluşuna, birkaç ayrı faturaya ve birbirinden farklı kilitlenme davranışına dağılmış olur. Adımların kendisi zor değildir. Zor olan, bu adımları doğru sırayla, yüzlerce domain için, bir müşterinin sitesini ya da e-posta akışını kesintiye uğratmadan yürütmektir. Bu rehber, büyük bir taşımanın gerçekten gerektirdiği hazırlık, uygulama, hata çözümü ve doğrulama adımlarını anlatıyor.
Toplu domain transferi nedir?
Toplu domain transferi, Türkçe kaynaklarda toplu alan adı transferi olarak da geçer ve çok sayıda domainin tek bir işlemle yeni bir kayıt kuruluşuna taşınmasıdır. Her domain yine tek tek kilitten çıkarılır, kendi transfer koduyla yetkilendirilir ve kayıt kurumu tarafından ayrı ayrı değerlendirilir. Bu yüzden sonucu belirleyen şey hazırlıktır: güncel iletişim bilgisi, geçerli transfer kodu ve gönderim öncesi yapılmış uygunluk kontrolü.
|
Özet: bilinmesi gereken altı şey
|
Toplu domain transferi nasıl çalışır?
Toplu domain transferi, birden fazla transfer talebinin tek seferde gönderilmesidir. Bu, panelden liste yapıştırarak veya API üzerinden yapılabilir. Kolaylık gerçektir ama yalnızca arayüz katmanındadır. Altta her domain tekil bir transferle aynı yolu izler: yeni kayıt kuruluşu, domainin transfer koduyla birlikte kayıt kurumuna talebi iletir, kayıt kurumu kodu doğrular, mevcut kayıt kuruluşunun yanıt için tanımlı bir süresi vardır ve kayıt kurumu o domain için onay ya da ret üretir.
Üç rolü ayırmak işi kolaylaştırır. Kayıt kurumu (registry) uzantıyı işletir ve asıl kaydı tutar. Kayıt kuruluşu (registrar) o kurumla akreditasyon ya da sözleşme ilişkisine sahiptir ve talebi sizin adınıza iletir. Domain sahibi ise domainin hukuki sahibidir. Transfer yalnızca kayıt kuruluşunu değiştirir; sahibi değiştirmez ve siz ayrıca değiştirmedikçe DNS’in nerede barındığını da değiştirmez.
Ekipleri en çok şaşırtan nokta burada. 300 domainlik bir partiden 274 onay ve 26 ret dönmesi, partinin kısmen başarısız olduğu anlamına gelmez. Ortaya her biri kendi ret gerekçesi ve kendi çözümü olan 26 ayrı vaka çıkmıştır.
Toplu domain transferi ne zaman gerekir?
Portföyü yönetmenin maliyeti taşımanın maliyetini geçtiğinde. Tipik tetikleyiciler şunlar: bir satın alma sonrası konsolidasyon, fiyatı ya da paneli artık yetmeyen bir bayilik platformundan çıkış, süresi dolmuş kurumsal kartlara dağılmış yenileme faturalarını tek yerde toplama, ya da bir ajansın yıllardır enformel yönettiği müşteri domainleri resmî hale getirmesi. Taşıma aynı zamanda sessizce biriken sorunları temizlemek için doğru andır: iki yıl önce kapatılmış sunuculara işaret eden isim sunucuları, şirketten ayrılmış kişilere ait iletişim adresleri, kimse bakmadığı için liste fiyatından yenilenen domainler. Taşıma sizi envanter çıkarmaya zorlar ve çoğu zaman envanterin değeri, taşımaya sebep olan fiyat farkından yüksektir.
Tekil transfer ile toplu transfer farkı
İki iş akışı mekanik olarak değil, yükün nereye biriktiği konusunda ayrışır. Tekil transferde yük gönderim anındadır. Toplu transferde yük öne, hazırlığa ve arkaya, doğrulamaya kayar.
| Kriter | Tekil transfer | Toplu transfer |
| Tipik hacim | Bir ile on domain | Onlarca ile binlerce |
| Yükün yeri | Gönderimde, her ad için tekrar | Envanter, uygunluk kontrolü ve doğrulamada |
| Transfer kodları | Gerektikçe tek tek alınır | Toplanır, saklanır ve geçerlilik süresi içinde kullanılır |
| Hata görünürlüğü | Anında fark edilir | Kısmi başarısızlığı görmek için takip tablosu gerekir |
| DNS planlaması | Çoğunlukla enformel yürür | Sahibi belli, geri dönüş planı olan ayrı bir iş kalemi olmalı |
| Süre dolma riski | Düşük; tek tarih takip edilir | Yüksek; gözden kaçan tek tarih domaini kurtarma dönemine sokar |
| Maliyet kontrolü | Domain bazında karar | Portföy geneli yenileme fiyatı sonucu belirler |
| Uygun olduğu durum | Tekil taşımalar ve düzeltmeler | Konsolidasyon, platform değişimi, portföy yeniden yapılandırma |
Domain transferi öncesi kontrol listesi
Hiçbir şey göndermeden önce bu kontrolleri yapın. Başarısız toplu taşımaların neredeyse tamamı, portföyün bir kısmı için atlanmış bir maddeye dayanır.
| Kontrol | Neden önemli | Yapılacak işlem |
| Transfer kilidi | Kilitli domain, talep nasıl gönderilirse gönderilsin kayıt kurumu tarafından reddedilir. | Partideki her domainin kilidini açın ve durumun panelde değil kayıt kurumu tarafında değiştiğini doğrulayın. |
| Geçerli transfer kodu | Çoğu uzantı, kayıt kurumunun doğrulayabileceği bir kod ister ve kodların çoğu süreli olur. | Kodları gönderime yakın alın, eksiksiz kopyalandığını kontrol edin, süresi geçenleri yeniden talep edin. |
| Domain sahibi bilgisi | Onay ve politika bildirimleri kayıttaki sahibe gider. Terminoloji değişti: güncel ICANN çalışmalarında ayrı bir idari sorumlu yerine domain sahibi (Registered Name Holder) esas alınıyor. | Kayıttaki adresin işlem yapabilecek biri tarafından takip edildiğini doğrulayın, gerekiyorsa parti başlamadan güncelleyin. |
| Yeni tescil veya yeni transfer | gTLD tarafında ICANN politikası gereği tescilden, önceki transferden veya belirli sahiplik değişikliklerinden sonra 60 günlük kısıt yaygındır. .tr tarafında da benzer bir 60 gün kuralı uygulanır. | Etkilenen domainleri işaretleyin ve reddi göze almak yerine sonraki partiye planlayın. |
| Bitiş tarihine yakınlık | Süresi dolmak üzere olan domain, işlem ortasında ek süre dönemine girip süreci karmaşıklaştırabilir. | Taşımadan önce yenileyin veya bu domainleri ayrı ve yakın takipli bir partide taşıyın. |
| Domain durum kodları | Kayıt kurumu veya kayıt kuruluşu kaynaklı bekletme durumları transferi engeller ve bakılmadıkça görünmez. | WHOIS veya RDAP çıktısındaki durum kodlarını kontrol edin, engelleri gönderimden önce çözün. |
| DNSSEC | İmzalı bir domainde kayıt kurumundaki DS kayıtları imza zinciriyle uyuşmayı bırakırsa doğrulama kırılır. | DNS sağlayıcısı ve anahtarlar değişmiyorsa mevcut DS kayıtlarının yeni kayıt kuruluşuna taşınmasını planlayın. Yalnızca zincir değişecekse veya kayıtlar taşınamıyorsa kaldırın. |
| Gizlilik / vekil servisi | Vekil iletişim bilgisi, onay verecek kişi ile bildirim arasına girebilir. | İlgili uzantıda servisin yetkilendirmeyi veya onay bildirimlerini etkileyip etkilemediğini kontrol edin; yalnızca kayıt kuruluşu ya da kurumu gerektiriyorsa kapatın. |
| Hesap bakiyesi | Transferler ücretlidir ve başarısız bir ödeme partiyi durdurur. | Premium ve özel uzantılar dahil parti tutarının tamamı için hesabı fonlayın. |
| Uzantıya özel kurallar | Ülke kodu uzantıları belge, yerel varlık veya kurum tarafında ayrı bir onay adımı isteyebilir. | Bu uzantıları ayırın ve her kurumun prosedürünü planlamadan önce teyit edin. |
Birden fazla domain nasıl transfer edilir: adım adım
Aşağıdaki sıra, birden fazla kayıt kuruluşuna dağılmış birkaç yüz domainlik bir portföyü varsayar. Parti büyüklüğünü kendi hacminize göre ayarlayın; sırayı değiştirmeyin.
1. Envanteri çıkarın. Her kayıt kuruluşundan ve her hesaptan listeleri tek bir tabloya aktarın: domain, uzantı, mevcut kayıt kuruluşu, bitiş tarihi, isim sunucuları, DNSSEC durumu, kilit durumu, kayıttaki sahip adresi, iş sahibi ve kritiklik derecesi.
2. Gruplayın. Uzantıya ve mevcut kayıt kuruluşuna göre sıralayın. Bu iki eksen hangi kuralların geçerli olduğunu ve hangi panelde çalışacağınızı belirler, dolayısıyla partilerinizi de belirler.
3. Kritikliğe göre ayırın. Gelir üreten domainler, e-posta taşıyan domainler, yalnızca yönlendirme yapanlar ve savunma amaçlı tesciller ayrı listeler olsun. Son iki grup pilot için idealdir.
4. Engelleri temizleyin. Her grup için kontrol listesini uygulayın: kilidi açın, iletişim bilgisini düzeltin, süresi yaklaşanları yenileyin, kısıt penceresindekileri kenara alın.
5. Pilot parti gönderin. Tek uzantıdan beş on düşük riskli domain. Pilot, kod yönetiminizi, onay bildirimlerinin nereye gittiğini ve takip düzeninizi kritik bir ada dokunmadan test eder.
6. Transfer kodlarını güvenli toplayın. Kodları göndereceğiniz oturumda alın, paylaşılan bir tablo yerine kontrollü bir kasada tutun ve parola gibi davranın.
7. Kademeli gönderin. Uzantı ve kaynak kayıt kuruluşu bazında gruplayın, tek bir sistemsel hatanın yayılmayacağı büyüklükte partiler kurun ve ilk sonuçlara tepki verebilmek için aralarında zaman bırakın.
8. Durumu her gün izleyin. Domain bazında bekleyen, onaylanan ve reddedilen durumları takip edin. Sessizliği ilerleme sanmayın; onay e-postaları çoğu zaman ortak bir kutuda açılmadan bekler.
9. Her parti indiğinde sürekliliği doğrulayın. İsim sunucularını kontrol edin, siteyi açın, e-posta taşıyan domainlerde test mesajı gönderip alın, domain doğrulamasına bağlı sertifika yenilemelerinin çalıştığını teyit edin.
10. Taşıma sonrası denetim yapın. Kilitleri geri kapatın, bitiş tarihlerini ve otomatik yenilemeyi kontrol edin, son domain sayısını ilk envanterle karşılaştırın.
Transfer kodu ve EPP kodu nasıl hazırlanır?
Transfer kodu, talebin meşru olduğunu kanıtlayan bir kimlik bilgisidir. Panellerde ve dokümanlarda farklı adlarla geçer: transfer kodu, EPP kodu, auth code, AuthInfo, güncel ICANN çalışmalarında ise TAC. Hepsi aynı kontrolü ifade eder ve yönetim gereksinimleri aynıdır.
Hacimde üç özellik sorun çıkarır. Kodlar çoğunlukla sürelidir; üç hafta önce hazırlanmış bir tablo kullanacağınız gün kısmen geçersizdir. Bazı kayıt kuruluşları kodu panelde göstermek yerine yalnızca kayıttaki sahip adresine gönderir; bu, takip edilmeyen bir posta kutusunu doğrudan engele çevirir. Ve kodlar büyük küçük harfe duyarlıdır, kopyalarken kırpılan bir karakter ancak kayıt kurumu talebi reddettiğinde fark edilir.
Bu yüzden kodları parola gibi ele alın: kullanacağınız ana yakın alın, paylaşılan bir dokümanda değil kasada saklayın, erişimi taşımayı yürüten ekiple sınırlayın ve transfer bitince silin. Bir portföyün geçerli kod listesi, sızdığında doğrudan bir domain ele geçirme setidir.
Panelden toplu domain transferi nasıl yapılır?
Gönderim, öncesindeki hazırlıktan genellikle daha basittir. Domain Name API bayi panelinde transfer işlemleri Domain Management altında yer alır ve iki sekme iş akışını ayırır: tekil ad için Transfer Sorgulama, parti için Toplu Transfer Sorgulama.
*Domain Name API bayi panelinde toplu transfer sorgulama ekranı: her satırda bir domain ve onun transfer kodu.*
Giriş alanı her satıra bir domain, ardından bir boşluk ve o domainin transfer kodunu bekler. Beklenen format alanın hemen üstünde örneklendiği için hazırlanmış bir liste doğrudan yapıştırılabilir ve sorgu, herhangi bir ücret işlemeden önce çalışır. Bu format hazırlık aşamasında dikkate değer, çünkü envanter tablonuzu nasıl kuracağınızı belirler: domain ile kodunu yan yana sütunlarda ve aynı satır sırasında tutarsanız son ihracat bir yapıştırma işine dönüşür. Parti ve sorgu limitleri panelde gösterilir ve değişebilir; büyük bir portföy planlamadan önce güncel değerleri kendi hesabınızdan teyit edin.
Listeyi yapıştırmadan önce kontrol edilecek beş şey
Hazırlığın kuyruğu uzundur ama az sayıda kontrol, ters gidenlerin çoğunu yakalar.
- Kod hâlâ geçerli mi? Kodlar eskir. Göndereceğiniz gün alın, bir hafta önce değil.
- Kilit gerçekten açık mı? Panel açık diyor olabilir. Karar veren kayıt kurumudur.
- Onay mesajı kime gidiyor? Adres ayrılmış bir çalışana aitse o transfer zaten tıkalıdır.
- Önümüzdeki otuz günde ne bitiyor? Şimdi yenileyin, transfer ortasında değil.
- Hangi domainler e-posta taşıyor? Onlar en sona, küçük bir partide ve izlenerek gider.
Listenin üstünden on dakika geçmek, aksi halde bir hafta peşinde koşacağınız retlerin çoğunu ortadan kaldırır.
Domain transferi neden başarısız olur, nasıl çözülür?
Hatalar sınırlı sayıda kalıba oturur. Tablo, göreceğiniz belirtiyi olası nedene ve çözüme bağlıyor.
| Sorun | Olası neden | Çözüm |
| Talep anında reddediliyor | Transfer kilidi hâlâ açık değil ya da kilit açma kayıt kurumuna yansımamış. | Durumu panelden değil WHOIS veya RDAP üzerinden kontrol edin, kilidi yeniden açıp tekrar gönderin. |
| Transfer kodu geçersiz | Kodun süresi dolmuş, kopyalarken kırpılmış ya da uzantı farklı bir mekanizma kullanıyor. | Kodu yeniden üretin, boşluksuz yapıştırın ve uzantının gerçek gereksinimini teyit edin. |
| Onay mesajı gelmiyor | Kayıttaki adres eski veya filtreleniyor, ya da vekil servis bildirimi yönlendiriyor. | Kaydı güncelleyin, spam karantinasını kontrol edin ve başka bir şey değiştirmeden yeniden gönderim isteyin. |
| 60 gün kısıtı nedeniyle ret | Domain son 60 gün içinde tescil edilmiş, transfer edilmiş veya sahiplik bilgisi değişmiş. | Kısıtın kalkacağı tarihi kaydedin ve domaini sonraki partiye planlayın. |
| Süre bitimine yakın takılma | Domain süreci sırasında dolmuş veya ek süre dönemine girmiş. Uygulama kayıt kuruluşuna ve uzantıya göre değişir. | Önce mevcut kayıt kuruluşunda yenileyin, yenilemenin oturmasını bekleyin, sonra transferi yeniden başlatın. |
| Transfer sonrası domain açılmıyor | Kayıt kurumundaki DS kayıtları imza zinciriyle uyuşmuyor ya da isim sunucuları sıfırlanmış. | İsim sunucularını hemen geri yükleyin, ardından DS kayıtlarını kullanımdaki anahtarlarla uyumlandırın. |
| .tr domain reddediliyor | TRABİS süreci kendi kurallarına göre işler; kilit, kod ve yanıt penceresi ayrı yönetilir. | Mevcut kayıt kuruluşundan kilidi kapattırıp transfer kodunu alın ve talebi kendi akışında takip edin. |
| Tek domainde her şey tıkalı | Domaine bağlı bir uyuşmazlık, mahkeme kararı veya kurum bekletmesi var. | Önce esas meseleyi çözün; uyuşmazlıklı domainler partiden çıkarılmalı. |
| Parti sessizce eksik kalıyor | Gönderilen liste ile gelen liste karşılaştırılmadığı için retler görünmemiş. | Her partiden sonra sayıları karşılaştırın ve her farkı açıklanana kadar açık iş olarak takip edin. |
Domain transferi siteyi, DNS'i ve e-postayı etkiler mi?
Kayıt kuruluşu transferi tescil kaydını taşır, ona bağlı hizmetleri değil. İsim sunucusu delegasyonu normalde taşımadan sağ çıkar; çoğu transferin olaysız geçmesinin sebebi budur. Risk, DNS barındırmanın da eski kayıt kuruluşunda olduğu durumda ortaya çıkar: domain ayrıldığında o ücretsiz bölge silinebilir ve tüm A, MX, TXT ve CNAME kayıtları onunla birlikte gider.
En güvenli sıra iki değişikliği ayırır: önce DNS barındırmayı gideceği yere taşıyın, bölgenin doğru çözümlendiğini doğrulayın, birkaç gün çalışsın, sonra tescili transfer edin. İkisi aynı anda olmak zorundaysa başlamadan önce tüm bölge dosyalarını dışa aktarın ve delegasyonu değiştirmeden önce yeni sağlayıcıda yeniden kurun. Kritik kayıtların TTL değerlerini bir iki gün önceden düşürün; böylece bir hata saatler yerine dakikalar içinde geri alınır.
E-posta ayrı ilgi ister, çünkü oradaki arıza sessizdir. MX kayıtlarının, SPF, DKIM seçicilerinin ve DMARC politikasının birebir yeniden kurulduğunu doğrulayın. Eksik bir DKIM seçicisi postayı durdurmaz; giden mesajların spam klasörüne düşme oranını sessizce artırır ve bir hafta sonra bunun taşımayla ilgisi kolay kolay akla gelmez.
DNSSEC refleksle değil kararla yönetilmeli. DNS sağlayıcısı ve imzalama anahtarları değişmiyorsa kayıt kurumundaki DS kayıtları geçerliliğini korur ve doğru adım, yeni kayıt kuruluşunun bu kayıtları taşıyabildiğini teyit etmektir. DS kayıtlarını kaldırmak yalnızca imza zinciri değişecekse, DNS farklı anahtar kullanan bir sağlayıcıya taşınıyorsa veya yeni kayıt kuruluşu mevcut kayıtları sürdüremiyorsa doğrudur. Bu durumlarda önce kaldırın, eski değerlerin dolaşımdan çıkmasını bekleyin ve taşıma bittikten sonra yeniden imzalayın. Uyuşmayan bir DS kaydı, domaini doğrulama yapan tüm çözümleyiciler için erişilemez hale getirir; bu sürecin en yıkıcı sonucudur.
Büyük domain portföyü taşımasında güvenlik
Taşıma, olağandışı yetkileri tek bir zaman aralığında bir araya toplar: kilidi açılmış domainler, geçerli transfer kodları ve yükseltilmiş hesap erişimi. Bu dönemi yüksek riskli bir pencere olarak yönetin.
- İki faktörlü doğrulamayı hem kaynak hem hedef hesapta işten önce açın, sonra değil.
- Kod talep edebilecek ve kilit açabilecek kişi sayısını sınırlayın, isimli hesaplar kullanın ki işlemler kime ait belli olsun.
- Kodları bir parola kasası üzerinden dağıtın. E-posta ve sohbet kayıtları, kodların geçerlilik süresinden çok daha uzun yaşar.
- Transfer biten her domainin kilidini yeniden kapatın. Taşımadan artakalan açık kilitler kalıcı bir risktir.
- Sizin başlatmadığınız transfer kodu taleplerini izleyin. Taşıma sırasında beklenmedik kod üretimi hemen incelenmelidir.
Taşımayı API ile yürütüyorsanız aynı disiplini kimlik bilgilerine de uygulayın. Domain Name API’nin API anahtarı güvenliği ve erişim hataları dokümanı anahtarların ortam değişkeninde tutulması, IP kısıtlaması, anahtar rotasyonu ve sızma durumunda yapılacakları anlatıyor.
.tr domain transferi: TRABİS kuralları ve gTLD farkı
.com, .net, .org ve yeni nesil uzantılar ICANN Transfer Politikası altında çalışır; yetkilendirme, yanıt süreleri ve ret gerekçeleri akredite kayıt kuruluşları arasında standartlaştırılmıştır. Ülke kodu uzantıları kendi kayıt kurumlarının kurallarına tabidir ve aynı modeli izlemek zorunda değildir.
.tr uzantıları 2022’den bu yana BTK bünyesindeki TRABİS üzerinden yönetiliyor. Süreç pratikte tanıdıktır: mevcut kayıt kuruluşunda transfer kilidi kapatılır, oradan transfer kodu alınır, yeni kayıt kuruluşunda talep açılır ve talep TRABİS aracılığıyla eski kuruluşa iletilir. Ancak yanıt penceresi, onay akışı ve bazı uzantılarda belge gereksinimi gTLD tarafından ayrışır. Bu yüzden .tr portföyünü genel partiden ayırın ve kendi takvimiyle yürütün.
Diğer ülke uzantılarında farklar daha da yapısaldır. Örneğin .uk transferi transfer kodu göndererek değil, domaini yöneten kuruluşu tanımlayan IPS tag değiştirilerek tamamlanır. Bazı kurumlar belge, yerel varlık ya da kendi portalı üzerinden onay ister. Kısıt pencereleri ve yenileme davranışı da değişir. Genel uzantılar büyük partiler halinde taşınır; ülke uzantıları çoğu zaman taşınamaz ve taşınabileceğini varsayarak plan yapmak, taşımaların takvimden sapmasının en yaygın sebebidir.
Transfer sonrası doğrulama listesi
Ekranda tamamlandı yazması, taşımanın bittiği anlamına gelmez. Bu listeyi her parti için, değişiklikler hâlâ tazeyken uygulayın.
- Gelen domain sayısı ile gönderilen sayıyı karşılaştırın, her farkı açıklayın.
- İsim sunucularını, çözümlenen değere göre değil hedeflenen yapılandırmaya göre kontrol edin.
- Yayındaki her domaini açın ve HTTPS üzerinden yükleyin; sertifika doğrulama sorunları burada görünür.
- E-posta taşıyan her domainde test mesajı gönderip alın, SPF, DKIM ve DMARC uyumunu doğrulayın.
- Bitiş tarihlerini kontrol edin. Çoğu genel uzantı transferde bir yıl ekler; bazı ülke uzantıları eklemez.
- Otomatik yenilemeyi tek tip ayarlayın ve hesapta geçerli bir ödeme yöntemi bulunduğunu doğrulayın.
- Transfer kilidini geri açın, gerekiyorsa gizlilik servisini yeniden devreye alın.
- Domain imzalıysa DNSSEC doğrulamasının çalıştığını ve DS kayıtlarının kullanımdaki anahtarlarla uyuştuğunu teyit edin.
- Varlık envanterinizi ve izleme sistemlerinizi yeni sağlayıcıya göre güncelleyin.
Bayiler, ajanslar ve BT ekipleri için toplu transfer
Bayiler ve hosting sağlayıcıları
Sizin darboğazınız genelde transfer mekanizması değil, onay yoludur. Bildirimler kayıttaki sahibe gider; bayi portföyünde bu, mesajı tanımayabilecek son kullanıcı demektir. Parti öncesi bilgilendirin, taşımayı müşteri segmentine göre kademelendirin ve ilk parti inmeden önce fatura entegrasyonunuzu yapılandırın ki yenilemeler kaymasın.
Web ajansları
En dağınık portföyler ajanslara miras kalır: kişisel hesaplarda tutulan domainler, süresi dolmuş müşteri kartları, belirsiz sahiplik. Taşımayı sahiplik kayıtlarını netleştirmek ve müşteri onayını belgelemek için kullanın. Sahipliğini kanıtlayamadığınız hiçbir domain gönderim sonrasına bırakılmamalı.
Kurumsal portföy yöneticileri ve BT birimleri
Sıralama ve kayıt tutmak hızdan önemlidir. Bir değişiklik penceresi tanımlayın, geri dönüş koşullarını yazın ve domain bazında neyin ne zaman değiştiğini kaydedin. Savunma amaçlı ve yönlendirme yapan domainler kontrollü pilot olarak önce gider; marka ve e-posta taşıyan domainler en sona, tek tek izlenerek kalır.
Domain yatırımcıları
Ekonomiyi bitiş tarihi yönetimi ve yenileme fiyatı belirler. Uzantı izin veriyorsa yenileme tarihlerini hizalayın ve park edilmiş ya da gelir üreten yapılandırmanın eski kurulum sökülmeden önce yeniden kurulduğunu doğrulayın.
Bayi paneli mi API mi: taşıma için hangisi?
Birinin diğerine mutlak üstünlüğü yok. Karar, işi ne sıklıkta tekrarlayacağınıza ve ne kadarının güvenle otomatikleştirilebileceğine bağlı.
| Kullanım durumuBayi paneliAPIUygun olan | |||
| Birkaç yüz domainlik tek seferlik taşıma | Yeterli; geliştirme gerekmez | Getirisi maliyetini karşılamaz | Panel |
| Müşteriler için tekrarlayan taşımalar | Tekrarlı ve hataya açık | Tekrarlanabilir ve denetlenebilir | API |
| Karışık ülke uzantısı portföyü | İstisnaları ve manuel adımları iyi taşır | İstisna yönetimi özel kod ister | Panel, standart uzantılarda API |
| Partiler arası durum takibi | Elle karşılaştırma | Programatik sorgulama ve raporlama | API |
| Fatura sistemi senkronizasyonu | Manuel veya dışa aktarma ile | Modül veya entegrasyonla doğal | API veya modül |
| Geliştirici kaynağı olmayan ekip | Hemen kullanılabilir | Mühendislik olmadan uygulanamaz | Panel |
| Taşıma sonrası sürekli portföy yönetimi | Düşük hacimde yeterli | Portföyle birlikte ölçeklenir | API |
Otomasyona gidecekseniz sağlayıcının hız kurallarına ilk satırdan itibaren uyun. Domain Name API’nin API hız limiti, kısıtlama ve toplu kullanım politikası dokümanı gerçek zamanlı çağrıları /api ucunda, otomatik işleri /api-bulk ucunda ayırıyor, API anahtarı başına saniyede bir istek sınırı koyuyor ve HTTP 429 yanıtından sonra beklenen üstel geri çekilme davranışını tanımlıyor. Bu limite uyan bir kuyruğu baştan kurmak, erişim kısıtlandıktan sonra eklemekten ucuzdur.
Domain portföyü taşıması ne kadara mal olur?
Transfer ücreti hesabın en küçük kalemidir ve kararın en sık ona bakılarak verildiği kalemdir. Bunun yerine şunları modelleyin.
- Hedefteki yenileme fiyatları, portföyün tamamı ve gerçekçi bir elde tutma süresi üzerinden. Üç yıllık ölçekte bu kalem diğer hepsini bastırır.
- Uzantı bazında transfer ücretleri. Çoğu genel uzantı transferde bir yıl ekler, bazı ülke uzantıları eklemez.
- Süre engelini kaldırmak için eski kayıt kuruluşunda yapmanız gereken yenilemeler.
- Envanter, düzeltme, gönderim, izleme ve doğrulama için harcanacak insan saati. Birkaç yüz karışık domainde genelde en büyük gerçek maliyet budur.
- Standart fiyat tablolarının dışında kalan premium ve kısıtlı uzantı ücretleri.
Hedefin yayımlanmış domain transfer ve yenileme fiyatlarını yalnızca .com üzerinden değil, portföyünüzdeki uzantılar üzerinden karşılaştırın. Portföyler nadiren fiyat sayfalarının düzenlendiği şekilde oluşur.
Domain Name API ile toplu domain transferi
Domain Name API, ICANN akredite kayıt operatörü Atak Domain altyapısı üzerinde çalışan bir domain bayilik programıdır. Yayımlanmış rakamlarını kendi ihtiyacınızla karşılaştırmakta fayda var: 800’den fazla domain uzantısı, 200’den fazla ülkede 40.000’den fazla aktif bayi ve yirmi yılı aşan sektör deneyimi.
Taşıma özelinde üç şey önemli. Bayi paneli ve REST API’nin ikisi de tescil, transfer, yenileme ve DNS yönetimini kapsıyor; yani portföy ekibe uyan arayüzden taşınabiliyor. WHMCS, WiseCP, HostBill, Blesta ve ClientExec için modüller var; taşıma sırasında faturalamanın bozulmaması gerektiğinde bu belirleyici oluyor. Ve toplu kullanım politikası, izin verilen otomatik hacmi kod yazmadan önce söylüyor, sonra değil.
Bayilik sayfasında ayrıca başka bir platformdan gelen bayilere taşıma desteği verildiği belirtiliyor: domain listesini iletiyorsunuz, transfer kilitlerini açıp transfer kodlarını sağlıyorsunuz, transfer sürecini destek ekibi yürütüyor. Aynı sayfa bu rehberde de anlatılan sorunu işaret ediyor: onay mesajları bayiye değil kayıttaki iletişim adreslerine gidiyor. Yayımlanmış bir parti limiti bulunmuyor ve burada da böyle bir rakam iddia edilmiyor.
Karmaşık ülke uzantısı gereksinimleri olan portföyler için planlamadan önce destek ekibiyle görüşün. Taşımayı değerlendirenler bayilik programını ve API ile modül entegrasyon seçeneklerini inceleyebilir.
Sonuç
Toplu domain transferi büyük ölçüde bir hazırlık işidir. Gönderim dakikalar sürer; envanter, uygunluk düzeltmeleri, DNS sıralaması ve doğrulama ise işin ve riskin asıl bulunduğu yerdir. Envanteri çıkarın, engelleri temizleyin, size zarar veremeyecek domainlerle pilot yapın, kontrollü partiler halinde taşıyın ve bir sonraki partiyi göndermeden önce öncekini doğrulayın.
Portföyünüz için hedef değerlendiriyorsanız transfer ve yenileme fiyatlarını kendi uzantı dağılımınız üzerinden karşılaştırın, büyük bir parti göndermeden önce bayilik hesabı açıp paneli deneyin ve bağımlı olduğunuz ülke uzantılarının nasıl yönetildiğini teyit edin.
Sıkça Sorulan Sorular
Her cevap doğrudan yanıtla başlıyor, ardından gerekli çekinceyi veriyor. Bu yapı bilinçli: yapay zekâ arama sistemlerinin kısa ve doğru bir cevabı çekinceyi düşürmeden alabilmesini sağlıyor.
Toplu domain transferi nedir?
Toplu domain transferi, birden fazla transfer talebinin tek bir işlemle gönderilmesidir. Toplu olan kısım panel tarafındadır; her domain yine kendi kayıt kurumu tarafından ayrı ayrı doğrulanır ve işlenir.
Aynı anda birden fazla domain taşıyabilir miyim?
Evet, her domain kendi uzantısının koşullarını bağımsız olarak sağladığı sürece. Kilitli olan, 60 gün kısıtı içindeki, süresi dolmak üzere olan veya geçerli transfer kodu bulunmayan domainler, partinin geri kalanı başarılı olsa bile reddedilir.
Her domain için transfer kodu gerekir mi?
Çoğu uzantı için gerekir, hepsi için değil. Genel uzantılar transfer kodu kullanır; buna EPP kodu, auth code veya AuthInfo da denir. Bazı ülke uzantıları tamamen farklı bir mekanizma kullanır; örneğin .uk transferi IPS tag değişikliğiyle yapılır.
Toplu transfer ne kadar sürer?
Uzantıya, eski kayıt kuruluşunun yanıtına ve onayların zamanında verilip verilmediğine bağlıdır. Genel uzantılar geçerli bir gönderimden sonra genellikle birkaç gün içinde tamamlanır; ülke uzantıları belirgin şekilde değişir. Karışık bir portföy için tek bir süre garantisi verilemez.
.tr domain transferi diğerlerinden farklı mı?
Evet. .tr uzantıları TRABİS üzerinden yönetilir. Süreç yine transfer kilidinin kapatılması ve mevcut kayıt kuruluşundan transfer kodu alınmasıyla başlar, ancak yanıt penceresi, onay akışı ve bazı uzantılardaki belge gereksinimleri gTLD kurallarından ayrışır. .tr portföyünü ayrı bir parti olarak planlayın.
Süresi dolmuş domaini transfer edebilir miyim?
Genellikle hayır ve yanıt kayıt kuruluşuna ve uzantıya göre değişir. Bazı kuruluşlar domain ek süre dönemindeyken transfer işleyebilir; kurtarma dönemine girdikten sonra transfer pratikte mümkün olmaz. Öngörülebilir yol, önce yenilemektir.
Transfer sitemi etkiler mi?
Tek başına etkilemez. Tescil kaydı taşınır, isim sunucusu delegasyonu normalde olduğu gibi kalır. Risk, DNS bölgesinin de eski kayıt kuruluşunda barındığı durumdadır; domain ayrıldığında o bölge silinebilir. Taşımadan önce bölge dosyalarını dışa aktarın.
Transfer sırasında e-postam durabilir mi?
DNS kayıtları kaybolur veya yanlış yeniden kurulursa evet. MX kayıtları, SPF, DKIM seçicileri ve DMARC politikası birebir yeniden kurulmalıdır. Eksik doğrulama kayıtları postayı genellikle tamamen durdurmaz; spam klasörüne düşme oranını artırır ve bunu fark etmek daha zordur.
Transfer neden başarısız olur?
En sık nedenler: açık kalan transfer kilidi, geçersiz veya süresi dolmuş transfer kodu, takip edilmeyen kayıt adresi, son 60 gün içindeki tescil veya transfer, süre bitimine yakınlık, kurum kaynaklı bekletme durumu ve farklı prosedür kullanan ülke uzantıları.
Toplu göndermek tekil transferleri hızlandırır mı?
Hayır. Toplu gönderim sizin harcadığınız süreyi kısaltır, kayıt kurumundaki işlem süresini değil. Her domain yine kendi takviminde ve kendi uygunluk kurallarına göre değerlendirilir.
Transferden önce domainleri yenilemeli miyim?
Süresi yaklaşanları başlamadan önce yenileyin. Çoğu genel uzantı transfer tamamlandığında bir yıl eklediği için erken yenileme genellikle boşa gitmez ve domainin transfer beklerken dolma riskini ortadan kaldırır.
Transferden önce DNSSEC’i kaldırmam gerekir mi?
Otomatik olarak gerekmez. DNS sağlayıcısı ve imzalama anahtarları değişmiyorsa mevcut DS kayıtları geçerliliğini korur; soru yalnızca yeni kayıt kuruluşunun bu kayıtları taşıyıp taşıyamayacağıdır. DNSSEC’i kaldırıp yeniden kurmak, ancak imza zinciri değişecekse ya da kayıtlar yeni kuruluşta sürdürülemiyorsa doğrudur.
Büyük bir portföy için API şart mı?
Hayır. Birkaç yüz domainlik tek seferlik bir taşımayı bayi paneli rahatlıkla kaldırır. API, taşımalar tekrar ettiğinde, partiler arası durum takibinin programatik olması gerektiğinde veya portföy sonrasında sürekli yönetileceğinde anlamlı hale gelir.
