Dangling DNS-records: wat ze zijn en hoe je het overnemen van subdomeinen kunt voorkomen

Een ‘dangling’ DNS-record is een DNS-vermelding die nog steeds verwijst naar een bron die niet meer bestaat, zoals een verwijderde clouddienst, een buiten gebruik gestelde server of een inactief platform van een derde partij. Het record blijft worden omgezet, terwijl de bestemming erachter niet meer bestaat, en juist die kloof is waar aanvallers op uit zijn.

Voor IT- en beveiligingsteams is het zelden een kwestie van het opsporen van één enkel foutief record. Het gaat erom continu inzicht te behouden in domeinen, subdomeinen en authenticatierecords, terwijl de onderliggende infrastructuur voortdurend verandert. Bij elke migratie, elke leverancierswissel en elke dienst die buiten gebruik wordt gesteld, blijven er kandidaten achter.

Wat zijn bungelende DNS-records?

Een ‘dangling’ DNS-record is een DNS-vermelding die verwijst naar een bron die niet meer bestaat of niet meer toegankelijk is. Cybercriminelen op het internet zijn voortdurend op zoek naar dergelijke DNS-vermeldingen, omdat deze kwetsbaar zijn voor informatielekken. Sommige van deze vermeldingen kunnen gevoelige informatie over een domein bevatten, waardoor ze een ware goudmijn aan gegevens vormen waar kwaadwillenden munt uit kunnen slaan.

Veelvoorkomende situaties die tot ‘dangling DNS’ leiden

Foutieve DNS-configuraties. Het Domain Name System wordt los van de internetbron waarmee we willen communiceren geconfigureerd. DNS-records die aan het DNS worden toegevoegd, verwijzen naar deze bronnen, waardoor we er toegang toe krijgen. In bepaalde gevallen kan een eerder geconfigureerde bron door de host worden gedeconfigureerd. Een DNS-record werd bijvoorbeeld door een domeineigenaar geconfigureerd om naar het IP-adres van een server te verwijzen. Deze server is nu niet meer in gebruik. Het DNS-record verwijst nu naar een bron die niet meer bestaat en kan daarom worden aangeduid als een „dangling DNS“-vermelding.

Verlopen of verwijderde cloudbronnen. Als een clouddienst die door een domeineigenaar wordt gebruikt, verloopt of wordt verwijderd, wordt elk DNS-record dat naar die dienst verwijst een losstaand DNS-record. Dit DNS-record blijft actief en elke aanvaller kan de resource gebruiken om schadelijke inhoud te verspreiden.

Verouderde IP-adressen. Een bedrijf kan diensten naar een nieuwe provider migreren, terwijl de oude IP-adressen worden afgeschreven. Als het team vergeet de oude DNS-records bij te werken of te verwijderen, worden die records kwetsbaar voor subdomeinovername en kunnen ze gemakkelijk worden misbruikt.

Buitengebruikstelling of stopzetting van een dienst. Een e-mailserver, hostingaccount of externe dienstverlener wordt stopgezet of buiten gebruik gesteld, maar de DNS-records zoals MX-, A- en CNAME-records zijn nog steeds actief en geconfigureerd. Aanvallers kunnen misbruik maken van deze actieve, losstaande DNS-records om zich voor te doen als de stopgezette dienst.

Welke DNS-records blijven ‘hangen’ en welke risico’s brengt elk daarvan met zich mee?

De kwetsbaarheid zit in de kloof tussen de DNS-laag en de bronlaag. Een record kan syntactisch volkomen correct zijn en toch gevaarlijk zijn wanneer de bestemming erachter niet langer in bezit is of niet langer beschikbaar is. In de onderstaande tabel wordt die kloof per recordtype weergegeven.

Veelgemaakte fout

Een succesvolle DNS-opzoeking wordt beschouwd als bewijs dat het record in orde is. Een ‘dangling record’ wordt normaal omgezet, omdat de vermelding zelf geldig is. Het gaat erom of uw organisatie nog steeds eigenaar is van de bestemming en daar zeggenschap over heeft. Het controleren van de omzetting zonder de eigendom te controleren, is de reden waarom deze records audits doorstaan.

Waar losse records het vaakst voorkomen

