Overheid VS onderzoekt dns-over-https bij Google vanwege concurrentiezorgen

De juridische commissie van het Amerikaanse Huis van Afgevaardigden is een onderzoek gestart naar de implementatie van dns-over-https door Google. De commissie is mogelijk bang dat Google dns naar zich toe wil trekken en zo meer macht over het internet krijgt.

De juridische commissie wil weten of Google de data die het zou kunnen verzamelen door dns-over-https aan te zetten, commercieel wil gebruiken, meldt The Wall Street Journal. Daarom heeft de commissie een brief met vragen aan de zoekgigant gestuurd.

Dankzij de stap naar dns-over-https slaat de browser de dns van providers over en legt een beveiligde verbinding met een dns-server. Googles implementatie is vooralsnog dat de dns van gebruikers het gebruik van doh moet ondersteunen om het te kunnen gebruiken. Firefox-maker Mozilla kiest voor een agressievere aanpak en zet gebruikers standaard over naar 1.1.1.1 van Cloudflare, die doh ondersteunt.

Bij dns-over-https wordt een dns-query versleuteld met ssl- of tls-encryptie. Daardoor kunnen andere partijen zoals providers niet meer meekijken naar welke webpagina's specifieke gebruikers opvragen. Hoewel de beslissing op het eerste gezicht goed lijkt voor de privacy van gebruikers, is niet iedereen even blij met de beslissing. In Engeland, waar strengere internetregels gelden, waren internetproviders lange tijd niet blij met het plan. Door de versleuteling kunnen providers bijvoorbeeld niet meer kijken welke url's worden bezocht, wat in Engeland problemen zou opleveren met het beruchte pornofilter. In de VS geldt hetzelfde. Ook cdn Akamai is tegen dns-over-https. Sommige gebruikers zijn er bovendien niet blij mee omdat het proces betekent dat een dns-query via een centrale dns-provider als Cloudflare of Google wordt verstuurd.

Door Arnoud Wokke

Redacteur

30-09-2019 • 13:32

76 Linkedin

Submitter: aliencowfarm

Reacties (76)

76
76
50
14
1
23
Wijzig sortering
Hoewel de beslissing op het eerste gezicht goed lijkt voor de privacy van gebruikers is niet iedereen even blij met de beslissing.
Hierna wordt wel opgesomd wie er niet blij zijn, maar niet waarom. Zijn er nadelen voor de gebruiker? Is het naast op het eerste gezicht, uiteindelijk niet echt goed voor de privacy en waarom precies?
Hierna wordt wel opgesomd wie er niet blij zijn, maar niet waarom. Zijn er nadelen voor de gebruiker? Is het naast op het eerste gezicht, uiteindelijk niet echt goed voor de privacy en waarom precies?
Het gaat allemaal om de vraag wie jij vertrouwt. Je DNS-provider (of die nu DoH of iets anders gebruikt) kan in principe* al je DNS-queries zien en daarmee precies volgen wat je op internet doet.
Kennis is macht, en je moet je dus afvragen aan wie jij die macht wil geven.

Traditioneel gezien gebruiken de meeste mensen een DNS-resolver van hun internet provider (ISP). Dan is het dus je ISP die precies kan zien welke sites je bezoekt. Van oudsher is de gedachte dat je je eigen ISP moet vertrouwen of anders overstappen naar een andere ISP. Als je je ISP niet kan vertrouwen heb je een groter probleem dan DNS (zeker vroeger toen encryptie nog niet gebruikelijk was en iedereen een e-mail-account van de ISP gebruikte).

De laatste jaren is daar verandering in gekomen. Enerzijds omdat er (met name buitenlandse) ISPs zijn die misbruik van hun macht maken en hun eigen gebruikers dataminen. Anderzijds omdat de overheid zich steeds meer met internet is gaan bemoeien en blokkades en taps uitvoert met medewerking van de ISPs. Ook dat valt in Nederland relatief gezien mee, maar er zijn landen waar de internetverbindingen streng worden gecontroleerd. Al met al is het vertrouwen in de ISPs gedaald.

Op die gronden is er dus een argument te maken dat je beter DNS-over-HTTP van Google/Cloudflare/<WebReus> kan gebruiken, want dan kunnen je lokale overheid en je lokale ISP niet zien wat jij op internet doet. In die zin is het goed voor de privacy, en is sommige landen ook je persoonlijke veiligheid en vrijheid.

Daar staat wel tegenover dat je meer informatie geeft aan je DoH-provider. Het risico bestaat dat die er iets mee doet wat jij niet ziet zitten, zoals reclameprofielen op stellen en doorverkopen. Ook bestaat het risico dat een overheid (bv de Amerikaans) zo'n organisatie dwingt om jouw data te overhandigen, zonder dat je het zelf weet of je er tegen kan verzetten.

DoH heeft ook nog een paar concrete nadelen, zoals dat split-DNS niet werkt en dat beveiligingsmaatregelen die werken via lokale DNS buiten spel worden gezet.

De vraag of DoH goed is voor de privacy of niet is dus niet eenvoudig te beantwoorden. Het ligt aan de omstandigheden en vooral aan de vraag wie jij vertrouwt en wie niet.

* Er zijn verschillende systemen in ontwikkeling om DNS verder te beveiligen tegen dit soort problemen maar die zijn allemaal nog vrij experimenteel.
Mooie reactie. Als ik even praktisch mag aanvullen (in de hoop dat ik het correct heb begrepen):

