Setiap kali pelanggan mengetik alamat situs pada browser, ada satu layanan senyap yang bekerja lebih dulu sebelum halaman benar-benar tampil. Layanan itu bernama DNS, dan bagi pengelola RT-RW Net maupun ISP kecil, mengaktifkan DNS server Mikrotik termasuk optimasi paling murah sekaligus paling terasa hasilnya. RouterOS sudah membawa fitur resolver ini sejak versi lama, namun banyak teknisi hanya mengisi kolom Servers lalu melupakan sisanya. Padahal di balik kolom sederhana itu tersimpan cache, entri statis, dan satu celah keamanan yang sanggup mengubah router Anda menjadi senjata bagi penyerang.
Saya mengelola jaringan dengan ratusan pelanggan PPPoE, dan pengalaman lapangan menunjukkan bahwa keluhan “internet lemot” sering kali bukan soal kapasitas bandwidth. Sebagian besar keluhan justru lahir dari resolusi nama yang lambat, karena router meneruskan setiap permintaan ke server publik tanpa menyimpan apa pun. Begitu cache aktif dan perangkat menjawab sendiri permintaan berulang, waktu buka halaman turun drastis meski uplink tidak bertambah satu megabit pun. Perbedaan itu terasa paling jelas pada jam sibuk ketika ratusan perangkat meminta nama domain yang sama berulang-ulang.
Panduan ini membahas fitur resolver dari hulu ke hilir: pengertian, alur resolusi bertingkat, konfigurasi lengkap, pengamanan port 53, entri statis, sampai pemaksaan klien lewat NAT. Bagian terakhir sengaja saya tulis apa adanya soal DoH, karena banyak tutorial lain melewatkannya padahal dampaknya sangat nyata pada jaringan produksi hari ini.
Pengertian DNS Server Mikrotik dan Fungsinya
DNS server Mikrotik adalah fitur bawaan RouterOS yang membuat router bertindak sebagai penerjemah nama domain menjadi alamat IP sekaligus penyimpan hasil terjemahan tersebut di dalam cache. Manusia mengingat nama seperti mikrotikpedia.com, sedangkan perangkat jaringan hanya mengenal angka seperti 103.23.198.182. DNS berdiri persis di tengah keduanya sebagai buku telepon raksasa yang tersebar di seluruh dunia. Tanpa layanan ini, pelanggan harus menghafal deretan angka untuk setiap situs yang ingin mereka buka.
Pada RouterOS, seluruh pengaturan resolver berkumpul di menu /ip dns. Di sana Anda menemukan daftar server hulu, ukuran cache, batas TTL, serta sakelar allow-remote-requests yang menentukan apakah perangkat lain boleh bertanya kepada router. Menu turunannya, /ip dns static, menyimpan pemetaan manual antara nama dan alamat. Kombinasi keduanya membuat sebuah router kecil seharga dua juta rupiah mampu melayani ratusan klien tanpa server tambahan.
Perlu Anda bedakan dua peran yang sering tertukar. Peran pertama adalah DNS client, yaitu ketika router memakai alamat resolver untuk keperluan dirinya sendiri seperti mengunduh paket upgrade atau menjalankan /tool fetch. Peran kedua adalah DNS resolver untuk jaringan, yaitu ketika router menerima pertanyaan dari klien lalu menjawabnya. Sakelar allow-remote-requests inilah yang memisahkan kedua peran tersebut, dan salah paham soal ini menjadi sumber masalah paling sering di lapangan. Sebelum melangkah lebih jauh, ada baiknya Anda menyegarkan pemahaman tentang dasar pengalamatan IP dan pembagian kelasnya.

