Transfer Domain Massal: Panduan Memindahkan Portofolio

Memindahkan satu domain adalah pekerjaan administratif. Memindahkan empat ratus adalah sebuah proyek. Portofolio yang tumbuh bertahun-tahun biasanya tersebar di tiga atau empat registrar dan beberapa akun penagihan, mencampur ekstensi generik dengan ekstensi negara, masing-masing dengan perilaku penguncian dan tanggal kedaluwarsa sendiri. Langkah-langkahnya tidak sulit. Yang sulit adalah menjalankannya dalam urutan yang benar, dalam jumlah besar, tanpa mematikan situs pelanggan atau alur emailnya. Panduan ini membahas persiapan, pelaksanaan, penanganan kegagalan, dan verifikasi yang benar-benar dibutuhkan sebuah migrasi besar.

Apa itu transfer domain massal?

Transfer domain massal memindahkan banyak nama domain dari satu registrar ke registrar lain dalam satu pengiriman terkoordinasi. Setiap domain tetap dibuka kuncinya sendiri, diotorisasi dengan kode transfernya sendiri, dan diproses registri secara terpisah. Karena itu hasilnya ditentukan oleh persiapan: data kontak yang benar, kode yang masih berlaku, dan kelayakan yang sudah diperiksa sebelum dikirim.

Poin utama

Pengiriman massal adalah kemudahan di sisi panel. Registri tetap menilai setiap domain secara terpisah dengan aturannya sendiri.
Sebagian besar migrasi yang gagal kalah di tahap persiapan: kunci masih aktif, kode kedaluwarsa, alamat kontak yang tidak dipantau siapa pun.
Perpindahan registrar tidak memindahkan hosting DNS, situs, maupun email. Itu jalur kerja tersendiri.
Ekstensi negara punya aturannya sendiri: .id dikelola PANDI dan tidak otomatis mengikuti model ICANN.
Mengirim batch besar tidak mempercepat pemrosesan di registri, hanya memangkas waktu kerja Anda.
Batch percontohan berisi lima sampai sepuluh domain berisiko rendah membongkar sebagian besar masalah sebelum menyentuh nama yang menghasilkan pendapatan.

Bagaimana cara kerja transfer domain massal?

Transfer massal adalah pengiriman beberapa permintaan perpindahan registrar sekaligus, entah dengan menempelkan daftar di panel atau lewat rangkaian panggilan API. Penggabungan terjadi di lapisan antarmuka. Di bawahnya, setiap domain menempuh jalur yang sama dengan transfer tunggal: registrar penerima mengirim permintaan ke registri beserta kode transfer, registri memvalidasi kode itu, registrar lama punya jendela waktu tertentu untuk merespons, lalu registri memutuskan untuk domain tersebut. Ada tiga peran yang sebaiknya dibedakan. Registri mengelola ekstensi dan menyimpan catatan resmi. Registrar memegang akreditasi atau kontrak dengan registri itu dan mengajukan permintaan atas nama Anda. Pemegang nama domain adalah pemilik sahnya. Transfer mengganti registrar. Ia tidak mengganti pemegang nama dan tidak memindahkan DNS kecuali Anda melakukannya secara terpisah. Dari sinilah kejutan yang paling sering muncul. Batch berisi 300 domain yang mengembalikan 274 persetujuan dan 26 penolakan bukan berarti gagal sebagian sebagai batch. Ia menghasilkan 26 penolakan terpisah, masing-masing dengan alasan dan solusinya sendiri.

Checklist sebelum transfer domain

Kerjakan poin-poin ini sebelum mengirim apa pun. Hampir semua migrasi yang berantakan bisa dilacak ke satu poin di daftar ini yang dilewati untuk sebagian portofolio.

