De korte versie: klassiek DNS stuurt je query's — elk "wat is het IP-adres van example.com?" — als onversleuteld UDP dat iedereen op het netwerkpad kan lezen of aanpassen. DoH wikkelelt die query's in HTTPS, zodat de netwerktoehoorder geen domeinnamen meer ziet en geen valse antwoorden kan injecteren. Dat lost drie legitieme problemen op (DNS-snooping door de ISP, DNS-injectie in het café, en bepaalde vormen van DNS-censuur op staatsniveau) en schept twee nieuwe (ouderlijk toezicht en bedrijfsbeveiliging stoppen met werken, en je hebt nu je gekozen DoH-provider ingelicht over elk domein dat je bezoekt). DoH is noch "privéer" noch "minder privé" — het is anders privé, en de vraag is welke afweging past bij jouw dreigingsmodel.
Wat DoH werkelijk is (en wat het vervangt)
Klassiek DNS is een van de oudste protocollen die nog in productie zijn. Het dateert uit 1983, is ouder dan alomtegenwoordig HTTPS, en werd ontworpen toen "iedereen op het netwerk is min of meer vertrouwenswaardig" een redelijke aanname was. De werking: je apparaat stuurt een UDP-pakket naar poort 53 van je geconfigureerde DNS-resolver (meestal die van je ISP, of 8.8.8.8 / 1.1.1.1 als je dat hebt gewijzigd). Het pakket, in leesbare tekst, vraagt "geef me de A-record van example.com." De resolver antwoordt, in leesbare tekst, met het IP-adres. Drie eigenschappen zijn het vermelden waard:
- Iedereen op het netwerkpad kan de query lezen. Je ISP, de WiFi van het café, iedereen die tcpdump draait op het lokale netwerk — elke domeinnaam die je opzoekt staat in de openbaarheid.
- Iedereen op het netwerkpad kan een antwoord vervalsen. Als ze voor de legitieme resolver een nep-antwoord terugsturen naar je apparaat, word je omgeleid. Zo werken sommige captive portals en sommige censuurregimes.
- Je geconfigureerde resolver ziet elke query. Wie je DNS beheert, kent elk domein dat je bezoekt, op volgorde, met tijdstempels.
DoH (RFC 8484, 2018) verandert punt 1 en 2: query's reizen via een TLS-versleutelde HTTPS-verbinding naar de resolver. Toehoorders op het pad zien HTTPS-bytes, geen domeinnamen. Vervalsing wordt even moeilijk als het vervalsen van een willekeurig HTTPS-antwoord (dus: effectief onmogelijk zonder het TLS-certificaat van de resolver). Punt 3 verandert niet — de resolver ziet de query's nog steeds, want ze zijn aan de resolver geadresseerd. DoH verschuift de vertrouwensgrens; hij verwijdert hem niet.
DoT (DNS-over-TLS, RFC 7858) doet hetzelfde via een aparte poort (853) in plaats van op HTTPS-poort 443 mee te liften. Functioneel equivalente privacyeigenschappen; operationeel anders. DoH is moeilijker te blokkeren op netwerkniveau, omdat blokkeren ervan willekeurig HTTPS blokkeren inhoudt, waardoor het hele internet platgaat. DoT is voor netwerkbeheerders gemakkelijker selectief af te dwingen of te blokkeren. DoH won de deploymentwedloop grotendeels omdat Mozilla en Google het standaard in browsers leverden.
Drie dingen die DoH echt oplost
1. DNS-snooping door de ISP
In de Verenigde Staten mogen ISP's since 2017 wettelijk browsedata verkopen zonder expliciete toestemming, en DNS-querylogs horen bij wat ze verzamelen. In andere landen verschilt het juridisch kader; in sommige geldt verplichte dataretentie op naam voor DNS. Hoe dan ook: als je de resolver van je ISP gebruikt, heeft je ISP een volledig log van welke sites je bezoekt, per tijdstempel.
DoH naar een niet-ISP-resolver (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9, NextDNS, AdGuard DNS, Mullvad's DNS, de resolver in je VPN) sluit dit vanuit het perspectief van je ISP volledig af. De ISP ziet nog steeds TLS-verbindingen naar specifieke IP-adressen, en via die IP's (plus SNI in de TLS-handshake, zie hieronder) kan hij vaak de hostnaam afleiden — maar hij heeft geen schoon, doorzoekbaar DNS-log meer. Het vertrouwen verschuift van de ISP naar wie je DoH-resolver beheert.
2. DNS-injectie in het café
Captive portals op openbare WiFi werken door DNS-query's (en HTTP-verzoeken) te onderscheppen en om te leiden naar een portalpagina totdat je de netwerkvoorwaarden accepteert. Dat mechanisme — jouw DNS onderscheppen — heeft dezelfde vorm als kwaadaardige DNS-injectie. Een vijandig netwerk kan je DNS-antwoorden herschrijven om je naar phishingpagina's of advertentie-injectiepoxy's te sturen. Gewoon DNS geeft hen een gemakkelijk aanvalsoppervlak; DoH sluit dat af.
Dit is een van de gevallen waarbij DoH en een VPN-tunnel overlappen. Een VPN tunnelt alles, inclusief DNS, via versleutelde bytes; DoH alleen tunnelt enkel de DNS-query's. Op een vijandig netwerk verslagen beide ingrepen de klasse van DNS-injectienaanvallen, maar ze pakken verschillende lagen aan. We behandelden het dreigingslandschap in Openbare WiFi-aanvallen in 2026.
3. Bepaalde vormen van DNS-censuur op staatsniveau
Verschillende censuurregimes implementeren blokkering op DNS-niveau: als je vraagt "wat is het IP-adres van geblokkeerde-site.com?", geeft de door de staat voorgeschreven resolver NXDOMAIN terug of stuurt door naar een "deze site is geblokkeerd"-pagina. DoH naar een resolver buiten de censurerende jurisdictie verslaat dit specifieke mechanisme, omdat het censorerende netwerk alleen HTTPS naar de DoH-resolver ziet, niet de query's erin.
Het voorbehoud: dit werkt alleen totdat de censor escaleert. Geavanceerde censuurregimes (China, Iran) blokkeren DoH-resolvers direct op IP-adres, dwingen HTTPS-inspectie af via door de staat uitgegeven root-CA's, of gebruiken SNI-gebaseerde blokkering (zie volgende sectie). DoH verslaagt naïeve DNS-censuur; het verslaagt geen vastberaden censuur op staatsniveau.
Drie dingen waar DoH niet bij helpt
1. SNI-lek in de TLS-handshake
Dit is de valkuil die de meeste artikelen overslaan. Wanneer je verbinding maakt met "example.com" via HTTPS, stuurt je browser de hostnaam in leesbare tekst tijdens de TLS-handshake — specifiek in de SNI (Server Name Indication)-extensie. De reden: één IP-adres bedient vaak veel domeinen via TLS-terminatie, en de server moet weten welk certificaat te tonen vóórdat de versleutelde sessie begint. SNI is by design leesbare tekst.
Nettoresultaat: zelfs met DoH ziet een toehoorder op het netwerk welke hostnamen je via SNI bezoekt. De fix voor DNS-snooping is dus gedeeltelijk. De maatregel is ECH (Encrypted Client Hello) — een relatief nieuwe TLS-extensie die de SNI versleutelt. Cloudflare schakelde ECH in voor sites achter hun netwerk in 2023, en Firefox + Chrome voegden ondersteuning toe, maar adoptie buiten Cloudflare is nog wisselvallig. Totdat ECH universeel is, sluit DoH slechts de helft van de "wie kan zien welke sites je bezoekt"-vraag.
2. IP-gebaseerde identificatie van bestemmingen
Zelfs met DoH en ECH gaan je TLS-verbindingen nog steeds naar specifieke doel-IP's. Voor sites met eigen infrastructuur (banken, nichédiensten) is het doel-IP-adres vrijwel een perfecte identifier van de site, zelfs zonder DNS of SNI. Voor sites achter grote CDN's (Cloudflare, Fastly, AWS CloudFront) is IP-gebaseerde identificatie vager — miljoenen sites delen een paar IP's — maar de grootste sites hebben nog steeds unieke infrastructuur of onderscheidende verkeerspatronen.
DoH lost dit niet op; dat kan het ook niet. Een netwerktoehoorder die echt wil weten welke sites je bezoekt, kan een IP-naar-domein-maptabel opbouwen en je verkeersbestemmingen opzoeken. De maatregel is een VPN-tunnel, die de zichtbaarheid van doel-IP's van het lokale netwerk naar de VPN-provider verplaatst. Het vertrouwen moet altijd ergens naartoe; DoH alleen laat het bij de netwerkeigenaar.
3. Je DoH-provider ziet alles wat je vroeger naar je ISP lekte
Dit is de afweging die DoH-marketing gewoonlijk weglaat: DoH maakt je DNS-query's niet privé; het verschuift de zichtbaarheid van je ISP naar je gekozen DoH-resolver. Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9, NextDNS, AdGuard en elke andere DoH-provider zien elke query die je maakt, precies zoals je ISP dat vroeger deed. Sommige publiceren strikte no-log-policies; sommige publiceren alleen geaggregeerde logging; sommige verkopen geaggregeerde data aan "onderzoekspartners." Het juridisch kader rondom je DoH-provider is even belangrijk als dat rondom je ISP.
Cloudflare's 1.1.1.1 publiceert auditrapporten die aangeven dat ze logs na 24 uur vernietigen en geen DNS-data verkopen. Google's 8.8.8.8 logt query's (met anonimisering) voor onbepaalde tijd conform hun gestelde retentiebeleid. NextDNS laat je je eigen logretentie instellen van "geen" tot "jouw account, jouw keuze." De keuze voor de DoH-provider doet ertoe; de vraag is welke vertrouwensrelatie je comfortabeler vindt — je ISP onder de wetten van je land, of je DoH-provider onder die van zijn land.
Twee dingen die DoH legitiem breekt
1. Ouderlijk toezicht en gezinsnetwerk-filtering
De meeste consumentenoplossingen voor ouderlijk toezicht werken door DNS te inspecteren op de router of via een geconfigureerde gezinsfilter-DNS-resolver (OpenDNS Family Shield, Cleanbrowsing Family, NextDNS-gezinsprofiel). Wanneer het apparaat van je kind die resolvers gebruikt, geven opzoekingen van content voor volwassenen, gokken, enzovoort NXDOMAIN terug. Het systeem is afhankelijk van het feit dat het apparaat de ouderlijk-toezicht-DNS-resolver aanspreekt.
DoH op browserniveau (Firefox schakelde DoH standaard in 2019 in voor Amerikaanse gebruikers; Chrome en Edge gebruiken de OS-resolver maar met DoH indien geconfigureerd) omzeilt deze systemen stilzwijgend. De browser vraagt Cloudflare of Google rechtstreeks, de gezinsfilter-resolver ziet de query nooit, en het kind bereikt de gewenste site. Dit is by design vanuit Mozilla's perspectief ("we mogen netwerken niet laten censureren"); per ongeluk vanuit het perspectief van een ouder ("het filter waarvoor we betaald hebben werkt gewoon niet meer").
Er zijn maatregelen, maar ze zijn omslachtig: configureer DoH op OS-niveau (niet browser) naar een gezinsvriendelijke resolver zoals NextDNS-gezinsprofiel of OpenDNS Family Shield, en schakel daarna DoH op browserniveau uit zodat het doorvalt naar de OS-keuze. Zowel Apple's Configuration Profiles als Windows-groepsbeleid ondersteunen dit. Voor de meeste huishoudens is het ingewikkeld genoeg om een echte drempel te vormen.
2. Bedrijfsbeveiliging en malwareblokkering op netwerkniveau
De meeste bedrijfsnetwerken implementeren DNS-gebaseerde beveiliging: een sinkhole-DNS-server lost bekende kwaadaardige domeinen op naar niets (of naar een interne waarschuwingspagina), waardoor malware-command-and-control, phishing-omleidingen en data-exfiltratie naar bekende endpoints worden geblokkeerd. Dit werkt omdat elk apparaat op het bedrijfsnetwerk de bedrijfs-DNS gebruikt, zodat elke opzoeking gefilterd wordt.
DoH op browserniveau omzeilt dit stilzwijgend. Een gecompromitteerde browser die geblokkeerd zou moeten worden van zijn C2-server, kan eenvoudig de C2-hostnaam via Cloudflare DoH-oplossen, het echte IP-adres ophalen en rechtstreeks verbinden. IT-teams reageerden door: (a) browserbeleid te configureren om DoH uit te schakelen, (b) volledige TLS-inspectie in te zetten zodat de beveiligingsstack in HTTPS inclusief DoH-verkeer kan kijken, of (c) bekende DoH-resolver-IP's bij de firewall te blokkeren. Geen van die opties is prettig — optie (a) laat gebruikers thuis ook op gewoon DNS, optie (b) vereist het installeren van een root-CA op elk apparaat, optie (c) breekt zodra nieuwe DoH-endpoints verschijnen.
DoH op elk platform — wat is de werkelijke configuratie?
iOS 14+ / iPadOS 14+: Instellingen → Algemeen → VPN & apparaatbeheer → DNS — maar alleen via een geïnstalleerd configuratieprofiel. iOS stelt DoH niet bloot in de standaard Instellingen-UI; je installeert een .mobileconfig-bestand (Cloudflare, Quad9, NextDNS, AdGuard en Mullvad publiceren ze allemaal). Na installatie gebruikt elke app op het apparaat DoH naar die resolver. Dit is by design — iOS behandelt DoH als een instelling op OS-niveau, niet per app.
Android 9+: Instellingen → Netwerk & internet → Geavanceerd → Privé-DNS — maar dit is eigenlijk DoT, niet DoH. Android implementeerde "Privé-DNS" met DoT (poort 853) in plaats van DoH (HTTPS). Functioneel equivalente privacyeigenschappen; het protocol verschilt. Voer de hostnaam in van een DoT-resolver (one.one.one.one voor Cloudflare, dns.google voor Google, dns.adguard.com voor AdGuard) en Android versleutelt elke DNS-query systeembreed.
macOS 11+: hetzelfde configuratieprofielmechanisme als iOS. Apple levert eigen DoH-ondersteuning maar stelt die niet beschikbaar via Systeeminstellingen; je installeert een profiel.
Windows 11: Instellingen → Netwerk & internet → adaptereigenschappen → DNS-servertoewijzing → "Alleen versleuteld (DNS over HTTPS)" — Windows kent Cloudflare, Google en Quad9 standaard en configureert DoH automatisch als je die IP's instelt. Windows 10 heeft DoH-ondersteuning maar die is moeilijker te vinden.
DoH op browserniveau: Firefox schakelt DoH standaard in voor Amerikaanse gebruikers (Instellingen → Privacy & beveiliging → DNS over HTTPS). Chrome noemt het "Veilig DNS" (Instellingen → Privacy en beveiliging → Beveiliging). Safari gebruikt de configuratie op macOS-niveau in plaats van browserspecifieke configuratie. Edge gebruikt het Windows-niveau. DoH op browserniveau is snel in te schakelen, maar schept het hierboven beschreven probleem van omzeiling van ouderlijk toezicht en bedrijfsbeleid; DoH op OS-niveau plaatst de beslissing op één plek waar die beheerd kan worden.
Een DoH-resolver kiezen — de eerlijke vergelijking
Je DoH-resolver kiezen is de werkelijke privacybeslissing die DoH je laat nemen. De belangrijkste opties:
- Cloudflare 1.1.1.1: snel (anycast, onder de 15 ms in de meeste steden), logretentie van 24 uur, jaarlijks geauditeerd. Heeft een "gezins"-variant (1.1.1.3) die content voor volwassenen blokkeert. Cloudflare biedt ook WARP aan, een VPN-lite die DoH combineert met een tunnel naar het netwerk van Cloudflare.
- Google 8.8.8.8: snel, alomtegenwoordig, onbepaalde logretentie conform het gestelde beleid van Google. Privacy redelijk naar Google-maatstaven, maar als "vertrouw Google met nog een gegevensstroom" een sticking point is, kijk dan elders.
- Quad9 9.9.9.9: non-profitfundatie in Zwitserland, blokkeert standaard bekende kwaadaardige domeinen, gestelde no-log-policy, conservatiever met data dan de meeste.
- NextDNS: configureerbaar per profiel (blocklists, gezinsfilter, logretentie) — de keuze voor gevorderde gebruikers. Zie onze vergelijking voor meer diepgang.
- AdGuard DNS: blokkeert advertenties en trackers op DNS-laag aggressief, ondersteunt zowel DoH als DoT.
- Mullvad DNS: ook beschikbaar als standalone (geen VPN-abonnement vereist), Zweeds, configureerbare contentblokkering, toegankelijk via DoH en DoT.
- De resolver van je VPN-provider: Casper's Cloak, ProtonVPN (NetShield), Mullvad — DNS afgehandeld binnen de VPN-tunnel, geen aparte configuratie vereist. Handig; betekent dat je de VPN-provider voor beide lagen vertrouwt, wat onvermijdelijk is als je toch een VPN gebruikt.
De eerlijke formulering: er is geen "beste" DoH-resolver; er is een beste voor jouw dreigingsmodel. Voor sommigen telt snelheid, voor anderen blocklists, voor anderen de no-log-policy, voor weer anderen de jurisdictie. Kies er een, configureer die op OS-niveau (niet alleen op browserniveau) zodat de keuze elke app dekt, en herzie dit als je prioriteiten of de transparantierapporten van een resolver veranderen.
Waar DoH past bij VPN's en advertentieblokkering — het geïntegreerde beeld
Drie onafhankelijke privacylagen, elk sluitend voor een ander aanvalsoppervlak:
- VPN-tunnel: versleutelt de zichtbaarheid van doel-IP's vanuit het lokale netwerk, verplaatst die naar de VPN-provider. Sluit "het café / de ISP kan zien op welke IP's je verbinding maakt" af.
- DoH / DoT: versleutelt de DNS-query's vanuit het lokale netwerk en van de ISP, verplaatst DNS-zichtbaarheid naar de DoH-resolver. Sluit "DNS-log bij de ISP" en "DNS-injectie op netwerkniveau" af.
- DNS-niveau contentfiltering (Pi-hole, NextDNS, AdGuard DNS): blokkeert opzoekingen voor advertenties, trackers, malware en phishing — bij de resolver. Sluit "elke app op je apparaat laadt tracker-SDK's waarvan de endpoints op DNS-laag geblokkeerd kunnen worden" af.
DoH alleen is één laag. Een echte privacyhouding stapelt alle drie. Casper's Cloak is gebouwd om deze stack als één app te leveren: VPN-tunnel + Pi-hole DNS-filtering (we draaien een Pi-hole-instantie per gebruiker als resolver) + ML-gebaseerde zero-day phishingdetectie bovenop de statische blocklists. DoH is impliciet in hoe dit is bedraad — DNS-query's tussen het apparaat en onze resolver zijn versleuteld. De eerlijke formulering is dat dit één geldige architectuur is; een andere is "configureer DoH op OS-niveau naar NextDNS, voeg een VPN naar keuze toe, bereik hetzelfde eindresultaat met meer knoppen." Beide werken; de afweging is gemak versus configureerbaarheid. We behandelden hetzelfde punt vanuit de DNS-filteringhoek in Hoe DNS-filtering daadwerkelijk werkt.
Conclusie
DoH is een echte en nuttige privacyverbetering, met voorbehouden die niet in de marketingtekst staan. Het sluit DNS-snooping door de ISP, DNS-injectie in het café en naïeve censuur af — drie echte problemen voor echte gebruikers. Het sluit SNI-lek, IP-gebaseerde bestemmingsidentificatie en vertrouwen in je gekozen resolver niet af. En het breekt ouderlijk toezicht en bedrijfsbeveiliging in legitieme gebruiksscenario's, tenzij je zorgvuldig configureert.
De belangrijkste DoH-beslissing is welke resolver je kiest, geconfigureerd op OS-niveau zodat elke app die consistent krijgt. De op één na belangrijkste beslissing is of je DoH combineert met een VPN-tunnel (sluit zichtbaarheid van doel-IP's af) en DNS-niveau contentfiltering (blokkeert advertenties, trackers en opzoekingen van kwaadaardige domeinen). DoH alleen lost één laag op; de geïntegreerde stack dekt het volledige oppervlak.
Gerelateerd: Hoe DNS-filtering daadwerkelijk werkt behandelt de filterlaag die DoH alleen niet omvat; Openbare WiFi-aanvallen in 2026 behandelt het dreigingsmodel van een vijandig netwerk waar DoH bij helpt; Gratis VPN versus betaalde VPN in 2026 behandelt de VPN-tunnellaag. De NextDNS-vergelijking en de Pi-hole-vergelijking gaan dieper in op de configureerbare DNS-resolvorkeuzes.