1. DNS-over-HTTPS is een goed protocol en geeft potentieel een betere bscherming van de privacy
2. De gebruiker (of diens organisatie) kan zelf kiezen om DoH uit te zetten, dan wel om DoH te implementeren via een eigen service provider
3. Hooguit de mate waarin de DOH service provider zijn systeem oplegt aan de gebruikers (bvb door die als default in een browser in te stellen), kan als kwalijk gezien worden
4. In zoverre de DoH service provider geen 1:1 link kan leggen tussen een individuele gebruiker en een DNS request, verwateren de bezwaren tegen dergelijke gecentraliseerde DoH-systemen.

Conclusie: per familie / vriendenkring / bedrijf een eigen caching/resolving DNS-systeem opzetten dat op zich perfect gebruik mag maken van de DoH-systemen van Google, Cloudflare, Microsoft en whatnot.

[Reactie gewijzigd door zenlord op 30 september 2019 15:09]

1. DNS-over-HTTPS is een goed protocol en geeft potentieel een betere bscherming van de privacy
Ik doe geen uitspraken over de kwaliteit van het protocol zelf, daarvoor ken ik het nog niet genoeg.

Of het beter is voor de privacy is erg afhankelijk van de omstandigheden.

Ik geef mijn data liever niet aan Google/Cloudflare/GroteToko, maar gebruik ik liever de DNS-resolver van een Nederlandse provider die onder de Nederlandse wet en toezicht valt.

Als je je netwerkprovider minder vertrouw dan een DoH-aanbieder dan is DoH beter.

Dit zijn overigens niet de enige twee keuzes. Er zijn meer mogelijkheiden, zoals DNS-over-TLS, DNS-over-DTLS en DNSCrypt die misschien wel een betere keuze zijn.
2. De gebruiker (of diens organisatie) kan zelf kiezen om DoH uit te zetten, dan wel om DoH te implementeren via een eigen service provider
Correct, al is er wat ophef omdat de meeste gebruikers niet zullen beseffen dat er iets is veranderd.
Daarnaast kan het erg misleidend zijn dat je webbrowser een ander DNS-mechanisme gebruikt dan de rest van je systeem. Dat gaat tegen alle precedent in.
3. Hooguit de mate waarin de DOH service provider zijn systeem oplegt aan de gebruikers (bvb door die als default in een browser in te stellen), kan als kwalijk gezien worden
Correct, al hebben die service providers daar typisch niks over te zeggen. In praktijk is het een keuze van de browserbouwers. Dat is een beetje gek, want traditioneel bemoeiden die zich niet met DNS. Nu zou je kunnen zeggen dat de browsers het beleid van de lokale beheerder ondermijnen, door een alternatieve DNS-dienst te gebruiken waar de rest van het OS niks van ziet.
4. In zoverre de DoH service provider geen 1:1 link kan leggen tussen een individuele gebruiker en een DNS request, verwateren de bezwaren tegen dergelijke gecentraliseerde DoH-systemen.
Dan vervalt één van de bezwaren.
Ik zie zelf nog wel andere bezwaren.
Persoonlijk vind ik bijvoorbeeld dat Google veel te veel invloed heeft op deze wereld. Ieder extra stukje data dat ze krijgen is er een te veel, ook als dat data van grote anonieme groepen is.
Een ander bezwaar is dat ook wel een risico is om allemaal dezelfde centrale DNS-server te gebruiken. Als daar iets mis gaat valt half internet uit. Momenteel is DNS zeer gedistribueerd en treden storingen vooral lokaal op.
Conclusie: per familie / vriendenkring / bedrijf een eigen caching/resolving DNS-systeem opzetten dat op zich perfect gebruik mag maken van de DoH-systemen van Google, Cloudflare, Microsoft en whatnot.
Lokale DNS-resolvers zijn inderdaad een goed idee. Of groeperen per familie/bedrijf genoeg is zal je zelf moeten bepalen. Ik kan me voorstellen dat in de meeste gezinnen onmiddelijk duidelijk is wie er "xxx.com" bezoekt en wie "abortus.org". Of je die informatie liever deelt met je internetprovider of met een datahark zal je zelf moeten bepalen.

[Reactie gewijzigd door CAPSLOCK2000 op 30 september 2019 16:59]

Waarom doe je dan niet gewoon direct dns op de root ipv je provider. Probleem opgelost.
Omdat je er niet zo heel veel mee opschiet, DNS pakketjes gaan onbeveiligd over de lijn en kunnen eenvoudig door mijn provider worden afgetapt.


Dat is in ieder geval het theoretische antwoord voor de gewone mens. ;)
In praktijk draai ik thuis m'n eigen DNS-servers die beveiligd zijn met ieder denkbaar experimenteel protocol, waaronder maatregelen om te voorkomen dat m'n provider de pakketjes kan aftappen.
volgensmij heb je een hele goede case om dan zeen rechtzaak aan te spannen in NL,

Als je hun DNS server gebruikt tja dan geef je ze data , Als je root servers gebruikt mag een ISP niet zomaar je lijn afluisteren zonder dat ze toestemming hebben van een overheids instantie.

Ik snap je punt wel, en er zijn legio oplossingen VPN naar cloud machine etc maar jouw punt specifiek heeft niks met DNS te maken maar met het algehele punt moeten we een cull C2C encrypted internet maken / willen.

nadeel is dat het een beetje rommeld met de foundations van internet om een open en vrij platform te zijn waar iedereen alles samen deelt.. Ja ik weet dat hier al meer aan gesleuteld wordt maar we moeten elke keer weer een extra conpromi doen. encrypted DNS onder het mom van anonimiteit leverd ook weer een stukje veiligheid in gezien opsporings diensten het weer moeilijker gaan krijgen criminelen oprollen.

