Kryptert DNS utan VPN gøymer spørjinga, ikkje adressa di

Ein DNS-lekkasjetest som viser heimenettverket ditt er ikkje prov på at kryptert DNS feila, og det er heller ikkje prov på at noko verka. Testen svarar på eitt spørsmål: kva resolver nådde denne spørjinga frå dette nettverket. Om det er eit problem, kjem an på kva og kven du verna deg mot.

Skriv ned målet før du køyrer nokon test.

Steg 1: nemn vernet du faktisk vil ha

Tre mål blir blanda saman. Du vil kanskje at ein observatør på vegen skal slutte å lese spørjingar. Du vil kanskje at ein bestemt resolver skal slutte å ta imot dei. Du vil kanskje at nettstadene du besøkjer skal slutte å sjå heimeadressa di. Kryptert DNS tener det første, endrar kven som oppfyller det andre og gjer absolutt ingenting for det tredje.

Ein VPN tener det tredje og, avhengig av leverandøren, det første. Ingen av verktøya er ei overmengd av det andre.

Steg 2: vel ein resolver og stadfest identiteten hans

DNS over TLS pakkar spørjinga inn i ein TLS-økt med resolveren, og DNS over HTTPS pakkar ho inn i ein HTTP-førespurnad; RFC 7858 og RFC 8484 skildrar begge, og ingen av dei treng ein tunnel. Det avgjerande operativt er at sertifikatet blir stadfesta mot namnet du konfigurerte, fordi ei kryptert økt med feil part er verre enn klartekst med den rette. Det tyder streng modus der plattforma tilbyr det, ikkje ein opportunistisk modus som fell tilbake når stadfestinga feilar. Kontroller økta direkte før du stolar på innstillinga: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Handtrykket bør nemne resolveren du konfigurerte og returnere ei kjede du kan stadfeste.

Steg 3: avgjer åtferda ved feil

Kvar implementasjon har ein policy for ein utilgjengeleg kryptert resolver, og den policyen er personvernavgjerda. Streng modus lèt oppslaget feile, noko som er synleg og irriterande. Opportunistisk modus prøver på nytt i klartekst, noko som er usynleg og underminerer føremålet nettopp den dagen det gjeld. Vel medvite, og skriv så valet ved sida av kravet.

På systemd-resolved tyder det DNSOverTLS=yes i staden for opportunistic; på Android tyder det vertsnamnmodus for Private DNS i staden for automatisk.

Kontroller kva som faktisk gjeld med resolvectl status | grep -i -A1 "dns over tls", fordi ei drop-in-fil som aldri vart lasta inn på nytt ikkje endrar noko.

Steg 4: kontroller at program følgjer systemresolveren

Ein nettlesar med si eiga innstilling for trygg DNS omgår systemkonfigurasjonen heilt, og det same gjer ein container-runtime med ein innebygd resolver eller ein språkdriftstid som les ei hardkoda liste. Få dei til å følgje systemet, eller konfigurer dei eksplisitt og skriv det ned. Sjå så på fallback-åtferda til kvar av dei, fordi ikkje alle feilar lukka. Oversynet er kort i praksis: nettlesar, container-runtime og kvar VPN-klient du òg køyrer.

Private organisasjonsnamn blir verande på den godkjende interne resolveren. Å sende dei til ein offentleg teneste så ein test ser ryddig ut skaper med vilje eit anna problem.

Steg 5: les lekkasjetesten mot kravet

Ein test som rapporterer ein uventa resolver er eit hint, ikkje ein dom. Han kan ha observert den tiltenkte krypterte resolveren din, ei bruksspesifikk innstilling eller eit fall tilbake til klartekst du ikkje visste om. Samanlikn den rapporterte resolveren med det steg 2 konfigurerte, og samanlikn resultatet med målet frå steg 1.

Om målet var å halde spørjingar unna det lokale nettverket, er ein test som viser den vanlege resolveren din eit reelt funn. Om målet var anonymitet under surfing, ville inga DNS-innstilling nokosinne ha levert det.

Skriv akseptlinja på språket til målet: desse oppslaga brukar denne stadfesta resolveren under desse vilkåra. Alt breiare er ein påstand du ikkje kan teste.