Nameserver vs Rekod DNS: Memahami Perbezaannya

Pelayan nama menetapkan kuasa, rekod memberikan jawapan

Nameserver berautoriti ialah perkhidmatan yang bertanggungjawab menjawab pertanyaan DNS bagi sesuatu zon. Rekod DNS pula ialah satu maklumat di dalam zon tersebut, seperti alamat pelayan laman web atau destinasi e-mel masuk. Perniagaan boleh mendaftarkan domain melalui sebuah syarikat, mengehos laman melalui syarikat lain dan mengurus DNS melalui penyedia ketiga. Susunan itu tidak bercanggah kerana pendaftaran, kuasa DNS dan penyampaian perkhidmatan ialah tanggungjawab berbeza. Perbezaan ini penting apabila seseorang berkata mahu 'halakan domain'. Tanya sama ada mereka hendak menggantikan nameserver berautoriti atau hanya mengubah rekod tertentu kerana kesan operasinya tidak sama.

Ikuti pertanyaan pelayar sehingga mendapat jawapan

Apabila pelanggan memasukkan domain perniagaan, penyelesai DNS rekursif lazimnya menggunakan maklumat cache atau mengikuti hierarki DNS untuk mencari sumber berautoriti. Delegasi pada zon induk menunjukkan nameserver yang boleh menjawab bagi zon anak. Penyelesai kemudian meminta rekod yang sesuai, biasanya A atau AAAA untuk alamat web, sebelum memulangkan hasil kepada aplikasi. Laman web sebenar dihantar kemudian melalui sambungan berasingan. Oleh itu, pendaftaran domain yang betul sahaja tidak menjamin laman dapat dibuka. Delegasi mesti menuju ke pelayan berautoriti yang berfungsi, dan pelayan itu mesti mempunyai rekod yang diperlukan. Jawapan tersimpan dalam cache juga boleh menyembunyikan perubahan buat sementara waktu.

Pendaftar domain tidak semestinya mengehos DNS

Pendaftar mengurus hubungan pendaftaran dan biasanya menyediakan tetapan nameserver berautoriti untuk domain. Namun pendaftar tidak semestinya menyimpan zon DNS aktif atau mengendalikan laman web perniagaan. Contohnya, sebuah firma Malaysia mungkin membayar pendaftar untuk domain, menggunakan penyedia DNS khusus bagi zon dan mengekalkan laman di syarikat hosting lain. Menukar tetapan nameserver dalam akaun pendaftar boleh mengalihkan keseluruhan delegasi kepada pengendali DNS berbeza. Sebaliknya, menyunting rekod A pada penyedia berautoriti semasa hanya mengubah satu jawapan tanpa semestinya mengubah kuasa DNS. Sahkan nameserver semasa sebelum memilih papan pemuka yang benar-benar mengawal konfigurasi.

Zon ialah himpunan rekod, bukan satu alamat sahaja

Zon DNS menghimpunkan rekod bagi nama di bawah sempadan pentadbiran tertentu. Syarikat kecil mungkin mempunyai rekod domain utama, alias www, rekod pelayan e-mel, rekod teks untuk pengesahan dan autentikasi, serta rekod portal tempahan atau sistem pelanggan. Sesetengah subdomain pula mungkin didelegasikan kepada pengendali lain melalui rekod NS. Oleh itu, perubahan satu alamat laman web tidak sama dengan penggantian kuasa keseluruhan zon. Perbezaan ini membantu pemilik menolak arahan migrasi yang hanya menyebut halaman utama. Inventori yang boleh dipercayai menyenaraikan setiap nama hos, jenis rekod, nilai, TTL, pemilik perkhidmatan dan sebab rekod itu wujud, termasuk rekod yang tidak kelihatan kepada pelawat.

Bandingkan suntingan rekod A dengan pertukaran nameserver