Pemeriksaan	Mengapa penting	Tindakan
Kunci transfer	Domain yang terkunci akan ditolak registri, tidak peduli bagaimana permintaannya dikirim.	Buka kunci semua domain dalam batch dan pastikan statusnya benar-benar berubah di sisi registri, bukan hanya di panel.
Kode otorisasi yang valid	Sebagian besar ekstensi meminta kode yang bisa diverifikasi registri, dan banyak kode punya masa berlaku terbatas.	Ambil kode mendekati waktu pengiriman, pastikan lengkap, dan minta ulang yang sudah kedaluwarsa.
Data pemegang nama domain	Konfirmasi dan pemberitahuan dikirim ke alamat pemegang nama yang tercatat. Istilahnya bergeser: pekerjaan ICANN saat ini berpusat pada pemegang nama domain, bukan kontak administratif terpisah.	Pastikan alamat itu dibaca orang yang bisa bertindak dan perbaiki sebelum proses dimulai.
Registrasi atau transfer baru	Pada ekstensi generik, kebijakan ICANN umumnya memberlakukan pembatasan 60 hari setelah registrasi, setelah transfer sebelumnya, dan setelah perubahan pemegang nama tertentu.	Tandai domain yang terkena dan jadwalkan ke batch berikutnya alih-alih menerima penolakan.
Kedekatan dengan kedaluwarsa	Domain yang hampir habis masa berlakunya bisa masuk masa tenggang di tengah proses dan mempersulit operasinya.	Perpanjang sebelum migrasi, atau pindahkan nama-nama itu dalam batch terpisah yang dipantau ketat.
Kode status domain	Status penahanan dari registri atau registrar memblokir transfer dan tidak terlihat kalau tidak diperiksa.	Periksa kode status lewat WHOIS atau RDAP dan selesaikan penahanan sebelum mengirim.
DNSSEC	Pada domain yang ditandatangani, validasi rusak bila catatan DS di registri tidak lagi cocok dengan rantai tanda tangan.	Bila penyedia DNS dan kuncinya tidak berubah, rencanakan agar registrar penerima membawa catatan DS yang ada. Hapus hanya bila rantainya berubah atau catatan tidak bisa dipindahkan.
Layanan privasi	Kontak proxy bisa berdiri di antara registri dan orang yang harus menyetujui.	Periksa apakah layanan itu memengaruhi otorisasi atau pesan persetujuan pada ekstensi tersebut, dan matikan hanya bila registrar atau registri mensyaratkannya.
Saldo akun	Transfer berbayar, dan pembayaran yang ditolak menghentikan batch.	Isi saldo akun penerima untuk seluruh batch, termasuk ekstensi premium atau terbatas.
Aturan per ekstensi	Registri negara bisa meminta dokumen, kehadiran lokal, atau langkah persetujuan tambahan.	Pisahkan ekstensi tersebut dan pastikan prosedur tiap registri sebelum menetapkan jadwal.

Cara transfer banyak domain langkah demi langkah

Urutan berikut mengasumsikan portofolio beberapa ratus domain yang tersebar di lebih dari satu registrar lama. Sesuaikan ukuran batch dengan volume Anda, tetapi jangan mengubah urutannya.

Susun inventaris. Ekspor semua registrar dan akun ke satu lembar kerja: domain, ekstensi, registrar saat ini, tanggal kedaluwarsa, name server, status DNSSEC, status kunci, alamat pemegang nama, penanggung jawab bisnis, dan tingkat kekritisan.
Kelompokkan. Urutkan berdasarkan ekstensi dan registrar lama. Dua sumbu ini menentukan aturan mana yang berlaku dan panel mana yang Anda pakai, jadi keduanya menentukan batch Anda.
Pilah berdasarkan kekritisan. Pisahkan domain penghasil pendapatan, domain pembawa email, domain pengalihan saja, dan registrasi defensif yang tidak aktif. Dua kelompok terakhir adalah kandidat ideal untuk percontohan.
Bereskan penghambat. Jalankan checklist untuk tiap kelompok: buka kunci, perbaiki data kontak, perpanjang yang mendekati kedaluwarsa, dan sisihkan yang masih dalam masa pembatasan.
Jalankan batch percontohan. Lima sampai sepuluh domain berisiko rendah dari satu ekstensi. Percontohan menguji cara Anda menangani kode, jalur konfirmasi, dan pelaporan status sebelum kesalahan menyentuh sesuatu yang penting.
Kumpulkan kode dengan aman. Ambil kode pada sesi yang sama saat Anda akan mengirim, simpan di penyimpanan terkendali alih-alih spreadsheet bersama, dan perlakukan seperti kredensial.
Kirim bertahap. Kelompokkan menurut ekstensi dan registrar lama, jaga ukuran batch cukup kecil agar satu kesalahan sistemik tetap terkurung, dan beri jeda antar batch.
Pantau status setiap hari. Catat status menunggu, disetujui, dan ditolak per domain. Sunyi bukan berarti maju: konfirmasi sering menumpuk tanpa dibuka di kotak masuk bersama.
Verifikasi kesinambungan setiap batch selesai. Cek name server, buka situsnya, kirim dan terima pesan uji pada domain pembawa email, dan pastikan perpanjangan sertifikat yang bergantung pada validasi domain masih berjalan.
Tutup dengan audit. Kunci kembali, periksa tanggal kedaluwarsa dan perpanjangan otomatis, lalu cocokkan jumlah akhir dengan inventaris awal.

