Cara Memindahkan Domain tanpa Mengganggu Laman Web atau E-mel

Fahami perkara sebenar yang dipindahkan

Pendaftar domain mengurus pendaftaran komersial sesuatu nama. DNS berautoriti menjawab pertanyaan tentang nama tersebut; hosting web menyampaikan halaman; platform e-mel menyimpan dan menghalakan mesej. Menukar pendaftaran daripada satu pendaftar kepada pendaftar lain tidak bermakna tiga perkhidmatan yang lain turut berpindah. Anggap pemindahan pendaftar sebagai pertukaran pihak yang mengurus pendaftaran, bukannya migrasi laman web.

Gangguan lazimnya berpunca daripada perubahan konfigurasi yang berasingan: nameserver diganti tanpa menyalin rekod, akaun hosting tamat, rantaian DNSSEC rosak atau rekod mel tertinggal dalam zon baharu. Syarikat Malaysia yang merancang pemindahan perlu menyenaraikan penyedia bagi setiap fungsi terlebih dahulu. Peta perkhidmatan itu menentukan sama ada pelan paling selamat ialah mengekalkan semua tetapan DNS dan hosting.

Tentukan sebab perniagaan sebelum bermula

Sebab yang munasabah termasuk menyatukan pentadbiran pembaharuan, mengembalikan kawalan akaun pendaftar kepada syarikat, mendapatkan rekod bil yang jelas atau menukar penyedia yang sokongannya tidak lagi sesuai. Harga promosi yang rendah sahaja belum memadai. Bandingkan kadar pembaharuan berikutnya, sokongan sambungan domain, kawalan akses, bantuan pemindahan dan kebolehan mendapatkan rekod akaun.

Jika masalah sebenar ialah hosting laman yang perlahan atau e-mel yang tidak sesuai, pemindahan pendaftar mungkin tidak menyelesaikannya. Hosting dan e-mel selalunya boleh ditukar tanpa memindahkan pendaftaran, manakala penyedia DNS boleh diurus secara berasingan. Pilih masalah yang hendak diselesaikan. Menggabungkan beberapa migrasi menyukarkan siasatan apabila berlaku kegagalan dan menimbulkan kekeliruan tentang pihak yang bertanggungjawab.

Sediakan inventori domain dan perkhidmatan

Catat ejaan penuh domain serta sambungannya, pendaftar, organisasi pemegang pendaftaran, hubungan pentadbiran, tarikh pembaharuan, status pemindahan, nameserver, pengendali DNS, hos web, penyedia e-mel dan perkhidmatan lain yang bergantung pada domain. Masukkan subdomain untuk portal pelanggan, tempahan, pengesahan, panggilan balik pembayaran atau alat kakitangan. Simpan salinan bertarikh dalam ruang yang dikawal syarikat.

Semak jawapan DNS awam dan juga antara muka zon pada penyedia berautoriti. Carian awam mungkin tidak menunjukkan semua rekod, manakala import automatik boleh terlepas entri TXT, SRV atau CAA tertentu. Senaraikan rekod A, AAAA dan CNAME untuk laman; MX dan nama hos mel; SPF, DKIM dan DMARC; token pengesahan; serta butiran delegasi DNSSEC sebelum sesiapa mengubah nameserver.

Asingkan pemilikan daripada akses pentadbiran

Pemegang domain berdaftar sepatutnya entiti perniagaan atau individu yang dibenarkan mengikut peraturan pendaftaran, bukan secara automatik pembangun laman yang menerima bayaran. Semak nama pemegang sah dan sama ada syarikat boleh membuka akaun pendaftar, melihat bil, menerima e-mel kelulusan serta menggunakan kaedah pemulihan. Pemindahan berisiko jika hanya bekas pekerja atau agensi mempunyai akses tersebut.

Tetapkan seorang pemilik proses, seorang pemeriksa teknikal dan seorang hubungan kecemasan. Pemilik proses mengurus kod kebenaran serta kelulusan pendaftar; pemeriksa teknikal menyemak DNS, laman dan e-mel sebelum dan selepas perubahan. Jika tugas dipegang orang yang sama, gunakan senarai semak bertulis bersama masa pemeriksaan. Jangan hantar kod pemindahan dalam tiket terbuka atau kepada pihak yang identitinya belum disahkan.

Semak kelayakan sambungan domain

