Šifrované DNS bez VPN skrýva dopyt, nie vašu adresu

Test úniku DNS, ktorý ukazuje vašu domácu sieť, nie je dôkazom, že šifrované DNS zlyhalo, a nie je ani dôkazom, že niečo fungovalo. Test odpovedá na jednu otázku: ktorý resolver dostal tento dopyt z tejto siete. Či je to problém, závisí od toho, pred čím a pred kým ste sa chránili.

Pred spustením akéhokoľvek testu si zapíšte cieľ.

Krok 1: pomenujte ochranu, ktorú skutočne chcete

Tri ciele sa miešajú. Možno chcete, aby pozorovateľ na ceste prestal čítať dopyty. Možno chcete, aby určitý resolver prestal dopyty dostávať. Možno chcete, aby webové stránky, ktoré navštevujete, prestali vidieť vašu domácu adresu. Šifrované DNS slúži prvému, mení, kto naplní druhý, a pre tretí nerobí vôbec nič.

VPN slúži tretiemu a v závislosti od poskytovateľa aj prvému. Ani jeden nástroj nie je nadmnožinou toho druhého.

Krok 2: vyberte resolver a overte jeho identitu

DNS over TLS obaľuje dopyt do TLS relácie s resolverom a DNS over HTTPS ho obaľuje do HTTP požiadavky; RFC 7858 a RFC 8484 opisujú oba a ani jeden nepotrebuje tunel. Prevádzkovo je dôležité, aby sa certifikát overoval voči názvu, ktorý ste nastavili, pretože šifrovaná relácia s nesprávnou stranou je horšia než otvorený text so správnou. To znamená striktný režim tam, kde ho platforma ponúka, nie oportunistický režim, ktorý ustúpi pri zlyhaní overenia. Overte reláciu priamo predtým, než nastaveniu uveríte: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Handshake by mal uviesť resolver, ktorý ste nastavili, a vrátiť reťaz, ktorú môžete overiť.

Krok 3: rozhodnite o správaní pri zlyhaní

Každá implementácia má politiku pre nedostupný šifrovaný resolver a táto politika je rozhodnutím o súkromí. Striktný režim nechá vyhľadávanie zlyhať, čo je viditeľné a otravné. Oportunistický režim to skúsi znova otvoreným textom, čo je neviditeľné a marí účel práve v deň, keď na ňom záleží. Vyberte vedome a potom voľbu zapíšte vedľa požiadavky.

Na systemd-resolved to znamená DNSOverTLS=yes namiesto opportunistic; na Androide to znamená režim názvu hostiteľa Private DNS namiesto automatického.

Overte, čo je skutočne v platnosti, pomocou resolvectl status | grep -i -A1 "dns over tls", pretože drop-in súbor, ktorý sa nikdy znova nenačítal, nič nemení.

Krok 4: overte, či aplikácie nasledujú systémový resolver

Prehliadač s vlastným nastavením zabezpečeného DNS úplne obchádza systémovú konfiguráciu, rovnako ako kontajnerový runtime so vstavaným resolverom alebo runtime jazyka, ktorý číta pevne zakódovaný zoznam. Buď ich prinúťte nasledovať systém, alebo ich výslovne nastavte a zapíšte to. Potom sa pozrite na správanie pri zlyhaní u každého z nich, pretože nie všetky zlyhávajú zatvorene. Zoznam je v praxi krátky: prehliadač, kontajnerový runtime a akýkoľvek klient VPN, ktorý tiež prevádzkujete.

Súkromné názvy organizácie zostávajú na schválenom internom resolveri. Posielať ich do verejnej služby, aby test vyzeral upravene, úmyselne vytvára iný problém.

Krok 5: čítajte test úniku voči požiadavke

Test, ktorý hlási neočakávaný resolver, je podnet, nie verdikt. Možno pozoroval vami zamýšľaný šifrovaný resolver, nastavenie špecifické pre aplikáciu alebo ústup na otvorený text, o ktorom ste nevedeli. Porovnajte hlásený resolver s tým, čo nastavil krok 2, a porovnajte výsledok s cieľom z kroku 1.

Ak bolo cieľom držať dopyty mimo miestnej siete, test, ktorý ukazuje váš obvyklý resolver, je skutočné zistenie. Ak bolo cieľom anonymita pri prehliadaní, žiadne nastavenie DNS by to nikdy neposkytlo.

Zapíšte akceptačný riadok v jazyku cieľa: tieto vyhľadávania používajú tento overený resolver za týchto podmienok. Čokoľvek širšie je tvrdenie, ktoré nemôžete otestovať.