SRV Record Adalah: Fungsi, Port, Prioritas & Bobot

Sebagian layanan di internet tidak cukup dipanggil dengan nama domainnya saja. Server Minecraft sering harus ditulis main.contoh.com:25565, panel administrasi diakses di contoh.com:8443, dan server game lain memakai nomor yang berbeda lagi. Nomor di belakang titik dua itu adalah port, dan tanpa mengetahuinya koneksi tidak akan tersambung.

Kebiasaan mengetik nomor tersebut muncul karena catatan DNS yang biasa kita pakai memang tidak menyimpannya. A record hanya membawa alamat IP, sementara MX record hanya membawa nama server penerima email. SRV record adalah jawaban DNS atas keterbatasan tersebut, karena ia satu-satunya jenis catatan yang ikut membawa nomor port di dalamnya.

Artikel ini membahas isi tiap kolom SRV record dan perbedaan tugas antara angka prioritas dan angka bobot. Dibahas juga layanan apa saja yang benar-benar memakainya, cara memeriksa milik Anda sendiri, serta alasan website justru tidak memakainya.

SRV Record Adalah Penunjuk Layanan Beserta Nomor Portnya

SRV record adalah catatan DNS yang memberi tahu klien di host mana dan di port berapa sebuah layanan berjalan. SRV merupakan singkatan dari Service Record, yang berarti catatan layanan. Aturannya ditetapkan RFC 2782 pada Februari 2000, dokumen yang menggantikan RFC 2052 sebelumnya.

Perbedaannya dengan catatan lain paling mudah dilihat berdampingan:

Kolom port itulah yang membuat SRV berbeda secara mendasar. Sebuah aplikasi yang mendukung SRV dapat menemukan sendiri host beserta portnya hanya dengan mengetahui nama domainnya, tanpa penggunanya perlu menghafal angka apa pun.

Konsekuensinya, layanan dapat dipindahkan ke mesin dan port lain tanpa satu pun pengguna mengubah pengaturannya. Cukup nilai SRV record yang diperbarui.

Membaca Satu Baris SRV Record

Cara tercepat memahami susunannya adalah membedah satu baris nyata. Berikut catatan milik jabber.org, layanan pesan instan yang memakai protokol XMPP:

dig SRV _xmpp-client._tcp.jabber.org +noall +answer

_xmpp-client._tcp.jabber.org. 60 IN SRV 30 30 5222 scarlet.jabber.org.

Satu baris tersebut sebenarnya terdiri dari dua bagian besar. Bagian kiri adalah namanya, bagian kanan adalah isinya. Berikut rinciannya:

1. _xmpp-client: nama layanan, selalu diawali garis bawah.
2. _tcp: protokol transport yang dipakai layanan itu.
3. jabber.org: domain yang catatannya sedang ditanyakan.
4. 60: TTL (Time To Live), yaitu berapa detik jawaban ini boleh disimpan di cache.
5. IN: kelas record, praktis selalu bernilai IN untuk internet.
6. 30 (angka pertama): prioritas.
7. 30 (angka kedua): bobot.
8. 5222: nomor port tempat layanan itu mendengar.
9. scarlet.jabber.org.: target, yaitu nama host yang menjalankan layanan tersebut.

Dua angka 30 yang berdampingan di contoh ini mudah menyesatkan. Nilainya kebetulan sama, padahal tugasnya berbeda sama sekali.

Satu baris SRV record terbagi dua: namanya memuat layanan, protokol, domain; isinya prioritas, bobot, port 5222, target.

Prioritas, bobot, dan port sama-sama bilangan bulat 16-bit, sehingga masing-masing hanya boleh diisi angka 0 sampai 65535.

Kolom target punya dua aturan wajib. Pertama, isinya harus nama host, bukan alamat IP. Kedua, RFC 2782 menyatakan nama itu tidak boleh berupa alias, sehingga mengarahkannya ke CNAME adalah pelanggaran. Nama tersebut harus punya setidaknya satu A record atau AAAA record, karena dari situlah klien memperoleh alamat yang dihubungi.

