De noodzaak voor DNS-versleuteling: Voorbij gewone tekstvragen

Het domeinnaamsysteem (DNS) is een basisprotocol dat menselijke leesbare domeinnamen vertaalt naar IP-adressen. Ondanks zijn kritieke rol, is het traditionele DNS-verkeer historisch verzonden in platte tekst over UDP of TCP, waardoor het kwetsbaar is voor afluisteren, manipulatie en cachevergiftiging. Aanvallen op hetzelfde netwerk of binnen het pad van een query kan DNS antwoorden om gebruikers omleiden naar kwaadaardige sites of om browsemetadata te verzamelen. Aangezien de privacy van het internet is toegenomen, zijn twee aanvullende encryptieprotocollen ontstaan om DNS-verkeer te beschermen: ]DNS over HTTPS (DoH)] en .DNS over TLS (DoT).

Beide protocollen versleutelen de zoek- en reactiegegevens, het beschermen van het tegen observatie en manipulatie. Echter, ze verschillen in implementatie, port gebruik, en hoe ze integreren met bestaande netwerk stacks. Het begrijpen van deze verschillen is essentieel voor het kiezen van de juiste aanpak voor individuele gebruikers, netwerkbeheerders en applicatieontwikkelaars.

DNS over HTTPS (DoH): Inbedding opzoeken in webverkeer

DNS over HTTPS wraps traditionele DNS-queries en antwoorden binnen standaard HTTPS-verzoeken en -antwoorden, met dezelfde poort 443 gebruikt voor regelmatig webverkeer. Dit ontwerp maakt DoH verkeer niet te onderscheiden van andere HTTPS-verkeer naar netwerkwaarnemers, tenzij ze uitvoeren diepe pakketinspectie of analyseren server IP-adressen. DoH werd gestandaardiseerd in RFC 8484 en is aangenomen door grote browsers zoals Mozilla Firefox en Google Chrome

Hoe werkt DoH?

Wanneer een client (browser of applicatie) een domein wil oplossen, stuurt hij een HTTP POST of GET-verzoek naar een DoH-compatibele resolver (zoals Cloudflare's 1.1.1.1 of Google's 8.88.8). De DNS-query is gecodeerd in de aanvraagtekst of query string, en de resolver reageert met een DNS-respons gecodeerd in het HTTP-responslichaam. Omdat de gehele transactie plaatsvindt via HTTPS, zijn alle encryptie, authenticatie en certificaatvalidatie die door TLS wordt geleverd, geërfd.