Bayangkan perniagaan memindahkan laman penerangannya ke pelayan hosting lain tetapi mengekalkan platform e-mel yang sama. Jika DNS berautoriti sedia ada masih sesuai, pentadbir lazimnya boleh mengubah rekod A atau AAAA laman dan menyemak konfigurasi www. Rekod MX serta TXT berkaitan e-mel kekal pada tempatnya. Pertukaran nameserver ialah tindakan lebih luas: delegasi induk mula mengarahkan pertanyaan ke zon lain yang kandungannya mungkin berbeza. Jika zon baharu belum mempunyai rekod setara, e-mel, pengesahan, subdomain atau integrasi lain boleh gagal. Memilih perubahan lebih kecil mengurangkan bilangan sistem terlibat, walaupun setiap suntingan DNS tetap memerlukan pelan pemulihan.

Kenal pasti panel kawalan yang berkuasa sebelum menyunting

Panel kawalan hosting mungkin memaparkan rekod DNS walaupun pelayannya bukan sumber berautoriti bagi domain tersebut. Entri itu boleh berguna kepada perisian hosting setempat tetapi tidak semestinya menentukan jawapan DNS awam. Sebaliknya, papan pemuka penyedia DNS berautoriti mungkin berasingan daripada akaun pendaftar dan hosting. Sebelum menyunting, bandingkan nameserver yang diterbitkan melalui delegasi domain dengan nameserver perkhidmatan DNS yang dicadangkan. Kemudian semak rekod semasa terus pada pelayan berautoriti. Catat siapa mempunyai akses dan kelayakan mana yang diluluskan untuk kerja tersebut. Jangan anggap paparan Zone Editor membuktikan trafik awam menggunakan zon itu.

E-mel bergantung pada beberapa jawapan DNS berbeza

Penghantaran e-mel lazimnya bergantung pada rekod MX, manakala pengesahan domain penghantar boleh menggunakan maklumat SPF, DKIM dan DMARC dalam rekod TXT atau nama hos berkaitan. Penyedia peti mel mungkin juga memerlukan rekod penemuan automatik atau pengesahan. Tiada jaminan bahawa butiran tersebut kekal apabila domain mula menggunakan zon berautoriti yang berbeza. Sebelum memindahkan nameserver, dapatkan nilai terkini yang diperlukan daripada penyedia e-mel, catat entri sedia ada dan kenal pasti konfigurasi penghalaan khas. Selepas perubahan, uji mesej masuk dan keluar dengan kebenaran, kemudian periksa hasil autentikasi. Laman yang berjaya dibuka bukan bukti penghalaan e-mel atau kawalan anti-penyamaran masih berfungsi.

Jangan samakan rekod delegasi NS dengan rekod hos biasa

Rekod NS menamakan nameserver bagi zon atau subzon yang didelegasikan; ia bukan bentuk lain bagi rekod A. Pada sempadan induk, delegasi memberitahu penyelesai tempat kuasa DNS berada. Di dalam zon anak pula, rekod memberikan jawapan untuk nama yang diuruskan di situ. Syarikat boleh mendelegasikan subdomain seperti support.example.com kepada pasukan lain tanpa memindahkan kuasa keseluruhan example.com. Susunan tersebut memerlukan konfigurasi zon induk dan anak yang selaras, bukannya rekod NS rawak dalam papan pemuka yang tidak berkaitan. Apabila penyedia meminta 'nameserver', jelaskan sama ada mereka bermaksud delegasi pada pendaftar, delegasi subzon atau sekadar penciptaan nama hos.

Sediakan zon destinasi sebelum mengubah delegasi

Urutan lebih selamat untuk migrasi nameserver terancang ialah menginventori zon semasa, membina zon destinasi, membandingkan rekod diperlukan dan hanya kemudian menjadualkan perubahan delegasi. Sertakan rekod web domain utama dan www, penghalaan e-mel, autentikasi penghantar, semakan pemilikan domain pihak ketiga, penemuan perkhidmatan, sekatan CAA serta subdomain yang didelegasikan. Dokumentasi penyedia DNS menjelaskan bahawa imbasan rekod automatik boleh terlepas entri tertentu. Oleh itu, jangan anggap senarai import atau imbasan sudah lengkap tanpa perbandingan dengan sumber berautoriti lama dan keperluan penyedia. Simpan salinan bertarikh konfigurasi asal sambil mengendalikan nilai sensitif mengikut dasar akses syarikat supaya pemulihan mempunyai input yang jelas.

