DNS prek TLS skupaj z VPN: kateri del je zaščiten

DNS prek TLS šifrira izmenjavo med odjemalcem in resolverjem, ki ga je izbral, resolver pa še vedno bere ime. Ta stavek razreši večino zmede okoli DoT skupaj z VPN. Tunel odloči, po kateri poti gre šifrirana poizvedba, medtem ko resolver še vedno izve, kaj je bilo vprašano. Noben mehanizem ne nadomesti drugega in noben ne naredi drugega odvečnega.

Štiri preverjanja odločijo, ali je postavitev, ki jo imate, tista, za katero mislite, da jo imate.

Preverjanje 1: kaj pokriva šifriranje

DoT zavije izmenjavo DNS v TLS, zato opazovalec na poti vidi povezavo z naslovom in vrati, ne imena v poizvedbi. Resolver sam dešifrira in odgovori. Primerjajte z DNS prek HTTPS: oba šifrirata in uporabljata različne prenose, zato omrežje, ki dovoljuje spletni promet, ne dovoli samodejno povezave DoT.

Ta razlika je pomembna, ko ujetniški portal ali filtrirajoča vmesna škatla dovoli 443 in blokira 853. Orodje, ki je tam delovalo, ni dokaz, da bo drugo.

Preverjanje 2: po kateri poti gre poizvedba

Pot je vprašanje odjemalske politike. Do resolverja DoT je mogoče priti skozi tunel, zunaj njega ali po poti, ki se spreminja z omrežjem. Katera se zgodi, je odvisno od poti in od tega, ali odjemalec ščiti svojo lastno vtičnico DNS. Tunel, ki ujame ves promet, običajno poizvedbo vzame s seboj, karkoli pravi naslov resolverja.

Videti naslov resolverja tretje strani v preizkusu ne dokazuje obhoda, videti šifriranje pa ne dokazuje želenega prejemnika. Berite resolver in pot ločeno, nato odločite, ali je par tisti, ki ste ga zasnovali.

Preverjanje 3: notranja imena

Organizacija, ki objavlja notranja imena, potrebuje resolver, ki hrani te zapise. Javna storitev DoT ne pozna vašega zasebnega imenskega prostora, usmeritev odjemalca nanjo pa zagotavlja, da ta imena ne bodo delovala. To je najpogostejša praktična regresija, ko nekdo vklopi šifriran DNS na upravljani napravi.

Ohranite notranji resolver za notranje pripone in ta skok šifrirajte, če politika to zahteva, namesto da bi ga nadomestili z javnim ponudnikom.

Preverjanje 4: vedenje ob napaki

Stroga nastavitev resolverja brez dosegljivega resolverja povzroči napako pri razreševanju imen, medtem ko tunel ostane pokonci. Poglejte način platforme in njeno dokumentirano rezervno pot, namesto da bi se dotikali ključev ali potrdil.

Rezervna pot, ki tiho uporablja običajni DNS, je odločitev politike, ne udobje. Odločite, ali naj bo napaka vidna ali naj se poslabša na nekaj šibkejšega, in odgovor zapišite.

Zaupajte potrdilu, ne odgovoru

Uporabite ime gostitelja ponudnika in konfiguracijo preverjanja, dokumentirano za storitev. Izklop preverjanj TLS, da bi neznan resolver odgovoril, vam da šifriran kanal do nepreverjene končne točke, kar je v enem konkretnem pogledu slabše od nadomeščene običajne poizvedbe: videti je varno. Specifikacija DNS prek TLS razlaga pričakovanje preverjanja za tem preverjanjem.

Odgovor resolverja, ki ga ne morete preveriti, je trditev, ne rezultat.

Kaj to pušča nerazloženo

DoT ne skriva imena pred resolverjem, ne skriva ciljnega naslova povezave pred omrežjem in ne odloča, ali je poizvedba šla skozi tunel. To so tri ločena vprašanja s tremi ločenimi odgovori.

Zapišite identiteto resolverja, tranzitno pot in politiko notranjih imen kot tri vrstice. Naslednje vprašanje o DNS, ki ga dobite, bo eno od njih.