Belangrijkste voordelen van DoH

  • Cover integratie: Door het gebruik van poort 443 en HTTPS framing, DoH verkeer combineert met normaal webverkeer, waardoor het moeilijker voor netwerkfiltering of blokkeren om DNS-queries te richten zonder bijkomende schade aan webbrowsing.
  • Eenvoudige implementatie in toepassingen: Browsers en apps kunnen DoH implementeren zonder wijzigingen in de DNS-configuratie van het besturingssysteem te vereisen. Gebruikers kunnen eenvoudig een instelling inschakelen of een uitbreiding installeren.
  • Heffecten bestaande HTTPS-infrastructuur: DoH kan dezelfde HTTP/2 of HTTP/3 verbindingen hergebruiken en volwassen load balancing, caching en content delivery netwerken (CDN's) gebruiken die het moderne web voeden.

Overwegingen en kritiek

Ondanks de voordelen van de privacy, heeft DoH een debat aangewakkerd. Netwerkbeheerders verliezen vaak zichtbaarheid in DNS-verkeer omdat individuele toepassingen kunnen omzeilen systeem-niveau DNS-instellingen. Dit kan inhoud filteren, ouderlijk toezicht en enterprise security beleid belemmeren. Bovendien, DoH introduceert een lichte prestatie overhead als gevolg van HTTP framing en de noodzaak van aparte TLS handshakes (hoewel HTTP/2 multiplexing dit vermindert). Sommige critici beweren dat DoH centraliseert DNS-resolutie aan een paar grote aanbieders, potentieel het creëren van nieuwe punten van surveillance of controle.

DNS via TLS (DoT): Systeem-niveau beveiliging op een speciale haven

DNS over TLS (DoT) gebruikt het TLS-protocol maar communiceert via een speciale poort (853) in plaats van te piggybacken op HTTP. Deze aanpak werd gedefinieerd in RFC 7858 en is typisch geconfigureerd op het niveau van het besturingssysteem of op routers, zodat alle DNS-verkeer van elke toepassing wordt versleuteld.

Hoe werkt DoT

Een DoT-client maakt een TCP-verbinding met een resolver op poort 853 en voert een TLS-handshake uit. Na succesvolle authenticatie van het certificaat van de resolver worden de DNS-berichten direct via de TLS-sessie uitgewisseld, met hetzelfde draadformaat als de traditionele DNS maar binnen een gecodeerde tunnel. Omdat DoT een unieke poort gebruikt, kan het eenvoudig worden geïdentificeerd en beheerd door netwerk firewalls en routeringsbeleid.

Belangrijkste voordelen van DoT

  • Systeembrede handhaving: Zodra DoT is geconfigureerd op het niveau van het besturingssysteem of router, profiteren alle toepassingen van encryptie zonder individuele ondersteuning. Dit is bijzonder waardevol voor mobiele apparaten, IoT gadgets en bedrijfsnetwerken.
  • Eenvoudig te monitoren en te filteren: Beheerders kunnen DoT-verkeer toestaan of blokkeren op basis van de speciale poort en bekende resolver IP's, waardoor het makkelijker wordt om beleid te handhaven in vergelijking met de verborgen aard van DoH.
  • Efficiënt draadformaat: DoT voegt geen HTTP-headers of multiplexing overhead toe, wat resulteert in een lagere per-query latency in veel scenario's. Het binaire DNS-protocol wordt bewaard, waardoor verwerkingsvereisten worden verminderd.

Overwegingen voor DoT

DoT's afhankelijkheid van een speciale poort maakt het gemakkelijker om te blokkeren als een netwerkoperator of ISP besluit om gecodeerde DNS te beperken. Omdat DoT meestal systeembreed is geconfigureerd, wordt de ondersteuning in consumentenapparaten nog steeds groter. Android en iOS begonnen DoT op het niveau van het besturingssysteem alleen te ondersteunen in recente versies, en veel routers hebben geen ingebouwde opties voor het configureren van DoT upstreams.

DoH vs. DoT: Een zij-bij-zijvergelijking

Feature DNS over HTTPS (DoH) DNS over TLS (DoT)
Standard RFC 8484 RFC 7858
Transport port 443 (HTTPS) 853 (reserved)
Traffic visibility Hidden among web traffic Distinguishable by port
Typical deployment Application level (browser, app) System level (OS, router)
Authentication HTTPS certificate validation TLS certificate validation
Performance overhead Higher due to HTTP framing Lower; binary wire format
Ease of blocking Difficult without breaking web Easier via port 853
Centralization risk Higher (browser defaults) Lower (admin-controlled)

Geen van beide protocol is inherent superieur. De keuze hangt af van de context. Voor individuele privacybewuste gebruikers die hun eigen apparaten besturen, biedt DoH een handige manier om lokale DNS-snooping te omzeilen zonder systeeminstellingen te wijzigen. Voor netwerkbeheerders die consistente encryptie op alle apparaten vereisen, biedt DoT een meer beheersbare en auditable oplossing.

Uitvoering van gecodeerde DNS: Praktische overwegingen

Client-side configuratie

De meeste moderne browsers hebben ingebouwde DoH-ondersteuning. Firefox-gebruikers kunnen DoH inschakelen in de netwerkinstellingen, terwijl Chrome het DNS-over-HTTPS-beleid van het systeem respecteert indien ingesteld. Op Windows 11, kunnen gebruikers DoH of DoT instellen voor specifieke resolvers in de netwerkadaptereigenschappen. macOS en Linux-gebruikers kunnen stub-resolvers configureren zoals stubby (DoT) of tools gebruiken zoals dnscrypt-proxy[] die beide protocollen ondersteunen.

Selectie voor oplossen

Bekende publieke oplossers die zowel DoH als DoT aanbieden zijn Cloudflare (1.1.1.1), Quad9 (9.9.9) en Google (8.8.8). Elk heeft verschillende privacybeleid: Cloudflare belooft niet persoonlijk identificeerbare informatie te registreren, Quad9 blokkeert standaard kwaadaardige domeinen en Google maakt gebruik van anonimiseringstechnieken. Gebruikers moeten de betrouwbaarheid van de resolver controleren en naleving van lokale wetten.

Potentiële terugtrekking

Versleutelde DNS kan conflicteren met netwerkbeveiliging tools zoals inbraak detectie systemen die vertrouwen op het inspecteren van DNS-queries. Het kan ook breken captive portals (openbare Wi-Fi login pagina's) die platte tekst DNS nodig hebben om gebruikers te omleiden. Sommige enterprise omgevingen blokkeren alle externe gecodeerde DNS om corporate filtering beleid af te dwingen. In dergelijke gevallen, beheerders moeten een strategie te nemen . . . . .met behulp van een speciale interne gecodeerde resolver of het gebruik van DANE (DNS-based Authentication of Named Entities) voor DoT.

De toekomst van DNS-versleuteling

Naast DoH en DoT, duwen nieuwe protocollen de envelop verder. DNS over QUIC (DoQ) gebruikt het QUIC transportprotocol om latency te verminderen en de veerkracht te verbeteren over onbetrouwbare netwerken. Oblivy DoH (ODoH) voegt een proxylaag toe om te voorkomen dat de resolver queries koppelt aan IP-adressen van de klant, waardoor de privacy van de metadata wordt versterkt. Ondertussen laat de IETF's DNS over HTTPS Certificaatopslag] CA's toe om certificaattransparantielogs via DNS te publiceren, waardoor het vertrouwen wordt vergroot.

Aangezien internet normalisatie organisaties blijven deze protocollen verfijnen, wordt de adoptie verwacht te groeien. Grote browsers en besturingssystemen zijn al verzenden met gecodeerde DNS ingeschakeld standaard in sommige regio's. Netwerkexploitanten en DNS-infrastructuur providers moeten zich voorbereiden op een toekomst waar niet-versleutelde DNS wordt de uitzondering in plaats van de norm.

Conclusie

DNS over HTTPS en DNS over TLS vertegenwoordigen een kritische evolutie in het behoud van de privacy en veiligheid van de gebruiker op het internet. Beide protocollen versleutelen het domeinresolutieproces, waardoor veel voorkomende aanvallen die niet-versleutelde DNS exploiteren worden voorkomen. Terwijl DoH naadloze integratie biedt met webtoepassingen en een betere dekking, biedt DoT een robuuste, systeembrede oplossing die gemakkelijker te beheren is in professionele netwerken. Inzicht in hun verschillen stelt gebruikers, ontwikkelaars en IT-professionals in staat om geïnformeerde keuzes te maken die aansluiten op hun beveiligingsvereisten en operationele beperkingen.

Voor nadere lezing, zie de officiële RFC's: RFC 8484 (DoH), RFC 7858 (DoT) en De DoH-documentatie van Cloudflare[. Naarmate het internet zich verder ontwikkelt, blijft gecodeerde DNS een hoeksteen van een veiliger, meer privé web.