Beranda › Panduan

Apa Itu DNSBL (RBL)? Cara Kerja Blacklist DNS

Diterbitkan 2026-11-03 ／ Diperbarui 2026-11-03 ／ Oleh Yuki Nakazawa

DNSBL (DNS-based blacklist, disebut juga DNS blocklist atau RBL) adalah daftar alamat IP atau nama domain yang dianggap oleh operator daftar sebagai sumber spam atau penyalahgunaan, dan dipublikasikan agar siapa pun dapat memeriksanya dengan kueri DNS biasa. Server email memeriksa setiap pengirim yang terhubung di satu atau beberapa DNSBL, lalu menolak pesan, menerimanya, atau menambahkan hasilnya ke skor spam.

Panduan ini menjelaskan cara kerja kueri DNSBL (alamat IP yang dibalik, record A dan TXT, format nibble IPv6), perbedaan antara daftar berbasis IP dan berbasis domain, cara penerima sebenarnya memakai jawabannya, perbedaan blacklist dan whitelist, alasan sebuah alamat masuk daftar, serta posisi pencantuman di antara penyebab email tidak terkirim. Panduan ini disusun berdasarkan RFC 5782 dan dokumentasi resmi operator daftar utama per November 2026.

Arti DNSBL dan RBL

RFC 5782, "DNS Blacklists and Whitelists", memakai istilah payung DNSxL untuk zona DNS yang record-nya mengidentifikasi host dalam sebuah daftar. Blacklist disebut DNSBL; whitelist disebut DNSWL. Keduanya dibangun dengan cara yang sama. Yang berbeda hanyalah makna yang diberikan penerima terhadap sebuah kecocokan.

RBL adalah singkatan dari Real-time Blackhole List. Menurut RFC tersebut, daftar pertama jenis ini dimulai pada tahun 1997 dan dikenal dengan nama itu. Secara ketat, RBL merujuk pada daftar asli tersebut dan penerusnya, dan RFC mencatat bahwa istilah ini merupakan merek layanan terdaftar di Amerika Serikat. Namun, dalam penggunaan sehari-hari, "RBL" dan "DNSBL" dipakai hampir secara bergantian, sehingga "apa itu RBL" dan "apa itu DNSBL" pada dasarnya adalah pertanyaan yang sama.

RFC 5782 adalah dokumen Informational, bukan standar Internet. Dokumen ini disusun oleh IRTF Anti-Spam Research Group dan mewakili konsensus kelompok tersebut tentang praktik yang meningkatkan interoperabilitas antara blacklist dan whitelist DNS. Dokumen ini tidak menjelaskan atau merekomendasikan kebijakan untuk menambahkan atau menghapus alamat; RFC mengharapkan hal itu dibahas dalam dokumen terpisah. Dalam praktiknya, setiap operator menetapkan kebijakan pencantuman dan penghapusannya sendiri.

Cara kerja kueri DNSBL

Kueri DNSBL adalah kueri DNS biasa, sehingga pengecekan manual tidak memerlukan software khusus: apa pun yang dapat me-resolve nama dapat melakukan kueri ke sebuah daftar. Meski begitu, operator daftar dapat menetapkan ketentuan penggunaan. Server publik Spamhaus, misalnya, hanya gratis untuk penggunaan nonkomersial bervolume rendah, dan kueri melalui resolver publik tidak dijawab secara andal (lihat di bawah).

IPv4: balik alamatnya lalu tambahkan zona

Untuk alamat IPv4, tulis keempat oktet dalam urutan terbalik lalu tambahkan nama zona daftar. Strukturnya meminjam dari reverse DNS. Contoh dalam RFC 5782 memeriksa 192.0.2.99 terhadap daftar di bad.example.com dengan kueri berikut:

99.2.0.192.bad.example.com

Record A menyatakan "tercantum", record TXT menjelaskan alasannya

