DNS Static MikroTik Berlaku untuk Semua Klien: Kenapa Jangan Membajak Domain Google

Bayangkan sebuah gedung kantor dengan satu buku telepon bersama di meja resepsionis. Suatu hari, bagian keuangan ingin menagih penyewa yang menunggak, lalu mengganti nomor “Pemadam Kebakaran” di buku itu dengan nomor kantor penagihan. Niatnya hanya untuk penunggak. Namun, semua orang di gedung memakai buku itu, sehingga setiap karyawan yang menelepon pemadam justru tersambung ke bagian penagihan. Begitulah cara kerja DNS static MikroTik: satu tabel untuk semua klien, tanpa pengecualian.

Artikel ini membahas kenapa entri /ip dns static selalu berlaku global, kebocoran nyata yang kami alami saat mencoba mengarahkan pelanggan isolir lewat domain Google, serta tiga alternatif yang aman. Selain itu, semua data router di sini berasal dari router produksi kami (hanya kami baca, tidak kami ubah), sedangkan simulasinya kami jalankan di VPS uji. Kami juga mengganti IP dan domain dengan nilai contoh.

Kenapa DNS Static MikroTik Berlaku untuk Semua Klien?

RouterOS punya satu resolver DNS bawaan. Resolver ini membaca satu tabel static, lalu meneruskan nama lain ke server upstream seperti 8.8.8.8. Masalahnya, entri /ip dns static tidak punya parameter src-address atau src-address-list. Akibatnya, router tidak bisa menjawab “IP A untuk pelanggan isolir, IP B untuk pelanggan aktif”. Di RouterOS 6 maupun 7, siapa pun yang bertanya ke resolver router akan menerima jawaban yang sama.

Lalu siapa saja yang bertanya ke resolver router? Ternyata jauh lebih banyak dari dugaan banyak admin. Tabel berikut merangkum jalur yang paling sering membuat klien memakai resolver MikroTik tanpa kita sadari.

Dengan kata lain, hanya baris terakhir yang aman dari tabel static. Sementara itu, mayoritas perangkat rumah dan kantor memakai DHCP bawaan, jadi hampir semua klien Anda ikut membaca tabel itu.

Cek Router Anda: Siapa yang Bertanya ke Resolver?

Sebelum menambah entri static apa pun, periksa dulu empat hal ini dari terminal RouterOS. Semua perintah di bawah hanya membaca, jadi aman untuk router produksi.

/ip dns print
/ip dns static print
/ip dhcp-server network print
/ppp profile print

Perhatikan tiga nilai. Pertama, allow-remote-requests=yes pada /ip dns print berarti router melayani query dari klien. Kedua, kolom dns-server yang kosong di DHCP network berarti klien LAN menerima IP router sebagai DNS. Ketiga, PPP profile tanpa dns-server membuat modem pelanggan cenderung memakai gateway. Jika ketiganya terpenuhi, setiap entri static Anda otomatis berlaku untuk seluruh jaringan.

Hasil di router kami cukup jelas. Resolver aktif, kedua DHCP network tidak mengisi dns-server, dan hotspot menambah rule NAT dinamis ke DNS router. Jadi, laptop admin, tamu hotspot, dan pelanggan PPPoE semuanya membaca tabel static yang sama. Untungnya, tabel itu sekarang hanya berisi dua domain milik kami yang menunjuk ke IP server asli, plus entri dinamis milik hotspot.

Contoh Kasus 1: reCAPTCHA Gagal karena Membelokkan Domain Google

Kasus ini terjadi pada 22 Mei 2026. Saat itu kami sedang menyiapkan halaman isolir untuk pelanggan PPPoE yang menunggak. Supaya HP Android memunculkan notifikasi “Sign in to Wi-Fi”, skrip setup lama menambah entri static clients3.google.com dan clients4.google.com yang menunjuk ke server halaman isolir. Niatnya, probe konektivitas Android mendarat di halaman isolir.

Beberapa jam kemudian, admin yang bekerja dari laptop di LAN router yang sama tidak bisa login ke panel billing. Konsol Chrome menampilkan ERR_CERT_COMMON_NAME_INVALID saat memuat recaptcha__id.js dari www.gstatic.com. Anehnya, admin yang sama bisa login normal dari HP dengan data seluler. Perbedaan inilah petunjuknya: HP memakai DNS operator seluler, sedangkan laptop memakai resolver MikroTik yang berisi entri Google palsu.

