Microsoft gaat dns-over-https toevoegen aan Windows

Microsoft gaat dns-over-https implementeren in Windows. Versleutelde dns-verbindingen worden standaard ingeschakeld in de dns-client van het besturingssyssteem. Dat gebeurt niet voor gebruikers die eigen dns-instellingen hebben ingesteld.

Bij dns-over-https worden dns-queries versleuteld om ze anoniem te houden. Steeds meer browser- en softwaremakers werken daaraan. Zo zet Firefox bij Amerikaanse gebruikers een DoH-proxy op via Cloudflare, en Google doet dat dat met verschillende providers voor Chrome. Microsoft was altijd een van de partijen die daarin tot nu toe weinig stelling nam. Het bedrijf heeft nu plannen aangekondigd om DoH naar Windows te brengen. Het bedrijf wil daarvoor verschillende dns-providers gebruiken 'zodat het protocol gedecentraliseerd blijft'.

Microsoft voert de implementatie van DoH in stappen uit. De eerste stap is dat alle dns-verzoeken standaard via DoH worden verstuurd waar dat mogelijk is. Gebruikers die hun dns-instellingen niet zelf aanpassen gebruiken automatisch de dns-instellingen van hun provider. Als die DoH ondersteunt, wordt dat bij de gebruiker ook doorgevoerd. Op die manier hoopt Microsoft dat de privacyelementen van dns-over-https worden doorgevoerd voor gewone gebruikers, zonder dat andere gebruikers met specifieke wensen over hun dns-configuratie daar last van hebben.

In de toekomst wil Microsoft het makkelijker maken voor gebruikers om de dns-instellingen te vinden en te veranderen. Nu moet dat nog grotendeels op netwerkniveau, of in individuele browsers. De optie om dns-instellingen daar te regelen zit ook vaak diep in de menu's verstopt. Hoe Microsoft de instellingen toegankelijker wil maken zegt het bedrijf niet. Het bedrijf zegt in de toekomst ook na te willen denken over de implementatie van dns-over-tls, een alternatief voor dns-over-https.

Wanneer de nieuwe feature beschikbaar komt, is nog niet duidelijk. De functionaliteit zit nog niet in de Insider Previews van Windows 10. Microsoft zegt het echter belangrijk te vinden om de voorgenomen intenties 'zo vroeg en zo duidelijk mogelijk' naar buiten te brengen.

Tweakers schreef onlangs een achtergrondartikel over de recente discussie rondom dns-over-https.

Door Tijs Hofmans

Nieuwscoördinator

18-11-2019 • 14:38

134 Linkedin

Reacties (134)

134
133
83
5
1
24
Wijzig sortering
DoH is de grootste dwaasheid aller tijden. Als men dan in één keten de dns weet te hacken ben je gezien! En dat zal gebeuren.
Microsoft is net als Google en Mozilla medeplichting hieraan. Per sé willen scoren - daar waar gewoon secure dns over TLS volstaat - het is gewoon krankzinnig!
Waarom is dat risico groter met DoH dan traditionele DNS?
Leesvoer:

DNS-over-HTTPS causes more problems than it solves, experts say

Ik begrijp ook niet dat ze niet gewoon TLS op DNS verkeer kunnen zetten, maar dat zal wel lastiger zijn met bestaande implementaties.

[Reactie gewijzigd door mkools24 op 18 november 2019 14:49]

TLS is afhankelijk van een "reliable transport protocol", zoals TCP om middels een handshake beveiligd te krijgen en houden. DNS gaat standaard over UDP en is daarmee niet geschikt voor versleuteling op basis van stateful negotiation.

DNS heeft daarnaast inherent een kip-ei probleem met dat TLS-certificaten geverifieerd worden op basis van de hostname, en je die pas kunt verifieren op correctheid na DNS-resolutie. Het is dus allesbehalve triviaal om dat even open te breken.

[Reactie gewijzigd door curry684 op 18 november 2019 14:59]

DNS is zowel UDP als TCP, waarbij de keus aan de client is welke deze wil gebruiken. Clients verkiezen UDP, omdat voor UDP niet eerst een verbinding opgezet moet worden, daardoor minder roundtrips nodig zijn en dus UDP sneller is.
de meeste mensen hebben thuis een router staan die de DNS server is. Dus dat die snel moet zijn is evident. De router zelf zal vast een sessie met een 'normale' DNS server hebben, en daarvoor hoeft maar 1 sessie te worden gemaakt. De overhead van de three-way-handshake is dus minimaal.

Dus lokaal, binnenshuis, gebruik je open DNS. Dus onversleuteld. De sesssie die buitenshuis opgezet wordt kan dan DNS over TLS zijn. heeft dus alle voordelen, zonder de nadelen.
Maar HTTP(s) is ook op TCP gebaseerd toch? En ook die certificaten moeten ergens geverifeerd worden? Speelt datzelfde probleem dan niet ook bij DNSoHTTPS?
Ik begrijp het probleem niet goed. De DNS server staat toch als hard IP ingesteld? Wat voor DNS resolutie is er dan noodzakelijk om de connectie tot stand te brengen?

Ik connect naar de DNS server op IP. De TLS handshake start. De server biedt zijn certificaat aan en als client verifieer ik dat. Verder nog wat negotiation over cyphers en dergelijke, maar daarna is de tunnel tot stand gekomen.
Dns-over-tls gaat over een unieke poort itt dns-over-https. Dat maakt DoT makkelijker af te sluiten door bv een provider.
Dat is zo, maar DNS poort 53 valt ook af te sluiten voor het hele internet behalve de ene DNS-server die de internetaanbieder wil dat gebruikt wordt. En dat soort situaties bestaan zeker, toch is het zo dat bij het merendeel van de internetaanbieders dit soort blokkades niet bestaan. Op dezelfde manier zal normaliter niet zomaar DNS-over-TLS geblokkeerd worden en is het als standaardprotocol prima toepasbaar en daarmee ook wenselijk, want HTTP heeft als protocol nogal wat bijkomende nadelen, zoals gegevens die via HTTP-headers ongemerkt meegestuurd worden. Pas als men gebruikers de macht wil geven om internetaanbieders te omzeilen, dan wordt DNS over HTTPS zinvol.
Ja dat is wel waar. DoH is voor Nederlanders ook wat minder interessant dan het voor Amerikanen is. Hier zijn isp's grotendeels een nutsvoorziening en hebben we vrij goede wetten rondom bv netneutraliteit. Dat is in de VS wel anders, dus daar hebben gebruikers meer baat bij een protocol dat hun provider omzeilt.
“Dat is in de VS wel anders”. Ik vind dit soort opmerkingen altijd wel vermakelijk om te lezen. Nederlanders roepen vaak de VS dit en de VS dat. Vergeten daarbij dat het een gigantisch land is met een complexe afstemming tussen Federale wetgeving en per-staat wetgeving.