Sommige delen van een landgoed leveren deze documenten veel betrouwbaarder op dan andere. Als je weet welke dat zijn, kun je de controle op basis van waarschijnlijkheid uitvoeren in plaats van elke keer het hele gebied te doorzoeken.

• Cloudopslagbuckets en hosts voor statische websites: bucketnamen zijn wereldwijd uniek en kunnen vrij opnieuw worden geregistreerd, dus een verwijderde bucket met een actieve CNAME is een van de gemakkelijkste doelen om te claimen
• CDN- en SaaS-vanity-subdomeinen: help.example.com, status.example.com en careers.example.com verwijzen doorgaans naar platforms van derden die de hostnaam vrijgeven zodra een abonnement afloopt
• Marketing- en landingspagina-tools: campagnesubdomeinen worden snel door teams buiten de IT-afdeling in gebruik genomen en zijn zelden onderworpen aan een buitengebruikstellingsproces
• Staging- en testomgevingen: dev-, uat- en staging-records blijven bestaan nadat de projecten waarmee ze zijn aangemaakt, zijn beëindigd, en niemand merkt dat op omdat er geen echt verkeer van afhankelijk is
• Verworven of onderliggende domeinen: overgenomen zones bevatten records waarvan de oorspronkelijke eigenaren zijn vertrokken, en er wordt zelden documentatie bij geleverd
• Niet meer actieve e-mail- en ondersteuningsaanbieders: MX-records, DKIM-CNAME's en SPF-inclusies voor een platform waarvoor u vorig jaar bent gestopt met betalen

De rode draad die deze gevallen met elkaar verbindt, is eigendomsverschuiving. Elk record is correct aangemaakt door iemand die daartoe bevoegd was, maar is vervolgens langer blijven bestaan dan de relatie die de aanmaak ervan rechtvaardigde. Daarom is het opschonen van deze records de taak van degene die een dienst buiten gebruik stelt, en niet van degene die het DNS beheert.

DMARC TXT-records

DMARC-records worden gepubliceerd als TXT-records en bevatten vaak rapportagedestinaties via de tags `rua` en `ruf`. Als die bestemmingen verwijzen naar inactieve of onbewaakte mailboxen, verliezen teams het inzicht in authenticatiefouten en spoofingpogingen zonder dat er fouten aan het licht komen. Bekijk hoe u een DMARC-record publiceert telkens wanneer rapportageadressen of eigenaren veranderen.

SPF TXT-records

SPF-records bevatten een lijst van geautoriseerde verzendservices op basis van IP-adressen en omvatten verificatiemechanismen. Als een SPF-record verwijst naar een verouderde dienst van een derde partij of een verlaten domein, wordt de authenticatie onbetrouwbaar en krijgt een aanvaller die dat verlaten leveranciersdomein registreert, de verzendbevoegdheid in handen. Naarmate het aantal SaaS-verzenders toeneemt, overschrijden de records ook de limiet van 10 DNS-lookups, dus SPF-afvlakking zorgt ervoor dat ze binnen de limiet blijven. Lees meer over SPF.

TLS-RPT-records

TLS-RPT-records geven aan waar SMTP TLS -rapporten naartoe moeten worden gestuurd. Als de rapportagebestemming inactief is, verkeerd is geconfigureerd of niet langer wordt bewaakt, lopen teams fouten in de transportbeveiliging mis die van invloed zijn op de bezorging van versleutelde e-mail. Lees meer over TLS-RPT en MTA-STS.

DKIM CNAME-records

DKIM-records kunnen worden gepubliceerd als CNAME-records die verwijzen naar de DKIM-host van een verzendprovider. Als het account bij de provider wordt verwijderd of het doeldomein inactief wordt, vallen de DKIM-ondertekening en -verificatie onopgemerkt weg. Het subdomein mail.domain.com is bijvoorbeeld een alias voor het CNAME-record info.domain.com. Wanneer een server dus mail.domain.com opzoekt, wordt deze doorgestuurd naar info.domain.com. Uw DKIM authenticatiesysteem wordt vaak aan de DNS toegevoegd als een CNAME-record.