Kenapa Domain yang Tidak Kita Sentuh Ikut Rusak?

Kami tidak pernah menambah www.gstatic.com ke tabel static, tetapi domain itu tetap gagal. Penyebabnya adalah HTTP/2 connection coalescing. Browser boleh memakai ulang satu koneksi TLS untuk beberapa domain sekaligus, asalkan sertifikat koneksi itu mencakup semua domain tersebut. Sertifikat Google sendiri memang mencakup banyak nama sekaligus, seperti hasil pemeriksaan berikut.

echo | openssl s_client -connect clients3.google.com:443 -servername clients3.google.com 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName | tr "," "\n" \
  | grep -n -E "CN=|\*\.google\.com$|gstatic|DNS:google.com" | head

# 1:subject=CN=*.google.com
# 3:    DNS:*.google.com
# 31: DNS:*.gstatic.com
# 32: DNS:*.metric.gstatic.com
# 50: DNS:google.com

Perintah ini mengambil sertifikat asli clients3.google.com, lalu memecah daftar Subject Alternative Name per baris. Hasilnya, satu sertifikat mencakup *.google.com dan *.gstatic.com (totalnya lebih dari 60 nama). Karena itu, browser menganggap semua domain Google “satu keluarga”. Begitu resolver membelokkan salah satu anggotanya ke server kita, sertifikat server kita yang hanya mencakup domain sendiri langsung bentrok dengan harapan browser. Hasil akhirnya, reCAPTCHA gagal dan form login tidak pernah terkirim.

Contoh Kasus 2: Pelanggan Aktif Melihat Halaman Isolir

Setelah kasus pertama, kami menghapus entri Google dan menggantinya dengan domain probe yang tampak lebih aman: connectivitycheck.gstatic.com, captive.apple.com, gsp1.apple.com, www.msftconnecttest.com, dan detectportal.firefox.com. Namun, sifat global tabel static kembali menggigit.

Pada 29 Juni 2026, seorang pelanggan yang statusnya aktif melapor bahwa HP-nya menampilkan halaman isolir. Data RADIUS-nya bersih, paketnya normal, dan IP-nya bukan dari pool isolir. Ternyata HP-nya menjalankan probe connectivitycheck.gstatic.com lewat resolver router, lalu menerima IP server isolir. Android pun menyimpulkan ada captive portal. Di sisi Windows, gejalanya serupa. Probe NCSI ke www.msftconnecttest.com/connecttest.txt menerima redirect, bukan teks yang Windows harapkan, sehingga ikon jaringan menampilkan “No internet” padahal internet berjalan normal.

Selain itu, router yang sama juga melayani hotspot voucher. Pengguna hotspot yang sudah login dan membayar pun ikut melihat halaman isolir. Oleh karena itu, kami mengambil keputusan final: semua domain probe keluar dari tabel static.

/ip dns static remove [find name=connectivitycheck.gstatic.com]
/ip dns static remove [find name=captive.apple.com]
/ip dns static remove [find name=gsp1.apple.com]
/ip dns static remove [find name=www.msftconnecttest.com]
/ip dns static remove [find name=detectportal.firefox.com]
/ip dns cache flush

Lima perintah pertama menghapus entri berdasarkan nama. Perintah terakhir penting karena tanpa cache flush, router masih menyimpan jawaban palsu sampai TTL-nya habis. Konsekuensinya, popup captive portal otomatis untuk pelanggan isolir memang melemah. Namun, trade-off ini jauh lebih baik daripada mengganggu pelanggan aktif dan pengguna hotspot yang membayar.

Simulasi: Membuktikan Static DNS Menjawab Semua Klien

Agar perilaku ini tidak sekadar teori, kami menirunya di VPS uji Ubuntu 26.04 dengan dnsmasq. Sama seperti tabel static MikroTik, opsi --address pada dnsmasq menjawab satu nama dengan IP tetap. Kemudian kami mengirim query dari tiga IP sumber berbeda yang mewakili admin LAN, pelanggan aktif, dan pelanggan isolir.

