DNS over HTTPS: wat het is en hoe het uw query's beschermt

Alpha-gids » Computing » DNS over HTTPS: wat het is en hoe het uw query's beschermt

Wanneer je een webadres intypt, werkt er op de achtergrond een systeem dat ervoor zorgt dat je de juiste site bereikt: het Domain Name System (DNS). DNS vertaalt gemakkelijk te onthouden namen naar IP-adressen die computers kunnen begrijpen. Dat is handig, maar jarenlang kende het een aanzienlijke kwetsbaarheid: deze query's werden onversleuteld verzonden. Daarom is DNS over HTTPS, ook wel bekend als DoH, zo populair geworden: een extra beveiligingslaag die het voor je internetprovider moeilijker maakt om te achterhalen welke domeinen je bezoekt.

Het is belangrijk om vanaf het begin één ding duidelijk te maken: DoH verbetert de privacy van DNS-query's, maar het is geen VPN en het verandert je hele verbinding ook niet in een geheime tunnel . In dit artikel zullen we precies onderzoeken wat het is, waarom het zo populair is geworden, hoe je het activeert in Chrome, Edge en Firefox, de voor- en nadelen, hoe het verschilt van DNS over TLS en een VPN, en de technische en praktische beperkingen ervan.

Wat is DNS en waarom schiet het traditionele systeem tekort?

DNS-servers zijn een van die componenten waar bijna niemand naar kijkt, terwijl ze toch een groot deel van het internetgebruik ondersteunen. Hun taak is om een ​​domeinnaam te koppelen aan het IP-adres van de bijbehorende server . Wanneer je een website bezoekt, begrijpt je computer geen letters: hij heeft een IP-adres nodig om te weten met welke machine hij verbinding moet maken. Veel routers worden geleverd met DNS-servers die al door de internetprovider zijn geconfigureerd, wat het proces handig maakt, maar het laat ook een zichtbaar spoor achter voor degene die de infrastructuur beheert.

Het onderliggende probleem is dat traditionele DNS-query's in platte tekst en zonder bescherming worden uitgevoerd . Dit maakt afluisteren, man-in-the-middle-aanvallen en manipulatie van het antwoord mogelijk. Een internetprovider kan achterhalen welke domeinen u opvraagt ​​en wanneer; een aanvaller op een gedeeld netwerk kan proberen het verzoek te onderscheppen en een frauduleus antwoord te geven. Deze techniek staat bekend als DNS-kaping en kan er uiteindelijk toe leiden dat u terechtkomt op een neppagina, ongewenste advertenties of een website die is ontworpen om gegevens te stelen. Overheden en internetproviders hebben deze zwakheden in het verleden ook misbruikt om censuur in te voeren, domeinen te blokkeren of extra advertenties weer te geven.

• Passief luisteren: Iemand analyseert de zoekopdrachten en leidt daaruit af welke diensten of websites u regelmatig bezoekt.
• Man in het midden: De communicatie wordt onderschept en het antwoord wordt aangepast om zich voor te doen als een server.
• Blokkeren en filteren: Het voorkomt dat bepaalde domeinen worden weergegeven om de toegang tot content te controleren.

DNS via HTTPS: Versleutel de query zodat deze niet voor iedereen zichtbaar is.

DNS over HTTPS, ofwel DoH, is een oplossing die gebruikmaakt van het HTTPS-protocol om DNS-query's en -antwoorden versleuteld te verzenden . In plaats van een onversleuteld DNS-verzoek te versturen, verpakt het apparaat dit in een beveiligde verbinding, meestal via poort 443, dezelfde poort die door beveiligde websites wordt gebruikt. Dit beschermt zowel de query als het antwoord, waardoor het voor een buitenstaander onmogelijk wordt om ze te lezen.

Om dit te laten werken, moet de DNS-server die wordt geraadpleegd ook Domain-based DNS (DoH ) ondersteunen. Het is niet voldoende om simpelweg een optie in de browser in te schakelen: de gekozen resolver moet aan deze standaard voldoen. De specificatie is in ontwikkeling en wordt nog steeds beschouwd als een technologie in ontwikkeling, hoewel bedrijven zoals Google en de Mozilla Foundation deze sinds 2018 testen en integreren. Naast verbeterde privacy wijzen tests uit dat DoH de latentie kan verminderen en query's kan versnellen, omdat het niet altijd nodig is om het hele domein op te lossen, maar alleen het minimaal vereiste gedeelte.

