Providers als poortwachter tegen online fraude: Anti Phishing Shield uitgelegd

Tekst

Iedereen kent wel een familielid, vriend of kennis die slachtoffer is geworden van phishing, of misschien ben je er zelf weleens ingetrapt. Je denkt in te loggen bij je bank of webwinkel, maar in plaats daarvan vul je je inloggegevens in op een site van criminelen. KPN en het Nationaal Cyber Security Centrum (NCSC) willen dat soort fraude tegengaan met het Anti Phishing Shield.

Het idee is simpel. Het NCSC verzamelt bij verschillende bronnen – banken, de politie, Fraudehelpdesk, toezichthouders, enzovoorts – een lijst met phishingsites, fraudewebshops en scaminvesteringssites. Die lijst deelt het NCSC met providers zoals KPN. Die controleren de lijst en blokkeren de sites voor hun klanten. Tenminste, mits je instemt met het Shield.

Opt-inmalwarefilter

Het Anti Phishing Shield is opt-in. Het NCSC en KPN spreken al jaren over een concept als APS, maar liepen steeds tegen de wettelijke grenzen van netneutraliteit aan. Dit houdt in dat providers online verkeer gelijk en open moeten behandelen, ongeacht de bron. "Maar als we het opt-in doen en klanten er dus zelf voor moeten kiezen, mag het wel. En zo is het balletje gaan rollen", zegt Jeffrey Leusink, chief information security officer bij KPN.

De pilot begon in juli 2025. Sindsdien hebben 200.000 gebruikers zich aangemeld voor het schild en zijn er volgens KPN en het NCSC ruim twee miljoen pogingen geblokkeerd om phishingwebsites te bezoeken. De providers Snllr, TriNed en Kabelnoord doen inmiddels ook mee aan de pilot. Bij KPN zit het APS in het malwarefilter dat klanten kunnen activeren, ook wel bekend als Veilig browsen. APS werkt op basis van een gedeelde DNS-lijst. Het 'omzeilen' van de melding is niet mogelijk. Wanneer een site geblokkeerd is, moet je dus APS uitschakelen om die te kunnen bereiken.

Op de lijst staan nu 160.000 sites. Die lijst wordt elk kwartier bijgewerkt door het NCSC en direct gedeeld met internetproviders. Providers nemen die lijst niet blind over, maar controleren ook of er geen fouten in staan. Denk aan een legitieme webwinkel. Dit gebeurt geautomatiseerd, maar er kijken ook mensen live mee. Volgens Leusink is in het afgelopen jaar slechts één onterechte blokkade op de lijst terechtgekomen, 'wat we snel konden terugdraaien'.

Sites offline halen duurt lang

Ergens zou je het gek kunnen noemen dat providers dit probleem nu moeten oplossen. Als het NCSC weet welke sites crimineel zijn, waarom worden die dan niet gewoon offline gehaald? Het offline halen van een site is een langdurig traject, met politieonderzoek en uiteindelijk handhaving. Ondertussen blijft zo'n site online staan en slachtoffers maken.

Eefje Zents, directeur Samenwerking Digitale Weerbaarheid bij het NCSC, merkt daarnaast op dat het centrum geen opsporingsbevoegdheid heeft. "Daarom hebben we dit bedacht. En het offline halen van die sites gebeurt ook, maar dat gaat via een andere weg." Leusink merkt ook op dat het 'helaas' heel makkelijk is om snel een andere site online te zetten, waarna de crimineel verder kan gaan en het politieonderzoek opnieuw moet beginnen.

Maar uiteindelijk gaat het Shield wel om sites die niet door de rechtbank als verboden zijn verklaard, maar waarvan het NCSC en providers zeggen dat ze crimineel zijn. Niemand zal zeggen dat mensen niet beschermd moeten worden tegen criminaliteit, maar je kunt je afvragen of providers en het NCSC dan moeten bepalen wat 'crimineel' is of niet en op basis daarvan sites blokkeren, zonder tussenkomst van de rechter.

Het gaat ons alleen om criminele websites. We willen geen scheidsrechter spelen.

Goksites?

