DNS-filtering voor de middenmarkt: hoe DNS-beveiliging in de cloud werkt in 2026

DNS-filtering heeft zich ontwikkeld van een vinkbox voor webbeleid tot een van de goedkoopste en snelste lagen van cyberdefensie die een IT-team in het middensegment kan inzetten. Het blokkeert schadelijke domeinen voordat er verbinding wordt gemaakt, wat betekent dat phishingpagina’s niet worden geladen, ransomware zijn commandoserver niet kan bereiken en medewerkers op Wi-Fi in een hotel dezelfde bescherming krijgen als medewerkers op het hoofdkantoor. In deze handleiding wordt uitgelegd hoe DNS-filtering in de cloud werkt in 2026, wat het tegenhoudt, waar het tekortschiet en hoe je een leverancier moet evalueren als je 200 gebruikers hebt, geen SOC en een lijst met NIS2-controles waaraan je moet voldoen.

Wat is DNS-filtering en hoe werkt het in 2026?

DNS-filtering inspecteert elke zoekopdracht naar een domeinnaam die een apparaat uitvoert en beslist, op basis van beleid en informatie over bedreigingen, of deze wordt omgezet. Vijf dingen die u moet weten voordat u begint met evalueren:

• Het werkt op de DNS-laag, vóór de verbinding. Een geblokkeerd domein geeft nooit een IP-adres terug, dus de kwaadaardige pagina wordt nooit geladen en het C2-kanaal van de ransomware wordt nooit geopend.
• Door de cloud geleverde DNS-filtering vervangt lokale DNS-appliances door een wereldwijd Anycast-resolvernetwerk. Updates worden op elk apparaat toegepast zodra een nieuwe bedreiging wordt geïdentificeerd.
• Moderne filtering analyseert de query zelf. Algoritmes markeren nieuw geregistreerde domeinen, door AI gegenereerde namen en patronen die typisch zijn voor DNS-tunnelling.
• Identiteitsbewuste platformen koppelen het beleid aan de gebruiker en het apparaat, niet aan het IP-adres. Een financiële rol krijgt andere DNS-regels dan een aannemer op een onbeheerde laptop.
• Het is een onderdeel van een bredere beveiligingsarchitectuur. Cloud-beheerde SASE-platforms zoals Jimber bevatten DNS-filtering als een standaardlaag, niet als een aparte licentie.

Hoe DNS-filtering in de cloud eigenlijk werkt

Telkens wanneer een apparaat een website probeert te bereiken, een e-mail probeert te versturen, een SaaS-tool probeert te synchroniseren of zich probeert aan te melden bij een software-updateserver, stuurt het eerst een DNS-query. Die query vraagt een resolver om een menselijk leesbare naam te vertalen naar een IP-adres. DNS-filtering in de cloud bevindt zich in dat pad.

Het zoekpad, stap voor stap

Wanneer een gebruiker een URL in een browser typt of een applicatie een verbinding opent, stuurt het apparaat de DNS-query naar de geconfigureerde resolver. In een cloudmodel bevindt die resolver zich in een wereldwijd Anycast-netwerk, dat het verzoek doorstuurt naar het dichtstbijzijnde Point of Presence. Van daaruit:

1. De resolver identificeert de bron. Voor kantoorlocaties gebeurt dit via IP-gebaseerde identificatie of een IPsec- of GRE-tunnel. Voor mobiele en externe gebruikers identificeert een lichtgewicht roaming client het apparaat en de gebruiker.
2. De resolver controleert de query aan de hand van het beleid. Het beleid combineert statische blokkeer- en toestemmingslijsten, realtime informatiefeeds over bedreigingen, categorieregels (gokken, volwassenen, sociaal) en identiteitscontext indien geïntegreerd met de IdP.
3. Analyse op query-niveau wordt parallel uitgevoerd. De resolver inspecteert het domein zelf: hoe recent het geregistreerd is, het lexicale patroon van de naam, de entropie van het subdomein en of het querytype of -volume er abnormaal uitziet.
4. De resolver beslist. Als het IP schoon is, wordt het teruggestuurd. Als het kwaadaardig is, wordt sinkholing toegepast en wordt een gecontroleerd IP teruggestuurd dat naar een blokpagina of quarantainehandler wijst. Het IT-team krijgt een waarschuwing die gekoppeld is aan de gebruiker, het apparaat en het domein.

