Apa itu DNS SOA record?

DNS
Diterbitkan oleh

Jika Anda pernah menelusuri record DNS sebuah domain menggunakan dig atau alat pencarian online, Anda mungkin menemukan SOA record tanpa terlalu paham fungsinya. Padahal ini adalah salah satu record terpenting di setiap zona DNS: mendefinisikan siapa yang memiliki otoritas atas zona tersebut, bagaimana server DNS sekunder harus bersinkronisasi, dan berapa lama data tetap valid jika server utama tidak bisa dihubungi.

Apa yang terdapat dalam SOA record

SOA adalah singkatan dari Start of Authority. Setiap zona DNS wajib memiliki tepat satu SOA record. Selalu berada di puncak zona dan memiliki tujuh field yang berbeda. Berikut tampilan SOA record yang umum:

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                          2025052901  ; Serial
                          7200        ; Refresh
                          3600        ; Retry
                          1209600     ; Expire
                          86400 )     ; Minimum TTL

Mari kita urai setiap field:

  • MNAME (ns1.example.com.): server DNS utama yang berwenang untuk zona tersebut. Inilah server yang dihubungi oleh server sekunder untuk mendapatkan pembaruan
  • RNAME (admin.example.com.): alamat email administrator zona, tetapi menggunakan titik menggantikan @. Di sini berarti [email protected]. Jika bagian lokal mengandung titik, harus di-escape dengan backslash (nama\.belakang.example.com.)
  • Serial (2025052901): nomor versi zona. Setiap perubahan harus menaikkan nomor ini, jika tidak server sekunder tidak akan mendeteksi pembaruan. Format umum adalah YYYYMMDDNN (tanggal ditambah penghitung harian)
  • Refresh (7200): interval dalam detik antara pemeriksaan oleh server sekunder. Di sini setiap 2 jam
  • Retry (3600): waktu tunggu sebelum mencoba lagi jika pemeriksaan Refresh gagal. Di sini 1 jam
  • Expire (1209600): waktu setelah server sekunder berhenti menjawab untuk zona jika tidak bisa lagi menghubungi server utama. Di sini 14 hari. Setelah waktu ini, sekunder menganggap datanya kedaluwarsa dan berhenti melayani zona sepenuhnya
  • Minimum TTL (86400): sejak RFC 2308, field ini menentukan berapa lama respons negatif (NXDOMAIN) di-cache. Di sini 24 jam. Jika seseorang menanyakan subdomain yang tidak ada, resolver menyimpan jawaban "tidak ada" selama 24 jam

Mengapa nomor serial begitu penting

Serial mungkin adalah field yang paling sering menimbulkan masalah dalam praktik. Ketika server sekunder menghubungi server utama selama siklus Refresh, ia membandingkan nomor serial lokalnya dengan milik server utama. Jika milik server utama lebih tinggi, sekunder memulai transfer zona (AXFR atau IXFR) untuk memperbarui diri. Jika tidak berubah, tidak melakukan apa-apa.

Kesalahan klasik: mengubah record DNS di server utama tanpa menaikkan serial. Hasilnya, server utama memiliki versi yang benar tetapi server sekunder terus menyajikan versi lama selama berjam-jam atau berhari-hari. Pengguna mendapat jawaban berbeda tergantung server mana yang mereka hubungi, dan masalahnya sulit didiagnosis jika tidak ada yang berpikir untuk memeriksa SOA.

Format YYYYMMDDNN adalah konvensi, bukan keharusan. Serial adalah integer 32-bit, jadi nilai mana pun dari 0 hingga 4.294.967.295 berfungsi. Namun format tanggal direkomendasikan karena membuat kesalahan terlihat: serial 2025052901 jelas merupakan perubahan pertama pada 29 Mei 2025.

Bagaimana Refresh, Retry, dan Expire bekerja sama

Tiga nilai ini membentuk sistem ketahanan untuk zona DNS. Refresh menetapkan ritme sinkronisasi normal. Retry mengambil alih saat Refresh gagal. Expire adalah jaring pengaman terakhir: melewati periode ini tanpa kontak dengan server utama, sekunder lebih memilih tidak menjawab sama sekali daripada menyajikan data yang mungkin sudah kedaluwarsa.

Untuk domain standar, RFC 1912 merekomendasikan:

  • Refresh: 3.600 hingga 86.400 detik (1 jam hingga 24 jam)
  • Retry: 600 hingga 3.600 detik (10 menit hingga 1 jam)
  • Expire: 1.209.600 hingga 2.419.200 detik (2 hingga 4 minggu)
  • Minimum TTL: 3.600 hingga 86.400 detik (1 jam hingga 24 jam)

Jika zona Anda sering berubah (misalnya CDN atau infrastruktur dengan load balancing dinamis), turunkan Refresh ke 300 atau 600 detik. Jika stabil, 86.400 sangat memadai dan mengurangi beban pada server utama.

Cara memeriksa SOA record sebuah domain

Di Linux dan macOS, perintah dig paling praktis:

dig SOA example.com

Di Windows, gunakan nslookup:

nslookup -type=SOA example.com

Responsnya menampilkan ketujuh field SOA. Perhatikan khususnya serial: jika terlihat lama atau beku, itu sering menjadi alasan mengapa perubahan DNS tidak menyebar dengan benar.

Kesalahan SOA yang sering terjadi

Beberapa masalah yang sering ditemui dalam praktik:

  • RNAME menggunakan @ alih-alih titik, yang merusak sintaks. [email protected] harus ditulis sebagai admin.example.com. dalam SOA
  • Serial tidak sengaja turun setelah pemulihan backup. Server sekunder akan menolak sinkronisasi sampai serial server utama kembali di atas nilai lokal mereka
  • Expire terlalu pendek (beberapa jam). Jika server utama down di akhir pekan, sekunder berhenti menjawab sebelum ada yang bisa menangani
  • Minimum TTL diset 0, artinya resolver tidak men-cache respons negatif. Setiap kueri ke subdomain yang tidak ada menghasilkan round trip penuh, yang bisa membebani server DNS Anda saat terjadi pemindaian atau serangan
SOA record jarang menjadi hal pertama yang diedit saat menyiapkan domain, tetapi sering menjadi yang menjelaskan mengapa "DNS tidak menyebar". Sebelum mencari penyebab rumit, periksa apakah serial sudah dinaikkan dengan benar dan apakah nilai Refresh dan Expire sesuai dengan penggunaan Anda.