Šifrēts DNS bez VPN slēpj vaicājumu, nevis jūsu adresi

DNS noplūdes tests, kas parāda jūsu mājas tīklu, nav pierādījums, ka šifrētais DNS neizdevās, un tas nav arī pierādījums, ka kaut kas strādāja. Tests atbild uz vienu jautājumu: kuru risinātāju šis vaicājums sasniedza no šī tīkla. Vai tā ir problēma, ir atkarīgs no tā, ko un no kā jūs aizsargājāt.

Pierakstiet mērķi pirms jebkura testa palaišanas.

1. solis: nosauciet aizsardzību, kuru patiešām vēlaties

Trīs mērķi sajaucas. Varbūt vēlaties, lai novērotājs ceļā pārstātu lasīt vaicājumus. Varbūt vēlaties, lai konkrēts risinātājs pārstātu tos saņemt. Varbūt vēlaties, lai vietnes, kuras apmeklējat, pārstātu redzēt jūsu mājas adresi. Šifrēts DNS kalpo pirmajam, maina, kas piepilda otro, un trešajam nedara pilnīgi neko.

VPN kalpo trešajam un, atkarībā no pakalpojumu sniedzēja, pirmajam. Neviens instruments nav otra virskopa.

2. solis: izvēlieties risinātāju un pārbaudiet tā identitāti

DNS over TLS iesaiņo vaicājumu TLS sesijā ar risinātāju, un DNS over HTTPS iesaiņo to HTTP pieprasījumā; RFC 7858 un RFC 8484 apraksta abus, un nevienam nav vajadzīgs tunelis. Operatīvi svarīgi ir tas, ka sertifikāts tiek pārbaudīts pret jūsu konfigurēto nosaukumu, jo šifrēta sesija ar nepareizo pusi ir sliktāka par atklātu tekstu ar pareizo. Tas nozīmē stingru režīmu tur, kur platforma to piedāvā, nevis oportūnistisku režīmu, kas atkāpjas, kad pārbaude neizdodas. Pārbaudiet sesiju tieši pirms uzticaties iestatījumam: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Rokasspiedienam jānosauc jūsu konfigurētais risinātājs un jāatgriež ķēde, kuru varat pārbaudīt.

3. solis: izlemiet uzvedību neizdošanās gadījumā

Katrai ieviešanai ir politika nepieejamam šifrētam risinātājam, un šī politika ir privātuma lēmums. Stingrs režīms liek meklēšanai neizdoties, kas ir redzami un kaitinoši. Oportūnistiskais režīms mēģina vēlreiz atklātā tekstā, kas nav redzami un iznīcina mērķi tieši tajā dienā, kad tas ir svarīgi. Izvēlieties apzināti un pēc tam pierakstiet izvēli pie prasības.

Sistēmā systemd-resolved tas nozīmē DNSOverTLS=yes nevis opportunistic; savukārt Android tas nozīmē Private DNS resursdatora nosaukuma režīmu, nevis automātisku.

Pārbaudiet, kas patiešām ir spēkā, ar resolvectl status | grep -i -A1 "dns over tls", jo drop-in fails, kas nekad nav ticis pārlādēts, neko nemaina.

4. solis: pārbaudiet, vai lietotnes ievēro sistēmas risinātāju

Pārlūks ar savu drošā DNS iestatījumu pilnībā apiet sistēmas konfigurāciju, un tāpat dara konteineru runtime ar iebūvētu risinātāju vai valodas runtime, kas lasa cieti kodētu sarakstu. Vai nu lieciet tiem ievērot sistēmu, vai konfigurējiet tos skaidri un pierakstiet to. Pēc tam aplūkojiet katra atkāpšanās uzvedību, jo ne visi no tiem neizdodas slēgti. Saraksts praksē ir īss: pārlūks, konteineru runtime un jebkurš VPN klients, ko arī darbināt.

Organizācijas privātie nosaukumi paliek apstiprinātajā iekšējā risinātājā. To sūtīšana uz publisku pakalpojumu, lai tests izskatītos kārtīgi, apzināti rada citu problēmu.

5. solis: lasiet noplūdes testu pret prasību

Tests, kas ziņo par negaidītu risinātāju, ir mājiens, nevis spriedums. Iespējams, tas novēroja jūsu paredzēto šifrēto risinātāju, lietotnei raksturīgu iestatījumu vai atklāta teksta atkāpšanos, par kuru nezinājāt. Salīdziniet ziņoto risinātāju ar to, ko konfigurēja 2. solis, un salīdziniet rezultātu ar 1. soļa mērķi.

Ja mērķis bija turēt vaicājumus prom no vietējā tīkla, tests, kas parāda jūsu parasto risinātāju, ir īsts atradums. Ja mērķis bija anonimitāte pārlūkošanas laikā, neviens DNS iestatījums to nekad nebūtu nodrošinājis.

Pierakstiet pieņemšanas rindu mērķa valodā: šie meklējumi izmanto šo pārbaudīto risinātāju šajos apstākļos. Viss plašākais ir apgalvojums, ko nevarat pārbaudīt.