Dit hele proces voegt 5 tot 50 milliseconden toe voor gebruikers in de buurt van een Point of Presence, wat onmerkbaar is. Zonder een PoP in de buurt kan de latentie oplopen tot boven de 100 ms en beginnen gebruikers dit op te merken.

Bedreigingsintelligentie en de rol van AI

De beleidsengine is slechts zo goed als zijn gegevens. Moderne DNS-resolvers verwerken miljarden query’s per dag in hun klantenbestand. Die schaal is de bron van hun informatie over bedreigingen. Wanneer een nieuw phishingdomein wordt gedetecteerd bij één klant in Brussel, geldt de blokkade binnen enkele minuten voor elke klant wereldwijd.

Dit is waar DNS-filtering in de cloud een beslissende voorsprong heeft op filtering op locatie. Industrieel onderzoek uit 2025 wees uit dat de gemiddelde levensduur van een phishingdomein minder dan vier uur is. Tegen de tijd dat een statische blokkadelijst is bijgewerkt en naar een oudere appliance is gestuurd, is de campagne al weer verder. Real-time bedreigingsfeeds, gekoppeld aan gedragsanalyse, zijn het enige mechanisme dat gelijke tred houdt.

DNS-laag AI in 2026 kijkt naar verschillende dingen tegelijk. Nieuw waargenomen domeinen, die in de afgelopen 24 tot 72 uur zijn geregistreerd, worden extra nauwkeurig bekeken. Domain Generation Algorithm-patronen, die duizenden onzinnige namen per dag produceren waar ransomware doorheen draait, worden alleen al op basis van lexicale kenmerken gemarkeerd. Fast-flux DNS, waarbij het IP-adres achter een kwaadaardige naam om de paar minuten verandert om takedown te omzeilen, wordt gepakt door de snelheid van verandering.

Moderne SASE-platforms, waaronder Jimber, voeren deze analyse uit op dezelfde PoP die SWG, ZTNA en firewallbeleid afhandelt. Dat betekent dat het DNS-oordeel direct wordt gedeeld met de rest van de beveiligingsstack.

Welke aanvalstypen DNS-filtering blokkeert en waar het tekortschiet

DNS-filtering is een van de meest waardevolle beveiligingsinvesteringen per euro voor organisaties in het middensegment. De reden hiervoor is de enorme hoeveelheid aanvallen die afhankelijk zijn van een succesvolle DNS-lookup.

Wat het stopt

Phishing en diefstal van referenties. Phishing blijft het belangrijkste toegangspunt voor de meeste inbreuken. In het ENISA-rapport over het bedreigingslandschap van 2025 werd phishing aangewezen als de belangrijkste vector voor initiële toegang, en door AI gegenereerde lokmiddelen hebben de succespercentages aanzienlijk verhoogd. Elke phishing-campagne heeft een domein nodig. Blokkeer het domein op de DNS-laag en de campagne mislukt voordat de gebruiker erin trapt.

Command-and-control communicatie. Malware die op een eindpunt terechtkomt, via een phishingbijlage of een drive-by download, moet zijn operator bereiken. Die communicatie verloopt bijna altijd via DNS. Blokkeer het C2-domein en de malware zwijgt, kan geen instructies ontvangen of gegevens exfiltreren.

Algoritme voor domeingeneratie malware. Ransomwarefamilies zoals Conti en zijn afstammelingen genereren duizenden wegwerpdomeinen per dag. Statische lijsten halen dit nooit in. DNS-filtering met AI-gebaseerde DGA-detectie identificeert het lexicale patroon en blokkeert de hele familie.

