DNS pār TLS kopā ar VPN: kura daļa ir aizsargāta

DNS pār TLS šifrē apmaiņu starp klientu un tā izvēlēto resolveri, un resolvers joprojām nolasa nosaukumu. Šis teikums atrisina lielāko daļu neskaidrības ap DoT kopā ar VPN. Tunelis nosaka, pa kuru ceļu iet šifrētais vaicājums, bet resolvers joprojām uzzina, kas tika jautāts. Neviens mehānisms neaizstāj otru, un neviens nepadara otru lieku.

Četras pārbaudes izšķir, vai jūsu rīcībā esošā kārtība ir tā, kā jūs domājat, ka tā ir.

1. pārbaude: ko aptver šifrēšana

DoT ietin DNS apmaiņu TLS, tāpēc novērotājs uz ceļa redz savienojumu ar adresi un portu, nevis nosaukumu vaicājumā. Pats resolvers atšifrē un atbild. Salīdziniet ar DNS pār HTTPS: abi šifrē, un tie izmanto dažādus transportus, tāpēc tīkls, kas atļauj tīmekļa trafiku, automātiski neatļauj DoT savienojumu.

Šī atšķirība ir svarīga, kad uztveršanas portāls vai filtrējoša starpierīce atļauj 443 un bloķē 853. Instruments, kas tur strādāja, nav pierādījums, ka strādās otrs.

2. pārbaude: pa kuru maršrutu iet vaicājums

Maršruts ir klienta politikas jautājums. DoT resolveri var sasniegt pa tuneli, ārpus tā vai pa ceļu, kas mainās līdz ar tīklu. Kurš gadījums notiks, atkarīgs no maršrutiem un no tā, vai klients aizsargā savu DNS ligzdu. Tunelis, kas pārtver visu trafiku, parasti paņem līdzi arī vaicājumu, lai ko teiktu resolvera adrese.

Trešās puses resolvera adreses redzēšana testā nepierāda apiešanu, un šifrēšanas redzēšana nepierāda paredzēto saņēmēju. Lasiet resolveri un ceļu atsevišķi, tad izlemiet, vai pāris ir tas, ko projektējāt.

3. pārbaude: iekšējie nosaukumi

Organizācijai, kas publicē iekšējos nosaukumus, vajag resolveri, kas glabā šos ierakstus. Publisks DoT pakalpojums nezina jūsu privāto nosaukumu telpu, un klienta novirzīšana uz to garantē, ka šie nosaukumi neizdosies. Tā ir visbiežākā praktiskā regresija, kad kāds ieslēdz šifrētu DNS pārvaldītā ierīcē.

Saglabājiet iekšējo resolveri iekšējiem sufiksiem un šifrējiet šo lēcienu, ja politika to prasa, tā vietā, lai aizstātu to ar publisku pakalpojumu sniedzēju.

4. pārbaude: uzvedība kļūmes gadījumā

Stingrs resolvera iestatījums bez sasniedzama resolvera rada nosaukumu atrisināšanas kļūmi, kamēr tunelis paliek uzcelts. Skatieties uz platformas režīmu un tā dokumentēto rezerves ceļu, nevis aiztieciet atslēgas vai sertifikātus.

Rezerves ceļš, kas klusi izmanto parasto DNS, ir politikas lēmums, ne ērtība. Izlemiet, vai kļūmei jābūt redzamai vai jānolaižas līdz kaut kam vājākam, un pierakstiet atbildi.

Uzticieties sertifikātam, nevis atbildei

Izmantojiet pakalpojumam dokumentēto pakalpojumu sniedzēja resursdatora nosaukumu un verifikācijas konfigurāciju. TLS pārbaužu izslēgšana, lai nezināms resolvers atbildētu, dod jums šifrētu kanālu uz nepārbaudītu galapunktu, kas vienā konkrētā ziņā ir sliktāk nekā aizstātais vienkāršais vaicājums: tas izskatās droši. DNS pār TLS specifikācija izklāsta autentifikācijas gaidas, kas slēpjas aiz šīs pārbaudes.

Atbilde no resolvera, kuru nevarat autentificēt, ir apgalvojums, nevis rezultāts.

Ko tas atstāj neizskaidrotu

DoT neslēpj nosaukumu no resolvera, neslēpj savienojuma galamērķa adresi no tīkla un neizlemj, vai vaicājums gāja caur tuneli. Tie ir trīs atsevišķi jautājumi ar trim atsevišķām atbildēm.

Pierakstiet resolvera identitāti, tranzīta ceļu un iekšējo nosaukumu politiku kā trīs rindas. Nākamais DNS jautājums, ko saņemsit, būs viens no tiem.