DNS pribadi vs pemblokiran situs oleh ISP

Jawaban singkat: DNS pribadi hanya mengganti satu lapisan

DNS pribadi tidak membuka situs yang diblokir ISP kalau pemblokirannya tidak berada di lapisan DNS. Setelan itu mengubah satu hal saja: siapa yang menjawab pertanyaan "nama ini alamat IP-nya berapa". Kalau ISP memblokir dengan cara membuat resolvernya menjawab salah, mengeluarkan resolver itu dari jalur memang cukup, dan situsnya terbuka. Kalau yang memblokir adalah perangkat di jalur keluar yang membaca nama situs di dalam paket TLS, atau rute ke alamat tujuan yang sudah dibuang, jawaban DNS yang benar tidak menolong sama sekali. Paket Anda tetap mati di titik yang sama.

Halaman ini mengajarkan cara membedakan kasus-kasus itu dari laptop dan ponsel Anda sendiri. Semua perintah di bawah Anda jalankan sendiri, di koneksi Anda sendiri, karena hanya itu yang menjawab pertanyaannya. Perilaku satu ISP bukan perilaku ISP lain, dan bisa berubah minggu depan tanpa pemberitahuan. Jadi tidak ada satu pun bagian tulisan ini yang mengklaim apa yang dilakukan penyedia tertentu hari ini.

Apa yang benar-benar diubah setelan "DNS Pribadi"

Di Android jalurnya: Setelan, lalu Jaringan & internet, lalu DNS Pribadi. Pilihan "Nama host penyedia DNS pribadi" meminta satu nama host, misalnya dns.google atau one.one.one.one, lalu memakai DoT (DNS over TLS) untuk semua kueri nama di perangkat itu. DoT adalah DNS biasa yang dibungkus TLS (transport layer security) di port TCP 853. Sertifikatnya diverifikasi terhadap nama host yang Anda tulis, jadi Anda tahu sedang berbicara dengan resolver yang benar.

Yang berubah: resolver ISP keluar dari jalur, dan isi kueri tidak lagi terbaca di jaringan lokal. Karena isinya terenkripsi dan sertifikatnya diverifikasi, kueri itu juga tidak bisa dijawab diam-diam oleh perangkat di tengah. Akibatnya, pengalihan di lapisan DNS berhenti bekerja.

Yang tidak berubah: setelah nama menjadi alamat, paket Anda tetap berjalan ke alamat tersebut melalui jaringan ISP yang sama. Alamat IP tujuan ada di header setiap paket, terbuka, karena router memang harus membacanya. Nama situs juga masih dikirim apa adanya di dalam TLS ClientHello, di kolom SNI (server name indication), kecuali ECH (encrypted client hello) aktif di kedua sisi. Dasar setelan ini dibahas terpisah di apa itu DNS pribadi dan bagian mana yang sebenarnya dienkripsi, dan mekanisme kuerinya di cara kerja DNS dari pertanyaan sampai jawaban.

Satu catatan praktis yang sering mengejutkan. Mode "Nama host" gagal tertutup. Kalau port 853 ke host itu tidak bisa dicapai, Android tidak kembali ke DNS biasa. Tidak ada nama yang bisa diselesaikan, dan seluruh internet terlihat mati walau koneksi datanya normal. Mode "Otomatis" berbeda: ia mencoba DoT ke resolver jaringan, lalu kembali ke port 53 biasa kalau gagal.

Tiga tempat sebuah situs bisa mati, dan satu yang bukan ulah ISP

• Lapisan DNS. Resolver menjawab dengan alamat lain, dengan 0.0.0.0, atau dengan NXDOMAIN. Gejala khasnya: browser membuka halaman pemberitahuan, bukan pesan error koneksi.
• Lapisan nama di dalam koneksi. Perangkat inline membaca SNI di ClientHello TLS, atau header Host pada HTTP tanpa enkripsi, lalu mengirim TCP RST atau membuang paketnya. Gejalanya: TCP tersambung, lalu koneksi terputus tepat setelah handshake mulai.
• Lapisan rute dan filter IP. Alamat tujuan tidak diteruskan, karena null route atau daftar filter di perbatasan jaringan. Gejalanya: SYN tidak pernah dijawab, untuk port apa pun.
• Bukan ISP. Server tujuan sendiri yang menolak, misalnya geoblok per negara, domain kedaluwarsa, atau layanan yang sedang mati. Ini paling sering tertukar dengan blokir ISP.

