Catatan DNS untuk Pengembang — A, CNAME, MX, TXT, dan TTL yang Membuat Anda Menunggu 48 Jam

Anda membeli domain, mengarahkannya ke suatu tempat, dan sekarang Anda memandang browser yang masih menampilkan situs lama. Atau Anda salah konfigurasi record MX Anda dan menemukan bahwa saat email mulai menolak. DNS adalah salah satu hal yang developer biasanya mengabaikan sampai ia menyerang mereka — dan ketika itu terjadi, lingkaran umpan baliknya lambat dan menyakitkan.

Ini bukan tutorial untuk orang yang belum pernah mendengar tentang DNS. Ini adalah referensi bagi para developer yang tahu apa itu domain tetapi selalu mencari Stack Overflow setiap kali mereka perlu menambahkan tipe record yang belum mereka sentuh selama enam bulan.

Cara DNS bekerja sebenarnya (versi 30 detik)

Ketika browser menyelesaikan example.com, ia meminta resolver rekursif (biasanya penyedia ISP Anda atau 8.8.8.8). Resolver tersebut memeriksa cache-nya. Jika terdapat hit cache, maka ia mengembalikan jawaban yang disimpan. Jika tidak, ia bergerak ke atas pohon DNS — dari nameserver akar → nameserver TLD (.com) → nameserver otoritas domain Anda — dan menyimpan hasilnya selama waktu yang ditentukan oleh TTL.

Setiap record DNS memiliki tipe, nama, nilai, dan TTL. Itu saja. Kompleksitasnya muncul dari memahami tipe mana yang melakukan apa dan bagaimana record berinteraksi dalam cara yang tidak jelas.

Tipe record yang akan Anda gunakan sebenarnya

Record A — Alamat IP untuk nama host

Memetakan nama host ke alamat IP IPv4. Ini adalah record paling umum yang akan Anda temui.

example.com.     300   IN  A   93.184.216.34
www.example.com. 300   IN  A   93.184.216.34

Kesalahan umum: Anda bisa memiliki beberapa record A untuk nama host yang sama. DNS akan mengembalikan semua dari mereka, dan klien akan memilih satu (biasanya dengan metode round-robin). Ini adalah pengaturan sederhana untuk pembagian beban — tetapi jika salah satu IP tersebut down, DNS tidak memiliki pengecekan kesehatan. Ia akan terus menyajikan IP yang rusak sampai TTL berakhir dan Anda menghapusnya.

Untuk IPv6, yang setara adalah record AAAA. Konsep yang sama, alamat 128-bit alih-alih 32-bit.

Record CNAME — Alias ke nama host lain

Mengarahkan satu nama host ke nama host lain (bukan IP). Resolutor mengikuti rantai hingga menemukan record A.

www.example.com.    300  IN  CNAME  example.com.
blog.example.com.   300  IN  CNAME  mysite.netlify.app.

CNAME vs A — kapan harus menggunakan mana: Jika Anda mengarahkan ke layanan yang memberikan Anda nama host (Netlify, Vercel, GitHub Pages, Heroku, kebanyakan CDN), gunakan CNAME. Jika Anda memiliki IP statis, gunakan record A. Sederhana.

Aturan sulit: Anda tidak boleh menempatkan CNAME di apex zona (nama domain tanpa tambahan — example.com, bukan www.example.com). RFC 1034 melarangnya karena apex harus menyimpan record SOA dan NS, dan CNAME pada nama yang sama akan menimbulkan konflik. Ketika Netlify atau Vercel mengatakan Anda harus menambahkan CNAME untuk domain akar, yang sebenarnya mereka maksudkan adalah menggunakan penyedia DNS yang mendukung record ANAME atau ALIAS — ekstensi khusus yang berperilaku seperti CNAME tetapi menyelesaikan ke record A pada tingkat zona.

Juga: jangan CNAME ke CNAME jika bisa dihindari. Secara teknis sah tetapi setiap langkah dalam rantai adalah pencarian DNS tambahan. Lebih penting lagi, jika CNAME tengah rusak, maka record Anda juga rusak.

Record MX — Pengalokasian surat

Mengatakan kepada server surat lain di mana surat harus dikirimkan untuk domain Anda. Record MX memiliki nomor prioritas — angka yang lebih rendah berarti prioritas lebih tinggi.

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

Jika mail1 tidak tersedia, server pengiriman akan mencoba mail2. Ini adalah fallback yang benar, bukan pembagian beban — Anda tidak membagi trafik, Anda hanya menentukan urutan preferensi.

Kesalahan yang sering dilakukan oleh developer: mengarahkan MX ke alamat IP atau CNAME. Nilai MX harus mengarah ke record A (nama host), bukan IP atau CNAME. Beberapa penyedia DNS akan memungkinkan Anda menyimpan konfigurasi ini tanpa peringatan, dan kemudian email Anda akan gagal secara diam-diam.

Jika Anda mengatur Google Workspace atau Microsoft 365, mereka akan memberikan sejumlah record MX. Jangan mengubah angka prioritas berpikir Anda sedang cerdas — logika pengalokasian surat bergantung pada keakuratan angka tersebut.

Record TXT — Teks bebas, terutama untuk verifikasi dan autentikasi email

Record TXT menyimpan string teks bebas. Dalam praktiknya, mereka digunakan untuk tiga hal:

• Verifikasi domain — Google Search Console, Stripe, GitHub, dan ratusan layanan lainnya akan meminta Anda menambahkan record TXT untuk membuktikan kepemilikan domain
• SPF (Sender Policy Framework) — menentukan server surat mana yang diperbolehkan mengirim email atas nama domain Anda
• DKIM dan DMARC — record autentikasi email yang mencegah penipuan