Critici zouden daarom kunnen vrezen voor function creep. De lijst blijkt succesvol in het blokkeren van scamsites. Zo'n lijst zou dan ook handig kunnen zijn voor het blokkeren van andere 'ongewenste' sites, zoals bijvoorbeeld goksites. Dit wijzen zowel KPN als het NCSC resoluut van de hand. "Het gaat ons echt alleen om het blokkeren van criminele websites", zegt Leusink. "Dat is een harde lijn die wij willen trekken. Voor de rest willen we geen scheidsrechter spelen en bepalen wat klanten wel of niet mogen bezoeken."

Het Nederlandse Anti Phishing Shield is niet volledig uniek; in België bestaat het al langer. De Belgische versie werkt net als de Nederlandse variant op DNS-niveau en wordt beheerd door het Centrum voor Cybersecurity België. Dit systeem lijkt geen opt-in te zijn, waardoor het ook groter is dan de Nederlandse variant. Zo werd er vorig jaar 200 miljoen keer een waarschuwingspagina getoond aan Belgische internetgebruikers. Belgen die niet mee willen doen aan APS moeten een alternatieve DNS-provider kiezen.

De melding die de Belgische Anti-Phishing Shield toont.

Meer providers en 5G

De Nederlandse pilot is nu dus klaar, maar daarmee verdwijnt het schild niet. Dat blijft gewoon bestaan. Sterker nog, het NCSC en KPN willen nu kijken hoe ze het verder willen uitbreiden. Nu is het aantal deelnemende providers nog relatief laag, maar ze hopen meer providers te kunnen toevoegen.

KPN wil ook kijken naar gebruik op het mobiele netwerk. Nu werkt het APS om 'technische redenen' alleen met vaste netwerken. Klanten die dus op het mobiele netwerk op een phishinglink klikken, krijgen de scamsite nog steeds te zien. Leusink sluit niet uit dat het APS uiteindelijk ook voor mobiele klanten beschikbaar komt.

"Dit is een pragmatische oplossing om effect te bereiken", zegt Leusink. Zents zegt dat zulke publiek-private samenwerkingen belangrijk zijn omdat 'je per definitie zo meer kunt bereiken'. Zents: "Het succes van deze pilot laat zien dat we door samen te werken consumenten kunnen beschermen tegen de gevaren van phishing."

_{Redactie: Hayte Hugo • Eindredactie: Monique van den Boomen • Bannerafbeelding: BestForBest / Getty Images}

Reacties (78)

[Guru Evi]

Ten eerste zijn er meer dan 160,000 phishing and scamsites. Gewoon een commerciele blocklijst gebruiken ipv de overheid te laten regelen, daar staan gemakkelijk 1.6M scam sites op. Maandelijks worden er volgens onderzoek ~300,000 nieuwe scam sites gelanceerd.

Ten tweede is dit tegenwoordig ontwijkt met VPN, DoH en DNSSEC. Daarmee de 'technische redenen' dat dit niet gedaan wordt op mobiele netwerken, is dat Apple dit soort onzin niet graag ziet en gaat mekkeren dat ze de privacy schenden. En met macOS zie je nu ook meer aansporingen om veilige DNS en VPN te gebruiken (ingebakken in het OS).

Ten derde is DNS niet bedoeld om sites te blokkeren.

De taal die ze gebruiken ""Het gaat ons echt alleen om het blokkeren van criminele websites" - nee, ik dacht dat het gaat om scamsites, niet criminele sites. Interessante herwoording van het doel. Zijn goksites 'crimineel', zijn pornosites 'crimineel' - misschien als ze je informatie niet doorgeven naar de overheid zijn ze wel crimineel?

[Reactie gewijzigd door Guru Evi op 30 maart 2026 16:25]

[Annihilism]

VPN is tegenwoordig bijna niet meer te gebruiken. Bijna altijd loop je tegen een cloudflare blokkade aan of een eindeloos "prove you're not a bot" ritueel.

Even afgezien daarvan vind ik filtering door je isp echt een verschrikkelijk idee waar extreem conservatieve partijen maar wat graag misbruik van gaan maken door het op een gegeven moment te verplichten. Die smullen van censuur en surveillance.

[Morrowind3]

Ligt aan je VPN. Met Mullvad had ik er een stuk meer last van dan met Proton. En met proton kun je ook specifieke websites whitelisten als het echt niet anders kan.

[Guru Evi]

Hangt af van je VPN. Apple heeft een in iCloud dat heel goed werkt. NordVPN doet het bij mij ook relatief goed, enkel de meest restrictieve CloudFlare instellingen voor bepaalde sites hebben er problemen mee.

