Clouder

Panduan DNS Record: A, CNAME, MX, TXT, dan Cara Mengaturnya

Oleh Tim Clouder ·

Website baru Anda tidak bisa dibuka padahal hosting sudah aktif, atau email kantor tiba-tiba tidak masuk setelah pindah layanan. Hampir selalu penyebabnya ada di satu tempat: dns record domain Anda. Satu baris yang salah ketik, atau satu record lama yang lupa dihapus, cukup untuk membuat situs dan email berhenti bekerja.

Panduan ini menjelaskan setiap jenis DNS record yang akan Anda temui di panel domain (A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, dan PTR), fungsi masing-masing, contoh pengisian yang benar, cara kerja TTL dan propagasi, serta kesalahan yang paling sering kami lihat di lapangan. Di akhir ada checklist yang bisa Anda pakai setiap kali mengubah DNS.

Apa itu DNS dan bagaimana DNS record bekerja

DNS (Domain Name System) adalah "buku alamat" internet. Komputer berkomunikasi memakai alamat IP seperti 203.0.113.10, sedangkan manusia lebih mudah mengingat tokoanda.id. DNS menerjemahkan nama ke alamat, dan juga menyimpan informasi lain seperti server email mana yang menerima surat untuk domain tersebut.

Saat seseorang membuka www.tokoanda.id, kurang lebih inilah yang terjadi:

  1. Browser bertanya ke recursive resolver (biasanya milik ISP, atau publik seperti 1.1.1.1 dan 8.8.8.8).
  2. Jika jawabannya belum ada di cache, resolver bertanya ke root server, lalu ke server TLD .id, yang menunjuk ke nameserver domain Anda.
  3. Nameserver domain Anda (authoritative) memberikan jawaban dari DNS record yang Anda atur.
  4. Resolver menyimpan jawaban itu di cache selama TTL, lalu mengirimkannya ke browser.

Setiap DNS record terdiri dari beberapa bagian: nama (host, misalnya www atau @ untuk domain utama), tipe (A, MX, dan seterusnya), TTL dalam detik, dan nilai. Di file zona standar, satu record ditulis seperti ini:

www.tokoanda.id.   3600   IN   A   203.0.113.10

Di panel domain, simbol @ berarti domain itu sendiri (tokoanda.id), bukan subdomain. Titik di akhir nama (tokoanda.id.) menandakan nama lengkap; sebagian panel menambahkannya otomatis, sebagian tidak, jadi perhatikan contoh dari penyedia Anda.

Record A dan AAAA: mengarahkan domain ke server

Record A (IPv4)

Record A menghubungkan nama ke alamat IPv4. Inilah record yang paling sering Anda ubah saat pindah hosting.

@     3600  IN  A  203.0.113.10
www   3600  IN  A  203.0.113.10

Satu nama boleh memiliki lebih dari satu record A, dan klien biasanya mencoba bergantian. Ini sering menjadi sumber masalah: record A ke server lama yang lupa dihapus membuat sebagian pengunjung masih melihat situs lama.

Record AAAA (IPv6)

Record AAAA fungsinya sama, tetapi untuk alamat IPv6 (didefinisikan di RFC 3596):

@  3600  IN  AAAA  2001:db8::10

Aturan pentingnya: hanya buat record AAAA jika server Anda benar-benar melayani website lewat IPv6. Banyak perangkat di Indonesia, terutama jaringan seluler, sudah memakai IPv6 dan akan memilihnya lebih dulu. Jika AAAA menunjuk ke alamat yang tidak aktif atau server yang tidak dikonfigurasi untuk domain Anda, pengunjung tersebut akan mengalami situs lambat atau gagal dibuka, sementara Anda yang memakai IPv4 melihat semuanya normal.

Record CNAME: alias ke nama lain

CNAME (Canonical Name) membuat satu nama menjadi alias dari nama lain. Resolver yang menemukan CNAME akan melanjutkan pencarian ke nama tujuan.

www    3600  IN  CNAME  tokoanda.id.
shop   3600  IN  CNAME  tokoanda.platformtoko.example.

Jika IP tujuan berubah, Anda tidak perlu mengubah apa pun. Karena itu layanan pihak ketiga (toko online, landing page builder, CDN) biasanya meminta CNAME, bukan record A.