Eksport zon berguna tetapi bukan audit migrasi lengkap

Sesetengah penyedia DNS membenarkan eksport dan import fail zon gaya BIND, sekali gus mengurangkan kesilapan menyalin secara manual. Eksport merekodkan entri yang diketahui oleh perkhidmatan tersebut pada masa berkenaan; ia tidak semestinya merangkumi pergantungan aplikasi yang tidak didokumenkan, tetapan proksi khusus penyedia atau dasar akses. Rekod yang diimport juga perlu disahkan kerana platform destinasi mungkin mentafsir jenis rekod, alias atau mod proksi secara berbeza. Semak sama ada noktah akhir, nilai TTL, keutamaan rekod dan rentetan teks khusus perkhidmatan dikekalkan dengan betul. Anggap eksport sebagai inventori permulaan dan bandingkan dengan jawapan berautoriti sebenar, bukan bukti semua fungsi perniagaan akan terus berjalan selepas delegasi berubah.

TTL mempengaruhi cache, bukan ketepatan zon

Time to Live atau TTL memberitahu penyelesai berapa lama jawapan DNS boleh disimpan dalam cache. TTL yang lebih rendah pada rekod biasa boleh memendekkan sebahagian tempoh peralihan jika diubah lebih awal, tetapi tidak membaiki rekod MX yang hilang atau delegasi nameserver yang salah. Cache NS pada zon induk dan rekod berkaitan DNSSEC boleh mempunyai pertimbangan masa berbeza daripada rekod A laman web. Tiada satu saat sejagat apabila semua penyelesai terus melupakan jawapan lama. Rancang kemungkinan hasil berbeza sementara cache tamat dan uji melalui lebih daripada satu penyelesai atau rangkaian ketika menyiasat masalah. Jangan menjanjikan tempoh propagasi tetap atau menyamakan cache lama dengan bukti konfigurasi baharu betul.

DNSSEC menambah pergantungan pada delegasi

DNSSEC boleh mengesahkan jawapan DNS melalui rantaian kepercayaan yang merangkumi maklumat Delegation Signer pada zon induk. Jika domain menukar penyedia DNS berautoriti sedangkan maklumat DS lama masih merujuk susunan tandatangan terdahulu, penyelesai yang membuat pengesahan mungkin menolak jawapan walaupun rekod kelihatan betul. Prosedur migrasi yang diperlukan bergantung pada penyedia semasa dan sokongan peralihan berbilang penandatangan. Ikuti urutan DNSSEC yang didokumenkan oleh penyedia dan jangan sekadar menyalin rekod A serta MX yang kelihatan. Catat status DS lama, konfigurasi tandatangan baharu yang dirancang dan ujian pengesahan. Jika pasukan tidak memahami keadaan DNSSEC semasa, tangguhkan migrasi nameserver dan dapatkan semakan teknikal yang layak.

Contoh migrasi PKS Malaysia secara andaian

Bayangkan sebuah firma perunding rekaan di Selangor menggunakan pendaftar domain, hosting laman cPanel dan penyedia e-mel perniagaan berasingan. Pereka mencadangkan pertukaran nameserver untuk mengaktifkan perkhidmatan DNS baharu. Sebelum meluluskan perubahan, pemilik meminta inventori yang menunjukkan laman utama, www, pelayan e-mel, SPF, DKIM, DMARC dan rekod pengesahan sistem tempahan pelanggan. Pasukan mendapati zon destinasi yang dicadangkan hanya mengandungi alamat laman utama. Mereka menambah rekod yang tertinggal, mendokumenkan pasangan nameserver berautoriti, memilih masa perubahan yang kurang sibuk dan menetapkan ujian penerimaan. Contoh ini menggambarkan risiko yang boleh dicegah, bukan dakwaan tentang konfigurasi pelanggan sebenar atau arahan mengubah DNS produksi OnHypp.