[Llopigat]

Ja maar een site heeft geen controle over welke dns je gebruikt. Een app wel, dus apps kunnen DoH gebruiken om bijvoorbeeld een pihole te omzeilen. Veel doen dat ook.

Maar phishing gaat meestal gewoon via een linkje en dan gebruikt hij gewoon je systeem dns.

[jimshatt]

Ik zie stichting BREIN al staan trappelen...

[Powersoft744]

Is dit ook los van kpn beschikbaar rechtstreeks bij Ncsc? Ik kan namelijk in mijn router zelf alternatieve dns-filters invoegen. Ik heb er liever zelf controle over.

[Mit-46]

Ik gebruik die van Quad9 sinds enige tijd terwijl ik juist KPN heb.

Quad9 doet dit onder andere ook.

Wel vind ik het goed dat providers dit ook (gaan) doen. Ik begrijp alleen niet waarom het niet al standaard is en ook niet waarom het af moet hangen van de NCSC.

[Reactie gewijzigd door Mit-46 op 30 maart 2026 17:10]

[Fido]

Het gebeurt regelmatig dat een phishingsite onderdeel is van een (gehackte) legitieme website. Je kan dan niet via DNS blokkeren omdat je dan de legitieme website ook blokkeert. Niet dat daar iemand van wakker ligt, maar toch.

[Reactie gewijzigd door Fido op 31 maart 2026 13:54]

[Mit-46]

Ik moet bekennen dat ik niet weet wat de regels zijn hieromtrent, maar het lijkt mij wel een legitieme reden om zo'n website op dat moment in ieder geval te blokkeren.

[m.z]

Dit dus. Ik onderzoek, nou ja, controleer phishing mails op dagelijkse basis. Deze “wall” zit er dus al tussen. Dus een deel wordt voor mij gedaan. Ik controleer vervolgens de inhoud van de mail zelf en waar nodig de urls/bijlagen in een sandbox.

Het is mij opgevallen dat er geregeld legitieme websites “gekaapt” zijn en ingezet zijn als phishing. Simpel voorbeeld wat ik ben tegengekomen, zijn willekeurige hotel websites het slachtoffer zijn geworden en een gecomprimeerde pagina of server hebben.

Dit niet alleen, een meer voor de hand liggend incident is: e-mail account is gehackt en vanuit dat account worden phishing mails verstuurd.

Ik weet niet hoe ze dit bij KPN gaan doen en hoe dit actief actueel blijft. Grotere partijen hebben al veel data met inzicht op wat verdacht is en wat niet. Vooralsnog moet ik ook input geven, door sites/afzender/domein op de blokkade lijst te plaatsen, maar ook bepaalde criteria die voorkomen in phishing opnemen in een filter.

[Gert]

Iemand moet het centraal coördineren en dan is het NCSC, in Nederland een logische partij.

[adejoode]

Een overheid zou niet moeten bepalen war je wel/niet mag zien, of wat wel/niet OK is. Je kunt dat beter privaat regelen (bv via een Stichting), NCSC zou dan 1 van de bronnen kunnen zijn.

(in casu zie je bovenstaande dus ncsc geeft een voorzet, provider checkt en implementeert).

[Lucb1e]

Quad9 heb ik een minder hoge pet van op sinds ze mijn domein op zwart gooiden na een foutieve melding. Je kan er ook niet zomaar omheen zoals met Safebrowsing waar een "toch doorgaan"-knop is: het hele domein resolve't niet meer, je computer kán er niet meer mee verbinden tot de dns cache leeg is. Quad9 zegt natuurlijk van niks te weten en verwijst naar zo'n twintig derden waar ze data van ontvangen. Daarvan heb ik enkele benaderd uit interesse hoe het probleem ontstaan is, maar geen enkele heeft ook maar gereageerd, en ze hebben ook niet allemaal een contactmogelijkheid. Je bent gewoon de sjaak als je eenmaal op zo'n lijst staat. (Daarnaast lijken ze blindelings van elkaar te kopiëren, of wellicht is er een gemeenschappelijke bron die ze niet wilden prijsgeven. Als die bal eenmaal rolt is er weinig meer wat je kan doen...)

Toevallig zag een medewerker de problematiek beschreven in een subthread op hackernews en hebben ze me toen handmatig gedeblokkeerd, maar dat geluk moet je ook maar hebben