Voordelen van DoH: meer privacy, minder manipulatie en betere prestaties.

Het meest voor de hand liggende voordeel is de beveiliging. Omdat DNS-query's versleuteld worden verzonden, zijn ze veel moeilijker te onderscheppen of te wijzigen . Dit bemoeilijkt man-in-the-middle-aanvallen, vermindert de kwetsbaarheid op openbare wifi-netwerken en voorkomt dat een lokale operator duidelijk kan zien welke domeinen u opvraagt. Omdat DoH-verkeer poort 443 gebruikt, gaat het op in andere HTTPS-verbindingen en is het moeilijk te onderscheiden van een normaal webbezoek.

Er zijn ook prestatievoordelen. DoH kan de latentie verlagen en de DNS-communicatie versnellen dankzij veranderingen in de manier waarop namen worden opgelost en een beter gebruik van de cache. De GET-methode van sommige API's is bijvoorbeeld ontworpen om efficiënter in de cache te worden opgeslagen. In de praktijk kan dit zich vertalen in iets sneller browsen, hoewel het geen wondermiddel is en de verbetering niet altijd merkbaar is. Bovendien hoeft de gebruiker, omdat het in de browser is geïmplementeerd, niet te wachten tot zijn internetprovider het activeert.

Nadelen en discussies: wanneer encryptie het leven ingewikkelder maakt

Niet iedereen is positief over domeingebaseerde encryptie (DoH). Dezelfde encryptie die de gebruiker beschermt, maakt netwerkmonitoring ook lastiger . Veel programma's voor ouderlijk toezicht zijn afhankelijk van het inspecteren van DNS-query's om te bepalen welke websites kinderen proberen te bezoeken; met DoH wordt deze taak veel complexer en kan zelfs onmogelijk worden. Een vergelijkbare situatie doet zich voor bij netwerkbeheerders van bedrijven, die geen inzicht meer hebben in de domeinen die worden opgevraagd en bepaalde regels daardoor minder gemakkelijk kunnen afdwingen.

Internetproviders verliezen ook de mogelijkheid om de toegang te monitoren en specifieke domeinen te blokkeren op verzoek van een instelling. Dit leidt tot een legitiem debat: sommigen zien het als een overwinning voor de privacy, terwijl anderen het beschouwen als een probleem voor controle en beheer . In het geval van DoT wordt het ook bekritiseerd omdat het een eigen herkenbare poort gebruikt, waardoor DNS-query's kunnen worden geïdentificeerd, zelfs zonder precies te weten wat er wordt gevraagd. DoH vermijdt dit duidelijke signaal door zich te verbergen in HTTPS-verkeer, maar in ruil daarvoor hebben netwerkbeheerders minder tools om hun communicatie te beheren.

Hoe schakel je DoH in Chrome, Edge en Firefox in?

Het inschakelen van Domain Name System (DNS) in een moderne browser is meestal eenvoudig, vooral als deze gebaseerd is op Chromium of Firefox. De optie bestaat, hoewel deze in sommige gevallen verborgen is in geavanceerde instellingenmenu's . Voordat u iets wijzigt, is het belangrijk te begrijpen dat de browser alleen zijn eigen query's beschermt: andere applicaties op het apparaat kunnen een ander DNS-systeem blijven gebruiken als dit niet ook op systeemniveau is geconfigureerd.

Google Chrome

In Chrome is de snelste manier om te typen chrome://flags/#dns-over-https in de adresbalk. Daarmee kom je direct bij de Flags of experimentele functies van Chrome terecht.Je ziet een optie genaamd 'Beveiligde DNS-zoekopdrachten' geselecteerd; klik op het vervolgkeuzemenu 'Standaard' en kies 'Ingeschakeld'. Vervolgens moet je je browser opnieuw opstarten om de wijziging door te voeren.

Microsoft Edge

In de op Chromium gebaseerde Edge is het proces vrijwel identiek. Open je browser en typ edge://flags/#dns-over-https in de zoekbalkJe opent de Edge-vlaggen en dezelfde optie voor beveiligde DNS-zoekopdrachten verschijnt. Wijzig 'Standaard' naar 'Ingeschakeld' en herstart de browser wanneer daarom wordt gevraagd.

Mozilla Firefox

