DNS přes TLS a VPN: která část je chráněná

DNS přes TLS šifruje výměnu mezi klientem a resolverem, který si vybral, a resolver přesto jméno čte. Tahle věta vysvětluje většinu zmatku kolem DoT a VPN. Tunel rozhoduje, kterou cestou šifrovaný dotaz půjde, zatímco resolver se stále dozvídá, na co se ptalo. Ani jeden mechanismus nenahrazuje druhý a ani jeden nedělá druhý nadbytečným.

Čtyři kontroly rozhodnou, zda uspořádání, které máte, je to, které si myslíte, že máte.

Kontrola 1: co šifrování pokrývá

DoT zabaluje výměnu DNS do TLS, takže pozorovatel na cestě vidí spojení na adresu a port, ne jméno v dotazu. Resolver sám dešifruje a odpovídá. Srovnejte s DNS přes HTTPS: oba šifrují a používají jiné transporty, takže síť, která povoluje webový provoz, automaticky nepovoluje spojení DoT.

Ten rozdíl je důležitý, když captive portal nebo filtrující mezibox povolí 443 a zablokuje 853. Nástroj, který tam fungoval, není důkazem, že bude fungovat ten druhý.

Kontrola 2: kterou trasou dotaz jde

Trasa je otázka klientské politiky. K DoT resolveru se lze dostat tunelem, mimo něj nebo cestou, která se mění se sítí. Která možnost nastane, závisí na trasách a na tom, zda klient chrání svůj vlastní DNS socket. Tunel, který zachytí veškerý provoz, obvykle vezme dotaz s sebou, ať adresa resolveru říká cokoli.

Vidět v testu adresu resolveru třetí strany nedokazuje obcházení a vidět šifrování nedokazuje zamýšleného příjemce. Čtěte resolver a cestu odděleně, pak rozhodněte, zda je dvojice ta, kterou jste navrhli.

Kontrola 3: interní názvy

Organizace, která zveřejňuje interní názvy, potřebuje resolver, který tyto záznamy drží. Veřejná služba DoT nezná váš soukromý jmenný prostor a nasměrování klienta na ni zaručí, že tyto názvy selžou. To je nejčastější praktická regrese, když někdo na spravovaném zařízení zapne šifrované DNS.

Ponechte interní resolver pro interní přípony a ten skok šifrujte, pokud to politika vyžaduje, místo abyste ho nahrazovali veřejným poskytovatelem.

Kontrola 4: chování při selhání

Přísné nastavení resolveru bez dostupného resolveru vyvolá selhání překladu názvů, zatímco tunel zůstává nahoře. Dívejte se na režim platformy a její dokumentovanou záložní cestu, místo abyste sahali na klíče nebo certifikáty.

Záložní cesta, která tiše používá obyčejné DNS, je rozhodnutí politiky, ne pohodlí. Rozhodněte, zda má být selhání viditelné, nebo se má degradovat na něco slabšího, a odpověď zapište.

Věřte certifikátu, ne odpovědi

Použijte název hostitele poskytovatele a konfiguraci ověřování dokumentovanou pro službu. Vypnutí kontrol TLS, aby neznámý resolver odpověděl, vám dá šifrovaný kanál k neověřenému koncovému bodu, což je v jednom konkrétním ohledu horší než obyčejný dotaz, který nahradil: vypadá bezpečně. Specifikace DNS přes TLS vykládá očekávání ověřování, které za tou kontrolou stojí.

Odpověď od resolveru, který nedokážete ověřit, je tvrzení, ne výsledek.

Co to nechává nevysvětlené

DoT neskrývá jméno před resolverem, neskrývá adresu cíle spojení před sítí a nerozhoduje, zda dotaz šel tunelem. To jsou tři oddělené otázky se třemi oddělenými odpověďmi.

Zapište identitu resolveru, tranzitní trasu a politiku interních názvů jako tři řádky. Příští dotaz na DNS, který dostanete, bude jeden z nich.