DNS over TLS saman med ein VPN: kva del er verna

DNS over TLS krypterer utvekslinga mellom ein klient og resolveren han valde, og resolveren les framleis namnet. Den setninga gjer slutt på det meste av forvirringa kring DoT saman med ein VPN. Tunnelen avgjer kva veg den krypterte spørjinga tek, medan resolveren framleis får vita kva det vart spurt om. Ingen av mekanismane erstattar den andre, og ingen gjer den andre overflødig.

Fire kontrollar avgjer om oppsettet du har, er det du trur du har.

Kontroll 1: kva krypteringa dekkjer

DoT pakkar DNS-utvekslinga inn i TLS, slik at ein observatør på vegen ser ei tilkopling til ein adresse og port i staden for eit namn i ei spørjing. Resolveren sjølv dekrypterer og svarar. Samanlikn med DNS over HTTPS: begge krypterer, og dei brukar ulike transportar, så eit nettverk som tillèt webtrafikk, tillèt ikkje automatisk ei DoT-tilkopling.

Den skilnaden har noko å seia når ein captive portal eller ei filtrerande mellomkasse tillèt 443 og blokkerer 853. Verktøyet som virka der, er ikkje prov for at det andre vil.

Kontroll 2: kva rute spørjinga tek

Ruta er eit spørsmål om klientpolitikk. Ein DoT-resolver kan ein nå gjennom tunnelen, utanfor han eller via ein veg som endrar seg med nettverket. Kva som skjer, avheng av rutene og av om klienten vernar sin eigen DNS-socket. Ein tunnel som fangar all trafikk, tek som regel spørjinga med seg, uansett kva resolveradressa seier.

Å sjå ei tredjeparts resolveradresse i ein test provar ikkje ei omgåing, og å sjå kryptering provar ikkje den tiltenkte mottakaren. Les resolveren og vegen kvar for seg, og avgjer så om paret er det du designa.

Kontroll 3: interne namn

Ein organisasjon som publiserer interne namn, treng ein resolver som held dei oppføringane. Ei offentleg DoT-teneste kjenner ikkje det private namnerommet ditt, og å peike klienten på ei slik garanterer at dei namna feilar. Dette er den vanlegaste praktiske regresjonen når nokon slår på kryptert DNS på ei administrert eining.

Hald på den interne resolveren for interne suffiks, og krypter det hoppet om politikken krev det, i staden for å byta han ut med ein offentleg leverandør.

Kontroll 4: åtferd ved feil

Ei streng resolverinnstilling utan ein tilgjengeleg resolver gjev ein namneoppslagsfeil medan tunnelen blir ståande. Sjå på plattformmodusen og den dokumenterte fallbacken hans i staden for å røre nøklar eller sertifikat.

Ein fallback som stille brukar vanleg DNS, er ei politisk avgjerd, ikkje ei lettvintheit. Avgjer om feilen skal vere synleg eller skal degraderast til noko veikare, og skriv svaret ned.

Stol på sertifikatet, ikkje på svaret

Bruk vertsnamnet til leverandøren og verifiseringskonfigurasjonen som er dokumentert for tenesta. Å slå av TLS-kontrollar slik at ein ukjend resolver svarar, gjev deg ein kryptert kanal til eit uverifisert endepunkt, noko som er verre enn den vanlege spørjinga han erstatta på ein bestemt måte: det ser trygt ut. Spesifikasjonen for DNS over TLS legg fram autentiseringsforventninga bak den kontrollen.

Eit svar frå ein resolver du ikkje kan autentisere, er ein påstand, ikkje eit resultat.

Kva dette lèt stå uforklart

DoT skjuler ikkje namnet for resolveren, skjuler ikkje destinasjonsadressa til tilkoplinga for nettverket og avgjer ikkje om spørjinga gjekk gjennom tunnelen. Det er tre separate spørsmål med tre separate svar.

Skriv resolveridentiteten, transitvegen og politikken for interne namn ned som tre linjer. Det neste DNS-spørsmålet du får, blir eitt av dei.