Uji laman web tanpa mengabaikan pergantungannya

Selepas perubahan yang dibenarkan, periksa domain tanpa awalan dan hos www serta sahkan kandungan laman yang dijangka, bukan sekadar menerima sebarang respons HTTP yang berjaya. Halaman parkir, hos lama atau pelayan lalai mungkin memberi respons walaupun menunjuk ke destinasi salah. Jika laman menggunakan rangkaian penghantaran kandungan, sahkan tetapan proksi atau DNS sahaja yang dimaksudkan serta tingkah laku sijil berdasarkan dokumentasi penyedia. Uji juga subdomain penting, pengalihan dan mana-mana titik API awam yang bergantung pada DNS dalam skop ujian yang diluluskan. Kaitkan hasil dengan cap masa dan penyelesai yang ditanya supaya penyemak kemudian dapat membezakan bukti daripada kenyataan umum bahawa laman 'berfungsi'.

Sahkan e-mel dan pengesahan pihak ketiga secara berasingan

Senarai semak pertukaran DNS perlu membezakan penerimaan e-mel, penghantaran e-mel dan pengesahan pemilikan domain. Pertanyaan MX membantu mengenal pasti penghalaan masuk tetapi tidak membuktikan peti mel benar-benar menerima mesej. Nilai SPF dan DKIM mungkin wujud namun tidak sejajar dengan perkhidmatan penghantar sebenar; laporan DMARC pula mungkin menunjukkan masalah hanya selepas mesej diproses. Rekod TXT atau CNAME untuk pengesahan domain perisian perniagaan boleh tidak kelihatan kepada pengguna biasa sehingga penyedia menolak akses. Minta pemilik sistem menjalankan ujian fungsi yang dibenarkan bagi setiap pergantungan menggunakan akaun ujian dan data tidak sensitif. Catat kegagalan secara berasingan dan jangan mengisytiharkan seluruh migrasi berjaya hanya kerana satu halaman dibuka.

Gunakan pertanyaan diagnostik untuk membezakan tiga punca kegagalan

Jika domain gagal, tentukan dahulu sama ada delegasi induk menunjukkan nameserver berautoriti yang dijangka. Seterusnya tanya pelayan tersebut secara langsung untuk melihat sama ada zon dan rekod yang dimaksudkan disediakan. Akhir sekali bandingkan jawapan penyelesai rekursif yang mungkin masih menggunakan cache. Ini tiga kategori kegagalan berbeza: delegasi salah, data berautoriti salah dan cache rekursif lama. Arahan seperti dig dengan pertanyaan NS atau jejak boleh membantu pengendali terlatih, manakala papan pemuka penyedia mungkin menawarkan semakan setara. Simpan output yang diperhatikan dan jangan membuat perubahan berdasarkan tekaan. Jika jawapan berautoriti memang salah, menunggu propagasi sahaja tidak akan membaikinya; betulkan konfigurasi sumber melalui proses perubahan yang diluluskan.

Rancang pemulihan mengikut jenis perubahan sebenar

Pemulihan bagi satu rekod A yang tersilap mungkin hanya memerlukan nilai asal dipulangkan pada penyedia berautoriti yang sama. Pemulihan selepas nameserver ditukar mungkin memerlukan delegasi lama dikembalikan dan zon terdahulu terus tersedia sepanjang tempoh cache tamat. Kedua-duanya tidak menjamin pemulihan serta-merta, khususnya jika DNSSEC, tingkah laku proksi khusus penyedia atau perubahan serentak terlibat. Dokumenkan siapa boleh meluluskan pembalikan, tetapan tepat yang disimpan, petunjuk untuk memulakan pemulihan dan cara pemilik sistem e-mel atau aplikasi dimaklumkan. Jangan padam zon lama sebaik sahaja pertukaran dibuat. Pelan pemulihan hanya berguna apabila konfigurasi asal dan kelayakan akses masih tersedia kepada pengendali yang dibenarkan.

Ketahui bila pertukaran nameserver tidak diperlukan