In Firefox hoef je niet naar Flags te gaan. Klik op de menuknop in de rechterbovenhoek en selecteer Opties . Scroll in het gedeelte Algemeen naar beneden en klik op Netwerkinstellingen. Vink in het venster dat verschijnt het vakje naast DNS via HTTPS inschakelen aan. Je kunt vervolgens kiezen uit providers zoals Cloudflare en NextDNS om encryptie via HTTPS uit te voeren.

DNS over TLS (DoT): het andere versleutelde pad

DNS over TLS, ofwel DoT, is een andere manier om DNS-query's te beschermen. In plaats van HTTPS gebruikt het TLS via een TCP-verbinding en een gestandaardiseerde poort, 853. TLS is gebaseerd op dezelfde beveiliging als HTTPS, dus het idee is vergelijkbaar: een versleutelde tunnel creëren waarin alleen de twee deelnemers de informatie kunnen decoderen en verwerken. Dit maakt man-in-the-middle-aanvallen moeilijker en voorkomt dat een derde partij de query kan lezen of manipuleren.

DotT heeft voordelen, vooral in vergelijking met traditionele DNS, dat geen beveiligingsmaatregelen biedt. Versleuteling voorkomt dat cybercriminelen verzoeken onderscheppen en belemmert ook bepaalde censuurmaatregelen . Het vereist echter compatibiliteit van zowel de client als de server. Verschillende aanbieders bieden compatibele servers aan, maar gebruik ervan op een desktop of laptop vereist meestal de installatie van extra software; op moderne Android-apparaten, in ieder geval sinds Android 9, is het al geïntegreerd. Er bestaan ​​oplossingen voor Windows en Linux, hoewel die niet altijd zo transparant zijn als men zou willen.

Een van de nadelen is dat DoT, volgens veel experts op het gebied van gegevensbescherming, gebruikmaakt van één herkenbare poort. Hoewel het onmogelijk is om te achterhalen welke website wordt bezocht, is het wel mogelijk om DNS-verkeer te detecteren . Voor sommige netwerkbeheerders is dit nuttig omdat ze zo een overzicht behouden van wat er gebeurt; voor anderen is het een signaal dat ze liever verborgen houden. Bovendien is DoT nog niet zo wijdverspreid als traditionele DNS en is de implementatie ervan aan de serverzijde beperkt. Er bestaat de vrees dat een paar bedrijven de DNS-query's steeds meer zullen concentreren, wat mogelijk een soort internationaal monopolie zou kunnen creëren.

Ministerie van Volksgezondheid versus Ministerie van Transport: Twee manieren om hetzelfde te beschermen

Het belangrijkste verschil tussen DoH en DoT zit hem in de poort en hoe het verkeer wordt gemaskeerd. DoT gebruikt een eigen poort, 853, terwijl DoH poort 443 gebruikt en opgaat in normale HTTPS-verbindingen . Dit ogenschijnlijk kleine verschil heeft tot veel discussie geleid. Vanuit privacyoogpunt is de ononderscheidbaarheid van DNS-query's van ander verkeer een voordeel: als ze niet worden herkend, kunnen ze minder gemakkelijk worden gemanipuleerd. Vanuit het perspectief van netwerkbeheer gaat de controle echter verloren en wordt het lastiger om beveiligings- of filterbeleid te implementeren.

In essentie zijn er twee visies. De IETF, het consortium dat veel internetstandaarden ontwikkelt, staat achter DoT , terwijl Google en de Mozilla Foundation DoH sterk hebben gepromoot. Dit zijn geen tegenstrijdige technologieën, maar ze vertegenwoordigen wel verschillende manieren om privacy, netwerkzichtbaarheid en de rol van tussenpersonen te begrijpen. De keuze tussen de twee hangt af van wat er beschermd moet worden en wie het netwerk moet beheren.

DoH versus een VPN: het beschermt de vraag, niet het hele proces.

DoH en een VPN worden vaak in dezelfde context genoemd als het over privacy gaat, maar ze doen niet hetzelfde. DoH beschermt de naamquery; een VPN beschermt het pad dat uw gegevens afleggen . De eenvoudigste manier om dit te begrijpen is door te bedenken dat DoH een gevoelige vraag in een verzegelde envelop stopt, terwijl een VPN de hele reis door een privétunnel laat gaan voordat deze weer op de openbare weg terechtkomt. Beide kunnen de privacy verbeteren, maar slechts één is ontworpen om het verkeer van telefoons, tablets en computers volledig te beschermen.