Opmerking: MX-, NS-, A-, AAAA-, CNAME- en TXT-records kunnen allemaal ‘dangling’ worden wanneer ze verwijzen naar inactieve infrastructuur, stopgezette diensten of verlaten externe providers. Dit artikel richt zich op de records voor e-mailverificatie, omdat fouten op dat gebied het langst onopgemerkt blijven.

Hoe ‘dangling DNS’ leidt tot de overname van subdomeinen

Verborgen DNS-kwetsbaarheden zoals dangling DNS kunnen leiden tot misbruik van domeinen en cyberdreigingen. In gereguleerde sectoren zoals de financiële sector, de gezondheidszorg, het onderwijs, de detailhandel en de publieke sector bemoeilijken onopgeloste DNS- en authenticatieproblemen bovendien beveiligingsbeoordelingen en de voorbereiding op audits.

De aanval zelf verloopt volgens een voorspelbaar patroon, wat nuttig is omdat het precies laat zien op welk punt een beveiligingsmaatregel de keten doorbreekt.

1. Subdomein-enumeratie. De aanvaller scant uw domein op subdomeinen met behulp van openbare DNS-tools, certificaattransparantielogboeken of brute-force-opsporing.
2. Identificatie van een ‘dangling record’. De aanvaller vindt een CNAME-, A- of MX-record dat verwijst naar een externe dienst die een reactie van het type 'dergelijk account bestaat niet' of 'niet opgeëist' retourneert.
3. Het claimen van bronnen. De aanvaller registreert datzelfde account, diezelfde bucket of diezelfde hostnaam op het externe platform, of het nu gaat om een cloudopslagbucket, een CDN-eindpunt of een SaaS-subdomein.
4. Verkeerskaping. Omdat uw DNS-record nog steeds naar dat subdomein verwijst, wordt elk verzoek aan dat subdomein nu gerouteerd via infrastructuur die de aanvaller beheert.
5. Misbruik van het vertrouwen dat is opgebouwd. Het vertrouwde subdomein gebruikt vervolgens phishingpagina's, host malware, steelt sessiecookies, verstuurt vervalste e-mails of verzamelt inloggegevens, allemaal onder de domeinnaam van uw organisatie.

Wat is een aanval waarbij een subdomein wordt overgenomen?

Wanneer een aanvaller een ‘dangling’ DNS-vermelding ontdekt die verwijst naar een niet-geconfigureerde bron, kan de aanvaller de verlaten bron overnemen en het verkeer omleiden via infrastructuur die hij beheert. De aanvaller neemt het (sub)domein over waarnaar het loshangende DNS-record verwijst, waardoor hij al het verkeer omleidt naar een door de aanvaller gecontroleerd domein, met volledige toegang tot de inhoud en bronnen van dat domein.

De schade reikt verder dan alleen een gemanipuleerde pagina. Tot de acties van aanvallers behoren onder meer het stelen van inloggegevens via valse inlogpagina’s, malware die op een vertrouwd subdomein wordt gehost, het zich voordoen als een merk via e-mail en het web, het onderscheppen van sessiecookies, misbruik van SEO door gebruik te maken van de autoriteit van uw domein, misbruik van e-mailverzending door verkeerd geconfigureerde MX- of SPF-records, en reputatieschade die later aan het licht komt bij nalevingscontroles.

Een 'dangling' hostnaam versus een 'dangling' DNS-record

De twee termen hangen nauw met elkaar samen en worden door elkaar gebruikt, hoewel ze verschillende zaken beschrijven. Een ‘dangling’ DNS-record is het record zelf, een CNAME- of A-record dat nog steeds in je zonebestand staat, maar verwijst naar een verwijderde of niet-toegewezen bron. Een ‘dangling’ hostnaam is het subdomein dat verwijst naar een bestemming waarover niemand binnen je organisatie nog zeggenschap heeft.

In de praktijk wordt de hostnaam door het record aangemaakt. Als dev.example.com een CNAME-record heeft dat verwijst naar een hostingaccount waarvan de toegang is ingetrokken, dan is dev.example.com een ‘dangling’ hostnaam en is het CNAME-record de ‘dangling’ record die erachter zit. Dit onderscheid is van belang omdat scanners het ene of het andere signaleren, terwijl beide dezelfde oplossing vereisen: controleer het eigendom van het doel en verwijder vervolgens het record of wijs het opnieuw toe.

