De korte versie: klassieke DNS (het protocol uit 1987) verstuurt zoekopdrachten in plaintext via UDP port 53. Iedereen op het netwerkpad kan elk domein zien dat je opzoekt, antwoorden aanpassen of specifieke zoekopdrachten blokkeren. DoT (RFC 7858, 2016) wikkelt DNS-zoekopdrachten in TLS over port 853. DoH (RFC 8484, 2018) plaatst ze in HTTPS-verzoeken op port 443. Beide lossen het plaintext-probleem op. Ze wijken uiteen op het punt van wie de implementatie beheert, wie de zoekopdrachten kan zien en wie ze kan blokkeren — en dat is de vraag die de meeste mensen eigenlijk stellen als ze vragen "welke moet ik gebruiken." Het hangt ervan af waartegen je je beschermt.
Wat DNS-versleuteling oplost — en wat niet
Voordat we de twee vergelijken, is het goed om helder te maken wat elk protocol eigenlijk beschermt. Klassieke DNS lekt elke domeinnaam die je apparaat opzoekt. Bezoek je example.com, dan kan je ISP — of elke netwerkoperator op het pad — de zoekopdracht voor example.com zien, nog voordat je browser het eerste HTTPS-verzoek verstuurt. De werkelijke inhoud van dat HTTPS-verzoek is versleuteld; de DNS-lookup die eraan voorafging is dat niet. Versleutelde DNS dicht dat specifieke gat.
Wat het niet oplost: het doel-IP-adres waarmee je verbinding maakt is nog steeds zichtbaar. Het TLS Server Name Indication (SNI)-veld lekte in oudere TLS-versies ook de hostnaam tijdens de handshake — al adresseert Encrypted Client Hello (ECH) dat in TLS 1.3. Versleutelde DNS plus ECH dicht de voor de hand liggende lekken. Zonder ECH dicht versleutelde DNS alleen één lek, maar laat het SNI-lek open, wat betekent dat de doelhostnaam nog steeds zichtbaar is tijdens de TLS-handshake. De eerlijke samenvatting: versleutelde DNS is noodzakelijk maar niet voldoende.
Hoe DoT werkt — een eigen kanaal op port 853
DoT (DNS-over-TLS, gedefinieerd in RFC 7858) is het conceptueel eenvoudigere ontwerp. Je apparaat opent een TCP-verbinding naar de DNS-server op port 853. Het voert een TLS-handshake uit — dezelfde TLS die HTTPS beschermt — en stuurt vervolgens standaard DNS-zoekopdrachten via de versleutelde stream. De DNS-server antwoordt met standaard DNS-antwoorden, ook via de versleutelde stream. Op het netwerk ziet men alleen een TLS-verbinding naar port 853.
Omdat port 853 officieel door IANA exclusief aan DoT is toegewezen, is elk TCP-verkeer op die poort ondubbelzinnig DoT. Netwerkoperatoren kunnen DoT moeiteloos herkennen — ze hoeven geen deep packet inspection te gebruiken, ze kijken alleen naar de doelpoort. Als ze DoT willen blokkeren, droppen ze port 853. Als ze het willen toestaan maar het IP-adres van de doel-DNS-server willen loggen, is dat eveneens eenvoudig. DoT is eerlijk over het feit dat het DNS is, wat voor sommige toepassingen een voordeel is en voor andere een nadeel.
Hoe DoH werkt — DNS verborgen in webverkeer
DoH (DNS-over-HTTPS, gedefinieerd in RFC 8484) hanteert een andere aanpak. Je apparaat verstuurt DNS-zoekopdrachten als HTTP POST-verzoeken (of GET-verzoeken met de query-parameter) naar een specifieke URL op de HTTPS-server van de DNS-aanbieder. De body van het POST-verzoek bevat een binair DNS-bericht; de response-body bevat een binair DNS-antwoord. Dit alles gebeurt via een gewone HTTPS-verbinding op port 443 — dezelfde poort die je browser gebruikt om webpagina's te laden.
Vanuit het perspectief van het netwerk is een DoH-verzoek niet te onderscheiden van een gewoon HTTPS-verzoek naar dezelfde server. De verbinding ziet eruit als webverkeer. De pakketgroottes zien eruit als webverkeer (na de initiële zoekopdracht hergebruiken vervolgzoekopdrachten dezelfde HTTP/2- of HTTP/3-verbinding). Het doel-IP behoort tot een generiek ogende endpoint — Cloudflare's 1.1.1.1 of Google's 8.8.8.8 bieden zowel DoH als ander webverkeer aan op dezelfde IP's. Om DoH specifiek te blokkeren moet een netwerkoperator de specifieke endpoints identificeren en blokkeren, wat veel lastiger is dan een poort blokkeren.
Verschillen in netwertzichtbaarheid
Het transportverschil leidt tot een zichtbaarheidsverschil. Met DoT kan je netwerkoperator (bedrijfs-IT, ISP, school, hotel) zien dat je versleutelde DNS gebruikt, kan zien welke DoT-server je gebruikt (via het doel-IP) en kan ervoor kiezen die server te blokkeren. Met DoH ziet de netwerkoperator versleuteld HTTPS-verkeer naar het IP van de DNS-aanbieder, maar tenzij ze specifiek blocklists van DoH-endpoints bijhouden, kunnen ze DoH niet onderscheiden van gewoon HTTPS naar dezelfde aanbieder.
Dit heeft voorspelbare gevolgen. Bedrijfs-IT-afdelingen gaven jarenlang de voorkeur aan DoT, omdat ze het eenvoudig kunnen blokkeren: drop port 853, en DNS valt terug naar de resolver van de organisatie, die ze monitoren en filteren. Ze hebben een hekel aan DoH om dezelfde reden — het omzeilt hun zichtbaarheid. Privacyadvocaten voor consumenten geven juist om diezelfde reden de voorkeur aan DoH. Verschillende belanghebbenden willen verschillende uitkomsten van dezelfde architectuurbeslissing.
Welke protocollen netwerken kunnen blokkeren
DoT is eenvoudig te blokkeren. Port 853 is de enige poort die dat protocol gebruikt; een firewallregel om hem te droppen, en klaar. Veel bedrijfsnetwerken doen dit al. Veel filteringsfirewalls in restrictieve regio's ook. Als je een apparaat configureert om DoT te gebruiken en dat netwerk port 853 blokkeert, mislukken de DNS-zoekopdrachten van het apparaat totdat het besturingssysteem of de app terugvalt op plaintext DNS — en de meeste vallen stilzwijgend terug.
DoH is veel lastiger te blokkeren, omdat de enige manier om het te blokkeren is alle DoH-endpoints te identificeren en op een blocklist te zetten. Cloudflare's 1.1.1.1 is het bekendst en staat meestal op de blocklist; Google's 8.8.8.8 doorgaans ook. Maar onafhankelijk beheerde DoH-endpoints vermenigvuldigen zich — publieke lijsten zoals curl's DoH-wiki catalogiseren er honderden. Een netwerkoperator die DoH wereldwijd wil blokkeren moet die lijst actueel houden en accepteren dat hij altijd één stap achterloopt op nieuwe endpoints. Sommige restrictieve netwerken proberen DoH te detecteren via verkeerspatroonanalyse (DoH heeft karakteristieke verzoekgroottes en timingpatronen), maar dit is kwetsbaar en leidt tot valse positieven.
De Mozilla DoH-documentatie vermeldt deze eigenschap — dat DoH moeilijk te blokkeren is door netwerken — expliciet als een bewuste ontwerpkeuze, niet als een bijwerking. Diezelfde eigenschap maakt DoH controversieel in bedrijfsomgevingen, waar de netwerkoperator DNS-zichtbaarheid beschouwt als een legitiem onderdeel van zijn beveiligingsstack in plaats van als een schending van de privacy van gebruikers.
Gevolgen voor bedrijven en ouderlijk toezicht
DNS-filtering (het type dat de meeste ouderlijk-toezichtsoftware, bedrijfsmatige "veilig browsen"-filtering en de eenvoudigste vormen van malwaredomeinnblokkering aandrijft) werkt door DNS-zoekopdrachten te onderscheppen en de zoekopdrachten voor geblokkeerde domeinen te droppen of valse antwoorden terug te sturen. We behandelden de werking in ons artikel over hoe DNS-filtering echt werkt.
Versleutelde DNS omzeilt dit volledig — zowel DoT als DoH sturen zoekopdrachten naar een andere resolver dan die van het lokale netwerk, waardoor eventuele filtering op de lokale resolver zinloos wordt. Vanuit het perspectief van de aanbieder van ouderlijk toezicht is dit een probleem. Vanuit het perspectief van de gebruiker hangt het er volledig van af of hij de filtering als legitiem of als inbreuk beschouwt. De meeste bedrijfsmatige endpoint-beheertools schakelen browser-DoH tegenwoordig via beleid uit en vertrouwen op DNS-configuratie op OS-niveau of volledige verkeerscontrole om zichtbaarheid te behouden. Apple's MDM-beheerde iOS-profielen bevatten een DoH/DoT-configuratiemechanisme dat precies hiervoor is ontworpen: het bedrijf kan een versleutelde DNS-resolver naar keuze opgeven en voorkomen dat gebruikers die overschrijven.
Voor huishoudens is de praktische werkelijkheid dat het inschakelen van DoH in een browser elke routergebaseerde inhoudsfiltering die je hebt ingesteld omzeilt. Dat is een functie of een fout, afhankvan welke kant van de configuratie je staat.
Prestatiekenmerken
DoT heeft doorgaans iets minder overhead per zoekopdracht dan DoH. Beide protocollen gebruiken TLS, maar DoT stuurt een veel kleinere wrapper om elk DNS-bericht — er is geen HTTP-aanvraagramp, geen headers, geen Content-Length, geen HTTP-methode. Het DNS-bericht gaat rechtstreeks de TLS-stream in. DoH daarentegen wikkelt elke DNS-zoekopdracht in een HTTP POST of GET, wat tientallen tot honderden bytes extra overhead per zoekopdracht toevoegt.
Die overhead wordt grotendeels geamortiseerd door hergebruik van verbindingen. Zowel DoT als DoH houden de TLS-verbinding open over meerdere zoekopdrachten, zodat de kosten van de handshake maar één keer worden betaald. DoH op HTTP/2 multiplext zoekopdrachten op dezelfde verbinding, en HTTP/3 (via QUIC) vermindert de latency verder. In de praktijk produceren de twee protocollen op een modern netwerk een niet te onderscheiden latency voor de gebruiker — hooguit enkele milliseconden verschil. Kies niet het een boven het ander om prestatieredenen; de keuze gaat over zichtbaarheid, controle en bedreigingsmodel.
DoT vs DoH in een oogopslag
| Eigenschap | DNS-over-TLS (DoT) | DNS-over-HTTPS (DoH) |
|---|---|---|
| Poort | 853 (toegewijd) | 443 (gedeeld met HTTPS) |
| RFC | RFC 7858 (2016) | RFC 8484 (2018) |
| Transport | Ruwe TLS over TCP | HTTPS (HTTP/2 of HTTP/3) |
| Herkenbaar op het netwerk | Ja — port 853 is uniek voor DoT | Nee — ziet eruit als gewoon HTTPS |
| Blokkeerbaarheid door netwerk | Eenvoudig (drop port 853) | Moeilijk (vereist endpoint-blocklist) |
| Browserondersteuning | Nee (browsers implementeren DoT niet) | Firefox, Chrome, Edge, Safari ondersteunen het allemaal |
| OS-ondersteuning | Android 9+, iOS 14+, macOS 11+, Linux (systemd-resolved) | Android 9+, iOS 14+, macOS 11+, Windows 11+ |
| Zichtbaarheid voor bedrijven | Zichtbaar via poort; eenvoudig te monitoren of blokkeren | Omzeilt poortgebaseerde monitoring; vereist endpoint-inspectie |
| Latency-overhead per zoekopdracht | Lager (minimale wrapper) | Iets hoger (HTTP-headers); verwaarloosbaar met HTTP/2-multiplexing |
| Censuurbestendigheid | Laag (te blokkeren via poort) | Hoger (port 443 is essentieel voor het moderne web) |
Welk protocol moet je gebruiken — drie scenario's
"Welk protocol is beter" hangt volledig af van wat je wilt bereiken. Hier zijn drie concrete scenario's met concrete antwoorden:
Scenario 1: Persoonlijk apparaat op vijandige of onbetrouwbare netwerken
Koffiezaken, hotels, luchthavens, het Wi-Fi van een vriend. Het bedreigingsmodel is de lokale netwerkoperator die je DNS observeert of aanpast. Elk protocol werkt voor de versleuteling zelf; DoH verdient de voorkeur omdat het veel moeilijker voor een vijandig netwerk te blokkeren is. Als je DoT gebruikt op een netwerk dat port 853 dropt, vallen je zoekopdrachten stilzwijgend terug op plaintext op port 53 (de meeste OS-clients falen op deze manier open) — en heb je alles gelekt wat je probeerde te beschermen. DoH bereikt zijn endpoint bijna altijd.
Scenario 2: Thuisnetwerk met beheerde apparaten van kinderen
Je wilt dat de apparaten van de kinderen een filterende DNS-resolver gebruiken (NextDNS, OpenDNS Family Shield, Cloudflare for Families) en dat ze die niet kunnen omzeilen. DoT is hier eigenlijk eenvoudiger — je configureert het apparaat om een specifieke DoT-resolver te gebruiken, en het kind kan niet zomaar een instelling in een browser aanpassen om een andere DNS te gebruiken. Browser-DoH kan worden uitgeschakeld via bedrijfs-/MDM-beleid of door het canary-domein in te stellen. De keuze tussen DoT en DoH is minder belangrijk dan het configureren van de DNS op apparaatniveau via het besturingssysteem in plaats van afzonderlijke apps te laten kiezen.
Scenario 3: Je gebruikt al een VPN
Als je een VPN gebruikt, kan het lokale netwerk je DNS-zoekopdrachten sowieso niet zien — de VPN-tunnel versleutelt alles, inclusief DNS. De relevante vraag wordt dan welke DNS-resolver de VPN intern gebruikt en of die versleutelde DNS naar zijn upstream-resolver ondersteunt. De meeste moderne VPN's (inclusief Casper's Cloak) gebruiken intern versleutelde DNS en passen threat shield-filtering toe bij de resolver voordat het antwoord terug door de tunnel wordt gestuurd. In deze configuratie is DoT vs DoH grotendeels een implementatiedetail; wat telt is dat de resolver niet je ISP is en je zoekopdrachten niet logt.
De vertrouwenskwestie die beide protocollen omzeilen
Zowel DoT als DoH verplaatsen vertrouwen van je lokale netwerkoperator naar de versleutelde DNS-aanbieder die je kiest. Cloudflare, Google, Quad9, NextDNS, ControlD — elk van deze bedrijven ziet elke DNS-zoekopdracht die je naar hen stuurt. Versleuteling naar hen betekent geen privacy van hen. Als je bezorgd bent dat je ISP je DNS niet moet zien, lost versleutelde DNS het probleem op. Als je bezorgd bent dat geen enkele derde partij je DNS mag zien, helpt geen van beide protocollen; je moet je eigen recursieve resolver draaien (wat een project op zich is).
Wat je kunt eisen van de resolver die je vertrouwt: een duidelijk logbeleid, audits door derden, ondersteuning voor query-minimalisatie (zodat de upstream-autoritatieve servers alleen de delen van de zoekopdracht zien die ze nodig hebben) en DNSSEC-validatie. De grote publieke DoH/DoT-aanbieders publiceren allemaal hun beleid; lees het. Onze uitgebreidere gids hierover staat in ons DoH-overzicht van 2026.
Conclusie
DoT en DoH lossen hetzelfde fundamentele probleem op — DNS-plaintext die je browse-bestemmingen lekt naar het netwerk — met twee verschillende architectuurstrategieën. DoT is het eerlijke ontwerp: een toegewijde poort, eenvoudig te herkennen, eenvoudig te beheren, eenvoudig te blokkeren. DoH is het gecamoufleerde ontwerp: verborgen in HTTPS-verkeer, moeilijk te herkennen zonder endpoint-blocklists, moeilijk op schaal te blokkeren.
Voor consumenten op vijandige netwerken is DoH de juiste keuze, omdat het het protocol is dat zijn endpoint daadwerkelijk bereikt. Voor bedrijven die DNS-zichtbaarheid nodig hebben, is DoT de meer coöperatieve keuze. Voor mensen die thuis een eigen filterende DNS draaien, is DoT beter configureerbaar en moeilijker door gebruikers te omzeilen op app-niveau. Voor VPN-gebruikers is de keuze grotendeels onzichtbaar — de VPN-client regelt het.
De echte vraag is zelden "DoT of DoH" — het is "welke resolver vertrouw ik, en wat is zijn logbeleid." Kies een resolver die je vertrouwt, configureer hem systeembreed (niet per browser) en controleer met een DNS-lektest of je de configuratie daadwerkelijk correct hebt ingesteld. Het protocol dat je gebruikt om ermee te communiceren doet er minder toe dan het beleid van de instantie aan het andere einde.