Wat doet DNS voordat een website laadt?

Voordat je browser een website kan laden, moet je apparaat zijn locatie weten. DNS werkt als een telefoonboek en vertaalt een websitenaam naar een IP-adres . Dit gebeurt constant: wanneer je een pagina opent, een app start, je e-mail bijwerkt of een video afspeelt. Meestal gebeurt dit ongemerkt en merk je er niets van, wat handig is, maar het maakt het ook makkelijk om het als privacyprobleem over het hoofd te zien. Traditionele DNS-query's zijn niet versleuteld, dus je internetprovider, je werkgever, je school, de wifi van een café of een hotelnetwerk kunnen zien welke domeinen je apparaat probeert te bereiken. Ze zien niet de volledige inhoud van een HTTPS-pagina, maar ze krijgen wel een vrij gedetailleerd beeld van je activiteiten.

Een DNS-query onthult niet elke pagina die je hebt bekeken of alles wat je in een formulier hebt ingevuld, maar een lijst met domeinen kan wel inzicht geven in je gewoonten, interesses, werktools, gezondheidsonderzoek of financiële diensten . Daarom is versleutelde DNS een nuttige privacyfunctie geworden. Het onthult niet alles, maar wel meer dan veel mensen beseffen.

Wat verbergt het ministerie van Volksgezondheid en wat onthult het?

DoH verzendt DNS-query's via HTTPS, hetzelfde versleutelde protocol dat wordt gebruikt door beveiligde websites. Het verzoek verlaat uw apparaat versleuteld en komt aan bij een resolver die de standaard ondersteunt . Op openbare wifi-netwerken kan dit het voor de netwerkbeheerder lastig maken om uw query's per ongeluk te lezen. Als uw internetprovider DNS beheert, kan overschakelen naar een DoH-resolver voorkomen dat ze deze query's op de gebruikelijke manier kunnen zien. Bovendien kan versleutelde DNS bepaalde vormen van manipulatie door een netwerk verminderen.

DoH verbergt de query, niet het hele gesprek. Het kan voorkomen dat sommige waarnemers de domeinlookup duidelijk kunnen zien, maar het verandert je hele internetverbinding niet in een versleutelde tunnel . Zodra het apparaat het IP-adres kent, volgt de rest van de verbinding zijn normale pad, tenzij een andere privacytool die route wijzigt. DoH verbergt je echte IP-adres niet voor de websites, apps of services waarmee je verbinding maakt, en het zorgt er ook niet voor dat het lijkt alsof je je in een andere stad of een ander land bevindt. Als je inlogt op een account, weet de service dat jij het bent. Als de browser cookies, opgeslagen sessies, advertentie-ID's of een herkenbare vingerafdruk heeft, wist DoH die signalen niet.

Het biedt ook geen bescherming aan elke applicatie, tenzij dit op systeemniveau is geconfigureerd en de applicatie die instelling respecteert. De ene browser gebruikt mogelijk beveiligde DNS, terwijl een andere applicatie op hetzelfde apparaat een ander DNS-pad gebruikt . Sommige apps beheren hun eigen netwerk en stemmen dit niet altijd af op de systeem- of browserinstellingen. Daarom kan DoH een vals gevoel van volledige bescherming geven: het verbetert de privacy van DNS-query's, maar het beschermt geen bestandsoverdrachten, berichtenverkeer, videogesprekken, gameverbindingen, synchronisatie op de achtergrond of streamingapplicaties zoals een VPN dat wel zou doen.

Wat beschermt een VPN wel en wat kan het niet verbergen?

Een VPN beschermt een ander aspect van je internetverkeer. Het creëert een versleutelde tunnel tussen je apparaat en een VPN-server, waardoor je internetverkeer via die server loopt . Je internetprovider of lokale wifi-netwerk ziet een versleutelde verbinding met de VPN-server, in plaats van een volledig beeld van elke website en dienst waarmee je verbinding maakt. Bovendien verandert de VPN het openbare IP-adres dat websites en apps zien: in plaats van het IP-adres van je thuis- of mobiele provider, ziet de bestemming het IP-adres van de VPN-server. Dit kan locatiebepaling verminderen, je helpen bepaalde profielen van internetproviders te omzeilen en het gebruik van openbare wifi veiliger maken.