Ik weet zo van geen providers die hier in de VS DoH blokkeren. Denk dat überhaupt privacy maar een beperkt voordeel is van DoH of DoT. Het is natuurlijk goed dat het DNS request dan niet meer clear text verloopt, maar het verbergt niet bepaald de sites die bezocht worden. Na DNS resolutie volgt een connectie op basis van IP en veel sites zijn uniek met dat IP te herleiden. De authenticiteit van het DNS request is interessanter.
Het is ook geen waardeoordeel hè, ik zeg gewoon dat in veel gevallen je ISP in Amerika iets kan doen wat hier in Nederland niet kan. Dat zal ongetwijfeld per staat verschillen wel, maar toch gebeurt het. Dat ze DoH niet blokkeren is ook niet uit goodwill maar omdat het technisch niet zomaar kan.
Nee het is geen waardeoordeel, maar het is wel enorm generaliseren en stemmingmakerij. Ik neem natuurlijk graag dit terug als je uitgebreide ervaring blijkt te hebben met verschillende ISPs door de VS of een expert bent in Amerikaanse netneutraliteit.

Ik bedoelde eigenlijk DoT blokkeren, niet DoH. Denk dat als ze de bekende, meest gebruikte DNS IPs zouden blokkeren dat ze het aardig tegen zouden kunnen gaan. Het is alleen de hel die ze daarbij over zich heen krijgen totaal niet waard.

Ze proberen je liever in een duur combi pakket te krijgen met een hoop TV kanalen of een modem abonnement aan je te slijten 🙂

[Reactie gewijzigd door Zyphrax op 20 november 2019 07:27]

zoals gegevens die via HTTP-headers ongemerkt meegestuurd worden
Dit is een beetje een non-argument. HTTPS wordt in dit geval specifiek gebruikt om DNS queries te doen door de browser of het OS om een name te resolven. Het is geen website die geladen wordt, met Referer header etc.
Het is dus wel een HTTP protocol query.. vanuit een browser oid.
Het argument dat er allerhande headers ongemerkt meegestuurd worden is nochtans onzin. Browsers bouwen dit in omwege privacy. Dan gaan ze bewust weer andere privacy-gevoelige informatie meesturen? Does not compute.
Google bouwt de DoH in Chrome, waarom niet extra info toevoegen om de oogs te te verbeteren?
Google die privacy ondersteund en toejuicht is wel een heel aparte benadering.
Wat een vreemde redenering. De DoH server is niet van Google. Zij hebben er niets aan om die informatie aan een andere partij te geven. En áls ze dat willen doen, dan hebben ze daar geen DoH voor nodig, en kunnen ze dat nu ook al.

[Reactie gewijzigd door .oisyn op 19 november 2019 11:41]

bv. omdat een DoH server geheel voorbijgaat aan een pi-hole filter, of andere filters die al ingezet kunnen zijn.
bv. omdat Google advertentie verkoper is en op deze manier een nog betere bron heeft voor data collectie (vgl.DNS servers 8.8.8.8 & 8.8.4.4). Waarbij lokale netwerk beheerders nog minder een kans hebben om het verkeer af te splitsen?
Omdat interne queries nu niet meer door een lokale DNS server opgelost kunnen worden?
De werkelijke implementatie zal bepalen hoe goed bruikbaar dit is. Im mijn use case zie ik eerder nadelen dan voordelen. Is de DoH server vrij te kiezen of opgelegd door de betreffende broser provider. Hoer blijft er een consistent beeld buiten de browsers om?

Een Opensource DoH resolver library voor Linux, Windows, ... etc zou wel een goede uitkomst zijn. dan kan een netwerk beheerder het naar eigen inzicht gebruiken en inrichten.
Als je in plaats van insinuaties te doen nou gewoon even het DoH verkeer van Chrome en FF capturet om je bewering te staven...
insinuaties?... of vragen voor een antwoord...
De laatste zin is een opmerking.

Waarom gaan browser bouwers aan de haal met een systeem functie. Het vertalen van namen in ip adressen. Het vertalen naar IP adressen wordt door de resolverlibrary gedaan. Als het op dat niveau werkt is het gelijk voor ALLES (inclusief mailers, chat applicaties, niet webdiensten etc. etc. ) geregeld.

Bij OpenSource komt er dan vanzelf een variant boven drijven die voor iedereen privacy vriendelijk kan zijn.
https://dnsprivacy.org/wi...+Privacy+Public+Resolvers
https://github.com/curl/curl/wiki/DNS-over-HTTPS
Daar valt inderdaad iets voor te zeggen.
Leesvoer:

DNS-over-HTTPS causes more problems than it solves, experts say

Ik begrijp ook niet dat ze niet gewoon TLS op DNS verkeer kunnen zetten, maar dat zal wel lastiger zijn met bestaande implementaties.
Uw leesvoer-link is correct.

Het antwoord op uw andere vraag luidt als volgt:
Het DNS protocol draait over UDP en voor SSL/TLS is een TCP verbinding vereist.
SSL is hierdoor dus fundamenteel onverenigbaar met DNS.

Het ligt dus niet aan de bestaande implementaties, want het is gewoon technisch onmogelijk om TLS of SSL op DNS te zetten en dus kan ook niemand een implementatie maken die dit wel zou kunnen.

Er is echter wel een andere oplossing voor de problemen met DNS en dat is het gebruik van DNSSEC, of het gebruik van een (correct ingestelde) VPN.