#!/bin/bash
# Simulasi resolver router: satu static entry, tiga klien berbeda
sudo dnsmasq --keep-in-foreground --no-resolv --no-hosts --port=5390 --listen-address=127.0.0.1 \
  --bind-interfaces --server=1.1.1.1 --address=/clients3.google.com/198.51.100.20 \
  --log-queries --log-facility=/tmp/dnsuji/dnsmasq.log --pid-file=/tmp/dnsuji/dnsmasq.pid &
sleep 1
for ip in 127.0.0.1 127.0.0.2 127.0.0.3; do
  echo "klien $ip -> clients3.google.com = $(dig +short -b $ip @127.0.0.1 -p 5390 clients3.google.com)"
done
echo "klien 127.0.0.2 -> www.google.com     = $(dig +short -b 127.0.0.2 @127.0.0.1 -p 5390 www.google.com | head -1)"
sudo kill $(cat /tmp/dnsuji/dnsmasq.pid)

Opsi -b pada dig memilih IP sumber query, sehingga resolver melihat tiga klien yang berbeda. Hasilnya, ketiga klien menerima 198.51.100.20 untuk clients3.google.com, sedangkan www.google.com tetap mendapat IP Google asli. Log dnsmasq juga mencatat tiga query dari tiga IP dengan jawaban config yang sama.

Efeknya ke HTTPS

Selanjutnya, kami meniru browser yang tersambung ke IP hasil pembelokan. Opsi --resolve pada curl memaksa nama Google mengarah ke server nginx lokal yang memakai sertifikat domain kami sendiri.

curl -sS -o /dev/null --resolve clients3.google.com:443:127.0.0.1 https://clients3.google.com/generate_204
# curl: (60) SSL: no alternative certificate subject name matches target hostname 'clients3.google.com'

curl -sS -o /dev/null -w "%{http_code}\n" https://clients3.google.com/generate_204
# 204

Pesan curl ini setara dengan ERR_CERT_COMMON_NAME_INVALID di Chrome. Sebaliknya, tanpa pembelokan, URL yang sama membalas 204 seperti biasa. Inilah alasan teknis kenapa membajak domain HTTPS milik pihak lain selalu berakhir dengan error sertifikat.

Alternatif Aman 1: Batasi dengan Address-List

Kalau DNS static tidak bisa memilih klien, firewall bisa. Rule NAT dan filter MikroTik menerima src-address-list, jadi kita membatasi semua trik isolir hanya untuk pool pelanggan yang menunggak. Potongan berikut berasal dari skrip setup isolir yang kini kami pakai di produksi. IP server halaman isolir kami ganti dengan 203.0.113.10.

/ip firewall address-list add list=EXPIRED address=10.200.200.0/23 comment="subnet pool isolir"
/ip firewall address-list add list=EXPIRED_PAGE address=10.200.200.1 comment="gateway isolir"
/ip firewall address-list add list=EXPIRED_PAGE address=203.0.113.10 comment="server halaman isolir"

/ip firewall filter add chain=forward action=drop src-address-list=EXPIRED dst-address-list=!EXPIRED_PAGE protocol=udp dst-port=!53 comment="drop isolir UDP non-DNS"
/ip firewall filter add chain=forward action=drop src-address-list=EXPIRED dst-address-list=!EXPIRED_PAGE protocol=tcp dst-port=!53,80 comment="drop isolir TCP non-page"

/ip firewall nat add chain=dstnat action=dst-nat src-address-list=EXPIRED dst-address-list=!EXPIRED_PAGE protocol=tcp dst-port=80 to-addresses=203.0.113.10 to-ports=80 comment="redirect HTTP ke isolir page"
/ip firewall nat add chain=dstnat action=redirect src-address-list=EXPIRED protocol=udp dst-port=53 to-ports=53 comment="DNS hijack"

Pertama, address-list EXPIRED mendefinisikan subnet pool isolir. Kedua, dua rule filter membuang semua trafik pelanggan isolir kecuali DNS dan HTTP ke halaman isolir. Ketiga, rule dst-nat membelokkan setiap request HTTP port 80 ke server halaman isolir, apa pun domain tujuannya. Terakhir, rule DNS hijack menangkap query port 53 dari pool isolir, termasuk yang menuju 8.8.8.8. Perbedaannya dengan tabel static sangat mendasar, karena semua rule ini hanya menyentuh src-address-list=EXPIRED.

