Pi-hole dan Mekanisme DNS Sinkhole

Sebagian besar iklan dan tracker muncul karena DNS: perangkat meminta alamat domain mereka, dan jawabannya datang seperti domain lain. Pi-hole memanfaatkan celah itu. Ia berdiri di tengah jaringan sebagai DNS sinkhole — resolver yang sengaja menenggelamkan query ke domain yang masuk daftar blokir sebelum jawabannya sampai ke perangkat pengguna. Artikel ini membahas mekanisme, deployment Docker Compose, dan keterbatasannya.

Mengapa DNS Sinkhole

Menangani iklan di level DNS punya satu keuntungan besar: sekali jalan untuk seluruh jaringan. Smartphone, PC, dan Smart TV tidak perlu ekstensi browser, dan blokir berlaku sebelum traffic memasuki perangkat — iklan dan telemetry tidak pernah dimuat. Di homelab, Pi-hole memegang dua peran utama:

Ad-Blocking dan Privasi: memblokir domain iklan dan telemetry secara terpusat untuk semua perangkat.
Internal DNS Resolution: memetakan domain lokal ke IP service internal agar service bisa diakses dengan nama yang rapi.

Karena peran ini, Pi-hole menjadi dependensi jaringan Tier 1: jika mati, seluruh perangkat bisa kehilangan resolusi DNS, bukan hanya kehilangan ad-blocking.

Arsitektur: FTL, Gravity, dan Alur Query

Pi-hole modern (v6) terdiri dari tiga bagian:

pihole-FTL: resolver DNS hasil fork dnsmasq dengan engine FTL (Faster Than Light) yang menggabungkan resolver, API, dan penyimpanan statistik query dalam satu proses.
Web interface: dashboard untuk konfigurasi, monitoring, dan pengelolaan daftar.
Core scripts: perintah pihole (pihole -g, pihole status, pihole disable, dst).

Alur querynya singkat. FTL menerima query dari client, memeriksa cache, lalu memeriksa tabel domainlist dan gravity di /etc/pihole/gravity.db (database SQLite). Jika domain terdaftar sebagai blokir, FTL langsung menjawab sesuai blocking mode — default NULL mengembalikan 0.0.0.0 (atau ::), sehingga client tidak pernah membuka koneksi ke server iklan. Domain bersih diteruskan ke upstream resolver (FTLCONF_dns_upstreams) dan jawabannya di-cache.

Gravity adalah mekanisme pengumpul daftar blokir. pihole -g mengunduh semua adlist yang disubscribe, menggabungkannya, membuang komentar dan duplikat, lalu menyimpannya sebagai satu daftar unik di tabel gravity — berjalan otomatis seminggu sekali di image Docker.

Deployment dengan Docker Compose

Berikut konfigurasi Docker Compose standar untuk menjalankan Pi-hole:

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    network_mode: "host"
    environment:
      TZ: "Asia/Makassar"
      FTLCONF_webserver_api_password: "ganti_password_aman"
    volumes:
      - ./etc-pihole:/etc/pihole
      - ./etc-dnsmasq.d:/etc/dnsmasq.d
    restart: unless-stopped

Catatan: Image v6 memakai variabel FTLCONF_* — password dashboard diatur lewat FTLCONF_webserver_api_password (variabel WEBPASSWORD lama sudah diganti). Volume ./etc-pihole menyimpan gravity.db dan konfigurasi; file dnsmasq di /etc/dnsmasq.d dibaca v6 jika FTLCONF_misc_etc_dnsmasq_d diaktifkan. Mode host membuat FTL melihat IP asli setiap client untuk pelaporan dan pemblokiran presisi.

Operasional dan Keamanan

Dashboard menampilkan query log, top domains, dan top clients untuk melihat domain yang diminta tiap perangkat.
Privacy levels mengontrol seberapa detail query disimpan di database FTL.
CLI harian: pihole status untuk cek kondisi, pihole disable untuk menjeda blokir sementara, pihole -g untuk memperbarui Gravity manual, docker logs -f pihole untuk melihat log container.
Dashboard dilindungi password (placeholder ganti_password_aman); jangan mengeksposnya ke internet.
Di host Linux dengan systemd-resolved, stub listener 127.0.0.53:53 perlu dimatikan agar port 53 bebas.

Backup dan Recovery (Teleporter)

Konfigurasi Pi-hole mudah dicadangkan menggunakan fitur Teleporter:

Buka dashboard Pi-hole -> Settings -> Teleporter -> Backup.
Berkas .tar.gz yang diunduh berisi seluruh adlist, local DNS records, allow/deny list, dan pengaturan.
Jika terjadi kerusakan container, jalankan container baru lalu restore berkas tersebut via Teleporter.

Kelebihan yang Dirasakan

Blokir network-wide tanpa ekstensi: Smart TV dan IoT ikut terlindungi tanpa adblock.
Gravity terjadwal otomatis: di image Docker, pembaruan daftar blokir berjalan mingguan tanpa intervensi.
Query keluar lebih hemat: FTL mempertahankan upstream tercepat selama 1000 query atau 10 menit, sehingga query keluar berkurang.
Local DNS records: nama internal dipetakan ke IP service homelab untuk akses antar-service dengan nama rapi.
Cache dan statistik bawaan: jawaban di-cache, dan dashboard memberi visibilitas atas perilaku DNS tiap perangkat.

Kontra dan Keterbatasan

Single point of failure: jika Pi-hole mati, resolusi DNS seluruh jaringan ikut berhenti. Perlu DNS sekunder atau fallback di router.
Hanya memblokir di level DNS: iklan yang disajikan dari domain yang sama dengan konten (misalnya iklan di YouTube) tidak bisa diblokir tanpa memblokir layanannya juga.
Bisa dilewati: browser atau perangkat yang memakai DNS-over-HTTPS (encrypted DNS) mengirim query langsung ke resolver DoH dan melewati Pi-hole; sebagian perangkat IoT juga punya resolver hardcoded.
False positive: blocklist yang agresif bisa memblokir domain sah, sehingga butuh allowlist manual.
Bukan kontrol konten penuh: karena hanya bekerja pada DNS, Pi-hole tidak melihat isi traffic HTTPS dan bukan pengganti firewall.

Kesimpulan

Di homelab satu mesin, Pi-hole tetap layak dipasang sebagai lapisan pertama ad-blocking dan resolver internal. Nilainya paling terasa pada perangkat yang tidak bisa diberi ekstensi dan pada pengelolaan nama domain internal. Tapi bukan solusi lengkap: single point of failure, iklan first-party, dan jalur DoH tetap ada. Disiplin yang dibutuhkan bukan pada pemasangannya, melainkan pada fallback DNS dan peninjauan allowlist.