Aturan "tidak boleh alias" ini mudah dilanggar tanpa sadar, karena banyak panel menerima isian apa pun tanpa memeriksanya. Setelah menyimpan, uji targetnya dengan dig A namatarget untuk memastikan ia menjawab dengan alamat, bukan dengan nama lain.

Kenapa Nama Layanan Diawali Garis Bawah

Susunan _layanan._protokol.domain bukan hiasan. RFC 2782 menyebutkan alasannya langsung: garis bawah ditambahkan agar label ini tidak bertabrakan dengan nama yang muncul alami di DNS. Tanpa awalan itu, subdomain sip.contoh.com bisa bentrok dengan penanda layanan SIP.

Konvensi itu dibakukan lebih luas oleh RFC 6763 pada Februari 2013. Satu aturan di dalamnya sangat sering disalahpahami: _tcp untuk layanan berbasis TCP, sedangkan _udp untuk semua transport selain TCP — termasuk SCTP. Jadi _udp berfungsi sebagai penampung umum, bukan penyebutan protokol UDP secara harfiah.

Nama layanannya sendiri diambil dari registry resmi yang dikelola IANA, dengan batas maksimal 15 karakter dan hanya boleh memuat huruf, angka, serta tanda hubung. Beberapa nama yang terdaftar di sana beserta portnya:

Menariknya, beberapa label SRV yang paling banyak dipakai justru tidak terdaftar di registry tersebut. _minecraft, _autodiscover, dan _vlmcs — yang terakhir dipakai Windows untuk menemukan server aktivasi KMS — adalah konvensi yang ditetapkan sendiri oleh pembuat perangkat lunaknya. DNS tetap melayaninya, tetapi Anda tidak akan menemukannya di daftar standar mana pun.

Penyimpangan serupa terjadi pada protokolnya. RFC 3263 mendefinisikan _sip._udp, _sip._tcp, dan _sips._tcp untuk SIP, dan tidak pernah mendefinisikan label _tls. Namun Microsoft memakainya, dan catatan itu masih hidup sampai sekarang:

dig +short SRV _sip._tls.microsoft.com

100 1 443 sipdir.online.lync.com.

Prioritas dan Bobot: Dua Angka, Dua Tugas Berbeda

Kedua angka ini berdampingan di setiap SRV record, dan tertukarnya keduanya adalah salah satu kekeliruan paling umum. Cara membedakannya cukup sederhana: prioritas mengatur urutan cadangan, bobot mengatur pembagian beban.

Prioritas bekerja persis seperti pada MX record. Angka yang lebih kecil dicoba lebih dulu, dan klien menuruni tangga ke angka berikutnya hanya kalau tujuan sebelumnya tidak dapat dihubungi. Ini mekanisme failover, yaitu peralihan ke cadangan saat yang utama gagal.

Bobot baru berperan setelah prioritas selesai menyaring. Di antara record yang prioritasnya sama, bobot menentukan seberapa besar peluang masing-masing terpilih. Contoh nyatanya ada di layanan SIP berikut, yang memakai dua record dengan prioritas dan bobot identik:

dig +short SRV _sip._udp.sip.antisip.com

10 50 9090 sip.antisip.com.
10 50 5060 sip.antisip.com.

Karena prioritas keduanya sama-sama 10 dan bobotnya sama-sama 50, klien akan menyebar koneksinya kira-kira seimbang ke port 9090 dan port 5060.

Pembagian itu tidak diserahkan pada tebakan masing-masing klien. RFC 2782 menetapkan langkahnya secara rinci: record berbobot 0 ditaruh di urutan depan, lalu dihitung running sum atau jumlah berjalan dari bobot tiap record. Klien kemudian mengambil bilangan acak seragam antara 0 dan total bobot, lalu memilih record pertama yang jumlah berjalannya sama dengan atau lebih besar dari bilangan tersebut.