Setelan DNS hanya bisa menyentuh lapisan pertama. Kalau blokirnya di lapisan kedua atau ketiga, alamat resolver mana pun yang Anda tulis akan memberi hasil yang sama, karena bagian yang memblokir tidak pernah bertanya kepada resolver.

Siapkan alatnya

Semua uji di bawah berjalan di Ubuntu 24.04 sebagai pengguna biasa, kecuali yang menyebut sudo.

sudo apt update
sudo apt install -y dnsutils knot-dnsutils curl netcat-openbsd mtr-tiny traceroute

Ponsel tidak punya alat ini. Cara paling andal menguji jalur data seluler Anda adalah menyalakan hotspot di ponsel, menyambungkan laptop ke hotspot itu, lalu menjalankan perintah yang sama dari laptop. Jalurnya sama dan alatnya lengkap. Satu hal yang perlu diingat: setelan DNS pribadi di ponsel tidak otomatis berlaku untuk laptop yang menumpang, jadi jangan menilai resolver dari perilaku sistem laptop. Karena itu setiap dig di bawah menyebut resolvernya secara eksplisit dengan @, supaya tidak ada yang perlu ditebak.

Simpan nama situs yang sedang Anda periksa di satu variabel, agar perintahnya bisa disalin apa adanya. Ganti example.com dengan nama yang gagal dibuka.

SITUS=example.com

Uji 1: apakah resolver ISP yang menjawab salah?

Cari dulu resolver yang dipakai laptop Anda di jaringan itu.

ISP_DNS=$(resolvectl status | awk '/Current DNS Server/ {print $4; exit}')
echo "$ISP_DNS"

Kalau resolvectl tidak ada, karena sistemnya tidak memakai systemd-resolved, pakai nmcli dev show | grep IP4.DNS. Alamat yang muncul biasanya router lokal Anda, yang meneruskan ke resolver ISP, atau resolver ISP langsung. Sekarang bandingkan jawabannya dengan resolver publik.

dig +short A "$SITUS" @"$ISP_DNS"
dig +short A "$SITUS" @1.1.1.1

Jawaban yang berbeda adalah bukti lapisan DNS. Bentuk perbedaannya menyebutkan caranya. Satu alamat yang sama untuk banyak situs berbeda berarti pengalihan ke satu server pemberitahuan. 0.0.0.0 atau jawaban kosong berarti nama itu dijawab mati. Untuk melihat kodenya, jalankan ulang tanpa +short dan baca baris ;; ->>HEADER<<-: status: NXDOMAIN berarti resolver menyatakan nama itu tidak ada, padahal resolver publik menemukannya.

Jawaban yang sama dari kedua resolver berarti pemblokirannya bukan di DNS, sehingga mengganti DNS pribadi tidak akan mengubah apa pun. Jangan berhenti di sini. Lanjutkan ke uji 2.

Ada satu kemungkinan lain yang harus dibuang lebih dulu: kueri Anda ke 1.1.1.1 mungkin tidak benar-benar sampai ke Cloudflare. Perangkat di jaringan bisa mengambil semua trafik port 53 dan menjawabnya sendiri, apa pun alamat yang Anda tulis. Ujinya sederhana. Tanyakan sesuatu ke alamat yang pasti tidak menjalankan DNS. 192.0.2.1 ada di blok dokumentasi RFC 5737 dan tidak dirutekan di internet.

dig +short +timeout=3 +tries=1 A example.com @192.0.2.1

Hasil yang benar adalah tidak ada jawaban, lalu ;; connection timed out; no servers could be reached. Kalau Anda justru menerima sebuah alamat IP, berarti port 53 di jaringan itu dijawab oleh perangkat lokal. Di jaringan seperti itu DoT memang mengubah keadaan, karena sesi TLS ke port 853 dengan sertifikat terverifikasi tidak bisa dipalsukan tanpa Anda sadari: ia berhasil, atau gagal dengan jelas.

Sekalian buktikan DoT-nya bisa lewat, sebelum Anda mengandalkannya di ponsel.

kdig +tls-ca +tls-host=dns.google @8.8.8.8 "$SITUS"

