DNSSEC eller VPN: kva for ein skjuler DNS-spurnadene dine?

To mekanismar får æra for den same oppgåva, og ingen av dei utfører henne. DNSSEC svarer på om dataa du fekk verkeleg kom frå sonen som publiserer dei, og ein VPN avgjer kva veg pakkane dine tek. Ingen av dei skjuler i alle tilfelle namnet du spurde om, og innstillingane som ser ut som dei burde gjere det, handlar vanlegvis om transport eller ruting og ikkje om validering. Viss du namngjev laget først, vert eit vagt personvernspørsmål til eit konkret spørsmål.

Tre påstandar som smeltar saman til éin

Autentisitet er påstanden om at svaret er det sonen publiserte, og at det ikkje vart endra undervegs. Konfidensialitet er påstanden om at ingen på vegen kan lese spurnaden eller svaret. Ruting er påstanden om at pakkane følgjer ein veg du valde, og det er nettopp det ein tunnel gir.

DNSSEC handsamar den første og seier ikkje noko om dei to andre. DoT og DoH handsamar den andre for hoppet til resolveren. Ein VPN handsamar den tredje og kan òg påverke den andre, men berre som ein bieffekt av kvar trafikken går.

Applikasjonstrafikk er eit fjerde tilfelle: HTTPS vernar om og autentiserer nettutvekslinga mellom klienten din og nettstaden, og ingen DNS-lag erstattar det.

Kva signaturvalidering kan og ikkje kan

Ein validerande resolver kontrollerer signaturkjeda frå sonen opp til eit konfigurert tillitsanker og returnerer deretter eit svar med flagget for autentiserte data sett når kontrollen lykkast. Det flagget er prov om dataa, ikkje om sambandet eller føremåla til destinasjonen.

Det kan ikkje hindre ein legitim soneeigar i å publisere autentiske oppføringar for ei teneste du ikkje bør stole på. Eit korrekt signert svar frå eit kompromittert domene er framleis korrekt signert, og DNSSEC har inga meining om korvidt det domenet fortener påloggingsinformasjonen din.

Det skjuler heller ingenting. Spurnaden og svaret kryssar nettverket i ei form som ein resolver og kvar ein observatør på den vegen kan lese, med mindre eit anna lag vernar om transporten. Eit signert svar og eit privat svar er ulike eigenskapar, og ein utrulling kan ha kvar av dei åleine. Test begge viss ein av dei betyr noko for deg.

Kvar konfidensialiteten faktisk kjem frå

Kryptert resolvertransport pakkar DNS-utvekslinga inn i TLS, så resolveren ser framleis spørsmålet, men vegen mellom deg og han ikkje. Det flyttar tillit i staden for å fjerne henne: du stolar meir på resolveren og mindre på det lokale nettverket.

Ein VPN kan føre spurnader til ein resolver på den andre sida, noko som endrar både vegen og resolveren som ser dei. Det er ei rutingsavgjerd med ein personvernkonsekvens, og på eit administrert nettverk kan den interne resolveren vere den einaste som kan svare på interne namn.

Kombinasjonen folk faktisk vil ha, er vanlegvis tre ting på ein gong: validering på, kryptert transport til ein resolver dei valde, og applikasjons-TLS på destinasjonen. Kvar er uavhengig, og hoppar du over éin, står eit anna hol att.

Kontroller validering og transport kvar for seg

To testar løyser det meste av forvirringa. Den første spør om resolveren validerte svaret; den andre spør om transporten var verna. Dei feilar på ulike måtar, og ingen av dei føreset den andre.

Desse kommandoane skriv ut flagga frå ein validerande spurnad, gientek spurnaden med kontrollen deaktivert og køyrer lokal validering med delv:

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

Eit svar med flagget for autentiserte data og ein tilstadesvarande signatur viser validering hos den resolveren. Ein valideringsfeil med delv viser ei broten kjede ein stad mellom sonen og tillitsankeret, noko som er eit publiseringsproblem og ikkje eit tunnelproblem. Ein tidsavbrot heilt utan flagg er eit transport- eller tilgjengeproblem, og å handsame det som ein signaturfeil sender deg til feil lag.

Kva du bør gjere når ein VPN øydelegg oppslag

Viss oppslag fungerte før tunnelen og stoppar etter han, samanlikn resolveren som kvar veg brukar. Deld tunnelering, ein intern resolver som berre er tilgjengeleg gjennom tunnelen, og ein klient som skriv over resolverinnstillingar endrar alle svaret utan å røre DNSSEC.

Å slå av validering globalt er det gale første trekket, fordi det fjernar den einaste mekanismen som rapporterer manipulering, og reparerer ikkje ein resolver som ikkje kan nåast. Avgrens feilen først: oppslag, transport, validering og deretter policy. Berre det tredje høyrer til DNSSEC, og berre det andre høyrer til kryptert transport.