DNS over TLS pluss en VPN: hvilken del er beskyttet

DNS over TLS krypterer utvekslingen mellom en klient og resolveren den valgte, og resolveren leser fortsatt navnet. Den setningen avgjør det meste av forvirringen rundt DoT pluss en VPN. Tunnelen bestemmer hvilken vei den krypterte spørringen tar, mens resolveren fortsatt får vite hva som ble spurt om. Ingen av mekanismene erstatter den andre, og ingen gjør den andre overflødig.

Fire kontroller avgjør om oppsettet du har, er det du tror du har.

Kontroll 1: hva krypteringen dekker

DoT pakker DNS-utvekslingen inn i TLS, slik at en observatør på veien ser en forbindelse til en adresse og port i stedet for et navn i en spørring. Resolveren selv dekrypterer og svarer. Sammenlign med DNS over HTTPS: begge krypterer, og de bruker ulike transporter, så et nettverk som tillater webtrafikk, tillater ikke automatisk en DoT-forbindelse.

Den forskjellen betyr noe når en captive portal eller en filtrerende mellomkasse tillater 443 og blokkerer 853. Verktøyet som virket der, er ikke bevis for at det andre vil.

Kontroll 2: hvilken rute spørringen tar

Ruten er et spørsmål om klientpolicy. En DoT-resolver kan nås gjennom tunnelen, utenfor den eller via en vei som endrer seg med nettverket. Hvilken som skjer, avhenger av rutene og av om klienten beskytter sin egen DNS-socket. En tunnel som fanger all trafikk, tar som regel spørringen med seg, uansett hva resolveradressen sier.

Å se en tredjeparts resolveradresse i en test beviser ikke en omgåelse, og å se kryptering beviser ikke den tiltenkte mottakeren. Les resolveren og veien hver for seg, og avgjør så om paret er det du designet.

Kontroll 3: interne navn

En organisasjon som publiserer interne navn, trenger en resolver som holder de oppføringene. En offentlig DoT-tjeneste kjenner ikke ditt private navnerom, og å peke klienten på en slik garanterer at de navnene feiler. Dette er den vanligste praktiske regresjonen når noen slår på kryptert DNS på en administrert enhet.

Behold den interne resolveren for interne suffikser, og krypter det hoppet hvis policyen krever det, i stedet for å erstatte den med en offentlig leverandør.

Kontroll 4: oppførsel ved feil

En streng resolverinnstilling uten en tilgjengelig resolver gir en navneoppslagsfeil mens tunnelen blir stående. Se på plattformmodusen og dens dokumenterte fallback i stedet for å røre nøkler eller sertifikater.

En fallback som stille bruker vanlig DNS, er en policybeslutning, ikke en bekvemmelighet. Bestem om feilen skal være synlig eller skal degraderes til noe svakere, og skriv svaret ned.

Stol på sertifikatet, ikke på svaret

Bruk leverandørens vertsnavn og verifiseringskonfigurasjonen som er dokumentert for tjenesten. Å slå av TLS-kontroller slik at en ukjent resolver svarer, gir deg en kryptert kanal til et uverifisert endepunkt, noe som er verre enn den vanlige spørringen den erstattet på én bestemt måte: det ser trygt ut. Spesifikasjonen for DNS over TLS legger frem autentiseringsforventningen bak den kontrollen.

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

Hva dette lar stå uforklart

DoT skjuler ikke navnet for resolveren, skjuler ikke forbindelsens destinasjonsadresse for nettverket og avgjør ikke om spørringen gikk gjennom tunnelen. Det er tre separate spørsmål med tre separate svar.

Skriv resolveridentiteten, transitveien og policyen for interne navn ned som tre linjer. Det neste DNS-spørsmålet du får, blir ett av dem.