[Pietervs]

Ik zat het me ook af te vragen: zeker op DNS niveau zou het fijn zijn als die lijsten beschikbaar zijn zodat ze toegevoegd kunnen worden aan Pihole of Adguard, bijvoorbeeld.

[RoestVrijStaal]

Net zoals bij elke zwarte lijst of het nou malware, spyware of adware tegen houdt: het wordt niet up-to-date gehouden.

Bij ieder willekeurige lijst van een adblocker of dnsblocker kan ik domeinen vinden die expired zijn of naar een landing page van een domeinboer redirecten. In het slechtste geval een "normale website".

Daarom vind ik dit initiatief maar een slecht idee. Enkel het toevoegen wordt gecontroleerd, niet of de inhoud nog valide is.

[paulwump]

uit het artikel: Die lijst wordt elk kwartier bijgewerkt door het NCSC en direct gedeeld met internetproviders.

[RoestVrijStaal]

"Bijwerken" betekent niet "Verouderde records verwijderen".

Nergens uit de passage, waarvan jij één zin uit quote, dat zoiets gebeurd.

Misschien dat providers wel een check doen of ieder domein überhaupt nog "alive and evil" is. Maar ik lees nergens dat die provider dat doet, laat staan dat het haar bevindingen terugkoppelt aan het NCSC.

[Het.Draakje]

Over het algemeen wordt met bijwerken bedoeld dat de oude records verwijderd worden (en nieuwe toegevoegd).

Dus "leuk" die aanname van jou, maar gaarne even onderbouwen waarom jij denkt dat NCSC dergelijke ondoordachte werkwijze zou hanteren.

[RoestVrijStaal]

Dus "leuk" die aanname van jou, maar gaarne even onderbouwen waarom jij denkt dat NCSC dergelijke ondoordachte werkwijze zou hanteren.

Nu doe jij de aanname dat NCSC elke van de 160 000+ domeinen periodiek gaat controleren of het nog geregistreerd is en voor phishing wordt gebruikt.

Ik ga ervan uit dat net als bij ieder andere zwarte lijst de lijst enkel gaat groeien. En dat het niet regelmatig in gesnoeid gaat worden. Wat kostelijk door de arbeidsintensiviteit, maar wel zo wenselijk is.

Het artikel geeft noch voor "mijn aanname" noch voor "jouw aanname" duidelijkheid erover.

Het feit dat de zware lijst niet openbaar is, helpt ook niet.

[Reactie gewijzigd door RoestVrijStaal op 30 maart 2026 21:12]

[Het.Draakje]

Quote:

Providers ... controleren of er geen fouten in staan. ..... slechts één onterechte blokkade ... 'wat we snel konden terugdraaien'.

Met andere woorden:

• Er is controle op de sites.
• Er is een terugkoppeling naar NCSC
• Een site is verwijderd van de blokkade omdat het onjuist was.

Dus nogmaals leuk dat je aanneemt dat er geen verwijdering van sites plaats vindt maar jouw aanname is nergens op gebaseerd. Het omgekeerde is wel bewezen.

[mvn23]

Dus de last van het controleren of sites er (al dan niet na een onbepaalde periode) onterecht tussen staan wordt bij de providers gelegd? Of hoe moet ik dit zien?

[Het.Draakje]

Dat de providers zelf controleren lijkt me logisch. Zij zijn juridisch aansprakelijk als een site ten onrechte geblokkeerd wordt.

In neem aan (zo zou ik het zelf opzetten) dat NCSC zelf ook e.e.a. controleert.

[Bor]

Nu doe jij de aanname dat NCSC elke van de 160 000+ domeinen periodiek gaat controleren of het nog geregistreerd is en voor phishing wordt gebruikt.

Stap 1 is in ieder geval al zeer eenvoudig te automatiseren

[Lucb1e]

Ik kan beamen wat @RoestVrijStaal zegt over dat dit soort lijsten niet worden bijgewerkt, in de zin van nalopen of de meldingen nog kloppen.

De NS-website kan wel elke 15 minuten de lijst met vertragingen "bijwerken", maar daar heb je niks aan tot iemand (zoals een sensor van prorail) terugkoppelt of de data voor een gegeven trein nog klopt. Dat laatste gebeurt letterlijk nooit in het geval van domeinen. Je moet ze als website-eigenaar tot actie proberen over te halen.

