Krüpteeritud DNS ilma VPN-ita peidab päringu, mitte sinu aadressi

DNS-i lekketest, mis näitab sinu koduvõrku, ei ole tõestus, et krüpteeritud DNS ebaõnnestus, ega ka tõestus, et midagi töötas. Test vastab ühele küsimusele: millise resolverini see päring sellest võrgust jõudis. Kas see on probleem, sõltub sellest, mida ja kelle eest sa kaitsesid.

Kirjuta eesmärk üles enne mis tahes testi käivitamist.

Samm 1: nimeta kaitse, mida sa tegelikult tahad

Kolm eesmärki segunevad. Võib-olla tahad, et tee peal olev vaatleja lõpetaks päringute lugemise. Võib-olla tahad, et teatud resolver lõpetaks nende vastuvõtmise. Võib-olla tahad, et saidid, mida külastad, lõpetaksid sinu koduadressi nägemise. Krüpteeritud DNS teenib esimest, muudab seda, kes rahuldab teise, ja ei tee kolmanda jaoks üldse midagi.

VPN teenib kolmandat ja olenevalt teenusepakkujast ka esimest. Kumbki tööriist ei ole teise ülemhulk.

Samm 2: vali resolver ja kontrolli selle identiteeti

DNS over TLS mässib päringu resolveriga TLS-seanssi ja DNS over HTTPS mässib selle HTTP-päringusse; RFC 7858 ja RFC 8484 kirjeldavad mõlemat ning kumbki ei vaja tunnelit. Operatiivselt on oluline, et sertifikaati kontrollitaks sinu seadistatud nime vastu, sest valele osapoolele krüpteeritud seanss on hullem kui õigele osapoolele tavatekst. See tähendab ranget režiimi seal, kus platvorm seda pakub, mitte oportunistlikku režiimi, mis kontrolli ebaõnnestudes taganeb. Kontrolli seanssi otse enne, kui seadele usaldad: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Kätlus peaks nimetama sinu seadistatud resolveri ja tagastama ahela, mida saad kontrollida.

Samm 3: otsusta ebaõnnestumise käitumine

Igal teostusel on poliitika kättesaamatu krüpteeritud resolveri jaoks ja see poliitika on privaatsusotsus. Range režiim laseb otsingul ebaõnnestuda, mis on nähtav ja tüütu. Oportunistlik režiim proovib uuesti tavatekstina, mis on nähtamatu ja nurjab eesmärgi täpselt sel päeval, mil see loeb. Vali teadlikult ja kirjuta valik seejärel nõude kõrvale.

systemd-resolvedis tähendab see DNSOverTLS=yes mitte opportunistic; Androidis tähendab see Private DNS-i hostinime režiimi automaatse asemel.

Kontrolli, mis tegelikult kehtib, käsuga resolvectl status | grep -i -A1 "dns over tls", sest drop-in-fail, mida kunagi uuesti ei laaditud, ei muuda midagi.

Samm 4: kontrolli, kas rakendused järgivad süsteemi resolverit

Brauser, millel on oma turvalise DNS-i seade, möödub süsteemi seadistusest täielikult, ja sama teeb konteineri runtime, millel on sisseehitatud resolver, või keele runtime, mis loeb kõvasti kodeeritud loendit. Kas pane need süsteemi järgima või seadista need selgesõnaliselt ja kirjuta see üles. Seejärel vaata igauhe taganemiskäitumist, sest kõik ei ebaõnnestu suletult. Loend on praktikas lühike: brauser, konteineri runtime ja mis tahes VPN-klient, mida sa samuti käitad.

Organisatsiooni privaatsed nimed jäävad heakskiidetud sisemisele resolverile. Nende saatmine avalikku teenusesse, et test näeks korrektne välja, loob meelega teise probleemi.

Samm 5: loe lekketesti nõude vastu

Test, mis teatab ootamatust resolverist, on vihje, mitte otsus. Võib-olla nägi see sinu kavatsetud krüpteeritud resolverit, rakenduspõhist seadet või tavateksti taganemist, millest sa ei teadnud. Võrdle teatatud resolverit sellega, mille seadistas samm 2, ja võrdle tulemust sammu 1 eesmärgiga.

Kui eesmärk oli hoida päringud kohalikust võrgust eemal, siis test, mis näitab sinu tavalist resolverit, on tõeline leid. Kui eesmärk oli anonüümsus sirvimise ajal, ei oleks ükski DNS-i seade seda kunagi andnud.

Kirjuta vastuvõtutingimus eesmärgi keeles: need otsingud kasutavad seda kontrollitud resolverit nendel tingimustel. Kõik laiem on väide, mida sa ei saa testida.