DNS-tunneling voor het exfiltreren van gegevens. Sommige aanvallers coderen zelf gestolen gegevens in DNS queries. Een query naar c2hlbGxvd29ybGQ.attacker.com ziet eruit als ruis, maar bevat payloadgegevens. DNS-filters in de cloud detecteren het abnormale volume en de abnormale recordtypes en sluiten het kanaal af.

Nieuw geregistreerde domeinen in het algemeen. De meeste schadelijke infrastructuur is jonger dan een week. Standaard blokkeren of waarschuwen voor nieuw waargenomen domeinen vangt een groot deel van de campagnes die nog niet zijn geclassificeerd.

Waar DNS-filtering tekortschiet

Wees eerlijk tegen je belanghebbenden over de grenzen.

• Harde IP-adressen. Malware die DNS volledig omzeilt en rechtstreeks verbinding maakt met een IP-adres, wordt niet gepakt op de DNS-laag. Dit is ongebruikelijk, maar het komt voor.
• Versleutelde DNS naar malafide resolvers. Een gebruiker of stuk malware kan DoH direct configureren naar een publieke resolver en zo het bedrijfsbeleid omzeilen. Endpointcontroles en firewallregels moeten afdwingen dat al het DNS-verkeer via de goedgekeurde resolver gaat.
• Aanvallen van de applicatielaag. SQL-injectie, cross-site scripting, compromissen in legitieme software. Dit zijn allemaal geen DNS-problemen. Ze hebben WAF, endpoint controls en software supply chain management nodig.
• Misbruik van toegestane domeinen door insiders. Een gebruiker die gevoelige gegevens uploadt naar een gesanctioneerde cloudservice is onzichtbaar voor een DNS-filter. CASB en DLP behandelen die laag.

DNS-filtering is een basislaag, geen complete beveiligingsstrategie. Behandel het als het eerste controlepunt in een defence-in-depth architectuur.

Cloud-levering versus legacy on-premise DNS-filtering

Voor de meeste IT-managers in het middensegment van de markt in 2026 is de vergelijking duidelijk. Hybride werken, uitdijende SaaS en de snelheid van moderne aanvallen hebben on-premise DNS-filtering operationeel onwerkbaar gemaakt voor organisaties van 50 tot 400 gebruikers. De onderstaande tabel laat zien waar de kloof ligt.

Een organisatie met 200 gebruikers die een on-premise resolver gebruikt, besteedt doorgaans één tot twee dagen per kwartaal aan patchen, logrotatie en capaciteitsplanning. Een door de cloud geleverd alternatief reduceert dat tot beleidscontrole en incidentrespons. Voor een klein IT-team is dat het verschil tussen brandjes blussen en strategisch werk.

Het prestatieargument is ook minder eenduidig dan verkopers vroeger beweerden. On-premise resolvers reageren in minder dan een milliseconde op het LAN. Cloud-resolvers voegen daar 5 tot 50 ms aan toe, afhankelijk van de nabijheid van PoP’s. Voor Europese organisaties in het middensegment is het belangrijk of je provider PoP’s heeft in Amsterdam, Brussel, Frankfurt of Londen. Als dat zo is, is de latentie onzichtbaar. Als dat niet het geval is, zullen gebruikers in de Benelux merken dat pagina’s langzamer worden geladen.

Hoe een DNS-filteroplossing evalueren in 2026

Het landschap van leveranciers is overvol. Cisco Umbrella, DNSFilter, Cloudflare Gateway en een lange reeks standalone tools beloven allemaal hetzelfde resultaat. De verschillen zitten in hoe de beleidsengine is opgebouwd, welke gegevens worden verwerkt en waar ze zich bevinden. Gebruik de onderstaande criteria om de ruis te filteren.

1. AI-gestuurde detectie van nieuwe en AI-gegenereerde domeinen

Vraag de verkoper specifiek hoe ze patronen van het algoritme voor domeingeneratie en nieuw waargenomen domeinen detecteren. Het antwoord moet verwijzen naar gedragsanalyse, niet alleen naar langere blokkadelijsten. Als het enige detectiemechanisme bestaat uit feeds op basis van handtekeningen, loopt het product achter op de campagnes die het moet tegenhouden. Vraag om gegevens over de tijd die nodig is om nieuwe bedreigingsdomeinen te blokkeren.

