Šifrirani DNS bez VPN-a skriva upit, a ne vašu adresu

DNS test curenja koji pokazuje vašu kućnu mrežu nije dokaz da je šifrirani DNS zakazao, a nije ni dokaz da je nešto uspjelo. Test odgovara na jedno pitanje: koji je resolver primio ovaj upit s ove mreže. Da li je to problem zavisi od toga šta ste štitili i od koga.

Zapišite cilj prije pokretanja bilo kakvog testa.

Korak 1: imenujte zaštitu koju zaista želite

Tri cilja se miješaju. Možda želite da posmatrač na putu prestane čitati upite. Možda želite da određeni resolver prestane da ih prima. Možda želite da web-stranice koje posjećujete prestanu vidjeti vašu kućnu adresu. Šifrirani DNS služi prvom, mijenja ko ispunjava drugi, a za treći ne čini baš ništa.

VPN služi trećem i, zavisno od provajdera, prvom. Nijedan alat nije nadskup onog drugog.

Korak 2: odaberite resolver i provjerite njegov identitet

DNS over TLS umotava upit u TLS sesiju s resolverom, a DNS over HTTPS ga umotava u HTTP zahtjev; RFC 7858 i RFC 8484 opisuju oba i nijedan ne treba tunel. Operativno je važno da se certifikat provjerava prema imenu koje ste konfigurisali, jer je šifrirana sesija s pogrešnom stranom gora od običnog teksta s pravom. To znači strogi režim tamo gdje ga platforma nudi, a ne oportunistički režim koji se povlači kada provjera ne uspije. Provjerite sesiju direktno prije nego što povjerujete postavci: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Rukovanje treba imenovati resolver koji ste konfigurisali i vratiti lanac koji možete provjeriti.

Korak 3: odlučite ponašanje pri neuspjehu

Svaka implementacija ima politiku za nedostupni šifrirani resolver, i ta politika jest odluka o privatnosti. Strogi režim obara pretragu, što je vidljivo i iritantno. Oportunistički režim ponovo pokušava običnim tekstom, što je nevidljivo i poništava svrhu baš onog dana kada je važna. Odaberite namjerno, pa zapišite izbor uz zahtjev.

Na systemd-resolved to znači DNSOverTLS=yes umjesto opportunistic; a na Androidu znači režim imena hosta Private DNS umjesto automatskog.

Provjerite šta je stvarno na snazi pomoću resolvectl status | grep -i -A1 "dns over tls", jer drop-in datoteka koja nikad nije ponovo učitana ne mijenja ništa.

Korak 4: provjerite prate li aplikacije sistemski resolver

Preglednik s vlastitom postavkom sigurnog DNS-a potpuno zaobilazi sistemsku konfiguraciju, kao i kontejnerski runtime s ugrađenim resolverom ili runtime jezika koji čita tvrdo kodirani spisak. Ili ih natjerajte da prate sistem, ili ih eksplicitno konfigurirajte i to zapišite. Zatim pogledajte ponašanje pri povlačenju kod svakog od njih, jer ne zakazuju svi zatvoreno. Inventar je u praksi kratak: preglednik, kontejnerski runtime i bilo koji VPN klijent koji također pokrećete.

Privatna imena organizacije ostaju na odobrenom internom resolveru. Slanje istih javnoj usluzi da bi test izgledao uredno namjerno stvara drugi problem.

Korak 5: čitajte test curenja prema zahtjevu

Test koji prijavi neočekivani resolver je nagovještaj, a ne presuda. Možda je primijetio vaš željeni šifrirani resolver, postavku specifičnu za aplikaciju ili povlačenje na običan tekst za koje niste znali. Uporedite prijavljeni resolver s onim što je konfigurisao korak 2 i uporedite rezultat s ciljem iz koraka 1.

Ako je cilj bio držati upite dalje od lokalne mreže, test koji pokazuje vaš uobičajeni resolver je stvarni nalaz. Ako je cilj bila anonimnost tokom pregledanja, nijedna DNS postavka to nikad ne bi pružila.

Zapišite liniju prihvatanja na jeziku cilja: ove pretrage koriste ovaj provjereni resolver pod ovim uslovima. Sve šire je tvrdnja koju ne možete testirati.