Ang naka-encrypt na DNS na walang VPN ay nagtatago ng query, hindi ng address mo
Pinoprotektahan ng naka-encrypt na DNS ang isang palitan sa isang resolver. Hindi nito itinatago ang address mo at hindi nito binubulag ang resolver, kaya itakda ang layunin bago magbasa ng pagsubok sa pagtagas.
Ang pagsubok sa pagtagas ng DNS na nagpapakita ng iyong home network ay hindi patunay na nabigo ang naka-encrypt na DNS, at hindi rin patunay na may gumana. Sinasagot ng pagsubok ang isang tanong: aling resolver ang naabot ng query na ito mula sa network na ito. Kung problema iyon ay depende sa kung ano at kanino ka nagpoprotekta.
Isulat ang layunin bago magpatakbo ng anumang pagsubok.
Hakbang 1: pangalanan ang proteksyong talagang gusto mo
Tatlong layunin ang naghahalo. Maaaring gusto mong tumigil ang isang tagamasid sa landas sa pagbabasa ng mga query. Maaaring gusto mong tumigil ang isang partikular na resolver sa pagtanggap ng mga ito. Maaaring gusto mong tumigil ang mga website na binibisita mo sa pagtingin sa iyong address sa bahay. Ang naka-encrypt na DNS ay nagsisilbi sa una, binabago kung sino ang tumutupad sa pangalawa, at wala talagang ginagawa para sa pangatlo.
Ang VPN ay nagsisilbi sa pangatlo at, depende sa provider, sa una. Wala sa dalawang tool ang superset ng isa.
Hakbang 2: pumili ng resolver at i-verify ang pagkakakilanlan nito
Binabalot ng DNS over TLS ang query sa isang TLS session kasama ang resolver, at binabalot ng DNS over HTTPS ito sa isang HTTP request; inilalarawan ng RFC 7858 at RFC 8484 ang dalawa, at wala sa kanila ang nangangailangan ng tunnel. Sa pagpapatakbo, mahalaga na ma-verify ang certificate laban sa pangalang ginawa mo, dahil ang naka-encrypt na session sa maling partido ay mas masama kaysa plaintext sa tamang partido. Nangangahulugan ito ng mahigpit na mode kung saan inaalok ito ng platform, hindi isang oportunistikong mode na bumabalik kapag nabigo ang verification. Suriin ang session nang direkta bago magtiwala sa setting: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.
Dapat pangalanan ng handshake ang resolver na ginawa mo at magbalik ng chain na maaari mong i-verify.
Hakbang 3: magpasya sa pag-uugali kapag nabigo
Bawat implementasyon ay may patakaran para sa hindi maabot na naka-encrypt na resolver, at ang patakarang iyon ang desisyon sa privacy. Ang mahigpit na mode ay nagpapabigo sa paghahanap, na nakikita at nakakainis. Ang oportunistikong mode ay sumusubok muli sa plaintext, na hindi nakikita at sinisira ang layunin sa mismong araw na mahalaga ito. Pumili nang sinasadya, pagkatapos itala ang pinili sa tabi ng kinakailangan.
Sa systemd-resolved, ang ibig sabihin nito ay DNSOverTLS=yes sa halip na opportunistic; sa Android, ang ibig sabihin ay ang hostname mode ng Private DNS sa halip na awtomatiko.
Suriin kung ano talaga ang may bisa gamit ang resolvectl status | grep -i -A1 "dns over tls", dahil ang drop-in file na hindi kailanman na-reload ay walang binabago.
Hakbang 4: suriin kung sinusunod ng mga aplikasyon ang resolver ng system
Ang browser na may sariling setting ng secure DNS ay ganap na lumalampas sa configuration ng system, gayundin ang container runtime na may naka-embed na resolver o runtime ng wika na nagbabasa ng hard-coded na listahan. Gawin mong sumunod sila sa system o i-configure nang tahasan at itala iyon. Pagkatapos tingnan ang pag-uugali ng fallback ng bawat isa, dahil hindi lahat ay nabigo nang sarado. Maikli ang imbentaryo sa praktika: browser, container runtime, at anumang VPN client na pinapatakbo mo rin.
Ang mga pribadong pangalan ng organisasyon ay nananatili sa aprubadong internal na resolver. Ang pagpapadala sa mga ito sa pampublikong serbisyo para magmukhang maayos ang pagsubok ay sadyang lumilikha ng ibang problema.
Hakbang 5: basahin ang pagsubok sa pagtagas laban sa kinakailangan
Ang pagsubok na nag-uulat ng hindi inaasahang resolver ay isang bakas, hindi hatol. Maaaring naobserbahan nito ang nilalayon na naka-encrypt na resolver, isang setting na partikular sa app, o isang pagbabalik sa plaintext na hindi mo alam. Ihambing ang iniulat na resolver sa kung ano ang ginawa ng hakbang 2, at ihambing ang resulta sa layunin mula sa hakbang 1.
Kung ang layunin ay ilayo ang mga query sa lokal na network, ang pagsubok na nagpapakita ng iyong karaniwang resolver ay tunay na natuklasan. Kung ang layunin ay hindi pagpapakilala habang nagba-browse, walang setting ng DNS ang makapagbibigay niyon.
Isulat ang linya ng pagtanggap sa wika ng layunin: ginagamit ng mga paghahanap na ito ang na-verify na resolver na ito sa ilalim ng mga kundisyong ito. Anumang mas malawak ay isang pahayag na hindi mo masusubukan.