Lebih mudah dilihat dengan angka. Misalkan ada tiga record berprioritas 10 dengan bobot 60, 30, dan 10:

Hasilnya, peluang terpilih masing-masing mendekati 60 persen, 30 persen, dan 10 persen — sebanding dengan bobotnya. Inilah cara membagi beban (load balancing) tanpa perangkat penyeimbang khusus.

Prioritas SRV record menentukan urutan cadangan 10, 20, lalu 30; bobot 60, 30, dan 10 membagi beban 60%, 30%, 10%.

Lalu bagaimana dengan bobot 0? RFC 2782 justru menganjurkan memakainya ketika memang tidak ada pemilihan server yang perlu dilakukan, semata agar catatannya lebih enak dibaca manusia. Bila ada record lain yang bobotnya di atas 0, record berbobot 0 nyaris tidak pernah terpilih. Google memakainya untuk layanan kalendernya:

dig +short SRV _caldavs._tcp.google.com

5 0 443 calendar.google.com.

Layanan yang Benar-Benar Memakai SRV Record

Semua catatan berikut dapat Anda tanyakan sendiri lewat dig, dan akan menjawab.

Minecraft Java Edition memakai _minecraft._tcp dengan port bawaan 25565, sehingga pemain cukup mengetik nama domain tanpa nomor port. Server besar seperti Hypixel memakainya:

dig +short SRV _minecraft._tcp.hypixel.net

1 1 25565 mc.hypixel.net.

Dukungan ini hanya ada di Java Edition. Bedrock Edition — versi Windows, konsol, dan ponsel — mengabaikan SRV, sehingga pemainnya tetap harus mengetik nomor port secara manual.

Microsoft Teams memakai satu SRV untuk federasi SIP, yaitu bertukar pesan dengan organisasi lain. Menurut dokumentasi resminya, nilainya adalah prioritas 100, bobot 1, port 5061, target sipfed.online.lync.com. Microsoft menerapkannya sendiri:

dig +short SRV _sipfederationtls._tcp.microsoft.com

100 1 5061 sipfed.online.lync.com.

Outlook mencarinya lewat _autodiscover._tcp di port 443 untuk menemukan pengaturan akun. Menurut dokumentasi Microsoft, SRV adalah cara terakhir yang dicoba Outlook — tiga cara sebelumnya memakai URL langsung dan alias autodiscover. Karena itu SRV berguna justru saat alias tersebut tidak tersedia:

dig +short SRV _autodiscover._tcp.fastmail.com

0 1 443 autodiscover.fastmail.com.

Active Directory adalah pemakai SRV terberat. Layanan Net Logon di tiap domain controller mendaftarkan belasan catatan sekaligus, agar komputer klien menemukan pengendali domain tanpa dikonfigurasi manual. Beberapa yang utama:

Bagian _msdcs di tengah nama itu adalah cabang khusus buatan Microsoft. Alasannya disebutkan langsung di dokumentasinya: implementasi LDAP selain Windows juga berhak mendaftarkan _ldap._tcp, sehingga Microsoft membutuhkan cabang terpisah untuk menandai peran khusus seperti domain controller dan Global Catalog.

Klien email dapat mengonfigurasi dirinya sendiri lewat SRV berkat RFC 6186. Fastmail menyediakannya lengkap, sehingga pengguna cukup memasukkan alamat emailnya:

dig +short SRV _imaps._tcp.fastmail.com
dig +short SRV _submissions._tcp.fastmail.com

0 1 993 imap.fastmail.com.
0 1 465 smtp.fastmail.com.

Selain itu ada XMPP yang mewajibkannya, Matrix untuk federasi antar-server, serta MongoDB yang memakainya lewat skema koneksi mongodb+srv:// sehingga daftar anggota klaster tidak perlu ditulis di aplikasi.

Arti Target Berupa Titik

Ada satu bentuk SRV record yang tampak seperti kesalahan padahal justru disengaja, yaitu target yang hanya berisi sebuah titik. RFC 2782 menetapkan artinya dengan tegas: target . berarti layanan tersebut dinyatakan tidak tersedia di domain itu.

