Kortversjonen: klassisk DNS (protokollen fra 1987) sender forespørsler i klartekst over UDP port 53. Hvem som helst på nettverksbanen kan lese hvert domene du slår opp, endre svarene eller blokkere bestemte forespørsler. DoT (RFC 7858, 2016) pakker DNS-forespørsler inn i TLS over port 853. DoH (RFC 8484, 2018) plasserer dem inne i HTTPS-forespørsler på port 443. Begge løser klartekstproblemet. De skiller seg når det gjelder hvem som kontrollerer utrullingen, hvem som kan se forespørslene og hvem som kan blokkere dem — og det er det spørsmålet de fleste egentlig stiller når de spør «hvilket bør jeg bruke». Det avhenger av hva du beskytter deg mot.
Hva DNS-kryptering fikser — og hva det ikke fikser
Før vi sammenligner de to er det verdt å avklare hva noen av protokollene faktisk beskytter. Klassisk DNS lekker hvert domenenavn enheten din slår opp. Besøk example.com, og ISP-en din — eller en hvilken som helst nettverksoperatør i banen — kan se forespørselen for example.com, selv før nettleseren sender den første HTTPS-forespørselen. Det faktiske innholdet i HTTPS-forespørselen er kryptert; DNS-oppslaget som kom før er det ikke. Kryptert DNS tetter akkurat det hullet.
Hva det ikke fikser: mål-IP-adressen du kobler til er fremdeles synlig. TLS Server Name Indication (SNI)-feltet, i eldre TLS-versjoner, lekket også vertsnavnet under håndtrykket — men Encrypted Client Hello (ECH) tar hånd om det i TLS 1.3. Kryptert DNS kombinert med ECH tetter de åpenbare lekkasjestedene. Uten ECH tetter kryptert DNS alene én lekkasje, men lar SNI-lekkasjen stå åpen, noe som betyr at destinasjonsvertsnavnet fortsatt er synlig under TLS-håndtrykket. For å si det ærlig: kryptert DNS er nødvendig, men ikke tilstrekkelig.
Slik fungerer DoT — dedikert kanal på port 853
DoT (DNS-over-TLS, definert i RFC 7858) er den konseptuelt enklere løsningen. Enheten din åpner en TCP-forbindelse til DNS-serveren på port 853. Den utfører et TLS-håndtrykk — det samme TLS som beskytter HTTPS — og sender deretter standard DNS-forespørsler inne i den krypterte strømmen. DNS-serveren svarer med standard DNS-svar, også inne i den krypterte strømmen. Sett fra linja ser nettverket bare en TLS-forbindelse til port 853.
Siden port 853 er offisielt tildelt av IANA utelukkende til DoT, er enhver TCP-trafikk på den porten utvetydig DoT. Nettverksoperatører kan identifisere DoT trivielt — de trenger ikke dyp pakkeanalyse, de ser bare på destinasjonsporten. Vil de blokkere DoT, dropper de port 853. Vil de tillate det, men logge destinasjons-IP-en til DNS-serveren, er det også enkelt. DoT er åpen om å være DNS, noe som er en fordel i noen brukstilfeller og en ulempe i andre.
Slik fungerer DoH — DNS skjult inne i nettverkstrafikk
DoH (DNS-over-HTTPS, definert i RFC 8484) tar en annen tilnærming. Enheten din sender DNS-forespørsler som HTTP POST-forespørsler (eller GET-forespørsler med spørreparameter) til en bestemt URL på DNS-leverandørens HTTPS-server. Brødteksten i POST-en inneholder en binær DNS-melding; svarteksten inneholder et binært DNS-svar. Det hele skjer over en vanlig HTTPS-forbindelse på port 443 — den samme porten nettleseren bruker til å laste inn nettsider.
Sett fra nettverkets perspektiv er en DoH-forespørsel ikke til å skille fra en vanlig HTTPS-forespørsel til samme server. Forbindelsen ser ut som nettverkstrafikk. Pakkestørrelsene ser ut som nettverkstrafikk (etter den første forespørselen gjenbruker oppfølgingsforespørsler samme HTTP/2- eller HTTP/3-forbindelse). Destinasjons-IP-en tilhører et generisk utseende endepunkt — Cloudflares 1.1.1.1 eller Googles 8.8.8.8 betjener både DoH og annen nettverkstrafikk på samme IP-adresser. For å blokkere DoH spesifikt må en nettverksoperatør identifisere og blokkere de spesifikke endepunktene, noe som er langt vanskeligere enn å blokkere en port.
Forskjeller i nettverkssynlighet
Transportforskjellen gir en synlighetsforskjell. Med DoT kan nettverksoperatøren din (bedrifts-IT, ISP, skole, hotell) se at du bruker kryptert DNS, kan se hvilken DoT-server du bruker (via destinasjons-IP) og kan velge å blokkere den serveren. Med DoH kan nettverksoperatøren se kryptert HTTPS-trafikk til DNS-leverandørens IP, men med mindre de aktivt vedlikeholder blokkeringslister over DoH-endepunkter kan de ikke skille DoH fra vanlig HTTPS til samme leverandør.
Dette har forutsigbare konsekvenser. Bedrifts-IT-avdelinger foretrakk i stor grad DoT i mange år fordi de kan blokkere det enkelt: dropp port 853, og DNS faller tilbake til organisasjonens resolver, som de overvåker og filtrerer. De misliker gjerne DoH av samme grunn — det omgår synligheten deres. Forbrukerpersonvernforkjempere foretrekker for det meste DoH av akkurat samme grunn. Ulike interessenter ønsker ulike utfall fra den samme arkitektoniske beslutningen.
Hvilken nettverket kan blokkere
DoT er lett å blokkere. Port 853 er det eneste som bruker den porten; én brannmurregel for å droppe den, og det er gjort. Mange bedriftsnettverk gjør allerede dette. Mange filtreringsbrannmurer i restriktive regioner gjør det også. Konfigurerer du en enhet til å bruke DoT og nettverket blokkerer port 853, mislykkes enhetens DNS-forespørsler inntil OS-et eller appen faller tilbake til klartekst-DNS — og de fleste gjør det uten å varsle.
DoH er langt vanskeligere å blokkere fordi den eneste måten å blokkere det på er å identifisere og sette hvert DoH-endepunkt på blokkeringslisten. Cloudflares 1.1.1.1 er det mest kjente og er vanligvis på blokkeringslisten; Googles 8.8.8.8 likeså. Men uavhengig drevne DoH-endepunkter sprer seg — offentlige lister som curls DoH-wiki katalogiserer hundrevis. En nettverksoperatør som ønsker å blokkere DoH globalt må holde den listen oppdatert og akseptere at de alltid vil ligge ett skritt bak nye endepunkter. Noen restriktive nettverk forsøker å detektere DoH via trafikkmonsteranalyse (DoH har karakteristiske forespørsels-størrelse- og tidskarakterstikker), men dette er skjørt og gir falske positiver.
Mozillas DoH-dokumentasjon nevner uttrykkelig denne egenskapen — at DoH er vanskelig for nettverk å blokkere — som et bevisst designmål, ikke en tilfeldighet. Den samme egenskapen gjør DoH kontroversiell i bedriftssammenhenger, der nettverksoperatøren anser DNS-synlighet som en legitim del av sikkerhetsstakken snarere enn et brudd på brukernes personvern.
Konsekvenser for bedrifter og foreldrekontroll
DNS-nivå-filtrering (den typen som driver de fleste programmer for foreldrekontroll, bedrifters «sikker surfing»-filtrering og de enkleste formene for blokkering av skadevaredomener) fungerer ved å avskjære DNS-forespørsler og enten droppe de for blokkerte domener eller returnere falske svar. Vi dekket mekanikken i vår gjennomgang av hvordan DNS-nivå-filtrering faktisk fungerer.
Kryptert DNS omgår dette fullstendig — både DoT og DoH ruter forespørsler til en annen resolver enn det lokale nettverkets, slik at filtrering som brukes på den lokale resolveren blir uten virkning. Fra leverandørens perspektiv for foreldrekontroll er dette et problem. Fra brukerens perspektiv avhenger det helt av om de anser filtreringen som legitim eller invasiv. De fleste bedriftens endepunktadministrasjonsverktøy deaktiverer nå nettleser-DoH via policy og er avhengige av enten DNS-konfigurasjon på OS-nivå eller full trafikkanalyse for å opprettholde synligheten. Apples MDM-administrerte iOS-profiler inkluderer en DoH/DoT-konfigurasjonsmekanisme designet nettopp for dette: bedriften kan spesifisere en kryptert DNS-resolver etter eget valg og hindre brukere i å overstyre den.
For husholdninger er den praktiske virkeligheten at det å slå på DoH i en nettleser omgår all ruterbasert innholdsfiltrering du har satt opp. Det er enten en funksjon eller en feil avhengig av hvilken side av konfigurasjonen du sitter på.
Ytelsesegenskaper
DoT har typisk litt lavere per-forespørselsoverhead enn DoH. Begge protokollene bruker TLS, men DoT sender en mye mindre innpakning rundt hver DNS-melding — det er ingen HTTP-forespørselslinje, ingen overskrifter, ingen Content-Length, ingen HTTP-metode. DNS-meldingen går direkte inn i TLS-strømmen. DoH, derimot, pakker hver DNS-forespørsel inn i en HTTP POST eller GET, noe som legger til titalls til hundrevis av bytes med overhead per forespørsel.
Den overheaden amortiseres for det meste bort ved gjenbruk av forbindelser. Både DoT og DoH holder TLS-forbindelsen åpen på tvers av mange forespørsler, slik at håndtrykkskostnaden betales én gang. DoH på HTTP/2 multiplekser forespørsler på samme forbindelse, og HTTP/3 (over QUIC) reduserer ventetiden ytterligere. I praksis, på et moderne nettverk, gir de to protokollene umulig å skille forsinkelse for brukeren — forskjeller på enkle millisekunder i det høyeste. Velg ikke den ene over den andre av ytelseshensyn; valget handler om synlighet, kontroll og trusselmodell.
DoT vs DoH på ett blikk
| Egenskap | DNS-over-TLS (DoT) | DNS-over-HTTPS (DoH) |
|---|---|---|
| Port | 853 (dedikert) | 443 (delt med HTTPS) |
| RFC | RFC 7858 (2016) | RFC 8484 (2018) |
| Transport | Rå TLS over TCP | HTTPS (HTTP/2 eller HTTP/3) |
| Identifiserbar på linja | Ja — port 853 er unik for DoT | Nei — ser ut som vanlig HTTPS |
| Kan blokkeres av nettverk | Enkelt (dropp port 853) | Vanskelig (krever endepunktblokkeringsliste) |
| Nettleserstøtte | Nei (nettlesere implementerer ikke DoT) | Firefox, Chrome, Edge, Safari støtter det alle |
| OS-støtte | Android 9+, iOS 14+, macOS 11+, Linux (systemd-resolved) | Android 9+, iOS 14+, macOS 11+, Windows 11+ |
| Bedriftssynlighet | Synlig via port; lett å overvåke eller blokkere | Omgår portbasert overvåking; krever endepunktanalyse |
| Per-forespørsels ventetidsoverhead | Lavere (minimal innpakning) | Litt høyere (HTTP-overskrifter); ubetydelig med HTTP/2-multipleksing |
| Sensurresistens | Lav (portblokkbar) | Høyere (port 443 er essensiell for det moderne nettet) |
Hvilket bør du bruke — tre scenarier
«Hvilken protokoll er best» avhenger helt av hva du prøver å oppnå. Her er tre konkrete scenarier med konkrete svar:
Scenario 1: Personlig enhet på fiendtlige eller upålitelige nettverk
Kaffebarer, hoteller, flyplasser, venners Wi-Fi. Trusselmodellen er at den lokale nettverksoperatøren observerer eller endrer DNS-en din. Begge protokoller fungerer for selve krypteringen; DoH er å foretrekke fordi det er langt vanskeligere for et fiendtlig nettverk å blokkere. Bruker du DoT på et nettverk som dropper port 853, faller forespørslene dine stille tilbake til klartekst på port 53 (de fleste OS-klienter feiler åpent på denne måten) — og du har lekket alt du prøvde å beskytte. DoH når nesten alltid frem til endepunktet.
Scenario 2: Hjemmenettverk med administrerte barneenheter
Du vil at barnas enheter skal bruke en filtrerende DNS-resolver (NextDNS, OpenDNS Family Shield, Cloudflare for Families) og du vil at de ikke skal kunne omgå den. DoT er faktisk enklere her — du konfigurerer enheten til å bruke en bestemt DoT-resolver, og barnet kan ikke enkelt veksle om en innstilling i en nettleser for å bruke en annen DNS. Nettleser-DoH kan deaktiveres via bedrifts-/MDM-policy eller ved å sette kanaridomeinet. Valget mellom DoT og DoH betyr mindre enn å konfigurere DNS på enhetsnivå i OS-laget fremfor å la individuelle apper velge.
Scenario 3: Du kjører allerede en VPN
Bruker du en VPN, kan ikke det lokale nettverket se DNS-forespørslene dine uansett — VPN-tunnelen krypterer alt, inkludert DNS. Det relevante spørsmålet blir hvilken DNS-resolver VPN-en bruker internt og om den støtter kryptert DNS til sin oppstrømsresolver. De fleste moderne VPN-er (inkludert Casper's Cloak) bruker kryptert DNS internt og bruker trusselskjermfiltrering ved resolveren før svaret sendes tilbake gjennom tunnelen. I denne konfigurasjonen er DoT vs DoH for det meste et implementeringsdetalj; det som betyr noe er at resolveren ikke er ISP-en din og ikke logger forespørslene dine.
Tillitsspørsmålet som begge protokoller unngår
Både DoT og DoH flytter tillit fra den lokale nettverksoperatøren til den krypterte DNS-leverandøren du velger. Cloudflare, Google, Quad9, NextDNS, ControlD — hvert av disse selskapene ser hver DNS-forespørsel du sender dem. Kryptering til dem betyr ikke personvern fra dem. Er bekymringen din at ISP-en ikke skal se DNS-en din, løser kryptert DNS problemet. Er bekymringen din at ingen tredjepart skal se DNS-en din, hjelper ingen av protokollene; du må kjøre din egen rekursive resolver (som er sitt eget prosjekt).
Hva du kan kreve av resolveren du stoler på: en tydelig loggingspolicy, tredjeparts revisjoner, støtte for forespørselsminimering (slik at de autoritative serverne oppstrøms bare ser de delene av forespørselen de trenger) og DNSSEC-validering. De store offentlige DoH/DoT-leverandørene publiserer alle sine retningslinjer; les dem. Vår dypere guide om dette finner du i vår DoH-gjennomgang for 2026.
Konklusjon
DoT og DoH løser det samme grunnleggende problemet — DNS-klartekst som lekker surfemålene dine til nettverket — med to forskjellige arkitektoniske strategier. DoT er den ærlige løsningen: en dedikert port, lett å identifisere, lett å administrere, lett å blokkere. DoH er den kamuflerte løsningen: skjult i HTTPS-trafikk, vanskelig å identifisere uten endepunktblokkeringslister, vanskelig å blokkere i stor skala.
For forbrukere på fiendtlige nettverk er DoH det riktige valget fordi det er den som faktisk når frem til endepunktet. For bedrifter som trenger DNS-synlighet er DoT det mer samarbeidsvillige valget. For folk som kjører sin egen filtrerende DNS hjemme er DoT mer konfigurerbar og vanskeligere for brukere å omgå på appnivå. For VPN-brukere er valget for det meste usynlig — VPN-klienten håndterer det.
Det virkelige spørsmålet er sjelden «DoT eller DoH» — det er «hvilken resolver stoler jeg på, og hva er dens loggingspolicy». Velg en resolver du stoler på, konfigurer den systemomfattende (ikke per nettleser), og verifiser med en DNS-lekkasjetest at du faktisk har fått konfigurasjonen riktig. Protokollen du bruker til å snakke med den betyr mindre enn policyen til entiteten i den andre enden.