DNS-over-TLS mot DNS-over-HTTPS – velg etter tillit og drift

DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH) krypterer DNS-meldinger mellom en klient og en rekursiv resolver. De løser samme transportproblem med ulike protokoller.

Valget handler mindre om hvilket akronym som er «sikrest», og mer om:

• hvilken resolver dere stoler på
• hvordan resolveren autentiseres
• om klienten faller tilbake til ukryptert DNS
• hvor policyen håndheves
• om interne navn og sikkerhetsfiltre må fungere
• hvem som kan drifte og overvåke løsningen

Kort sammenligning

DoT og DoH kan bruke like sterk TLS. Portnummeret avgjør ikke i seg selv konfidensialitet eller autentisering.

Hva krypteringen beskytter

Uten kryptert resolvertransport kan en aktør på samme nett eller på veien til resolveren lese eller endre vanlige DNS-spørsmål og svar.

DoT og DoH kan beskytte mot:

• passiv avlytting av DNS-meldingen mellom klient og resolver
• enkel manipulering på denne transportveien
• synliggjøring av hele DNS-svaret for lokale mellomledd

Beskyttelsen forutsetter at klienten autentiserer riktig resolver og ikke faller stille tilbake til klartekst når kryptering feiler.

Hva de ikke skjuler

Resolveren ser normalt:

• DNS-navnet klienten spør etter
• svaret som returneres
• klientens IP-adresse eller en nettverksidentitet
• tidspunkt og mønster for spørsmålene

En nettverksobservatør kan fortsatt se IP-adressen til DoT- eller DoH-tjenesten, mengde og tidspunkt for trafikk. Senere forbindelser til nettstedets IP-adresser kan også avsløre mye. DNS-prefetch, e-postklienter, apper og bakgrunnstjenester kan gjøre oppslag uten at brukeren besøker et nettsted.

Et DNS-spørsmål er derfor ikke alltid bevis på et besøk, og kryptert DNS er ikke anonymitet.

Hvor tilliten flyttes

Kryptering gjør ikke resolveren mindre sentral. Hvis enheten tidligere brukte bedriftens eller internettleverandørens resolver og nå bruker en global DoH-tjeneste, flyttes innsikten og kontrollen til den nye operatøren.

Vurder resolverens:

• identitet og jurisdiksjon
• logg- og slettingspolicy
• bruk av data til drift, sikkerhet eller analyse
• støtte for DNSSEC-validering
• filtrering eller omskriving av svar
• tilgjengelighet og hendelseshistorikk
• dokumentasjon av DoT/DoH-endepunkt og autentiseringsnavn

RFC 8932 gir anbefalinger til resolveroperatører om personvern, sikkerhet og drift. Les operatørens faktiske policy, ikke bare at tjenesten bruker kryptering.

DoT er en tydelig DNS-kanal

RFC 7858 angir port 853 som standard for DNS over TLS. Klienten oppretter TLS-forbindelse og sender DNS-meldinger over den.

Den dedikerte porten gjør det lettere å:

• tillate bare godkjente resolvere i nettverksbrannmur
• blokkere direkte DoT som omgår en administrert lokal resolver
• skille DNS-transport fra vanlig webtrafikk
• overvåke tilgjengelighet uten å lese spørsmålene

Det gjør også DoT enklere å blokkere i nettverk som ikke tillater port 853. En klient med opportunistisk fallback kan da gå over til ukryptert DNS hvis policyen tillater det.

DoH bruker HTTP-infrastruktur

RFC 8484 definerer DNS-meldinger over HTTPS. DoH kan bruke POST eller GET og vanlig HTTP-cache etter standardens regler.

Port 443 gir:

• bred gjennomtrengning i nettverk som tillater HTTPS
• gjenbruk av HTTP/2-, HTTP/3-, proxy- og autentiseringsinfrastruktur
• mulighet for nettleser eller app til å velge egen resolver