Ini pernyataan aktif, bukan kekosongan. Pemilik domain memberi tahu klien agar berhenti mencoba, alih-alih membiarkannya menunggu sampai kehabisan waktu. Fastmail memakainya untuk mematikan protokol yang tidak terenkripsi:

dig +short SRV _imap._tcp.fastmail.com
dig +short SRV _pop3._tcp.fastmail.com

0 0 0 .
0 0 0 .

Perhatikan bahwa _imaps._tcp di bagian sebelumnya menjawab dengan server sungguhan, sementara _imap._tcp tanpa huruf s dimatikan. Fastmail sedang menyatakan bahwa IMAP polos tidak dilayani.

Bentuk ini sejajar dengan null MX pada MX record, yang juga memakai satu titik untuk menyatakan bahwa sebuah domain sengaja tidak menerima email. Kalau domain Anda menampilkan 0 0 0 . padahal layanannya seharusnya hidup, catatan itulah yang harus dihapus.

Cara Cek SRV Record

SRV record bersifat publik, jadi siapa pun dapat membacanya tanpa masuk ke panel. Tiga perintah berikut memberi jawaban yang sama.

Lewat nslookup

Perintah ini sudah tersedia di Windows tanpa perlu memasang apa pun, dan juga ada di macOS serta Linux:

nslookup -type=srv _sip._tls.microsoft.com

_sip._tls.microsoft.com	service = 100 1 443 sipdir.online.lync.com.

Urutan angkanya adalah prioritas, bobot, port, lalu target. Penjelasan lengkap cara membaca keluaran perintah ini ada di pembahasan nslookup.

Lewat dig

Di macOS dan Linux, dig memberi keluaran paling ringkas dengan opsi +short:

dig +short SRV _matrix._tcp.matrix.org

10 5 8443 matrix-federation.matrix.org.cdn.cloudflare.net.

Tanpa +short, dig juga menampilkan sisa TTL sehingga Anda tahu berapa lama lagi jawaban lama masih tersimpan di cache.

Lewat host

Perintah host memberi keluaran berbentuk kalimat yang paling mudah dibaca sekilas:

host -t SRV _xmpp-client._tcp.jabber.org

_xmpp-client._tcp.jabber.org has SRV record 30 30 5222 scarlet.jabber.org.

Satu hal yang perlu Anda perhatikan sebelum menyimpulkan record tidak ada: nama yang ditanyakan harus lengkap dengan bagian _layanan._protokol. Menanyakan dig SRV jabber.org saja akan menjawab kosong, padahal catatannya jelas ada. Ini penyebab terbanyak laporan "SRV record tidak ketemu" yang sebenarnya keliru.

Cara Menambahkan SRV Record di Panel DNS

Kesulitan memasang SRV umumnya bukan pada konsepnya, melainkan pada bentuk formulir yang berbeda-beda antar panel. Ada dua gaya, dan mencampuradukkan keduanya adalah sumber kegagalan tersering.

Gaya gabung dipakai cPanel. Zone Editor-nya hanya menyediakan empat kolom khusus SRV: Priority, Weight, Port, dan Target. Nama lengkapnya Anda ketik di kolom Name yang dipakai bersama semua jenis record, misalnya _minecraft._tcp.contoh.com.

Gaya terpisah dipakai Cloudflare dan dokumentasi Microsoft. Di sini Service dan Protocol punya kolomnya sendiri: _minecraft masuk ke kolom Service, _tcp ke kolom Protocol. Kolom Name cukup diisi nama host, atau dibiarkan kosong.

Menuliskan _minecraft._tcp di kolom Name pada panel bergaya terpisah menghasilkan nama berlipat seperti _minecraft._tcp._minecraft._tcp.contoh.com. Catatannya tersimpan tanpa pesan error, tetapi tidak akan pernah ditemukan klien. Karena itu periksa selalu hasilnya dengan dig setelah menyimpan.

