Ein Dangling DNS-Eintrag ist ein A-, AAAA-, CNAME-, MX- oder NS-Eintrag, der zwar noch auflöst, aber auf eine Cloud-Ressource, IP-Adresse oder einen Nameserver zeigt, den es nicht mehr gibt: einen gelöschten Storage-Bucket, eine freigegebene Server-IP, ein gekündigtes SaaS-Konto. Kann ein Angreifer genau diese Ressource unter seinem eigenen Konto beanspruchen, liefert er seine eigenen Inhalte auf deiner Subdomain aus. Das nennt man Subdomain Takeover, und es ist einer der unauffälligeren Wege, auf denen eine vertrauenswürdige Domain plötzlich die Phishing-Seite oder Malware eines Fremden hostet. Die Lösung: Lösche einen DNS-Eintrag oder richte ihn neu aus, sobald die Ressource dahinter stillgelegt wird, und prüfe den Rest der Zone regelmäßig auf Einträge, an deren Anlage sich niemand mehr erinnert. Da der Cybersecurity Awareness Month Überprüfungen der Angriffsfläche wieder auf alle Checklisten bringt, ist ein Zonen-Audit eine der wertvollsten und zugleich am wenigsten aufwendigen Aufgaben, die du diesen Monat erledigen kannst.
Was ist ein Dangling DNS-Eintrag?
Der Begriff ist in keinem RFC definiert – er ist eine Kurzform aus dem Betriebsalltag für einen Eintrag, dessen Ziel stillschweigend verschwunden ist. Der DNS-Eintrag selbst ist völlig gültig und beantwortet weiterhin Anfragen; was fehlt, ist das, worauf er früher gezeigt hat. Vier Muster sind für fast alle Fälle verantwortlich:
- Ein CNAME verweist einen Hostnamen weiterhin auf einen Endpunkt eines Cloud-Dienstes (einen S3-Bucket, eine CDN-Distribution, eine PaaS-App), der gelöscht wurde.
- Ein A/AAAA-Eintrag zeigt weiterhin auf eine IP-Adresse, die an den Pool eines Cloud-Anbieters zurückgegeben wurde.
- Eine NS-Delegation verweist die Zone einer Subdomain weiterhin auf Nameserver, die zu einem gekündigten Anbieterkonto gehören.
- Ein MX-Eintrag leitet E-Mails weiterhin an eine Mail-Plattform, die das Team nicht mehr nutzt.
Keiner dieser Fälle ist ein Protokollfehler. Das DNS weiß nicht und kümmert sich nicht darum, dass das Gegenüber verschwunden ist – es antwortet einfach weiter. Genau das macht Dangling-Einträge unsichtbar, bis jemand nachsieht.
Wie ein Subdomain Takeover tatsächlich funktioniert
Viele Cloud- und SaaS-Plattformen lassen Kunden eine Ressource über ihren Namen beanspruchen – einen Bucket-Namen, einen App-Slug, einen Distribution-Alias –, und dieser Name wird für jeden verfügbar, sobald der ursprüngliche Besitzer ihn löscht. Hat dein DNS noch einen CNAME, der auf old-bucket.s3-website-us-east-1.amazonaws.com zeigt, und gehört dieser Bucket niemandem in deinem Unternehmen mehr, kann ein Angreifer einen neuen Bucket mit exakt demselben Namen anlegen, seine eigene Seite hochladen, und deine Subdomain liefert sie aus – inklusive gültigem TLS-Zertifikat, falls er eines bei einem Anbieter anfordert, der die Domain-Inhaberschaft nicht mit deinen Einträgen abgleicht.
asuid.<subdomain>-TXT-Anforderung), sind auf diesem Weg deutlich schwerer auszunutzen, viele ältere oder kleinere Dienste aber nach wie vor nicht.
Welche Dienste typischerweise betroffen sind
| Dienst | Dangling-Eintrag zeigt auf | Typisches „nicht beansprucht“-Signal |
|---|---|---|
| AWS S3 static site | CNAME auf bucket.s3-website-region.amazonaws.com |
NoSuchBucket XML-Fehler |
| AWS CloudFront | CNAME auf *.cloudfront.net |
"The request could not be satisfied" |
| GitHub Pages | CNAME auf username.github.io |
"There isn't a GitHub Pages site here" |
| Heroku | CNAME auf *.herokuapp.com |
"No such app" |
| Azure App Service | CNAME auf *.azurewebsites.net |
"404 Web Site not found" |
Diese Liste ist nicht vollständig – Fastly, Shopify, Zendesk, Surge.sh und mehrere andere Plattformen tauchten zu verschiedenen Zeitpunkten im selben Katalog auf. Das Muster ist immer gleich: eine freundliche Fehlerseite, die bestätigt, dass der Name frei ist, hinter einem DNS-Eintrag, den du noch kontrollierst.
So prüfst du deine DNS-Zone auf Dangling-Einträge
Exportiere zuerst alle Einträge der Zone und löse für jeden Hostnamen die Kette auf. Bei CNAMEs folgst du dem Ziel und schaust, was antwortet:
$ 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>
Ein schlichtes NXDOMAIN für das Ziel oder eine anbieterspezifische „nicht beansprucht“-Fehlerseite wie oben bedeuten beide, dass die Ressource weg ist und der Name möglicherweise frei beansprucht werden kann. Unser kostenloses DNS-Lookup-Tool ist ein schneller Weg, A-, CNAME-, MX- und NS-Einträge für einen Hostnamen abzurufen, ohne ein Terminal zu öffnen – praktisch, wenn du eine lange Liste von Subdomains von Hand prüfst.
Ab mehr als einer Handvoll Subdomains solltest du das skripten: Ermittle die Subdomains (aus deinem eigenen Inventar, aus Certificate-Transparency-Logs oder per Subdomain-Wortliste), löse jede auf und markiere jeden CNAME, dessen Ziel nicht auflöst oder einen bekannten „nicht beansprucht“-Fingerprint zurückgibt. Open-Source-Tools wie Subjack, tko-subs, dnsReaper und die Subdomain-Takeover-Templates von Nuclei automatisieren genau diesen Ablauf anhand öffentlicher Fingerprint-Datenbanken.
TipVerlass dich nicht auf dein Gedächtnis, was „noch genutzt wird“. Gleiche den Zonen-Export mit deinen tatsächlich bereitgestellten Cloud-Ressourcen ab – alles im DNS ohne passende aktive Ressource ist ein Kandidat zum Entfernen, egal wie alt oder harmlos es aussieht.
Dangling DNS-Einträge sicher entfernen
Sobald du bestätigt hast, dass ein Eintrag verwaist ist, lösche ihn – versuche nicht, ihn zu „reparieren“, indem du unter demselben Namen einen weiteren Eintragstyp hinzufügst. RFC 1034 legt ausdrücklich fest, dass ein Name mit CNAME keine anderen Eintragstypen tragen darf; du kannst also keinen A-Eintrag darüberlegen, ohne vorher den CNAME zu entfernen. Wenn du ihn noch nicht ganz löschen willst, richte ihn auf eine Ressource aus, die du kontrollierst – eine Parking-Seite oder einen eigenen Server –, statt ihn ins Leere zeigen zu lassen.
WarningPrüfe vor dem Löschen, ob der Eintrag zusätzlich als Nachweis der Domain-Inhaberschaft dient (ein TXT- oder CNAME-Verifizierungseintrag für die Plattform, die du verlässt). Wird ein Verifizierungseintrag zu früh entfernt, kann das eine laufende Migration kaputt machen, statt sie abzuschließen.
NS-Delegation-Takeover: ein ganz anderes Kaliber
Eine verwaiste NS-Delegation ist ein eigener, schwerwiegenderer Fall: Sie entsteht, wenn die Zone einer Subdomain an Nameserver eines Drittanbieterkontos (ein DNS-Host, ein CDN, ein Entwickler-Tool) delegiert ist, das inzwischen gekündigt wurde, und die Nameserver-Namen selbst für andere registrierbar werden. Wer diese Nameserver-Namen kontrolliert, kontrolliert dann das DNS der gesamten Subdomain, nicht nur einen Eintrag. Prüfe NS-Delegationen auf dieselbe Weise – löse jeden Nameserver-Hostnamen auf und bestätige, dass er noch zu einem Konto gehört, das du betreibst. Wenn du alle Zonen an einem Ort verwaltest, behältst du hier viel leichter den Überblick; sieh dir an, wie zentrales DNS-Management Delegationen zusammen mit gewöhnlichen Einträgen verwaltet.
Entfernen gehört zum Decommissioning, nicht hinterher
Die eigentliche Lösung ist kein einmaliges Audit, sondern ein Prozess. Lösche den DNS-Eintrag oder richte ihn neu aus, genau in dem Moment, in dem du die Ressource dahinter stilllegst – als Pflichtschritt in der Rückbau-Checkliste, nicht als Folgeticket, das vielleicht nie angelegt wird. Kombiniere das mit einem aktuellen Infrastruktur-Inventar, damit jeder Eintrag einen bekannten, aktuell aktiven Verantwortlichen hat, und ziehe Drift Detection in Betracht, damit ein Eintrag, der zu verwaisen beginnt, automatisch markiert wird, statt auf das nächste manuelle Audit zu warten.
Führe dieses Audit regelmäßig durch, nicht nur einmal. Neue Dangling-Einträge entstehen jedes Mal, wenn ein Projekt eingestellt wird, ein Testkonto abläuft oder ein Team eine Plattform verlässt – das ist eine laufende Wartungsaufgabe, kein Projekt mit Enddatum.
Starte mit einem kostenlosen Scan deiner eigenen Zone mit dem DNS-Lookup-Tool und mache das Löschen zum festen Bestandteil jeder Decommissioning-Checkliste.
Häufig gestellte Fragen
#Kann ein verwaister A-Eintrag einen Subdomain Takeover ermöglichen oder nur CNAMEs?
CNAMEs, die auf Cloud- oder SaaS-Endpunkte zeigen, sind der klassische Fall, weil der Zielname selbst wieder beanspruchbar werden kann. Aber auch ein verwaister A-Eintrag, der auf eine freigegebene Cloud-IP zeigt, lässt sich ausnutzen, wenn jemand anderem dieselbe IP zugewiesen wird und er darauf einen Dienst betreibt.
#Geht etwas kaputt, wenn ich einen Dangling-Eintrag lösche?
Wenn du bestätigt hast, dass die Ressource, auf die er zeigt, nicht mehr existiert, unterbricht das Löschen keinen Live-Traffic – der Eintrag lief ohnehin schon ins Leere oder lieferte nichts Sinnvolles aus. Prüfe aber vorher, ob er nicht zugleich als Verifizierungseintrag für die Domain-Inhaberschaft einer noch laufenden Migration dient.
#Wie oft sollte ich meine DNS-Zone auf Dangling-Einträge prüfen?
Prüfe nach jedem Decommissioning (Abschaltung einer App, Rückbau eines Servers, Kündigung eines SaaS-Dienstes) und zusätzlich in einem festen Rhythmus, etwa vierteljährlich, denn zwischen geplanten Überprüfungen geraten Einträge leicht in Vergessenheit.
#Bedeutet ein gültiges TLS-Zertifikat, dass eine Subdomain sicher ist?
Nein – wenn ein Angreifer eine verwaiste Ressource erfolgreich übernimmt, stellen ihm viele Zertifizierungsstellen ein Zertifikat für deine Subdomain aus, weil die Domain Control Validation den DNS-Eintrag prüft, den du stehen gelassen hast, und nicht, wer das Projekt ursprünglich angelegt hat.
Mit einem kostenlosen Tool ausprobieren
War dieser Artikel hilfreich?