Grof gezegd: Als uw provider met uw DNS-requests/replies ziekt, dan moet u een VPN gebruiken of een andere DNS-Server instellen die DNSSEC ondersteund.

Als u alleen maar bang bent dat derden (dus niet uw provider) met uw DNS requests/replies knoeien, dan heeft u genoeg aan alleen het gebruik van een DNS-server met DNSSEC.
Het antwoord op uw andere vraag luidt als volgt:
Het DNS protocol draait over UDP en voor SSL/TLS is een TCP verbinding vereist.
SSL is hierdoor dus fundamenteel onverenigbaar met DNS.
DNS is NIET uitsluitend UDP. DNS doet UDP en TCP, de client mag bepalen wat die gebruikt. Over het algemeen is UDP sneller, daardoor meestal gebruikt. En DOH (DNS over HTTPS) heeft geen TCP verbinding nodig?
Het ligt dus niet aan de bestaande implementaties, want het is gewoon technisch onmogelijk om TLS of SSL op DNS te zetten en dus kan ook niemand een implementatie maken die dit wel zou kunnen.
Een DOT (DNS over TLS) implementaties bestaan al en wordt ook door meerdere DNS software leveranciers ondersteunt.
En DOH (DNS over HTTPS) heeft geen TCP verbinding nodig?
HTTPS = HTTP over SSL.
SSL heeft TCP-verbindingen nodig, met meerdere handshakes. In de praktijk kan het dus niet op tegen DNS met DNSSEC over UDP.

Verder wist ik niet dat we tegenwoordig DNS over TLS laten draaien. Ik hoop dat u mij dat kleine hiaat aan achterstallige kennis gunt.
TLS 1.3 kan met QUIC ook gewoon UDP gebruiken: https://thenewstack.io/ht...etwork-speed-reliability/.

DNSSEC zorgt alleen voor validatie/authenticiteit van de DNS records. Dit is dus geen encryptie: je internetprovider kan alsnog zien welke DNS requests je doet.
DNSSEC zorgt alleen voor validatie/authenticiteit van de DNS records. Dit is dus geen encryptie: je internetprovider kan alsnog zien welke DNS requests je doet.
Dat heb ik eerder al aangegeven en ik heb daar ook over gesteld dat een VPN een geschiktere tool is, maar dat u zich flink achter de oren moet krabben over uw keuze voor een internet provider als u met dit probleem zit.
Internetproviders niet zozeer, maar wel: Overheidsinstanties.
Ter aanvulling, het gebruik van tcp/udp staat vastgelegd in (o.a.) RFC1035:
The Internet supports name server access using TCP [RFC-793] on server
port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
port 53 (decimal).

[Reactie gewijzigd door woutertje op 18 november 2019 16:12]