Nama SRV record ditulis utuh di kolom Name cPanel, dipecah jadi Service dan Protocol di Cloudflare; campurannya berlipat.

Dua hal lain yang perlu Anda siapkan sebelum menyimpan:

1. Target harus sudah punya A record: buat dulu catatan alamat untuk nama host tujuannya. Tanpa itu klien memperoleh nama yang tidak dapat diterjemahkan menjadi alamat.
2. Matikan proxy Cloudflare pada targetnya: Cloudflare menandai SRV sebagai catatan yang tidak dapat diproksikan, sehingga awan oranye pada host tujuan harus diubah menjadi abu-abu. Kekeliruan ini adalah penyebab umum server game yang tidak tersambung meski recordnya terlihat benar di dasbor.

Kalau Anda mengelola sendiri zona DNS lewat BIND9, tidak ada formulir yang perlu ditebak. Barisnya ditulis apa adanya: _minecraft._tcp IN SRV 0 0 25565 mc.contoh.com.

Seperti catatan DNS lainnya, perubahan SRV juga tunduk pada TTL. Turunkan dulu TTL ke 300 detik, tunggu selama durasi TTL lama, baru ubah isinya — rinciannya ada di pengertian propagasi DNS.

Kenapa Website Tidak Memakai SRV Record

Kalau SRV bisa menyembunyikan nomor port, kenapa website yang berjalan di port 8080 tetap harus diakses dengan contoh.com:8080?

Jawabannya sederhana dan agak mengecewakan: browser tidak pernah mengadopsi SRV. Standarnya ada sejak tahun 2000, tetapi tidak satu pun browser besar menanyakan SRV sebelum membuka halaman. Memasang _http._tcp di zona Anda tidak mengubah apa pun.

Minecraft, SIP, dan klien email menanyakan SRV record; browser tidak, dan memakai record HTTPS/SVCB dari RFC 9460.

Kekosongan itu diisi catatan lain, yaitu record HTTPS dan SVCB yang dibakukan RFC 9460 pada November 2023. Dokumen itu menyebut alasannya terbuka: menghadirkan manfaat serupa SRV untuk HTTP, justru karena SRV tidak pernah luas dipakai di sana.

Catatan ini bukan lagi rencana. Domain Indowebsite sendiri sudah menyajikannya:

Isinya memberi tahu browser bahwa situs ini melayani HTTP/2 dan HTTP/3 sebelum koneksi pertama dibuat, lengkap dengan petunjuk alamatnya. Catatan itu tidak pernah dipasang manual — Cloudflare menghasilkannya otomatis ketika Universal SSL aktif pada nama yang diproksikan.

Untuk menyembunyikan port sebuah website, yang Anda butuhkan bukan SRV melainkan reverse proxy di depannya.

Kesalahan yang Sering Terjadi

Berikut kekeliruan yang membuat SRV record tidak berfungsi, diurutkan dari yang paling sering ditemui.

1. Target diisi alamat IP: kolom target hanya menerima nama host. Isi dengan mail.contoh.com, bukan dengan angka alamat IP-nya.
2. Target diarahkan ke CNAME: dilarang RFC 2782. Arahkan ke nama yang memiliki A record langsung.
3. Garis bawah tidak ditulis: minecraft._tcp tanpa garis bawah di depan adalah subdomain biasa, bukan penanda layanan, dan tidak akan pernah ditemukan klien.
4. Protokol keliru: memasang _tcp untuk layanan yang ditanyakan sebagai _udp membuat catatannya tidak terbaca meski isinya benar.
5. SRV dicoba ditulis di file hosts: ini mustahil. Berkas hosts hanya memetakan nama ke alamat IP, dan tidak punya tempat untuk menyimpan port, prioritas, maupun bobot.
6. Nama domain tertulis dua kali: akibat mencampur gaya formulir seperti dijelaskan di bagian sebelumnya.
7. Perubahan dinilai gagal terlalu cepat: jawaban lama masih tersimpan selama TTL sebelumnya belum habis, sehingga pengecekan beberapa menit setelah menyimpan sering menyesatkan.

