DNS ialah direktori, bukan laman web itu sendiri
Sistem Nama Domain membantu perisian mencari destinasi rangkaian yang berkaitan dengan nama mudah dibaca manusia. Perniagaan mungkin memiliki contoh.com, menghoskan laman pada satu perkhidmatan dan menerima e-mel melalui perkhidmatan lain. Rekod DNS menerangkan cara perkhidmatan tersebut ditemui; ia tidak menyimpan halaman laman atau kandungan peti mel. Pendaftaran domain, perkhidmatan DNS autoritatif, pelayan web dan pembekal e-mel boleh menjadi empat hubungan komersial berasingan. Sebelum mengubah apa-apa, kenal pasti syarikat yang mengurus setiap lapisan. Rekod DNS yang betul diperlukan untuk banyak sambungan, tetapi ia tidak boleh membaiki aplikasi gagal atau akaun hosting yang belum dibayar.
Mulakan dengan pelayan nama autoritatif
Pendaftar menyimpan pendaftaran domain dan mewakilkan DNS melalui tetapan pelayan nama. Pembekal DNS autoritatif ialah tempat rekod zon aktif diterbitkan. Jika pendaftar menunjuk kepada pelayan nama Cloudflare, menyunting zon berasingan dalam akaun cPanel lama mungkin tidak memberi kesan awam. Sebaliknya, jika pendaftar masih mewakilkan kepada pembekal hosting, rekod yang ditaip dalam zon Cloudflare yang tidak digunakan tidak akan menjawab pertanyaan biasa. Sahkan pelayan nama sebenar dahulu, kemudian gunakan antara muka pengurusan DNS yang sepadan. Rekodkan konfigurasi terdahulu sebelum perubahan kerana pertukaran pelayan nama boleh mempengaruhi resolusi laman dan e-mel.
Rekod A menghubungkan nama kepada alamat IPv4
Rekod A memetakan nama hos kepada alamat IPv4. Perniagaan mungkin menggunakan satu rekod A bagi domain utama dan satu lagi bagi subdomain tertentu, bergantung pada susunan hosting. Nilai rekod mestilah destinasi betul yang diberikan pembekal hosting, bukannya alamat yang diteka daripada tangkapan skrin pelayar. Apabila laman berpindah pelayan, rekod A mungkin perlu dikemas kini selepas pelayan baharu disediakan dan diuji. Rekod A tidak dengan sendirinya mengaktifkan HTTPS, mengkonfigurasi aplikasi atau mewujudkan peti mel e-mel. Sahkan alamat terhasil melalui carian DNS luaran dan kemudian uji perkhidmatan sebenar.
Rekod AAAA mengurus destinasi IPv6
Rekod AAAA mempunyai tujuan serupa dengan rekod A tetapi memberikan alamat IPv6. Sesetengah platform hosting menyokong IPv4 dan IPv6, manakala yang lain menyediakan satu keluarga alamat sahaja. Menambah rekod AAAA semata-mata kerana ia kelihatan moden boleh menyebabkan sambungan tidak konsisten jika destinasi sebenarnya tidak menyediakan laman. Tanya pembekal sama ada IPv6 disokong dan alamat mana perlu diterbitkan. Ketika menyelesaikan masalah, bandingkan jawapan A dan AAAA secara berasingan; pelayar mungkin memilih salah satu laluan. Jika satu keluarga alamat masih menuju pelayan lama, pengguna boleh melihat hasil berbeza walaupun domain utama kelihatan betul.
Rekod CNAME menunjuk satu nama hos kepada nama lain
Rekod CNAME mengenal pasti nama hos lain sebagai sasaran kanonik bagi sesuatu nama. Ia kerap digunakan untuk www, subdomain pengesahan atau perkhidmatan yang alamat IP asasnya mungkin berubah. Sasaran mestilah nama hos, bukan alamat IP. CNAME biasa juga mempunyai aturan keserasian dengan rekod lain pada nama sama; sesetengah pembekal melaksanakan teknik flattening khas bagi domain utama. Jangan menggantikan rekod MX atau TXT dengan CNAME hanya kerana destinasi kelihatan serupa. Salin nama dan sasaran tepat daripada arahan perkhidmatan serta sahkan pembekal DNS menyokong susunan yang dimaksudkan.
Rekod MX menentukan destinasi e-mel masuk
Rekod Mail Exchange mengenal pasti pelayan yang menerima e-mel bagi domain. Rekod ini mengandungi keutamaan dan nama hos, bukannya kandungan peti mel. Syarikat yang menggunakan Microsoft 365, Google Workspace atau e-mel cPanel memerlukan nilai MX yang sesuai dengan pembekal sebenar. Jangan menyalin contoh umum ke zon produksi; nilai dan keutamaan khusus pembekal boleh berbeza. Mengubah MX tanpa pelan migrasi boleh menghantar mesej baharu ke sistem salah sementara e-mel lama kekal di tempat lain. Sebelum pertukaran, inventori rekod sedia ada, sahkan peti mel sasaran, rancang ujian dan tentukan cara menyiasat mesej gagal atau tertangguh.
Keutamaan MX bukan kedudukan prestasi
Rekod MX boleh menyenaraikan lebih daripada satu destinasi dengan nilai keutamaan angka. Sistem e-mel penghantar menggunakan keutamaan tersebut menurut aturan penghantaran; angka lebih kecil lazimnya menunjukkan pelayan yang lebih diutamakan. Angka itu bukan penilaian pelanggan, kelajuan perkhidmatan atau jaminan replikasi peti mel automatik. Sesetengah pembekal memerlukan beberapa entri MX untuk ketahanan, manakala yang lain menetapkan satu destinasi. Ikuti dokumentasi pembekal tepat, termasuk keperluan beberapa entri. Jika dua perkhidmatan e-mel yang tidak berkaitan dicampur tanpa reka bentuk, mesej mungkin dihantar secara tidak konsisten. Uji tingkah laku utama dan sandaran jika berkenaan.
Rekod TXT membawa teks pengesahan dan dasar
Rekod TXT menyimpan teks yang boleh ditanya oleh perkhidmatan lain melalui DNS. Pembekal lazimnya menggunakan nilai TXT untuk mengesahkan kawalan domain sebelum mengaktifkan e-mel, analitik atau ciri berkaitan sijil. Mekanisme pengesahan e-mel juga menggunakan rekod teks DNS, tetapi nama dan kandungan tepatnya berbeza. Entri TXT bukan tempat menyimpan rahsia kerana jawapan DNS boleh dicari secara awam. Jangan letakkan kata laluan, kunci API atau data pelanggan dalam TXT. Apabila pembekal memberikan token pengesahan, tambahkannya pada nama hos ditetapkan dan kekalkan nilai mengikut arahan. Semak sama ada entri pengesahan lama selamat dibuang sebelum memadamnya.
SPF, DKIM dan DMARC mempunyai tugas berbeza
SPF membantu mengenal pasti infrastruktur penghantar yang dibenarkan, DKIM menyediakan tandatangan kriptografi mesej, manakala DMARC menentukan cara penerima menilai penjajaran serta mengendalikan kegagalan. Mekanisme ini sering bergantung pada rekod TXT, walaupun pemilih DKIM mungkin diterbitkan melalui CNAME dalam sesetengah tetapan pembekal. Ia tidak menggantikan MX yang mengawal penghalaan e-mel masuk. Menyalin dasar SPF syarikat lain boleh merosakkan penghantaran sah atau membenarkan perkhidmatan tidak dimaksudkan. Inventori semua sistem yang menghantar bagi pihak domain, termasuk platform bil dan surat berita, sebelum mengubah pengesahan. Uji serta pantau hasil dan jangan terus menggunakan dasar ketat tanpa bukti.
TTL mengawal cache, bukan kiraan detik sejagat
Time to Live memberitahu penyelesai DNS berapa lama jawapan boleh disimpan dalam cache sebelum ditanya semula. TTL lebih pendek boleh membantu perubahan dirancang kelihatan lebih cepat, tetapi tidak menjamin semua pengguna melihat rekod baharu pada saat sama. Cache setempat, tingkah laku pembekal dan nilai TTL terdahulu masih mempengaruhi pemerhatian. Cloudflare mendokumenkan pilihan TTL berbeza untuk rekod melalui proksi dan DNS sahaja. Sebelum migrasi berjadual, catat nilai semasa dan rancang pelarasan TTL yang sesuai lebih awal. Selepas perubahan, bandingkan jawapan autoritatif dengan beberapa penyelesai rekursif dan jangan anggap satu muat semula pelayar sebagai bukti penyebaran lengkap.
Tetapan proksi Cloudflare bukan untuk semua perkhidmatan
Cloudflare boleh memproksikan rekod A, AAAA dan CNAME tertentu untuk web, tetapi protokol e-mel biasa tidak melalui proksi HTTP standardnya. Rekod MX ialah DNS sahaja, dan nama hos e-mel yang digunakan SMTP, IMAP atau POP3 lazimnya perlu menuju terus kepada perkhidmatan mel. Panduan penyelesaian masalah rasmi Cloudflare memberi amaran bahawa memproksikan nama hos mel boleh menghalang sambungan pelanggan. Jangan menukar tetapan awan jingga pada semua rekod semata-mata untuk menyeragamkan paparan zon. Kenal pasti nama hos laman dan e-mel, kemudian ikuti arahan pembekal. Perubahan proksi boleh mengubah laluan trafik tanpa mengubah langganan e-mel asas.
Zone Editor cPanel mungkin bukan sumber autoritatif
Zone Editor cPanel boleh mewujudkan dan menyunting rekod DNS apabila akaun hosting serta konfigurasi pembekal membenarkannya. Namun kewujudan fungsi dalam papan pemuka tidak membuktikan domain awam mewakilkan DNS kepada pelayan itu. Tetapan pelayan nama pendaftar menentukan zon autoritatif yang ditanya internet. Jika DNS dihoskan di tempat lain, suntingan cPanel mungkin kekal setempat dan tidak kelihatan kepada pelanggan. Sebelum menggunakan Zone Editor, sahkan delegasi dan semak kebenaran ciri pembekal. Eksport atau rekodkan entri A, CNAME, MX dan TXT sedia ada dahulu. cPanel juga memberi amaran tetapan semula zon boleh memadam perubahan, maka reset bukan jalan pintas penyelesaian masalah yang selamat.
Domain utama dan www mungkin memerlukan entri berasingan
Pelanggan mungkin menaip contoh.com dan www.contoh.com, tetapi DNS menganggap kedua-dua nama secara berasingan. Perniagaan boleh menerbitkan rekod A bagi domain utama dan CNAME bagi www, atau menggunakan susunan lain yang disyorkan platform hosting. DNS sahaja tidak menentukan URL kanonik untuk enjin carian; pengalihan pelayan web dan metadata halaman mengendalikannya secara berasingan. Uji kedua-dua alamat melalui HTTPS dan sahkan pengalihan atau kandungan yang dijangka. Jika pembekal menyokong teknik flattening CNAME pada domain utama, fahami ia ciri khusus pembekal dan bukan aturan umum semua hos DNS. Dokumenkan seni bina dipilih untuk migrasi akan datang.
Subdomain mempunyai keperluan DNS tersendiri
Perniagaan boleh menggunakan mail.contoh.com, shop.contoh.com atau support.contoh.com bagi perkhidmatan berlainan. Setiap nama hos memerlukan rekod atau delegasi yang sesuai dengan fungsinya. Rekod A domain utama tidak secara automatik mewujudkan semua subdomain. Rekod wildcard mungkin meliputi sebahagian nama yang belum ditakrifkan, tetapi boleh menyebabkan penghalaan tidak dijangka dan tidak patut menggantikan konfigurasi perkhidmatan khusus. Apabila menambah subdomain, kenal pasti pemilik, perkhidmatan sasaran, keperluan TLS serta rekod pengesahan e-mel atau verifikasi jika diperlukan. Uji nama hos tepat, bukan laman utama sahaja. Buang rekod lapuk hanya selepas memastikan tiada perkhidmatan aktif masih bergantung padanya.
Rancang migrasi laman tanpa merosakkan e-mel
Apabila memindahkan laman ke hos baharu, mungkin memadai menukar rekod A atau CNAME yang digunakan web sambil mengekalkan MX serta rekod pengesahan e-mel. Pelan tepat bergantung pada sama ada hos DNS turut berpindah. Sebelum pertukaran, salin zon sedia ada sepenuhnya, sediakan destinasi, uji laman melalui nama hos ujian dan dokumenkan nilai untuk kembali semula. Semak sama ada pembekal baharu memerlukan rekod TXT pengesahan. Jadualkan perubahan ketika pasukan bertanggungjawab boleh memantau hasil. Jangan menggantikan seluruh zon DNS dengan templat hosting lalai tanpa membandingkan setiap rekod; tindakan itu boleh memutuskan e-mel perniagaan secara senyap.
Siasat ralat DNS berdasarkan bukti
Jika laman atau peti mel berhenti selepas perubahan, asingkan gejala. Semak sama ada domain berdaftar dan aktif, pelayan nama betul, DNS autoritatif memberikan rekod yang dimaksudkan serta pelayan sasaran benar-benar menjawab. Jawapan MX yang betul tidak membuktikan pelayan mel menerima mesej; jawapan A yang betul tidak membuktikan HTTPS berfungsi. Cloudflare mengesyorkan semakan resolusi MX terhadap nilai dijangka pembekal e-mel ketika menyiasat masalah mel. Rekodkan hasil pertanyaan, cap masa dan mesej ralat sebelum suntingan lanjut. Mengubah rekod tidak berkaitan berulang kali tanpa hipotesis menjadikan punca asal lebih sukar dikenal pasti.
Simpan inventori rekod dan pegawai bertanggungjawab
Inventori DNS yang berguna merekodkan nama hos, jenis, nilai, TTL, pembekal, tujuan perniagaan, pegawai perkhidmatan dan tarikh pengesahan terakhir. Labelkan entri yang menyokong e-mel, laman utama, pengesahan, sijil atau aplikasi luaran. Simpan sejarah rekod di lokasi terkawal supaya juruteknik baharu memahami sebab token TXT yang tidak dikenali wujud. Elakkan menyalin kelayakan akaun sensitif ke dokumentasi DNS. Semak entri ketika pembekal berubah atau pekerja berhenti, tetapi jangan memadam rekod hanya kerana tujuannya tidak jelas. Kenal pasti dahulu perkhidmatan berkaitan dan sahkan sama ada pembuangan selamat. Disiplin kecil ini mengurangkan gangguan tidak sengaja semasa penyelenggaraan biasa.
Contoh andaian perubahan DNS syarikat kecil
Bayangkan firma perunding Malaysia memindahkan laman daripada satu syarikat hosting kepada syarikat lain sambil mengekalkan e-mel Microsoft 365. Juruteknik mengesahkan pelayan nama autoritatif, menyalin zon semasa dan mengenal pasti rekod A web, CNAME www, MX Microsoft serta entri pengesahan e-mel. Selepas menyediakan dan menguji laman baharu, hanya destinasi web yang diperlukan diubah. Pasukan kemudian menyemak kedua-dua nama hos laman, e-mel masuk, e-mel keluar dan tingkah laku sijil. Ini proses keputusan andaian, bukan templat rekod sejagat: nilai tepat mesti datang daripada arahan semasa setiap pembekal. Mengekalkan rekod e-mel tanpa perubahan ialah keputusan sengaja, bukan keciciran.
Senarai semak perubahan yang selamat
Sebelum menyimpan suntingan DNS, sahkan domain dan pembekal autoritatif, nama hos diminta, jenis rekod, nilai tepat, TTL serta perkhidmatan dimaksudkan. Kenal pasti pihak yang meluluskan perubahan dan rekod lain yang mungkin bergantung padanya. Ambil sandaran atau eksport zon sedia ada dan nyatakan nilai untuk kembali semula. Selepas menyimpan, sahkan jawapan autoritatif kemudian uji aplikasi atau aliran e-mel daripada sambungan bebas. Rekodkan hasil dan biarkan rekod tidak berkaitan. Suntingan DNS dilaksanakan apabila pembekal menerimanya, tetapi hanya disahkan apabila perkhidmatan yang dimaksudkan berfungsi betul; kedua-duanya ialah titik semakan berlainan bagi pemilik perniagaan.