Als er eenmaal een (al dan niet automatische) melding binnenkomt, vind je onder elke steen die je omkeert weer een nieuwe zwarte lijst die jouw domein heeft opgenomen. Ze kopiëren items van elkaar zonder controle (immers hadden ze de, in mijn geval, false-positive dan opgemerkt). Je kan vervolgens bij ze allemaal gaan aankloppen en veruit de meeste geven niet thuis, enkele hebben überhaupt geen contactmogelijkheid, en weer anderen vereisen bijvoorbeeld naamsbekendheid voordat ze geloven dat je legit bent en niet een scammer met een nieuw domein (ook al is je domein oud genoeg om bier te drinken). In mijn geval ging het zelfs zover dat mijn registrar verhaal kwam halen, die e-mail niet afgeleverd werd (ik zag in mijn logs hun server verbinden en, zonder afleverpoging, de verbinding weer verbreken), waarna het domein helemáál op zwart ging tot ze op maandagochtend weer te bereiken waren het zal je bedrijf maar zijn. In mijn geval is het een hobbyprojectje

[njittam]

Dit klopt niet. Volgens de website van NCSC

Domeinen die offline zijn gehaald of niet meer malafide zijn, worden van de lijst gehaald.

https://www.ncsc.nl/nieuws/ruim-twee-miljoen-bezoeken-aan-kwaadaardige-websites-voorkomen-in-pilot

[RoestVrijStaal]

Jammer dat die cruciale zin niet in dit artikel is opgenomen.

[supersnathan94]

Daarom vind ik dit initiatief maar een slecht idee. Enkel het toevoegen wordt gecontroleerd, niet of de inhoud nog valide is.

Het probleem is alleen. Wie bepaalt dat de "invalide" inhoud betekent dat het weer een veilig domein is?

Wat mij betreft kun je er immers nooit meer vanuit gaan dat het domein daadwerkelijk safe is. Ook al staat ie in parked mode, dat is natuurlijk een zeeeer simpele redirect in je configpanel. Hoef je werkelijk waar weinig voor te doen.

En als dat het criterium wordt, is het natuurlijk kinderlijk eenvoudig om bepaald verkeer wel naar die redirect te gooien en ander verkeer niet, waardoor je dus nooit meer met zekerheid kunt zeggen dat het géén phishing is.

Want als men ieder kwartier de inhoud gaat controleren heeft men dat zo gefingerprint. Dat verkeer identificeer je in een paar uur. Als kwaadwillende heb je daar zo een filtertje voor wat dat verkeer doorzet naar whatever. dat betekent niet dat de inhoud ook altijd veilig is.

Nee we missen er als mensheid helemaal niks aan als dat domein gewoon gepurged wordt. Gewoon nooit meer gebruiken.

[Noxious]

Hoe werkt dit eigenlijk met TLS? Is er een specifiek seintje via DNS naar de browser dat een website onveilig is, of wordt het afgevangen naar een webserver bij de ISP die van een CA een certificaat krijgt voor dit domein 'for the good cause'?

[Keyb]

Dit gaat volledig buiten TLS om. Je browser vraagt eerst aan de DNS server waar de webserver staat (ip adres) en in dat stukje hebben ze hier dus ingebouwd dat je daar een ander antwoord zal krijgen.

Pas daarna zou je met een TLS handshake beginnen waar je die hostname nog eens meestuurt zodat de webserver ook weet welke website je geserveert gaat krijgen.

[mbe81]

En daar zit dus precies de vraag: Hoe kan deze andere server een certificaat presenteren voor het domein wat oorspronkelijk bij de phishingsite hoorde?

[blinchik]

Bij moderne browsers denk ik dat dit inderdaad niet kan, want die proberen eerst https. Dus als het IP verandert kom je direct op een "verkeerd" certificaat terecht en krijg je een waarschuwing ipv een nette pagina.

[Steam_Deck]

Even kijken of ik het goed begrijp. Als ik mijn browser instel op https only dan ben ik eigenlijk al beschermd tegen fishing, omdat een fishing website nooit een correct TLS certificaat kan presenteren. Klopt dat een beetje?

[LOTG]

Dat hoeft toch niet? Het is een DNS request, en je browser kan nu ook DNS errors weer geven en je request komt nooit aan bij de server die je wilde bereiken.