2. Integratie van identiteit en apparaathouding

Een moderne DNS-filter zou identiteit moeten halen uit je IdP (Microsoft Entra ID, Okta, Google Workspace) en beleid moeten toepassen per gebruiker en per groep. Beter nog, het zou een laag moeten aanbrengen in de context van de apparaatstatus, zodat dezelfde gebruiker een ander beleid krijgt op een beheerde laptop dan op een persoonlijke telefoon. Als de leverancier nog steeds voornamelijk praat in termen van IP-gebaseerd beleid, loopt hij achter de feiten aan.

3. Europees ingezetenschap van gegevens en juridische duidelijkheid

Voor NIS2 en GDPR is het niet optioneel waar DNS-logs zich bevinden en wie er toegang toe heeft. Amerikaanse leveranciers vallen onder de CLOUD Act, ongeacht waar hun PoP’s zich bevinden. Een PoP in Frankfurt van een Amerikaanse provider staat niet gelijk aan Europese gegevenssoevereiniteit. Evalueer waar query’s worden geïnspecteerd, waar logs worden opgeslagen en welk wettelijk kader van toepassing is op toegangsverzoeken. Jimber, met hoofdkantoor in België, verwerkt verkeer en slaat logs standaard op binnen de EU-grenzen.

4. Op NIS2 afgestemd loggen en auditrapportage

Auditors willen DNS query logs zien die gecorreleerd kunnen worden met de identiteit van de gebruiker, het apparaat en het resultaat. Controleer of de leverancier configureerbare logboekretentie, SIEM-streaming en auditklare rapporten biedt. Vraag of hun logschema de bewijsvereisten ondersteunt die in CyberFundamentals (CyFun) worden beschreven op het niveau dat uw organisatie moet bereiken.

5. SASE stappenplan en platform geschiktheid

DNS-filtering als zelfstandig product is steeds moeilijker te rechtvaardigen. De markt consolideert zich rond platformen die DNS, SWG, CASB, ZTNA en FWaaS combineren in één inspectiepijplijn. Als je vandaag een standalone DNS-tool koopt, wil je die dan over twee jaar nog steeds hebben als je bredere beveiligingsstack overgaat op SASE? Of bent u beter af als u een platform kiest dat DNS vanaf het begin als één component bevat?

6. Versleutelde DNS-ondersteuning

DNS over HTTPS (DoH) en DNS over TLS (DoT) zijn de privacystandaard in 2026. Een leverancier die nog steeds voornamelijk vertrouwt op UDP/53 in platte tekst geeft aan dat zijn architectuur niet is meegegaan. Even belangrijk: controleer of het platform DoH-verkeer kan onderscheppen en inspecteren, zodat uw beleid niet wordt omzeild door browsers of toepassingen die hun eigen resolvers gebruiken.

7. Multi-tenant beheer voor servicepartners

Als uw organisatie werkt met een MSP, of als u zelf een MSP bent, dan is multi-tenant functionaliteit belangrijk. Eén venster om beleidsregels voor verschillende klanten te beheren, met gedeelde sjablonen en isolatie per huurder, is wat DNS-filtering operationeel levensvatbaar maakt op schaal.

DNS-filtering als SASE-component versus standalone

De eerlijkheid gebiedt te zeggen dat beide paden kunnen werken, maar dat ze passen bij verschillende stadia van organisatievolwassenheid.

Een standalone DNS-filter is zinvol wanneer u een snelle, goedkope beschermingslaag nodig hebt en de rest van uw beveiligingsstack nog niet klaar is om te consolideren. Implementatie kan in een dag worden gedaan. De opbrengst in geblokkeerde bedreigingen per uitgegeven euro is moeilijk te overtreffen. Voor een bedrijf met 50 gebruikers dat nog steeds draait op een basis firewall plus endpoint AV, is het toevoegen van standalone DNS-filtering een verstandige quick win.