Cara Kerja Resolusi DNS Bertingkat
Proses penerjemahan nama berlangsung bertingkat dan melibatkan beberapa lapisan server yang berbeda tugas. Ketika laptop pelanggan meminta mikrotikpedia.com, permintaan itu pertama-tama mendarat di router sebagai resolver terdekat. Router memeriksa isi cache miliknya; apabila jawaban masih tersimpan dan belum kedaluwarsa, jawaban langsung meluncur kembali dalam hitungan mikrodetik. Situasi inilah yang membuat halaman yang sering dibuka terasa jauh lebih responsif dibanding kunjungan pertama.
Bila cache kosong, barulah router menempuh jalur panjang. Permintaan berjalan ke resolver hulu, misalnya milik Google atau Cloudflare, yang kemudian bertanya kepada root server untuk mengetahui siapa pengelola akhiran .com. Root server menunjuk ke TLD server, dan TLD server menunjuk lagi ke authoritative server milik pemilik domain. Authoritative server memberikan jawaban final berupa alamat IP, lalu jawaban itu mengalir balik melewati rantai yang sama sampai tiba di laptop pelanggan.
Seluruh rantai tadi memakan waktu antara 30 sampai 300 milidetik tergantung jarak dan kualitas uplink. Router menyimpan hasilnya sesuai nilai TTL yang domain tersebut tetapkan, sehingga permintaan kedua dan seterusnya selesai secara lokal. Sebuah halaman berita modern memanggil 40 sampai 80 nama domain berbeda untuk gambar, skrip, dan iklan; menghemat 100 milidetik pada tiap nama berarti menghemat beberapa detik penuh. Angka itulah yang pelanggan rasakan sebagai “koneksi terasa ringan” walau paket kecepatannya tidak berubah.
Kelebihan dan Kekurangan DNS Server Mikrotik
Memakai DNS server Mikrotik bukan keputusan tanpa konsekuensi. Ada alasan kuat memilihnya, ada pula kondisi ketika mengarahkan pelanggan langsung ke resolver publik justru lebih bijak. Tabel berikut merangkum perbandingan yang saya susun dari pengalaman mengoperasikan beberapa jaringan komunitas.
| Aspek | Resolver di Router | Langsung ke DNS Publik |
|---|---|---|
| Latensi permintaan berulang | Sangat rendah, dijawab dari cache lokal | Selalu keluar ke internet |
| Konsumsi bandwidth uplink | Hemat, terutama saat jam sibuk | Boros paket kecil bervolume tinggi |
| Kontrol administrator | Penuh, bisa blokir dan petakan nama lokal | Nyaris nol |
| Nama lokal seperti NVR atau server billing | Bisa lewat entri statis | Tidak mungkin |
| Beban CPU router | Naik saat klien banyak | Tidak ada |
| Risiko keamanan | Ada, bila port 53 terbuka ke internet | Minim di sisi router |
| Ketergantungan | Router mati berarti seluruh jaringan buta | Klien tetap jalan selama uplink hidup |
Keunggulan terbesar terletak pada kontrol. Anda bisa memetakan billing.rtrwnet.lan ke alamat internal, memblokir domain iklan, atau mengarahkan seluruh pelanggan ke halaman pemberitahuan saat tagihan menunggak. Kelemahan terbesar terletak pada ketergantungan tunggal: begitu perangkat utama bermasalah, pelanggan mengeluh “tidak bisa browsing” meski ping ke alamat angka masih lancar. Router kelas RB750 atau hEX masih nyaman menjalankan DNS server Mikrotik untuk 200 klien, tetapi di atas angka itu saya sarankan memisahkan resolver ke mesin tersendiri.
Persiapan Sebelum Mengaktifkan Fitur Resolver
Siapkan dulu beberapa hal supaya konfigurasi berjalan mulus tanpa memutus koneksi pelanggan. Pertama, pastikan router sudah memiliki koneksi internet yang stabil dan alamat gateway yang benar, karena resolver tanpa uplink hanya menghasilkan timeout. Kedua, catat topologi jaringan Anda: interface mana menghadap ISP dan interface mana menghadap pelanggan. Ketiga, siapkan akses Winbox cadangan lewat MAC address, sebab kesalahan pada rule firewall port 53 bisa membuat Anda kehilangan kendali sementara.
Versi RouterOS juga menentukan seberapa lengkap kemampuan DNS server Mikrotik yang bisa Anda pakai. Parameter match-subdomain dan tipe entri NXDOMAIN pada entri statis hanya muncul di RouterOS 7, sedangkan RouterOS 6 hanya mengenal regexp untuk pencocokan pola. Dukungan DoH di sisi router sendiri mulai hadir sejak versi 6.47. Bila perangkat Anda masih memakai firmware lama, luangkan waktu membaca prosedur upgrade RouterOS yang aman sebelum melanjutkan.
Tentukan pula resolver hulu yang akan router pakai. Pilihan populer meliputi Google pada 8.8.8.8 dan 8.8.4.4, Cloudflare pada 1.1.1.1, atau resolver milik upstream ISP Anda yang biasanya paling dekat secara jaringan. Saya biasa memasang dua alamat dari penyedia berbeda supaya kegagalan satu pihak tidak melumpuhkan seluruh pelanggan. Untuk jaringan komunitas, resolver milik ISP hulu sering memberi respons paling cepat karena jaraknya hanya satu atau dua hop.
Cara Setting DNS Server Mikrotik Langkah demi Langkah
Rangkaian langkah berikut memandu Anda membangun DNS server Mikrotik dari konfigurasi paling dasar hingga pengamanan penuh. Jalankan perintah lewat terminal Winbox atau SSH, dan periksa hasilnya setelah setiap langkah. Urutan berikut sengaja saya susun agar router tidak pernah berada dalam kondisi terbuka tanpa pelindung, bahkan untuk sesaat.
Langkah 1: Menetapkan Alamat Resolver Hulu
Mulailah dengan mengisi daftar server hulu pada menu utama. Perintah di bawah menetapkan dua resolver publik sekaligus mengizinkan router memakai alamat yang ISP berikan lewat DHCP client apabila Anda memang menginginkannya. Nilai use-peer-dns sebaiknya Anda matikan agar daftar server tidak berubah sendiri ketika ISP mengganti konfigurasi.
/ip dns set servers=8.8.8.8,1.1.1.1 /ip dhcp-client set [find interface=ether1] use-peer-dns=no /ip dns print
Perintah /ip dns print menampilkan ringkasan seluruh parameter aktif. Perhatikan baris dynamic-servers; kalau baris itu masih terisi padahal Anda sudah mematikan use-peer-dns, kemungkinan besar ada koneksi PPPoE client atau DHCP client lain yang masih menyuntikkan alamat. Uji hasilnya dengan resolusi sederhana dari terminal router.
:put [:resolve mikrotikpedia.com]
Langkah 2: Mengaktifkan allow-remote-requests
Sampai tahap ini router baru melayani dirinya sendiri. Agar perangkat pelanggan boleh bertanya, aktifkan sakelar allow-remote-requests lalu arahkan klien ke alamat LAN router. Pengarahan itu Anda lakukan lewat DHCP server untuk jaringan kabel dan WiFi, serta lewat profil PPP untuk pelanggan PPPoE.
/ip dns set allow-remote-requests=yes /ip dhcp-server network set [find address=192.168.10.0/24] dns-server=192.168.10.1 /ppp profile set [find name=default-encryption] dns-server=192.168.10.1
Sesuaikan alamat 192.168.10.1 dengan IP router pada sisi pelanggan. Setelah perintah berjalan, pelanggan yang memperbarui lease DHCP akan menerima router sebagai resolver utama mereka. Bagi pengguna PPPoE, profil baru berlaku setelah sesi mereka terputus dan tersambung ulang, jadi jangan heran bila perubahan belum terasa seketika. Detail pengelolaan profil semacam ini saya bahas lebih dalam pada panduan membangun PPPoE server di RouterOS.
Langkah 3: Mengamankan Port 53 dengan Firewall Filter
Inilah langkah yang paling sering orang lewatkan, dan akibatnya paling mahal. Sakelar allow-remote-requests tidak membedakan asal permintaan; router akan menjawab siapa pun yang bertanya, termasuk mesin asing dari internet. Kondisi terbuka semacam itu mengubah perangkat Anda menjadi open resolver yang penyerang manfaatkan untuk DNS amplification attack, yaitu teknik memperbesar volume serangan dengan memalsukan alamat pengirim.
Solusinya sederhana: izinkan port 53 hanya dari arah pelanggan, lalu tolak dari arah internet. Gunakan interface list supaya rule tetap ringkas walaupun Anda memiliki banyak interface. Perhatikan urutan rule, karena firewall RouterOS membaca dari atas ke bawah dan berhenti pada kecocokan pertama.
/interface list add name=WAN /interface list add name=LAN /interface list member add list=WAN interface=ether1 /interface list member add list=LAN interface=bridge1 /ip firewall filter add chain=input action=accept protocol=udp dst-port=53 in-interface-list=LAN comment="Izinkan DNS dari pelanggan" add chain=input action=accept protocol=tcp dst-port=53 in-interface-list=LAN add chain=input action=drop protocol=udp dst-port=53 in-interface-list=WAN comment="Tolak DNS dari internet" add chain=input action=drop protocol=tcp dst-port=53 in-interface-list=WAN
Setelah rule aktif, mintalah teman menguji router Anda dari jaringan luar memakai perintah dig atau nslookup. Hasil yang benar adalah timeout, bukan jawaban. Langkah pengerasan lain seperti membatasi akses Winbox dan mematikan layanan yang tidak terpakai bisa Anda pelajari pada artikel pengamanan router Mikrotik dari serangan luar.
Langkah 4: Membuat Static DNS Entry untuk Nama Lokal
Entri statis memetakan nama pilihan Anda ke alamat IP tertentu tanpa melibatkan internet sama sekali. Fitur ini sangat membantu di jaringan RT-RW Net yang memiliki perangkat internal seperti NVR CCTV, server billing, atau mesin voucher. Teknisi cukup mengetik nama yang mudah diingat alih-alih menghafal deretan angka pada setiap kunjungan lapangan.
/ip dns static add name=router.rtrwnet.lan address=192.168.10.1 ttl=1d comment="Gateway utama" add name=nvr.rtrwnet.lan address=192.168.10.20 ttl=1d comment="NVR CCTV" add name=billing.rtrwnet.lan address=192.168.10.30 ttl=1d comment="Server billing" /ip dns static print
Nilai ttl menentukan berapa lama klien menyimpan jawaban tersebut. Angka satu hari terasa pas untuk perangkat internal yang alamatnya jarang berubah. Bila Anda sedang memindahkan server, turunkan nilainya menjadi 5m beberapa hari sebelum migrasi supaya klien cepat mengikuti alamat baru. Pastikan pula akhiran nama yang Anda pilih tidak bentrok dengan domain publik yang benar-benar ada.
Langkah 5: Memblokir Domain lewat Entri Statis
Entri statis juga berfungsi sebagai alat pemblokiran yang sangat ringan. Prinsipnya, Anda mengarahkan domain terlarang ke alamat kosong seperti 127.0.0.1 sehingga browser pelanggan tidak pernah menemukan server aslinya. RouterOS 7 menyediakan cara yang lebih rapi lewat tipe NXDOMAIN dan parameter match-subdomain yang menjangkau seluruh anak domain sekaligus.
/ip dns static add name=doubleclick.net type=NXDOMAIN match-subdomain=yes comment="Blokir iklan" add name=situsterlarang.example address=127.0.0.1 match-subdomain=yes comment="Blokir konten"
Metode ini murah secara CPU karena router hanya membandingkan string, bukan membedah isi paket. Kelemahannya jelas: pelanggan yang mengganti resolver di perangkat mereka langsung lolos dari saringan. Karena itu pemblokiran berbasis nama sebaiknya Anda gabungkan dengan pendekatan lain, dan perbandingan lengkap antar metode sudah saya tulis pada panduan memblokir situs di RouterOS dengan berbagai teknik.
Langkah 6: Mengarahkan Paksa Klien ke DNS Server Mikrotik
Sebagian pelanggan mengganti resolver perangkat mereka menjadi 8.8.8.8, entah karena mengikuti tutorial di internet atau karena sengaja menghindari pemblokiran. Anda bisa membelokkan semua permintaan port 53 kembali ke router memakai action redirect pada chain dstnat. Teknik ini bekerja di lapisan transport, jadi klien tetap merasa berbicara dengan alamat pilihannya.
/ip firewall nat add chain=dstnat action=redirect to-ports=53 protocol=udp dst-port=53 in-interface-list=LAN comment="Belokkan DNS pelanggan" add chain=dstnat action=redirect to-ports=53 protocol=tcp dst-port=53 in-interface-list=LAN
Letakkan kedua rule tersebut di urutan atas chain dstnat agar tidak tertutup rule lain seperti port forwarding. Sesudah rule aktif, pantau counter paketnya lewat /ip firewall nat print stats untuk melihat seberapa banyak pelanggan yang sebenarnya memakai resolver luar. Angka counter yang tinggi biasanya menandakan banyak perangkat memakai pengaturan bawaan pabrik yang mengunci alamat tertentu.
Langkah 7: Mengatur Cache Size dan TTL
Ukuran cache bawaan DNS server Mikrotik hanya 2048 KiB dan terasa sempit begitu jumlah klien menembus seratus. Naikkan nilainya sesuai kapasitas RAM perangkat, lalu batasi umur maksimum entri supaya jawaban basi tidak bertahan terlalu lama. Router dengan RAM 256 MB masih nyaman memakai cache 8192 KiB tanpa mengganggu layanan lain.
/ip dns set cache-size=8192 cache-max-ttl=1d /ip dns cache print /ip dns print
Parameter cache-max-ttl memotong TTL yang terlalu panjang dari domain sumber. Nilai satu hari menjaga keseimbangan antara efisiensi dan kesegaran data. Ketika Anda mengubah entri statis atau curiga ada jawaban keliru yang menempel, bersihkan isi cache dengan satu perintah singkat.
/ip dns cache flush
Bahaya DNS Amplification pada DNS Server Mikrotik
Serangan amplifikasi memanfaatkan sifat protokol DNS yang memakai UDP tanpa proses jabat tangan. Penyerang mengirim pertanyaan kecil berukuran 60 byte ke ribuan open resolver sambil memalsukan alamat pengirim menjadi alamat korban. Setiap resolver membalas dengan jawaban yang jauh lebih besar, kadang mencapai 4000 byte, dan seluruh balasan itu membanjiri korban. Rasio penguatan puluhan kali lipat membuat teknik ini sangat digemari pelaku DDoS.
Bagi Anda sebagai pemilik router, kerugiannya berlapis. Uplink terkuras oleh trafik yang tidak menghasilkan apa pun bagi pelanggan, CPU perangkat memanas melayani permintaan asing, dan alamat IP publik Anda berpotensi masuk daftar hitam. Saya pernah menemukan hEX milik rekan yang mengirim 30 Mbps balasan DNS ke luar sementara pelanggannya mengeluh koneksi tersendat. Penyebabnya cuma satu centang allow-remote-requests tanpa satu pun rule pelindung.
Deteksinya mudah. Periksa apakah DNS server Mikrotik Anda sedang melayani orang asing lewat /ip firewall connection print lalu saring koneksi dengan port tujuan 53, atau jalankan /tool torch pada interface WAN dan amati lonjakan trafik UDP. Bila Anda melihat ribuan koneksi dari alamat publik acak, segera pasang rule drop seperti pada Langkah 3. Sebagai lapisan tambahan, pertimbangkan pembatasan laju dengan action=drop berbasis connection limit untuk menahan lonjakan mendadak.
Keterbatasan DoH terhadap DNS Server Mikrotik
Bagian ini perlu saya tulis terus terang, karena banyak panduan menjanjikan pemaksaan DNS yang sebenarnya sudah tidak sepenuhnya berlaku. DNS over HTTPS, atau DoH, membungkus permintaan nama ke dalam koneksi HTTPS biasa pada port 443. Chrome, Firefox, dan Edge versi baru mengaktifkan mekanisme itu secara otomatis pada sebagian wilayah, bahkan Android sejak versi 9 memiliki mode Private DNS bawaan. Alhasil rule redirect port 53 tidak melihat apa pun, sebab permintaan sudah menyamar sebagai trafik web biasa.
Konsekuensinya nyata di lapangan. Entri statis pemblokiran yang Anda buat tetap tersimpan rapi di router, tetapi browser pelanggan tidak pernah menanyakannya. Nama lokal seperti billing.rtrwnet.lan juga gagal terbaca pada perangkat yang memaksa DoH, sehingga teknisi bingung mengapa alamat internal tiba-tiba tidak ditemukan. Saya sendiri menghabiskan dua jam mengecek konfigurasi resolver sebelum sadar bahwa masalahnya ada di setelan Private DNS pada ponsel pelanggan.
Mitigasi paling realistis adalah memblokir alamat penyedia DoH yang paling populer pada port 443, meski cara ini tidak pernah tuntas seratus persen karena daftar penyedia terus bertambah. Pendekatan lain yang lebih jujur adalah menerima kenyataan tersebut dan memindahkan penyaringan konten ke lapisan lain seperti Layer 7 atau proxy transparan. Dokumentasi resmi mengenai dukungan DoH tersedia di portal dokumentasi MikroTik.
/ip firewall address-list add list=doh-server address=1.1.1.1 comment="Cloudflare DoH" add list=doh-server address=1.0.0.1 comment="Cloudflare DoH" add list=doh-server address=8.8.8.8 comment="Google DoH" add list=doh-server address=8.8.4.4 comment="Google DoH" /ip firewall filter add chain=forward action=reject reject-with=icmp-network-unreachable protocol=tcp dst-port=443 dst-address-list=doh-server comment="Tahan DoH pihak ketiga"
Menariknya, RouterOS sendiri mampu berperan sebagai klien DoH sehingga permintaan dari router ke resolver hulu ikut terenkripsi. Konfigurasinya membutuhkan sertifikat CA yang Anda impor lebih dulu, lalu satu baris pengaturan pada menu utama.
/tool fetch url=https://curl.se/ca/cacert.pem /certificate import file-name=cacert.pem passphrase="" /ip dns set use-doh-server=https://cloudflare-dns.com/dns-query verify-doh-cert=yes
Studi Kasus DNS Server Mikrotik di RT-RW Net
Jaringan yang saya kelola melayani 180 pelanggan aktif dengan uplink 300 Mbps dan router utama RB4011. Sebelum optimasi, seluruh pelanggan menerima 8.8.8.8 langsung dari profil PPPoE tanpa singgah di DNS server Mikrotik. Pengukuran pada jam 20.00 menunjukkan waktu resolusi rata-rata 84 milidetik dengan lonjakan sampai 400 milidetik saat trafik memuncak. Keluhan yang masuk ke grup pelanggan selalu berbunyi sama: “buka Instagram lama, padahal download cepat.”
Perubahan yang saya lakukan hanya tiga hal. Pertama, menghidupkan DNS server Mikrotik dengan cache 8192 KiB dan cache-max-ttl=1d. Kedua, mengarahkan profil PPPoE ke alamat LAN router. Ketiga, memasang rule drop port 53 dari arah WAN plus redirect dstnat untuk pelanggan bandel. Seluruh pekerjaan selesai dalam 20 menit tanpa memutus satu sesi pun.
Hasil pengukuran seminggu kemudian cukup memuaskan. Waktu resolusi rata-rata turun ke 12 milidetik untuk domain populer, dengan rasio cache hit sekitar 78 persen pada jam sibuk. Trafik uplink khusus port 53 menyusut dari 1,4 Mbps menjadi sekitar 300 Kbps, dan yang lebih penting, keluhan “lemot” berkurang drastis. Bila Anda sedang menyiapkan jaringan serupa dari awal, panduan membangun RT-RW Net dari nol memberi kerangka lengkap termasuk penempatan layanan pendukung seperti ini.
Tips dan Best Practice DNS Server Mikrotik
Beberapa kebiasaan kecil membuat pengelolaan DNS server Mikrotik jauh lebih tenang dalam jangka panjang. Daftar berikut lahir dari kesalahan yang pernah saya buat sendiri, jadi anggap saja jalan pintas supaya Anda tidak mengulanginya.
- Pasang minimal dua resolver hulu dari penyedia berbeda agar kegagalan satu pihak tidak melumpuhkan pelanggan.
- Selalu tambahkan rule drop port 53 dari WAN sebelum mengaktifkan
allow-remote-requests, bukan sesudahnya. - Isi kolom
commentpada setiap entri statis supaya teknisi lain paham maksudnya enam bulan kemudian. - Pakai akhiran nama internal yang unik seperti
.lanatau.rtrwnet, jangan memakai domain publik milik orang lain. - Sesuaikan
cache-sizedengan RAM perangkat; jangan asal memasang angka besar pada router bermemori 64 MB. - Simpan konfigurasi secara berkala dan uji hasil restore-nya di perangkat cadangan.
- Pantau counter rule firewall port 53 sebagai indikator dini adanya percobaan penyalahgunaan.
Satu tips tambahan yang jarang orang sebut: catat pengaturan resolver dalam dokumentasi jaringan Anda. Saat router utama rusak dan Anda harus memasang unit pengganti pukul dua dini hari, daftar entri statis dan rule firewall akan menyelamatkan waktu Anda. Biasakan pula mengambil cadangan konfigurasi setiap kali menambah entri penting, lalu simpan berkasnya di luar perangkat. Kebiasaan sederhana itu mengubah insiden besar menjadi gangguan kecil yang selesai dalam hitungan menit.
Troubleshooting Masalah Umum
Gangguan pada DNS server Mikrotik punya gejala khas yang mudah dikenali begitu Anda terbiasa. Tiga kasus berikut mewakili hampir seluruh tiket yang pernah masuk ke meja saya.
Tidak Bisa Browsing Padahal Ping ke IP Berhasil
Gejala ini merupakan tanda paling klasik bahwa resolusi nama gagal sementara jalur data sehat. Uji dengan membandingkan dua perintah: ping 8.8.8.8 yang berhasil melawan ping google.com yang gagal. Bila dugaan terbukti, periksa apakah allow-remote-requests benar-benar aktif dan apakah klien menerima alamat resolver yang tepat lewat ipconfig /all pada Windows.
Penyebab lain yang sering muncul adalah rule firewall input yang terlalu ketat sehingga permintaan pelanggan ikut terblokir. Periksa urutan rule Anda; rule accept dari LAN harus berada di atas rule drop apa pun yang menyentuh port 53. Jalankan /ip firewall filter print stats lalu amati rule mana yang counter-nya melonjak saat pelanggan mencoba membuka situs.
Cache Penuh dan Resolusi Melambat
Cache yang penuh membuat router membuang entri lama lebih cepat sehingga rasio cache hit anjlok. Cek pemakaiannya lewat /ip dns print dan perhatikan nilai cache-used dibanding cache-size. Angka pemakaian yang selalu menempel di batas atas menandakan Anda perlu menaikkan kapasitas atau menurunkan cache-max-ttl.
Perhatikan juga kemungkinan penyalahgunaan. Lonjakan pemakaian cache yang tiba-tiba pada dini hari, ketika pelanggan seharusnya tidur, biasanya menandakan ada perangkat terinfeksi malware yang membanjiri router dengan permintaan acak. Telusuri sumbernya memakai /tool torch pada interface LAN sambil menyaring port 53, lalu isolasi perangkat tersebut.
Entri Statis Tidak Terbaca karena DoH Aktif
Kasus ini semakin sering muncul sejak 2023 dan sempat membuat banyak teknisi frustrasi. Anda sudah membuat entri statis dengan benar, /ip dns static print menampilkannya rapi, tetapi perangkat pelanggan tetap tidak menemukan nama tersebut. Uji cepat dengan nslookup billing.rtrwnet.lan 192.168.10.1; bila perintah itu berhasil sementara browser gagal, DoH-lah biang keroknya.
Perbaikannya berada di sisi klien, bukan di router. Matikan opsi “Use secure DNS” pada Chrome atau Edge, ubah “DNS over HTTPS” menjadi Off pada Firefox, dan setel Private DNS ke Automatic pada Android. Untuk perangkat yang tidak bisa Anda sentuh, blokir alamat penyedia DoH populer seperti contoh sebelumnya sambil menyadari bahwa cara itu hanya menutup sebagian celah.
| Gejala | Dugaan Penyebab | Perintah Pemeriksaan |
|---|---|---|
| Nama domain gagal, IP jalan | Resolver tidak aktif atau salah alamat | /ip dns print |
| Pelanggan tetap lolos blokir | Klien memakai resolver luar atau DoH | /ip firewall nat print stats |
| Trafik WAN membengkak | Router menjadi open resolver | /ip firewall connection print |
| Resolusi melambat bertahap | Cache penuh | /ip dns cache print |
| Entri statis tidak berlaku | Cache lama masih menempel | /ip dns cache flush |
FAQ Seputar DNS Server Mikrotik
Apakah Semua Seri Router Mendukung Fitur Resolver Ini?
Ya, seluruh perangkat berbasis RouterOS mendukung fitur resolver, mulai dari hAP Lite hingga CCR seri besar. Perbedaannya hanya terletak pada kapasitas cache yang bisa Anda alokasikan sesuai jumlah RAM. Perangkat bermemori 64 MB sebaiknya tetap memakai cache di bawah 4096 KiB agar layanan lain tidak kekurangan memori.
Berapa Ukuran Cache yang Ideal?
Patokan praktis saya adalah 2048 KiB untuk di bawah 50 klien, 4096 KiB untuk 50 sampai 150 klien, dan 8192 KiB ke atas untuk jaringan yang lebih besar. Pantau nilai cache-used selama seminggu, lalu naikkan bila angkanya konsisten menyentuh batas. Menambah cache tanpa memperhatikan RAM justru berisiko membuat router kehabisan memori saat trafik memuncak.
Apakah DNS Server Mikrotik Aman Dibuka untuk Publik?
Tidak aman sama sekali tanpa pembatasan, karena router Anda akan menjadi open resolver yang penyerang pakai untuk amplification attack. Bila memang ada kebutuhan melayani jaringan luar, batasi aksesnya dengan address list berisi alamat yang Anda percaya. Untuk mayoritas kasus RT-RW Net, membatasi port 53 hanya pada interface LAN sudah lebih dari cukup.
Bisakah Entri Statis Memblokir Seluruh Subdomain Sekaligus?
Bisa, memakai parameter match-subdomain=yes pada RouterOS 7 yang mencocokkan domain induk beserta seluruh anaknya. Pengguna RouterOS 6 harus memakai regexp untuk mencapai hasil serupa, meski konsumsi CPU-nya sedikit lebih tinggi. Uji selalu hasilnya dengan nslookup sebelum menganggap pemblokiran berhasil.
Kenapa Perubahan Entri Statis Belum Terasa di Perangkat Klien?
Penyebabnya hampir selalu cache, baik di router maupun di sistem operasi klien. Bersihkan cache router memakai /ip dns cache flush, lalu jalankan ipconfig /flushdns pada Windows. Browser modern juga menyimpan cache sendiri, sehingga menutup dan membuka ulang aplikasi sering menjadi langkah terakhir yang diperlukan.
Lebih Baik Memakai Resolver ISP atau Resolver Publik?
Resolver milik ISP hulu biasanya memberi respons paling cepat karena letaknya hanya satu atau dua hop dari router Anda. Resolver publik seperti Cloudflare unggul dari sisi keandalan dan privasi, namun jaraknya lebih jauh. Kombinasi keduanya, dengan resolver ISP di urutan pertama, memberi keseimbangan terbaik menurut pengalaman saya.
Apakah Redirect Port 53 Melanggar Privasi Pelanggan?
Pembelokan trafik nama termasuk praktik lazim pada jaringan berlangganan, tetapi sebaiknya Anda cantumkan dalam syarat layanan agar transparan. Sampaikan alasannya secara jujur, misalnya untuk efisiensi bandwidth dan penyaringan konten berbahaya. Keterbukaan semacam ini menghindarkan Anda dari salah paham ketika pelanggan menyadari pengaturan resolvernya tidak berfungsi.
Bagaimana Kalau Router Utama Mati?
Seluruh pelanggan akan kehilangan kemampuan menerjemahkan nama meski jalur data lain masih hidup. Mitigasinya adalah memberi klien dua alamat resolver, dengan alamat kedua mengarah ke resolver publik sebagai cadangan. Cara itu sedikit mengurangi kontrol Anda, namun menyelamatkan pengalaman pelanggan saat perangkat utama bermasalah.
Kesimpulan
Mengaktifkan DNS server Mikrotik termasuk pekerjaan sepuluh menit yang dampaknya terasa berbulan-bulan. Cache lokal memangkas latensi, entri statis memberi Anda nama internal yang rapi sekaligus alat pemblokiran ringan, dan redirect dstnat menjaga pelanggan tetap melewati jalur yang Anda kelola. Kunci keberhasilannya bukan pada perintah yang rumit, melainkan pada urutan kerja yang benar: amankan port 53 lebih dulu, baru buka layanan untuk pelanggan.
Ingat pula bahwa lanskap jaringan terus bergerak. DoH membuat pemaksaan resolver tidak lagi mutlak berhasil, dan tren enkripsi ini hampir pasti semakin luas pada tahun-tahun mendatang. Sikap paling sehat adalah memakai DNS server Mikrotik untuk apa yang benar-benar bisa ia lakukan, yaitu mempercepat akses dan menyediakan nama lokal, sambil menyiapkan lapisan lain untuk kebutuhan penyaringan konten.
Mulailah dari konfigurasi dasar pada perangkat uji sebelum menyentuh router produksi. Ukur waktu resolusi sebelum dan sesudah perubahan supaya Anda punya bukti angka, bukan sekadar perasaan. Setelah terbiasa, gabungkan pengaturan ini dengan manajemen bandwidth dan pengelolaan pelanggan agar jaringan Anda benar-benar terkendali dari satu tempat.