De hamvraag uiteindelijk is wat is belangrijker Jouw privacy of criminelen netwerken moeilijk maken te vinden. Is jouw privacy zo belngrijk voor je dat je dat tenkosten van aanslagen wilt laten gaan.
volgensmij heb je een hele goede case om dan zeen rechtzaak aan te spannen in NL,
In theorie wel, in praktijk heb ik liever technische bescherming dan juridische bescherming. Die eerste voorkomt concrete problemen, die tweede heb ik pas iets aan als het al fout is gegaan. (Allebei zijn nodig, net zoals je zowel verkeersregels nodig hebt, als gordels en bumpers.)
Ik snap je punt wel, en er zijn legio oplossingen VPN naar cloud machine etc maar jouw punt specifiek heeft niks met DNS te maken maar met het algehele punt moeten we een cull C2C encrypted internet maken / willen.
Daar ben ik het eigenlijk wel mee eens, maar als ik er pragmatisch naar kijk is DNS momenteel een van de zwakke punten. Ons webverkeer versleutelen we in inmiddels vrij aardig met https, waardoor DNS nu het volgende zwakke punt is geworden.
De hamvraag uiteindelijk is wat is belangrijker Jouw privacy of criminelen netwerken moeilijk maken te vinden. Is jouw privacy zo belngrijk voor je dat je dat tenkosten van aanslagen wilt laten gaan.
Dat is een valse tegenstelling waar ik niet in mee wil gaan. We hoeven niet te kiezen tussen veiligheid en privacy. Geen van de grote aanslagen uit de afgelopen 20 jaar had voorkomen kunnen worden met minder privacy. In de meeste gevallen was zelfs wel duidelijk dat er iets mis was met de aanslagplegers maar hebben we daar domweg niks mee gedaan.
Er is echt wel een relatie tussen beveiliging en het werk van de politie, maar het is nooit zo zwart-wit, en gebrek aan beveiliging is een groter probleem. Zo sluit ik steeds mijn voordeur tegen dieven, ook al sluit ik daar ook de politie mee buiten.
anders ander zijn er aardig wat aanslagen verijdelt door succesvolle afluistering, iets wat je nu gaat bemoeilijken.

de vergelijking met je deur snap ik niet helemaal amls de politie binnen moet zijn is de deur al opengemaakt voor ze door de boeven.

en ik denk dat je ze maar al te graag binnen laat nadat alles gestolen is en er mensen gewond zijn in huis door dat de inbreker iets te agresief was en dat je dan niet even je deur opnieuw gaat sluiten.

ik snap dat ik het heel zwart wit neer zet maar dat maakt het probleem wel heel duidelijk.,

Secure internet Ja, security door privacy , twijfel.

Beetje zelfde verhaal als alle ISP verplichten logs te verwijderen na 1 uur, Goed voor jouw privacy , maar ook goed voor malifide acties te verbergen.

[Reactie gewijzigd door Scriptkid op 1 oktober 2019 17:25]

Klinkt als een boeiende case @CAPSLOCK2000 , care to share?
2. De gebruiker (of diens organisatie) kan zelf kiezen om DoH uit te zetten,
Is dat wel zo? Ik kan een DoH client binnen mijn netwerk niet zomaar blokkeren, het is immers HTTPS verkeer.
Kijk naar de Google Chromecast met hardcoded DNS. Met wat truken is die nog wel te blokkeren, maar als Google besluit DoH te gaan gebruiken zal het een stuk complexer worden om een Chromecast te forceren een lokale dns server te gebruiken,
In zoverre de DoH service provider geen 1:1 link kan leggen tussen een individuele gebruiker en een DNS request,
De mogelijkheden om een link te leggen aan een individuele gebruiker zijn niet anders dan bij een gewone DNS oplossing.
Mooie reactie. Als ik even praktisch mag aanvullen (in de hoop dat ik het correct heb begrepen):
1. DNS-over-HTTPS is een goed protocol en geeft potentieel een betere bscherming van de privacy
De bescherming/gebruikers informatie Is hoofdzakelijk verschoven, het is meer, wat is het beste van twee kwaden bij data misbruik. Ik vertrouw dan eerder mijn lokale ISP met de lokale regelgeving.
Ik ben zelf ook pro DoH en DoT. Houd er met DoH echter rekening mee dat in het geval van dat de SNI van het HTTPS transport niet versleuteld is, uiteindelijk (zij het wat met meer moeite) alsnog gegevens zijn te achterhalen.

Dat gezegd hebbende, DoH en DoT zijn technieken die we snel moeten omarmen. En HTTP en DNS-plain-text snel droppen in support.
Klasse reactie, wat mij betreft houden we deze macht mooi binnen Nederland. En dit is een zeer serieuze zero sum aanval op dns wat mij betreft.
Het gaat om wie er vertrouwd kan worden met een macht die de uitslag van verkiezingen kan bepalen, ik denk dat de het perspectief is waarmee naar dit onderzoek gekeken dient te worden.

Controle over het DNS verkeer door een enkele groep of partij betekend dat je de gedachten of effectiviteit van bepaalde websites kunt beïnvloeden.

Je kunt bijvoorbeeld bepaalde soort reclames meer naar het publiek van politieke tegenstanders sturen om ze ongemakkelijk en zo minder effectief te maken op bepaalde websites, of je kunt gewoonweg soms wat routeringspakketjes droppen onder het mom van traffic shaping (er is geen net neutraliteit meer) en ga zo maar door wat Google hiermee kan doen.

Google heeft alle services in handen om deze macht te misbruiken en er worden nu vragen gesteld vanuit de regering of hier nu een halt aan toe geroepen