Kode otorisasi dan kode EPP: cara menyiapkannya

Kode transfer adalah kredensial yang membuktikan permintaan itu sah. Ia muncul dengan beberapa nama di berbagai panel dan dokumentasi: kode otorisasi, kode EPP, AuthInfo, dan dalam pekerjaan ICANN terkini disebut Transfer Authorization Code atau TAC. Semuanya merujuk kontrol yang sama dan cara menanganinya identik. Tiga sifat menyebabkan sebagian besar kegagalan pada volume besar. Kode sering punya masa berlaku, jadi spreadsheet yang disusun tiga minggu sebelumnya sudah sebagian tidak berguna pada hari pengiriman. Sebagian registrar hanya mengirim kode ke alamat pemegang nama alih-alih menampilkannya di panel, sehingga kotak masuk yang tidak dipantau berubah menjadi penghalang keras. Dan kode membedakan huruf besar-kecil serta cukup panjang sehingga karakter yang terpotong saat menyalin baru ketahuan ketika registri menolak. Perlakukan seperti kata sandi: ambil mendekati waktu pakai, simpan di pengelola rahasia bukan dokumen bersama, batasi aksesnya pada tim migrasi, dan hapus setelah transfer selesai. Daftar kode aktif untuk satu portofolio penuh, bila bocor, adalah perangkat siap pakai untuk membajak domain.

Cara melakukan transfer domain massal lewat panel

Mengirim biasanya lebih sederhana daripada persiapan sebelumnya. Di panel reseller Domain Name API, transfer berada di bawah Domain Management, dengan dua tab yang memisahkan alurnya: kueri untuk satu nama dan kueri transfer massal untuk satu batch.

Kueri transfer massal di panel Domain Name API: satu domain dan kode transfernya pada tiap baris. Kolom isian menunggu satu domain per baris, diikuti spasi dan kode transfer domain tersebut. Pola yang diharapkan ditampilkan tepat di atas kolom, jadi daftar yang sudah disiapkan bisa ditempel langsung, dan kuerinya berjalan sebelum ada yang terikat. Format ini penting sejak tahap persiapan karena menentukan cara Anda menyusun lembar inventaris: letakkan domain dan kodenya di kolom bersebelahan dengan urutan baris yang sama, maka ekspor akhirnya menjadi pekerjaan tempel, bukan pekerjaan pencocokan. Batas ukuran batch dan kueri ditampilkan di panel dan bisa berubah, jadi pastikan angka yang berlaku di akun Anda sendiri sebelum merencanakan portofolio besar.

Lima hal yang perlu dicek sebelum menempel daftar

Persiapan punya ekor panjang, tetapi sedikit pemeriksaan menangkap hampir semua yang bisa keliru.

Apakah kodenya masih hidup? Kode menua. Ambil pada hari pengiriman, bukan seminggu sebelumnya.
Apakah kuncinya benar-benar terbuka? Panel bilang terbuka. Yang memutuskan adalah registri.
Siapa yang menerima konfirmasi? Kalau itu mantan karyawan, transfer tersebut sudah tersumbat.
Apa yang kedaluwarsa dalam tiga puluh hari ke depan? Perpanjang sekarang, bukan di tengah transfer.
Nama mana yang membawa email? Yang itu berangkat terakhir, dalam batch kecil, dan diawasi.

Kenapa transfer domain gagal dan bagaimana mengatasinya?

Kegagalan berkumpul dalam sedikit pola. Tabel berikut menghubungkan gejala yang terlihat dengan penyebab yang mungkin dan tindakan yang menyelesaikannya.

