DNS over TLS plus en VPN: hvilken del er beskyttet

DNS over TLS krypterer udvekslingen mellem en klient og den resolver, den valgte, og resolveren læser stadig navnet. Den sætning afklarer det meste af forvirringen omkring DoT plus en VPN. Tunnelen afgør, hvilken vej den krypterede forespørgsel tager, mens resolveren stadig får at vide, hvad der blev spurgt om. Ingen af mekanismerne erstatter den anden, og ingen gør den anden overflødig.

Fire kontroller afgør, om den ordning, du har, er den, du tror, du har.

Kontrol 1: hvad krypteringen dækker

DoT pakker DNS-udvekslingen ind i TLS, så en observatør på vejen ser en forbindelse til en adresse og port i stedet for et navn i en forespørgsel. Resolveren selv dekrypterer og svarer. Sammenlign med DNS over HTTPS: begge krypterer, og de bruger forskellige transportmidler, så et netværk, der tillader webtrafik, tillader ikke automatisk en DoT-forbindelse.

Den forskel betyder noget, når en captive portal eller en filtrerende mellemboks tillader 443 og blokerer 853. Det værktøj, der virkede der, er ikke bevis for, at det andet vil.

Kontrol 2: hvilken rute forespørgslen tager

Ruten er et spørgsmål om klientpolitik. En DoT-resolver kan nås gennem tunnelen, uden for den eller ad en vej, der ændrer sig med netværket. Hvilken der sker, afhænger af ruter og af, om klienten beskytter sin egen DNS-socket. En tunnel, der fanger al trafik, tager som regel forespørgslen med sig, uanset hvad resolveradressen siger.

At se en tredjeparts resolveradresse i en test beviser ikke en omgåelse, og at se kryptering beviser ikke den tilsigtede modtager. Læs resolveren og vejen hver for sig, og afgør så, om parret er det, du designede.

Kontrol 3: interne navne

En organisation, der offentliggør interne navne, har brug for en resolver, der holder de poster. En offentlig DoT-tjeneste kender ikke dit private navnerum, og at pege klienten på en garanterer, at de navne fejler. Det er den mest almindelige praktiske regression, når nogen aktiverer krypteret DNS på en administreret enhed.

Behold den interne resolver til interne suffikser, og krypter det spring, hvis politikken kræver det, i stedet for at erstatte den med en offentlig udbyder.

Kontrol 4: opførsel ved fejl

En streng resolverindstilling uden en tilgængelig resolver giver en navneopløsningsfejl, mens tunnelen bliver oppe. Se på platformstilstanden og dens dokumenterede fallback i stedet for at røre ved nøgler eller certifikater.

En fallback, der stille bruger almindelig DNS, er en politisk beslutning, ikke en bekvemmelighed. Beslut, om fejlen skal være synlig, eller om den skal degraderes til noget svagere, og skriv svaret ned.

Stol på certifikatet, ikke på svaret

Brug udbyderens værtsnavn og den verifikationskonfiguration, der er dokumenteret for tjenesten. At slå TLS-kontroller fra, så en ukendt resolver svarer, giver dig en krypteret kanal til et uverificeret endepunkt, hvilket er værre end den almindelige forespørgsel, den erstattede, på én bestemt måde: det ser sikkert ud. Specifikationen for DNS over TLS redegør for den autentificeringsforventning, der ligger bag den kontrol.

Et svar fra en resolver, du ikke kan autentificere, er en påstand, ikke et resultat.

Hvad det her lader uforklaret

DoT skjuler ikke navnet for resolveren, skjuler ikke forbindelsens destinationsadresse for netværket og afgør ikke, om forespørgslen gik gennem tunnelen. Det er tre separate spørgsmål med tre separate svar.

Skriv resolveridentiteten, transitvejen og den interne navnepolitik ned som tre linjer. Det næste DNS-spørgsmål, du får, bliver et af dem.