En dan nog is er het vraagstuk of een corporatie onafhankelijk meer macht over alle informatie dan een nationale regering mag hebben, denk aan 5G, spionage en China.
Natuurlijk is het belangrijk te bepalen wie jij vertrouwd en om die reden vind ik het van groot belang dat er veel meer DoH oplossingen komen waarbij je via een random selector requests naar een va de vele DoH instances kunt sturen. Met een soort van sticky session oplossing om bijvoorbeeld de als de Google server gebruikt is om pornhub.com re resolven zij ook de volgende keer deze query krijgen. Op die manier splitst jouw encrypted DNS verkeer tussen vele verschillende providers, en is het hele erg veel moeilijker voor deze bedrijven om een compleet profiel van je op te stellen.

Het grootste probleem is dat als een overheid hier iets tegen wil doen ze simpel erg de route naar de verschillende DoH providers kunnen blokkeren om je op die manier te dwingen de landelijke DoH dienst te gebruiken en op deze manier toch te kunnen controleren wat jij zo al bekijkt online.

Ik ben er erg op tegen om altijd maar de zelfde DNS provider te gebruiken en ik zou heel erg veel liever zien dat je een flinke lijst van zeg 100 verschillende DNS providers hebt die allemaal ongeveer 1% van je DNS verkeer ontvangen op die manier is het praktisch gezien niet mogelijk om een volledig profiel op te stellen van de persoon die de requests af vuurt zeker niet als deze DNS providers onder verschillende wetgevers vallen en dus niet door een land gedwongen kunnen worden om alles wat ze over jouw hebben te overhandigen waarna de overheid er een volledig plaatje van kan maken.

Ik zie wel wat problemen met die aanpak, zo veel servers kan leiden tot een tragere resolutie omdat er gegarandeerd een aantal van deze servers een tragere link zien tussen jouw en de server. Ook is er het probleem dat overheden zo als de Amerikaanse absoluut geen zin hebben in dit soort oplossingen omdat zij veel liever zouden zien dat zij alle data netjes op een presenteerblaadje zouden krijgen aangereikt.
Ik gok dan ook dat het nog heel lang gaat duren voor dit soort oplossingen ook echt werkelijkheid zullen worden omdat de over grote meerderheid van de software die hier voor nodig is ontwikkeld wordt door Amerikaanse organisaties (al dan niet commercieel). Om deze reden is het niet waarschijnlijk dat het bedrijven zo als Google zal lukken om echt een van uit een privacy oogpunt veilige DNS oplossing te ontwikkelen.
ISPs kunnen niet meekijken, maar de DoH provider (wat mogelijk best je ISP kan zijn) kan dit nog steeds.

Vele bedrijven maken gebruik van eigen DNS servers om interne (privé) servers bereikbaar te maken via namen inplaatst van IP adressen. Doordat de browsers de system DNS settings gaan negeren(/deels overrullen) komt die info ineens bij een externe partij te liggen. Volgens mij is het hebben van een eigen DNS ook een vereiste voor het gebruik van AD.

Daarnaast kan je privé ook prima redenen hebben om je eigen DNS te gebruiken, denk bijvoorbeeld aan pi-hole.

[Reactie gewijzigd door Caayn op 30 september 2019 13:53]