Ter aanvulling, het gebruik van tcp/udp staat vastgelegd in (o.a.) RFC1035:
Ik zat ernaast.
Bedankt voor de correctie.
+ RFC7858 voor DoT (https://tools.ietf.org/html/rfc7858)
+ RFC8310 usage profiles voor DoT (https://tools.ietf.org/html/rfc8310)
gebruikt poort 853 UDP of TCP.
DNSSEC zorgt er alleen voor dat je zeker weet dat het antwoord niet vervalst is. Dat is heel iets anders dan encryptie met DoH en biedt dan ook geen encryptie aan

[Reactie gewijzigd door GrooV op 18 november 2019 15:23]

DNSSEC zorgt er alleen voor dat je zeker weet dat het antwoord niet vervalst is. Dat is heel iets anders dan encryptie met DoH en biedt dan ook geen encryptie aan
Welk probleem wilt u oplossen? Privacy of het tegengaan van vervalsingen?

DoH is prima voor privacy ten opzichte van uw provider, maar vervalsingen en privacy-schendingen bij de DoH aanbieder zijn nog steeds prima mogelijk.

DNSSEC lost het probleem van vervalsingen echter prima op. Er blijft dan alleen nog het probleem van privacy over.

Eigenlijk vind ik dat u gewoon een andere provider moet kiezen als u die niet kunt vertrouwen of bang bent voor de privacy-implicaties. Als dat niet kan, heeft u waarschijnlijk meer dan een combinatie van een VPN en DNSSEC dan aan heel DoH.
Ach in de SNI header van de werkelijk connectie staat de website alsnog vermeld, als DNS het niet oppakt dan kan de ISP de SNI headers van HTTPS wel lezen.
Ach in de SNI header van de werkelijk connectie staat de website alsnog vermeld, als DNS het niet oppakt dan kan de ISP de SNI headers van HTTPS wel lezen.
Dit is o.a. waarom ik stel dat u meer heeft aan DNS met DNSSEC en een VPN dan aan DoH.
Voor de DoH staat er de SNI in van de DNS over HTTP server.
Voor de connectie naar google staat er www.google.com in als de url https://www.google.com/ was.
etc.

Dus de DNS query is veilig voor transit naar de DNS server. Als dns.google.com gebruikt wordt om www.microsoft.com op te zoeken dan staat er in de DoH verbinding dns.google.com in de SNI en www.microsoft.com in de SNI in de verbinding naar Microsoft.

DNSSEC gaat hier niet tegen helpen vrees ik. DNSSEC gaat overigens over of packets tijdens transit verhaspeld worden, de packets zijn nog steeds leesbaar. Packet spoofing kan dan niet meer zo makkelijk, of het in flight aanpassen van packets. (bv. Proxy adres van ISP op alle antwoorden invullen).
DoT gaat over encryptie van DNS queries an sich. (poort 853) zowel voor UDP als voor TCP.

[Reactie gewijzigd door tweaknico op 20 november 2019 13:39]

Ik heb ook al vanaf het eerste moment aangegeven dat er twee problemen zijn, namelijk privacy en geknoei met dns replies.

Ik zie in DNSSEC een overduidelijke oplossing voor het knoeien met paketten, maar ik zie in DoH geen oplossing voor het privacyprobleem EN tevens ook geen oplossing voor het knoeien met de replies.

Het enige verschil is nu dat Google/CloudFlare of wie er ook als DoH-provider gekozen wordt naar hartelust met de replies kan knoeien en wellicht zelfs DNSSEC wereldwijd kan ondermijnen door het gewoon niet te ondersteunen.

In die situatie legt u uw informatie niet meer bij uw eigen provider of overheid, maar bij de DoH-provider en de Amerikaanse overheid. Ik zie niet hoe dat een verbetering is? SNI is in deze eigenlijk totaal irrelevant.

Maar als u kiest voor een, door u zelf gekozen, VPN aanbieder en een DNSSEC enabled resolver gebruikt. bent u van beide problemen af en dan zonder centralisatie van het protocol (en dus de macht) bij een Google of CloudFlare.
DoH is prima voor privacy ten opzichte van uw provider, maar vervalsingen en privacy-schendingen bij de DoH aanbieder zijn nog steeds prima mogelijk.
Dit is het idd. Vertrouw je je browsermaker meer of minder dan je ISP?
Dit is het idd. Vertrouw je je browsermaker meer of minder dan je ISP?
De browsermakers kiezen over het algemeen vaak voor CloudFlare en die vertrouw ik voor geen meter.
Je zou eigenlijk een DNS server van een willekeurige provider ergens in Polen of Mexico moeten kiezen. Geen hond die daar in jouw DNS requests geinteresseerd is. OK, misschien is de latency een beetje hoog.
Je zou eigenlijk een DNS server van een willekeurige provider ergens in Polen of Mexico moeten kiezen. Geen hond die daar in jouw DNS requests geinteresseerd is. OK, misschien is de latency een beetje hoog.
Met als gevolg dat de data van die providers spotgoedkoop is en dat het vervolgens triviaal is om de IP-adressen die zij verzameld hebben zeer gemakkelijk naast de andere databases en logfiles te leggen zijn.

Het maakt dus niet uit, u bent hoe dan ook de pineut en het spelletje begint bij de keuze van uw internetprovider.
Tsja, maar laten we wel zijn, welke Nederlandse commerciele partij die een advertentieprofiel van mij wil aanleggen gaat de moeite doen om te lopen onderhandelen met een Mexicaanse ISP over inzage in hun DNS requests uit Nederland?
Tsja, maar laten we wel zijn, welke Nederlandse commerciele partij die een advertentieprofiel van mij wil aanleggen gaat de moeite doen om te lopen onderhandelen met een Mexicaanse ISP over inzage in hun DNS requests uit Nederland?
Bent u op de hoogte van het bestaan van allerlei brokers, zoals deze, die dat hele spelletje al voor hen heeft gedaan?
Ik zie Google, Instagram en Facebook, maar verbazend weinig Mexicaanse of Poolse ISP's in dat lijstje :)
Ik zie Google, Instagram en Facebook, maar verbazend weinig Mexicaanse of Poolse ISP's in dat lijstje :)
Het is dan ook een voorbeeld van een broker die alles op één hoop veegt en eenvoudig toegankelijk maakt. Zij zijn zeker niet de enige en er zijn zat anderen waarvan wij het bestaan niet kennen, maar die de mensen die er echt naar zoeken, wel weten te vinden.
Tsja theoretisch wel, maar ik betwijfel nog steeds hoeveel commerciele partijen die zich richten op het profileren van Nederlanders werkelijk moeite doen voor userdata van obscure providers uit verre landen, via een broker of anders.
CloudFlare is een commercieel Amerikaans bedrijf dat in de Nasdaq staat. Dat "do no evil" gelieg van de techsector trap ik niet meer in.
Het DNS protocol draait over UDP en voor SSL/TLS is een TCP verbinding vereist.
SSL is hierdoor dus fundamenteel onverenigbaar met DNS.
Zie (reeds genoemd) https://en.wikipedia.org/..._Transport_Layer_Security
The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees. The DTLS protocol datagram preserves the semantics of the underlying transport—the application does not suffer from the delays associated with stream protocols, but because it uses UDP, the application has to deal with packet reordering...
Prachtig.
Helaas is de technologie nog niet bewezen en doet het niets af aan de kritiek die ik hier eerder gegeven heb.
Het grote voordeel van DNS-over-HTTPS is dat de HTTPS door alle firewalls heen mag, en zo'n beetje iedere andere poort problematisch is.
Je kan altijd nog actief ip-adressen van DoH servers blokkeren.
Volgens mij zijn er al veel te veel om nog bij te houden. Er komen er dagelijks nieuwe bij en er is geen centraal overzicht. Wel wat lijstjes, maar het beheer daarvan is handwerk.
Daar heb je zeker gelijk in, het is redelijk onbegonnen werk, maar het is technisch wel mogelijk. :D
A la tor blokkades.. Gewoon voor elke HTTP query ook een DoH querie in dezelfde richten bij een positief antwoord: block site. Is goed te automatiseren.
Ik weet echt niet of ik daar nu blij van wordt
Ja, en dat is ook het grootste nadeel, het is niet meer controlleerbaar zonder DPI
Je kan toch het met een policy op je Windows bakken uitzetten?
Ja, maar dat werkt niet voor applicaties die zich er niks van aantrekken (firefox..) of andere apparatuur, zoals Chromecast die zich niks van dns instellingen aantrekken?
Via die policy zorg je dan ook dat dit soort browsers er niet op staan :)

Chromecast op je bedrijfsnetwerk lijkt me niet zo jofel, maar die dingen kan je als het echt moet op een apart VLAN zetten in quarantaine van de rest, net als bv BYOD laptops met Firefox/Chrome.
Wie heeft het over een bedrijfs netwerk? En daarnaast, ook over het "apart VLAN" wil je controle houden en niet zomaar alles toelaten.
Nou ja, als je het hebt over dingen uitzetten met policies, dan gaat het normaal gesproken over bedrijfsnetwerken :)

Idd, ook dat aparte VLAN kan je filteren, maar dat moet je dan doen op IP range basis ipv op DNS.
Jij bent degene die begon over policies...
maar dat moet je dan doen op IP range basis ipv op DNS.
Waarom? netflix.com blokkeren is een stuk eenvoudiger dan de rijen IP ranges blokkeren.