Hoe je ontbrekende DNS-records kunt opsporen

Door DNS-records die naar nog niet in gebruik genomen resources verwijzen in een vroeg stadium op te sporen, kunt u uw merk helpen beschermen. U kunt dit op twee manieren aanpakken: handmatig en geautomatiseerd.

Handmatige detectie

Hoewel een handmatige controle veel tijd kost, kan deze helpen om verouderde DNS-records op te sporen, met name na cloudmigraties, wisselingen van leverancier, het buiten gebruik stellen van diensten of het aanmelden van nieuwe afzenders.

• Controleer uw DNS-vermeldingen: Vergelijk alle DNS-records in uw DNS-beheersysteem met de actieve bronnen in uw omgeving. Zoek naar vermeldingen die verwijzen naar niet-bestaande diensten of IP-adressen.
• Controleer de DNS-configuraties: Gebruik tools zoals nslookup of dig om elk record op te vragen en te controleren of de bijbehorende resource is ingesteld en actief is. Een DNS-antwoord op zich is geen bewijs van veiligheid, dus controleer of het doel in het bezit is van en actief wordt beheerd door uw organisatie.
• Controleer op achtergebleven services: Onderzoek services zoals hosting door derden, cloudplatforms of CDN-providers die mogelijk zijn beëindigd zonder dat de bijbehorende DNS-vermeldingen zijn verwijderd.

Voor validatie per record kun je elk item ook door een DNS-recordchecker om te controleren waarnaar het momenteel verwijst, voordat u besluit of u het wilt behouden.

Waarom handmatige detectie op grote schaal niet meer werkt

Hoewel handmatige methoden grondig zijn, zijn ze gevoelig voor menselijke fouten en kunnen ze onbeheersbaar worden bij domeinen met omvangrijke of complexe DNS-configuraties. Er zijn verschillende factoren die ervoor zorgen dat deze methoden al onbetrouwbaar worden lang voordat een zone omvangrijk wordt.

• Gedecentraliseerd beheer van het DNS-systeem over teams en afdelingen heen
• Vergeten test- en stagingomgevingen waarin nog steeds actieve DNS-records staan
• Schaduw-IT en niet-geregistreerde SaaS-integraties van derden
• Verlopen cloudresources die nooit aan een formeel buitengebruikstellingsproces zijn gekoppeld
• Meerdere DNS-zones die via overnames of dochterdomeinen zijn overgenomen
• Beperkte documentatie voor verouderde infrastructuur waarvan momenteel niemand de verantwoordelijkheid draagt

Geautomatiseerde detectie

Geautomatiseerde monitoring wordt noodzakelijk zodra domeinen, subdomeinen, afzenders en clouddiensten sneller veranderen dan de auditcyclus. In plaats van periodieke controles brengt een gecentraliseerd platform continu inactieve records, defecte authenticatieconfiguraties en verdachte wijzigingen in de gehele portefeuille aan het licht.

Het praktische voordeel zit hem eerder in de timing dan in de grondigheid. Bij een kwartaalcontrole wordt uiteindelijk hetzelfde probleem ontdekt, maar pas na een kwartaal waarin het risico heeft kunnen bestaan. Door continue monitoring wordt die periode tussen het moment waarop de dienst buiten gebruik wordt gesteld en de volgende controle – waarin het overnamerisico daadwerkelijk schuilt – gesloten.

Hoe los je ongeldige DNS-records op?

Zodra een ‘dangling record’ is geïdentificeerd, is de volgorde van de handelingen van belang. Als je het record verwijdert voordat je de bron vrijmaakt, kan er een veiligheidslek ontstaan, en als je de TTL-stap overslaat, duurt het uren in plaats van minuten voordat je oplossing is doorgevoerd.