Die bedrijven kunnen dan ook netjes hun eigen name servers zo configureren dat zij tegen de browser zeggen dat ze dat niet moeten doen via een canary domain die hier specifiek voor bedacht is (die wordt eerst geraadpleegt conform de OS-instellingen voordat de verkenner z'n DoH dingen gaat doen)
https://support.mozilla.o...in-use-application-dnsnet
(Zowel Firefox als Chrome luisteren hier naar), en anders moet de netwerkbeheerde het met policies dicht zetten.
Is het canary domain een geaccepteerde standaard of het is weer iets wat per applicatie/browser verschilt?

Policies ben ik sowieso een voorstander van, maar applicaties die vanuit zichzelf system settings negeren vind ik dan ook weer niet netjes. Met iedere update kan je dan de sjaak zijn als er een nieuwe feature/setting wordt toegevoegd en je niet op tijd bent met het bijwerken van de policies.

[Reactie gewijzigd door Caayn op 30 september 2019 14:15]

Zover ik weet is dit domain verzonnen door Mozilla en heeft Google aangegeven het ook te honoreren, al kan ik van dat laatste even geen bron vinden. Het is dus inderdaad niet optimaal, maar wel relatief makkelijk te implementeren.

Policies doen bijvoorbeeld niet altijd zo veel als iemand besluit om een Portable applicatie te starten. (is ook wel tegen te gaan natuurlijk, maar dat is veelal gedoe)
Sterker nog, chrome negeert al je dns verzoeken op Android als je die optie niet uitdrukkelijk uit zet. Dat moet je eerst doen om je hosts-file based adblockers te laten werken...
Anoniem: 470811
@Caayn30 september 2019 18:42
Google Chrome kijkt naar je DNS instelling en ziet: 192.168.178.1.1 en ziet dan dat hij het niet kan upgraden naar DNS-over-HTTPS.

Mijn vraag/twijfel zit hem meer dus in: kijkt Chrome naar je lokale DNS setting? Of naar de uiteindelijke externe DNS server? Ik vermoed het eerst, en de grap is dan dat bij het leeuwendeel van de mensen DoH niet eens aangaat, omdat daar het router-iepeetje staat.
Ik merk wel dat google alles, onder het mom van privacy en security, aan het dichtschroeven is. Maar dat ze hun eigen business ongemoeid laten. Op deze manier wordt het steeds moeilijker om er tussen te komen.
Dat zeg je maar heb je er ook even een concreet voorbeeld van?

Want Google maakt met Chrome al lange tijd gebruik van ingebouwde DNS clients, net als apparaten zoals Chromecast. Microsoft doet precies hetzelfde... Daar is dus niets nieuws.

Dat men nu DoH implementeert is gewoon goed gebruik maken van een open standaard (zie ook Mozilla).
Akamai snuffelt DNS-verkeer om webverzoeken efficienter te kunnen serveren.
https://blogs.akamai.com/...for-evolving-the-dns.html
Centralized DNS resolvers (such as some of the DoH servers deployed today) may provide increased privacy against a local network observer, but they can also result in significantly impaired Internet performance for users in some cases. For example, CDNs such as Akamai that map traffic based on DNS may lose the ability to direct end-user traffic to a nearby cluster in cases where a DNS service is being used that is not affiliated with the local network and which does not send "EDNS Client Subnet" (ECS) information to the CDN's DNS authorities
Het VK (waar Engeland deel van uit maakt) wil o.a. een effectief pornofilter door ISP's laten uitvoeren (kort door de bocht met een soort digid-achtig systeem om te verifieren dat je 18+ bent)
nieuws: VK stelt verplichte leeftijdsverificatie voor online porno uit
nieuws: Regering VK wil onlineplatforms aansprakelijk stellen voor schadelijk...

De VS zou ik niet weten (mijn vermoeden is weer is de terreurtroef, maar dat is alleen gebaseerd op mijn vermoeden en niks anders)
Akamai kijkt naar source IP van DNS queries die bij de eigen (authoritative) nameservers aankomen. Als je, zeg, www.cloudflare.com resolv't via de nameserver van je ISP komt niets daarvan bij Akamai. Als je www.akamai.com resolv't via Cloudflares 1.1.1.1 komt Cloudflare daar wel alles van te weten.
Het beperkt nogal de mogelijkheden om te filteren. Er zijn mensen die bijvoorbeeld piHole gebruiken om advertenties en andere troep te weren in hun netwerk, maar er zijn ook providers die een service aanbieden om bijvoorbeeld pornografie te weren. Als gebruikers niet meer kunnen vertrouwen op hun ingestelde DNS, dan werken dit soort dingen ook niet meer.
Verstandig. Het is ook een zorgelijke ontwikkeling, en dan met name dat het standaard geactiveerd wordt in Firefox. DNS+SSL kan je provider ook prima in voorzien en de browser heeft zich daar helemaal niet mee te bemoeien. Op een systeem wil je een gecentraliseerde DNS-oplossing, niet iets wat het besturingssysteem bypassed.
DNS+SSL kan je provider ook prima in voorzien en de browser heeft zich daar helemaal niet mee te bemoeien.
Het probleem(pje) is alleen dat de providers het blijkbaar niet (willen?) doen.
Ook doet je OS het niet standaard en vereist het dus extra software (althans, zover ik weet (ik word graag gecorrigeerd), spreken Windows/Linux/MacOS/iOS standaard geen DoH, Android heeft tegenwoordig wel de optie).
Op deze manier ondersteund je internetverkenner het in elk geval wel, zonder dat je als eindgebruiker 'ingewikkelde dingen' hoeft te doen om iets meer privacy te hebben.

Idealiter zou inderdaad je OS het zelf doen, en de DNS-provider van je netwerkverbinding, maar dan moet je die wel vertrouwen (publieke wifi netwerken) en hopen dat zij hun beveiliging op orde hebben. Dan is een externe partij allicht een beter idee (Of je Google/Cloudflare vertrouwd/ziet zitten of niet, zijn ze wel een redelijk veilige keuze als het gaat om hun eigen beveiliiging)

Ik ben het overigens met je eens dat Firefox het wel heel erg aggressief doet. (Het had fijner geweest als ze bij de eerste keer opstarten je een keuze forceren te geven en eventueel wat meer keuzes dan alleen Cloudflare, maar dan moet Mozilla als die andere clubs wel vertrouwen)
Bind ondersteund RFC 7858 als DNS server, Linux kan ermee overweg, dus wat is het probleem? Ik zou eerlijk gezegd niet weten of providers (in Nederland) het aanbieden, maar ik draai toch mijn eigen DNS-server. Van Windows weet ik het ook niet, dat gebruik ik niet ;)

Mij wordt nu een oplossing voor een niet-bestaand probleem door de strot geduwd. Ik heb het vanzelfsprekend hard uitgezet in Firefox maar het had in de eerste plaats niet automatisch aangezet moeten worden.

En dan nog, dan kunnen deze partijen beter gaan lobby'en bij Microsoft e.d. om support voor DNS-over-TLS of DNS-over-HTTPS in te bouwen, in plaats van het heft in eigen hand nemen en het door de strot duwen vanuit de browser. Het geeft een inconsistente user experience.
Je kan toch je bind9 configureren om te reageren op het eerdergenoemde canary domain? Dan zou Firefox zijn ingebouwde DoH resolving niet eens moeten aanspreken. Ik ga mijn eigen bind9 servertje in ieder geval zeker even herconfigureren. :D
Dat kan, maar dat is opt out. Slechte zaak. Net als die rare suffix die ik aan mijn SSID zou moeten geven voor opt-out van Google. Dit soort zaken moeten opt-in zijn, niet opt-out.
Bind ondersteund RFC 7858 als DNS server
Ik doel op de DNS-client van het OS. Bind is gewoon een stuk software dat zowel onder Linux als Windows draait en heeft hier niet zo veel mee te maken.
Mij wordt nu een oplossing voor een niet-bestaand probleem door de strot geduwd.
Er is wel degelijk een probleem. Kort door de bocht is je DNS-verkeer is het enige stukje verkeer dat nog niet gecodeerd je internetlijn op gaat. Als je je eigen DNS-server draait gaat de boel nog steeds ongecodeerd de lijn op, en is het aan jouw IP te correleren door 'alle partijen' die tussen jouw IP en de root name servers, en jouw IP en de name server van het domein dat je opvraagt). Als je bijvoorbeeld DoH met Google of Cloudflare praat, dan zijn de verzoeken alleen door die betreffende partij aan jou te koppelen.

