Panduan Memilih Resolver DNS Publik

 (evilbit.de)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Resolver DNS publik tidak seharusnya dinilai hanya dari kecepatan; privasi, pemfilteran, yurisdiksi, pihak pengelola, dan transport terenkripsi juga perlu dipertimbangkan bersama, dan panduan ini membandingkan 30 layanan global berdasarkan kebutuhan
  • Alat pemilihan menggunakan DoH·DoT·DoQ·DNSCrypt, validasi DNSSEC, IPv6, yurisdiksi, jenis operator, dan EDNS Client Subnet sebagai filter keras, lalu memberi skor prioritas berdasarkan tujuan penggunaan
  • Uji latensi DoH berbasis browser menunjukkan kecepatan relatif dari lokasi saat ini, tetapi mencakup overhead TLS/HTTP dan tidak dapat mengukur resolver yang hanya mendukung DNS plaintext
  • DNS terenkripsi mengurangi penyadapan dan manipulasi oleh pihak di tengah, tetapi penyedia resolver yang dipilih tetap dapat melihat domain yang dicari, sehingga kebijakan tanpa log dan desain oblivious juga perlu dipertimbangkan
  • Dalam pemilihan praktis, DNSSEC, trade-off kecepatan-privasi pada ECS, performa DoQ, karakteristik DNSCrypt, batasan analisis lalu lintas, perbedaan kepatuhan standar, serta risiko yurisdiksi dan sentralisasi perlu dinilai bersama

Kriteria yang dibandingkan oleh alat pemilihan

  • Resolver DNS publik dibandingkan dengan cara memeriksa syarat yang dianggap penting oleh pengguna
  • Kondisi yang digunakan sebagai filter keras
    • Transport terenkripsi: DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), DNS-over-QUIC (DoQ), DNSCrypt
    • Dukungan validasi DNSSEC
    • Penyediaan alamat resolver IPv6
    • Yurisdiksi operator
    • Jenis operator: nirlaba·komunitas·kepentingan publik, komersial, semua
    • EDNS Client Subnet (ECS): tidak digunakan, digunakan, tidak peduli
  • Item yang masuk ke penilaian prioritas
    • Privasi maksimum dan tanpa log atau log minimum
    • Pemblokiran malware·phishing
    • Pemblokiran iklan·pelacak
    • Kontrol orang tua dan pemblokiran konten dewasa
    • Tanpa pemfilteran, mengembalikan respons DNS yang dipublikasikan apa adanya
    • Daftar/rule pemblokiran kustom melalui akun
    • Kecepatan latensi rendah berbasis anycast global
    • Operator nonkomersial

Uji kecepatan DoH berdasarkan lokasi saat ini

  • Uji bawaan mengukur waktu pulang-pergi dari browser ke masing-masing resolver yang mendukung DoH
  • Resolver yang hanya mendukung DNS plaintext tidak dapat diuji dengan cara ini
  • Hasilnya merupakan nilai referensi relatif dan mencakup overhead TLS dan HTTP, sehingga sebaiknya dijalankan beberapa kali
  • Karena browser mengirim kueri langsung ke tiap resolver, alamat IP pengguna terekspos ke resolver tersebut
  • Implementasi uji ini terinspirasi dari DNS Speed Test open source karya Silviu Stroe, tetapi merupakan implementasi independen dan hanya berjalan saat halaman disajikan melalui HTTPS

Performa dan perbedaan transport terenkripsi

  • Transport terenkripsi seperti DoH dan DoT menambah latensi per kueri, tetapi total waktu muat halaman sering kali mendekati DNS plaintext, dan overhead DoH juga cenderung kecil di lingkungan nyata
  • Pada koneksi dengan loss atau latensi tinggi, Do53 plaintext masih lebih unggul
  • Performa berbeda menurut penyedia dan wilayah, sehingga resolver tercepat bergantung pada lokasi pengguna
  • Dalam pengukuran end-to-end skala besar terhadap DNS terenkripsi, kemungkinan kueri disadap atau diubah saat transmisi jauh lebih rendah dibanding DNS plaintext, dan overhead-nya kecil
  • Namun, dalam studi tersebut sekitar 25% penyedia DoT memberikan sertifikat TLS yang tidak valid, sehingga penting memilih penyedia dengan kualitas operasional yang baik

