DNS cez TLS plus VPN: ktorá časť je chránená

DNS cez TLS šifruje výmenu medzi klientom a resolverom, ktorý si vybral, a resolver napriek tomu meno číta. Táto veta vysvetľuje väčšinu zmätku okolo DoT a VPN. Tunel rozhoduje, ktorou cestou šifrovaná požiadavka pôjde, zatiaľ čo resolver sa stále dozvedá, na čo sa pýtalo. Ani jeden mechanizmus nenahrádza druhý a ani jeden nerobí druhý nadbytočným.

Štyri kontroly rozhodnú, či usporiadanie, ktoré máte, je to, ktoré si myslíte, že máte.

Kontrola 1: čo šifrovanie pokrýva

DoT zabalí výmenu DNS do TLS, takže pozorovateľ na ceste vidí spojenie na adresu a port, nie meno v požiadavke. Resolver sám dešifruje a odpovedá. Porovnajte s DNS cez HTTPS: oba šifrujú a používajú iné transporty, takže sieť, ktorá povoľuje webovú prevádzku, automaticky nepovoľuje spojenie DoT.

Ten rozdiel je dôležitý, keď captive portál alebo filtrujúci medzikus povolí 443 a zablokuje 853. Nástroj, ktorý tam fungoval, nie je dôkazom, že bude fungovať ten druhý.

Kontrola 2: ktorou trasou požiadavka ide

Trasa je otázka klientskej politiky. K DoT resolveru sa dá dostať tunelom, mimo neho alebo cestou, ktorá sa mení so sieťou. Ktorá možnosť nastane, závisí od trás a od toho, či klient chráni svoj vlastný DNS socket. Tunel, ktorý zachytí všetku prevádzku, zvyčajne vezme požiadavku so sebou, čokoľvek hovorí adresa resolvera.

Vidieť v testovaní adresu resolvera tretej strany nedokazuje obchádzanie a vidieť šifrovanie nedokazuje zamýšľaného príjemcu. Čítajte resolver a cestu oddelene, potom rozhodnite, či je dvojica tá, ktorú ste navrhli.

Kontrola 3: interné názvy

Organizácia, ktorá zverejňuje interné názvy, potrebuje resolver, ktorý tieto záznamy drží. Verejná služba DoT nepozná váš súkromný menný priestor a nasmerovanie klienta na ňu zaručí, že tie názvy zlyhajú. Toto je najčastejšia praktická regresia, keď niekto na spravovanom zariadení zapne šifrované DNS.

Ponechajte interný resolver pre interné prípony a ten skok šifrujte, ak to politika vyžaduje, namiesto toho, aby ste ho nahrádzali verejným poskytovateľom.

Kontrola 4: správanie pri zlyhaní

Prísne nastavenie resolvera bez dostupného resolvera vyvolá zlyhanie prekladu názvov, zatiaľ čo tunel zostáva hore. Pozerajte sa na režim platformy a jej dokumentovanú záložnú cestu, namiesto toho, aby ste sa dotýkali kľúčov alebo certifikátov.

Záložná cesta, ktorá ticho používa obyčajné DNS, je rozhodnutie politiky, nie pohodlie. Rozhodnite, či má byť zlyhanie viditeľné alebo sa má degradovať na niečo slabšie, a odpoveď zapíšte.

Verte certifikátu, nie odpovedi

Použite názov hostiteľa poskytovateľa a konfiguráciu overovania dokumentovanú pre službu. Vypnutie kontrol TLS, aby odpovedal neznámy resolver, vám dá šifrovaný kanál k neoverenému koncovému bodu, čo je v jednom konkrétnom ohľade horšie ako obyčajná požiadavka, ktorú nahradil: vyzerá bezpečne. Špecifikácia DNS cez TLS vykladá očakávanie overenia, ktoré za tou kontrolou stojí.

Odpoveď od resolvera, ktorý nedokážete overiť, je tvrdenie, nie výsledok.

Čo to necháva nevysvetlené

DoT neskrýva meno pred resolverom, neskrýva adresu cieľa spojenia pred sieťou a nerozhoduje, či požiadavka išla tunelom. To sú tri oddelené otázky s tromi oddelenými odpoveďami.

Zapíšte identitu resolvera, tranzitnú trasu a politiku interných názvov ako tri riadky. Najbližšia otázka na DNS, ktorú dostanete, bude jedna z nich.