Als je zelf lokaal een DNS draait met filter krijg je ook DNS errors als die geblokt word.

[Noxious]

Vandaar mijn vraag of hiervoor een speciale response in DNS zit die de browsers verteld dat het een 'kwaadaardige site' is; zoals op bovenstaande screenshot.

Het is geen leeg antwoord, anders zou je dat voor iedere niet bestaande site krijgen

[LOTG]

Die screenshot is van de variant die nu in België beschikbaar is. Ik zie niet zo snel hoe het werkt met die pagina maar ik zie wel dat er een browser extensie is.

Het is uiteraard ook gewoon mogelijk dat je die pagina krijgt met een certificaat error er bij.

[Reactie gewijzigd door LOTG op 30 maart 2026 17:26]

[doavid]

Op dit moment bij een provider zoals kliksafe krijg je bij hun dns filtering nu idd een timeout met errorcode te zien.

[Keyb]

Dat kan die server niet en dat is niet nodig aangezien KPN zich niet gaat voordoen als die site. Ze zouden een redirect kunnen sturen bijv.

[Noxious]

Voor een redirect (30x) heb je echter eerst een TLS sessie nodig (assuming https).

[Reactie gewijzigd door Noxious op 30 maart 2026 17:16]

[Keyb]

KPN staat volgens mij wel in de CAs van de meeste browsers, dus zullen ze dat kunnen 'misbruiken' of ze laten voor https gewoon een lelijke certificaat fout zien.

[Noxious]

Dat was denk ik 'vroeger' via PKIoverheid (Staat der Nederlanden root); maar die publieke chain is er niet meer.

[Keyb]

Ja, dan wil ik nu ook wel weten hoe de vork in de steel zit.

[kr4t0s]

Dit werkt niet met CA's dit is in browser ingebouwde feature genaamd "Google Safe Browsing" (firefox gebruikt dat ook). Je browser download op de achtergrond regelmatig een hash lijst en check die lijst als je naar een site gaat. Als die site die lijst staat krijg je dus deze waarschuwing. Dat heet een interstitial pagina en staan hier chrome://interstitials/ en chrome://safe-browsing/ . En voor firefox: about:blocked

[Reactie gewijzigd door kr4t0s op 30 maart 2026 20:11]

[OlivierH]

Hmmm, kunnen ze dit misschien in dat DNS4EU inbouwen?
nieuws: Europese DNS-resolver DNS4EU die websites kan filteren is beschikbaar

Los van dat bovenstaand me wel mooi zou lijken, ben ik het wel eens met het benoemde gevaar hiervan, wie zegt ons dat ze dit in de toekomst niet voor andere dingen gaan gebruiken? ik zie ondertussen ook wel eens dat Ziggo websites blokkeerd die in essentie gewoon legaal zijn (geen torrentsites ofzo, maar digital security dingen die dan opeens niet bereikbaar zijn want och en wee er word iets uitgelegd)

[Klaus_1250]

Je kan beter gewoon je eigen DNS runnen. Genoeg blocklists te vinden om alle meuk eruit te filteren en je kan dan zelf kiezen wat je wel en niet in je netwerk wil.

As for DNS4EU, het is een DNS resolver van een europees bedrijf, medegefinancieerd door de EU. Maar er zijn genoeg andere europese DNS aanbieders te vinden).

[GertMenkel]

DNS-servers op internet gebruiken heeft twee voordelen: je verbinding naar de DNS-provider wordt versleuteld zodat je provider niet mee kan lezen, en je maakt gebruik van een gedeelde cache waardoor een website met een belaste DNS-server alsnog snel te bereiken is.

Als je thuis een recursieve resolver draait, raak je op zijn minst dat eerste kwijt. Ziggo kan triviaal je DNS-verzoeken monitoren en de antwoorden zelfs aanpassen.

Het tweede grote voordeel is afhankelijk van hoe je internet gebruikt, maar ik bezoek regelmatig websites die ik nog niet eerder bezocht hebt en zelfs de websites die ik vaak bezoek hebben vaak een TTL die tussen bezoeken nog wel eens verlopen zouden kunnen zijn.

Daarnaast heeft een gedeelde DNS-server nog het voordeel dat je minder makkelijk te tracken bent als je DNS-provider je IP-range niet meestuurt via EDNS (zoals Cloudflare dat niet doet). Kun je ook in je eigen DNS-server uitzetten, maar als alleengebruiker van je DNS-server ben je nogal makkelijk te identificeren