Maar zelfs dan nog, "mijn" netwerk, dus werken volgens mijn (DNS) regels...
IP ranges is wel effectiever - zo omzeil je ook advertentienetwerken of applicaties die hun spul direct vanaf IP adressen inladen ipv via DNS. En zoveel werk ook weer niet, immers: je hebt de domein namen al, de bijbehorende IP adressen vind je met 1 DNS lookup :)

Om maar te zeggen, filteren via DNS is ook niet alles, ook zonder DoH.

[Reactie gewijzigd door Dreamvoid op 18 november 2019 23:06]

Waarom denk je google zo blij is met DoH.
Yep, een extra stukje controle over het internetverkeer in Chrome/Chromecast/ChromeOS/Android.
Ik ben benieuwd hoe dit dan gaat in bedrijfsnetwerken. Je wilt toch dat daar de interne DNS wordt benut; niet alleen voor de interne domeinen maar ook voor filtering (bijv. geen netflix).
Ik ben benieuwd hoe dit dan gaat in bedrijfsnetwerken.
Via policies zal dit waarschijnlijk tot in de puntjes te beheren zijn, en daarmee ook uit te schakelen.

Verder gebruik je natuurlijk niet (enkel) DNS om bijvoorbeeld Netflix te filteren. Dat kan je ook op netwerkniveau doen.

[Reactie gewijzigd door The Zep Man op 18 november 2019 14:45]

Als je met “policies” Windows-meuk via een gecentraliseerde server zoals AD bedoelt, daar heb ik helemaal niets aan. Ik heb een heel scala aan apparaten en daarvan wil ik allemaal dat ze tegen de blokkades aan lopen. Ik heb bewust een blocklist op DNS niveau voor m’n complete netwerk, uit privacy overweging tegen voornamelijk advertentieprofilers, social media en Google, en DoH is een actieve poging om dit te omzijlen. Als ik Facebook of Google was zou ik gewoon een eigen DNS gaan draaien en die hardcoded in eigen applicaties inbouwen om om de blokkades heen te komen. DoH neigt in mijn setup naar virus-achtig gedrag.
Exact dit idd, maar dat houd je bij applicaties sowieso niet tegen, die kunnen altijd een verbinding naar een in de applicatie hardcoded IP adres opzetten. Als de Facebook app naar een of ander IP adres verbindt, houdt ook je PiHole DNS filter dat niet tegen.

Browsers als Chrome die inderdaad alle DNS verkeer via Google omleiden en zo je beter kunnen profileren/tracken, dat is idd bedenkelijk en je zou als beheerder eigenlijk ook daardoor dit soort browers moeten dumpen.

Als een browser daarentegen een gigantische lijst aan DNS servers heeft en daaruit telkens een willekeurige pakt voor zijn DoH requests, dan maak je juist het profileren weer moeilijker.

[Reactie gewijzigd door Dreamvoid op 18 november 2019 20:59]

Een hardcoded IP adres voor DNS in een app gebruiken, is af te vangen...
Een dst-nat rule in je firewall die udp/tcp poort 53 naar je eigen DNS server omzet zou voldoende moeten zijn. En zo ook hier thuis gedaan; alle apps die hardcoded een externe DNS willen benaderen worden hiermee wel door PiHole verder afgehandeld.

Maar dit wordt dus door DoH onmogelijk gemaakt.
Ik bedoel niet een IP adres voor de DNS server, maar het IP adres van de site waar ze naartoe willen.

In plaats van bv het domein facebook.com blokkeren via je DNS server, blokkeer je rechtstreeks de IP adressen van Facebook.

[Reactie gewijzigd door Dreamvoid op 18 november 2019 22:40]

Voor grote site kan het nog, maar steeds meer kleine sites gebruiken het zelfde IP adres (SNI)
Hostingservers met honderden (kleine) sites op een enkel IP adres. Die blokkeer je dan allemaal.
OK maar in de regel zijn de blokkades die je als beheerder van bedrijfsnetwerken doet niet voor kleine co-hosted individuele sites, maar voor ofwel grote content netwerken (Netflix, Spotify, NPO etc om je netwerk niet te overbelasten), ofwel geoblocks (Rusland, China, etc, vanuit security).

Overigens gaat SNI er langzaamaan wel uit met IPv6, waar iedereen weer een eigen IP adres heeft, maar goed dat duurt nog wel even.

[Reactie gewijzigd door Dreamvoid op 19 november 2019 11:37]

Dat hoeft geen gecentraliseerd systeem te zijn (met bv AD). Je kan perfect ook chef(-zero) of Ansible oid gebruiken op non-AD systemen om die policies in te stellen. Als je een compleet netwerk te beheren hebt, doe je het apparaatbeheer en -configuratie toch met config management? ;)
Dan heb je m’n point niet echt begrepen. Ik heb ook bv smartphones en consoles die helemaal niks kunnen met config management, maar waarvan ik nog steeds wil dat ze in de pihole blijven hangen om te voorkomen dat games en apps allemaal shit naar trackers sturen. Een hoop hebben gewoon Facebook en Google libraries geintegreerd en sturen data achter je rug om.
Lijkt me eerder dat Windows gewoon DHCP blijft respecteren. Niet iedereen draait active directory, zelfs niet in grote omgevingen en de DHCP is er om te dicteren welke servers waarvoor aangesproken moet worden.

Ik zou het echt achterlijk vinden als ze gewoon lokale settings gaan overriden.

[Reactie gewijzigd door Koffiebarbaar op 18 november 2019 14:48]

De truc met DNS-over-HTTPS is dat in bijvoorbeeld Chrome juist niet de met DHCP aangeleverde DNS instellingen gerespecteerd worden, juist om onbetrouwbare DNS servers te voorkomen.
Bij Jan met de Pet is de use-case wel iets anders dan zakelijk. Maar ook daar vind ik het achterlijk om te gaan defaulten naar DOH van bvb cloudflare als je ziet dat er één of andere lokale DNS gepusht wordt door de DHCP. (al dan niet voor windows zelf, voor datzelfde AD)
De kans dat je dan aan heel bewust geconfigureerde meuk gaat negeren als arbitraire browser is groot.

[Reactie gewijzigd door Koffiebarbaar op 18 november 2019 14:55]

