Elke keer dat je op een link klikt of een adres in je browser invoert, stuurt je apparaat een opzoekverzoek naar een recursieve resolver. Al tientallen jaren verwerken traditionele DNS-servers deze verzoeken via onversleutelde UDP- en TCP-verbindingen op poort 53. Omdat dit verkeer volledig onversleuteld is, kan iedereen die zich op de communicatieroute bevindt je surfgedrag inzien of de antwoorden die je ontvangt manipuleren.
Om deze hardnekkige beveiligingslek op te lossen, heeft de Internet Engineering Task Force (IETF) twee verschillende cryptografische transportprotocollen gestandaardiseerd: DNS over TLS (DoT) en DNS over HTTPS (DoH). Hoewel beide protocollen domeinverzoeken tussen uw client en een resolver versleutelen, werken ze op verschillende lagen van de netwerkstack en leiden ze tot zeer uiteenlopende resultaten op het gebied van netwerkbeheer binnen ondernemingen, gebruikersprivacy en bedreigingsbeheer.
Waarom zou je DNS überhaupt versleutelen?

DNS in leesbare tekst blijft een van de grootste structurele kwetsbaarheden van de verouderde internetarchitectuur. Wanneer verzoeken zonder versleuteling via openbare of onbetrouwbare verbindingen worden verzonden, worden gebruikers en organisaties blootgesteld aan drie belangrijke risico’s:
1. Passief afluisteren: Elke entiteit die inzicht heeft in het netwerkverkeer – waaronder internetproviders (ISP’s), exploitanten van openbare wifi-netwerken en surveillanceprogramma’s – kan elke domeinopzoeking die je apparaat uitvoert, registreren. Zelfs als het daaropvolgende webverkeer via HTTPS verloopt, geven je DNS-verzoeken nog steeds precies weer met welke diensten, apps en domeinen je interactie hebt.
2. Manipulatie en onderschepping tijdens de overdracht: Aanvallers die zich op hetzelfde lokale netwerk bevinden, kunnen verzoeken in leesbare tekst onderscheppen en vervalste antwoorden invoegen, een tactiek die bekendstaat als een ‘man-in-the-middle’-aanval. Hierdoor kan een aanvaller legitiem verkeer omleiden naar kwaadaardige infrastructuur zonder dat het slachtoffer dit merkt.
3. Omleiding en spoofing: In een typisch DNS-spoofingscenario leiden gemanipuleerde zoekresultaten gebruikers naar phishing-landingspagina’s die interne bedrijfsportalen, banksites of Single Sign-On-aanbieders nabootsen.
Door het transportkanaal tussen het clientapparaat (stub-resolver) en de upstream recursieve resolver te versleutelen, worden deze aanvalsvectoren afgesloten. Dit zorgt ervoor dat afluisteraars alleen versleutelde gegevensstromen te zien krijgen in plaats van domeinnamen in leesbare tekst, en garandeert tegelijkertijd dat de antwoorden niet kunnen worden gewijzigd door tussenliggende apparaten op het traject.
Wat is DNS over TLS (DoT)?
DNS over TLS, gestandaardiseerd door de IETF in RFC 7858, beveiligt berichten in het klassieke DNS-wire-formaat binnen een versleutelde Transport Layer Security (TLS)-tunnel.
In plaats van de standaardpoort 53 te gebruiken, werkt DoT via een eigen, speciale netwerkpoort: poort 853.
Wanneer een apparaat DoT initieert, brengt het een betrouwbare TCP-verbinding tot stand met poort 853 van een aangewezen resolver, voltooit het een standaard TLS-cryptografische handshake en wisselt het DNS-verzoeken uit binnen die beveiligde sessie. RFC 7858 verbiedt het verzenden van onversleutelde gegevens via poort 853; als de TLS-onderhandeling mislukt, wordt de verbinding beëindigd in plaats van terug te vallen op onversleutelde overdracht via die poort.
Omdat DoT geen wrappers op applicatieniveau toevoegt, blijft de overhead van zoekopdrachten minimaal. Zodra de verbinding tot stand is gebracht, kunnen clients bestaande TLS-sessies hergebruiken en meerdere zoekopdrachten tegelijkertijd doorsturen, om te voorkomen dat er bij elke zoekopdracht vertraging ontstaat door de handshake.
Ondersteuning voor besturingssystemen en platforms
- Android: Vanaf Android 9 (Pie) heeft Google native ondersteuning voor DoT toegevoegd via de instelling ‘Private DNS’. Wanneer deze is ingeschakeld met een gekozen hostnaam, worden alle DNS-verzoeken op het apparaat via DoT doorgestuurd.
- Linux: Systeemresolvers zoals systemd-resolved en lokale caching-daemons zoals Unbound of Stubby bieden native DoT-ondersteuning.
- Bedrijfsapparatuur: Moderne next-generation firewalls (NGFW) en speciale recursieve resolvers ondersteunen vaak standaard DoT om interne verzoeken te versleutelen die naar beveiligende upstream-resolvers worden verzonden.
Wat is DNS over HTTPS (DoH)?

