DNS preko TLS-a uz VPN: koji je dio zaštićen

DNS preko TLS-a šifrira razmjenu između klijenta i resolvera koji je odabrao, a resolver i dalje čita ime. Ta rečenica rješava većinu zabune oko DoT-a uz VPN. Tunel odlučuje kojim putem ide šifrirani upit, dok resolver i dalje saznaje što je pitano. Nijedan mehanizam ne zamjenjuje drugi i nijedan ne čini drugi suvišnim.

Četiri provjere odlučuju je li uređenje koje imate ono za koje mislite da ga imate.

Provjera 1: što šifriranje pokriva

DoT zamata DNS razmjenu u TLS, pa promatrač na putu vidi vezu prema adresi i portu, a ne ime u upitu. Sam resolver dešifrira i odgovara. Usporedite s DNS-om preko HTTPS-a: oba šifriraju i koriste različite transporte, pa mreža koja dopušta web promet ne dopušta automatski DoT vezu.

Ta razlika je važna kad captive portal ili filtrirajući međusklop dopušta 443 i blokira 853. Alat koji je tamo radio nije dokaz da će drugi raditi.

Provjera 2: kojom rutom ide upit

Ruta je pitanje klijentske politike. Do DoT resolvera može se doći kroz tunel, izvan njega ili putem koji se mijenja s mrežom. Koji će se dogoditi ovisi o rutama i o tome štiti li klijent svoj DNS socket. Tunel koji hvata sav promet obično će ponijeti upit sa sobom, što god adresa resolvera govorila.

Vidjeti adresu resolvera treće strane u testu ne dokazuje zaobilaženje, a vidjeti šifriranje ne dokazuje željenog primatelja. Čitajte resolver i put odvojeno, pa odlučite je li par ono što ste projektirali.

Provjera 3: interna imena

Organizacija koja objavljuje interna imena treba resolver koji drži te zapise. Javna DoT usluga ne poznaje vaš privatni prostor imena, a usmjeravanje klijenta na nju jamči da će ta imena propasti. To je najčešća praktična regresija kad netko uključi šifrirani DNS na upravljanom uređaju.

Zadržite interni resolver za interne sufikse i šifrirajte taj skok ako politika to zahtijeva, umjesto da ga zamijenite javnim pružateljem.

Provjera 4: ponašanje pri kvaru

Stroga postavka resolvera bez dostupnog resolvera daje kvar razrješavanja imena dok tunel ostaje podignut. Gledajte način rada platforme i njezin dokumentirani rezervni put, umjesto da dirate ključeve ili certifikate.

Rezervni put koji tiho koristi obični DNS je odluka politike, a ne pogodnost. Odlučite treba li kvar biti vidljiv ili se treba spustiti na nešto slabije, i zapišite odgovor.

Vjerujte certifikatu, a ne odgovoru

Koristite ime hosta pružatelja i konfiguraciju provjere dokumentiranu za uslugu. Isključivanje TLS provjera da bi nepoznati resolver odgovorio daje vam šifriran kanal prema neprovjerenoj krajnjoj točki, što je gore od običnog upita koji je zamijenio, u jednom konkretnom pogledu: izgleda sigurno. Specifikacija DNS-a preko TLS-a izlaže očekivanje provjere autentičnosti iza te kontrole.

Odgovor resolvera koji ne možete provjeriti je tvrdnja, a ne rezultat.

Što ovo ostavlja neobjašnjenim

DoT ne skriva ime od resolvera, ne skriva adresu odredišta veze od mreže i ne odlučuje je li upit išao kroz tunel. To su tri odvojena pitanja s tri odvojena odgovora.

Zapišite identitet resolvera, tranzitni put i politiku internih imena kao tri retka. Sljedeće DNS pitanje koje dobijete bit će jedno od njih.