Peraturan bergantung pada domain peringkat tertinggi. Bagi banyak domain generik, dasar pemindahan ICANN membenarkan penolakan dalam keadaan tertentu, termasuk pendaftaran atau pemindahan yang masih baharu, kunci selepas perubahan pemegang, pertikaian dan sebab lain yang ditakrifkan. Peraturan itu bukan arahan seragam bagi setiap domain kod negara. Minta kedua-dua pendaftar mengesahkan kelayakan sambungan sebenar.

Untuk keluarga domain .my di Malaysia, rujuk dasar pemindahan pendaftar MYNIC dan prosedur terkini pendaftar yang dilantik. MYNIC membezakan pertukaran pendaftar, pertukaran pemegang domain dan pemindahan antara akaun. Jangan anggap semuanya operasi yang sama. Sahkan dokumen kelayakan, had berkaitan tamat tempoh, kuasa hubungan, caj pemindahan dan kesan terhadap tempoh pendaftaran sebelum membuat bayaran atau permohonan.

Periksa tarikh luput dan masa pembaharuan

Domain yang hampir tamat tempoh menambah risiko yang tidak diperlukan. Semak tarikh luput dalam rekod pendaftaran, status invois pendaftar semasa dan tetapan pembaharuan automatik. Tentukan sama ada pemindahan menambah tempoh pendaftaran dan sama ada sambungan tersebut mempunyai pengecualian. Jangan menganggap caj, lanjutan tempoh atau tarikh siap adalah sama bagi .com, .my dan nama lain.

Jika pembaharuan semakin dekat, tanya pendaftar berkaitan sama ada domain patut diperbaharui dahulu dan sama ada tindakan itu mewujudkan sekatan sementara. Simpan bukti pembayaran serta tarikh luput yang baharu. Elakkan pelan yang memerlukan pemindahan selesai beberapa jam sebelum pelancaran pelanggan, pembayaran gaji atau kempen penting. Pemindahan rutin perlu mempunyai ruang masa untuk menangani kegagalan dengan selamat.

Semak kunci dan kod kebenaran pemindahan

Kunci pendaftar ialah kawalan keselamatan, bukan petanda domain rosak. Domain generik mungkin memaparkan status clientTransferProhibited apabila pemindahan disekat. Apabila benar-benar bersedia, pemegang yang sah boleh mengikut prosedur pendaftar untuk membuka kunci dan mendapatkan kod AuthInfo atau EPP yang unik. Pastikan kod masih sah, disalin dengan tepat dan dimasukkan hanya dalam portal selamat pendaftar penerima.

Jangan buka kunci terlalu awal atau simpan kod kebenaran dalam hamparan yang dikongsi ramai. Jika permohonan ditolak, minta status dan alasan dasar yang tepat, bukannya mengubah DNS berulang kali. Di bawah dasar ICANN yang berkuat kuasa, pendaftar berkaitan mempunyai kewajipan tentang akses kepada kod AuthInfo dan penyingkiran sekatan pemindahan; namun sambungan domain serta keadaan khusus tetap menentukan tindakan yang dibenarkan.

Pastikan saluran kelulusan boleh diakses

Permohonan pemindahan mungkin memerlukan tindakan melalui papan pemuka pendaftar atau mesej kepada hubungan pendaftaran. Sebelum memulakan, pastikan peti masuk untuk notis berfungsi dan dipantau. Jika e-mel utama syarikat menggunakan domain yang sama, sediakan hubungan pemulihan atau pentadbiran bebas apabila penyedia membenarkannya; gangguan DNS tidak sepatutnya menyebabkan arahan pemindahan turut hilang.

Berwaspada terhadap pemalsuan mesej. E-mel penipuan boleh menyerupai notis pendaftar sebenar. Buka portal melalui penanda halaman yang diketahui, semak domain dan akaun yang diminta, kemudian sahkan jadual dengan pemilik proses. Catat kelulusan yang diberikan, nama pihak yang meluluskan dan masanya. Jangan anggap ketiadaan balasan atau mesej yang tidak dikenali sebagai bukti pemindahan telah selesai.

Kekalkan nameserver jika DNS tidak perlu berpindah

Bagi pertukaran pendaftar biasa, mengekalkan nameserver berautoriti sedia ada selalunya pilihan paling kurang mengganggu jika disokong kedua-dua pendaftar. Pastikan pendaftar penerima boleh mengekalkan nameserver itu dan perkhidmatan DNS terus aktif secara bebas daripada akaun pendaftar lama. Nilai nameserver boleh kekal sama walaupun perkhidmatan di belakangnya telah dibatalkan; semak juga hubungan langganan.