Det gjør samtidig policy mer krevende. Trafikken deler port med vanlig HTTPS, men er ikke nødvendigvis «usynlig». Destinasjons-IP, resolverdomene, TLS-metadata, applikasjonspolicy og endepunktlister kan fortsatt gi nettverket styringsmuligheter.

Blokkering av all ukjent HTTPS er ikke en rimelig DoH-strategi. Bedrifter bør administrere resolvervalg på enhetene, tilby en godkjent kryptert tjeneste og følge plattformenes policyfunksjoner.

Streng eller opportunistisk personvernprofil

Transporttypen sier ikke hva klienten gjør når TLS eller resolveren feiler.

RFC 8310 skiller mellom:

En kryptert forbindelse uten riktig autentisering kan koble klienten til feil resolver. En fallback til port 53 kan gjøre at en blokkering av DoT/DoH fjerner hele personverngevinsten uten tydelig varsel.

Bestem derfor eksplisitt:

• skal DNS feile lukket eller falle tilbake
• hvilke resolvere er godkjent som reserve
• hvordan brukeren og driften varsles ved nedgradering
• hvordan captive portal og nødsituasjoner håndteres

Nettleser, operativsystem og ruter kan velge ulikt

En enhet kan ha flere resolverlag:

1. Nettleseren kan bruke egen DoH.
2. Operativsystemet kan bruke DoH eller DoT for alle apper.
3. VPN-klienten kan sette en bedriftsresolver.
4. Ruteren kan videresende til en kryptert upstream.
5. En app kan ha innebygd resolver.

Hvis disse lagene ikke er samordnet, kan dig, nettleseren og e-postklienten få ulike svar.

For privat bruk gir OS- eller ruterbasert kryptering ofte mer helhetlig dekning enn én nettleserinnstilling. I et bedriftsmiljø bør resolverpolicyen styres sentralt og testes for alle relevante apper.

Intern DNS og split-horizon må bevares

Bedrifter bruker ofte interne navn eller ulike svar avhengig av nettverk. En nettleser som sender alt til en ekstern DoH-resolver kan:

• ikke finne interne tjenester
• få offentlig i stedet for intern adresse
• omgå sikkerhetsfiltrering
• bryte VPN-basert tjenesteoppdagelse
• gi uforutsigbar support fordi bare én app feiler

En god utrulling støtter split DNS: interne soner går til riktig bedriftsresolver, mens offentlige spørsmål følger avtalt policy. Ikke publiser interne adresser offentlig for å gjøre ekstern DoH «kompatibel».

Sikkerhetsfiltrering og hendelsesrespons

DNS-filtrering kan blokkere kjente skadevarer og gi signaler til hendelsesrespons. Kryptering er kompatibelt med slik filtrering hvis klientene bruker en godkjent resolver som utfører policyen.

Problemet oppstår når en app velger en annen resolver utenfor bedriftens kontroll. Løsningen er ikke å deaktivere personvern for alle, men å:

• tilby administrert DoT eller DoH
• styre resolvervalg med enhets- og nettleserpolicy
• blokkere kjente uautoriserte resolvere etter risikovurdering
• overvåke policybrudd uten å samle mer data enn nødvendig
• dokumentere unntak for feilsøking og spesialsystemer

DNS-logger inneholder potensielt følsomme data. Begrens tilgang, formål og lagringstid.

DNSSEC løser en annen del

DoT og DoH beskytter transporten fra klient til resolver. DNSSEC lar en validerende resolver kontrollere at signerte DNS-data ikke er endret i kjeden fra autoritativ kilde.

En vanlig modell er:

klient -- DoT/DoH --> validerende resolver -- DNSSEC-kontroll --> autoritativ DNS

DoT/DoH uten DNSSEC-validering betyr at klienten fortsatt stoler på resolverens svar. DNSSEC uten kryptert transport skjuler ikke spørsmålene mellom klient og resolver. De kan brukes sammen.

Les DNSSEC forklart for signaturkjeden.

Oblivious DoH reduserer resolverens klientinnsikt

