DNSSEC versus VPN: welke verbergt je DNS-query's?

Twee mechanismen krijgen dezelfde taak toebedeeld en geen van beide voert die uit. DNSSEC beantwoordt of de gegevens die je ontving echt afkomstig zijn van de zone die ze publiceert, en een VPN bepaalt welke route je pakketten nemen. Geen van beide verbergt in alle gevallen de naam die je hebt opgevraagd, en de instellingen die daarop lijken te wijzen gaan meestal over transport of routering en niet over validatie. Als je eerst de laag benoemt, wordt een vage privacysvraag een concrete vraag.

Drie beweringen die samensmelten tot één

Authenticiteit is de bewering dat het antwoord het antwoord is dat de zone publiceerde en dat het onderweg niet is gewijzigd. Vertrouwelijkheid is de bewering dat niemand op het pad de query of het antwoord kan lezen. Routering is de bewering dat de pakketten een pad volgen dat jij hebt gekozen, en dat is precies wat een tunnel biedt.

DNSSEC behandelt de eerste en zegt niets over de andere twee. DoT en DoH behandelen de tweede voor de sprong naar de resolver. Een VPN behandelt de derde en kan ook de tweede beïnvloeden, maar alleen als bijeffect van waar het verkeer naartoe gaat.

Applicatieverkeer is een vierde geval: HTTPS beschermt en authenticeert de webuitwisseling tussen je client en de site, en geen enkele DNS-laag vervangt dat.

Wat signatuurvalidatie wel en niet kan

Een validerende resolver controleert de keten van signaturen van de zone tot een geconfigureerde vertrouwensanker en geeft vervolgens een antwoord terug met de vlag voor geauthenticeerde gegevens gezet wanneer de controle slaagt. Die vlag is bewijs over de gegevens, niet over de verbinding of de bedoelingen van de bestemming.

Het kan een legitieme zone-eigenaar er niet van weerhouden authentieke records te publiceren voor een dienst die je niet zou moeten vertrouwen. Een correct ondertekend antwoord van een gecompromitteerd domein is nog steeds correct ondertekend, en DNSSEC heeft geen mening over de vraag of dat domein je inloggegevens verdient.

Het verbergt ook niets. De query en het antwoord gaan door het netwerk in een vorm die een resolver en elke waarnemer op dat pad kunnen lezen, tenzij een andere laag het transport beschermt. Een ondertekend antwoord en een privéantwoord zijn verschillende eigenschappen, en een implementatie kan er slechts één hebben. Test beide als een van beide voor jou belangrijk is.

Waar vertrouwelijkheid werkelijk vandaan komt

Versleuteld resolvertransport wikkelt de DNS-uitwisseling in TLS, zodat de resolver de vraag nog steeds ziet maar het pad tussen jou en de resolver niet. Dat verplaatst vertrouwen in plaats van het weg te nemen: je vertrouwt de resolver meer en het lokale netwerk minder.

Een VPN kan query's naar een resolver aan de andere kant brengen, wat zowel het pad als de resolver die ze ziet verandert. Dat is een routeringsbeslissing met een privacygevolg, en op een beheerd netwerk kan de interne resolver de enige zijn die interne namen kan beantwoorden.

De combinatie die mensen echt willen is meestal drie dingen tegelijk: validatie aan, versleuteld transport naar een zelfgekozen resolver en applicatie-TLS op de bestemming. Elk is onafhankelijk, en er één overslaan laat een ander gat achter.

Controleer validatie en transport afzonderlijk

Twee tests lossen het meeste misverstand op. De eerste vraagt of de resolver het antwoord heeft gevalideerd; de tweede vraagt of het transport was beschermd. Ze falen op verschillende manieren en geen van beide impliceert de andere.

Deze opdrachten drukken de vlaggen af van een validerende query, herhalen de query met de controle uitgeschakeld en voeren lokale validatie uit met delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

Een antwoord met de vlag voor geauthenticeerde gegevens en een aanwezige signatuur toont validatie bij die resolver. Een validatiefout met delv toont een gebroken keten ergens tussen de zone en de vertrouwensanker, wat een publicatieprobleem is en geen tunnelprobleem. Een time-out zonder enige vlag is een transport- of bereikbaarheidsprobleem, en dat als een signatuur fout behandelen stuurt je naar de verkeerde laag.

Wat te doen als een VPN opzoekingen breekt

Als opzoekingen voor de tunnel werkten en erna stoppen, vergelijk de resolver die elk pad gebruikt. Gesplitst tunnelen, een interne resolver die alleen via de tunnel bereikbaar is, en een client die resolverinstellingen herschrijft, veranderen allemaal het antwoord zonder DNSSEC aan te raken.

Validatie wereldwijd uitschakelen is de verkeerde eerste stap, omdat het het enige mechanisme verwijdert dat manipulatie meldt en een onbereikbare resolver niet repareert. Beperk eerst de storing: resolutie, transport, validatie en dan beleid. Alleen de derde hoort bij DNSSEC, en alleen de tweede bij versleuteld transport.