Een uitgebreide VPN kan browsers, streaming-apps, e-mailclients, cloudback-uptools, berichtenapps, games en achtergrondservices beschermen. Een VPN kan ook DNS-verzoeken via de versleutelde tunnel leiden wanneer deze correct is geconfigureerd . Daarom is het verstandig om een ​​DNS-lektest uit te voeren. Een VPN is echter geen tovermiddel. Als u inlogt op een sociaal netwerk, e-mailaccount, streamingdienst of webwinkel, weet die dienst nog steeds wie u bent. Uw oorspronkelijke IP-adres kan verborgen blijven, maar uw inloggegevens worden niet geanonimiseerd. Hetzelfde geldt voor alles wat u rechtstreeks verstuurt: uw naam, e-mailadres, betaalgegevens, verzendadres, foto's of berichten.

Cookies en browserfingerprinting blijven een belangrijk probleem. Apps kunnen soortgelijke problemen veroorzaken via advertentie-identificaties, machtigingen, locatietoegang, Bluetooth-scanning, namen van nabijgelegen wifi-netwerken en scantools. Malware vormt een andere lastige hindernis, omdat het gegevens kan onderscheppen voordat deze de VPN-tunnel bereiken . Kortom, een VPN verbergt en versleutelt veel activiteit, maar maskeert niet elke digitale vingerafdruk.

DoH en een VPN kunnen gelijktijdig worden gebruikt.

Ja, ze kunnen gecombineerd worden, maar de ideale configuratie hangt af van hoe het apparaat, de browser en de VPN-app met DNS omgaan. In veel gevallen is de eenvoudigste oplossing om de VPN de DNS te laten afhandelen . Een goede app zou DNS-query's via de versleutelde tunnel moeten versturen, zodat je internetprovider ze niet rechtstreeks ontvangt. Op deze manier krijg je DNS-privacy als onderdeel van de VPN-verbinding, zonder dat je je browserinstellingen apart hoeft aan te passen.

Het probleem ontstaat wanneer de browser zijn eigen Domain Authority (DoH)-configuratie gebruikt, terwijl de VPN probeert DNS op systeemniveau te beheren. Er hoeft niets kapot te gaan, maar er kan wel verwarring ontstaan : je zou kunnen denken dat alle query's via de VPN lopen, maar in werkelijkheid stuurt de browser sommige query's zelf naar een andere resolver. Hier komt een DNS-lektest van pas. Als je na het verbinden met de VPN de DNS-servers van je internetprovider ziet, werkt er iets niet zoals verwacht; als je servers ziet die aan de VPN zijn gekoppeld, werkt de configuratie waarschijnlijk correct.

Wanneer is DoH voldoende en wanneer is een VPN aan te raden?

DoH kan voldoende zijn als uw voornaamste zorg de basisprivacy van DNS-query's in uw browser is. Op een vertrouwd thuisnetwerk vermindert het inschakelen van Secure DNS de blootstelling van onversleutelde gegevens zonder dat u uw locatie hoeft te wijzigen of al uw applicaties hoeft te beveiligen . Het is ook nuttig op netwerken waar DNS-filtering of -manipulatie een probleem vormt, omdat het via HTTPS verzenden ervan moeilijker is om gegevens te inspecteren of te wijzigen. Dit betekent niet dat alle beperkingen worden omzeild of dat het censuurbestendig is, maar het is een aanzienlijke verbetering ten opzichte van onversleutelde DNS. Bovendien is het lichtgewicht: u hoeft geen VPN-server te kiezen of uw routering ingrijpend te wijzigen, en u zult doorgaans geen significant verschil in snelheid merken.

Een VPN is vooral handig als je apparaatbrede bescherming wilt, niet alleen DNS-zoekopdrachten. Denk bijvoorbeeld aan luchthavens, hotels, scholen, coworkingruimtes, cafés en vakantiehuizen . Op gedeelde netwerken weet je immers niet wie de router beheert, wie er nog meer verbonden is of of iemand probeert je internetverkeer te onderscheppen. Een VPN is ook nuttig als je niet wilt dat je internetprovider een profiel van je surfgedrag opbouwt: hoewel HTTPS de inhoud van webpagina's beschermt, kunnen netwerkmetadata nog steeds nuttige patronen onthullen. Reizen is een ander duidelijk voorbeeld: een VPN kan je verbinding stabieler maken, je beschermen op onbekende netwerken en ervoor zorgen dat websites de locatie van de VPN-server zien in plaats van je tijdelijke lokale verbinding.