Qua Europese upstream-DNS-servers ken ik er niet zoveel, heb je daar misschien een lijstje van? DNS4EU heeft juist omdat het in de EU gehost wordt zijn populariteit verworven.

Als Tweaker raad ik zeker aan om een eigen DNS-server te draaien, namelijk om als tracking/adblocker te dienen zoals Pihole of diens alternatieven, maar zelfs dan zijn er goede redenen om DoH-servers te gebruiken.

[Pietervs]

Als je thuis een recursieve resolver draait, raak je op zijn minst dat eerste kwijt.

Tenzij je unbound draait en rechtstreeks bij de rootservers je DNS resolved.

Dat neemt ook meteen het tracking-bezwaar weg.

[GertMenkel]

Verkeer naar rootservers is onversleuteld, dus je biedt alleen maar meer opties om op afgeluisterd te worden. Plus, wellicht dat er rootservers zijn die recursie aanbieden, maar doorgaans zul je toch echt zelf de recursie moeten uitvoeren die nodig is om een domain op te halen.

Als ik de RIPE-rootserver om een specifiek domain vraag, dan krijg ik hooguit de DNS-servers van .nl terug (de NS-records en omdat de root-server zo lief is zelfs de A/AAAA records).

Het enige dat je oplost door te beginnen bij rootservers is het risico dat iemand een cache heeft verpest. Bij het opzoeken van DNSSEC-domeinen kun je vaak zelfs nog zien of iemand met de resultaten zit te klooien (dan moet het domein wel DNSSEC kunnen, dat kan wat, 5% van de wereldwijde domeinen? 't is bijna ongebruikt op een paar specifieke landen na!), maar het origineel haal je niet terug, je moet ook nog eens de kosten betalen voor TCP-verbindingen omdat DNSSEC-sleutels al snel te groot zijn voor UDP-pakketten.

Het trackingprobleem verandert er in elk geval niet door.

[Pietervs]

Unbound supports DNS-over-TLS and DNS-over-HTTPS

Dus het verkeer hoeft niet unencrypted te zijn.

[GertMenkel]

Ik kan maar één root-server vinden die DoT ondersteunt (die in Berkeley; die van RIPE lijkt niet meer te werken?) en zelfs dan moet je iedere volgende stap in de recursieve keten nog zonder DoT/DoH doen. ns1/2/3/4.dns.nl doen bijvoorbeeld al geen DoT dus daar houdt ver versleutelde keten op.

DoT/DoH combineren met een DNS-resolver, is inderdaad wel zo verstandig als je DNS-resolver naar keuze die optie biedt, maar bij zelf resolven vanaf root-servers gaat DoT je weinig helpen.

[Pietervs]

Als ik kijk naar de lijst met root-servers, zie ik dat er de nodige (b, c, e, f, g om er een paar te noemen) Bind gebruiken. En bind ondersteunt DoT. En DoH. Maar blijkbaar wordt dat niet of nauwelijks geïmplementeerd?

(Volgens ChatGPT zouden de voordelen te beperkt zijn ten opzichtevan de nadelen, eigenlijk ook wat jij al zei).

[atthias]

mullvad DNS lijkt redelijk goed te zijn en is Zweeds als ik het internet moet geloven?

[Bor]

DNS-servers op internet gebruiken heeft twee voordelen: je verbinding naar de DNS-provider wordt versleuteld zodat je provider niet mee kan lezen, en je maakt gebruik van een gedeelde cache waardoor een website met een belaste DNS-server alsnog snel te bereiken is.

Dat eerste hoeft helemaal niet en is afhankelijk van jouw client. Caching doet je client oook. Hoe vaak het jij een systeem niet kunnen bereiken door een "belaste DNS-server" en waarom zou de "DNS server op internet" niet (over)belast kunnen zijn?

Verder verleg je met encryptie alleen het punt waarop jouw requests bekeken kunnen worden. Dat kan bij je eigen provider zijn maar ook bij "de server op Internet" (die veelal niet perse onder NL of EU wetgeving valt).

[Reactie gewijzigd door Bor op 30 maart 2026 22:27]

[Steam_Deck]

Zoals nextdns. Nietwaar?

[Commendatore]

Ik heb altijd een beetje een dubbel gevoel bij DNS-filtering door providers. Aan de ene kant geeft het een wat minder technisch onderlegd publiek een klein beetje extra bescherming, aan de andere kant is het verre van waterdicht en kan daardoor ook schijnveiligheid opleveren. Denk aan een smartphone die buiten het bereik van het WiFi-netwerk komt en dan ineens weer via ongefilterde DNS gaat, software die niet de DNS van het netwerk gebruikt, maar ook gewoon websites die door het net glippen. Mensen denken dan ten onrechte dat ze volledig veilig zijn en worden misschien een beetje nonchalant. Het zou beter zijn als dit op OS of browserniveau gebeurt. (Wat voor een deel ook al zo is.)

Daarnaast heb je natuurlijk ook nog het probleem van false positives wat tot rare situaties kan leiden die niet meteen verklaarbaar zijn; een voorbeeld hiervan is het malwarefilter van KPN dat een keer korte tijd de berichtenbox van Mijn Overheid blokkeerde. Mede hierom is het belangrijk dat providers transparant zijn over hoe de lijst met geblokkeerde websites samengesteld wordt, wat nu maar heel beperkt het geval is, en dat het makkelijk is om false positives te melden, die dan ook snel opgelost moeten worden.

[BvdW1978]

KPN blokkeert op de netwerklaag. Ze doen lookups met de DNS-lijst, en blokkeren vervolgens de IP's op een centraal firewallplatform. Werkt dat false-positives in de hand? Jazeker. Daarom kijken er ook mensen mee voor als er een complete CDN in het putje verdwijnt.

[Paddy99]

Dus dit kan ik straks toevoegen aan mijn PiHole? Gewoon een lijstje erbij en done (?), dit zou wellicht handig zijn oor mij en de rest van de fam.

[biteMark]

Kan dit niet met de dns op je eigen router? Een in-memory whitelist met veelgebruikte domeinen (google, banken, overheden etc.), aangevuld met veilige domeinen die door gebruikers van het netwerk vaak worden bezocht (nieuwssites, marktplaats etc.) kan hoog cpu-/geheugengebruik en langdurige controles voorkomen. Meer exotische domeinen kunnen in de tabel met onveilige domeinen worden opgezocht. Een chron-job kan checken of de whitelist domeinen bevat die inmiddels gevlagt zijn en uit de whitelist halen.

Op die manier zouden providers helemaal niet meer je internetverkeer in de gaten hoeven houden, alleen maar de blacklist naar je router pushen. NCSC kan de blacklist beschikbaar maken voor mensen die niet de router van hun provider gebruiken maar bijv. een pi-hole o.i.d.

[RVNetwork]

Ik zou inderdaad best een blocklist (voor Pi-Hole) willen 'accepteren'. Als het doel daadwerkelijk is om gebruikers te beschermen (en niet af te schermen) lijkt me dat deze er ook wel komt (?).

Het voordeel van Pi-Hole is dat je eigen regie hebt, fijn om onder de streep alsnog zelf te bepalen of je wel of niet een website bezoekt, los van de logging die eventueel op de (NCSC) DNS servers plaats zal vinden.

On-topic: Dit lijkt me voor mijn ouders/digibeten in de familie erg handig. Vooral als deze ook op de mobiele DNS doorgevoerd kan worden (KPN mobile?). Ikzelf heb een best zware blocklist, een Pi-Hole bij de familie is één en al ellende omdat telkens doorverwijzingen/reclame URL's geblokkeerd worden :-)

[kodak]

Iedereen kent wel een familielid, vriend of kennis die slachtoffer is geworden van phishing,

Vreemde stelling. Het initiatief doet daar geen beweringen over en het lijkt verder ook niet gebaseerd op een onafhankelijk onderzoek. Het lijkt me eerder dat mensen zich zorgen om phishing maken, ongeacht of men werkelijk slachtoffers kent. En dat is zo te lezen al reden om het aan te bieden, maar ook om er niet zomaar gebruik van te willen maken.

[thof]

Wel benieuwd hoe dit dan zit met DoH (DNS over HTTPS). Ik zie dat KPN tegenwoordig ook DoH aanbiedt: https://community.kpn.com/internet-9/dns-over-tls-dot-wordt-inmiddels-ondersteund-door-kpn-625966

Dan rest nog de vraag of deze dienst ook doorgetrokken is naar DoH of dat het alleen op de regulier DNS geregeld is.