Batasan nyata privasi

  • DNS terenkripsi menyembunyikan kueri dari jaringan, tetapi penyedia resolver yang dipilih tetap dapat melihat semua domain yang dicari
  • Jika ini menjadi masalah, pilih operator tanpa log atau pertimbangkan desain oblivious seperti ODoH, di mana proxy memisahkan identitas dan kueri
  • Cloudflare dan Apple adalah contoh yang telah menerapkan ODoH
  • DNS terenkripsi saja tidak sepenuhnya menyembunyikan situs yang dikunjungi
    • Bahkan dengan DoH, domain yang dikunjungi dapat diidentifikasi dengan akurasi tinggi melalui analisis lalu lintas
    • Padding EDNS standar juga tidak sepenuhnya mencegah hal ini
    • Jika model ancaman ini relevan, jangan hanya mengandalkan padding; gunakan juga Tor atau desain oblivious

DNSSEC, ECS, yurisdiksi

  • Hanya resolver yang melakukan validasi DNSSEC yang melindungi dari record palsu
  • Google, Cloudflare, dan Quad9 memvalidasi DNSSEC, serta menangani rollover root key KSK pertama tanpa gangguan bagi pengguna
  • Jika integritas penting, validasi DNSSEC harus dianggap sebagai syarat wajib
  • EDNS Client Subnet (ECS) mengirim sebagian IP ke CDN demi routing geografis yang lebih baik
    • Google dan OpenDNS mengirim ECS untuk pemetaan CDN yang lebih presisi
    • Cloudflare dan Quad9 standar menonaktifkan ECS demi privasi
  • Lokasi hukum operator memengaruhi tindakan yang dapat dipaksakan dan pencatatan log
  • Sejumlah kecil penyedia menangani porsi besar trafik DNS rekursif global
  • NSA Amerika Serikat memperingatkan bahwa resolver eksternal dapat melewati pemfilteran dan inspeksi DNS internal, sehingga perlu menimbang keseimbangan antara kemudahan dan kontrol

DoQ dan DNSCrypt

  • Dalam pengukuran DoQ tahun 2022, DNS-over-QUIC mengungguli DoT dan DoH dalam waktu respons
  • Namun, karena batasan validasi alamat pada QUIC, sekitar 40% handshake menjadi lebih lambat
  • Jika klien dan resolver sama-sama mendukungnya, DoQ menjadi opsi terenkripsi yang lebih disukai
    • Contoh dukungan: Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS, dan layanan utama di Tiongkok
  • DNSCrypt adalah opsi enkripsi yang lebih tua daripada DoH, DoT, dan DoQ, dan versi 2 dirilis pada 2013
  • DNSCrypt mengenkripsi sejak paket pertama menggunakan kunci publik yang dibagikan sebelumnya oleh resolver, sehingga tidak memerlukan lookup nama host plaintext maupun ketergantungan pada certificate authority
  • Mode Anonymized DNS pada 2019 juga menyembunyikan IP klien
  • Di antara objek perbandingan, penyedia DNSCrypt adalah Quad9, OpenDNS, AdGuard, NextDNS, Control D, dan Yandex
  • Angka penggunaan yang andal masih kurang, dan pengukuran skala besar seperti APNIC Labs melacak DoH dan DoT tetapi tidak melacak DNSCrypt

Kualitas implementasi resolver dan data operasional

  • Dalam studi Extended DNS Errors tahun 2023, resolver besar menunjukkan ketidaksesuaian pelaporan error diagnostik pada 94% kasus uji
  • Cloudflare menunjukkan pelaporan error paling presisi dalam studi tersebut
  • Perbedaan kualitas implementasi dan kepatuhan standar antar-resolver memengaruhi pemecahan masalah dan keandalan
  • Data operasional dan komunitas yang dapat dijadikan referensi

