De resolutie van domeinnamen en de controle van TCP-poorten vormen twee pijlers van het netwerkbeveiligingsbeleid. Sinds de inwerkingtreding van de Europese uitvoeringsverordening 2024/2690 op 1 juli 2025, zijn DNS-leveranciers, top-level domeinregisters en cloudservices onderworpen aan specifieke technische vereisten. Dit regelgevend kader verandert de manier waarop netwerkteams DNS-filtering en governance van TCP-stromen moeten benaderen.
Versleutelde DNS en verlies van netwerkzichtbaarheid: een onderschatte blinde vlek
DNS over HTTPS (DoH), DNS over TLS (DoT) en DNS over QUIC beschermen de privacy van verzoeken tussen de client en de resolver. Deze bescherming heeft een keerzijde: wanneer een browser of besturingssysteem een externe resolver gebruikt die niet door de organisatie wordt gecontroleerd, worden interne filteringsbeleid onbruikbaar.
Het probleem beperkt zich niet tot het omzeilen van blokkadelijsten. Een externe resolver kan ook de detectie van gegevensexfiltratie via DNS-tunneling voorkomen, een techniek die informatie in de verzoeken zelf encodeert. Zonder zicht op deze stromen verliezen beveiligingsteams een detectievermogen dat gebaseerd was op de analyse van onversleuteld DNS-verkeer op poort 53.
Om dit zicht te behouden, moet de versleutelde resolutie gecentraliseerd worden naar een interne resolver die compatibel is met DoH of DoT. De beveiligingsbronnen op Open Syd beschrijven de bijbehorende verharde mechanismen. De filtering op het niveau van de firewall moet dan uitgaande DNS-verzoeken naar niet-geautoriseerde externe resolvers blokkeren, ook op poort 443 die door DoH wordt gebruikt.
TCP-poorten en DNS-filtering: een samenhangend controlebeleid opbouwen
DNS gebruikt voornamelijk UDP-poort 53 voor standaardverzoeken. Wanneer het antwoord de maximale grootte van een UDP-datagram (512 bytes standaard) overschrijdt, meldt de server een truncatie en schakelt de client over naar TCP-poort 53 om het volledige antwoord te verkrijgen. Zone-overdrachten tussen DNS-servers gebruiken ook TCP 53.
Deze dualiteit van UDP/TCP creëert een specifieke aanvalsvector. Het blindelings blokkeren van TCP 53 voor uitgaand verkeer kan de resolutie van bepaalde grote records (DNSSEC, lange TXT-records) verstoren. Aan de andere kant vergemakkelijkt het openlaten van TCP 53 zonder restricties DNS-tunneling en ongeautoriseerde zone-overdrachten.
Criteria voor geschikte netwerkfiltering
- Sta TCP 53 alleen toe tussen interne DNS-servers en geïdentificeerde upstream resolvers, nooit rechtstreeks vanaf werkstations
- Beperk tijdelijke bronpoorten (bereik 49152-65535 volgens IANA-aanbevelingen) tot legitieme DNS-resolutieprocessen via applicatiefirewallregels
- Monitor abnormale volumes van uitgaande DNS-verzoeken, een klassieke indicator van tunneling of communicatie met een command-and-controlserver (C2)
- Log DNS-verzoeken op de interne resolver om het SIEM te voeden, wat het verlies van zichtbaarheid als gevolg van end-to-end encryptie compenseert
Filtering op basis van poorten alleen is niet voldoende. De combinatie van poortcontrole en DNS-inhoudsanalyse (inspectie van opgeloste domeinnamen, detectie van hoge entropie in subdomeinen) biedt een robuustere dekking tegen evasietechnieken.
NIS2-verplichtingen: wat de richtlijn verandert voor DNS-beheer
De NIS2-richtlijn (richtlijn (EU) 2022/2555) en de uitvoeringsverordening 2024/2690 introduceren operationele verplichtingen die rechtstreeks van invloed zijn op de DNS-infrastructuur van de betrokken entiteiten.
In geval van een incident dat de beschikbaarheid of integriteit van de DNS-service beïnvloedt, vereist het meldingsmechanisme een initiële waarschuwing binnen 24 uur, gevolgd door een gedetailleerde melding binnen 72 uur, en vervolgens een eindrapport binnen een maand. Deze termijnen veronderstellen een snelle detectie- en kwalificatiecapaciteit van DNS-incidenten.
De verordening dekt ook de beveiliging van de toeleveringsketen, cryptografie en toegangscontrole. Voor een netwerkbeheerder betekent dit dat de keuze voor een externe DNS-resolver (cloudservice, openbare resolver) een evaluatie van de leverancier op basis van deze criteria moet omvatten. De ervaringen op dit punt lopen uiteen: sommige organisaties beschouwen grote openbare resolvers als veerkrachtiger, terwijl anderen van mening zijn dat de afhankelijkheid van een derde partij het regelgevingsrisico vergroot.
Netwerksegmentatie en DNS: de blootstellingsoppervlakte verminderen door routing
Netwerksegmentatie beperkt de verspreiding van een compromis, maar de interactie met DNS wordt zelden in detail behandeld. Een netwerk dat is gesegmenteerd in VLAN met een enkele DNS-resolver voor alle segmenten biedt een draaipunt voor een aanvaller die deze resolver compromitteert.
Het implementeren van specifieke DNS-resolvers per netwerksegment vermindert dit risico. Elke resolver lost alleen de namen op die nodig zijn voor het segment dat hij bedient, en de firewallregels verbieden ongeautoriseerde inter-segment DNS-verzoeken. Deze aanpak verzwaren de administratie, maar compartimenteert effectief de laterale bewegingen.
Controlepunten voor een DNS-audit
- Controleren of elk netwerksegment expliciete regels heeft die DNS-verkeer naar specifieke bestemmingen toestaan of weigeren
- Zorgen dat interne DNS-records (privézones) niet toegankelijk zijn vanuit segmenten die aan internet zijn blootgesteld
- Controleren of zone-overdrachten (AXFR/IXFR) zijn beperkt tot alleen geautoriseerde secundaire servers, met TSIG-authenticatie
De samenhang tussen DNS, TCP-poorten en netwerksegmentatie vormt een samenhangend geheel waarvan elk onderdeel de beperkingen van de anderen compenseert. Een poortfiltering zonder DNS-governance blijft doorlatend, net zoals een beveiligde DNS zijn effectiviteit verliest als de netwerkrouting omzeilingen mogelijk maakt. De NIS2-richtlijn dringt er bij organisaties op aan deze samenhang te formaliseren, maar de beschikbare gegevens stellen nog niet in staat om het werkelijke niveau van naleving door de betrokken entiteiten te meten.