1. Bepaal welk record het betreft en wat de bestemming ervan is. Gebruik DNS-tools of een monitoringplatform om de specifieke vermelding te vinden en te achterhalen waarnaar deze momenteel verwijst.
2. Controleer of u de eigenaar bent van het doel. Controleer of uw organisatie nog steeds zeggenschap heeft over de bestemming door dit na te vragen bij de provider of in het accountregister.
3. Verlaag eerst de TTL. Zet deze waarde op een waarde tussen 60 en 300 seconden voordat je wijzigingen aanbrengt, zodat updates snel worden doorgevoerd zodra je actie onderneemt.
4. Claim de bron terug als deze kan worden geclaimd. Als het doel een niet-geclaimde cloudbucket of een CDN-eindpunt is, claim deze dan voordat u DNS aanpast om de overnamemogelijkheid te sluiten.
5. Verwijder het record of wijzig de verwijzing. Verwijder het als de dienst niet meer wordt aangeboden. Als het actief moet blijven, wijs het dan toe aan een resource die u momenteel bezit en hebt ingericht.
6. Controleer of de wijziging is doorgevoerd. Gebruik dig of nslookup om te controleren of het record correct wordt omgezet en of de oude bestemming niet meer reageert.
7. Leg de wijziging vast. Leg vast wat er is gewijzigd, waarom, wanneer en door wie, werk vervolgens de DNS-inventaris bij en wijs een vaste verantwoordelijke aan.

Hoe je kunt voorkomen dat subdomeinen worden overgenomen door ‘dangling’ DNS-records

Preventie combineert DNS-hygiëne met continue monitoring. De onderstaande maatregelen zijn het belangrijkst voor IT-teams, beveiligingsteams en MSP’s die meerdere domeinen beheren.

• Verwijder ongebruikte DNS-records onmiddellijk: verwijder CNAME-, A-, AAAA-, MX- en TXT-records wanneer diensten worden stopgezet, in plaats van ze te laten staan voor het geval dat
• Controleer of doelen van derden geldig zijn voordat u ernaar verwijst: controleer eerst of de cloud-, CDN-, e-mail- en hostingbronnen actief zijn en eigendom zijn van uw organisatie
• Controleer de gegevens voor e-mailverificatie: controleer DMARC, SPF, DKIM, MTA-STS, TLS-RPT en BIMI regelmatig op inactieve of onjuiste verwijzingen
• Eigendom van documenten: houd een inventaris bij van domeinen, subdomeinen, afzenders en service-eigenaren, waarbij bij elk record een eigenaar met naam wordt vermeld
• Integreer het opschonen van DNS-gegevens in het buitengebruikstellingsproces: maak het verwijderen van records een verplichte stap wanneer een clouddienst, SaaS-platform of hostingaccount buiten gebruik wordt gesteld
• Stel automatische waarschuwingen in: let op verweesde services, DNS-afwijkingen en nieuwe subdomeinen die in uw zone verschijnen
• Voer periodieke hygiëne-audits uit: maandelijks of driemaandelijks, afhankelijk van de complexiteit, en onmiddellijk na elke migratie, verandering van provider of domeinovername

Wat te doen met oude of ongebruikte subdomeinen

Wanneer een subdomein niet langer nodig is, leidt dat meestal tot een van de volgende vijf uitkomsten.

• Verwijderen het record wanneer het subdomein geen zakelijke rechtvaardiging meer heeft
• Terugvorderen de verlaten externe bron terug wanneer het subdomein actief moet blijven en het account nog steeds kan worden opgeëist
• Parkeer veilig door het te verwijzen naar een gecontroleerde interne bron, nooit naar een extern platform, wanneer het moet worden omgezet maar niets hoeft te serveren
• Omleiden alleen als daar een zakelijke reden voor is, en controleer of de bestemming eigendom is van de gebruiker en actief is
• Leg Leg elke beslissing vast en wijs verantwoordelijkheden toe voordat u iets buiten gebruik stelt

Hoe PowerDMARC helpt

PowerDMARC centraliseert het toezicht op domein- en e-mailverificatie, zodat teams problemen met DMARC, SPF, DKIM, MTA-STS, TLS-RPT en BIMI kunnen opsporen zonder elk DNS-record handmatig te hoeven controleren. Het doel is niet om één losstaand record te vinden, maar om continu inzicht te hebben in elk domein, subdomein en verificatierecord dat van invloed is op uw beveiligingsstatus.