• Record A. Setiap entri yang tercantum harus memiliki record A. Menurut konvensi, nilainya 127.0.0.2. Nilai ini adalah sinyal, bukan alamat, dan tidak boleh dipakai sebagai alamat; daftar memakai rentang 127.0.0.0/8 agar nilai yang terpakai secara keliru tidak menimbulkan lalu lintas jaringan yang tidak diinginkan.
• Tidak tercantum. Jika alamat tidak ada di daftar, tidak ada record untuknya, sehingga kueri biasanya mengembalikan NXDOMAIN.
• Record TXT. DNSBL sebaiknya memublikasikan record TXT yang menjelaskan alasan pencantuman. Klien harus memeriksa record A dan boleh juga memeriksa record TXT.
• Nilai berbeda untuk subdaftar berbeda. Daftar gabungan dapat mengembalikan nilai 127.0.0.x yang berbeda untuk menunjukkan subdaftar mana yang cocok, atau beberapa record A sekaligus. Maknanya khusus untuk setiap daftar, jadi selalu baca dokumentasi operatornya. Panduan kami tentang kode balasan DNSBL membahas kode-kode yang umum.

Dari terminal (zona di sini hanya contoh):

dig +short 99.2.0.192.bad.example.com A
dig +short 99.2.0.192.bad.example.com TXT

Entri uji

RFC 5782 mewajibkan daftar IPv4 memuat entri untuk 127.0.0.2 dan tidak memuat entri untuk 127.0.0.1. Klien diharapkan memeriksa entri uji ini sebelum memercayai sebuah zona, dan tidak memakai zona yang menjawabnya secara keliru.

IPv6: format nibble

Alamat IPv6 ditulis lengkap sebagai 32 digit heksadesimal, lalu dibalik satu digit (satu nibble) demi satu digit dengan titik di antara setiap digit, diikuti zona daftar. Contoh dari RFC untuk 2001:db8:1:2:3:4:567:89ab di ugly.example.com:

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ugly.example.com

Daftar IPv6 harus memuat entri uji ::FFFF:7F00:2 (127.0.0.2 sebagai alamat IPv4-mapped) dan tidak boleh memuat ::FFFF:7F00:1. Tidak semua daftar mendukung IPv6, jadi periksa dokumentasi operator sebelum mengandalkan kueri IPv6.

Daftar berbasis IP dan berbasis domain

Secara garis besar, daftar terbagi menjadi dua jenis menurut isinya.

Dalam contoh domain di RFC 5782, invalid.edu diperiksa terhadap doms.example.net dengan kueri invalid.edu.doms.example.net. Daftar berbasis domain kadang disebut RHSBL (right-hand-side blacklist). Entri ujinya memakai nama yang dicadangkan: daftar harus memuat TEST dan tidak boleh memuat INVALID.

Spamhaus Domain Blocklist (dbl.spamhaus.org) adalah contoh yang banyak dipakai, dan dokumentasinya menyampaikan beberapa poin praktis:

• Daftar ini khusus domain. Kueri dengan alamat IP selalu mengembalikan kode "tercantum", sehingga daftar ini tidak boleh dikonfigurasi sebagai DNSBL IP generik. Spamhaus menyarankan ZEN (zen.spamhaus.org) untuk kueri IP.
• Anda dapat melakukan kueri dengan hostname lengkap; hasilnya cocok jika domain dari host tersebut tercantum.
• Selama sesi SMTP, daftar ini diperiksa terhadap string HELO dan domain MAIL FROM. Setelah pesan diterima, daftar ini diperiksa terhadap domain di header dan isi pesan, seperti URL dan alamat kontak.

Konsekuensi praktisnya: IP pengirim yang bersih tidak menjamin email terkirim. Domain pengirim yang tercantum, atau domain tercantum yang ditautkan di dalam pesan, tetap dapat menyebabkan pemblokiran.

Cara server penerima memakai DNSBL

RFC 5782 menjelaskan pengaturan yang umum. Server email memeriksa sekumpulan DNSxL yang dikonfigurasi pada setiap koneksi SMTP yang masuk. Kecocokan di blacklist membuatnya menolak koneksi; kecocokan di whitelist membuatnya menerima. Sebagai alternatif, hasilnya dimasukkan ke fungsi penilaian (scoring) yang menimbangnya bersama sinyal lain. Filter yang berjalan setelah pesan diterima biasanya mengambil IP yang akan diuji dari kolom header Received atau dari URI di isi pesan.