Of je dit een echt probleem vind of niet heb ik geen oordeel over, maar ik ben wel van mening dat zoveel mogelijk verkeer versleuteld moet zijn om verschillende redenen.
Ik noem server (bind) en client (linux). Beide ondersteunen dns over tls en dat gebruik ik dan ook. Daarmee is mijn verkeer versleuteld en biedt DoH alleen maar nadelen.
Eens. DNS is infrastructuur, applicaties moeten dit niet zelf willen doen. Ik snap dat ze zo de adoptie willen versnellen maar we creëren een landschap waar elke app zelf wat doet en het moeilijker wordt om iets centraal te configureren. Daarnaast brengen we al onze requests onder bij één of twee grote partijen die eigenlijk al genoeg macht hebben. DNS over TLS (RFC 7858) is wat mij betreft een betere keuze.
Daarnaast brengen we al onze requests onder bij één of twee grote partijen die eigenlijk al genoeg macht hebben.
Helemaal mee eens, maar kleine partijen lijken hier niet eens mee bezig te zijn. Het zou toch fijn zijn als de Ziggo's en KPN's van dit land die allang hadden gedaan.
Buiten dat is de OS-ondersteuning ook nog nihil. Zover bij mij bekend heeft alleen Android (optioneel) ondersteuning van DoH.
DNS over TLS (RFC 7858) is wat mij betreft een betere keuze.
Uit interesse, waarom vind je DoT beter dan DoH?
mogelijk vanwege de extra abstractielaag ertussen, Voordeel van over http is natuurlijk wel dat het een stuk lastiger te dpi-en of te blokkeren is. Port 53 dichtzetten is een stuk makkelijker
https://en.wikipedia.org/wiki/DNS_over_TLS
Android clients use DNS over TLS by default.

Linux and Windows users can use DNS over TLS as a client through the NLNetLabs stubby daemon or Knot Resolver[15]. Alternatively they may install getdns-utils[16] to use DoT directly with the getdns_query tool.

The open source Technitium DNS Server can be used with Windows, Linux, or macOS as a DNS proxy by configuring forwarder option to use DNS over TLS [17].
DoT versleutelt het dns verkeer van de op je systeem ingestelde dns servers en dus voor heel je systeem, terwijl DoH alleen vanuit een applicatie gebeurt en dus alleen die applicatie het dns verkeer versleutelt. Bovendien maakt DoH gebruik van het http protocol, wat mijn inziens een extra overhead heeft dan gewoon je dns verkeer direct met tls versleutelen(maar ik kan het mis hebben). En wellicht dat aan de serverkant DoT ook minder belastend is dan DoH met een hele webserver en alles wat daarbij meekomt, maar niet nodig is voor puur dns verkeer.
Andere DNS per applicatie is vast verwarrend als er verschillen of problemen optreden. Maar vanuit privacy oogpunt is het eigenlijk best ok: geen enkele (DNS) provider kan je zo volledig volgen.

Toch snap ik het privacy aspect niet helemaal. Ik dacht dat een provider bij https al niet kan zien welke pagina's je vraagt, doch alleen welk domein. Op zich zien ze met alleen een IP dus niet eens zo gek veel minder, daar grotere sites toch geen shared IP adres gebruiken.

Ook in Nederland moeten providers deze info enige tijd te bewaren voor opsporingsdoeleinden. Dus ook hier interessant wat daarvan overblijft als je het nu al zo makkelijk kunt overslaan - want wie op domeinnaamniveau onzichtbaar wil zijn kan dus nu al z'n DNS op die Cloudflare oplossing instellen, begrijp ik, vermoedelijk na installeren van een juiste client op het systeem.
Toch snap ik het privacy aspect niet helemaal. Ik dacht dat een provider bij https al niet kan zien welke pagina's je vraagt, doch alleen welk domein

Klopt, maar dat domein wordt toch gezien als een soort privacy risico.

In deze context echter gaat het niet zozeer om je webpagina request zelf, maar de DNS-request. Ofwel nog voor je naar een pagina kunt gaan moet je eerst het IP weten. Dat vraag je aan de DNS server, en dart gebeurd volledig onversleuteld. Dat kun je versleutelen via DNS-over-HTTPS, maar het risico is dat een klein aantal partijen dit naar zich toe trekken ipv de meer decentrale benadering nu.
Ja, dat begreep ik. Maar het overheids loggen gaat nu dan toch ook in twee stappen, vermoed ik? 1) DNS verzoek: ditdomein.com, antwoord x.y.z.a. 2) Verzoek naar IP x.y.z.a., inhoud (= welke pagina?) ook nu al versleuteld.
Het idee is dat stap 1 voorkomen wordt omdat men het hele verzoek "ditdomein.com" niet meer ziet.

Wellicht dat men in sommige gevallen via stap 2 nog het domein kan zien, of dat het hele IP zelf al, alle informatie lekt, maar dat is een losstaand probleem.

Merk namelijk op dat het niet enkel gaat om loggen, maar ook tegengaan van blokkeren. Men kan nu niet meer simpelweg via DNS blokkeren, maar moet nu routering aanpassen of geavanceerde packet-inspectie doen.