Vanlig DoH lar resolveren se både klient og spørsmål. RFC 9230 beskriver ODoH med en proxy og et separat target:

• proxyen ser klienten, men ikke DNS-spørsmålet i klartekst
• target ser spørsmålet, men normalt bare proxyen som kilde
• modellen forutsetter at proxy og target ikke samarbeider om å koble data

ODoH er mer komplekst og gir ikke generell anonymitet eller vern mot all trafikkanalyse. Det illustrerer likevel hvorfor «DoH skjuler spørsmålet for resolveren» er feil for vanlig DoH.

Slik velger dere

Hjem og små miljøer

Velg en pålitelig resolver med tydelig policy. Bruk OS- eller ruternivå hvis hele enheten skal dekkes. Kontroller om oppsettet er strict eller faller tilbake.

Administrert bedriftsnett

Bruk en sentralt styrt resolver som kan håndtere interne soner, DNSSEC og sikkerhetspolicy. DoT er lett å skille i nettverket. DoH kan være riktig når endepunktene administreres og HTTP-infrastrukturen er ønsket. Begge krever enhetsstyring.

Mobile og skiftende nettverk

DoH over 443 kan passere flere nettverk, mens DoT på 853 kan blokkeres. Test captive portals, VPN, mobilnett og Wi-Fi. Ikke anta at tilgjengelig transport automatisk har riktig intern DNS.

Apper med egen resolver

Dokumenter hvorfor appen trenger en egen resolver, hvordan den følger virksomhetens policy, og hva som skjer når tjenesten er utilgjengelig. Unngå skjult fallback.

En trygg utrullingsplan

1. Kartlegg dagens resolvere for nettleser, OS, VPN, ruter og apper.
2. Definer trusselmodell, personvernmål og krav til intern DNS.
3. Velg resolveroperatør og autentiseringsnavn etter dokumentert policy.
4. Bestem strict eller opportunistisk fallback.
5. Konfigurer en liten testgruppe sentralt.
6. Test offentlige navn, interne soner, DNSSEC, filtrering og captive portal.
7. Verifiser hvilken resolver hver apptype faktisk bruker.
8. Mål oppslagstid, feil, fallback og supporthendelser.
9. Rull ut trinnvis med rask rollback.
10. Revider loggtilgang, datalagring og uautoriserte resolverveier.

Hva en test må bevise

Et vanlig dig-oppslag beviser ikke DoT eller DoH med mindre verktøyet går gjennom den konfigurerte krypterte klienten.

Kontroller:

• TLS-sertifikat og autentiseringsnavn for resolveren
• faktisk transportprotokoll og port
• om klartekst port 53 brukes ved feil
• resolveridentitet for hver apptype
• interne og offentlige svar
• DNSSEC-validering
• oppførsel når primær resolver stoppes
• varsling ved fallback eller blokkering

Bruk operativsystemets, nettleserens eller den lokale resolverens diagnostikk og logger. Vær forsiktig med offentlige «DNS leak tests»: de blir selv en tredjepart som mottar testdata.

Vanlige feil

Dette påvirker ikke domenets autoritative oppsett direkte

DoT og DoH er normalt mellom sluttklient og rekursiv resolver. A, MX, TXT, DNSSEC og navnetjenere for bedrift.no konfigureres fortsatt hos den autoritative DNS-leverandøren.

Vymo tilbyr ikke en offentlig DoT- eller DoH-resolver i standardleveransen. Vi setter opp domene og den enkle bedriftsnettsiden, men valget av resolver på kundens enheter og bedriftsnett er kundens IT-ansvar. Ved DNS-feilsøking bør dere oppgi hvilken resolver og klient som gir feil, men aldri sende passord, API-nøkler eller private DNSSEC-nøkler via kontaktsiden .

DoT og DoH beskytter samme strekning. Den beste løsningen er den som autentiserer riktig resolver, håndterer fallback ærlig, bevarer intern DNS og kan styres på alle enhetene som faktisk gjør oppslag.