Jangan menerima nameserver halaman parkir atau zon DNS lalai hanya kerana ia dipaparkan semasa pembayaran. Minta pendaftar penerima menunjukkan nilai delegasi akhir sebelum permohonan dihantar. Bandingkan setiap aksara dengan rekod asal. Jika pendaftar lama turut menyediakan DNS yang akan tamat selepas domain keluar, rancang migrasi DNS yang berasingan dan diuji terlebih dahulu.

Urus pertukaran penyedia DNS sebagai projek lain

Jika perkhidmatan DNS lama tidak boleh diteruskan selepas pemindahan, bina zon pengganti yang lengkap sebelum mengubah delegasi. Salin rekod daripada sumber berautoriti dan semak nama, jenis, nilai, keutamaan, tetapan proksi serta TTL satu demi satu. Teliti rekod subdomain, pengesahan pihak ketiga, pemilih DKIM dan sekatan pihak berkuasa sijil. Imbasan automatik hanya permulaan, bukan sandaran lengkap.

Pilih masa peralihan yang terkawal, kekalkan zon DNS lama semasa tempoh cache berubah dan uji pelayan berautoriti baharu secara langsung. Jangan menukar IP hosting, platform e-mel dan nameserver serentak melainkan terdapat pelan migrasi khusus yang sudah disahkan. Migrasi DNS boleh menjejaskan pelanggan walaupun pemindahan pendaftaran dari sudut pentadbiran telah berjaya.

Fahami TTL dan jawapan yang disimpan dalam cache

Time to live atau TTL menentukan tempoh penyelesai DNS boleh menyimpan sesuatu jawapan dalam cache. Mengurangkan TTL rekod tertentu lebih awal boleh memendekkan tempoh cache bagi perubahan nilai kemudian, tetapi tidak menjadikan pertukaran nameserver serta-merta dan tidak mengatasi jawapan lama yang sudah disimpan. Dokumentasi Cloudflare membezakan TTL rekod biasa daripada tetapan berkaitan nameserver.

Jika pemindahan hanya menukar pendaftar dan mengekalkan semua nameserver serta nilai rekod, mengurangkan setiap TTL biasanya tidak membawa manfaat. Jika DNS perlu ditukar, catat TTL asal, ubah hanya jika disokong dan tunggu tempoh cache lama tamat. Uji melalui lebih daripada satu penyelesai dan rangkaian. Kejayaan pada komputer pejabat tidak membuktikan semua pelanggan telah menerima jawapan terkini.

Anggap DNSSEC sebagai kebergantungan penting

DNSSEC menggunakan tandatangan dan rantaian kepercayaan untuk membantu penyelesai mengesahkan data DNS. Rekod DS pada zon induk boleh menghubungkan domain dengan kunci penyedia DNS berautoriti. Jika nameserver atau kunci tandatangan berubah tanpa penyelarasan rekod DS, penyelesai yang membuat pengesahan mungkin memulangkan SERVFAIL walaupun zon baharu mengandungi rekod A dan MX yang betul.

Jika nameserver dan tetapan tandatangan tidak berubah, elakkan pengubahsuaian DNSSEC yang tidak perlu. Apabila migrasi DNS diwajibkan, ikut turutan DNSSEC yang didokumenkan oleh penyedia lama dan baharu serta tunggu tempoh cache berkaitan. Catat maklumat DS dan DNSKEY semasa, kemudian sahkan resolusi bertandatangan. Mematikan DNSSEC secara sambil lewa boleh mengurangkan perlindungan dan menyembunyikan punca masalah sebenar.

Lindungi penerimaan e-mel perniagaan

Penghantaran e-mel masuk bergantung pada rekod MX domain dan ketersediaan hos mel yang dinamakan. Pemindahan pendaftar tidak menyalin peti mel atau memindahkan mesej tersimpan secara automatik. Jika DNS dan penyedia mel kekal aktif, penghalaan MX sepatutnya tidak berubah; walau bagaimanapun, catat keutamaan MX, rekod A atau AAAA hos mel dan tetapan yang diwajibkan oleh penyedia.

Sebelum dan selepas pemindahan, hantar mesej ujian daripada peti mel luaran yang tidak berkaitan kepada alamat perniagaan terpilih. Sahkan penerimaan, masa penghantaran dan sebarang notis kegagalan. Sertakan alias dan alamat berkongsi jika penting untuk pertanyaan pelanggan. Jika mel gagal, bandingkan jawapan MX semasa dengan konfigurasi rasmi penyedia serta semak sama ada langganan perkhidmatan masih aktif.

Lindungi pengesahan e-mel keluar