Menolak atau memberi skor?

Pilihan itu ada di tangan penerima. FAQ SpamCop sendiri menyebut daftarnya sebagai alat yang agresif dan menyarankan untuk menandai atau mengalihkan email yang diduga spam, atau memakai daftar sebagai salah satu faktor dalam skor, alih-alih langsung menolak email. FAQ tersebut menggambarkan pengaturan penolakan sebagai informasi bagi administrator yang tidak dapat memakai pendekatan yang lebih halus.

Jebakan yang diperingatkan kepada penerima

• Anda mendelegasikan penilaian. Memakai DNSxL berarti menyerahkan sebagian pengelolaan server Anda kepada operator daftar. RFC menyatakan bahwa Anda harus memastikan kebijakan daftar tersebut sejalan dengan kebijakan Anda sendiri.
• Daftar yang sudah mati. Operator yang menghentikan sebuah daftar mungkin memasang wildcard yang mencantumkan setiap alamat. Entri uji di atas adalah cara klien menyadari hal ini.
• Cache. Server boleh menyimpan hasil dalam cache, tetapi harus mematuhi TTL dan membuang record yang sudah kedaluwarsa.
• Resolver publik. FAQ Spamhaus menyebutkan bahwa kueri melalui Google Public DNS dalam sebagian besar kasus akan mengembalikan "tidak tercantum", sehingga pencantuman yang sebenarnya terlewat. Kode dalam rentang 127.255.255.x adalah galat, seperti 127.255.255.254 untuk kueri melalui resolver publik yang diblokir, dan tidak boleh dibaca sebagai "tercantum". Spamhaus mencatat bahwa sebagian server keliru menolak semua email karena hal ini dan menyarankan Anda menjalankan resolver sendiri.

Inilah salah satu alasan dua alat pengecekan bisa memberikan hasil berbeda untuk alamat yang sama: keduanya mungkin bertanya melalui resolver yang berbeda.

Blacklist vs whitelist (DNSBL vs DNSWL)

DNSBL dan DNSWL dikueri dengan cara yang sama, tetapi kecocokan berarti kebalikannya. Menurut RFC 5782, pengelola jaringan biasanya memakai DNSBL untuk memblokir lalu lintas dan DNSWL untuk mengutamakan penerimaan lalu lintas. Daftar yang sama bahkan dapat berfungsi sebagai blacklist dalam satu konteks dan sebagai whitelist dalam konteks lain.

dnswl.org (list.dnswl.org) adalah contoh whitelist. Dokumentasinya menyebutkan bahwa jawaban berbentuk 127.0.x.y, dengan x sebagai kategori dan y sebagai tingkat kepercayaan dari 0 (tidak ada) hingga 3 (tinggi). Dokumentasi itu menyarankan agar host yang tercantum dilewatkan dari greylisting dan pengecekan blacklist, host dengan tingkat kepercayaan sedang dan tinggi dilewatkan dari penyaringan spam, dan pemindaian virus tidak pernah dilewati. Seberapa besar pengecualian yang diberikan entri whitelist tetap merupakan keputusan penerima.

Alasan umum IP atau domain masuk daftar

Setiap operator menetapkan kriterianya sendiri, dan banyak yang merahasiakan pemicu persisnya. Alasan-alasan di bawah ini berasal dari dokumentasi yang dipublikasikan para operator.

