DNS ISP Meracuni Riset Online, Anti-bot Jadi Kambing
Bulan-bulan salah duga anti-bot; pelakunya DNS ISP Indonesia yang mengalihkan resolusi duckduckgo.com ke blok Trustpositif.
Ringkasan
Kegagalan browser headless di Docker buka DuckDuckGo ternyata bukan ulah anti-bot, melainkan DNS ISP yang meracuni resolusi domain lewat mekanisme TrustPositif sejak mandat Kominfo 2015. Diagnosa nslookup membuktikan IP jawaban bukan milik DDG. Solusinya satu flag: jalankan container dengan --dns 1.1.1.1, langsung normal tanpa sentuh kode.
Log browser otomatis (headless) di dalam Docker container terus-menerus gagal membuka DuckDuckGo. Error-nya aneh: kadang timeout, kadang dialihkan ke halaman yang jelas bukan antarmuka DDG. Sementara di laptop normal yang satu jaringan, DuckDuckGo terbuka mulus.
Kalimat yang lama menghantui kepala: kenapa anti-bot ini sekelas dunia sampai segitunya? Emang se-bengis apa fingerprinting mereka?
Bulan-bulan saya salah jalan. Sibuk mengutak-atik konfigurasi fingerprint, memanipulasi cookie, sampai mencoba berbagai teknik bypass yang rumit. Padahal pelakunya sama sekali bukan DuckDuckGo.
Momen nslookup membongkar segalanya
Titik baliknya terjadi saat saya berhenti sejenak dan memeriksa lapisan paling dasar: resolusi nama domain. Perintahnya sederhana, dijalankan di dalam container yang bermasalah:
nslookup duckduckgo.comHasilnya: 103.123.248.32.
Saya cek lagi. IP itu bukan milik DuckDuckGo. Di server saya, gethostbyname bahkan membalik nama domainnya jadi trustpositif.moratelindo.io: blok IP milik ISP lokal yang dikenal sebagai mekanisme pemblokiran TrustPositif. Container mewarisi konfigurasi DNS default dari jaringan host, dan DNS itulah yang memanipulasi jawaban resolusi domain. Semua teori rumit soal anti-bot dan fingerprinting runtuh seketika. Ternyata saya tidak diblokir DuckDuckGo, saya "diracuni" DNS ISP sendiri.
Kenapa ini bisa terjadi di Indonesia
Masalah ini bukan kebetulan semata. Sejarah mencatat bahwa "On May 31, 2015, Kominfo mandated all home and cellular ISPs operating in Indonesia to redirect port 53 for censorship purposes" menurut catatan sensor internet di Indonesia di Wikipedia. Sejak saat itu, query DNS port 53 di banyak ISP diarahkan ke server ISP, dan sebagian ISP bahkan memblokir domain DNS terenkripsi. Fenomena ini bisa muncul di mana saja: jaringan kantor, provider seluler tertentu, atau perangkat yang warisan konfigurasinya belum disentuh.
Untuk membuktikannya, bandingkan hasil diagnosa di jaringan yang terdampak dengan resolver publik:
# Di dalam container (mewarisi DNS ISP)
nslookup duckduckgo.com
# jawaban: 103.123.248.32 (bukan DDG)
# Pembanding via resolver publik
dig +short @1.1.1.1 duckduckgo.com
# jawaban: 20.43.161.105 (IP asli DDG)Solusinya? Satu baris. Saat menjalankan container, paksa pakai resolver publik tepercaya, misalnya 1.1.1.1 dari Cloudflare:
docker run --dns 1.1.1.1 --dns 8.8.8.8 --dns 9.9.9.9 -d nama-image-risetSetelah itu DuckDuckGo langsung terbuka normal, tanpa mengubah satu baris pun kode fingerprint atau cookie.
Bonus pelajaran: karena satu mesin pencari bisa saja bermasalah di waktu lain, riset otomatis saya kini pakai rotasi: DDG, Bing, Yandex, Google, plus fallback DNS kalau resolusi terdeteksi aneh lagi.
Diagnosa murah selalu lebih dulu
Prinsip DNS over HTTPS (DoH) diciptakan justru agar query DNS tidak rentan terhadap "eavesdropping and manipulation ... by man-in-the-middle attacks", sesuai catatan DoH di Wikipedia. Prinsipnya persis menggambarkan masalah ini: manipulasi di lapisan tengah oleh pihak yang seharusnya jadi penunjuk jalan.
Pelajaran terbesar dari insiden ini: sebelum menyalahkan anti-bot, fingerprinting, atau kompleksitas jaringan tingkat tinggi, pastikan dulu lapisan paling bawah (DNS) sehat. Jangan sampai habis berbulan-bulan buat masalah yang sebenarnya selesai dengan satu flag --dns.
Penutupnya simpel: semua container di server riset saya sekarang eksplisit memakai DNS publik. Tidak ada lagi warisan DNS default yang berpotensi "meracuni" hasil riset.