Masalah	Kemungkinan penyebab	Penyelesaian
Permintaan langsung ditolak	Kunci transfer masih aktif, atau pembukaan kunci belum sampai ke registri.	Cek status lewat WHOIS atau RDAP alih-alih panel, buka kunci lagi, lalu kirim ulang.
Kode otorisasi tidak valid	Kode kedaluwarsa, terpotong saat disalin, atau ekstensinya memakai mekanisme lain.	Buat ulang kode, tempel tanpa spasi, dan pastikan persyaratan sebenarnya dari ekstensi itu.
Pesan konfirmasi tidak datang	Alamat tercatat sudah usang atau tersaring, atau layanan privasi mengalihkan pemberitahuan.	Perbarui datanya, cek karantina spam, dan minta kirim ulang sebelum mengubah hal lain.
Ditolak karena pembatasan 60 hari	Domain baru didaftarkan, ditransfer, atau berganti pemegang nama dalam 60 hari terakhir.	Catat tanggal pembatasan berakhir dan jadwalkan domain ke batch berikutnya.
Transfer tersendat dekat kedaluwarsa	Domain kedaluwarsa atau masuk masa tenggang saat proses berjalan. Perlakuannya berbeda antar registrar dan ekstensi.	Perpanjang di registrar lama, biarkan perpanjangan mengendap, lalu mulai ulang transfer.
Domain tidak bisa diakses setelah transfer	Catatan DS tidak lagi cocok dengan rantai tanda tangan, atau name server tereset.	Kembalikan name server segera, lalu selaraskan catatan DS dengan kunci yang benar-benar dipakai.
Ditolak pada ekstensi negara	Ekstensi itu memakai prosedur sendiri, bukan kode otorisasi standar.	Ikuti prosedur yang diterbitkan registri tersebut, yang bisa menuntut dokumen atau persetujuan tambahan.
Satu domain menyumbat semuanya	Ada sengketa, putusan pengadilan, atau penahanan registri pada nama tersebut.	Selesaikan dulu persoalan pokoknya; domain bersengketa jangan dimasukkan ke batch.
Batch diam-diam tidak lengkap	Penolakan tidak terlihat karena tidak ada yang mencocokkan daftar terkirim dengan daftar diterima.	Cocokkan jumlahnya setelah tiap batch dan perlakukan selisih apa pun sebagai butir terbuka.

Apakah transfer domain memengaruhi DNS, situs, dan email?

Transfer registrar memindahkan catatan registrasi, bukan layanan yang menempel padanya. Delegasi name server umumnya selamat melewati perpindahan, dan itulah sebabnya kebanyakan transfer terasa tanpa kejadian. Risikonya muncul ketika registrar lama juga menyediakan hosting DNS, karena zona itu bisa dihapus setelah domain pergi dan membawa serta setiap catatan A, MX, TXT, dan CNAME. Urutan yang aman memisahkan dua perubahan itu: pindahkan dulu hosting DNS ke tujuan akhirnya, pastikan zonanya resolve dengan benar, biarkan berjalan beberapa hari, baru transfer registrasinya. Kalau keduanya harus bergerak bersamaan, ekspor semua berkas zona sebelum mulai dan bangun ulang di penyedia baru sebelum mengalihkan delegasi. Turunkan nilai TTL catatan penting satu atau dua hari sebelumnya, supaya kesalahan bisa dikoreksi dalam hitungan menit, bukan jam. Email pantas mendapat perhatian sendiri karena kegagalannya sunyi. Pastikan catatan MX, SPF, selektor DKIM, dan kebijakan DMARC direproduksi persis. Selektor DKIM yang hilang tidak menghentikan email; ia diam-diam menaikkan porsi pesan keluar yang mendarat di folder spam, dan seminggu kemudian tidak ada yang mengaitkannya dengan migrasi. DNSSEC menuntut keputusan, bukan refleks. Bila penyedia DNS dan kunci penandatanganan tidak berubah, catatan DS di registri tetap sah dan tugasnya hanya memastikan registrar penerima bisa membawanya. Menghapus catatan DS baru tepat bila rantai tanda tangan akan berubah, bila DNS pindah ke penyedia dengan kunci berbeda, atau bila registrar penerima tidak bisa memelihara catatan itu. Dalam kasus tersebut, hapus dulu, biarkan nilai lama kedaluwarsa, lalu tandatangani ulang setelah migrasi. Catatan DS yang tidak cocok membuat domain tidak terjangkau oleh semua resolver yang memvalidasi, dan itu hasil paling merusak dalam keseluruhan proses.

Keamanan transfer untuk portofolio domain besar

