Skip to content

Domain, hosting, code and data — in your name, in writing

jagaweb.

Pengehosan & Infrastruktur

Rekod DNS Diterangkan untuk Pemilik Perniagaan

Bacaan 7 minitOleh JagaWeb

Panduan mudah tentang rekod A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC dan NS, dan kenapa kawalan DNS adalah titik kawalan sebenar.

Direktori yang Tiada Sesiapa Semak Sehingga Sesuatu Hilang

Tiada sesiapa fikir tentang DNS sehingga email berhenti sampai atau laman web menjadi gelap selepas pembaharuan domain rutin — dan pada masa itu berlaku, rekod yang menyebabkannya biasanya sudah duduk di situ, salah, selama beberapa minggu. DNS (Domain Name System) ialah perkhidmatan direktori internet: ia menterjemah nama yang boleh dibaca manusia seperti yourbusiness.com.my kepada alamat teknikal yang sebenarnya digunakan oleh komputer untuk mencari laman web anda, mail server anda, dan segala-galanya yang berkaitan dengan domain anda. Memahami beberapa jenis rekod yang membentuk DNS adalah antara setengah jam paling bernilai yang boleh dihabiskan oleh pemilik perniagaan ke atas infrastruktur mereka sendiri.

Registrar, Zone, dan Rekod — Tiga Perkara Berbeza

Domain registrar ialah syarikat yang anda bayar untuk mendaftarkan nama domain itu sendiri; pembelian itu memberikan anda hak untuk mengawal apa yang dipanggil hierarki DNS di bawah nama tersebut. DNS zone pula ialah tempat rekod sebenar untuk domain anda berada — ia mungkin di-host oleh registrar anda, web host anda, atau provider DNS yang berasingan sepenuhnya (Microsoft Learn — DNS zones and records). Ketiga-tiga ini selalunya adalah tiga syarikat yang berbeza, dan itulah sebabnya domain akhirnya separuh terkawal tanpa sesiapa yang benar-benar bertanggungjawab selepas projek laman web tamat atau freelancer berhenti.

Rekod A dan AAAA: Di Mana Laman Web Itu Sendiri Berada

Rekod A memetakan hostname kepada alamat IPv4 — alamat bergaya "93.184.x.x" yang masih menjadi tulang belakang kebanyakan routing internet. Rekod AAAA melakukan kerja yang sama untuk IPv6, format alamat yang lebih baharu dan jauh lebih besar, ditulis dalam hexadecimal. Jika mana-mana satu daripada ini tersilap, atau masih menuding ke server lama selepas migrasi, pelawat akan dihantar ke server yang sama ada tidak menjawab langsung atau menghidangkan sesuatu yang salah sama sekali.

CNAME: Alias, Bukan Destinasi

Rekod CNAME langsung tidak menuding kepada alamat IP — ia menuding kepada nama domain lain, dan memberitahu DNS untuk mencari rekod nama itu sebaliknya. Begitulah cara www.yourbusiness.com biasanya di-alias kepada yourbusiness.com, atau cara subdomain ditudingkan kepada perkhidmatan pihak ketiga seperti help desk atau tool landing-page tanpa anda perlu menjejaki sendiri alamat IP provider tersebut yang sentiasa berubah.

MX: Ke Mana Email Sebenarnya Pergi

Rekod MX (Mail Exchanger) memberitahu internet secara umum mail server mana yang dibenarkan menerima email untuk domain anda. Setiap rekod MX membawa nombor keutamaan — nombor yang lebih rendah dicuba dahulu — supaya sesebuah domain boleh menyenaraikan mail server utama dan satu atau lebih fallback. Jika rekod MX tersilap, hilang, atau masih menuding ke platform mel yang anda sudah tinggalkan berbulan lalu, mel masuk sama ada terpantul balik kepada penghantar atau hilang senyap ke dalam server yang tiada sesiapa semak. Ini antara punca paling biasa bagi "kami tak pernah terima email itu" yang rupa-ranya tiada kaitan langsung dengan spam filter.

TXT: Rekod yang Melakukan Hampir Semua Perkara Lain

Rekod TXT sekadar menyimpan teks bebas terhadap sesuatu nama domain. Asalnya ini untuk nota yang boleh dibaca manusia, tetapi rekod TXT kini menjadi mekanisme di sebalik kebanyakan pengesahan domain (membuktikan kepada Google, Microsoft atau platform lain bahawa anda mengawal domain itu) dan — yang paling penting — pengesahan email (email authentication). Di bawah RFC 7208, piawaian yang mentakrifkannya, rekod SPF mesti diterbitkan menggunakan jenis rekod TXT; jenis rekod "SPF" yang berasingan dan khusus telah deprecated dan provider DNS moden tidak lagi menyokongnya (Microsoft Learn).

SPF, DKIM dan DMARC: Trio Anti-Spoofing

Ketiga-tiga mekanisme ini bekerjasama untuk menghalang orang lain daripada menghantar email yang kelihatan seolah-olah datang daripada domain anda — taktik biasa dalam phishing.

SPF (Sender Policy Framework) membolehkan anda menerbitkan, sebagai rekod TXT, senarai mail server yang dibenarkan menghantar email bagi pihak domain anda, supaya server penerima boleh menyemak sama ada mesej masuk itu benar-benar datang daripada salah satu daripadanya.