SPF, DKIM dan DMARC lazimnya diterbitkan sebagai rekod TXT DNS, kadangkala pada beberapa nama hos. Rekod ini membantu mengesahkan penghantar, tandatangan mesej dan dasar atau laporan domain. Jika pemilih DKIM tertinggal atau rekod SPF bercanggah diterbitkan semasa migrasi DNS, mesej sah syarikat boleh gagal pemeriksaan atau masuk ke folder spam walaupun e-mel masuk kelihatan normal.

Simpan senarai semua sistem penghantar yang dibenarkan: platform peti mel utama, borang laman web, perkhidmatan invois dan penyedia transaksi yang diluluskan. Selepas perubahan DNS, periksa rekod yang diperlukan dan lakukan ujian penghantaran terkawal ke akaun luaran. Jangan menggantikan rekod khusus penyedia dengan templat yang diteka. Pemindahan pendaftar sahaja tidak sepatutnya memerlukan penulisan semula rekod ini.

Lindungi laman web, HTTPS dan subdomain

Catat cara domain utama dan nama hos www mencapai laman, termasuk CDN atau proksi songsang jika digunakan. Pastikan langganan hosting web, aplikasi dan mekanisme pembaharuan sijil TLS terus aktif. Pemindahan domain tidak membina semula laman atau menyalin pangkalan data. Perubahan tidak sengaja pada rekod A, AAAA atau CNAME boleh menghantar pelanggan ke pelayan salah atau halaman sementara.

Uji halaman utama, halaman perkhidmatan penting, sijil HTTPS, ubah hala dan borang contoh tanpa menghantar data sulit pelanggan. Periksa subdomain kritikal secara berasingan; halaman utama yang berfungsi tidak membuktikan portal tempahan atau log masuk kakitangan boleh dicapai. Simpan senarai keputusan yang dijangka bersama tarikh supaya perubahan selepas itu boleh dibandingkan dengan bukti sebenar.

Pilih masa tenang dan rekod keadaan asal

Jadualkan permohonan di luar tempoh perniagaan yang sibuk dan maklumkan pasukan yang bertanggungjawab terhadap laman serta e-mel bahawa perubahan pendaftaran sedang berlaku. Pemindahan boleh mengambil beberapa hari bergantung pada prosedur pendaftaran dan pendaftar. Jangan menjanjikan tiada gangguan; DNS yang stabil mengurangkan risiko tetapi kegagalan penyedia, kelulusan terlepas dan langganan tamat masih boleh berlaku.

Sebelum menghantar permohonan, simpan status pendaftar, delegasi nameserver, jawapan DNS, keputusan ujian mel, ketersediaan laman dan tarikh luput. Nyatakan zon masa bagi cap masa. Tetapkan semakan semasa status masih menunggu dan semakan lanjut selepas selesai. Bukti keadaan asal membantu membezakan masalah baharu daripada gangguan yang sudah wujud sebelumnya.

Hantar permohonan melalui pendaftar penerima

Gunakan proses pemindahan dalam portal sah pendaftar yang dipilih. Masukkan domain tepat, berikan kod kebenaran hanya apabila diminta dan teliti harga, tempoh serta maklumat hubungan yang dipaparkan. Sahkan pendaftar penerima menyokong sambungan domain dan susunan nameserver tersebut. Simpan rujukan pesanan atau transaksi tanpa mendedahkan kata laluan atau kod rahsia dalam dokumen bersama.

Pantau kedua-dua papan pemuka pendaftar dan notis pentadbiran yang disahkan. Sesetengah proses meminta pendaftar lama meluluskan atau melepaskan permohonan, manakala proses lain selesai selepas tempoh menunggu. Pembayaran sahaja bukan bukti kejayaan. Jika proses tergendala, kumpulkan status, masa dan sebab penolakan sebelum menghubungi sokongan. Jangan memulakan permohonan kedua yang mungkin bercanggah.

Pantau tanpa mengubah tetapan lain

Semasa permohonan masih diproses, semak secara berkala bahawa domain menggunakan nameserver dijangka, laman dimuatkan melalui HTTPS dan e-mel ujian boleh dihantar serta diterima. Tujuannya mengesan perubahan tidak dijangka, bukannya mengubah DNS berulang kali. Simpan log ringkas tentang gejala, perkhidmatan terjejas, kaedah ujian dan masa kejadian.