Migrasi memusatkan hak istimewa yang tidak biasa dalam satu jendela waktu: domain terbuka kuncinya, kode transfer yang masih berlaku, dan akses akun yang ditinggikan. Perlakukan periode ini sebagai masa berisiko tinggi.

Aktifkan autentikasi dua faktor di akun lama dan akun baru sebelum mulai, bukan sesudah.
Batasi siapa yang boleh meminta kode atau membuka kunci, dan pakai akun bernama agar tindakan bisa ditelusuri.
Bagikan kode lewat pengelola kata sandi. Utas email dan obrolan bertahan jauh lebih lama daripada masa berlaku kode.
Kunci kembali setiap domain begitu transfernya selesai. Portofolio yang dibiarkan terbuka setelah migrasi adalah risiko permanen.
Awasi permintaan kode yang bukan Anda mulai. Pembuatan kode yang tak terduga selama migrasi layak diperiksa segera.

Bila migrasi Anda berbasis API, terapkan disiplin yang sama pada kredensial. Panduan Domain Name API tentang keamanan kunci API dan kesalahan akses membahas penyimpanan kunci di variabel lingkungan, pembatasan IP, rotasi kunci, dan langkah bila kunci bocor.

Transfer domain .id: aturan PANDI dibanding gTLD

Ekstensi generik seperti .com, .net, dan .org berjalan di bawah Kebijakan Transfer ICANN, yang menyeragamkan otorisasi, tenggat respons, dan alasan penolakan di antara registrar terakreditasi. Registri negara diatur aturannya sendiri dan tidak wajib mengikuti model itu. Domain .id dikelola PANDI, dan perpindahan registrar mengikuti prosedur yang ditetapkan registri tersebut. Yang membedakan .id dari ekstensi generik adalah sebagian nama tingkat kedua, seperti .co.id, memiliki syarat kepemilikan dan dokumen pendukung tersendiri, sehingga data pemegang nama harus rapi sebelum permintaan diajukan. Jalankan blok .id sebagai jalur kerja terpisah dengan jadwalnya sendiri dan pastikan prosedur yang berlaku sebelum menetapkan tanggal. Pada ekstensi negara lain perbedaannya lebih struktural lagi. Transfer .uk diselesaikan dengan mengubah tag IPS yang menandai registrar pengelola, bukan dengan mengirim kode. Registri lain meminta dokumen, kehadiran lokal, atau persetujuan di portal mereka sendiri. Ekstensi generik bergerak dalam batch besar; ekstensi negara biasanya tidak, dan merencanakan seolah-olah bisa adalah penyebab paling umum sebuah migrasi meleset dari jadwal.

Setelah transfer: checklist verifikasi

Status selesai pada sebuah transfer tidak sama dengan migrasi yang selesai. Kerjakan daftar ini per batch, selagi perubahan masih cukup segar untuk dikaitkan.

Cocokkan jumlah domain yang diterima dengan jumlah yang dikirim, dan jelaskan setiap selisih.
Verifikasi name server terhadap konfigurasi yang dimaksudkan, bukan terhadap apa yang kebetulan resolve.
Resolve setiap hostname produksi dan buka situsnya lewat HTTPS untuk menangkap masalah validasi sertifikat.
Kirim dan terima pesan uji pada setiap domain pembawa email, lalu periksa keselarasan SPF, DKIM, dan DMARC.
Periksa tanggal kedaluwarsa. Sebagian besar ekstensi generik menambah satu tahun saat transfer; sebagian ekstensi negara tidak.
Atur perpanjangan otomatis secara seragam dan pastikan ada metode pembayaran yang sah pada akun.
Aktifkan kembali kunci transfer dan, bila relevan, pulihkan layanan privasi.
Bila domain sebelumnya ditandatangani, pastikan DNSSEC tervalidasi dan catatan DS cocok dengan kunci yang dipakai.
Perbarui daftar aset dan sistem pemantauan agar mengarah ke penyedia baru.

Panel reseller atau API: mana yang dipakai untuk migrasi

Tidak ada yang secara mutlak lebih baik. Pilihannya bergantung pada seberapa sering Anda mengulang pekerjaan ini dan seberapa banyak bagiannya yang bisa diotomasi dengan aman.