DKIM (DomainKeys Identified Mail) melampirkan tandatangan kriptografi pada mel keluar; server penerima mengambil public key anda daripada DNS dan mengesahkan tandatangan itu sepadan, mengesahkan mesej itu tidak diubah semasa perjalanan.

DMARC (Domain-based Message Authentication, Reporting and Conformance) duduk di atas kedua-duanya. Ia memberitahu mail server penerima apa yang perlu dilakukan apabila sesuatu mesej gagal SPF atau DKIM, dan ia memerlukan "alignment" — domain yang lulus pengesahan mesti sepadan dengan domain yang benar-benar dilihat oleh penerima pada alamat From, dan itulah yang menghalang penyerang daripada lulus SPF pada domain lain yang tidak berkaitan sambil memalsukan (spoof) domain anda pada medan penghantar yang kelihatan.

Apabila rekod-rekod ini hilang atau tersilap konfigurasi, biasanya salah satu daripada dua perkara berlaku: email marketing atau transaksi yang sah mula jatuh ke dalam spam (atau terus ditolak oleh mail provider yang lebih ketat), atau — jika ia langsung tiada — domain itu menjadi lebih mudah dipalsukan secara meyakinkan dalam percubaan phishing terhadap pelanggan anda sendiri.

Rekod NS: Titik Kawalan Sebenar

Rekod NS (Name Server) menentukan server mana yang berkuasa (authoritative) untuk domain anda — bermakna, pihak mana sahaja yang mengawal nameserver tersebut mengawal ke mana setiap rekod lain untuk domain itu akhirnya resolve. Inilah sebab rekod NS lebih penting daripada mana-mana rekod A atau MX secara individu: tukar siapa yang memegang nameserver, dan anda boleh redirect laman web, email, dan segala-galanya yang berkaitan dengan domain itu, semuanya sekali gus, tanpa menyentuh langsung mana-mana rekod lain.

Untuk domain .my Malaysia, fungsi registry dan registrar dilaksanakan oleh MYNIC, yang tidak meng-host DNS itu sendiri tetapi membenarkan pemegang domain berdaftar menguruskan sehingga enam entri nameserver melalui control panel-nya sendiri (MYNIC). Sesiapa sahaja yang mempunyai akses log masuk ke akaun MYNIC tersebut — atau ke akaun registrar mana-mana yang memegang domain antarabangsa — sebenarnya mempunyai kata putus terakhir ke atas keseluruhan domain, tidak kira siapa yang membina laman web atau menguruskan hosting.

Kenapa Kawalan Domain Lebih Penting Daripada Host Mana yang Anda Pilih

Domain tanpa perlindungan transfer boleh, pada dasarnya, dipindahkan ke registrar lain oleh sesiapa sahaja yang memperoleh credential akaun atau kod pengesahan (authorisation code). Transfer lock registrar (yang kelihatan dalam rekod WHOIS sebagai status seperti clientTransferProhibited) menyekat permintaan transfer terus sehingga sengaja dialih keluar, dan segelintir registry menawarkan "Registry Lock" yang lebih kukuh lagi, yang memerlukan pengesahan manual di luar talian (out-of-band) — panggilan telefon atau passphrase selamat — sebelum sebarang perubahan diluluskan. Secara berasingan, DNSSEC menandatangani respons DNS secara kriptografi supaya resolver boleh mengesahkan ia tidak diusik semasa perjalanan, melindungi daripada serangan spoofing dan cache-poisoning yang DNS pada asalnya tidak direka untuk menahannya (IBM).

TTL, dan Kenapa "Belum Update Lagi" Itu Perkara Biasa

Setiap rekod DNS membawa nilai TTL (Time to Live), dalam saat, yang memberitahu server lain berapa lama mereka dibenarkan meng-cache rekod itu sebelum menyemak semula (Microsoft Learn). Rekod dengan TTL sejam boleh mengambil masa sehingga sejam untuk update di mana-mana sahaja; rekod dengan TTL 24 jam boleh mengambil masa sehingga sehari. Dalam kes paling teruk, sesetengah resolver mengabaikan panduan TTL dan meng-cache lebih lama daripada sepatutnya, dan itulah sebabnya perubahan kadangkala boleh mengambil masa sehingga 48 jam untuk kelihatan di mana-mana sahaja. Menurunkan TTL sehari atau dua sebelum perubahan yang dirancang — migrasi server, pertukaran mail provider — adalah amalan standard khusus untuk mempercepatkan cutover akhirnya.

Senarai Semak Ringkas yang Patut Benar-Benar Dilakukan

Ketahui, secara bertulis, siapa yang memegang log masuk akaun domain registrar anda dan siapa yang mengawal DNS zone anda — dan pastikan ia tidak terkunci dalam akaun peribadi seorang pekerja yang akan meninggalkan syarikat atau agensi tertentu. Semak sama ada transfer lock aktif. Sahkan rekod MX, SPF, DKIM dan DMARC anda sepadan dengan email provider semasa anda, bukan yang lama. Semua ini tidak memerlukan kemahiran teknikal yang mendalam untuk disemak, cuma kemahuan untuk benar-benar menyemaknya.

Jika anda lebih suka ada orang lain yang mendokumentasikan dan memantau perkara ini dengan betul, JagaWeb Care (RM450 sebulan) merangkumi semakan penjagaan berterusan seperti ini — atau mulakan dengan Essential System Review (RM1,500, kini RM999 sehingga 16 September 2026) untuk mendapat gambaran bertulis yang jelas tentang keadaan DNS anda sebenarnya hari ini.

WhatsApp