Kortversionen: klassisk DNS (protokollet från 1987) skickar förfrågningar i klartext över UDP port 53. Vem som helst längs nätvägen kan läsa varje domän du slår upp, modifiera svaren eller blockera specifika förfrågningar. DoT (RFC 7858, 2016) lindar in DNS-förfrågningar i TLS över port 853. DoH (RFC 8484, 2018) lägger dem inuti HTTPS-förfrågningar på port 443. Båda löser klartext-problemet. De skiljer sig åt i vem som styr driftsättningen, vem som kan se förfrågningarna och vem som kan blockera dem — och det är den frågan de flesta egentligen ställer när de undrar "vilket ska jag använda." Det beror på vad du skyddar dig mot.
Vad DNS-kryptering löser — och vad det inte löser
Innan vi jämför de två är det värt att klargöra exakt vad något av protokollen faktiskt skyddar. Klassisk DNS läcker varje domännamn din enhet slår upp. Besöker du example.com kan din ISP — eller vilken nätverksoperatör som helst längs vägen — se förfrågan om example.com, redan innan din webbläsare skickar den första HTTPS-förfrågan. Själva innehållet i den HTTPS-förfrågan är krypterat; DNS-sökningen som föregick den är det inte. Krypterad DNS täpper till just den luckan.
Vad det inte löser: mål-IP-adressen du ansluter till är fortfarande synlig. TLS Server Name Indication (SNI)-fältet läckte i äldre TLS-versioner även ut värdnamnet under handskakningen — men Encrypted Client Hello (ECH) åtgärdar det i TLS 1.3. Krypterad DNS plus ECH täpper till de uppenbara läckorna. Utan ECH täpper krypterad DNS ensam till ett läckage men lämnar SNI-läckan öppen, vilket innebär att destinations-värdnamnet fortfarande syns under TLS-handskakningen. Det ärliga perspektivet: krypterad DNS är nödvändigt men inte tillräckligt.
Hur DoT fungerar — dedikerad kanal på port 853
DoT (DNS-over-TLS, definierat i RFC 7858) är den konceptuellt enklare designen. Din enhet öppnar en TCP-anslutning till DNS-servern på port 853. Den utför en TLS-handskakningsdansen — samma TLS som skyddar HTTPS — och skickar sedan vanliga DNS-förfrågningar i den krypterade dataströmmen. DNS-servern svarar med vanliga DNS-svar, också i den krypterade dataströmmen. Ur nätverkets synvinkel ser man bara en TLS-anslutning till port 853.
Eftersom port 853 är officiellt tilldelad av IANA uteslutande för DoT är all TCP-trafik på den porten otvetydigt DoT. Nätverksoperatörer kan identifiera DoT helt trivialt — de behöver ingen djup paketinspektion, de tittar bara på destinationsporten. Vill de blockera DoT släpper de port 853. Vill de tillåta det men logga DNS-serverns mål-IP är det också enkelt. DoT är öppenhjärtig med att det är DNS, vilket är en fördel i vissa fall och en nackdel i andra.
Hur DoH fungerar — DNS dold i webbtrafik
DoH (DNS-over-HTTPS, definierat i RFC 8484) tar en annan approach. Din enhet skickar DNS-förfrågningar som HTTP POST-förfrågningar (eller GET-förfrågningar med frågeparametern) till en specifik URL på DNS-leverantörens HTTPS-server. Innehållet i POST:en innehåller ett binärt DNS-meddelande; svarsinnehållet innehåller ett binärt DNS-svar. Allt sker via en vanlig HTTPS-anslutning på port 443 — samma port din webbläsare använder för att ladda webbsidor.
Ur nätverkets perspektiv är en DoH-förfrågan omöjlig att skilja från en vanlig HTTPS-förfrågan till samma server. Anslutningen ser ut som webbtrafik. Paketstorlekarna ser ut som webbtrafik (efter den inledande förfrågan återanvänder uppföljningsförfrågningar samma HTTP/2- eller HTTP/3-anslutning). Destinations-IP:n tillhör en generiskt utseende slutpunkt — Cloudflares 1.1.1.1 eller Googles 8.8.8.8 hanterar både DoH och annan webbtrafik på samma IP-adresser. För att blockera DoH specifikt måste en nätverksoperatör identifiera och blockera de specifika slutpunkterna, vilket är betydligt svårare än att blockera en port.
Skillnader i nätverkssynlighet
Transportskillnaden ger en synlighetssskillnad. Med DoT kan din nätverksoperatör (företags-IT, ISP, skola, hotell) se att du använder krypterad DNS, se vilken DoT-server du använder (via mål-IP) och välja att blockera den servern. Med DoH kan nätverksoperatören se krypterad HTTPS-trafik till DNS-leverantörens IP, men om de inte specifikt underhåller blocklister över DoH-slutpunkter kan de inte skilja DoH från vanlig HTTPS till samma leverantör.
Det här får förutsägbara konsekvenser. Företags-IT-avdelningar föredrog länge DoT eftersom de kan blockera det rent: stäng port 853 och DNS faller tillbaka på organisationens resolver, som de övervakar och filtrerar. De ogillar DoH av samma anledning — det kringgår deras synlighet. Konsumentintegritetförespråkare föredrar av samma skäl mestadels DoH. Olika intressenter vill ha olika utfall av samma arkitektoniska beslut.
Vilket nätverk kan blockera
DoT är enkelt att blockera. Port 853 är den enda porten som använder just den porten; en brandväggsregel som stänger den är allt som krävs. Många företagsnätverk gör redan det. Många filtrerande brandväggar i restriktiva regioner också. Om du konfigurerar en enhet att använda DoT och nätverket blockerar port 853 misslyckas enhetens DNS-förfrågningar tills operativsystemet eller appen faller tillbaka till klartext-DNS — och de flesta gör det utan att märka det.
DoH är mycket svårare att blockera eftersom det enda sättet att blockera det är att identifiera och blocklista varje DoH-slutpunkt. Cloudflares 1.1.1.1 är den mest välkända och finns vanligtvis på blocklistan; Googles 8.8.8.8 likaså. Men oberoende drivna DoH-slutpunkter sprider sig — publika listor som curls DoH-wiki katalogiserar hundratals. En nätverksoperatör som vill blockera DoH globalt måste hålla den listan aktuell och acceptera att de alltid kommer att ligga ett steg efter nya slutpunkter. En del restriktiva nätverk försöker detektera DoH via trafikmönsteranalys (DoH har karakteristiska förfrågningsstorlekar och tidsmönster), men detta är bräckligt och ger falska positiva.
Mozillas DoH-dokumentation nämner explicit denna egenskap — att DoH är svårt för nätverk att blockera — som ett medvetet designmål, inte en tillfällighet. Samma egenskap gör DoH kontroversiellt i företagsmiljöer, där nätverksoperatören betraktar DNS-synlighet som en legitim del av sin säkerhetsstack snarare än en kränkning av användarnas integritet.
Konsekvenser för företag och föräldrakontroller
DNS-nivåfiltrering (den typ som driver de flesta föräldrakontrollprogram, företagens "säker surfning"-filtrering och de enklaste formerna av blockering av skadliga domäner) fungerar genom att fånga upp DNS-förfrågningar och antingen kassera dem för blockerade domäner eller returnera falska svar. Vi gick igenom mekaniken i vår artikel om hur DNS-nivåfiltrering faktiskt fungerar.
Krypterad DNS kringgår detta helt — både DoT och DoH skickar förfrågningar till en annan resolver än det lokala nätverkets, så all filtrering som tillämpas på den lokala resolvern är meningslös. Ur föräldrakontrollleverantörens perspektiv är detta ett problem. Ur användarens perspektiv beror det helt på om de betraktar filtreringen som legitim eller inkräktande. De flesta företagets endpoint-hanteringsverktyg inaktiverar nu webbläsar-DoH via policy och förlitar sig antingen på DNS-konfiguration på OS-nivå eller fullständig trafikinspektion för att behålla synligheten. Apples MDM-hanterade iOS-profiler inkluderar en DoH/DoT-konfigurationsmekanism utformad just för detta: företaget kan ange en krypterad DNS-resolver efter eget val och hindra användare från att åsidosätta den.
För hushåll är den praktiska verkligheten att aktivera DoH i en webbläsare kringgår eventuell routerbaserad innehållsfiltrering du har konfigurerat. Det är antingen en funktion eller ett fel beroende på vilken sida av konfigurationen du befinner dig på.
Prestandaegenskaper
DoT har vanligtvis något lägre overhead per förfrågan än DoH. Båda protokollen använder TLS, men DoT skickar ett mycket mindre omslag runt varje DNS-meddelande — det finns ingen HTTP-förfrågningsrad, inga headers, ingen Content-Length, ingen HTTP-metod. DNS-meddelandet går direkt in i TLS-dataströmmen. DoH däremot lindar varje DNS-förfrågan i ett HTTP POST eller GET, vilket lägger till tiotals till hundratals bytes overhead per förfrågan.
Den overheaden amorteras till stor del bort via återanvändning av anslutningar. Både DoT och DoH håller TLS-anslutningen öppen över många förfrågningar, så handskakningen betalar man bara en gång. DoH på HTTP/2 multiplexar förfrågningar på samma anslutning, och HTTP/3 (över QUIC) minskar latensen ytterligare. I praktiken, på ett modernt nätverk, ger de två protokollen omätbara latenskillnader för användaren — enstaka millisekunder som mest. Välj inte det ena framför det andra av prestandaskäl; valet handlar om synlighet, kontroll och hotmodell.
DoT vs DoH i korthet
| Egenskap | DNS-over-TLS (DoT) | DNS-over-HTTPS (DoH) |
|---|---|---|
| Port | 853 (dedikerad) | 443 (delad med HTTPS) |
| RFC | RFC 7858 (2016) | RFC 8484 (2018) |
| Transport | Raw TLS över TCP | HTTPS (HTTP/2 eller HTTP/3) |
| Identifierbar på nätverksnivå | Ja — port 853 är unik för DoT | Nej — ser ut som vanlig HTTPS |
| Blockerbarhet av nätverk | Enkelt (stäng port 853) | Svårt (kräver blocklista över slutpunkter) |
| Webbläsarstöd | Nej (webbläsare implementerar inte DoT) | Firefox, Chrome, Edge, Safari stöder alla det |
| OS-stöd | Android 9+, iOS 14+, macOS 11+, Linux (systemd-resolved) | Android 9+, iOS 14+, macOS 11+, Windows 11+ |
| Synlighet för företag | Synlig via port; enkel att övervaka eller blockera | Kringgår portbaserad övervakning; kräver slutpunktsinspektion |
| Latensoverhead per förfrågan | Lägre (minimalt omslag) | Något högre (HTTP-headers); försumbar med HTTP/2-multiplexering |
| Censurresistens | Låg (blockeras via port) | Högre (port 443 är essentiell för den moderna webben) |
Vilket ska du använda — tre scenarier
"Vilket protokoll är bättre" beror helt på vad du försöker uppnå. Här är tre konkreta scenarier med konkreta svar:
Scenario 1: Personlig enhet på fientliga eller opålitliga nätverk
Kaféer, hotell, flygplatser, kompisens Wi-Fi. Hotmodellen är att den lokala nätverksoperatören observerar eller modifierar din DNS. Båda protokollen fungerar för själva krypteringen; DoH är att föredra eftersom det är mycket svårare för ett fientligt nätverk att blockera. Använder du DoT på ett nätverk som stänger port 853 faller dina förfrågningar tyst tillbaka till klartext på port 53 (de flesta OS-klienter misslyckas öppet på detta sätt) — och du har läckt allt du försökte skydda. DoH når nästan alltid sin slutpunkt.
Scenario 2: Hemnätverk med hanterade barns enheter
Du vill att barnens enheter ska använda en filtrerande DNS-resolver (NextDNS, OpenDNS Family Shield, Cloudflare for Families) och du vill att de inte ska kunna kringgå den. DoT är faktiskt enklare här — du konfigurerar enheten att använda en specifik DoT-resolver och barnet kan inte trivialt ändra en inställning i en webbläsare för att använda en annan DNS. Webbläsar-DoH kan inaktiveras via enterprise/MDM-policy eller genom att ange canary-domänen. Valet mellan DoT och DoH spelar mindre roll än att konfigurera DNS på enhetsnivå i OS-lagret snarare än att låta enskilda appar välja.
Scenario 3: Du kör redan ett VPN
Använder du ett VPN kan det lokala nätverket inte se dina DNS-förfrågningar oavsett — VPN-tunneln krypterar allt, inklusive DNS. Den relevanta frågan blir vilken DNS-resolver VPN:et använder internt och om det stöder krypterad DNS till sin uppströmsresolver. De flesta moderna VPN:er (inklusive Casper's Cloak) använder krypterad DNS internt och tillämpar threat shield-filtrering på resolvern innan svaret skickas tillbaka genom tunneln. I den konfigurationen är DoT vs DoH mestadels en implementationsdetalj; det som spelar roll är att resolvern inte är din ISP och inte loggar dina förfrågningar.
Förtroende-frågan som båda protokollen undviker
Både DoT och DoH flyttar förtroendet från din lokala nätverksoperatör till den krypterade DNS-leverantör du väljer. Cloudflare, Google, Quad9, NextDNS, ControlD — var och ett av dessa företag ser varje DNS-förfrågan du skickar dem. Kryptering mot dem innebär inte integritet från dem. Om din oro är att din ISP inte ska se din DNS löser krypterad DNS problemet. Om din oro är att ingen tredje part ska se din DNS hjälper inget av protokollen; du behöver köra din egen rekursiv resolver (vilket är ett eget projekt).
Vad du kan kräva av resolvern du litar på: en tydlig loggningspolicy, tredjepartsrevisioner, stöd för query minimization (så att de uppströms auktoritativa servrarna bara ser de delar av förfrågan de behöver) och DNSSEC-validering. De stora offentliga DoH/DoT-leverantörerna publicerar alla sina policyer; läs dem. Vår djupare guide om detta finns i vår DoH-genomgång för 2026.
Slutsats
DoT och DoH löser samma grundläggande problem — DNS i klartext läcker dina surfmål till nätverket — med två olika arkitektoniska strategier. DoT är den öppna designen: en dedikerad port, enkel att identifiera, enkel att hantera, enkel att blockera. DoH är den kamouflerade designen: gömd i HTTPS-trafik, svår att identifiera utan slutpunktsblocklister, svår att blockera i stor skala.
För konsumenter på fientliga nätverk är DoH rätt val eftersom det är det som faktiskt når sin slutpunkt. För företag som behöver DNS-synlighet är DoT det mer samarbetsvilliga valet. För personer som kör sin egen filtrerande DNS hemma är DoT mer konfigurerbart och svårare för användare att kringgå på appnivå. För VPN-användare är valet mestadels osynligt — VPN-klienten hanterar det.
Den verkliga frågan är sällan "DoT eller DoH" — det är "vilken resolver litar jag på, och vad är dess loggningspolicy." Välj en resolver du litar på, konfigurera den systemövergripande (inte per webbläsare) och verifiera med ett DNS-läckagetest att du faktiskt fick konfigurationen rätt. Protokollet du använder för att kommunicera med den spelar mindre roll än policyn hos den enhet som finns i andra änden.