Kasus penggunaan	Panel reseller	API	Paling cocok
Migrasi sekali jalan di bawah beberapa ratus domain	Memadai, tanpa kerja pengembangan	Bebannya melebihi manfaatnya	Panel
Migrasi berulang untuk pelanggan	Berulang dan rawan salah	Bisa diulang dan diaudit	API
Portofolio campuran dengan ekstensi negara	Menangani pengecualian dan langkah manual dengan baik	Pengecualian butuh logika khusus	Panel, dengan API untuk ekstensi standar
Pelacakan status antar batch	Pencocokan manual	Polling dan pelaporan terprogram	API
Sinkronisasi dengan sistem penagihan	Manual atau lewat ekspor	Native lewat modul atau integrasi	API atau modul
Tim tanpa sumber daya pengembang	Langsung bisa dipakai	Tidak mungkin tanpa rekayasa	Panel
Operasi portofolio berkelanjutan setelah migrasi	Cukup pada volume kecil	Ikut menskala bersama portofolio	API

Bila Anda mengotomasi, hormati aturan laju penyedia sejak baris kode pertama. Domain Name API menerbitkan kebijakan batas laju, throttling, dan penggunaan massal API yang memisahkan panggilan waktu nyata di /api dari pekerjaan otomatis di /api-bulk, menetapkan batas satu permintaan per detik per kunci API, dan menjelaskan mundur eksponensial yang diharapkan setelah respons HTTP 429. Membangun antrean yang menghormati batas itu sejak awal lebih murah daripada menambahkannya setelah akses dibatasi.

Transfer domain massal dengan Domain Name API

Untuk migrasi, tiga hal yang relevan. Panel reseller dan REST API sama-sama mencakup registrasi, transfer, perpanjangan, dan pengelolaan DNS, sehingga portofolio bisa dipindahkan lewat antarmuka mana pun yang cocok untuk tim. Tersedia modul untuk WHMCS, WiseCP, HostBill, Blesta, dan ClientExec, yang menentukan ketika penagihan pelanggan tidak boleh terputus. Dan kebijakan penggunaan massal yang diterbitkan memberi tahu laju otomatis yang diizinkan sebelum Anda menulis kode, bukan sesudah. Halaman resellernya juga menyebut bahwa reseller yang pindah dari platform lain dibantu proses migrasinya: Anda menyediakan daftar domain, membuka kunci transfer, dan memberikan kode transfer, lalu tim dukungan yang menjalankan proses transfernya. Halaman yang sama menunjuk persoalan yang sudah dibahas di panduan ini, yaitu pesan persetujuan sampai ke kontak yang tercatat dan bukan ke reseller. Tidak ada batas ukuran batch yang dipublikasikan, dan di sini pun tidak ada angka yang diklaim. Domain Name API adalah program reseller yang berjalan di atas infrastruktur registrar terakreditasi ICANN, Atak Domain. Angka yang dipublikasikannya layak dibandingkan dengan kebutuhan Anda: akses ke lebih dari 800 ekstensi domain, lebih dari 40.000 reseller aktif di lebih dari 200 negara, dan pengalaman lebih dari dua dekade di industri domain. Untuk portofolio dengan kebutuhan ekstensi negara yang rumit, bicarakan dulu dengan tim dukungan sebelum menetapkan jadwal. Yang sedang menimbang perpindahan bisa menelaah program reseller dan pilihan integrasi API serta modul.

Penutup

Transfer domain massal sebagian besar adalah latihan persiapan. Pengirimannya makan waktu beberapa menit; inventaris, pembersihan penghambat, urutan perubahan DNS, dan verifikasi adalah tempat pekerjaan dan risikonya berada. Susun inventarisnya, bereskan penghambatnya, uji coba dengan nama yang tidak bisa merugikan Anda, pindahkan dalam batch terkendali, dan verifikasi tiap batch sebelum mengirim berikutnya. Kalau Anda sedang menilai tujuan untuk memindahkan portofolio, bandingkan harga transfer dan perpanjangan berdasarkan komposisi ekstensi Anda yang sebenarnya, buka akun reseller dan coba panelnya sebelum mengirim batch besar, lalu pastikan bagaimana penyedia itu menangani ekstensi negara yang Anda andalkan.

Pertanyaan yang sering diajukan

Setiap jawaban dibuka dengan jawaban langsung, lalu menambahkan kualifikasi yang diperlukan. Struktur ini disengaja: mesin jawaban bisa mengambil jawaban pendek yang benar tanpa kehilangan catatan pentingnya.

Apa itu transfer domain massal?