DNS-filtering als onderdeel van een SASE-platform is zinvol als je al aan het evalueren bent hoe je firewalls, VPN, webfiltering en toegangscontrole kunt consolideren. Nu een standalone tool kopen betekent een andere leverancier, een ander contract, een andere console. Als je weet dat je binnen 18 maanden overgaat op een geconvergeerde architectuur, dan is het beter om een SASE-platform te kiezen waarin DNS-filtering als laag is opgenomen.

Dit is waar Jimber’s benadering het geconvergeerde model illustreert. DNS-filtering is geen bolt-on. Het wordt uitgevoerd in dezelfde single-pass inspectiepijplijn als ZTNA, SWG, FWaaS en SD-WAN, en beleidsregels delen identiteitscontext over alle engines. Voor een klein IT-team is de operationele eenvoud van één console, één beleidsraamwerk en één logboekpijplijn belangrijker dan welke functie op een vergelijkingsformulier dan ook. Jimbers netwerkisolatieplatform koppelt de DNS-laag standaard aan het beleid per gebruiker en per apparaat. Voor agentloze apparaten zoals printers, IP-camera’s en industriële apparatuur breidt NIAC-hardware DNS-bewuste controles uit naar eindpunten die geen softwareagenten kunnen uitvoeren.

Voor een diepere architecturale kijk op waarom DNS zit waar het zit in een Zero Trust stack, behandelt ons eerdere stuk over DNS beveiliging in Zero Trust de ontwerpgedachte. Deze gids richt zich op de koper-evaluatievraag. De twee stukken vullen elkaar aan.

Implicaties van NIS2 en CyFun voor bescherming op DNS-niveau

NIS2 is in België live gegaan in oktober 2024. Essentiële entiteiten moeten tegen 18 april 2026 een basis of belangrijke verificatie van CyberFundamentals bereiken. Belangrijke entiteiten kunnen vrijwillig hetzelfde doen. DNS-filtering wordt niet expliciet genoemd in artikel 21, maar het valt wel onder de technische en organisatorische maatregelen die auditors verwachten.

Netwerkbeveiliging en detectie van bedreigingen. Artikel 21 vereist passende maatregelen om cyberrisico’s te beheren. Een gedocumenteerd DNS-filterbeleid met logboekregistratie, identiteitscontext en informatie over bedreigingen is een van de duidelijkste demonstraties van bedreigingsdetectie op netwerkniveau aan de controletafel.

Tijdlijnen voor incidentafhandeling en rapportage. NIS2 verplicht een eerste incidentmelding binnen 24 uur en een gedetailleerde beoordeling binnen 72 uur. DNS-querylogs, gecorreleerd met gebruiker en apparaat, zijn vaak het snelste bewijsspoor bij het reconstrueren hoe een phishingcampagne de organisatie heeft bereikt of hoe een stuk malware heeft geprobeerd te communiceren.

Supply chain security. Artikel 21 vereist expliciet dat organisaties de beveiliging van hun leveranciers beheren. DNS-filtering kan beleid afdwingen voor uitgaande communicatie naar domeinen van derden en interacties met nieuwe of niet-geverifieerde leveranciers markeren.

CyFun-kader uitlijning. Het CyFun-raamwerk van het CCB is de praktische vertaling van NIS2 naar de Belgische organisatorische realiteit. De editie 2025 van CyFun is afgestemd op NIST CSF 2.0 en voegt Governance toe als zesde functie. Bescherming op DNS-niveau heeft te maken met Identify (zichtbaarheid in uitgaand verkeer), Protect (blokkeren van kwaadaardige domeinen) en Detect (loggen en waarschuwen). Op de niveaus Belangrijk en Essentieel verwachten auditors dat deze controles werken met identiteitscontext en auditklaar bewijs.

