DNSSEC vs. en VPN: hvilken skjuler dine DNS-forespørgsler?

To mekanismer får æren for den samme opgave, og ingen af dem udfører den. DNSSEC svarer på, om de data, du modtog, virkelig kom fra den zone, der udgiver dem, og en VPN afgør, hvilken vej dine pakker tager. Ingen af dem skjuler i alle tilfælde det navn, du spurgte om, og de indstillinger, der ser ud som om de burde, handler normalt om transport eller routing frem for om validering. Navngiver du først laget, bliver et vagt spørgsmål om privatliv til et konkret et.

Tre påstande, der smeltes sammen til én

Ægthed er påstanden om, at svaret er det, zonen udgav, og ikke blev ændret undervejs. Fortrolighed er påstanden om, at ingen på vejen kan læse forespørgslen eller svaret. Routing er påstanden om, at pakkerne følger en vej, du valgte, hvilket er det, en tunnel giver.

DNSSEC behandler den første og siger intet om de to andre. DoT og DoH behandler den anden for hoppet til resolveren. En VPN behandler den tredje og kan også påvirke den anden, men kun som en bivirkning af, hvor trafikken går hen.

Applikationstrafik er et fjerde tilfælde: HTTPS beskytter og autentificerer webudvekslingen mellem din klient og webstedet, og intet DNS-lag erstatter det.

Hvad signaturvalidering kan og ikke kan

En validerende resolver kontrollerer signaturkæden fra zonen op til et konfigureret tillidsanker og returnerer derefter et svar med flaget for autentificerede data sat, når kontrollen lykkes. Det flag er bevis om dataene, ikke om forbindelsen eller destinationens hensigter.

Det kan ikke forhindre en legitim zoneejer i at udgive ægte poster for en tjeneste, du ikke bør stole på. Et korrekt signeret svar fra et kompromitteret domæne er stadig korrekt signeret, og DNSSEC har ingen mening om, hvorvidt det domæne fortjener dine legitimationsoplysninger.

Det skjuler heller intet. Forespørgslen og svaret krydser netværket i en form, som en resolver og enhver observatør på den vej kan læse, medmindre et andet lag beskytter transporten. Et signeret svar og et privat svar er forskellige egenskaber, og en udrulning kan have hver enkelt alene. Test begge, hvis en af dem betyder noget for dig.

Hvor fortroligheden faktisk kommer fra

Krypteret resolvertransport pakker DNS-udvekslingen ind i TLS, så resolveren ser stadig spørgsmålet, men vejen mellem dig og den gør ikke. Det flytter tillid i stedet for at fjerne den: du stoler mere på resolveren og mindre på det lokale netværk.

En VPN kan føre forespørgsler til en resolver på den anden side, hvilket ændrer både vejen og den resolver, der ser dem. Det er en routingbeslutning med en privatlivskonsekvens, og på et administreret netværk kan den interne resolver være den eneste, der kan svare på interne navne.

Den kombination, folk faktisk ønsker, er normalt tre ting på én gang: validering slået til, krypteret transport til en resolver, de selv valgte, og applikations-TLS på destinationen. Hver er uafhængig, og springer man en over, efterlader det et andet hul.

Kontroller validering og transport hver for sig

To test løser det meste af forvirringen. Den første spørger, om resolveren validerede svaret; den anden spørger, om transporten var beskyttet. De fejler på forskellige måder, og ingen af dem forudsætter den anden.

Disse kommandoer udskriver flagene fra en validerende forespørgsel, gentager forespørgslen med kontrol deaktiveret og kører lokal validering med delv:

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

Et svar med flaget for autentificerede data og en tilstedeværende signatur viser validering på den resolver. En valideringsfejl med delv viser en brudt kæde et sted mellem zonen og tillidsankeret, hvilket er et udgivelsesproblem snarere end et tunnelproblem. En timeout helt uden flag er et transport- eller tilgængelighedsproblem, og at behandle det som en signaturfejl sender dig til det forkerte lag.

Hvad du skal gøre, når en VPN ødelægger opslag

Hvis opslag virkede før tunnelen og stoppede efter den, sammenlign den resolver, hver vej bruger. Opdelt tunneling, en intern resolver, der kun kan nås gennem tunnelen, og en klient, der overskriver resolverindstillinger, ændrer alle svaret uden at røre DNSSEC.

At slå validering fra globalt er det forkerte første skridt, fordi det fjerner den eneste mekanisme, der rapporterer manipulation, og ikke løser en resolver, der ikke kan nås. Indkreds fejlen først: opløsning, transport, validering og derefter politik. Kun det tredje hører til DNSSEC, og kun det andet hører til krypteret transport.