Bij Jan met de Pet is de use-case wel iets anders dan zakelijk.
Al wil je zakelijk het netwerkverkeer beheren dan moet je ook zakelijk de end-points beheren. Al sta je BYOD toe, dan is BYOD (het gebruiken van privé apparatuur in een zakelijk netwerk) je probleem. Je moet dan niet DNS-over-HTTPS de schuld geven.

[Reactie gewijzigd door The Zep Man op 18 november 2019 15:25]

Al wil je zakelijk het netwerkverkeer beheren dan moet je ook zakelijk de end-points beheren.
Geen (microsoft) active directory draaien betekend niet dat je endpoints onbeheerd zijn.
Je moet dan niet DNS-over-HTTPS de schuld geven.
Ik geef DOH schuld ergens van?
Ik vind het nochtans redelijk duidelijk dat mijn eventuele grieven gericht zijn aan Microsoft's (eventuele/hypothetische) configuratiekeuze's.

[Reactie gewijzigd door Koffiebarbaar op 18 november 2019 16:04]

Hou je BYOD devices op een apart VLAN in quarantaine, strikt gescheiden van je zelfbeheerde spullen, en blacklist eventueel de IP ranges waarvan je niet wil dat je die devices naartoe connecten. Da's robuuster dan via DNS.
De kans dat je dan aan heel bewust geconfigureerde meuk gaat negeren als arbitraire browser is groot.
Maar waar ligt nu eigenlijk het probleem? Die bewust geconfigureerde meuk is waarom ingesteld? Om werknemers verkeer te kunnen inzien. Dat is dan een inbreuk op privacy.

Ik vind het persoonlijk helemaal prima dat we afstappen van 'meekijken' met jan en allemaal. Ook als dit geld voor bedrijven. Het streeft ook helemaal niet met de AVG dat websitebezoek zomaar van iedereen wordt opgeslagen.
Maar waar ligt nu eigenlijk het probleem? Die bewust geconfigureerde meuk is waarom ingesteld? Om werknemers verkeer te kunnen inzien. Dat is dan een inbreuk op privacy.
Deze aanname mag je toch wel even gaan staven met feiten.
Dat is niet zo moeilijk. De GDPR gespecificeerd al duidelijk dat persoonlijke data niet verzameld mag worden zonder duidelijk doel. Maar internet en email verkeer van werknemers mag al sinds jaar en dag niet:
https://www.deondernemer....nemers-controleren~290183
Ik zie hier geen ondersteuning voor je statement dat lokale dns ingericht wordt om bij medewerkers te gluren.
Die bewust geconfigureerde meuk is waarom ingesteld? Om werknemers verkeer te kunnen inzien.
Wat een onzin. Een lokale DNS server is helemaal niet bedoeld om verkeer van medewerkers te kunnen inzien. Als de werkgever verkeer van het personeel wilt inzien op haar werk computers dan zijn daar veel betere oplossingen voor.
interne dns servers zijn handig voor authenticatie, security, intern gehoste applicaties. interne dns heeft geen fuck te maken met logging van gegevens. ik ken geen bedrijf die logt wat dns doet, anders dan diagnostics logging over technische status van de server.

daarnaast kan je bij meeste bedrijven ook geen lookups doen van externe systemen, dat doet de proxy wel voor je.
In een bedrijfsomgeving met Internet rechtstreeks op de werkplek zou je juist wel queries moeten loggen om beveiligingsredenen. Dat staat inderdaad vaak standaard uit.

Als je niet logt is de kans groot dat je niet in de gaten hebt dat computers besmet zijn met malware of dat er andere criminele activiteiten plaatsvinden. Wat je niet mag is die gegevens gebruiken om werknemers te bespioneren, tenminste niet zonder gerede verdenking en niet zonder dat werknemers hiervan tevoren op de hoogte zijn gesteld.