Resolver kecil, komunitas, dan regional

  • Di luar tabel perbandingan, ada resolver hobi, komunitas, dan khusus negara; status serta kebijakannya perlu diperiksa sebelum digunakan
  • Entri Eropa dirangkum di European Alternatives
  • Resolver di wilayah dengan sensor kuat atau sanksi dapat menerapkan aturan konten lokal atau dioperasikan untuk melewati pemblokiran geografis, sehingga perlu kehati-hatian lebih
  • Contoh layanan
    • DNS4all: resolver Eropa tanpa filter yang menekankan netralitas dan performa
    • BlahDNS: proyek open source pemblokiran iklan hobi yang berjalan di server regional kecil, mendukung DoH·DoT·DoQ
    • LibreDNS: resolver komunitas dari LibreOps, dengan pemblokiran iklan dan kebijakan tanpa log, mendukung DoH·DoT
    • Dismail.de: resolver komunitas Jerman berfokus privasi, tanpa log, mendukung DoH·DoT
    • IIJ Public DNS: resolver publik DoH·DoT dari Internet Initiative Japan, memblokir domain materi eksploitasi seksual anak
    • DNS for Family: DoH pemfilteran keluarga yang mencakup konten dewasa, perjudian, malware, iklan·pelacak, dan safe search
  • Layanan legacy atau yang sudah dihentikan yang sebaiknya dihindari mencakup Oracle Dyn, Level3 (4.2.2.x), Freenom World, dns0.eu, dan Norton ConnectSafe

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Opini Hacker News

  • Setiap kali melihat daftar seperti ini atau pengumuman layanan baru, saya tidak terlalu terkesan, dan di Hacker News pun tampaknya cukup banyak reaksi yang mirip
    Saya sudah hampir 25 tahun menjalankan sendiri layanan DNS proksi, dan pernah memakai tiga paket perangkat lunak di enam sistem operasi; semua item di tab filter bisa dilakukan sendiri, dan memang saya lakukan
    Yang menarik dari daftar ini bukan pilihannya, melainkan hal-hal yang terungkap. Misalnya, semua item yang ditandai sebagai ‘China’ disebut ‘beroperasi di bawah regulasi Tiongkok’, dan pada 2026 ini bukan hanya item Tiongkok, tetapi juga faktor yang perlu diperhatikan pengguna di benua saya
    Frasa ‘dioperasikan oleh 1 individu di Denmark’ adalah informasi menarik yang menunjukkan bus factor, tetapi kita tidak bisa berasumsi item lain lebih baik hanya karena mereka tidak menyebutkan hal itu. Informasi tentang siapa di balik DNS.Watch jauh lebih sedikit dibanding Thomas Steen Rasmussen, dan tampaknya layanan itu setidaknya pernah down sekali dalam beberapa tahun terakhir, jadi ini kekhawatiran yang wajar
    Quad101 tampaknya punya pembatasan wilayah ketersediaan, dan ada banyak faktor lain yang tidak ada di daftar ini tetapi bisa penting bagi pengguna, seperti Gcore yang merupakan perusahaan AI

    • ‘Dioperasikan oleh 1 individu di Denmark’ lebih menarik dari sisi pengawasan organisasi daripada bus factor
      Jika beberapa orang terlibat dalam operasional, mereka bisa saling mengawasi dan mengangkat masalah bila terlihat sesuatu yang aneh, seperti resolver DNS melakukan logging selektif atau mengintervensi hasil. Jika satu orang mengoperasikan semuanya, tidak ada yang bisa menahan orang tersebut
      Orang mungkin berpikir, “orang itu berprinsip, jadi tidak mungkin melakukan hal seperti itu,” tetapi tekanan dari lembaga penegak hukum bisa sangat kuat
    • Sekitar 2 tahun lalu saya mengonfigurasi sendiri sebuah resolver, dan berjalan baik-baik saja. Belum pernah ada masalah

  • Jika memakai DNS resmi ISP, Anda bisa mendapatkan rute terpendek yang memungkinkan dari titik handoff ISP ke CDN atau trunk luar negeri. Intinya, jangan memakai DNS umum yang tidak memahami struktur ISP
    ISP: 1 ms ke Cloudflare
    Cloudflare: 10 ms ke Cloudflare
    Namun, saran ini berlaku untuk negara dengan hukum privasi yang baik dan tanpa pengawasan negara. Jadi bukan AS

    • Jika membutuhkan DNS tanpa sensor, cara itu tidak bagus
    • Dalam praktiknya, memakai DNS yang memblokir server iklan kemungkinan besar memberi performa keseluruhan yang lebih baik
    • Saya tidak tahu apakah negara-negara seperti itu benar-benar masih ada. Dan ini bukan hanya soal privasi; hampir semua negara berusaha mencegah pengguna mengakses tempat-tempat yang tidak mereka inginkan, biasanya dengan cara ceroboh seperti DNS bawaan ISP mengarahkan ke halaman peringatan alih-alih situs yang semula ingin dibuka
      Karena itu, mengganti ke DNS seperti 8.8.8.8 belum tentu meningkatkan privasi, tetapi menjadi langkah besar pertama untuk memperbaiki pengalaman browsing
    • Cloudflare, seperti diketahui luas, memakai anycast, jadi dari mana pun asalnya, respons DNS tetap sama. Angka yang diberikan sulit dianggap disebabkan oleh DNS
      Justru Cloudflare bisa memperpendek kueri rekursif untuk layanannya sendiri sehingga tahap resolusi nama bisa lebih cepat, dan bila perlu routing berbasis lokasi juga dimungkinkan lewat eDNS Client Subnet
    • Mengganti DNS hampir tidak berdampak pada privasi. Kueri DNS dan SNI tetap bisa dibaca

  • Saya butuh saran tentang cara memakai resolver DNS bersama Wi-Fi publik
    Banyak Wi-Fi publik harus memakai DNS mereka sendiri agar bisa mengalihkan ke layar persetujuan syarat penggunaan, dan kadang meminta otorisasi ulang setiap 30–60 menit
    Saat masalah muncul, kita menyadari internet berhenti, mencoba ping ke google.com dan menunggu timeout, menebak apakah ini masalah ISP, lalu sadar bahwa sesi Wi-Fi sepertinya kedaluwarsa, mengganti DNS dan mengosongkan cache, membuka domain non-TLS, menyetujui gerbang, lalu mengembalikan DNS lagi
    Pasti ada sesuatu yang bisa mengelola hal seperti ini

    • Kalau di macOS, mungkin bisa diselesaikan dengan /etc/resolver
      sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
      Saya memakai cara ini ketika situs internal kampus hanya bisa di-resolve lewat nameserver jaringan. Saya terpikir ini juga mungkin bisa diterapkan pada URL yang dipakai macOS untuk deteksi captive portal, dan harus saya cek lain kali saat pergi ke kafe
    • Di macOS dan iOS, Anda bisa membuat profil yang menentukan server DNS yang selalu digunakan. Ini juga berlaku di Wi-Fi lain dan data seluler
      https://doh.lvv.me/
      Saya sudah memakainya selama beberapa tahun dan tidak pernah mengalami masalah di hotspot publik
    • Cukup masukkan alamat IP di bilah alamat. Biasanya semua trafik port 80 sedang dicegat
    • Hal seperti ini seharusnya ditangani oleh sistem operasi sebagai bagian dari dukungan captive portal. Sebaiknya hubungi pembuat sistem operasi dan daftarkan bug

  • Menggunakan Unbound secara lokal sebagai server DoH. Paket Unbound di Alpine Linux dikompilasi bersama libnghttp2 yang diperlukan untuk listener DoH bawaan, dan ini sudah cukup untuk mengaktifkan ECH
    Setiap jam, semua domain yang sering dipakai dipra-cache dengan cron. ISP tidak akan mengutak-atik permintaan DNS saya, dan para pegawainya lebih aneh daripada saya. Kalau saya mulai menjelajah web lewat ponsel, saya akan membuat server DoH publik sendiri. Hanya butuh beberapa menit, dan saya juga bisa mendapatkan log kueri sendiri saat men-debug masalah aneh
    [1] - https://tls-ech.dev/

    • Sudah sekitar 3 tahun menjalankan DoH, DoT, DoQ, TCP, dan UDP dengan instance public powerdns, dnsdist, serta server rekursif/otoritatif sendiri
      Sebelumnya saya memakai bind, unbound, dan dnsmasq, jadi konfigurasinya memang butuh waktu. Sangat stabil, bisa dipakai di perangkat mobile maupun perangkat lama, dan juga bisa digunakan sebagai resolver untuk unbound, adguard/dnsproxy, maupun resolve.conf lokal
    • Saya penasaran kenapa dipra-cache. Kalau demi kecepatan, bukankah paling hanya 30–50 ms? Saya juga penasaran apakah TTL dari server otoritatif dipaksa menjadi 3600 jika lebih pendek dari 60 menit
      Saya juga penasaran apakah semua koneksi ke situs web yang dikunjungi diaudit sampai mengumpulkan domain yang meng-host aset lalu semuanya dipra-cache, atau apakah yang penting hanya domain situs utama yang paling berpengaruh pada latensi yang terasa
    • Unbound punya prefetch untuk memperbarui record cache yang mendekati kedaluwarsa, dan ada beberapa opsi penyesuaian terkait cache dan TTL. serve-expired juga tampaknya bekerja dengan baik
    • Saya penasaran seperti apa bentuk “setiap jam, semua domain yang sering dipakai dipra-cache dengan cron” itu. Apakah berupa skrip shell yang mengueri daftar hostname, dan apa kriteria “domain yang digunakan”
    • Di sini juga menjalankan Unbound. Saya suka karena bisa memakai wildcard untuk pemblokiran domain. Saya memakai daftar blokir besar, lalu menaruh daftar pengecualian di atasnya
      Ada juga alat kecil yang menyederhanakan input seperti ayt7.ads.acme.com, afi6.ads.acme.com, foi5.ads.acme.com menjadi ads.acme.com
      Selain itu ada skrip yang menghasilkan variasi dari domain yang digunakan. Misalnya jika domain sahnya mybank.com, maka myb4nk.com, mibank.com, mybank.{semua TLD lain} dan seterusnya diblokir
      Saya membuat ini setelah bank mengirimkan contoh situs phishing yang sangat meyakinkan. Variasi seperti ini dibuat sampai ratusan ribu dan semuanya diblokir di Unbound
      Saya sudah memakai konfigurasi ini selama bertahun-tahun, dan satu juta domain yang diblokir pun berjalan baik di Pi 3 lama. Di komputer yang lebih kuat, Unbound seharusnya bisa menangani daftar blokir jutaan, mungkin bahkan puluhan juta domain. Saya belum beralih ke pendekatan daftar izinkan saja
      Semua domain Unicode juga saya blokir. Domain yang memakai karakter Unicode pada namanya tidak bisa diakses, dan saya tidak peduli

  • Saya memakai NextDNS dengan puas. Ada banyak kemungkinan konfigurasi, seperti daftar filter mana yang diaktifkan, bagaimana logging dilakukan, dan sebagainya
    Stabil dan cepat hampir di mana saja. Ini lebih sulit dicapai jika menjalankan resolver sendiri di cloud, dan lagi pula saya tidak ingin memeliharanya

    • Saya juga memakai NextDNS dengan baik. Terutama setelah bertahun-tahun mengutak-atik Pi-hole lalu lelah memeliharanya, saya jadi lebih puas. Saat perlu, juga mudah dipakai bersama Mullvad VPN
    • Bagi saya juga cukup bagus

  • Saya tidak tahu kenapa hanya 29
    Apakah penulis mengatakan bahwa jumlah resolver terbuka di internet saat ini memang kira-kira segitu
    Saya heran bagaimana bisa mempertimbangkan “privasi” atau “keamanan” DNS tanpa sekaligus mempertimbangkan SNI
    SNI memungkinkan pihak ketiga melihat nama domain mana yang ingin dihubungi pengguna pada alamat publik, dan juga memungkinkan mereka mengganggu koneksi tersebut
    DNS hanya memungkinkan pihak ketiga melihat bahwa pengguna menanyakan alamat publik untuk nama domain tertentu. Untuk mengaitkan trafik non-DNS dengan kueri ini, diperlukan asumsi tentang bagaimana perangkat lunak tersebut bekerja
    Karena itu tidak mengejutkan jika perusahaan iklan yang menguasai browser web populer ingin pengguna memilih DoH di dalam browser, atau di sistem operasi perusahaan. Jika ini secara menyesatkan disebut “private DNS”, pihak ketiga dapat mengorelasikan kueri dengan trafik non-DNS dari perangkat lunak yang berjalan di browser atau sistem operasi perusahaan secara lebih efektif
    Klaim menyesatkan seperti ini bisa berujung gugatan. Misalnya, pengguna pernah menang dalam gugatan terkait klaim menyesatkan tentang “private browsing”

    • Angka 29 itu berarti layanan-layanan yang cukup dipercaya oleh banyak orang untuk menyerahkan kueri DNS mereka. Selain itu, ke-29 layanan tersebut memublikasikan informasi tentang atribut layanannya
      Jika membaca seluruh halaman, resolver DNS publik lain yang layak disebut juga dicantumkan secara terpisah
      Untuk long tail resolver DNS terbuka yang tidak dikenal, gunakan Shodan. Namun saya tidak ingin menyarankan agar mempercayai apa yang ditemukan di Shodan untuk mengurus penggunaan internet Anda
      SNI memang masalah privasi internet secara umum, tetapi bukan atribut DNS. Sisi positifnya, ECH sudah melewati IETF dan perlahan akan tersedia juga bagi pengguna umum
      — penulis
    • ECH belum tersedia luas bagi pengguna web umum selain di beberapa situs “uji coba”
      Tidak jelas juga siapa yang dimaksud dengan “you” dalam jawaban penulis
      Dalam kasus saya, DNS jarak jauh hanya dipakai saat mengambil data DNS massal secara berkala. Saat mengakses server HTTP, saya tidak membuat permintaan DNS jarak jauh. Saya sudah memiliki informasi alamat IP yang diperlukan, dan cara ini lebih cepat serta lebih stabil
      Data DNS massal dari berbagai sumber dimuat ke memori proxy penerus TLS lokal
      Setiap pengguna berbeda, dan masing-masing harus berpikir sendiri

  • Untuk pengguna Kanada, CIRA menjalankan resolver publik melalui IPv4, IPv6, DoH, dan DoT
    https://www.cira.ca/en/canadian-shield/configure/summary-cir...

    • Saya tidak tahu kenapa orang Kanada harus lebih mempercayai CIRA dibanding alternatif lain. Meski begitu, kemungkinan besar tetap lebih baik daripada memakai DNS ISP bawaan

  • DNScryptProxy memelihara daftar besar server DNS publik. Juga ditampilkan apakah mendukung DNSSEC, pemfilteran, dan logging
    https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...

  • Akan bagus jika situs seperti ini menyediakan uji perbandingan kecepatan dasar berdasarkan jaringan lokal
    Sepertinya berguna jika bisa membandingkan waktu respons P90 dan waktu respons median untuk kueri acak

    • Saya penulisnya, dan sekarang sudah saya tambahkan: https://evilbit.de/dns-resolver-guide2.html#speedtest
      Namun hanya berfungsi di DoH
    • Jika Anda meng-clone repositori ini lalu mengubah nama domain dan resolver sesuai keinginan, Anda bisa mendapatkan hasil yang mirip dengan yang dicari
      [1] - https://github.com/cleanbrowsing/dnsperftest
    • Untuk keperluan ini saya menjalankan instance smokeping secara lokal. Saya mengirim ping ke beberapa server DNS, DNS ISP, dan beberapa situs web utama, lalu secara berkala memperbarui upstream server DNS lokal sesuai hasilnya
      Di lingkungan saya, semua server DNS besar berada di kisaran 5–6 ms, tetapi tidak selalu begitu. DNS ISP juga rata-ratanya mirip, tetapi variasinya besar dan ada lonjakan hingga 50 ms. Padahal seharusnya lokasinya yang paling cepat

  • DNS adalah topik yang sangat penting untuk privasi dan keamanan. Menurut saya, daripada memilih DNS publik, lebih baik meng-host infrastruktur sendiri
    Tidak perlu instance publik. Cukup jalankan ADGUARD, unbound, dnsmasq, atau dnsdist dalam mode rekursif di router atau mesin
    Anda juga bisa mengatur pembatasan dan daftar blokir sesuai kebutuhan

    • Meski begitu, ISP tetap bisa mencatat semua kueri