DNSSEC eller VPN: hvilken skjuler DNS-spørringene dine?

To mekanismer får æren for den samme oppgaven, og ingen av dem utfører den. DNSSEC svarer på om dataene du mottok virkelig kom fra sonen som publiserer dem, og en VPN avgjør hvilken vei pakkene dine tar. Ingen av dem skjuler i alle tilfeller navnet du spurte om, og innstillingene som ser ut som de burde gjøre det, handler vanligvis om transport eller ruting og ikke om validering. Hvis du navngir laget først, blir et vagt personvernspørsmål til et konkret spørsmål.

Tre påstander som smelter sammen til én

Autentisitet er påstanden om at svaret er det sonen publiserte, og at det ikke ble endret underveis. Konfidensialitet er påstanden om at ingen på veien kan lese spørringen eller svaret. Ruting er påstanden om at pakkene følger en vei du valgte, og det er nettopp det en tunnel gir.

DNSSEC behandler den første og sier ingenting om de to andre. DoT og DoH behandler den andre for hoppet til resolveren. En VPN behandler den tredje og kan også påvirke den andre, men bare som en bivirkning av hvor trafikken går.

Applikasjonstrafikk er et fjerde tilfelle: HTTPS beskytter og autentiserer nettutvekslingen mellom klienten din og nettstedet, og ingen DNS-laget erstatter det.

Hva signaturvalidering kan og ikke kan

En validerende resolver kontrollerer signaturkjeden fra sonen opp til et konfigurert tillitsanker, og returnerer deretter et svar med flagget for autentiserte data satt når kontrollen lykkes. Det flagget er bevis om dataene, ikke om forbindelsen eller destinasjonens hensikter.

Det kan ikke hindre en legitim soneeier i å publisere autentiske oppføringer for en tjeneste du ikke bør stole på. Et korrekt signert svar fra et kompromittert domene er fortsatt korrekt signert, og DNSSEC har ingen mening om hvorvidt det domenet fortjener påloggingsinformasjonen din.

Det skjuler heller ingenting. Spørringen og svaret krysser nettverket i en form som en resolver og enhver observatør på den veien kan lese, med mindre et annet lag beskytter transporten. Et signert svar og et privat svar er forskjellige egenskaper, og en utrulling kan ha hver av dem alene. Test begge hvis en av dem betyr noe for deg.

Hvor konfidensialiteten faktisk kommer fra

Kryptert resolvertransport pakker DNS-utvekslingen inn i TLS, så resolveren ser fortsatt spørsmålet, men veien mellom deg og den ikke. Det flytter tillit i stedet for å fjerne den: du stoler mer på resolveren og mindre på det lokale nettverket.

En VPN kan føre spørringer til en resolver på den andre siden, noe som endrer både veien og resolveren som ser dem. Det er en rutingsbeslutning med en personvernkonsekvens, og på et administrert nettverk kan den interne resolveren være den eneste som kan svare på interne navn.

Kombinasjonen folk faktisk vil ha, er vanligvis tre ting på en gang: validering på, kryptert transport til en resolver de valgte, og applikasjons-TLS på destinasjonen. Hver er uavhengig, og hopper du over én, etterlates et annet hull.

Kontroller validering og transport hver for seg

To tester løser det meste av forvirringen. Den første spør om resolveren validerte svaret; den andre spør om transporten var beskyttet. De feiler på ulike måter, og ingen av dem forutsetter den andre.

Disse kommandoene skriver ut flaggene fra en validerende spørring, gjentar spørringen med kontroll deaktivert og kjører lokal validering med delv:

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

Et svar med flagget for autentiserte data og en tilstedeværende signatur viser validering hos den resolveren. En valideringsfeil med delv viser en brutt kjede et sted mellom sonen og tillitsankeret, noe som er et publiseringsproblem og ikke et tunnelproblem. En tidsavbrudd helt uten flagg er et transport- eller tilgjengelighetsproblem, og å behandle det som en signaturfeil sender deg til feil lag.

Hva du bør gjøre når en VPN ødelegger oppslag

Hvis oppslag fungerte før tunnelen og stopper etter den, sammenlign resolveren som hver vei bruker. Delt tunnellering, en intern resolver som bare er tilgjengelig gjennom tunnelen, og en klient som overskriver resolverinnstillinger endrer alle svaret uten å røre DNSSEC.

Å slå av validering globalt er det gale første trekket, fordi det fjerner den eneste mekanismen som rapporterer manipulering, og ikke reparerer en resolver som ikke kan nås. Begrens feilen først: oppslag, transport, validering og deretter policy. Bare det tredje hører til DNSSEC, og bare det andre hører til kryptert transport.