Hal yang Perlu Anda Pertimbangkan

SRV menyelesaikan satu urusan dengan rapi, tetapi ada lima hal yang berada di luar jangkauannya.

1. Kliennya harus mendukung SRV: catatan ini tidak berguna kalau aplikasinya tidak pernah menanyakannya. Inilah pembatas terbesarnya, dan alasan SRV gagal di dunia web.
2. Ada satu putaran query tambahan: klien menanyakan SRV dulu, baru menanyakan alamat targetnya, baru menyambung. Pada koneksi pertama tambahan ini terasa, meski hasilnya kemudian tersimpan di cache.
3. Isinya terbuka untuk umum: memindahkan layanan ke port tidak lazim lalu mengumumkannya lewat SRV sama sekali bukan bentuk penyembunyian. Siapa pun dapat membacanya dengan satu perintah.
4. Jawabannya bisa dipalsukan: DNS biasa tidak menyertakan bukti keaslian, sehingga jawaban SRV dapat diarahkan ke server lain di jaringan yang tidak tepercaya. Perlindungannya datang dari DNSSEC, bukan dari SRV itu sendiri.
5. Bobot bergantung pada kepatuhan klien: pembagian beban hanya terjadi kalau aplikasinya benar-benar menjalankan algoritma RFC 2782. Sebagian klien menyederhanakannya dengan memilih record pertama, sehingga bobot yang Anda susun tidak selalu dihormati.

Pertanyaan yang Sering Muncul

SRV record singkatan dari apa? SRV adalah singkatan dari Service Record, atau catatan layanan. Namanya menggambarkan fungsinya, yaitu menunjukkan lokasi sebuah layanan, bukan sekadar lokasi sebuah nama.

Bisakah SRV record menyembunyikan port website? Tidak. Browser tidak menanyakan SRV sebelum membuka halaman, sehingga website di port tidak lazim tetap harus diakses lengkap dengan nomornya. Untuk keperluan itu Anda membutuhkan reverse proxy, bukan catatan DNS.

Kenapa SRV record sudah dibuat tapi tidak berfungsi? Ada tiga sebab yang paling sering. Nama domainnya tertulis dua kali karena gaya formulir panel tercampur, target belum punya A record, atau target masih diproksikan Cloudflare. Periksa hasilnya dengan dig memakai nama lengkap berikut bagian _layanan._protokol.

Apa bedanya SRV record dengan CNAME? CNAME hanya menyatakan bahwa sebuah nama merupakan alias dari nama lain, tanpa menyebut port maupun urutan prioritas. SRV menyebut layanan, host, port, prioritas, dan bobot sekaligus. Keduanya juga tidak boleh digabung, karena target SRV dilarang menunjuk ke sebuah CNAME.

Bisakah SRV record ditulis di file hosts? Tidak bisa. Berkas hosts hanya mampu memetakan nama ke alamat IP, sehingga tidak ada tempat untuk menuliskan port, prioritas, maupun bobot. SRV hanya dapat disimpan di zona DNS.

Kesimpulan

SRV record adalah catatan DNS yang menyebutkan sebuah layanan berjalan di host mana dan di port berapa, dan kolom port itulah yang tidak dimiliki jenis catatan lain. Dua angka di dalamnya punya tugas terpisah: prioritas menentukan urutan cadangan, sedangkan bobot membagi beban di antara tujuan yang prioritasnya sama.

Perlu tidaknya Anda memasangnya ditentukan satu hal saja, yaitu apakah aplikasi yang dipakai memang menanyakan SRV. Untuk server Minecraft, layanan SIP, XMPP, klien email, dan jaringan Active Directory, jawabannya ya. Untuk website, jawabannya tidak, dan urusan itu sudah diambil alih record HTTPS yang umumnya dihasilkan penyedia CDN Anda secara otomatis.

Semoga artikel ini membantu.