Krypterad DNS utan VPN döljer frågan, inte din adress

Ett DNS-läckagetest som visar ditt hemnätverk är inte bevis för att krypterad DNS misslyckades, och inte heller bevis för att något fungerade. Testet svarar på en fråga: vilken resolver nådde den här frågan från det här nätverket. Om det är ett problem beror på vad och vem du skyddade dig mot.

Skriv ner målet innan du kör något test.

Steg 1: namnge det skydd du faktiskt vill ha

Tre mål blandas ihop. Du kanske vill att en observatör på vägen slutar läsa frågor. Du kanske vill att en viss resolver slutar ta emot dem. Du kanske vill att webbplatserna du besöker slutar se din hemadress. Krypterad DNS tjänar det första, ändrar vem som uppfyller det andra och gör absolut ingenting för det tredje.

Ett VPN tjänar det tredje och, beroende på leverantör, det första. Inget av verktygen är en övermängd av det andra.

Steg 2: välj en resolver och verifiera dess identitet

DNS over TLS packar in frågan i en TLS-session med resolvern, och DNS over HTTPS packar in den i en HTTP-begäran; RFC 7858 och RFC 8484 beskriver båda, och ingen av dem behöver en tunnel. Operativt viktigt är att certifikatet verifieras mot namnet du konfigurerade, eftersom en krypterad session med fel part är värre än klartext med rätt. Det innebär strikt läge där plattformen erbjuder det, inte ett opportunistiskt läge som faller tillbaka när verifieringen misslyckas. Kontrollera sessionen direkt innan du litar på inställningen: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Handskakningen bör namnge resolvern du konfigurerade och returnera en kedja du kan verifiera.

Steg 3: bestäm beteendet vid fel

Varje implementering har en policy för en otillgänglig krypterad resolver, och den policyn är integritetsbeslutet. Strikt läge låter sökningen misslyckas, vilket är synligt och irriterande. Opportunistiskt läge försöker igen i klartext, vilket är osynligt och omintetgör syftet just den dag det spelar roll. Välj medvetet och skriv sedan ner valet bredvid kravet.

På systemd-resolved betyder det DNSOverTLS=yes i stället för opportunistic; på Android betyder det värdnamnsläget för Private DNS i stället för automatiskt.

Kontrollera vad som faktiskt gäller med resolvectl status | grep -i -A1 "dns over tls", eftersom en drop-in-fil som aldrig lästes in igen inte ändrar något.

Steg 4: kontrollera att program följer systemets resolver

En webbläsare med egen inställning för säker DNS kringgår systemkonfigurationen helt, och detsamma gör en container-runtime med en inbyggd resolver eller en språkruntime som läser en hårdkodad lista. Antingen får du dem att följa systemet eller så konfigurerar du dem uttryckligen och skriver ner det. Titta sedan på varje enskilds fallback-beteende, eftersom inte alla misslyckas stängt. Inventariet är kort i praktiken: webbläsare, container-runtime och vilken VPN-klient du än kör.

Organisationens privata namn stannar på den godkända interna resolvern. Att skicka dem till en offentlig tjänst så att ett test ser prydligt ut skapar medvetet ett annat problem.

Steg 5: läs läckagetestet mot kravet

Ett test som rapporterar en oväntad resolver är en ledtråd, inte en dom. Det kan ha observerat den avsedda krypterade resolvern, en programspecifik inställning eller en återgång till klartext som du inte kände till. Jämför den rapporterade resolvern med det som steg 2 konfigurerade, och jämför resultatet med målet från steg 1.

Om målet var att hålla frågor borta från det lokala nätverket är ett test som visar din vanliga resolver ett verkligt fynd. Om målet var anonymitet vid surfande skulle ingen DNS-inställning någonsin ha levererat det.

Skriv acceptansraden på målets språk: dessa uppslag använder denna verifierade resolver under dessa villkor. Allt bredare är ett påstående du inte kan testa.