Banyak kerja penyelenggaraan biasa tidak memerlukan perubahan delegasi. Mengemas kini alamat laman, menambah rekod TXT pengesahan, menetapkan pelayan e-mel atau mencipta subdomain sering boleh dilakukan dalam zon berautoriti sedia ada. Pertukaran nameserver mungkin wajar apabila perniagaan sengaja menukar pengendali DNS, menggunakan perkhidmatan yang memerlukan kawalan berautoriti atau menyusun semula zon yang didelegasikan. Bandingkan keupayaan yang dikehendaki dengan perubahan konfigurasi paling kecil yang disokong, implikasi pemilikan dan risiko operasinya. Jika permintaan hanya melibatkan satu nama hos, tanya penyedia sama ada penyelesaian pada peringkat rekod disokong sebelum memindahkan seluruh zon. Sekatan penyedia dan ciri pelan boleh mempengaruhi jawapannya.

Dokumenkan tanggungjawab merentas penyedia dan kakitangan

Rekod pengurusan DNS yang berkekalan perlu mengenal pasti pemegang pendaftaran domain yang sah, penjaga akaun pendaftar, pengendali DNS berautoriti, pentadbir hosting dan pentadbir e-mel. Peranan ini mungkin dipegang oleh individu atau syarikat berlainan. Perniagaan perlu mengekalkan akses kepada akaun pendaftaran, saluran pemulihan dan inventori rekod penting, dengan perubahan direkod serta dibenarkan. Jika kontraktor berhenti, susunan nameserver yang tidak didokumenkan menyukarkan respons insiden walaupun laman kelihatan normal. Simpan rekod serah tugas yang menyatakan lokasi zon berautoriti, siapa boleh mengubahnya, perkhidmatan yang bergantung padanya dan tarikh pengesahan terakhir. Jangan simpan kata laluan atau kunci peribadi dalam artikel awam atau inventori DNS rutin.

Senarai keputusan untuk pemilik perniagaan

Sebelum meluluskan permintaan, dapatkan lima jawapan secara bertulis. Perkhidmatan tepat manakah yang perlu berubah? Siapa sedang mengehos DNS berautoriti? Adakah tindakan dicadangkan berupa suntingan rekod, delegasi subdomain atau penggantian semua nameserver? Rekod laman, e-mel, autentikasi dan pihak ketiga yang manakah mesti terus berfungsi? Bukti serta prosedur pemulihan apakah yang menentukan kejayaan atau kegagalan? Minta nilai sebelum dan selepas, pengendali bertanggungjawab, masa kerja dan semakan pascaperubahan. Jaminan pembekal bahawa 'DNS akan propagate' bukan pengganti inventori. Jika jawapan masih tiada, tangguhkan perubahan sehingga skop jelas dan jangan menganggap DNS sebagai butiran teknikal yang tidak perlu diketahui.

Soalan lazim dan perbezaan utama

Adakah menukar nameserver memindahkan fail laman? Tidak; ia menukar perkhidmatan DNS berautoriti, bukan lokasi fail disimpan. Bolehkah domain menggunakan syarikat lain untuk e-mel? Boleh, dengan syarat zon berautoriti mempunyai rekod e-mel yang diperlukan dan perkhidmatan dikonfigurasi dengan betul. Adakah suntingan rekod DNS mengubah pemilikan domain? Tidak; pendaftaran dan konfigurasi DNS ialah perkara berasingan. Bolehkah subdomain mempunyai nameserver sendiri? Boleh melalui delegasi yang disengajakan daripada zon induk. Pengajaran utamanya ialah menamakan lapisan yang hendak diubah. Suntingan rekod melaraskan satu jawapan dalam zon aktif; pertukaran nameserver memilih kuasa baharu yang mesti disediakan lebih awal untuk menjawab bagi semua perkhidmatan bergantung padanya.

Sumber & bacaan lanjut

Bersedia melihat perkhidmatan berkaitan?

Lihat perkhidmatan OnHypp yang berkaitan dan tentukan sama ada ia sesuai dengan keperluan perniagaan anda.

Domain E-mel & hosting