Subdomein overname: hoe een vergeten DNS-record je domein weggeeft
Bijgewerkt: 11 oktober 2026
Kort antwoord: bij een subdomein overname neemt iemand anders een subdomein van jouw organisatie in gebruik, omdat er nog een DNS-record naar een dienst wijst die je hebt opgezegd. De aanvaller claimt die dienst opnieuw en bepaalt daarna wat er op jouw subdomein staat. Je voorkomt het door DNS mee te nemen bij het opzeggen van diensten en door een actuele lijst van je subdomeinen bij te houden.
Hoe het ontstaat
Stel, de afdeling marketing laat een campagnesite bouwen bij een clouddienst. Om die onder je eigen naam bereikbaar te maken, komt er een CNAME-record in je DNS: actie.jouwdomein.nl wijst naar een adres bij de cloudaanbieder. De campagne loopt af en de dienst wordt opgezegd. Niemand denkt aan het DNS-record, dus dat blijft staan. Je subdomein wijst nu naar een naam die niemand meer gebruikt.
Bij veel cloud- en SaaS-diensten kan iedereen een vrijgekomen naam opnieuw aanmaken. Doet een aanvaller dat, dan komt het verkeer naar actie.jouwdomein.nl bij hem uit. Microsoft beschrijft precies dit verloop van aanmaken, opheffen en overnemen voor zijn eigen cloud, en het patroon geldt voor veel meer aanbieders. Zulke achtergebleven verwijzingen heten in het Engels dangling DNS records.
Welke records kwetsbaar zijn
CNAME-records zijn het bekendste geval, maar niet het enige. De testgids van OWASP noemt ook onder meer A-, MX- en NS-records. Een A-record dat naar een vrijgegeven IP-adres in de cloud wijst, kan bij een andere klant van die cloud uitkomen. Een NS-record dat een deel van je domein delegeert aan een naamserver op een domein dat niet meer geregistreerd is, geeft wie dat domein koopt de controle over dat hele deel. Een MX-record naar een opgeheven maildienst kan betekenen dat iemand anders de mail voor dat subdomein ontvangt.
Wat een aanvaller ermee kan
- Phishing op je eigen domein. Een inlogpagina op een echt subdomein van jouw organisatie is voor medewerkers en klanten niet van echt te onderscheiden. Het gebruikelijke advies om goed naar de domeinnaam te kijken helpt dan niet.
- Cookies buitmaken. Webapplicaties stellen sessiecookies vaak beschikbaar aan alle subdomeinen. Een overgenomen subdomein kan die cookies dan uitlezen bij bezoekers die er via een link terechtkomen.
- Een geldig certificaat. Wie een subdomein beheert, kan er een TLS-certificaat voor aanvragen. Het slotje in de browser zegt in dit geval dus niets over wie er achter de site zit.
- Mail ontvangen die voor het subdomein bedoeld is, als er een MX-record achterblijft.
- Reputatieschade door inhoud op jouw domein die je niet zelf hebt geplaatst.
Microsoft wijst er bovendien op dat gegevens die je eigen applicaties nog naar het oude subdomein sturen, zoals inloggegevens of tokens, dan bij een derde terecht kunnen komen.
Hoe je het opspoort
Begin met een inventaris. Je kunt alleen controleren wat je kent, en juist vergeten subdomeinen zijn het probleem. Exporteer je DNS-zones bij je registrar of DNS-aanbieder en vul die aan met wat openbaar te vinden is. Uitgegeven certificaten worden publiek vastgelegd in Certificate Transparency-logs, en daarin staan vaak subdomeinen die intern al lang uit beeld zijn.
- Zoek alle CNAME-records die naar een externe dienst wijzen. Controleer per record of de dienst nog bestaat en of het account van jouw organisatie is.
- Kijk wat het subdomein laat zien. Een foutpagina van de aanbieder die meldt dat de site, app of opslag niet bestaat, is vaak het teken dat de naam vrij is.
- Controleer gedelegeerde delen van je domein. Bestaan de domeinen van de naamservers nog, en zijn ze van een partij die je kent?
- Herhaal dit op vaste momenten. Een record dat vandaag klopt, kan na de volgende opzegging loshangen.
Hoe je het voorkomt
- DNS hoort bij het opzeggen. Zet het verwijderen van DNS-records op de checklist voor het uitfaseren van elke dienst, en doe dat voordat je de dienst opheft. Dan is er geen moment waarop de naam vrij is en je record er nog naar wijst.
- Een eigenaar per record. Leg bij elk subdomein vast wie het gebruikt en waarvoor. Zonder eigenaar durft niemand een record te verwijderen, en dan blijft het jaren staan.
- Domeinverificatie waar het kan. Sommige aanbieders laten je met een TXT-record bewijzen dat het domein van jou is. Een ander kan het dan niet aan zijn eigen account koppelen.
- Eén route voor wijzigingen. Beperk wie DNS mag aanpassen en laat wijzigingen langs één plek lopen. Zo blijft je inventaris in de pas met de werkelijkheid.
- Doorlopend controleren. Volgens Microsoft lopen organisaties die vaak diensten aanmaken en opheffen het meeste risico. Een jaarlijkse controle is voor hen te weinig.
Waar dit raakt aan NIS2
De Cyberbeveiligingswet, de Nederlandse invoering van NIS2, is op 15 augustus 2026 in werking getreden. Artikel 21 lid 2 van de richtlijn noemt onder meer het beheer van activa (sub i) en de beveiliging bij het onderhouden van netwerk- en informatiesystemen, inclusief de omgang met kwetsbaarheden (sub e). Een actuele lijst van je subdomeinen en een vast opruimproces voor DNS passen daar direct in. Beoordeel je leveranciers, dan geldt hetzelfde voor hun domeinen via de zorgplicht voor de toeleveringsketen (sub d). Meer daarover lees je op de pagina over ketenrisico onder de Cyberbeveiligingswet.
Wat Exposure Watch hier wel en niet doet
De passieve scan van Exposure Watch brengt subdomeinen van je domein in kaart vanuit openbare bronnen, zonder je systemen te raken. Dat geeft je een lijst om naast je eigen DNS-zones te leggen. Een actieve scan doen we alleen op verzoek en alleen op domeinen waarvan je het eigendom hebt aangetoond. Elk rapport krijgt een controlecode, zodat je later kunt laten zien wat er op dat moment is vastgesteld. Het opruimen van records doe je zelf of met je eigen beheerder, want hersteldiensten leveren we niet.
Weten welke subdomeinen er van je bekend zijn?
Start de gratis scan op de voorpagina en zie binnen minuten wat er van je domein online staat.
Bronnen
- Microsoft Learn: Prevent dangling DNS entries and avoid subdomain takeover
- OWASP Web Security Testing Guide: Test for Subdomain Takeover
- RFC Editor: RFC 6962, Certificate Transparency
- EUR-Lex: Richtlijn (EU) 2022/2555 (NIS2)