• Gecentraliseerd dashboard: domein, subdomein en authenticatiestatus op één plek te bekijken
• Snelle detectie van problemen: configuratiefouten worden opgespoord voordat ze de beveiliging of de afleverbaarheid beïnvloeden
• Geautomatiseerd SPF-beheer: minder zoekfouten en schonere verzendbronnen naarmate SaaS-platforms veranderen
• Voorbereiding op de audit: ondersteuning bij de voorbereiding op audits voor teams in de financiële sector, de gezondheidszorg, het onderwijs, de detailhandel en de publieke sector
• Deskundige ondersteuning: wereldwijde ondersteuning om risicovolle gegevens snel te onderzoeken, te valideren en te corrigeren

Voor dienstverleners maken gecentraliseerde domeingroepering en op rollen gebaseerde toegang het mogelijk om meerdere klantomgevingen tegelijk te monitoren. De MSP- en MSSP-programma is rond die workflow opgebouwd.

Als je snel wilt weten hoe je huidige houding eruitziet, controleer dan je domein met de gratis analysetool. Voer uw domein in, klik op 'Nu controleren' en u kunt uw DNS-recordconfiguraties, gedetecteerde fouten en praktische tips om deze op te lossen bekijken.

Veelgestelde Vragen

Hierin worden de operationele vragen behandeld die aan de orde komen zodra het concept duidelijk is.

Hoe los je het probleem van ‘dangling’ DNS-records op?

Zoek het verouderde record op, controleer of uw organisatie nog steeds eigenaar is van het doelobject en verlaag vervolgens de TTL. Maak de resource eerst vrij als dit mogelijk is, verwijder het record of wijzig de verwijzing, controleer de verspreiding met `dig` en documenteer de wijziging.

Wat is een 'dangling hostname'?

Een subdomein dat verwijst naar een bestemming die niet langer onder beheer staat van de domeineigenaar. Dit wordt veroorzaakt door een ‘dangling’ DNS-record. Als dev.example.com verwijst naar een cloudaccount waarvan de toegang is ingetrokken, is er sprake van een ‘dangling’ hostnaam.

Kunnen ongeldige DNS-records de e-mailbeveiliging beïnvloeden?

Ja. DMARC-, SPF-, DKIM-, MTA-STS- en TLS-RPT-records worden allemaal ongeldig wanneer ze verwijzen naar inactieve domeinen, verouderde afzenders of onbewaakte rapportagemailboxen. Dit leidt tot mislukte authenticaties en onopgemerkte hiaten in de zichtbaarheid.

Hoe vaak moeten organisaties hun DNS-records controleren?

Na elke buitengebruikstelling van een dienst, migratie van een provider, domeinaankoop of wijziging van de afzender. Voeg, afhankelijk van de complexiteit, terugkerende maandelijkse of driemaandelijkse controles toe, evenals continue monitoring om afwijkingen tussen deze controles op te sporen.

Betekent een 'dangling record' altijd dat een subdomein kan worden overgenomen?

Nee. Bij een overname moet de doelbron door iemand anders kunnen worden opgeëist, wat vaak het geval is bij cloudbuckets, CDN-eindpunten en SaaS-subdomeinen. Een record dat naar een niet-bestaand IP-adres verwijst, leidt nog steeds tot storingen en het risico op onderschepping.

Wie zou intern verantwoordelijk moeten zijn voor het opschonen van DNS-records?

De verantwoordelijkheid voor het buiten gebruik stellen van diensten ligt bij de eigenaar ervan, en niet alleen bij de DNS-beheerder. Records raken verouderd op het moment dat een dienst wordt stopgezet, dus het opschonen daarvan hoort thuis in de checklist voor het beëindigen van diensten en niet in een afzonderlijke DNS-controle.

• Over
• Laatste berichten

Yunes Tarada

Expert op het gebied van domein- en e-mailbeveiliging bij PowerDMARC

Yunes is teamleider Operations bij PowerDMARC en heeft expertise in e-mailauthenticatie en -beveiliging. Hij is een door Microsoft gecertificeerde Azure Administrator Associate en beschikt over certificeringen zoals CompTIA A+ en vele andere.

Laatste berichten van Yunes Tarada (Bekijk alle berichten)

• Handleiding voor het instellen van Happyfox DKIM, DMARC en SPF - 13 augustus 2026
• Wat is DMARC-quarantaine? Uitleg over het p=quarantine-beleid - 12 augustus 2026
• Handleiding voor het instellen van Twikey SPF, DKIM en DMARC - 11 augustus 2026