Als je context echter meer is, dat je constateert dat dit dus geen waterdichte beveiliging is, maar enkel een klein stapje in de wapenwedloop, dan denk ik dat je gelijk hebt ;)
Een groot nadeel vond ik toch wel dat met DOH je hostfile plots niets meer tegen houdt.
Ik had een hele lijst van foute websites erin gezet maar die zijn nu via DOH gewoon te gebruiken.
Ik heb het in Firefox alweer uitgezet (stond standaard op aan na nieuwe installatie) en nu werkt de hostfile weer.
Daarbij moet je Cloudflare maar vertrouwen op hun blauwe ogen dat ze niet je data farmen en aangezien ik er een aantal negatieve berichten over gelezen heb ben ik voorzichtig met het opzetten van DOH.
Firefox heeft dus een ingebouwde DNS client die niet eens kijkt naar je hostsfile, iets wat (vrijwel?) elke system-wide resolver wel gewoon netjes doet.
Opzich vrij logisch. Als je op applicatie level DNS gaat resolven, dan gaan mechanismes op OS niveau zoals je hosts file) natuurlijk niet meer werken.

Ik vind het een heel lelijke keuze. Het ligt toch veel meer voor de hand om infrastructurele netwerkfunctionaliteit also DNS op OS level te doen. Dan profiteren alle applicaties ervan, heb je dus minder onderhoud/overhead, en als een bonus gedragen alle applicaties zich hetzelfde. Tot slot zorgt het ervoor dat dingen als hosts files nog werken, en dat lokale caches een stuk meer zin hebben.

Ik zie ook niet in waarom je DNS-over-HTTPS niet op OS level kan implementeren......
Klopt, omdat inderdaad de OS DNS wordt genegeerd. Echter kun je dan gebruik maken van tools die o.a. hier te vinden zijn: https://dnscrypt.info/implementations/ zoals Simple DNSCrypt waarbij je een lokale DNS proxy draait die gebruikt kan worden. Vervolgens gebruikt deze de DoH implementatie naar de publieke DNS servers die dit ondersteunen. Aan die proxy kun je dan weer een blacklist toevoegen van domeinen. (gebruik dit zelf trouwens niet).

Ik draai zelf een server met zowel DoT als DoH ondersteuning waarin ik de blokkade heb toegevoegd en deze heb ik via firefox ingesteld a.d.h.v. about:config in de network.trr instellingen. Nu wordt i.p.v. de default CloudFlare oplossing, mijn eigen DoH server gebruikt en zover ik weet is dit ook mogelijk in Chrome.

[Reactie gewijzigd door mrdemc op 30 september 2019 14:51]

ik d8t dat Cloudflare alle gegevens verwijderen na 24-48.
Ben een beetje verward.
- Firefox is de eerste grote browser die dit implementeert, niet google.
- Firefox gebruikt cloudflare als dns service, niet google dns.
Groot? Nog geen 5%.

Paar weken geleden overgestapt van Firefox naar Chrome omdat ik problemen heb met verschillende websites in Firefox die wel prima werken in Chrome. Erg jammer hoor want ik kies Firefox voor de privacy.

Mijn provider ondersteunt (nog) geen DOH. Daardoor gaat mijn DNS verkeer straks opeens ergens anders naartoe. Daar ben ik dus echt niet blij mee. De malware filtering van mijn provider werkt uitstekend en dat is een dienst die ik niet kwijt wil (XS4ALL). Die gebruik ik JUIST voor het browsen.
XS4ALL bied wel DNS over TLS aan, geen enkele reden om DNS over HTTPS ook aan te moeten bieden.
Als je O.S. het ondersteund, zal deze automatisch DoT gebruiken i.p.v. normale DNS.
Ik gebruik Firefox voor alles. Alleen als het fout gaat gebruik ik (soms, soms laat ik het dan maar helemaal) Chrome.
Google biedt al enige tijd een DoH oplossing via Intra
Interessant - kan je dus toch DNS-verkeer omleiden voor adblocking (iets dat Google niet toestaat in de Play-store).
Google is bezig om dit in Chrome ook te implementeren. Weliswaar iets vrijer dan Mozilla met Firefox maar nog steeds op een manier dat het de system DNS overruled.

[Reactie gewijzigd door Caayn op 30 september 2019 13:46]

Ben een beetje verward.
- Firefox is de eerste grote browser die dit implementeert, niet google.
- Firefox gebruikt cloudflare als dns service, niet google dns.
Chrome doet ook DoH, ik weet niet welke browser eerst was.
Chrome verschilt van Firefox in dat Chrome een DoH-provider kiest die past bij je oude DNS-resolvers.
Als je voorheen de DNS-servers van Google gebruikte (8.8.8.8) dan kan Chrome er voor kiezen om DoH te doen met de Google DNS-servers als backend.
Dat komt waarschijnlijk omdat Google de bedenker is van het protocol. Het zal de Amerikaanse overheid ook niet gaan om welke DNS servers je gebruikt, maar het feit dat DNS verkeer "verstopt" tussen ander HTTPS verkeer.

Voor ze er echt last van krijgen grijpen ze in. Ik gebruik zelf DNS servers in mijn lokale netwerk maar geen van die twee ondersteunt DoH of DoT. Als dat eenmaal rond is en het is een standaard onderdeel van DNS servers dan is er geen houden meer aan.
Ik vind het altijd vreemd als zo'n vraag wordt gesteld, nog voordat een commissie of de politiek zelf een standpunt hebben ingenomen.
Je kan het antwoord namelijk niet vertrouwen, dus die kan je niet gebruiken om je beslissing op te baseren.

Door deze vraag te stellen voordat je zelf je publiekelijk standpunt hebt ingenomen, wek je de suggestie dat het antwoord belangrijk is voor je standpunt.
En wegens de onbetrouwbaarheid zou het dat niet mogen zijn.

Google zal nu "nee" zeggen, over 2 jaar "misschien ooit", en zodra iedereen het gebruikt "ja, want reden".

[Reactie gewijzigd door Zynth op 30 september 2019 13:49]

Ik vind het altijd vreemd als zo'n vraag wordt gesteld, nog voordat een commissie of de politiek zelf een mening hebben geuit over de wenselijkheid.
Je kan het antwoord namelijk niet vertrouwen, dus die kan je niet gebruiken om je beslissing op te baseren.

