DNS super TLS plus VPN: kiu parto estas protektata

DNS super TLS ĉifras la interŝanĝon inter kliento kaj la solvilo, kiun ĝi elektis, kaj la solvilo ankoraŭ legas la nomon. Tiu frazo solvas la plejparton de la konfuzo pri DoT plus VPN. La tunelo decidas, kiun vojon la ĉifrita demando iras, dum la solvilo ankoraŭ ekscias, kion oni demandis. Nek unu mekanismo anstataŭas la alian, kaj nek unu igas la alian superflua.

Kvar kontroloj decidas, ĉu la aranĝo, kiun vi havas, estas tiu, kiun vi pensas, ke vi havas.

Kontrolo 1: kion la ĉifrado kovras

DoT envolvas la DNS-interŝanĝon en TLS, do observanto sur la vojo vidas konekton al adreso kaj pordo anstataŭ nomon en demando. La solvilo mem malĉifras kaj respondas. Komparu ĝin kun DNS super HTTPS: ambaŭ ĉifras, kaj ili uzas malsamajn transportojn, do reto, kiu permesas retan trafikon, ne aŭtomate permesas DoT-konekton.

Tiu distingo gravas, kiam kaptita portalo aŭ filtra mezkesto permesas 443 kaj blokas 853. La ilo, kiu funkciis tie, ne estas pruvo, ke la alia funkcios.

Kontrolo 2: kiun vojon la demando iras

La vojo estas demando de klienta politiko. Oni povas atingi DoT-solvilon tra la tunelo, ekster ĝi, aŭ per vojo, kiu ŝanĝiĝas kun la reto. Kiu okazas dependas de la vojoj kaj de tio, ĉu la kliento protektas sian propran DNS-ingon. Tunelo, kiu kaptas la tutan trafikon, kutime kunportas la demandon, kion ajn diras la adreso de la solvilo.

Vidi adreson de triaparta solvilo en testo ne pruvas preterpason, kaj vidi ĉifradon ne pruvas la celitan ricevanton. Legu la solvilon kaj la vojon aparte, poste decidu, ĉu la paro estas tiu, kiun vi projektis.

Kontrolo 3: internaj nomoj

Organizo, kiu publikigas internajn nomojn, bezonas solvilon, kiu tenas tiujn rikordojn. Publika DoT-servo ne konas vian privatan nomspacon, kaj direkti la klienton al ĝi garantias, ke tiuj nomoj malsukcesos. Ĉi tio estas la plej ofta praktika regreso, kiam iu ŝaltas ĉifritan DNS sur administrata aparato.

Konservu la internan solvilon por internaj sufiksoj kaj ĉifru tiun salton, se politiko postulas tion, anstataŭ anstataŭigi ĝin per publika provizanto.

Kontrolo 4: konduto ĉe fiasko

Severa solvila agordo sen atingebla solvilo produktas fiaskon de nomosolvado dum la tunelo restas supre. Rigardu la platforman reĝimon kaj ĝian dokumentitan rezervan varianton anstataŭ tuŝi ŝlosilojn aŭ atestilojn.

Rezerva varianto, kiu silente uzas ordinaran DNS, estas politika decido, ne komfortaĵo. Decidu, ĉu fiasko devas esti videbla aŭ ĉu ĝi devas degeneri al io pli malforta, kaj skribu la respondon.

Fidu la atestilon, ne la respondon

Uzu la gastigantnomon de la provizanto kaj la validigan agordon dokumentitajn por la servo. Malŝalti TLS-kontrolojn, por ke nekonata solvilo respondu, donas al vi ĉifritan kanalon al nevalidigita finpunkto, kio estas pli malbona ol la ordinara demando, kiun ĝi anstataŭis, en unu konkreta rilato: ĝi aspektas sekura. La specifo de DNS super TLS prezentas la aŭtentigajn atendojn malantaŭ tiu kontrolo.

Respondo de solvilo, kiun vi ne povas aŭtentigi, estas aserto, ne rezulto.

Kion ĉi tio lasas neklarigita

DoT ne kaŝas la nomon de la solvilo, ne kaŝas la destinan adreson de la konekto de la reto, kaj ne decidas, ĉu la demando vojaĝis tra la tunelo. Tiuj estas tri apartaj demandoj kun tri apartaj respondoj.

Skribu la identecon de la solvilo, la transitan vojon kaj la internan nompolitikon kiel tri liniojn. La sekva DNS-demando, kiun vi ricevos, estos unu el ili.