Voor entiteiten die financiële diensten verlenen en onder DORA vallen, gaan de vereisten verder. De integriteit van de DNS-infrastructuur, redundantie en DNSSEC-validatie zijn nu basisverwachtingen voor kritieke entiteiten onder de pijler operationele veerkracht van DORA.

Veelgestelde vragen

Wat is DNS-filtering en wat doet het?

DNS-filtering inspecteert zoekopdrachten naar domeinnamen voordat ze worden omgezet en blokkeert de zoekopdrachten die zijn gekoppeld aan schadelijke of ongewenste bestemmingen. Het stopt phishing, ransomware command-and-control verkeer en toegang tot ongepaste inhoud op de netwerklaag, voordat er verbinding wordt gemaakt met de bestemming. In 2026 omvat moderne DNS-filtering ook gedragsanalyse om AI-gegenereerde domeinen en DNS-tunneling op te sporen.

Hoe werkt DNS-filtering?

Een apparaat stuurt een DNS-query naar een resolver. In een DNS-filter dat door de cloud wordt geleverd, controleert de resolver het gevraagde domein aan de hand van beleidsregels, informatiebronnen over bedreigingen en gedragsregels. Als het domein kwaadaardig is of tegen het beleid indruist, retourneert de resolver een sinkhole-adres in plaats van het echte IP-adres, waardoor de verbinding wordt verhinderd. Het IT-team krijgt een gebeurtenislogboek dat laat zien welke gebruiker en welk apparaat de blokkade hebben veroorzaakt.

Is DNS-filtering de moeite waard voor een organisatie in het middensegment?

Ja. DNS-filtering biedt een van de hoogste rendementen per euro van alle beveiligingscontroles. Het blokkeert een groot deel van de levering van phishing en ransomware zonder endpoint agents, zonder VPN-backhaul en zonder gespecialiseerd personeel. Voor een organisatie van 50 tot 400 gebruikers met een klein IT-team is het een van de minst inspannende lagen met de grootste impact om in te zetten.

Wat blokkeert een DNS-filter dat een firewall niet blokkeert?

Een traditionele firewall inspecteert verkeer op IP-adres, poort en protocol. Meestal laat hij DNS verkeer door op poort 53 zonder veel inspectie. Een DNS filter inspecteert de inhoud van de query zelf, inclusief de domeinnaam, het type record dat wordt opgevraagd en het opzoekpatroon. Hierdoor kunnen nieuw geregistreerde domeinen, AI-gegenereerde domeinen en DNS-tunneling worden opgespoord, die allemaal onzichtbaar zijn voor de meeste firewalls.

Zal DNS-filtering de internetprestaties vertragen?

In een cloudmodel met een Point of Presence in de buurt is de extra latentie meestal 5 tot 50 milliseconden, die onzichtbaar is voor gebruikers. Als de provider geen PoP in uw regio heeft, kan de latentie oplopen tot meer dan 100 ms en merkbaar worden. Controleer voor Europese organisaties of de leverancier PoP’s heeft in Amsterdam, Brussel, Frankfurt of Londen voordat u ondertekent.

Kan DNS-filtering mijn webgateway of firewall vervangen?

Nee. DNS filtering blokkeert domeinen op de resolutielaag. Een Secure Web Gateway inspecteert het eigenlijke HTTP en HTTPS verkeer, inclusief TLS-versleutelde inhoud, bestandsdownloads en categoriegebaseerde browsingregels. Een firewall dwingt het poort- en protocolbeleid af. De drie lagen werken samen. Een verenigd SASE platform combineert ze in één enkele pijplijn.

DNS-filtering op zichzelf is een snelle overwinning. DNS-filtering als onderdeel van een geconvergeerd SASE-platform is de basis van een verdedigbare architectuur. Als je team beide paden evalueert, is de nuttigste volgende stap om je huidige DNS-dekking in kaart te brengen ten opzichte van de NIS2- en CyFun-verwachtingen en te zien waar de hiaten zitten. Boek een demo met Jimber om te zien hoe DNS-filtering, identiteitsbewuste toegang en inline isolatie samenwerken in één console, met standaard Europese gegevensresidentie.