Jika hanya satu penyelesai menunjukkan jawapan lama, bandingkan DNS berautoriti dengan cache sebelum menganggap keseluruhan laman tergendala. Jika banyak penyelesai gagal akibat pengesahan DNSSEC, periksa rantaian DS. Jika laman berfungsi tetapi e-mel gagal, semak MX dan rekod hos mel dahulu. Pemerhatian ini membantu mengarahkan isu kepada penyedia dan pasukan yang betul.

Sediakan pemulihan yang realistik

Pemindahan pendaftar yang sudah selesai mungkin tidak boleh dibalikkan serta-merta melalui pemindahan kedua kerana sesetengah sambungan mempunyai sekatan selepas pemindahan. Oleh itu, pelan pemulihan yang praktikal ialah mengekalkan akses DNS, langganan penyedia dan kelayakan akaun, bukannya mengandaikan pendaftar lama boleh dipulihkan dalam beberapa minit. Catat siapa boleh memulihkan zon, membetulkan delegasi dan menghubungi kedua-dua pendaftar.

Jika permohonan gagal sebelum selesai, biarkan nameserver dan hosting yang berfungsi tanpa perubahan sambil menyelesaikan masalah kelayakan atau kod. Jika DNS berubah tanpa dirancang, pulihkan delegasi atau rekod yang diketahui betul mengikut prosedur penyedia serta ambil kira cache. Jika masalah luput berlaku, utamakan pembaharuan dan pengesahan status pendaftaran, bukan pembelian hosting baharu.

Sahkan kejayaan dan kukuhkan keselamatan akaun

Apabila pendaftar penerima melaporkan pemindahan selesai, sahkan secara bebas pendaftar yang tercatat dalam data pendaftaran jika tersedia, tarikh luput, maklumat pemegang dan delegasi nameserver. Uji semula laman, HTTPS, subdomain penting, mel masuk, mel keluar dan DNSSEC jika diaktifkan. Catat pemeriksaan yang lulus, yang tidak berkaitan dan sebarang ketidakpastian yang belum diselesaikan.

Aktifkan pengesahan pelbagai faktor dan kunci pendaftar yang sesuai pada akaun baharu, semak hubungan pemulihan serta tetapkan peringatan pembaharuan di bawah kawalan syarikat. Simpan invois dan rekod pemindahan dalam sistem dokumen yang diluluskan. Jangan membatalkan langganan DNS atau hosting lama sehingga terbukti ia tidak lagi digunakan oleh mana-mana perkhidmatan penting.

Contoh PKS Malaysia dan senarai keputusan

Bayangkan sebuah studio reka bentuk di Selangor yang menggunakan domain .com.my daripada satu pendaftar, DNS daripada penyedia kedua dan e-mel perniagaan daripada penyedia ketiga. Studio mahu menyatukan bil pembaharuan tetapi tidak mahu menukar laman atau platform mel. Soalan awal ialah sama ada pendaftar baharu boleh mengekalkan nameserver dan sama ada dasar MYNIC membenarkan pemindahan pada tahap pendaftaran semasa.

Pemilik mencatat ketiga-tiga pembekal, menyemak hubungan pentadbiran dan prosedur kod, menguji MX serta laman, kemudian memilih masa di luar tarikh akhir pelanggan. Selepas selesai, pemilik memeriksa pendaftar dan tarikh luput manakala rakan sekerja menguji e-mel luaran serta HTTPS. Jika nameserver atau perkhidmatan DNS perlu ditukar, kerja itu menjadi projek berasingan dengan syarat penerimaan sendiri.

Soalan akhir sebelum menutup kerja

Bolehkah syarikat membuktikan siapa pemegang domain, siapa yang boleh meluluskan pemindahan dan penyedia yang akan mengenakan bil pembaharuan seterusnya? Adakah nameserver berautoriti masih aktif dan adakah pendaftar baharu memaparkan delegasi yang dijangka? Sudahkah laman, penerimaan dan penghantaran e-mel serta subdomain kritikal diuji dari luar rangkaian pejabat? Jawapan ini lebih bermakna daripada satu label pada papan pemuka.

Catat juga perkara yang belum disahkan: peraturan sambungan khusus penyedia, rekod DNS pihak ketiga yang jarang digunakan, harga pembaharuan masa depan atau aplikasi lama yang belum diuji. Minta pakar bertanggungjawab menutup jurang tersebut sebelum menganggap projek diterima sepenuhnya. Pemindahan pendaftar yang berjaya ialah perubahan pentadbiran terkawal dengan bukti, bukan jaminan semua perkhidmatan digital berkaitan sentiasa sihat.

Sumber & bacaan lanjut

Jadikan panduan ini tindakan

Domain E-mel & hosting