Een voorbeeld van gebruik maken van DNS voor beveiliging is RPZ. Daarnaast zijn er allerlei honeypot omgevingen die dat ook doen.
Dan voert Google toch even een ongevraagde update zoals vorige week. 🙄
Je kan als bedrijfs netwerkbeheerder ook gewoon op je gateway de ongewenste IP ranges blokkeren, ipv de DNS requests.
Daarnaast zal waarschijnlijk de interne DNS die queries afvangen bij de manier waarop ze het nu eerst implementeren.
Dus voorlopig zal het nog meevallen.
Dat gebeurt niet voor gebruikers die eigen dns-instellingen hebben ingesteld.
Gok dat dit hieronder valt?
Ook dat kan je uitschakelen via policies. Als het niet kan via policies omdat BYOD gebruikt wordt, dan is BYOD eerder je probleem dan DNS-over-HTTPS. ;)
Daar heb je natuurlijk niks aan als je gewoon DNS instellingen via DHCP uitdeelt. Dan pas je ze niet zelf aan. Dit zou dus betekenen dat je ineens DHCP moet gaan negeren en diezelfde instelling die automatisch gaat overal hardcoden :(
en op je interne primary en sec. dns zet je je de ip adressen van DOH servers... (bijv. 1.1.1.1 ) <- en dat is geen grap.
We will not be making any changes to which DNS server Windows was configured to use by the user or network.
_/-\o_ _/-\o_

Zo te lezen zijn ze in ieder geval al beter bezig dan Google en Mozilla door niet de standaard settings te overschrijven en ineens een andere DNS provider te gebruiken wanneer deze niet voldoet aan de arbitraire eisen van Google en Mozilla.

[Reactie gewijzigd door Caayn op 18 november 2019 14:47]

Het is niet helemaal eerlijk. Google doet hetzelfde (checken of je dns een DNS-o-HTTPS provider is) en alleen dan omschakelen.

Het "google veranderd DNS OMG" verhaal is FUD van de concurrentie en is nooit het plan geweest. ze doen EXACT hetzelfde als Microsoft.

Mozilla doet dit wel onder bepaalde omstandigheden en alleen in Amerika (US versions) om een statement te maken tegen het misbruik van DNS door de lokale internet providers. Je mag daar van denken wat je wil natuurlijk. Persoonlijk vind ik het ook een wat zware maatregel. Aan de andere kant vragen providers daar dan ook gewoonweg extra geld (denk 20 euro/maand) om je gegevens niet te verkopen.
Ja, probeer eens naar een zelfgedefineerd domein te gaan, zoals test.dev.

Kun je mij vertellen dat google niet actief hun .dev domain forceert.
Andere discussie, omdat google ook providers ondersteund behalve die van henzelf. chrome ondersteund ook cloudflare quad9 etc.

Het .dev TLD is nu eenmaal van google. dat mag je niet leuk vinden maar volgens de internationale regels kunnen ze ermee doen wat ze willen, zolang ze ervoor betalen.
Het .dev domein heeft standaard HSTS ingesteld staan in de browser. Hierdoor mag er alleen met HTTPS gebruik van maken. Dat maakt *.dev een slecht domein voor eigen testwerk.
Voor testen niet de daarvoor gereserveerde tlds gebruiken is vragen om problemen. In Rfc 2606 staan de voor testen bedoelde tlds. .dev is daar geen tld in. Dan moet je voor klachten eerder bij diegene zijn die dacht dat het een goed idee was om eigenwijs te gaan doen. Het zal niet de eerste keer zijn dat iemand dan gevoelige testgegevens door blunderen met organisaties deelt die het niet moeten ontvangen. Al waren het maar domeinnamen of urls.

[Reactie gewijzigd door kodak op 18 november 2019 17:37]

Ik denk vooral dat het Mozilla legal team duidelijk kan overzien wat de impact ervan is in de VS en daar buiten zich er niet aan durven te branden nog 🙂
Ze komen er laat mee maar hebben gelukkig heel goed naar de shitshow van de concurrenten gekeken.
En wat gaat dit doen met onze PiHoletjes? iemand?
Niks, want jouw dns instelling is custom naar de pihole.
Het zijn eerder de browsers van google/mozilla die opeens jouw dns setup omzeilen en direct naar cloudflare danwel google verwijzen.

@iedereen die hier gereageerd heeft: kijk naar de documentatie hierboven van @Cyberia404
Windows neemt zoals je meermaals kan lezen de DNS settings over die zijn ingesteld, is het een DoH dns server, dan zal die DoH zijn, anders niet.

Als je browser een andere DNS kiest dan je hebt ingesteld, is het een probleem van jouw browser, niet van je OS

[Reactie gewijzigd door Soggney op 18 november 2019 15:05]

En als je DHCP server de PiHole als DNS opgeeft?
Of je de PiHole in je router ingesteld hebt als DNS?
(Dit zodat het standaard werkt voor elk apparaat in je netwerk)

Dan wordt dat allemaal omzeilt door je browser?
Maar welke DNS server wordt er uiteindelijk dan gebruikt bij DNS over HTTPS?

[Reactie gewijzigd door FuaZe op 18 november 2019 15:01]

Dat hangt dus weer netjes van de implementatie af. Google en Mozilla werken met een select aantal DoH providers. Veel keuze heb je daar niet. Zoals ik deze nieuwspost lees zal MS veel toleranter zijn en dus ook ISPs de kans geven een eigen DoH implementatie op te zetten of mogelijks zelfs gebruikers de kans te geven een eigen DoH server in te stellen.

DoH via DHCP moet in principe ook mogelijk zijn, maar de vraag is: wil je dat wel? DoH moet net veilig zijn, en dan is een kwetsbaar protocol moeten vertrouwen zoals DHCP misschien niet direct de beste keuze. De implementatie van Google en Mozilla zal het evenwel eenvoudig maken om, als je een eigen DNS server hebt, DoH gewoon uit te schakelen door het aanmaken van een DNS record. Als dat record bestaat blijven ze gewoon standaard DNS gebruiken.
DoH via DHCP moet in principe ook mogelijk zijn, maar de vraag is: wil je dat wel?
Als de DNS server vertrouwd is (geldig certificaat), waarom niet? Zou bijvoorbeeld kunnen door een certificaat voor een publiek IP adres te laten ondertekenen door een vertrouwde CA, en dat adres ook in te stellen voor DNS-over-HTTPS in het DHCP antwoord. De client kan dan zelf uitvogelen of het certificaat dat de DNS server aanbiedt klopt met het IP adres waarop de DNS server te vinden is.

Welke eisen je dan zou moeten stellen aan het uitgeven van een certificaat expliciet voor een DNS server is een andere discussie. Dit is niet zo makkelijk als een domain validated Let's Encrypt certificaat.

[Reactie gewijzigd door The Zep Man op 18 november 2019 17:26]

Het ligt er dan aan of de DNS van je PiHole ondersteuning biedt voor DNS over HTTPS. Als dat niet het geval is blijft je DNS dus onversleuteld richting de PiHole gaan.
Als die mogelijkheid er wel is, gebruik je voortaan DNS over HTTPS naar je PiHole.
De DNS server zelf wordt niet aangepast.

[Reactie gewijzigd door dutchgio op 18 november 2019 15:08]

Niks, want jouw dns instelling is custom naar de pihole.
Ook als dat via DHCP van de router komt?
Hoe weet Windows dan het verschil tussen custom en niet-custom?
Niet. In tegenstelling tot de shitshow van Google en Mozilla past Microsoft/Windows niet de te gebruiken DNS server aan, hoogstens het protocol om te communiceren.

[Reactie gewijzigd door Caayn op 18 november 2019 14:59]

Deze link gaat over het DNS verkeer vanaf de pihole richting het internet. Dat is niet waar ik me expliciet zorgen om maak.
Ik heb zelf ook in DHCP (dus niet statisch per PC) mijn pihole toegewezen als DNS server. Wat gaat deze aanpassing in Windows daarmee veroorzaken? Wordt de Pihole genegeerd aangezien dns over https direct richting het internet gaat? Waardoor alle ads ineens weer tevoorschijn komen?
Ook vang ik alle requests op Port 53 af en stuur die door naar de pihole i.p.v. rechtstreeks naar het internet te sturen (bedankt Google voor het niet respecteren van DNS instellingen op o.a. Chromecasts)
Alle https requests afvangen gaat’m niet worden, dan sloop ik mijn internet verbinding. De pi-hole een DoH DNS server maken is maar een gedeeltelijke oplossing (zie voorbeeld boven van apparaten die DNS instellingen toch negeren.) En wat als er een soort van HTST komt voor DoH? Dan valt er sowieso niets meer te filteren op DNS niveau.
DNS over HTTPS is gewoonweg een heel slecht idee behalve voor de grote bedrijven die leven van advertentieverkoop.
Dat blijft gewoon werken. Microsoft zegt dat ze de ingestelde DNS server blijven gebruiken en niet zullen overschrijven zoals Mozilla en Google dat doen.
We will not be making any changes to which DNS server Windows was configured to use by the user or network. Today, users and admins decide what DNS server to use by picking the network they join or specifying the server directly; this milestone won’t change anything about that. Many people use ISP or public DNS content filtering to do things like block offensive websites. Silently changing the DNS servers trusted to do Windows resolutions could inadvertently bypass these controls and frustrate our users. We believe device administrators have the right to control where their DNS traffic goes.

[Reactie gewijzigd door Caayn op 18 november 2019 14:49]

Ik volg mee want ja dat wil ik ook graag weten!
Als je PiHole werkt op blacklisten van DNS requests, dat omzeilt DoH inderdaad.

Zet je de PiHole tussen je PC en de router, en als je PiHole niet alleen de DNS lookups dumpt, maar ook de bijbehorende IP adressen van die blacklist blokkeert, dan werkt je PiHole prima.

[Reactie gewijzigd door Dreamvoid op 18 november 2019 20:39]

Hoog tijd voor een standaard om te communiceren welke protocollen je DNS-server ondersteunt.
Naast het traditionele protocol hebben we nu ook DNS-over-HTTPS, DNS-over-TLS en nog wat exotische protocollen. Traditioneel configureerde je DNS één keer op OS-niveau, tegenwoordig zijn er steeds meer applicatie die zelf met DNS aan de slag gaan en extra configuratie nodig hebben.
Ergens is dat natuurlijk een teken dat het OS achter loopt en niet biedt wat de applicaties nodig hebben. Wat dat betreft is het dus fijn dat Windows het zelf gaat doen.

Voor beheerders is het echter minder fijn als software slim probeert te zijn en zelf instellingen aanpast. In dit geval lijkt het er op dat DNS-over-HTTPS automatisch wordt aangezet als het systeem denkt dat je provider dit ondersteunt. Als provider zou ik daar graag wat meer controle over hebben in plaats van dat alle gebruiker onmiddellijk omschakelen zodra ik de deur open zet.

Misschien moeten we eens nadenken over een nieuwe standaard om te communiceren wat voor DNS-servers en protocol je wil gebruiken. Deels kunnen hiervoor gebruik maken van DHCP maar ik denk dat we iets willen dat ook werkt zonder DHCP en op afstand via internet.
Dat Chrome hiermee komt is natuurlijk maar voor 1 ding goed: advertentieinkomsten. Als het niet de dns verzoeken zelf zijn, dan wel het omzeilen van een PiHole installatie, of soortgelijken. In StarTrek termen, erg Ferenginieus gemotiveerd.

[Reactie gewijzigd door Mushroomician op 18 november 2019 17:34]

Dat Chrome hiermee komt is natuurlijk maar voor 1 ding goed: advertentieinkomsten. Als het niet de dns verzoeken zelf zijn, dan wel het omzeilen van een PiHole installatie, of soortgelijken.
Ik geloof dat Google betere redenen heeft, al komt het uiteindelijk wel neer op geld verdienen.
Een snel, betrouwbaar en veilig internet maakt het makkelijker om te handelen via internet. Hoe meer er online gedaan wordt hoe groter de koek die verdeeld wordt, en van zo'n beetje iedere transactie op internet pikt een van de internetreuzen een graantje mee, met Google voorop.
Mocht je systemwide al bezig willen met DNS over HTTPS, dan kun je de volgende (OpenSource) tool proberen :

https://simplednscrypt.org/
Inderdaad prima tooltje om je te wapenen tegen DNS hijacking. Handig icm VPN :)
Wel, goed voor al die mensen bij providers die zelf dns over https aanbieden :?
Goed dat Microsoft nu eindelijk eens meegaat. Vooral omdat anders de fragmentatie straks niet meer te overzien is en iedereen maar wat gaat toepassen.