Door deze vraag te stellen voordat je zelf je publiekelijk standpunt hebt ingenomen, wek je de suggestie dat het antwoord belangrijk is voor je standpunt.
Hoe moet het anders? Eerst een standpunt in nemen zonder onderbouwing en daar dan maar mee verder werken? Natuurlijk heeft zo'n commissie al een mening of een vermoeden dat er iets niet goed gaat, anders beginnen ze niet aan zo'n onderzoek.
Iedereen weet hoe dat werkt. Zo'n onderzoek is er vooral om bewijs op tafel te krijgen. Harde cijfers, feiten, documenten, meningen van experts. Alles wat je kan gebruiken om te bewijzen dat er iets niet goed gaat en er dus opgetreden moet worden.
Terwijl het antwoord op een dergelijke vraag nooit te vertrouwen is.
Die combinatie maakt mij altijd nerveus.

Google zal nu "nee" zeggen, over 2 jaar "misschien ooit", en zodra iedereen het gebruikt "ja, want reden".
Ik neem aan dat die commissie niet alleen de mening van Google vraagt maar ook aan concurrenten en onafhankelijke experts.
Kan Google de data van opgevraagde webpagina's toch weer mooi verkopen aan providers en andere partijen die dit door deze techniek niet meer te zien krijgen. Slim hoor ;)
Dat kunnen ze ook zonder DoH, door alleen de verzoeken naar 8.8.8.8 te versturen vanuit de browser (of de standaardinstelling van je Android toestel) zonder tussenkomst van DoH.
Niet helemaal, want zonder DOH kan je provider het ook zien dus hoeven ze het niet te kopen.

Google creeërt een probleem en tegelijk hebben ze al de oplossing
Je ISP heeft ook andere manieren om je verkeer te volgen als ze dit willen, maar je hebt gelijk dat als je ISP of een één of ander internetknooppunt makkelijker data wil correleren, dan moeten ze die data ergens anders vandaan halen. Alle andere partijen die jouw data als business hebben, maakt het niet voor uit.
De gelinkte WSJ bron zit achter een paywall, dus ik kan niet controleren wat daar oorspronkelijk in gezegd wordt. DoH is geenszins een Google protocol, het is een standaard uitgebracht door het IETF (zoals de meeste standaarden), opgesteld door werknemers van Mozilla en ICANN.
De beslissing die volgens dit artikel onder vuur ligt, is dat Google DoH binnenkort standaard zal gaan aanzetten in Chrome. Volgens Google zelf gebeurt dit alleen wanneer de DNS server die reeds ingesteld staat op het systeem van de browser dit ondersteund, te beginnen met een select aantal DNS providers voor dit experiment. Als de ingestelde DNS server dit niet ondersteund, zal het niet worden gebruikt. Er is dus totaal geen sprake van het omzeilen van de provider van de gebruiker, zoals in dit artikel wordt gesuggereerd. Waar dit wel het geval is, is bij de implementatie van Firefox, waar de DNS lookups geforceerd worden naar Cloudflare om DoH te ondersteunen.
Ja, een DNS request gaat toch via je OS?
Dus als je OS het via DNS, DNS-TLS of DoH doet dan heb je daar schijnbaar voor gekozen.
Toch?
Waarom zou het via je OS moeten gaan? Het is vrij gebruikelijk om dat te doen, maar er is niets dat een applicatie ervan weerhoudt om het zelf te doen. Of dat een slimme of elegante keuze is, is een hele andere discussie natuurlijk.
Meh.. daar heb je wel een punt. :/
Nee, DNS aanvraag gaat volgens mij via de DNS servers geconfigureerd in je router. Je OS vraagt het aan bij je standard gateway, bij 90% van de consumenten dus de router die DNS servers van de ISP gebruikt
Ik weet het niet hoor, maar als Google niet de enige is die DNS servers beheert met deze functie zie ik het probleem niet. Als Chrome (of welke browser dan ook) standaard naar google dns servers gaat wijzen om maar via https te resolven vind ik het wel een probleem.
De juridische commissie wil weten of Google de data die het mogelijk zou kunnen verzamelen door dns-over-https aan te zetten commercieel wil gebruiken,
Dit vind ik een beetje vreemd, tuurlijk gaat Google dat doen. Ze zeggen wellicht van niet, maar ze hebben inmiddels wel aangetoond dat ze die data gaan inzetten om er geld mee te maken. Het is nota bene de core-business van Google, wat denken ze dan?
De kans is aanwezig dat Google de specifieke data van die requests inderdaad wel eens niet gaat gebruiken. Al is het maar om overheden een beetje tevreden te houden.

Want het daadwerkelijke doel is denk ik eerder dat het lastiger wordt om in het netwerk de requests naar hun advertenties te blokkeren d.m.v. firewalls bv. Op die manier verdient de investering zichzelf heel makkelijk terug.

Hoe dan ook, elke tech en product waar Google zich voor inzet lijkt toch 9/10 keer terug te vallen op die core-business van hun. Blijf het jammer vinden.
Bij dns-over-https wordt een dns-query versleuteld met tls-encryptie. Daardoor kunnen andere partijen zoals providers niet meer meekijken naar welke webpagina's specifieke gebruikers opvragen. Hoewel de beslissing op het eerste gezicht goed lijkt voor de privacy van gebruikers is niet iedereen even blij met de beslissing. In Engeland, waar strengere internetregels gelden, waren internetproviders lange tijd niet blij met het plan. In de VS geldt hetzelfde. Ook cdn Akamai is tegen dns-over-https.
Dus daardoor kunnen de geheime diensten internet data niet meer lezen???

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee