Krypteret DNS uden VPN skjuler forespørgslen, ikke din adresse

En DNS-lækagetest, der viser dit hjemmenetværk, er ikke bevis for, at krypteret DNS fejlede, og det er heller ikke bevis for, at noget virkede. Testen besvarer ét spørgsmål: hvilken resolver nåede denne forespørgsel fra dette netværk. Om det er et problem afhænger af, hvad du beskyttede, og mod hvem.

Skriv målet ned, før du kører nogen test.

Trin 1: navngiv den beskyttelse, du faktisk vil have

Tre mål blandes sammen. Du vil måske have, at en observatør på vejen holder op med at læse forespørgsler. Du vil måske have, at en bestemt resolver holder op med at modtage dem. Du vil måske have, at de websteder, du besøger, holder op med at se din hjemadresse. Krypteret DNS tjener det første, ændrer hvem der opfylder det andet og gør absolut intet for det tredje.

En VPN tjener det tredje og, afhængigt af udbyderen, det første. Ingen af værktøjerne er en overmængde af det andet.

Trin 2: vælg en resolver, og verificér dens identitet

DNS over TLS pakker forespørgslen ind i en TLS-session med resolveren, og DNS over HTTPS pakker den ind i en HTTP-anmodning; RFC 7858 og RFC 8484 beskriver begge, og ingen af dem kræver en tunnel. Det afgørende operationelt er, at certifikatet verificeres mod det navn, du konfigurerede, fordi en krypteret session med den forkerte part er værre end klartekst med den rigtige. Det betyder streng tilstand, hvor platformen tilbyder den, ikke en opportunistisk tilstand, der falder tilbage, når verifikationen fejler. Kontrollér sessionen direkte, før du stoler på indstillingen: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Håndtrykket bør navngive den resolver, du konfigurerede, og returnere en kæde, du kan verificere.

Trin 3: beslut adfærden ved fejl

Hver implementering har en politik for en utilgængelig krypteret resolver, og den politik er privatlivsbeslutningen. Streng tilstand lader opslaget fejle, hvilket er synligt og irriterende. Opportunistisk tilstand prøver igen i klartekst, hvilket er usynligt og undergraver formålet præcis den dag, det betyder noget. Vælg bevidst, og skriv derefter valget ved siden af kravet.

På systemd-resolved betyder det DNSOverTLS=yes i stedet for opportunistic; på Android betyder det værtsnavntilstand for Private DNS i stedet for automatisk.

Kontrollér, hvad der faktisk er gældende, med resolvectl status | grep -i -A1 "dns over tls", fordi en drop-in-fil, der aldrig blev genindlæst, ændrer intet.

Trin 4: kontrollér, at programmer følger systemets resolver

En browser med sin egen indstilling for sikker DNS omgår systemkonfigurationen fuldstændigt, og det samme gør en container-runtime med en indlejret resolver eller en sprogruntime, der læser en hårdkodet liste. Enten får du dem til at følge systemet, eller du konfigurerer dem eksplicit og skriver det ned. Se derefter på fallback-adfærden for hver af dem, fordi de ikke alle fejler lukket. Inventaret er kort i praksis: browser, container-runtime og enhver VPN-klient, du også kører.

Private organisationsnavne bliver på den godkendte interne resolver. At sende dem til en offentlig tjeneste, så en test ser pæn ud, skaber bevidst et andet problem.

Trin 5: læs lækagetesten mod kravet

En test, der rapporterer en uventet resolver, er et hint, ikke en dom. Den kan have observeret din tilsigtede krypterede resolver, en programspecifik indstilling eller et fald tilbage til klartekst, du ikke vidste om. Sammenlign den rapporterede resolver med det, trin 2 konfigurerede, og sammenlign resultatet med målet fra trin 1.

Hvis målet var at holde forespørgsler væk fra det lokale netværk, er en test, der viser din almindelige resolver, et rigtigt fund. Hvis målet var anonymitet under browsing, ville ingen DNS-indstilling nogensinde levere det.

Skriv acceptlinjen på målets sprog: disse opslag bruger denne verificerede resolver under disse betingelser. Alt bredere er en påstand, du ikke kan teste.