Dulkóðað DNS án VPN felur fyrirspurnina, ekki heimilisfangið þitt

DNS-lekapróf sem sýnir heimanetið þitt er ekki sönnun þess að dulkóðað DNS hafi brugðist, og ekki heldur sönnun þess að eitthvað hafi virkað. Prófið svarar einni spurningu: hvaða leysir fékk þessa fyrirspurn frá þessu neti. Hvort það er vandamál fer eftir því hvað þú varst að verja og fyrir hverjum.

Skrifaðu markmiðið niður áður en þú keyrir nokkuð próf.

Skref 1: nefndu þá vernd sem þú vilt í raun

Þrjú markmið blandast saman. Þú vilt kannski að áhorfandi á leiðinni hætti að lesa fyrirspurnir. Þú vilt kannski að tiltekinn leysir hætti að taka við þeim. Þú vilt kannski að vefsíðurnar sem þú heimsækir hætti að sjá heimilisfangið þitt. Dulkóðað DNS þjónar því fyrsta, breytir því hver uppfyllir það annað og gerir ekkert fyrir það þriðja.

VPN þjónar því þriðja og, eftir þjónustuveitanda, því fyrsta. Hvort tækið er ekki ofurmengi hins.

Skref 2: veldu leysi og staðfestu auðkenni hans

DNS over TLS pakkar fyrirspurninni í TLS-lotu við leysinn, og DNS over HTTPS pakkar henni í HTTP-beiðni; RFC 7858 og RFC 8484 lýsa hvoru tveggja, og hvorugt þarf göng. Það sem skiptir máli í rekstri er að skírteinið sé staðfest gagnvart nafninu sem þú stilltir, því dulkóðuð lota við rangan aðila er verri en ódulkóðaður texti við réttan. Það þýðir stranga stillingu þar sem kerfið býður hana, ekki tækifærisstillingu sem hörfar þegar staðfesting mistekst. Athugaðu lotuna beint áður en þú treystir stillingunni: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Handabandið ætti að nefna leysinn sem þú stilltir og skila keðju sem þú getur staðfest.

Skref 3: ákveddu hegðun við bilun

Hver útfærsla hefur stefnu fyrir óaðgengilegan dulkóðaðan leysi, og sú stefna er persónuverndarákvörðunin. Ströng stilling lætur leitina mistakast, sem er sýnilegt og pirrandi. Tækifærisstilling reynir aftur í ódulkóðuðum texta, sem er ósýnilegt og eyðileggur tilganginn einmitt á þeim degi sem hann skiptir máli. Veldu af ásetningi og skráðu svo valið við hlið kröfunnar.

Á systemd-resolved þýðir það DNSOverTLS=yes ekki opportunistic; á Android þýðir það hýsilnafnastillingu Private DNS í stað sjálfvirkrar.

Athugaðu hvað er í raun í gildi með resolvectl status | grep -i -A1 "dns over tls", því drop-in skrá sem var aldrei hlaðin inn aftur breytir engu.

Skref 4: athugaðu að forrit fylgi leysi kerfisins

Vafri með eigin stillingu fyrir öruggt DNS fer algjörlega fram hjá stillingum kerfisins, og það sama gerir gáma-runtime með innbyggðum leysi eða tungumálaruntime sem les harðkóðaðan lista. Láttu þau annaðhvort fylgja kerfinu eða stilltu þau sérstaklega og skráðu það. Horfðu svo á afturhvarfshegðun hvers þeirra, því ekki mistakast öll lokuð. Listinn er stuttur í reynd: vafri, gáma-runtime og hvaða VPN-biðlari sem þú keyrir líka.

Einkanöfn stofnunarinnar haldast á samþykktum innri leysi. Að senda þau á opinbera þjónustu svo prófið líti snyrtilega út skapar viljandi annað vandamál.

Skref 5: lestu lekaprófið gagnvart kröfunni

Próf sem tilkynnir óvæntan leysi er vísbending, ekki dómur. Það kann að hafa séð fyrirhugaða dulkóðaða leysinn þinn, stillingu sem er sértæk fyrir forrit eða afturhvarf í ódulkóðaðan texta sem þú vissir ekki um. Berðu tilkynnta leysinn saman við það sem skref 2 stillti og berðu niðurstöðuna saman við markmiðið úr skrefi 1.

Ef markmiðið var að halda fyrirspurnum frá staðarnetinu er próf sem sýnir venjulega leysinn þinn raunveruleg niðurstaða. Ef markmiðið var nafnleysi við vafrun var engin DNS-stilling sem gæti nokkurn tíma veitt það.

Skrifaðu samþykkislínuna á tungumáli markmiðsins: þessar leitir nota þennan staðfesta leysi við þessar aðstæður. Allt víðtækara er fullyrðing sem þú getur ekki prófað.