DNS over HTTPS, gestandaardiseerd in RFC 8484, volgt een andere architecturale aanpak. In plaats van een apart transportkanaal voor domeinverzoeken in te voeren, verpakt DoH DNS-verzoek- en antwoordberichten in standaard HTTP/2- of HTTP/3-payloads die met TLS zijn versleuteld.
DoH werkt via poort 443, dezelfde netwerkpoort die wordt gebruikt voor standaard webverkeer.
Volgens RFC 8484 worden DNS-verzoeken verzonden als HTTP GET- of POST-verzoeken met het specifieke MIME-type application/dns-message. Omdat deze uitwisselingen volledig worden gemultiplexed met het webverkeer op poort 443, kunnen externe netwerkwaarnemers een DNS-opzoeking niet gemakkelijk onderscheiden van het downloaden van een gewone beveiligde webpagina.
Dit ontwerp biedt de privacy van de eindgebruiker maximale veerkracht. Als een tussennetwerk of internetprovider probeert het DNS-verkeer te inspecteren of te filteren, voorkomt DoH dat dit lukt, tenzij ze alle uitgaande HTTPS-verbindingen onderbreken en inspecteren.
Ondersteuning voor besturingssystemen en browsers
- Webbrowsers: Mozilla Firefox, Google Chrome, Microsoft Edge en Brave beschikken allemaal over configureerbare DoH-engines. Firefox was een pionier bij de standaardimplementatie van DoH in verschillende regio’s, terwijl op Chromium gebaseerde browsers automatische upgrades naar DoH ondersteunen wanneer het onderliggende besturingssysteem gebruikmaakt van een compatibele resolver.
- Windows 11: Windows 11 biedt ingebouwde ondersteuning voor DoH voor het hele systeem. Netwerkbeheerders en gebruikers kunnen via de eigenschappen van de netwerkadapter IP-adressen van DNS-servers toewijzen en handmatige DoH-sjabloon-URL’s opgeven.
- Apple (macOS en iOS): Apple-platforms ondersteunen DoH en DoT standaard via gecodeerde DNS-configuratieprofielen of speciale apps voor netwerkuitbreidingen.
DoH versus DoT: vergelijking naast elkaar
| Functie / Metrisch | DNS via TLS (DoT) | DNS via HTTPS (DoH) |
|---|---|---|
| IETF-standaard | RFC 7858 | RFC 8484 |
| Standaardpoort | TCP 853 | TCP/UDP 443 |
| OSI-laag | Transport / Weergave (Laag 4/6) | Toepassing (Laag 7) |
| Verkeerszichtbaarheid | Geïsoleerd op poort 853; gemakkelijk te herkennen | Vermengd met al het HTTPS-webverkeer; moeilijk te isoleren |
| Beheer van de firewall | Eenvoudig om toe te staan, te beperken of te controleren | Moeilijk te controleren zonder diepgaande pakketinspectie |
| Belangrijkste ontwerpdoelstelling | Directe cryptografische upgrade van DNS | Privacy van gebruikers en bestrijding van censuur door middel van versluiering |
| Protocoloverhead | Minder overhead; maakt gebruik van het ruwe DNS-wire-formaat | Iets hogere overhead; HTTP-framing en headers |
| Typische implementatie | Op besturingssysteemniveau, mobiel, bedrijfs-WAN | Webbrowsers, afzonderlijke apps, privacysoftware |
| Ondersteuning voor besturingssystemen | Android (privé-DNS), Linux, Apple-profielen | Windows 11, macOS, iOS, moderne browsers |
De belangrijkste verschillen uitgelegd
Poorttoewijzing en netwerkinzicht
Het duidelijkste operationele verschil tussen het DoT en het DoH betreft de aan hen toegewezen poortnummers.
DoT werkt op poort 853. Deze vaste toewijzing maakt netwerkmonitoring voorspelbaar. Een systeembeheerder kan de firewalllogboeken in één oogopslag bekijken, controleren of het verkeer op poort 853 naar een geautoriseerde interne resolver stroomt, en ongewenste verbindingen met één enkele regel blokkeren. Als een onbeheerd eindpunt probeert contact te maken met een niet-geautoriseerde resolver op poort 853, verwijdert de firewall het pakket zonder het normale webverkeer te verstoren.
DoH verloopt via poort 443. Aangezien vrijwel alle versleutelde internetverkeer via poort 443 verloopt, kan een netwerk poort 443 niet blokkeren zonder de toegang tot het World Wide Web te onderbreken. Daardoor kunnen netwerkbeheerders niet vaststellen of een uitgaand pakket een gewone API-aanroep is, een gebruiker die een e-commercewebsite laadt, of een versleuteld DNS-verzoek dat naar een externe resolver is gericht.
Afweging tussen veiligheid en privacy
Het ministerie van Volksgezondheid (DoH) en het ministerie van Transport (DoT) wijzen op een voortdurende discussie tussen de privacy van eindgebruikers en gecentraliseerde netwerkbeveiliging.
Wat de privacy van individuen betreft, blinkt DoH uit. Op openbare wifi-netwerken of in regio’s waar serviceproviders de browsegeschiedenis van klanten registreren en hier geld mee verdienen, verbergt DoH de metagegevens van zoekopdrachten in de reguliere webverkeersstromen, waardoor gebruikers worden beschermd tegen indringende tracking.
Vanuit het oogpunt van bedrijfsbeveiliging brengt onbeheerd DoH aanzienlijke risico’s met zich mee. Veel moderne systemen voor bedreigingspreventie maken gebruik van DNS-filtering om bekende command-and-control-domeinen (C2) te onderscheppen, tunnels voor gegevensdiefstal te stoppen en phishing-eindpunten te blokkeren nog voordat TCP-handshakes überhaupt van start kunnen gaan.
Wanneer een browser of een schadelijke toepassing binnen een bedrijfsnetwerk standaard overschakelt naar extern DoH:
- Het omzeilt lokale DNS-firewalls en Active Directory-resolvers volledig.
- Hierdoor krijgen SIEM-tools (Security Information and Event Management) geen toegang tot de logbestanden van eindpuntquery’s.
- Ervaren cybercriminelen kunnen DoH-kanalen misbruiken om heimelijk te communiceren met externe commandostructuren, waarbij ze schadelijke payloads verbergen in gewone sessies via poort 443.
Om deze reden blokkeren IT-teams van bedrijven vaak ongeautoriseerde DoH-eindpunten aan de IP-grens of voeren ze groepsbeleidsregels in die het gebruik van door het bedrijf goedgekeurde resolvers verplicht stellen.
Prestaties en latentie
In alledaagse omgevingen zorgen beide protocollen voor snelle reacties zodra de eerste verbindingen tot stand zijn gebracht. De onderliggende werking ervan zorgt echter voor subtiele verschillen in prestaties.
DoT maakt gebruik van onbewerkte DNS-payloads via TLS. Hierdoor blijft de framing compact, waardoor er minder bytes per transactie nodig zijn. Het maakt gebruik van standaard TCP-keep-alive-mechanismen en het hervatten van TLS-sessies om de overhead van de verbinding tot een minimum te beperken.
DoH brengt iets meer verwerkingslast met zich mee, omdat het DNS-verzoeken in HTTP-headers moet inkapselen en HTTP-statusmachines moet onderhouden. Omdat DoH echter profiteert van multiplexing via HTTP/2 en HTTP/3, kan het honderden gelijktijdige verzoeken via één enkele stream verwerken zonder ‘head-of-line blocking’, terwijl het tegelijkertijd gebruikmaakt van HTTP-cachingmechanismen. Bij normaal surfen op het web is het verschil in latentie tussen DoT en DoH in de praktijk zelden merkbaar voor gebruikers.
Welke moet je kiezen?
De keuze tussen DoT en DoH hangt af van uw omgeving, de operationele vereisten en wie de netwerkinfrastructuur beheert.
Individuele gebruikers op onbetrouwbare of openbare netwerken
Als je vaak op reis bent, vanuit koffiebars werkt of gebruikmaakt van internetproviders voor thuisgebruik die je zoekopdrachten in de gaten houden, is DoH over het algemeen de veiligere keuze. Door DoH in je favoriete browser in te schakelen, zorg je ervoor dat lokale netwerkbeheerders de domeinen die je bezoekt niet kunnen registreren of trackingscripts kunnen invoegen.
Bedrijfs- en bedrijfsnetwerken
Organisaties moeten voorrang geven aan DoT of strikt beheerde DoH.
Binnen bedrijfsomgevingen is zichtbaarheid een absolute vereiste. IT-teams moeten ervoor zorgen dat alle werkstations, mobiele apparaten en IoT-hardware namen omzetten via goedgekeurde, beveiligde resolvers.
Om de controle te behouden en tegelijkertijd de versleuteling te handhaven, moeten bedrijven:
- Configureer eindpunten zodat ze via DoT gebruikmaken van interne recursieve resolvers.
- Pas administratieve beleidsregels toe in browsers zoals Chrome, Edge en Firefox om te voorkomen dat gebruikers of updates niet-beheerde openbare DoH-resolvers in- of uitschakelen.
- Blokkeer uitgaand verkeer naar bekende openbare DoH-resolver-IP-adressen op firewalls om te voorkomen dat interne beveiligingsmaatregelen worden omzeild.
- Pas beproefde best practices op het gebied van DNS-beveiliging toe om een uniforme bescherming in alle interne zones te waarborgen.
Mobiele apparaten
Mobiele apparaten schakelen voortdurend tussen vertrouwde bedrijfs-wifi-netwerken, thuisrouters en zendmasten van mobiele providers. Android zorgt hiervoor naadloos via de ingebouwde Private DNS-functie die gebruikmaakt van DoT, waardoor alle apps op het apparaat uniform worden versleuteld zonder dat daarvoor aparte software nodig is. iOS- en macOS-apparaten kunnen dezelfde bescherming realiseren via configuratieprofielen die DoT of DoH ondersteunen.
Hoe zit het met DNS over QUIC (DoQ)?
Naarmate transportarchitecturen zich verder ontwikkelen, is er een nieuw protocol in beeld gekomen: DNS over QUIC (DoQ), gestandaardiseerd in RFC 9250.
Terwijl DoT en het oudere DoH via TCP werken, maakt DoQ gebruik van QUIC via UDP-poort 853. QUIC integreert TLS 1.3-versleuteling rechtstreeks in de transport-handshake. Deze opzet lost het probleem van ‘head-of-line blocking’ op, versnelt het tot stand brengen van verbindingen door middel van 0-RTT-sessiehervatting en ondersteunt een naadloze overgang tussen verbindingen wanneer mobiele apparaten schakelen tussen wifi- en mobiele datanetwerken.
Hoewel DoQ toonaangevend is op het gebied van onderzoek naar en prestaties van versleutelde DNS, bevindt de implementatie in productieomgevingen zich nog in een vroeg stadium in vergelijking met de volwassen ecosystemen van DoT en DoH.
DoH/DoT versus DNSSEC: waarom je beide nodig hebt
Een veelvoorkomende misvatting is dat het inschakelen van DoH of DoT andere DNS-beveiligingsprotocollen overbodig maakt. In werkelijkheid richten versleuteld transport en Domain Name System Security Extensions (DNSSEC) zich op twee totaal verschillende onderdelen van de beveiligingscyclus.
- DoH en DoT beveiligen het transporttraject: ze versleutelen de verbinding tussen je apparaat en de recursieve resolver. Ze voorkomen dat afluisteraars op je lokale netwerk of bij je internetprovider de zoekopdracht kunnen afluisteren. Ze geven echter geen uitsluitsel over de vraag of de upstream-resolver een juist antwoord van de echte domeineigenaar verstrekt.
- DNSSEC waarborgt de integriteit van gegevens: DNSSEC maakt gebruik van cryptografische digitale handtekeningen (RRSIG-records) die in het zonebestand worden gepubliceerd om te controleren of de teruggestuurde DNS-gegevens niet op het autoritatieve niveau zijn gewijzigd of in de caches van resolvers zijn gemanipuleerd.
Als een aanvaller een upstream-autoritatieve naamserver compromitteert of een DNS-cachepoisoning-aanval uitvoert, zullen DoH en DoT dat vervalste antwoord rechtstreeks via een beveiligde, versleutelde tunnel naar je apparaat sturen.
Om de volledige integriteit van de infrastructuur te waarborgen, moeten organisaties DNSSEC implementeren in hun eigen domeinzones en tegelijkertijd resolvers zo configureren dat ze handtekeningen valideren. U kunt controleren of uw huidige domeinen geldige cryptografische handtekeningen publiceren door ze door onze geautomatiseerde DNSSEC-checker te halen.
Veelgestelde Vragen
Is DoH veiliger dan DoT?
Vanuit puur cryptografisch oogpunt is geen van beide protocollen inherent veiliger dan het andere. Beide maken gebruik van robuuste TLS-versleuteling om DNS-verzoeken te beschermen tegen inzicht en manipulatie. Het echte verschil zit hem in de zichtbaarheid op het netwerk: DoH biedt meer privacy tegen monitoring binnen het lokale netwerk doordat het poort 443 deelt met webverkeer, terwijl DoT superieure beheermogelijkheden biedt voor beveiligingsteams van ondernemingen door gebruik te maken van de speciale poort 853.
Moet ik DNS via HTTPS in- of uitschakelen?
Voor individuele gebruikers op persoonlijke apparaten biedt het ingeschakeld laten van DoH directe voordelen op het gebied van privacy, doordat wordt voorkomen dat lokale netwerkbeheerders en internetproviders zoekopdrachten registreren.
In bedrijfsomgevingen moet onbeheerd DoH echter doorgaans worden uitgeschakeld of worden omgeleid naar door het bedrijf goedgekeurde resolvers. Wanneer DoH op browserniveau onbeheerd blijft, omzeilt het interne netwerkfirewalls, regels voor inhoudsfiltering en apparatuur voor het monitoren van bedreigingen.
Kan DoH op een netwerk worden geblokkeerd?
Ja. Hoewel DoH niet kan worden geblokkeerd door een specifieke poort te sluiten zonder tegelijkertijd het HTTPS-webverkeer op poort 443 uit te schakelen, kunnen organisaties DoH wel beperken met behulp van alternatieve maatregelen. Netwerkbeheerders kunnen de toegang tot de openbare IP-adressen van bekende commerciële DoH-resolvers blokkeren, de toegang via webproxies beperken of next-generation firewalls gebruiken met applicatie-identificatie-engines (App-ID) die in staat zijn om DoH-verkeerssignaturen te herkennen.
Maakt een VPN DoH of DoT overbodig?
Een Virtual Private Network (VPN) versleutelt al het netwerkverkeer dat je apparaat verlaat, inclusief je DNS-verzoeken, binnen een versleutelde tunnel terug naar de VPN-gateway. Als je je VPN-provider vertrouwt en je systeem zo configureert dat verzoeken via hun eigen recursieve resolvers worden verwerkt, heb je niet per se DoH of DoT nodig, aangezien de gehele tunnel al versleuteld is.
Het gebruik van DoH of DoT binnen of buiten een VPN zorgt echter voor een meerlaagse beveiliging, waardoor zoekopdrachten beschermd blijven, zelfs als er door split-tunneling standaard DNS-pakketten uitlekken.
Laatste opmerkingen: Bescherm uw resolvers en uw records
Zowel DNS over HTTPS als DNS over TLS bieden aanzienlijke verbeteringen op het gebied van privacy ten opzichte van de veertig jaar oude standaard voor onversleutelde UDP-poort 53. De keuze tussen beide hangt af van de context: DoH biedt individuele gebruikers anonimiteit en privacy op openbare netwerken, terwijl DoT organisaties de duidelijke grenzen en het inzicht biedt die nodig zijn om het beveiligingsbeleid van de onderneming te handhaven.
Het versleutelen van de manier waarop uw team domeinen van derden opzoekt, dekt echter slechts de helft van de kwetsbaarheden in uw infrastructuur. U moet ook de openbare DNS-records beveiligen die de rest van de wereld naar de webservices, applicaties en e-mailservers van uw bedrijf leiden.
Domein zones die niet worden bewaakt, lopen het risico op ongeoorloofde wijzigingen in records, ontbrekende cryptografische handtekeningen en verlopen certificaten. PowerDMARC helpt organisaties om volledig overzicht over hun domeinen te behouden door middel van DNS-beveiligingsmonitoring en naleving van de voorschriften.
Door continue monitoring van records en waarschuwingen bij wijzigingen in de DNS-tijdlijn te combineren met onze gratis DNSSEC-checker, kunt u ervoor zorgen dat de DNS-infrastructuur van uw bedrijf controleerbaar en conform blijft en vanuit alle hoeken beschermd is tegen spoofing.