Aturan CNAME yang sering dilanggar

  • Nama yang memiliki CNAME tidak boleh punya record lain. Ini aturan dasar DNS sejak RFC 1034. Anda tidak bisa membuat www sebagai CNAME sekaligus memberi www record TXT atau MX.
  • CNAME tidak bisa dipasang di domain utama (@). Domain utama wajib memiliki record SOA dan NS, sehingga otomatis bentrok dengan aturan di atas. Beberapa penyedia DNS (misalnya Cloudflare) menawarkan CNAME flattening atau record ALIAS/ANAME yang meniru perilaku CNAME di root, tetapi itu fitur khusus penyedia, bukan record DNS standar.
  • MX dan NS tidak boleh menunjuk ke CNAME (RFC 2181). Arahkan ke nama yang memiliki record A/AAAA langsung.
  • Hindari rantai CNAME panjang. CNAME ke CNAME ke CNAME menambah waktu lookup dan titik kegagalan.

Record MX: ke mana email untuk domain Anda dikirim

Record MX (Mail Exchanger) memberi tahu server pengirim email ke server mana surat untuk @tokoanda.id harus diantarkan. Setiap MX punya angka prioritas: angka lebih kecil dicoba lebih dulu.

@  3600  IN  MX  10  mail.tokoanda.id.
@  3600  IN  MX  20  mail2.tokoanda.id.
mail   3600  IN  A  203.0.113.20
mail2  3600  IN  A  203.0.113.21

Jika mail.tokoanda.id tidak bisa dihubungi, pengirim akan mencoba mail2. Jika dua MX memiliki prioritas sama, pengirim membagi beban secara acak di antara keduanya.

Hal yang perlu diingat saat mengatur MX:

  • Nilai MX harus berupa nama host, bukan alamat IP. MX 10 203.0.113.20 tidak valid.
  • Nama host tujuan harus memiliki record A (dan/atau AAAA), bukan CNAME.
  • Saat pindah layanan email (misalnya dari email hosting ke Google Workspace), hapus MX lama. MX lama dengan prioritas lebih kecil akan tetap "menyedot" sebagian email.
  • MX hanya mengatur email masuk. Agar email keluar tidak masuk spam, Anda juga perlu SPF, DKIM, dan DMARC, yang dibahas lengkap di panduan SPF, DKIM, dan DMARC.

Record TXT: verifikasi dan autentikasi email

Record TXT menyimpan teks bebas. Dulu jarang dipakai, sekarang menjadi tempat untuk banyak hal penting:

  • SPF: daftar server yang boleh mengirim email atas nama domain Anda.
  • DKIM: kunci publik untuk memverifikasi tanda tangan email (di nama seperti default._domainkey).
  • DMARC: kebijakan jika email gagal autentikasi (di nama _dmarc).
  • Verifikasi kepemilikan: Google Search Console, Microsoft 365, layanan SSL, dan banyak platform lain meminta Anda menambahkan TXT berisi kode unik.
@                    3600  IN  TXT  "v=spf1 mx include:_spf.google.com -all"
_dmarc               3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@tokoanda.id"
@                    3600  IN  TXT  "google-site-verification=abc123..."

Satu nama boleh memiliki banyak record TXT, tetapi SPF hanya boleh satu. Dua record yang sama-sama diawali v=spf1 membuat hasil SPF menjadi permerror, dan email Anda bisa ditolak. Jika perlu menambahkan layanan baru, gabungkan ke dalam satu record.

Satu string TXT dibatasi 255 karakter. Nilai yang lebih panjang, seperti kunci DKIM 2048-bit, dipecah menjadi beberapa string dalam satu record ("bagian1" "bagian2"). Banyak panel melakukannya otomatis; jika tidak, ikuti format dari penyedia email Anda. Anda bisa mengecek SPF beserta jumlah DNS lookup-nya dengan SPF checker.

Record NS dan SOA: siapa yang memegang zona Anda

Record NS

Record NS menentukan nameserver mana yang authoritative untuk domain Anda. Ada dua tempat NS dicatat, dan keduanya harus sinkron:

  1. Di registry (untuk domain .id dikelola PANDI), diatur melalui registrar tempat Anda membeli domain. Inilah yang benar-benar menentukan nameserver mana yang dipakai dunia.
  2. Di zona DNS itu sendiri, sebagai record NS di @.

Kesalahan klasik: mengubah record A di panel hosting, padahal NS domain masih menunjuk ke nameserver registrar atau Cloudflare. Perubahan Anda tidak akan pernah terlihat. Sebelum mengedit record apa pun, pastikan dulu di mana zona Anda aktif.

Record SOA

Record SOA (Start of Authority) ada tepat satu di setiap zona dan biasanya dibuat otomatis. Isinya:

