Šifrované DNS bez VPN skrývá dotaz, ne vaši adresu

Test úniku DNS, který ukazuje vaši domácí síť, není důkazem, že šifrované DNS selhalo, a není ani důkazem, že něco fungovalo. Test odpovídá na jednu otázku: který resolver tento dotaz z této sítě dostal. Jestli je to problém, závisí na tom, před čím a před kým jste se chránili.

Než spustíte jakýkoli test, zapište si cíl.

Krok 1: pojmenujte ochranu, kterou skutečně chcete

Tři cíle se míchají dohromady. Možná chcete, aby pozorovatel na cestě přestal číst dotazy. Možná chcete, aby určitý resolver přestal dotazy dostávat. Možná chcete, aby weby, které navštěvujete, přestaly vidět vaši domácí adresu. Šifrované DNS slouží prvnímu, mění, kdo naplní druhý, a pro třetí nedělá vůbec nic.

VPN slouží třetímu a v závislosti na poskytovateli i prvnímu. Ani jeden nástroj není nadmnožinou toho druhého.

Krok 2: vyberte resolver a ověřte jeho identitu

DNS over TLS obaluje dotaz do TLS relace s resolverem a DNS over HTTPS ho obaluje do HTTP požadavku; RFC 7858 a RFC 8484 popisují oba a ani jeden nepotřebuje tunel. Provozně je důležité, aby se certifikát ověřoval proti názvu, který jste nastavili, protože šifrovaná relace s nesprávnou stranou je horší než prostý text se správnou. To znamená striktní režim tam, kde ho platforma nabízí, ne oportunistický režim, který při neúspěšném ověření ustoupí. Ověřte relaci přímo, než nastavení uvěříte: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Handshake by měl uvést resolver, který jste nastavili, a vrátit řetěz, který můžete ověřit.

Krok 3: rozhodněte o chování při selhání

Každá implementace má politiku pro nedostupný šifrovaný resolver a tato politika je rozhodnutím o soukromí. Striktní režim nechá vyhledávání selhat, což je viditelné a otravné. Oportunistický režim to zkouší znovu prostým textem, což je neviditelné a maří účel právě v den, kdy na něm záleží. Vyberte vědomě a volbu pak zapište vedle požadavku.

Na systemd-resolved to znamená DNSOverTLS=yes namísto opportunistic; na Androidu to znamená režim názvu hostitele Private DNS namísto automatického.

Ověřte, co je skutečně v platnosti, pomocí resolvectl status | grep -i -A1 "dns over tls", protože drop-in soubor, který nebyl nikdy znovu načten, nic nemění.

Krok 4: ověřte, že aplikace následují systémový resolver

Prohlížeč s vlastním nastavením zabezpečeného DNS zcela obchází systémovou konfiguraci, a stejně tak kontejnerový runtime s vestavěným resolverem nebo runtime jazyka, který čte pevně zapsaný seznam. Buď je donuťte následovat systém, nebo je výslovně nastavte a zapište to. Pak se podívejte na chování při selhání u každého z nich, protože ne všechny selhávají zavřeně. Inventář je v praxi krátký: prohlížeč, kontejnerový runtime a jakýkoli klient VPN, který také provozujete.

Soukromé názvy organizace zůstávají na schváleném interním resolveru. Posílat je do veřejné služby, aby test vypadal uklizeně, úmyslně vytváří jiný problém.

Krok 5: čtěte test úniku proti požadavku

Test, který hlásí neočekávaný resolver, je podnět, ne verdikt. Možná pozoroval vámi zamýšlený šifrovaný resolver, nastavení specifické pro aplikaci nebo ústup na prostý text, o kterém jste nevěděli. Porovnejte hlášený resolver s tím, co nastavil krok 2, a porovnejte výsledek s cílem z kroku 1.

Pokud bylo cílem držet dotazy mimo místní síť, test, který ukazuje váš obvyklý resolver, je skutečné zjištění. Pokud bylo cílem anonymita při prohlížení, žádné nastavení DNS by to nikdy nedalo.

Zapište akceptační řádek v jazyce cíle: tato vyhledávání používají tento ověřený resolver za těchto podmínek. Cokoli širšího je tvrzení, které nemůžete otestovat.