DNS TLS:n yli ja VPN: mikä osa on suojattu

DNS TLS:n yli salaa asiakkaan ja sen valitseman resolverin välisen vaihdon, ja resolver lukee silti nimen. Tämä lause ratkaisee suurimman osan DoT:n ja VPN:n ympärillä olevasta sekaannuksesta. Tunneli päättää, mitä reittiä salattu kysely kulkee, kun taas resolver saa silti tietää, mitä kysyttiin. Kumpikaan mekanismi ei korvaa toista, eikä kumpikaan tee toisesta tarpeetonta.

Neljä tarkistusta ratkaisee, onko järjestely se, jonka luulet sen olevan.

Tarkistus 1: mitä salaus kattaa

DoT käärii DNS-vaihdon TLS:ään, joten reitillä oleva tarkkailija näkee yhteyden osoitteeseen ja porttiin eikä nimeä kyselyssä. Resolver itse purkaa salauksen ja vastaa. Vertaa sitä DNS:ään HTTPS:n yli: molemmat salaavat, ja ne käyttävät eri kuljetuksia, joten verkko, joka sallii verkkoliikenteen, ei automaattisesti salli DoT-yhteyttä.

Tällä erolla on merkitystä, kun captive portal tai suodattava välilaite sallii portin 443 ja estää portin 853. Työkalu, joka toimi siellä, ei ole todiste siitä, että toinen toimisi.

Tarkistus 2: mitä reittiä kysely kulkee

Reitti on asiakkaan käytännön kysymys. DoT-resolveriin voi päästä tunnelin kautta, sen ulkopuolelta tai polkua, joka muuttuu verkon mukana. Kumpi tapahtuu, riippuu reiteistä ja siitä, suojaako asiakas oman DNS-pistokkeensa. Tunneli, joka kaappaa kaiken liikenteen, vie yleensä kyselyn mukanaan, mitä resolverin osoite sanoo tahansa.

Kolmannen osapuolen resolverin osoitteen näkeminen testissä ei todista ohitusta, eikä salauksen näkeminen todista aiottua vastaanottajaa. Lue resolveri ja reitti erikseen ja päätä sitten, onko pari se, jonka suunnittelit.

Tarkistus 3: sisäiset nimet

Organisaatio, joka julkaisee sisäisiä nimiä, tarvitsee resolverin, joka pitää ne tietueet. Julkinen DoT-palvelu ei tunne yksityistä nimiavaruuttasi, ja asiakkaan osoittaminen sellaiseen takaa, että ne nimet epäonnistuvat. Tämä on yleisin käytännön regressio, kun joku ottaa salatun DNS:n käyttöön hallinnoidulla laitteella.

Pidä sisäinen resolver sisäisille jälkiliitteille ja salaa se hyppy, jos käytäntö vaatii, sen sijaan että korvaisit sen julkisella palveluntarjoajalla.

Tarkistus 4: käyttäytyminen vian sattuessa

Tiukka resolver-asetus ilman tavoitettavissa olevaa resolveria tuottaa nimien selvityksen vian, kun taas tunneli pysyy pystyssä. Katso alustan tilaa ja sen dokumentoitua varareittiä sen sijaan, että kosket avaimiin tai varmenteisiin.

Varareitti, joka käyttää hiljaa tavallista DNS:ää, on käytäntöpäätös, ei mukavuus. Päätä, pitääkö vian olla näkyvä vai pitääkö sen heiketä johonkin heikompaan, ja kirjoita vastaus muistiin.

Luota varmenteeseen, älä vastaukseen

Käytä palveluntarjoajan isäntänimeä ja palvelulle dokumentoitua vahvistusasetusta. TLS-tarkistusten poistaminen käytöstä, jotta tuntematon resolver vastaa, antaa sinulle salatun kanavan vahvistamattomaan päätepisteeseen, mikä on yhdellä tietyllä tavalla huonompi kuin tavallinen kysely, jonka se korvasi: se näyttää turvalliselta. DNS:n yli TLS:n määritys esittää sen tunnistautumisodotuksen, joka on kyseisen tarkistuksen takana.

Vastaus resolverilta, jota et voi todentaa, on väite, ei tulos.

Mitä tämä jättää selittämättä

DoT ei piilota nimeä resolverilta, ei piilota yhteyden kohdeosoitetta verkolta eikä päätä, kulkiko kysely tunnelin kautta. Ne ovat kolme erillistä kysymystä, joihin on kolme erillistä vastausta.

Kirjoita resolverin identiteetti, kauttakulkureitti ja sisäisten nimien käytäntö kolmeksi riviksi. Seuraava DNS-kysymys, jonka saat, on yksi niistä.