@  IN  SOA  ns1.hostinganda.id. admin.tokoanda.id. (
        2026110801 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        3600 )     ; minimum (TTL negatif)
  • Serial: nomor versi zona, sering berformat tanggal (YYYYMMDDnn). Server sekunder hanya menyalin zona jika serial bertambah.
  • Refresh, retry, expire: jadwal sinkronisasi server sekunder.
  • Minimum: sejak RFC 2308, nilai ini (bersama TTL SOA itu sendiri) menentukan berapa lama jawaban "nama tidak ada" (NXDOMAIN) disimpan di cache. Ini penting: jika Anda mengecek blog.tokoanda.id sebelum record-nya dibuat, resolver bisa "mengingat" bahwa nama itu tidak ada sampai waktu tersebut habis.
  • Alamat email admin ditulis dengan titik menggantikan @.

Record CAA dan PTR: keamanan SSL dan reverse DNS

Record CAA

CAA (Certification Authority Authorization, RFC 8659) menentukan Certificate Authority mana yang boleh menerbitkan sertifikat SSL untuk domain Anda. CA wajib mengecek CAA sebelum menerbitkan sertifikat. Jika tidak ada record CAA sama sekali, CA mana pun boleh menerbitkan.

@  3600  IN  CAA  0 issue "letsencrypt.org"
@  3600  IN  CAA  0 issuewild "letsencrypt.org"
@  3600  IN  CAA  0 iodef "mailto:security@tokoanda.id"
  • issue mengizinkan CA untuk sertifikat biasa.
  • issuewild mengatur sertifikat wildcard (*.tokoanda.id). Jika tidak ada, aturan issue yang berlaku.
  • iodef adalah alamat untuk laporan pelanggaran.

Menurut dokumentasi Let's Encrypt, CA mencari record CAA terdekat dengan naik dari nama lengkap ke domain induk. Jadi CAA di @ berlaku juga untuk semua subdomain kecuali subdomain itu punya CAA sendiri.

Peringatan: jika Anda memasang CAA yang hanya mengizinkan satu CA, lalu hosting atau CDN Anda memakai CA lain, perpanjangan sertifikat akan gagal diam-diam. Sebelum menambah CAA, cek CA apa saja yang dipakai layanan Anda. Hosting kami menerbitkan SSL gratis dari Let's Encrypt secara otomatis, jadi pastikan letsencrypt.org ada di daftar jika Anda memasang CAA.

Record PTR (reverse DNS)

PTR adalah kebalikan dari A: mengubah IP menjadi nama. Record PTR untuk 203.0.113.20 disimpan di nama 20.113.0.203.in-addr.arpa.

Yang perlu Anda tahu: PTR tidak diatur di panel domain Anda, melainkan oleh pemilik blok IP, yaitu penyedia server atau ISP. PTR terutama penting untuk server email. Gmail dan Yahoo mewajibkan IP pengirim memiliki forward dan reverse DNS yang valid: PTR menunjuk ke sebuah nama, dan nama itu punya record A kembali ke IP yang sama. Jika Anda memakai email dari hosting bersama, hal ini biasanya sudah diurus penyedia.

TTL, propagasi, dan cara mengecek DNS record

TTL (Time To Live) adalah berapa detik resolver boleh menyimpan jawaban di cache. TTL 3600 berarti satu jam; 86400 berarti satu hari.

Istilah "propagasi DNS" sebenarnya agak menyesatkan. Perubahan tidak "menyebar" dari server ke server. Yang terjadi: nameserver Anda langsung memberikan jawaban baru, tetapi resolver di seluruh dunia masih memegang jawaban lama sampai TTL-nya habis. Karena itu, sebagian orang sudah melihat situs baru sementara yang lain belum.

Beberapa hal yang memengaruhi lamanya:

  • TTL record lama, bukan TTL baru. Jika record A lama ber-TTL 86400, resolver yang baru saja menyimpannya bisa memakainya hingga 24 jam.
  • Perubahan NS di registry biasanya paling lama, karena record NS di server TLD sering ber-TTL panjang dan berada di luar kendali Anda.
  • Cache lokal di browser, sistem operasi, dan router.
  • Cache negatif dari SOA, seperti dijelaskan di atas.

Strategi pindah server dengan downtime minimal

  1. Satu atau dua hari sebelum migrasi, turunkan TTL record A/AAAA/MX yang akan diubah menjadi 300 detik.
  2. Tunggu minimal sebesar TTL lama agar semua cache memakai TTL baru.
  3. Salin website dan database ke server baru, uji lewat file hosts di komputer Anda.
  4. Ubah record ke IP baru. Dalam beberapa menit sebagian besar pengunjung sudah pindah.
  5. Biarkan server lama aktif beberapa hari untuk menangkap lalu lintas yang tersisa.
  6. Setelah stabil, naikkan TTL kembali ke 3600 atau lebih.

