A DNS-szivárgásteszt, amely az otthoni hálózatodat mutatja, nem bizonyítja, hogy a titkosított DNS kudarcot vallott, és azt sem bizonyítja, hogy bármi működött. A teszt egyetlen kérdésre válaszol: melyik feloldóhoz jutott el ez a lekérdezés ebből a hálózatból. Hogy ez probléma-e, attól függ, mit és kitől védtél.

Írd le a célt, mielőtt bármilyen tesztet futtatsz.

1. lépés: nevezd meg a védelmet, amit valóban szeretnél

Három cél keveredik. Lehet, hogy azt szeretnéd, hogy az útvonalon lévő megfigyelő hagyjon fel a lekérdezések olvasásával. Lehet, hogy azt szeretnéd, hogy egy adott feloldó hagyjon fel a fogadásukkal. Lehet, hogy azt szeretnéd, hogy a meglátogatott webhelyek hagyjanak fel az otthoni címed látásával. A titkosított DNS az elsőt szolgálja, megváltoztatja, ki elégíti ki a másodikat, a harmadikért pedig semmit sem tesz.

A VPN a harmadikat szolgálja, és a szolgáltatótól függően az elsőt. Egyik eszköz sem halmaza a másiknak.

2. lépés: válassz feloldót, és ellenőrizd az identitását

A DNS over TLS TLS-munkamenetbe csomagolja a lekérdezést a feloldóval, a DNS over HTTPS pedig HTTP-kérésbe; az RFC 7858 és az RFC 8484 mindkettőt leírja, és egyik sem igényel alagutat. Üzemeltetésileg az számít, hogy a tanúsítvány a beállított névhez legyen ellenőrizve, mert a rossz féllel folytatott titkosított munkamenet rosszabb, mint a jó féllel folytatott nyílt szöveg. Ez szigorú módot jelent ott, ahol a platform kínálja, nem pedig opportunista módot, amely visszalép, ha az ellenőrzés meghiúsul. Ellenőrizd a munkamenetet közvetlenül, mielőtt megbízol a beállításban: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

A kézfogásnak meg kell neveznie a beállított feloldót, és olyan láncot kell visszaadnia, amelyet ellenőrizni tudsz.

3. lépés: döntsd el a hiba esetén követett viselkedést

Minden megvalósításnak van szabálya az elérhetetlen titkosított feloldóra, és ez a szabály az adatvédelmi döntés. A szigorú mód meghiúsítja a keresést, ami látható és idegesítő. Az opportunista mód nyílt szövegben próbálkozik újra, ami láthatatlan, és éppen azon a napon hiúsítja meg a célt, amikor számít. Válassz tudatosan, majd jegyezd fel a választást a követelmény mellé.

A systemd-resolved esetén ez azt jelenti, hogy DNSOverTLS=yes nem opportunistic; az Androidon pedig a Private DNS hosztnév-módját jelenti az automatikus helyett.

Ellenőrizd, mi van valóban érvényben ezzel: resolvectl status | grep -i -A1 "dns over tls", mert az a drop-in fájl, amelyet soha nem töltöttek újra, semmit sem változtat.

4. lépés: ellenőrizd, hogy az alkalmazások követik-e a rendszer feloldóját

A saját biztonságos DNS-beállítással rendelkező böngésző teljesen megkerüli a rendszerkonfigurációt, és ugyanezt teszi a beágyazott feloldóval rendelkező konténer-runtime vagy a mereven kódolt listát olvasó nyelvi runtime. Vagy érd el, hogy kövessék a rendszert, vagy állítsd be őket kifejezetten, és jegyezd fel. Utána nézd meg mindegyik visszaesési viselkedését, mert nem mindegyik hibázik zárt módon. A leltár a gyakorlatban rövid: böngésző, konténer-runtime és bármelyik VPN-kliens, amelyet szintén futtatsz.

A szervezet privát nevei a jóváhagyott belső feloldón maradnak. Nyilvános szolgáltatáshoz küldeni őket, hogy a teszt rendezettnek tűnjön, szándékosan más problémát teremt.

5. lépés: olvasd a szivárgástesztet a követelményhez mérve

A váratlan feloldót jelentő teszt nyom, nem ítélet. Lehet, hogy a szándékolt titkosított feloldót, egy alkalmazásspecifikus beállítást vagy egy általad nem ismert nyílt szöveges visszaesést figyelt meg. Hasonlítsd össze a jelentett feloldót azzal, amit a 2. lépés beállított, és hasonlítsd össze az eredményt az 1. lépés céljával.

Ha a cél az volt, hogy a lekérdezések távol maradjanak a helyi hálózattól, akkor a szokásos feloldódat mutató teszt valódi lelet. Ha a cél a böngészés közbeni névtelenség volt, egyetlen DNS-beállítás sem nyújtotta volna soha.

Írd meg az elfogadási sort a cél nyelvén: ezek a keresések ezt az ellenőrzött feloldót használják ilyen feltételek mellett. Minden ennél tágabb olyan állítás, amelyet nem tudsz tesztelni.

Kapcsolódó cikkek