Salattu DNS ilman VPN:ää piilottaa kyselyn, ei osoitettasi

DNS-vuototesti, joka näyttää kotiverkkosi, ei ole todiste siitä, että salattu DNS epäonnistui, eikä todiste siitä, että mikään toimi. Testi vastaa yhteen kysymykseen: mille resolverille tämä kysely tästä verkosta päätyi. Onko se ongelma, riippuu siitä, mitä ja ketä vastaan suojasit.

Kirjoita tavoite muistiin ennen minkään testin ajamista.

Vaihe 1: nimeä suojaus, jonka todella haluat

Kolme tavoitetta sekoittuvat. Ehkä haluat, että polulla oleva tarkkailija lakkaa lukemasta kyselyitä. Ehkä haluat, että tietty resolver lakkaa vastaanottamasta niitä. Ehkä haluat, että vierailemasi verkkosivustot lakkaavat näkemästä kotiosoitteesi. Salattu DNS palvelee ensimmäistä, muuttaa sitä kuka täyttää toisen, eikä tee kolmannen hyväksi yhtään mitään.

VPN palvelee kolmatta ja palveluntarjoajasta riippuen ensimmäistä. Kumpikaan työkalu ei ole toisen yläjoukko.

Vaihe 2: valitse resolver ja varmista sen identiteetti

DNS over TLS käärii kyselyn TLS-istuntoon resolverin kanssa ja DNS over HTTPS käärii sen HTTP-pyyntöön; RFC 7858 ja RFC 8484 kuvaavat molemmat, eikä kumpikaan tarvitse tunnelia. Käytännössä on tärkeää, että varmenne varmistetaan sitä nimeä vastaan, jonka määritit, koska salattu istunto väärän osapuolen kanssa on pahempi kuin selkokielinen oikean kanssa. Se tarkoittaa tiukkaa tilaa siellä, missä alusta tarjoaa sen, ei opportunistista tilaa, joka perääntyy varmennuksen epäonnistuessa. Tarkista istunto suoraan ennen kuin luotat asetukseen: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Kättelyn pitäisi nimetä määrittämäsi resolver ja palauttaa ketju, jonka voit varmistaa.

Vaihe 3: päätä epäonnistumisen käyttäytyminen

Jokaisella toteutuksella on käytäntö tavoittamattoman salatun resolverin varalle, ja tämä käytäntö on yksityisyyspäätös. Tiukka tila epäonnistuttaa haun, mikä on näkyvää ja ärsyttävää. Opportunistinen tila yrittää uudelleen selkokielisenä, mikä on näkymätöntä ja tekee tarkoituksen tyhjäksi juuri sinä päivänä, jolloin sillä on väliä. Valitse tietoisesti ja kirjaa valinta vaatimuksen viereen.

systemd-resolvedissa se tarkoittaa DNSOverTLS=yes eikä opportunistic; Androidissa se tarkoittaa Private DNS:n isäntänimitilaa automaattisen sijaan.

Tarkista, mikä on todella voimassa komennolla resolvectl status | grep -i -A1 "dns over tls", koska drop-in-tiedosto, jota ei koskaan ladattu uudelleen, ei muuta mitään.

Vaihe 4: tarkista, että sovellukset noudattavat järjestelmän resolveria

Selain, jolla on oma suojatun DNS:n asetuksensa, ohittaa järjestelmän kokoonpanon täysin, samoin konttisovelluksen runtime, jossa on sisäänrakennettu resolver, tai kielen runtime, joka lukee kovakoodattua luetteloa. Joko saat ne noudattamaan järjestelmää tai määrität ne erikseen ja kirjaat sen. Katso sitten kunkin varakäyttäytymistä, koska kaikki eivät epäonnistu suljetusti. Luettelo on käytännössä lyhyt: selain, kontin runtime ja mikä tahansa myös ajamasi VPN-asiakas.

Organisaation yksityiset nimet pysyvät hyväksytyssä sisäisessä resolverissa. Niiden lähettäminen julkiseen palveluun, jotta testi näyttäisi siistiltä, luo tarkoituksella toisen ongelman.

Vaihe 5: lue vuototesti vaatimusta vasten

Testi, joka raportoi odottamattomasta resolverista, on vihje, ei tuomio. Se on ehkä havainnut aiotun salatun resolverin, sovelluskohtaisen asetuksen tai selkokielisen varareitin, jota et tiennyt. Vertaa raportoitua resolveria siihen, minkä vaihe 2 määritti, ja vertaa tulosta vaiheen 1 tavoitteeseen.

Jos tavoite oli pitää kyselyt poissa paikallisesta verkosta, testi joka näyttää tavallisen resolverisi on todellinen löydös. Jos tavoite oli anonymiteetti selatessa, mikään DNS-asetus ei olisi koskaan sitä tarjonnut.

Kirjoita hyväksymisrivi tavoitteen kielellä: nämä haut käyttävät tätä varmennettua resolveria näissä olosuhteissa. Kaikki sitä laajempi on väite, jota et voi testata.