DNS-ul criptat fără VPN ascunde interogarea, nu adresa ta

Un test de scurgere DNS care îți arată rețeaua de acasă nu este dovada că DNS-ul criptat a eșuat și nici dovada că ceva a funcționat. Testul răspunde la o singură întrebare: cărui resolver i-a ajuns această interogare din această rețea. Dacă asta e o problemă depinde de ce și de cine te protejai.

Notează obiectivul înainte de a rula orice test.

Pasul 1: numește protecția pe care o vrei cu adevărat

Trei obiective se amestecă. Poate vrei ca un observator de pe traseu să nu mai citească interogările. Poate vrei ca un anumit resolver să nu le mai primească. Poate vrei ca site-urile pe care le vizitezi să nu-ți mai vadă adresa de acasă. DNS-ul criptat servește primul obiectiv, schimbă cine îl îndeplinește pe al doilea și nu face absolut nimic pentru al treilea.

Un VPN servește al treilea obiectiv și, în funcție de furnizor, pe primul. Niciunul dintre instrumente nu este o supramulțime a celuilalt.

Pasul 2: alege un resolver și verifică-i identitatea

DNS over TLS învelește interogarea într-o sesiune TLS cu resolverul, iar DNS over HTTPS o învelește într-o cerere HTTP; RFC 7858 și RFC 8484 le descriu pe amândouă, iar niciunul nu are nevoie de un tunel. Operațional contează ca certificatul să fie verificat față de numele pe care l-ai configurat, pentru că o sesiune criptată cu partea greșită este mai rea decât text simplu cu partea corectă. Asta înseamnă mod strict acolo unde platforma îl oferă, nu un mod oportunist care dă înapoi când verificarea eșuează. Verifică sesiunea direct înainte de a te încrede în setare: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Strângerea de mână ar trebui să numească resolverul pe care l-ai configurat și să returneze un lanț pe care îl poți verifica.

Pasul 3: decide comportamentul la eșec

Fiecare implementare are o politică pentru un resolver criptat inaccesibil, iar acea politică este decizia de confidențialitate. Modul strict face căutarea să eșueze, ceea ce este vizibil și enervant. Modul oportunist reîncearcă în text simplu, ceea ce este invizibil și anulează scopul exact în ziua în care contează. Alege deliberat, apoi notează alegerea lângă cerință.

În systemd-resolved asta înseamnă DNSOverTLS=yes în loc de opportunistic; în Android înseamnă modul nume de gazdă Private DNS în loc de automat.

Verifică ce este cu adevărat în vigoare cu resolvectl status | grep -i -A1 "dns over tls", pentru că un fișier drop-in care nu a fost reîncărcat niciodată nu schimbă nimic.

Pasul 4: verifică dacă aplicațiile urmează resolverul sistemului

Un browser cu propria setare de DNS sigur ocolește complet configurația sistemului, la fel și un runtime de containere cu un resolver încorporat sau un runtime de limbaj care citește o listă codificată rigid. Ori fă-le să urmeze sistemul, ori configurează-le explicit și notează asta. Apoi uită-te la comportamentul de repliere al fiecăruia, pentru că nu toate eșuează închis. Inventarul în practică este scurt: browser, runtime de containere și orice client VPN pe care îl rulezi și tu.

Numele private ale organizației rămân pe resolverul intern aprobat. Trimiterea lor către un serviciu public ca să arate testul îngrijit creează intenționat altă problemă.

Pasul 5: citește testul de scurgere față de cerință

Un test care raportează un resolver neașteptat este un indiciu, nu o sentință. S-ar putea să fi observat resolverul criptat intenționat, o setare specifică aplicației sau o repliere în text simplu despre care nu știai. Compară resolverul raportat cu cel configurat la pasul 2 și compară rezultatul cu obiectivul de la pasul 1.

Dacă obiectivul era să ții interogările departe de rețeaua locală, un test care îți arată resolverul obișnuit este o descoperire reală. Dacă obiectivul era anonimatul în timpul navigării, nicio setare DNS nu l-ar fi oferit vreodată.

Scrie linia de acceptare în limba obiectivului: aceste căutări folosesc acest resolver verificat în aceste condiții. Orice mai larg este o afirmație pe care nu o poți testa.