Baris yang menyebut ;; TLS session disusul bagian ;; ANSWER SECTION berarti port 853 terbuka dan sertifikatnya sah. Kalau perintah ini menggantung lalu gagal, port 853 tidak bisa lewat di jaringan itu. Itu penjelasan mengapa ponsel yang disetel ke mode nama host tiba-tiba tidak bisa membuka apa pun: resolusi nama berhenti total, bukan karena situsnya diblokir.

Uji 2: apakah namanya yang dibaca, bukan alamatnya?

Uji ini mengeluarkan DNS dari persamaan. Ambil alamat dari resolver publik, lalu paksa curl memakai alamat itu tanpa bertanya kepada resolver mana pun.

IP=$(dig +short A "$SITUS" @1.1.1.1 | tail -1)
echo "$IP"
nc -vz "$IP" 443

nc yang mencetak Connection to ... 443 port [tcp/https] succeeded! berarti TCP sampai ke tujuan dan portnya menerima koneksi. Kalau ini gagal untuk semua port, lompat ke uji 3. Kalau berhasil, teruskan.

curl -sS -o /dev/null -D - --max-time 15 --resolve "$SITUS":443:"$IP" "https://$SITUS/"

--resolve menanam pasangan nama dan alamat langsung ke dalam curl, jadi tidak ada kueri DNS sama sekali. Kalau permintaan ini berhasil sementara browser Anda gagal, masalahnya di DNS, dan uji 1 seharusnya sudah menunjukkannya. Kalau permintaan ini gagal padahal TCP tadi tersambung, DNS sudah tidak relevan: ada yang bereaksi terhadap nama di dalam koneksi. Pesan yang biasa muncul:

curl: (35) Recv failure: Connection reset by peer
curl: (28) Operation timed out after 15001 milliseconds with 0 bytes received

Untuk memastikan yang bereaksi adalah SNI, kirim dua ClientHello ke alamat yang sama dengan nama yang berbeda.

openssl s_client -connect "$IP":443 -servername "$SITUS" </dev/null 2>&1 | head -12
openssl s_client -connect "$IP":443 -servername www.wikipedia.org </dev/null 2>&1 | head -12

Bacalah perbedaannya, bukan berhasil atau tidaknya. Server yang asli menjawab dengan sertifikat, atau dengan peringatan TLS yang tertib seperti tlsv1 alert internal error. Perangkat penyaring di tengah memutus sesi sebelum ada ServerHello, dan openssl melaporkannya sebagai write:errno=104 atau SSL routines::unexpected eof while reading. Nama asli yang diputus tanpa ServerHello, sementara nama lain ke alamat yang sama tetap mendapat sertifikat, adalah pola penyaringan berbasis nama.

Periksa juga HTTP tanpa enkripsi di port 80, karena header Host dikirim terbuka dan sering diperiksa oleh perangkat yang sama.

curl -sS -o /dev/null -D - --max-time 10 -H "Host: $SITUS" "http://$IP/"

Balasan HTTP/1.1 302 atau 307 yang mengarah ke halaman pemberitahuan, padahal Anda meminta alamat IP secara langsung, berarti ada perangkat yang menulis jawaban atas nama server tujuan.

Di sini muncul hal yang paling sering disalahpahami. Setelah DNS pribadi aktif, blokir semacam ini tidak hilang. Tampilannya saja yang berubah. Halaman pemberitahuan yang rapi berganti menjadi koneksi yang terputus atau menggantung, karena resolver ISP sudah tidak ikut bicara sementara penyaring di jalur masih bekerja. Perubahan pesan error itu bukan tanda setelan DNS Anda salah. Itu bukti blokirnya berada di atas DNS.

Uji 3: apakah paketnya sampai ke tujuan sama sekali?

Kalau nc -vz tidak pernah berhasil untuk port mana pun, curigai lapisan rute. Lihat di hop mana jalurnya berhenti, dengan probe TCP ke port 443 supaya Anda tidak tertipu router yang membuang ICMP.

sudo mtr -T -P 443 -c 20 -r "$IP"
sudo traceroute -T -p 443 -n "$IP"