Sebuah record SPF terlihat seperti ini:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Ini berarti: Google dan SendGrid diperbolehkan mengirim email atas nama domain ini; hal lain harus dianggap dengan curiga (~all = gagal lemah, -all = gagal keras).

Record DMARC berada di _dmarc.example.com:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Hal penting: Anda hanya boleh memiliki satu record SPF TXT per domain. Jika Anda menambahkan satu lagi (karena layanan baru meminta Anda), kedua record akan ada, server surat akan melihat kebijakan yang bertentangan, dan autentikasi email akan gagal. Gabungkan saja: v=spf1 include:_spf.google.com include:sendgrid.net ~all.

Record NS — Delegasi nameserver

Menentukan nameserver mana yang otoritas untuk domain Anda. Anda biasanya mengatur ini di penyedia domain Anda, bukan langsung di zona DNS Anda. Ketika Anda pindah dari satu penyedia DNS ke yang lain (misalnya dari nameserver GoDaddy ke Cloudflare), Anda mengubah record NS di tingkat penyedia domain.

Propagasi record NS adalah alasan mengapa pindahan domain lambat. TTL record NS sering antara 24 hingga 48 jam, dan perubahan di penyedia domain memiliki penundaan propagasi tambahan di atas itu.

TTL — angka yang membuat Anda menunggu 48 jam

TTL (Time To Live) adalah angka dalam detik. Ini memberi tahu resolver yang di-cache seberapa lama mereka menyimpan jawaban sebelum meminta ulang. TTL 300 berarti lima menit. TTL 172800 berarti 48 jam.

Ketika Anda mengubah record DNS, jawaban lama masih di-cache di mana-mana hingga TTL lama. Jika record A Anda memiliki TTL 48 jam dan Anda baru saja mengubah IP, beberapa pengguna akan mengakses server lama hingga dua hari — dan tidak ada yang bisa Anda lakukan setelah perubahan tersebut dilakukan.

Solusi adalah menurunkan TTL sebelum Anda membuat perubahan. Praktik standar untuk migrasi yang direncanakan:

1. Turunkan TTL ke 300 (5 menit) minimal 48 jam sebelum migrasi — Anda harus menunggu TTL lama habis terlebih dahulu
2. Lakukan perubahan DNS
3. Tunggu 5–10 menit untuk propagasi
4. Naikkan TTL kembali ke sesuatu yang wajar (3600–86400) setelah Anda memastikan konfigurasi baru bekerja

Jika Anda lupa langkah 1 dan langsung ke langkah 2 dengan TTL tinggi, Anda akan terjebak. Anda bisa menurunkan TTL sekarang, tetapi itu hanya memperpendek waktu tunggu bagi resolver yang belum menyimpannya. Semua yang sudah menyimpan record harus menunggu hingga TTL awal habis.

Referensi cepat

Record	Menunjuk ke	Penggunaan umum	Kesalahan umum
A	Alamat IPv4	Nama host → alamat server	Tidak ada pengecekan kesehatan — IP rusak tetap berputar hingga TTL habis
AAAA	Alamat IPv6	Nama host → alamat server IPv6	Sangat mudah dilupakan untuk menambahkan bersamaan dengan record A untuk dukungan dual-stack
CNAME	Nama host lain	Alias, routing CDN/PaaS	Tidak boleh digunakan di apex zona; MX/NS tidak boleh mengarah ke CNAME
MX	Nama host (record A)	Pengalokasian pengiriman email	Nilai harus berupa nama host, bukan IP; angka prioritas penting
TXT	Teks bebas	SPF, DKIM, DMARC, verifikasi domain	Hanya satu record SPF yang diizinkan per domain — gabungkan, jangan tambahkan
NS	Nama host nameserver	Delegasi DNS	Perubahan dilakukan di penyedia domain dan membutuhkan waktu untuk menyebar
CAA	Domain CA	Kapan penyedia sertifikat SSL dapat mengeluarkan sertifikat untuk domain Anda	Sangat mudah mengunci diri Anda dari pembaruan sertifikat karena konfigurasi yang salah

Hal-hal yang akan menghemat waktu Anda

Uji dengan validator: dig langsung, bukan alat web. dig @8.8.8.8 example.com A menghindari resolver lokal dan menunjukkan tepat apa yang dilihat Google DNS. Tambahkan +short untuk hanya jawaban. Tambahkan +trace untuk menelusuri rantai resolusi penuh.

# Check what Google sees right now
dig @8.8.8.8 example.com A +short

# Check MX records
dig @8.8.8.8 example.com MX

# Check TXT (SPF, DMARC, verification tokens)
dig @8.8.8.8 example.com TXT
dig @8.8.8.8 _dmarc.example.com TXT

# Full resolution trace
dig @8.8.8.8 example.com A +trace

Periksa TTL sebelum setiap migrasi. sebelum menambahkan indeks apa pun. Pastikan masalahnya terlebih dahulu. dig example.com A dan lihat angka di kolom ketiga dari bagian jawaban. Itu adalah durasi (dalam detik) yang mungkin Anda tunggu jika Anda mengubah record sekarang tanpa menurunkan TTL terlebih dahulu.

Record yang di-proxy oleh Cloudflare tidak menampilkan IP asli Anda. Ketika Anda mengaktifkan awan oranye Cloudflare pada suatu record, alamat A yang dilihat oleh dunia adalah IP Cloudflare, bukan milik Anda. Ini biasanya yang Anda inginkan untuk perlindungan DDoS — tetapi ini berarti dig tidak akan menampilkan IP server Anda, dan alat yang memproyeksi IP secara langsung tidak akan berfungsi seperti yang diharapkan.

Anda mungkin juga menyukai