Versleutelde DNS zonder VPN verbergt de query, niet je adres

Een DNS-lektest die je thuisnetwerk toont, is geen bewijs dat versleutelde DNS heeft gefaald, en ook geen bewijs dat er iets werkte. De test beantwoordt één vraag: welke resolver heeft deze query van dit netwerk bereikt. Of dat een probleem is, hangt af van wat en tegen wie je beschermde.

Schrijf het doel op voordat je een test uitvoert.

Stap 1: benoem de bescherming die je echt wilt

Drie doelen lopen door elkaar. Misschien wil je dat een waarnemer op het pad stopt met het lezen van queries. Misschien wil je dat een bepaalde resolver stopt ze te ontvangen. Misschien wil je dat de websites die je bezoekt je thuisadres niet meer zien. Versleutelde DNS dient het eerste, verandert wie het tweede vervult en doet helemaal niets voor het derde.

Een VPN dient het derde en, afhankelijk van de provider, het eerste. Geen van beide hulpmiddelen is een superset van het andere.

Stap 2: kies een resolver en verifieer zijn identiteit

DNS over TLS verpakt de query in een TLS-sessie met de resolver, en DNS over HTTPS verpakt hem in een HTTP-verzoek; RFC 7858 en RFC 8484 beschrijven beide, en geen van beide heeft een tunnel nodig. Operationeel belangrijk is dat het certificaat wordt geverifieerd tegen de naam die je hebt geconfigureerd, want een versleutelde sessie met de verkeerde partij is erger dan platte tekst met de juiste. Dat betekent strikte modus waar het platform die biedt, geen opportunistische modus die terugvalt wanneer de verificatie mislukt. Controleer de sessie rechtstreeks voordat je de instelling vertrouwt: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

De handshake hoort de resolver te noemen die je hebt geconfigureerd en een keten terug te geven die je kunt verifiëren.

Stap 3: bepaal het gedrag bij een fout

Elke implementatie heeft een beleid voor een onbereikbare versleutelde resolver, en dat beleid is de privacybeslissing. Strikte modus laat de opzoeking mislukken, wat zichtbaar en irritant is. Opportunistische modus probeert het opnieuw in platte tekst, wat onzichtbaar is en het doel juist op de dag dat het ertoe doet ondermijnt. Kies bewust en noteer de keuze naast de eis.

Op systemd-resolved betekent dat DNSOverTLS=yes in plaats van opportunistic; op Android betekent het de hostnamemodus van Private DNS in plaats van automatisch.

Controleer wat werkelijk van kracht is met resolvectl status | grep -i -A1 "dns over tls", want een drop-in-bestand dat nooit opnieuw is geladen verandert niets.

Stap 4: controleer of toepassingen de systeemresolver volgen

Een browser met een eigen instelling voor veilige DNS omzeilt de systeemconfiguratie volledig, en dat geldt ook voor een container-runtime met een ingebouwde resolver of een taalruntime die een hardgecodeerde lijst leest. Laat ze het systeem volgen of configureer ze expliciet en leg dat vast. Bekijk daarna het terugvalgedrag van elk ervan, want ze falen niet allemaal gesloten. De inventaris is in de praktijk kort: browser, container-runtime en elke VPN-client die je ook draait.

Private organisatienamen blijven op de goedgekeurde interne resolver. Ze naar een openbare dienst sturen zodat een test er netjes uitziet, maakt met opzet een ander probleem.

Stap 5: lees de lektest tegen de eis

Een test die een onverwachte resolver meldt, is een aanwijzing, geen vonnis. Hij heeft misschien je bedoelde versleutelde resolver gezien, een toepassingsspecifieke instelling of een terugval naar platte tekst waarvan je niet wist. Vergelijk de gemelde resolver met wat stap 2 configureerde, en vergelijk het resultaat met het doel uit stap 1.

Als het doel was om queries weg te houden van het lokale netwerk, is een test die je gewone resolver toont een echte bevinding. Als het doel anonimiteit tijdens het browsen was, zou geen enkele DNS-instelling dat ooit hebben geleverd.

Schrijf de acceptatieregel in de taal van het doel: deze opzoekingen gebruiken deze geverifieerde resolver onder deze voorwaarden. Alles breder is een bewering die je niet kunt testen.