Cara membacanya. Kehilangan paket yang muncul di satu hop lalu hilang lagi di hop berikutnya adalah pembatasan laju ICMP di router itu, dan tidak berarti apa-apa. Yang berarti adalah kehilangan yang mulai di satu hop dan bertahan sampai baris terakhir. Kalau jalurnya berhenti di dalam jaringan ISP Anda, beberapa hop sebelum tujuan, paket itu tidak diteruskan keluar. Kalau jalurnya sampai ke jaringan tujuan lalu berhenti di sana, kemungkinan besar tujuannya sendiri yang menolak.

Alat ini punya batas yang perlu diakui: traceroute tidak bisa memisahkan null route dari filter paket dengan pasti, karena keduanya bisa diam tanpa mengirim pesan ICMP apa pun. Pembanding yang menyelesaikannya berada di luar koneksi Anda. Jalankan uji yang sama dari sebuah VPS di jaringan lain.

dig +short A "$SITUS" @1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 15 "https://$SITUS/"

VPS yang berhasil sementara koneksi rumah Anda gagal menunjuk ke jalur lokal Anda. VPS yang juga gagal dengan cara yang sama menunjuk ke tujuan, misalnya geoblok, dan tidak ada tunnel yang memperbaiki itu kecuali titik keluarnya kebetulan diizinkan oleh server tujuan.

Membacanya sebagai satu pertanyaan lapisan

1. Jawaban resolver ISP berbeda dari resolver publik: lapisan DNS. DoT atau DoH mengubahnya, dan DNS pribadi di ponsel akan terasa langsung.
2. Jawaban sama, TCP 443 tersambung, handshake diputus hanya untuk nama tertentu: lapisan nama. Setelan DNS tidak menyentuhnya.
3. TCP tidak pernah tersambung dan jalur berhenti di dalam jaringan ISP: lapisan rute. Setelan DNS tidak menyentuhnya.
4. Semua uji berhasil dari VPS lain dan gagal dari rumah: jalur lokal Anda, apa pun mekanismenya.
5. Gagal dari mana saja, dengan pesan yang datang dari server tujuan: tujuannya, bukan jalurnya.

ECH, dan kenapa SNI belum hilang

ECH mengenkripsi ClientHello, termasuk SNI, sehingga nama situs tidak lagi terbaca di jalur. Ia butuh tiga hal bekerja bersama, dan itulah sebabnya ECH belum menyelesaikan masalah ini untuk sebagian besar orang: server harus menerbitkan kunci ECH lewat DNS, browser harus mengambilnya lewat DNS terenkripsi, dan jalurnya harus mengizinkan keduanya. Anda bisa melihat catatan itu sendiri.

dig +short HTTPS crypto.cloudflare.com @1.1.1.1

Rekaman HTTPS yang kembali memuat parameter ech= berisi data base64. Situs yang tidak menerbitkan parameter itu berarti tidak mendukung ECH, jadi namanya tetap dikirim terbuka di ClientHello. Di browser, ECH juga hanya aktif kalau DNS aman dinyalakan, karena kunci ECH datang dari DNS.

Satu hal tetap benar walau ECH aktif: alamat IP tujuan masih ada di header paket, terbuka, dan penyaring bisa bekerja atas dasar alamat itu saja. ECH mempersempit apa yang terbaca. Ia tidak menyembunyikan ke mana Anda pergi.

Kalau blokirnya di atas DNS, yang perlu dipindahkan adalah seluruh jalurnya

Uji 2 dan uji 3 menunjuk ke kesimpulan yang sama: bagian yang memblokir berada di jalur, bukan di resolver. Satu-satunya perubahan yang berpengaruh adalah membuat paket Anda tidak lagi melewati jalur itu dalam bentuk yang bisa dibaca. Secara praktis berarti satu tunnel terenkripsi ke server yang Anda kendalikan, lalu semua trafik keluar dari sana. Dengan cara itu alamat tujuan yang terlihat di jaringan lokal hanyalah alamat server Anda, dan SNI berada di dalam tunnel.