Bukti dari Penghitung Paket

Penghitung paket di router kami membuktikan cakupannya bekerja. Rule DNS hijack sudah menangkap 69.715 paket dan rule redirect HTTP 1.423 paket, semuanya dari pool isolir. Selama periode yang sama, tidak ada lagi laporan pelanggan aktif yang melihat halaman isolir.

Alternatif Aman 2: DNS Khusus per Pool

Cara kedua adalah memisahkan “siapa bertanya ke siapa”. Pelanggan aktif sebaiknya tidak memakai resolver router sama sekali, sedangkan pelanggan isolir memakai resolver yang memang kita kendalikan.

Pisahkan DNS Pelanggan Aktif dan Isolir

Skrip setup kami membuat PPP profile isolir dengan DNS publik eksplisit, lalu menyisakan tabel static yang hanya berisi domain milik sendiri. Kedua domain itu menunjuk ke IP server aslinya, sehingga tetap benar untuk klien mana pun.

/ppp profile add name=EXPIRED_ISOLIR local-address=10.200.200.1 remote-address=EXPIRED_ISOLIR dns-server=8.8.8.8,1.1.1.1 comment="Profile Isolir"

/ip dns static remove [find comment~"ISOLIR"]
/ip dns static add name=isolir.contoh.com address=203.0.113.10 comment="ISOLIR - isolir page domain"
/ip dns static add name=app.contoh.com address=203.0.113.10 comment="ISOLIR - billing API (bypass CF)"

Untuk pelanggan aktif, isi juga kolom DNS Servers di IP > DHCP Server > Networks dan di PPP profile paket dengan DNS publik. Dengan begitu, laptop admin dan modem pelanggan aktif bertanya langsung ke 8.8.8.8, bukan ke router. Sebagai catatan, perangkat baru menerima DNS baru setelah lease DHCP berganti atau sesi PPPoE tersambung ulang.

Butuh Jawaban Berbeda per Pool? Pakai Resolver Ber-View

Jika Anda benar-benar membutuhkan jawaban DNS yang berbeda untuk pool isolir, pindahkan logika itu ke resolver di server Linux yang mendukung view, misalnya Unbound. Kemudian arahkan DNS hijack pool isolir ke resolver tersebut. Konfigurasi uji kami terlihat seperti ini.

server:
    interface: 127.0.0.1@5391
    access-control: 127.0.0.0/8 allow
    # pool isolir (di uji ini 127.0.0.3) memakai view khusus
    access-control-view: 127.0.0.3/32 isolir

view:
    name: "isolir"
    view-first: yes
    local-zone: "connectivitycheck.gstatic.com." redirect
    local-data: "connectivitycheck.gstatic.com. 60 IN A 198.51.100.20"

forward-zone:
    name: "."
    forward-addr: 1.1.1.1

Baris access-control-view mengikat subnet tertentu ke view isolir. Hanya klien dari subnet itu yang menerima jawaban palsu, sementara Unbound meneruskan query klien lain secara normal ke 1.1.1.1. Di produksi, ganti 127.0.0.3/32 dengan subnet pool isolir Anda.

Uji Hasil View

unbound-checkconf unbound-uji.conf
sudo aa-exec -p unconfined -- unbound -c /tmp/dnsuji/unbound-uji.conf
for ip in 127.0.0.1 127.0.0.2 127.0.0.3; do
  echo "klien $ip -> connectivitycheck.gstatic.com = $(dig +short -b $ip @127.0.0.1 -p 5391 connectivitycheck.gstatic.com | tail -1)"
done

Kami memakai aa-exec -p unconfined hanya karena file uji berada di /tmp, yang tidak termasuk izin profil AppArmor Unbound. Untuk pemasangan permanen, simpan konfigurasinya di /etc/unbound/unbound.conf.d/. Hasilnya, klien .1 dan .2 menerima IP Google asli, sedangkan hanya klien .3 menerima 198.51.100.20.

Alternatif Aman 3: Halaman Isolir yang Menangkap Semua Host

Karena rule dst-nat membelokkan HTTP dengan domain apa pun, server halaman isolir harus siap menerima Host header acak. Caranya, jadikan server block isolir sebagai default_server, lalu balas URL probe captive portal dengan redirect 302.