Technische details van de Google Public DNS DoH API's

Google Public DNS biedt twee verschillende DoH-API's. De ene is ontworpen voor RFC 8484 en accepteert GET- en POST-verzoeken op https://dns.google/dns-query; de andere is een JSON-API die alleen GET-verzoeken ondersteunt op https://dns.google/resolve . Er is ook een webinterface op https://dns.google/ die JSON-resultaten in de browser weergeeft, maar deze implementeert geen volledige API. Deze interface moet niet worden verward met de API-URL's of met https://dns.google/query. De service ondersteunt geen onbeveiligde HTTP-URL's en DoH wordt ook ondersteund door Google's openbare DNS64-service, hoewel in dat geval alleen IPv6 wordt ondersteund. De documentatie van Google over beveiligd transport bevat curl-voorbeelden en details over TLS, DoT en DoH.

Beschikbare HTTP-methoden

De GET-methode kan de latentie verlagen omdat deze efficiënter cachet. RFC 8484 GET-verzoeken moeten een `?dns=`-parameter bevatten met een Base64Url-gecodeerd DNS-bericht , en dit is de enige methode die door de JSON API wordt ondersteund. De POST-methode is ook alleen beschikbaar in RFC 8484 en gebruikt een binair DNS-bericht met `application/dns-message` in zowel de verzoek- als de antwoordbody. De HEAD-methode wordt momenteel niet ondersteund en retourneert een 400 Bad Request-fout. Andere methoden retourneren 501 Not Implemented-fouten.

Statuscodes en fouten

De API retourneert verschillende HTTP-codes die het waard zijn om te kennen. Een 200 OK geeft aan dat de HTTP-parsing en de communicatie met de DNS-resolver succesvol waren ; de responsbody kan een binaire DNS-respons of JSON zijn, afhankelijk van het eindpunt, de Accept-header en de GET-parameters. Let op: een HTTP-fout kan ook een DNS-fout zijn, dus het is raadzaam om de DNS-responscode te controleren, bijvoorbeeld het veld "Status" in de JSON, op fouten zoals SERVFAIL, FORMERR, REFUSED of NOTIMP.

• 301 is permanent verhuist: De client moet het verzoek opnieuw proberen op de URL die is opgegeven in Location. Als het oorspronkelijke verzoek een POST-verzoek was, mag het alleen opnieuw worden geprobeerd met een GET-verzoek als de nieuwe URL een DNS-parameter bevat; anders moet het opnieuw worden geprobeerd met een POST-verzoek. Er kunnen ook statuscodes 302, 307 en 308 verschijnen, en DoH-clients moeten deze vier afhandelen. Permanente statuscodes 301 en 308 kunnen onbeperkt in de cache worden opgeslagen. POST-verzoeken die een statuscode 307 of 308 ontvangen, moeten altijd opnieuw worden geprobeerd met een POST-verzoek.
• 400 Foute aanvraag: Problemen met het parsen van GET-parameters of een ongeldig DNS-verzoekbericht. De meeste ongeldige DNS-berichten ontvangen een 200 OK met FORMERR, maar er treden HTTP-fouten op bij onleesbare berichten zonder een vraaggedeelte, met een QR-code die een antwoord aangeeft, of met onzinnige combinaties van codes.
• 413 Laadvermogen te groot: De inhoud van een POST RFC 8484-verzoek overschrijdt de maximale berichtgrootte van 512 bytes.
• 414 URI te lang: De GET-queryheader was te groot of de DNS-parameter overschreed 512 bytes.
• 415 Niet-ondersteund mediatype: De POST-body bevatte niet de contenttype-header application/dns-message.
• 429 te veel verzoeken: Er zijn te veel verzoeken verzonden in een bepaalde periode. De client moet wachten tot het tijdstip dat is opgegeven in de Retry-After-header.
• 500 Internal Server Error: Interne fouten in de dienstverlening van het ministerie van Volksgezondheid.
• 501 Niet geïmplementeerd: Alleen GET en POST zijn geïmplementeerd; de rest geeft deze foutmelding.
• 502 slechte gateway: De DoH-service kon geen verbinding maken met de openbare DNS-resolvers van Google. Het proberen van een ander adres zou kunnen werken, maar een effectievere back-up is om een ​​andere DoH-service te proberen of over te schakelen naar traditionele DNS via UDP of TCP op 8.8.8.8.

