Kryptert DNS uten VPN skjuler spørringen, ikke adressen din

En DNS-lekkasjetest som viser hjemmenettverket ditt er ikke bevis for at kryptert DNS feilet, og det er heller ikke bevis for at noe virket. Testen svarer på ett spørsmål: hvilken resolver nådde denne spørringen fra dette nettverket. Om det er et problem avhenger av hva og hvem du beskyttet deg mot.

Skriv ned målet før du kjører noen test.

Trinn 1: navngi beskyttelsen du faktisk vil ha

Tre mål blandes sammen. Du vil kanskje at en observatør på veien skal slutte å lese spørringer. Du vil kanskje at en bestemt resolver skal slutte å motta dem. Du vil kanskje at nettstedene du besøker skal slutte å se hjemadressen din. Kryptert DNS tjener det første, endrer hvem som oppfyller det andre og gjør absolutt ingenting for det tredje.

En VPN tjener det tredje og, avhengig av leverandøren, det første. Ingen av verktøyene er en overmengde av det andre.

Trinn 2: velg en resolver og verifiser identiteten dens

DNS over TLS pakker spørringen inn i en TLS-økt med resolveren, og DNS over HTTPS pakker den inn i en HTTP-forespørsel; RFC 7858 og RFC 8484 beskriver begge, og ingen av dem trenger en tunnel. Det avgjørende operativt er at sertifikatet verifiseres mot navnet du konfigurerte, fordi en kryptert økt med feil part er verre enn klartekst med den riktige. Det betyr streng modus der plattformen tilbyr det, ikke en opportunistisk modus som faller tilbake når verifiseringen feiler. Kontroller økten direkte før du stoler på innstillingen: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Håndtrykket bør navngi resolveren du konfigurerte og returnere en kjede du kan verifisere.

Trinn 3: bestem oppførselen ved feil

Hver implementasjon har en policy for en utilgjengelig kryptert resolver, og den policyen er personvernbeslutningen. Streng modus lar oppslaget feile, noe som er synlig og irriterende. Opportunistisk modus prøver på nytt i klartekst, noe som er usynlig og undergraver formålet nettopp den dagen det betyr noe. Velg bevisst, og skriv deretter valget ved siden av kravet.

På systemd-resolved betyr det DNSOverTLS=yes i stedet for opportunistic; på Android betyr det vertsnavnmodus for Private DNS i stedet for automatisk.

Kontroller hva som faktisk gjelder med resolvectl status | grep -i -A1 "dns over tls", fordi en drop-in-fil som aldri ble lastet inn på nytt ikke endrer noe.

Trinn 4: kontroller at programmer følger systemets resolver

En nettleser med sin egen innstilling for sikker DNS omgår systemkonfigurasjonen fullstendig, og det samme gjør en container-runtime med en innebygd resolver eller en språkruntime som leser en hardkodet liste. Enten få dem til å følge systemet, eller konfigurer dem eksplisitt og skriv det ned. Se deretter på fallback-oppførselen til hver av dem, fordi ikke alle feiler lukket. Oversikten er kort i praksis: nettleser, container-runtime og enhver VPN-klient du også kjører.

Private organisasjonsnavn blir værende på den godkjente interne resolveren. Å sende dem til en offentlig tjeneste så en test ser ryddig ut skaper bevisst et annet problem.

Trinn 5: les lekkasjetesten mot kravet

En test som rapporterer en uventet resolver er et hint, ikke en dom. Den kan ha observert den tiltenkte krypterte resolveren din, en applikasjonsspesifikk innstilling eller et fall tilbake til klartekst du ikke visste om. Sammenlign den rapporterte resolveren med det trinn 2 konfigurerte, og sammenlign resultatet med målet fra trinn 1.

Hvis målet var å holde spørringer unna det lokale nettverket, er en test som viser din vanlige resolver et reelt funn. Hvis målet var anonymitet under surfing, ville ingen DNS-innstilling noensinne levert det.

Skriv akseptlinjen på målets språk: disse oppslagene bruker denne verifiserte resolveren under disse betingelsene. Alt bredere er en påstand du ikke kan teste.