Strategi yang sama berlaku saat memindahkan domain antar-registrar; detailnya ada di panduan transfer domain tanpa downtime.

Cara mengecek DNS record domain Anda

Anda bisa mengecek record dari sisi pengunjung dengan alat DNS lookup kami (mendukung A, AAAA, MX, NS, TXT, CNAME, SOA, dan CAA) atau lewat terminal:

dig tokoanda.id A +short
dig tokoanda.id MX +short
dig _dmarc.tokoanda.id TXT +short
dig tokoanda.id NS +short
dig @ns1.hostinganda.id tokoanda.id A

Perintah terakhir bertanya langsung ke nameserver authoritative, melewati cache. Jika hasilnya sudah benar tetapi dig biasa masih menampilkan nilai lama, berarti Anda hanya perlu menunggu TTL habis. Di Windows, gunakan nslookup -type=MX tokoanda.id. Untuk reverse DNS, jalankan dig -x 203.0.113.20 +short.

Kesalahan DNS record yang paling sering terjadi

  • Mengedit zona yang salah: record diubah di panel hosting, padahal NS menunjuk ke tempat lain.
  • Record A ganda: IP server lama masih ada bersama IP baru.
  • AAAA tidak aktif: pengguna IPv6 gagal membuka situs.
  • CNAME di root atau CNAME bersama record lain di nama yang sama.
  • Dua record SPF atau SPF yang melebihi 10 DNS lookup.
  • MX berupa alamat IP atau menunjuk ke CNAME.
  • MX lama tidak dihapus setelah pindah layanan email.
  • CAA terlalu ketat sehingga sertifikat SSL gagal diperpanjang.
  • Lupa menurunkan TTL sebelum migrasi, lalu panik karena perubahan "tidak masuk".

Checklist sebelum dan sesudah mengubah DNS

  1. Cek NS domain: di mana zona aktif?
  2. Catat (screenshot) semua record yang ada sekarang.
  3. Turunkan TTL jika ini migrasi.
  4. Ubah satu hal pada satu waktu.
  5. Verifikasi ke nameserver authoritative dengan dig @ns.
  6. Cek dari luar dengan alat DNS lookup.
  7. Uji website (HTTP dan HTTPS) serta kirim dan terima email percobaan.
  8. Kembalikan TTL ke nilai normal.

Pertanyaan yang sering diajukan

Berapa lama propagasi DNS?

Tergantung TTL record lama. Dengan TTL 300 detik, sebagian besar pengunjung melihat perubahan dalam beberapa menit. Dengan TTL 86400, bisa hingga 24 jam. Perubahan nameserver di registry umumnya paling lama dan bisa memakan waktu hingga 1–2 hari.

Apa beda record A dan CNAME?

Record A langsung menunjuk ke alamat IP, sedangkan CNAME menunjuk ke nama lain yang kemudian dicari IP-nya. Gunakan A untuk domain utama dan CNAME untuk subdomain yang diarahkan ke layanan pihak ketiga.

Bolehkah domain memiliki lebih dari satu record TXT?

Boleh, dan itu umum, misalnya untuk SPF, verifikasi Google, dan verifikasi layanan lain. Yang tidak boleh adalah lebih dari satu record SPF (v=spf1) di nama yang sama.

Kenapa email tidak masuk padahal record MX sudah benar?

Periksa apakah MX lama masih ada, apakah nama host di MX punya record A yang benar, dan apakah NS domain menunjuk ke zona yang Anda edit. Jika masalahnya email keluar masuk spam, penyebabnya biasanya SPF, DKIM, atau DMARC, bukan MX.

Apakah saya perlu record CAA?

Tidak wajib, tetapi disarankan karena membatasi CA yang boleh menerbitkan sertifikat untuk domain Anda. Pastikan semua CA yang dipakai hosting dan CDN Anda tercantum agar perpanjangan SSL tidak gagal.

Di mana saya mengatur record PTR?

PTR diatur oleh pemilik alamat IP, yaitu penyedia server atau ISP, bukan di panel domain. Jika Anda memakai VPS untuk server email, minta penyedia mengatur PTR ke nama host server Anda.

Langkah berikutnya

Setelah memahami DNS record, langkah praktis berikutnya adalah mengecek kondisi domain Anda sendiri dengan alat DNS lookup di atas dan memastikan tidak ada record lama yang tertinggal. Jika Anda sedang mencari tempat baru untuk website, paket hosting kami sudah termasuk SSL Let's Encrypt otomatis, email dengan domain sendiri, dan integrasi Cloudflare, sehingga pengaturan DNS cukup dilakukan sekali dengan benar.