Jalur yang paling lazim adalah WireGuard di VPS sendiri. Langkah lengkapnya, mulai dari pasangan kunci sampai NAT dan aturan firewall, ada di panduan memasang WireGuard di VPS Anda sendiri. Satu jebakan khas yang wajib Anda tutup setelah tunnel jalan: kueri DNS bisa tetap keluar lewat jaringan lokal walau trafik lain sudah tertunnel, jadi periksa kenapa DNS bocor di dalam tunnel WireGuard dan bagaimana menutupnya. Kalau paket tunnelnya sendiri yang tidak lewat, misalnya UDP di port itu dibuang, pilihan berikutnya dibahas di apa yang dijalankan ketika tunnel VPN Anda ikut diblokir. Dan kalau Anda masih menimbang antara menyewa VPS sendiri atau berlangganan layanan siap pakai, bedanya, termasuk siapa yang memegang log dan siapa yang memegang alamat IP keluar, dirangkum di perbandingan VPS sendiri dengan layanan VPN.

Ini bukan obat untuk semua kasus. Kalau uji 3 menunjukkan tujuannya yang menolak, memindahkan jalur hanya memindahkan penolakan.

Sebelum Anda menyimpulkan ini pemblokiran

Sebagian pemblokiran konten di Indonesia diwajibkan oleh regulasi, dan penyelenggara jasa internet menerapkannya karena memang harus. Tulisan ini menjelaskan mekanismenya dan cara mendiagnosisnya, bukan cara menghindari kewajiban hukum. Kalau situs yang Anda uji memang termasuk yang dibatasi secara sah, kesimpulan teknis di atas tetap berlaku, tetapi keputusan apa yang Anda lakukan sesudahnya berada di luar jangkauan tulisan ini.

Jaga juga kerendahan hati diagnostik. Situs yang tidak terbuka sering bukan diblokir. Domain kedaluwarsa, sertifikat lewat masa berlaku, rekaman DNS yang salah diubah, dan server yang mati menghasilkan gejala yang mirip. Uji 1 sampai 3 dirancang untuk membedakannya, dan satu perbandingan dari jaringan lain biasanya menutup perkaranya dalam satu menit.

FAQ

Kenapa situs tetap tidak terbuka setelah saya mengatur DNS pribadi?

Karena blokirnya tidak berada di lapisan DNS. Buktikan dengan satu perintah: curl -sS -o /dev/null -D - --resolve nama-situs:443:alamat-ip "https://nama-situs/" menanam alamat IP langsung ke curl, sehingga tidak ada kueri DNS sama sekali. Kalau permintaan itu masih gagal dengan Connection reset by peer atau timeout, resolver mana pun akan memberi hasil sama, karena bagian yang memblokir tidak bertanya kepada resolver. Sisanya ada di uji 2 dan uji 3 di atas.

Apakah DNS pribadi menyembunyikan situs yang saya buka dari ISP?

Ia menyembunyikan isi kueri nama, dan hanya itu. Setelah nama menjadi alamat, paket Anda tetap berisi alamat IP tujuan di header, yang harus terbuka agar router bisa meneruskannya. Nama situs juga masih dikirim terbuka di kolom SNI pada TLS ClientHello, kecuali ECH aktif di server dan di browser Anda. Jadi daftar tujuan Anda tetap dapat disimpulkan dari jalur, walau kuerinya terenkripsi.

Bagaimana cara tahu blokirnya di DNS atau di SNI?

Bandingkan dua hal. Pertama, dig +short A nama-situs ke resolver ISP dan ke 1.1.1.1: jawaban berbeda berarti lapisan DNS. Kedua, kalau jawabannya sama, sambungkan TCP ke alamat aslinya dengan nc -vz alamat-ip 443. TCP yang berhasil lalu handshake TLS yang diputus hanya ketika SNI memuat nama asli, sementara SNI lain ke alamat yang sama tetap mendapat sertifikat, menunjuk ke penyaringan berbasis nama.

Apakah mengganti DNS ke 1.1.1.1 sama dengan memakai DNS pribadi?

Tidak sama. Mengisi 1.1.1.1 di setelan Wi-Fi mengirim kueri sebagai DNS biasa di port 53 tanpa enkripsi, sehingga perangkat di jalur masih bisa membaca dan bahkan menjawabnya lebih dulu. Uji dig +short +timeout=3 A example.com @192.0.2.1 memperlihatkannya: jawaban dari alamat yang tidak menjalankan DNS berarti port 53 dibajak di jaringan itu. DNS pribadi di Android memakai DoT di port TCP 853 dengan sertifikat terverifikasi, jadi jawaban palsu tidak mungkin lolos tanpa terdeteksi.