• Laporan spam dan spam trap. SpamCop Blocking List memuat IP yang mengirim email yang dilaporkan oleh pengguna SpamCop, dengan bobot tambahan untuk email ke spam trap (alamat yang dikumpulkan atau dibuat oleh spammer). FAQ-nya menyebutkan bahwa tanpa laporan lebih lanjut, pencantuman hanya berlangsung 24 jam, dan alamat dihapus secara otomatis ketika laporan berhenti.
• Perangkat yang terinfeksi atau disusupi. Spamhaus XBL mencantumkan IP secara otomatis berdasarkan bukti seperti malware, aplikasi "VPN gratis" yang meneruskan lalu lintas pihak ketiga melalui perangkat, keterlibatan dalam serangan brute-force, atau upaya meneruskan email dengan kredensial curian. Jika penyebabnya masih ada, IP akan dicantumkan lagi saat terhubung berikutnya.
• Kesalahan konfigurasi dan pengelolaan daftar penerima yang buruk. Spamhaus CSS menyebutkan nama HELO yang tidak cocok dengan DNS forward, situs web dan instalasi CMS yang disusupi, konfigurasi yang tidak aman, serta mailing list yang tidak terawat. CSS menyatakan bahwa penyebabnya harus diidentifikasi dan diperbaiki sebelum penghapusan.
• Pencantuman berdasarkan kebijakan. Spamhaus PBL mencakup ruang alamat, sering kali broadband rumahan, yang tidak semestinya mengirim email secara langsung. Spamhaus menyatakan bahwa pencantuman PBL bukan akibat dari tindakan pengguna akhir; email dari rentang tersebut diharapkan keluar melalui server SMTP dengan autentikasi.
• Infrastruktur bersama. Pada shared hosting, pengiriman oleh pelanggan lain dapat memengaruhi IP yang Anda pakai. Lihat apa yang harus dilakukan jika IP shared hosting masuk blacklist.

Posisi DNSBL ketika email tidak terkirim

Pencantuman di DNSBL adalah salah satu kemungkinan penyebab email tidak terkirim, bukan satu-satunya. Alamat yang salah, kotak surat penuh, masalah di sisi penerima, dan autentikasi yang tidak ada juga dapat menyebabkan bounce. Jika sebuah daftar terlibat, pesan bounce sering menyebutkan nama daftarnya atau menyertakan URL pengecekan.

1. Baca pesan bounce. Catat kode balasan serta nama daftar atau URL apa pun yang ada dalam teks.
2. Identifikasi IP dan domain pengirim Anda. Gunakan baris Received di header, atau tanyakan kepada pengelola server.
3. Periksa daftar-daftar utama sekaligus. Gunakan pemeriksa blacklist, lalu konfirmasikan setiap kecocokan di halaman pengecekan milik operator.
4. Atasi penyebabnya. Telusuri penyebab-penyebab di atas. Permintaan yang diajukan sebelum penyebabnya diatasi biasanya berakhir dengan pencantuman ulang.
5. Ikuti proses operator tersebut. Sebagian daftar kedaluwarsa dengan sendirinya, sebagian menerima permintaan penghapusan, dan sebagian hanya menerima permintaan dari pemilik jaringan. Keputusan penghapusan selalu berada di tangan operator daftar, dan permintaan bukanlah jaminan penghapusan.

Penerima juga menjalankan penyaringan sendiri, sehingga email mungkin tidak langsung mengalir kembali begitu pencantuman berakhir. Untuk urutan pemecahan masalah selengkapnya, lihat email masuk blacklist: cara membaca pesan bounce, dan untuk autentikasi, lihat pengaturan SPF, DKIM, dan DMARC. Jika Anda tidak dapat menemukan penyebabnya sendiri, Anda dapat meminta bantuan kami.

Tanya jawab

Halaman resmi yang digunakan

Fakta dalam artikel ini telah diperiksa berdasarkan halaman resmi di bawah ini pada saat diterbitkan. Kebijakan dan perilaku layanan dapat berubah tanpa pemberitahuan, jadi periksa halaman resmi sebelum mengandalkan informasi yang penting.

• RFC 5782: DNS Blacklists and Whitelists
• Spamhaus FAQ: DNSBL Usage
• Spamhaus: Domain Blocklist (DBL)
• Spamhaus: Exploits Blocklist (XBL)
• Spamhaus: Combined Spam Sources (CSS)
• Spamhaus: Policy Blocklist (PBL)
• SpamCop FAQ: What is the SpamCop Blocking List (SCBL)?
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?
• dnswl.org: Return codes and recommended usage

Panduan terkait

Semua panduan →