Transfer domain massal adalah pengiriman beberapa permintaan perpindahan registrar sekaligus dalam satu operasi. Penggabungan terjadi di antarmuka; setiap domain tetap divalidasi dan diproses registrinya masing-masing secara terpisah.

Bisakah saya mentransfer banyak domain sekaligus?

Bisa, asalkan tiap domain secara mandiri memenuhi syarat ekstensinya. Domain yang terkunci, yang berada dalam masa pembatasan, yang mendekati kedaluwarsa, dan yang tidak punya kode valid akan ditolak meski sisa batch berhasil.

Apakah setiap domain butuh kode otorisasi?

Sebagian besar ekstensi memerlukannya, tetapi tidak semua. Ekstensi generik memakai kode transfer yang di berbagai sumber disebut kode otorisasi, kode EPP, AuthInfo, atau TAC. Sebagian ekstensi negara memakai mekanisme lain sama sekali, misalnya .uk dengan perubahan tag IPS.

Berapa lama transfer massal berlangsung?

Bergantung pada ekstensinya, respons registrar lama, dan apakah konfirmasi ditindaklanjuti tepat waktu. Ekstensi generik biasanya selesai dalam beberapa hari setelah permintaan yang sah; ekstensi negara sangat bervariasi. Tidak ada penyedia yang bisa menjamin satu tenggat untuk portofolio campuran.

Apakah transfer domain .id berbeda?

Ya. Domain .id dikelola PANDI dengan prosedur registrinya sendiri, dan sebagian nama tingkat kedua seperti .co.id punya syarat kepemilikan serta dokumen pendukung tersendiri. Rapikan data pemegang nama lebih dulu dan jalankan blok .id sebagai batch terpisah.

Bisakah domain yang sudah kedaluwarsa ditransfer?

Umumnya tidak, dan jawabannya bergantung pada registrar dan ekstensinya. Sebagian registrar masih memproses transfer selama domain berada di masa tenggang; setelah masuk masa penebusan, transfer praktis tidak tersedia. Memperpanjang lebih dulu adalah jalur yang dapat diprediksi.

Apakah transfer memengaruhi situs saya?

Tidak dengan sendirinya. Catatan registrasi berpindah, delegasi name server biasanya tetap. Risikonya muncul bila zona DNS dihosting di registrar lama, karena zona itu bisa dihapus setelah domain pergi. Ekspor berkas zona sebelum migrasi.

Bisakah email mati saat transfer?

Bisa, bila catatan DNS hilang atau dibangun ulang dengan keliru. Catatan MX, SPF, selektor DKIM, dan kebijakan DMARC harus direproduksi persis. Catatan autentikasi yang hilang jarang menghentikan email sepenuhnya; ia menaikkan penempatan ke spam, yang lebih sulit disadari.

Kenapa transfer gagal?

Yang paling sering: kunci transfer masih aktif, kode tidak valid atau kedaluwarsa, alamat tercatat yang tidak dipantau, registrasi atau transfer dalam 60 hari terakhir, kedekatan dengan kedaluwarsa, penahanan dari registri atau registrar, dan ekstensi negara dengan prosedur berbeda.

Apakah pengiriman massal mempercepat tiap transfer?

Tidak. Penggabungan memangkas waktu kerja Anda, bukan waktu pemrosesan registri. Setiap domain tetap dinilai menurut jadwalnya sendiri dan aturannya sendiri.

Perlukah memperpanjang domain sebelum transfer?

Perpanjang yang mendekati kedaluwarsa sebelum mulai. Sebagian besar ekstensi generik menambah satu tahun ketika transfer selesai, jadi perpanjangan lebih awal jarang terbuang dan menghilangkan risiko domain kedaluwarsa saat permintaan masih berjalan.

Apakah DNSSEC harus dilepas sebelum transfer?

Tidak otomatis. Bila penyedia DNS dan kuncinya tidak berubah, catatan DS yang ada tetap sah dan pertanyaannya hanya apakah registrar penerima bisa membawanya. Melepas lalu memasang ulang baru diperlukan bila rantai tanda tangan berubah atau catatan itu tidak bisa dipelihara di sana.

Apakah API wajib untuk portofolio besar?

Tidak. Migrasi sekali jalan untuk beberapa ratus domain masih nyaman lewat panel. API mulai sepadan ketika migrasi berulang, ketika pelacakan status antar batch harus terprogram, atau ketika portofolio akan dikelola terus-menerus setelahnya.