Gewoon straks 3 opties: DNS, DNS+HTTPS en DNS+TLS. Voor een bedrijf als Microsoft moet dat niet zo moeilijk zijn. Behalve dan dat ze historisch gezien wachtten totdat iedereen al wat anders heeft gedaan en dan de schade proberen terug te draaien.

De nieuwe Edge ondersteund overigens ook "gewoon" DNS-o-HTTPS
Dit klinkt in ieder geval als een iets veiligere oplossing dat wat Mozilla voor ogen heeft. Alsnog vind ik de ongevraagd fallback naar publieke DoH-servers zeer kwalijk. Geef dan op zijn minst een popupje die je laat kiezen met een link naar de relevante privacy policies, om maar eens wat te noemen.

In het algemeen voegt DoH weinig toe, zeker voor Europeanen. Dus laten ze ons dit niet door de strot duwen. Eigenlijk is het gewoon een oplossing voor een probleem van de Amerikaanse ISP-markt zonder privacy-beperkingen.
Nou de vraag is maar of het beter is dat Google al je DNS requests afhandelt, of je ISP - ook in de VS.
Eigenlijk moet dat "DNS via Google" of "DNS via Microsoft" heten, dat zou een veel correctere benaming zijn.
Nou ja, het punt is niet per sé het protocol natuurlijk. De overhead van HTTPS is wat zwaar maar verder is het in principe prima. Firefox dwingt je echter bijna om DNS via Cloudflare te doen. Chrome schakelt alleen over naar de DoH-server als je toch al DNS van een "ondersteunde" partij gebruikt, net als Windows hier lijkt te doen. Stukje netter. Sowieso is Windows (het OS) de plek om DoH-ondersteuning in te bouwen, het moet heel snel weer uit browsers verdwijnen want daar heeft het niets te zoeken.
We kiezen nu het zoekbalkje al, dus waarom ook niet de DNS provider 🙂?

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