server {
    listen 8089 default_server;   # di server asli: listen 80 default_server;
    server_name _;
    root /tmp/dnsuji/www;          # di server asli: /var/www/isolir
    index index.html;

    add_header Cache-Control "no-store, max-age=0" always;

    # URL probe captive portal: balas 302, bukan 204/200
    location = /generate_204               { return 302 http://isolir.contoh.com/; }
    location = /hotspot-detect.html        { return 302 http://isolir.contoh.com/; }
    location = /connecttest.txt            { return 302 http://isolir.contoh.com/; }
    location = /canonical.html             { return 302 http://isolir.contoh.com/; }

    location / { try_files $uri $uri/ /index.html; }
}

Probe Android, iOS, Windows, dan Firefox mengharapkan jawaban 204 atau teks tertentu. Saat menerima 302, sistem operasi menyimpulkan ada captive portal. Kali ini efeknya hanya mengenai pelanggan isolir, sebab trafik itu tiba lewat dst-nat yang cakupannya address-list.

Uji dengan Host Header Acak

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -H "Host: connectivitycheck.gstatic.com" http://127.0.0.1:8089/generate_204
# 302 http://isolir.contoh.com/
curl -s -H "Host: situs-acak.example" http://127.0.0.1:8089/berita/hari-ini
# <h1>Layanan Anda sedang diisolir</h1>

Perintah pertama meniru probe Android dan menerima 302. Perintah kedua meniru pelanggan yang membuka situs sembarang, lalu mendapat halaman isolir. Meski begitu, ingat batasannya. HP modern memakai DNS over HTTPS dan hampir semua situs memakai HTTPS, jadi redirect otomatis tidak selalu muncul. Oleh karena itu, kami tetap mengirim link halaman isolir lewat WhatsApp sebagai jalur utama.

Domain yang Aman dan Berbahaya di Tabel Static

Sebagai pegangan cepat, berikut klasifikasi entri yang pernah kami pasang beserta hasilnya di lapangan.

Kesalahan Umum

• Menganggap tabel static bisa memilih klien. RouterOS tidak punya parameter sumber untuk entri static, jadi pakai firewall dengan address-list.
• Membajak domain HTTPS pihak lain. Server Anda tidak punya sertifikat untuk domain itu, sehingga browser selalu menolak koneksinya.
• Lupa menjalankan /ip dns cache flush. Setelah menghapus entri, router dan klien masih memakai jawaban lama sampai TTL habis.
• Membiarkan dns-server kosong di DHCP dan PPP profile. Akibatnya, semua klien bertanya ke router dan ikut membaca tabel static.
• Lupa bahwa hotspot berbagi resolver. Rule NAT dinamis hotspot membelokkan DNS tamu ke router yang sama.
• Menguji dari jaringan yang salah. HP dengan data seluler tidak memakai resolver router, sehingga gejala kebocoran tidak terlihat.

Kesimpulan

DNS static MikroTik adalah buku telepon bersama. Setiap entri yang Anda tulis akan terbaca oleh admin LAN, pelanggan aktif, tamu hotspot, dan pelanggan isolir sekaligus. Karena itu, tabel static hanya cocok untuk domain milik sendiri yang menunjuk ke IP aslinya. Sebaliknya, membajak domain Google atau domain probe captive portal terbukti merusak reCAPTCHA dan membuat pelanggan aktif melihat halaman isolir.

Untuk mengarahkan pelanggan isolir, pakai alat yang memang bisa memilih klien: rule NAT dan filter dengan src-address-list, DNS publik eksplisit untuk pool aktif, resolver ber-view bila butuh jawaban khusus, serta halaman isolir yang menangkap semua Host. Terakhir, lengkapi dengan notifikasi WhatsApp, karena DNS over HTTPS di HP modern tetap bisa melewati semua trik jaringan.

Baca Juga

• Cara Akses Proxmox dari Internet Tanpa IP Publik (WireGuard + VPS)
• Keamanan Server Linux: Tutorial Hardening SSH, Firewall UFW, CrowdSec, dan Alarm Telegram
• Cara Memasang SSL dan HTTPS di WordPress

Referensi: MikroTik Documentation: DNS, MikroTik Documentation: Address-lists, RFC 9113: Connection Reuse (HTTP/2), unbound.conf(5) NLnet Labs.