Dangling DNS-records en subdomain takeover: zo vind en verwijder je ze

Een dangling DNS-record is een A-, AAAA-, CNAME-, MX- of NS-record dat nog steeds resolvet, maar verwijst naar een cloudresource, IP-adres of nameserver die niet meer bestaat: een verwijderde storage bucket, een vrijgegeven server-IP, een opgezegd SaaS-account. Als een aanvaller diezelfde resource onder zijn eigen account kan claimen, kan hij zijn eigen content op jouw subdomein serveren. Dit heet een subdomain takeover, en het is een van de stillere manieren waarop een vertrouwd domein ongemerkt de phishingpagina of malware van iemand anders gaat hosten. De oplossing: verwijder een DNS-record of laat het ergens anders naar verwijzen zodra de resource erachter wordt uitgefaseerd, en controleer de rest van de zone regelmatig op records waarvan niemand meer weet wie ze heeft aangemaakt. Nu Cybersecurity Awareness Month reviews van het aanvalsoppervlak weer op ieders checklist zet, is een zone-audit een van de taken met de hoogste waarde en de minste moeite die je deze maand kunt uitvoeren.

Wat is een dangling DNS-record?

De term is in geen enkele RFC gedefinieerd; het is operationeel jargon voor een record waarvan het doel ongemerkt is verdwenen. De DNS-entry zelf is volkomen geldig en beantwoordt nog steeds queries; wat ontbreekt, is het ding waar hij vroeger naar verwees. Vier patronen veroorzaken vrijwel alle gevallen:

• Een CNAME koppelt een hostnaam nog steeds als alias aan een endpoint van een clouddienst (een S3-bucket, een CDN-distributie, een PaaS-app) die is verwijderd.
• Een A/AAAA-record verwijst nog steeds naar een IP-adres dat is teruggegeven aan de pool van een cloudprovider.
• Een NS-delegatie laat de zone van een subdomein nog steeds verwijzen naar nameservers van een provideraccount dat is opgeheven.
• Een MX-record stuurt mail nog steeds naar een mailplatform dat het team niet meer gebruikt.

Geen van deze gevallen is een protocolfout. De DNS weet niet dat het ding aan de andere kant verdwenen is, en het maakt hem ook niet uit: hij blijft gewoon antwoorden. Juist daardoor blijven dangling records onzichtbaar totdat iemand ze controleert.

Hoe een subdomain takeover precies werkt

Veel cloud- en SaaS-platforms laten een klant een resource op naam claimen (een bucketnaam, een app-slug, een distributie-alias), en die naam komt voor iedereen beschikbaar zodra de oorspronkelijke eigenaar hem verwijdert. Als je DNS nog een CNAME heeft die naar old-bucket.s3-website-us-east-1.amazonaws.com verwijst, en niemand in je bedrijf die bucket nog bezit, kan een aanvaller een nieuwe bucket met precies dezelfde naam aanmaken, zijn eigen pagina uploaden, en dan serveert jouw subdomein die pagina. Inclusief een geldig TLS-certificaat als hij er een aanvraagt via een provider die het domeineigendom niet aan de hand van jouw records controleert. Dit is zo goed gedocumenteerd dat er een eigen OWASP-testcase voor bestaat (Testing for Subdomain Takeover) en een door de community bijgehouden catalogus van welke providers kwetsbaar zijn en welke beschermingsmaatregelen hebben ingevoerd: het project "Can I take over XYZ?" op GitHub. Providers die het domeineigendom verifiëren voordat ze een custom domain serveren (GitHub Pages, Azure App Service met zijn verplichte asuid.<subdomain> TXT-record) zijn op deze manier veel moeilijker te misbruiken, maar genoeg oudere of kleinere diensten doen dat nog steeds niet.

Welke diensten de gebruikelijke boosdoeners zijn

Deze lijst is niet volledig: Fastly, Shopify, Zendesk, Surge.sh en verschillende andere platforms zijn op diverse momenten in dezelfde catalogus verschenen. Het patroon is altijd hetzelfde: een vriendelijke foutpagina die bevestigt dat de naam vrij is, achter een DNS-record waar jij nog steeds over beschikt.

Je DNS-zone controleren op dangling records

Begin met het exporteren van elk record in de zone en resolve voor elke hostnaam de volledige keten. Volg bij CNAMEs het doel en kijk wat er antwoordt:

$ dig CNAME status.example.com +short
old-bucket.s3-website-us-east-1.amazonaws.com.

$ curl -s https://status.example.com
<Error><Code>NoSuchBucket</Code><Message>The specified bucket does not exist</Message></Error>

Een kale NXDOMAIN op het doel of een providerspecifieke "niet geclaimd"-foutpagina zoals hierboven betekent in beide gevallen dat de resource verdwenen is en dat de naam mogelijk vrij te claimen is. Met onze gratis DNS lookup tool haal je snel de A-, CNAME-, MX- en NS-records van een hostnaam op zonder een terminal te openen, wat handig is als je een lange lijst subdomeinen handmatig controleert.

Gaat het om meer dan een handvol subdomeinen, automatiseer het dan met een script: inventariseer subdomeinen (uit je eigen inventaris, certificate transparency logs of een woordenlijst met subdomeinen), resolve ze allemaal en markeer elke CNAME waarvan het doel niet resolvet of een bekende "niet geclaimd"-fingerprint teruggeeft. Opensourcetools zoals Subjack, tko-subs, dnsReaper en de subdomain-takeover-templates van Nuclei automatiseren precies deze workflow op basis van openbare fingerprintdatabases.

TipVertrouw niet op je geheugen voor wat er "nog in gebruik" is. Vergelijk de zone-export met de cloudresources die daadwerkelijk zijn geprovisioned: alles in DNS zonder bijbehorende actieve resource komt in aanmerking voor verwijdering, hoe oud of onschuldig het er ook uitziet.

Een dangling record veilig verwijderen

Zodra je hebt bevestigd dat een record dangling is, verwijder je het. Probeer het niet te "repareren" door een ander recordtype onder dezelfde naam toe te voegen. RFC 1034 stelt expliciet dat een naam met een CNAME geen andere recordtypes mag hebben, dus je kunt er geen A-record bovenop zetten zonder eerst de CNAME te verwijderen. Ben je er nog niet aan toe om het record helemaal te verwijderen, laat het dan verwijzen naar een resource die jij beheert, zoals een parkeerpagina of een server van jezelf, in plaats van het naar niets te laten wijzen.

WarningControleer voordat je het record verwijdert of het ook dient als bewijs van domeineigendom (een TXT- of CNAME-verificatierecord voor het platform waar je vertrekt). Als je een verificatierecord te vroeg verwijdert, kan dat een lopende migratie juist breken in plaats van afronden.

NS-delegatie-takeover: een ander verhaal

Een dangling NS-delegatie is een apart en ernstiger geval: het ontstaat wanneer de zone van een subdomein is gedelegeerd aan nameservers van een externe account (een DNS-host, een CDN, een ontwikkeltool) die inmiddels is opgeheven, en de nameservernamen zelf beschikbaar komen zodat iemand anders ze kan registreren. Wie die nameservernamen beheert, beheert vervolgens de DNS van dat hele subdomein, niet slechts één record. Controleer NS-delegaties op dezelfde manier: resolve elke nameserver-hostnaam en bevestig dat die nog steeds bij een account hoort dat jij beheert. Als je alle zones vanuit één plek beheert, is dit veel makkelijker overzichtelijk te houden; bekijk hoe gecentraliseerd DNS-beheer delegaties naast gewone records afhandelt.

Maak verwijderen onderdeel van uitfaseren, niet iets voor achteraf

De echte oplossing is geen eenmalige audit, maar een proces. Verwijder het DNS-record of laat het ergens anders naar verwijzen op hetzelfde moment dat je de resource erachter uitfaseert, als verplichte stap in de checklist voor het afbouwen, niet als vervolgticket dat misschien nooit wordt aangemaakt. Combineer dat met een actuele infrastructuurinventaris, zodat elk record een bekende, actieve eigenaar heeft, en overweeg drift detection, zodat een record dat dangling wordt automatisch wordt gemarkeerd in plaats van te wachten op de volgende handmatige audit.

Voer deze audit volgens een vast schema uit, niet slechts één keer. Er ontstaan nieuwe dangling records telkens wanneer een project wordt beëindigd, een proefaccount verloopt of een team van een platform migreert. Het is een doorlopende onderhoudstaak, geen project met een einddatum.

Begin met een gratis scan van je eigen zone met de DNS lookup tool en maak verwijderingen vervolgens onderdeel van elke checklist voor uitfasering.