Beste praktijken voor privacy en prestaties

Ontwikkelaars van DoH-applicaties moeten het aantal HTTP-headers beperken. Headers zoals Cookie, User-Agent en Accept-Language kunnen informatie over de clientimplementatie onthullen en bijdragen aan de-anonimisering . Het is aan te raden alleen de headers te verzenden die nodig zijn voor DoH: Host, Content-Type (voor POST-verzoeken) en, indien nodig, Accept. De User-Agent-header moet worden opgenomen in ontwikkelings- of testversies. Het is ook raadzaam om EDNS-paddingopties te gebruiken om query's in te korten tot een gangbare lengte en verkeersanalyse te bemoeilijken. HTTP/2-padding is mogelijk, maar in tegenstelling tot EDNS-padding genereert het geen padding in DoH-serverreacties.

De POST-methode in RFC 8484 mag alleen worden gebruikt in privacygevoelige toepassingen of browsermodi. Het gebruik van POST vermindert de cachecapaciteit en kan de latentie verhogen, dus het wordt over het algemeen afgeraden . Het verkleinen van de cachegrootte kan echter wel raadzaam zijn voor toepassingen die synchronisatieaanvallen op webapplicaties willen voorkomen, gericht op het achterhalen welke domeinen de gebruiker recent heeft bezocht. De HTTPS-aanpak heeft ook praktische voordelen: HTTPS API's zijn breed beschikbaar en worden ondersteund, wat de implementatie vereenvoudigt; een HTTPS-service geeft webapplicaties toegang tot alle soorten DNS-records, waardoor de beperkingen van browser- of besturingssysteem-API's, die doorgaans beperkt zijn tot host-naar-adres-lookups, worden vermeden; en clients die HTTPS over UDP met QUIC implementeren, kunnen problemen zoals line-head blocking die bij TCP optreden, voorkomen. Als u een bug tegenkomt of een nieuwe functie wilt aanvragen, moet u het DoH-gerelateerde probleem via de gebruikelijke kanalen melden.

Veelgestelde vragen over DoH en VPN

Een van de meest gestelde vragen is of het zinvol is om DoH te gebruiken als je al een VPN gebruikt. Het is mogelijk, maar de meest praktische aanpak is meestal om de VPN de DNS-afhandeling te laten verzorgen en met een lektest te controleren of de query's via de juiste kanalen lopen. Als de browser zijn eigen query's op een bepaalde manier verstuurt en de VPN op een andere manier, kun je voor een onaangename verrassing komen te staan.

Een andere veelgestelde vraag is of DoH voorkomt dat je internetprovider kan zien welke websites je bezoekt. DoH verbergt DNS-query's voor veel waarnemers, maar het verwijdert niet alle metadata en verbergt je IP-adres niet : je internetprovider kan nog steeds zien met welke IP-adressen je verbinding maakt en andere netwerkinformatie. Voor een bredere bescherming heb je een VPN of een combinatie van meerdere privacylagen nodig.

Het is ook de moeite waard om te vragen of DomainHost (DoH) voldoende bescherming biedt op openbare wifi-netwerken. Het kan voorkomen dat de netwerkbeheerder uw DNS-query's gemakkelijk kan onderscheppen, maar het beschermt niet de volledige verbinding of het verkeer van alle applicaties . Op luchthavens, in hotels en cafés is het gebruik van een VPN meestal een betere oplossing, vooral als u niet weet wie de router beheert of of er andere mensen online zijn.

Het Domain Name System (DNS) en VPN's zijn geen directe concurrenten, maar eerder tools met verschillende mogelijkheden. Een DNS versleutelt de domeinopzoeking en vermindert de kwetsbaarheid van dat deel van het proces; een VPN versleutelt het pad tussen uw apparaat en een server en wijzigt het IP-adres dat door de bestemming wordt gezien . Geen van beide maakt u onzichtbaar: accounts, cookies, browserfingerprints, app-machtigingen, malware en alle gegevens die u rechtstreeks deelt, kunnen u nog steeds identificeren. Maar dat maakt ze niet nutteloos. Het betekent simpelweg dat ze elk hun eigen rol hebben. Een DNS beschermt de adresopzoeking; een VPN beschermt een veel groter deel van het pad dat uw gegevens afleggen.