Dangling DNS: So findest und behebst du es, bevor eine Übernahme erfolgt

Dangling DNS ist eines dieser Probleme, die leicht entstehen und sich nur schwer wirklich erkennen lassen. Ein Eintrag zeigt weiterhin auf eine Cloud-Ressource, nachdem diese Ressource längst gelöscht wurde, und solange niemand gezielt danach sucht, fällt es niemandem auf, bis es zum Problem wird. Die gute Nachricht: Du musst das nicht von Grund auf selbst herausfinden. Zwei der glaubwürdigsten Quellen im Sicherheitsbereich, OWASP und AWS, dokumentieren, warum Dangling DNS entsteht und was dagegen zu tun ist. Dieser Blogbeitrag behandelt das Risiko, was beide dazu sagen, wie du ihre Empfehlungen in die Praxis umsetzt und wo die Tooling-Lücken liegen, die die meisten Teams angreifbar machen.

Kurzfassung: Dangling-DNS-Einträge ermöglichen es Angreifern, eine Subdomain zu übernehmen, ohne irgendetwas zu kompromittieren. OWASP und AWS dokumentieren beide das Problem und die Lösung, und die aktualisierten NIST-Richtlinien benennen es nun ausdrücklich. Die Lösung ist pro Eintrag einfach. Der schwierige Teil besteht darin, Dangling-Einträge kontinuierlich über einen realen Bestand mit mehreren Registraren und Clouds hinweg zu finden – genau diese Lücke kann Red Sift schließen.

Die wichtigsten Erkenntnisse:

• Ein Dangling-DNS-Eintrag zeigt auf eine Cloud-Ressource, die gelöscht wurde. Wenn der Ressourcenname erneut beansprucht werden kann, kann ein Angreifer eigene Inhalte über deine Subdomain ausliefern.
• Das ist kein Zeichen für ein nachlässiges Team. Es ist eine strukturelle Nebenwirkung davon, wie schnell Cloud-Ressourcen erstellt und wieder abgeschaltet werden.
• OWASP und AWS dokumentieren beide das Problem, sodass es klare, glaubwürdige Anleitungen gibt, denen man folgen kann.
• AWS gibt offen zu, dass die eigene Plattform diese Lücke nicht für dich schließt: wiederverwendbare Ressourcennamen, kein universeller Mechanismus zur Domain-Verifizierung und Angreifer, die bereits aktiv nach Dangling-Einträgen suchen.
• Die Lösung ist pro Eintrag unkompliziert. Der schwierige Teil ist die kontinuierliche Entdeckung über einen Bestand mit mehreren Registraren und mehreren Clouds hinweg – genau hier hilft Red Sift Attack Surface Management.

Ein Dangling-DNS-Eintrag ist ein DNS-Eintrag, meist ein CNAME (Canonical Name, der einen Namen auf einen anderen verweist), der weiterhin auf eine Cloud-Ressource zeigt, nachdem diese Ressource gelöscht wurde. Der Dienst existiert nicht mehr. Der Eintrag schon. Bei vielen Cloud-Plattformen wandert der Ressourcenname anschließend zurück in einen gemeinsamen Pool, den jeder Kunde beanspruchen kann. Ein Angreifer, der eine Ressource mit diesem Namen neu erstellt, übernimmt damit deine Subdomain, weil dein DNS weiterhin Traffic dorthin schickt.

Kein Einbruch, kein gestohlenes Passwort. Der Eintrag überlebt einfach die Ressource, und die Lücke, die dadurch entsteht, kann beansprucht werden.

Der Grund, warum das mehr ist als nur eine kaputte Seite, liegt im Vertrauen, das deine Domain bereits genießt. Eine Subdomain, die deine Kunden, Browser und Mailsysteme als deine eigene behandeln, gerät unter die Kontrolle eines Angreifers. Das ermöglicht Phishing über eine Domain, die Nutzer erkennen, den Diebstahl von Session-Cookies, die für die übergeordnete Domain gelten, gekaperte OAuth- und SSO-Login-Abläufe sowie gültige TLS-Zertifikate, die über Domain-Validierungsprüfungen in deinem Namen ausgestellt werden. Wenn die Eintragskette Mail betrifft, kann das auch abgefangene Passwort-Resets bedeuten. Das ist der "übernommene" Fehlermodus.

OWASP, die anbieterneutrale Standardgemeinschaft, behandelt Subdomain-Übernahmen als operatives Problem und nicht als Software-Fehler, und der nützlichste Punkt ist zugleich der einfachste. Die meisten Organisationen haben keine Möglichkeit zu erkennen, wenn das Ziel eines DNS-Eintrags stillschweigend aufhört zu existieren. Das ist der Standardzustand, kein Versagen der Sorgfalt. Der Eintrag und die Ressource driften auseinander, nichts gleicht sie ab, und die Lücke bleibt offen, bis jemand darüber stolpert.

OWASPs Empfehlungen zur Prävention sind klar und praxisnah: Führe ein Inventar darüber, worauf deine Einträge zeigen, entferne Einträge, bevor die Ressourcen, von denen sie abhängen, gelöscht werden, und achte auf die Fehlermeldungen der Anbieter, die eine tote Ressource zurückgibt, bevor jemand sie beansprucht. Das ist guter, umsetzbarer Rat, und er ist kostenlos.

AWS dokumentiert dies in den eigenen Sicherheitsrichtlinien, und diese Offenheit verdient Anerkennung. AWS macht deutlich, dass die Plattform diese Lücke nicht für dich schließt, und nennt drei Gründe dafür:

• Viele AWS-Dienste erlauben es einem neuen Kunden, einen zuvor verwendeten Hostnamen oder Ressourcennamen zu beanspruchen.
• AWS bietet derzeit keinen universellen Mechanismus zur Domain-Verifizierung über all seine Dienste hinweg.
• Die Incident-Response-Teams von AWS beobachten Angreifer, die aktiv öffentliche DNS-Einträge nach CNAME-Einträgen durchsuchen, die auf nicht mehr existierende Ressourcen verweisen.

Der letzte Punkt ist entscheidend. Das ist kein theoretisches Risiko, das irgendwo im Backlog liegt. Es ist ein aktives Scan-Verhalten, das jetzt gerade stattfindet.

Hier liegt der nützliche Unterschied zwischen den beiden Stimmen. OWASP ist nicht AWS, kann also beraten, aber nicht ändern, wie die Cloud funktioniert. AWS könnte universelle Kontrollen einführen, etwa eine Domain-Verifizierung, die einen Großteil dieses Problems entschärfen würde, hat sich bisher aber dagegen entschieden. Das lässt eine reale Lücke zwischen dem, was die Anbieter dir zur Verfügung stellen, und dem, was du brauchst, um geschützt zu bleiben. Diese Lücke hast nicht du geschaffen, und um sie zu schließen, musst du nicht darauf warten, dass ein Anbieter handelt. Es braucht Transparenz, und Transparenz kannst du schon heute schaffen.

Diesen Rat für einen einzelnen Eintrag zu befolgen, über den du gerade aktiv nachdenkst, ist einfach. Ihn über einen Bestand hinweg anzuwenden, den du gar nicht vollständig überblicken kannst, ist der schwierige Teil. Die Cloud hat verändert, wofür DNS genutzt wird, und die Bestände sind mitgewachsen. Bei einem realen Unternehmen kamen bei einer einzigen Apex-Domain über 25.000 Subdomains zum Vorschein, deren Zuständigkeit sich über Infrastruktur, Marketing, Entwickler, SaaS-Anbieter und Cloud-Provider verteilte. Kein einzelnes Team kann das alles manuell überblicken.

Die Antwort ist also keine einmalige Aufräumaktion. Es ist ein wiederholbares Betriebsmodell. Diese fünf Phasen, ausgerichtet an den NIST-Themen, machen aus den Empfehlungen etwas, das du tatsächlich umsetzen kannst.

1. Inventarisierung. Entdecke jede Domain, jede Zone, jeden Eintrag, unabhängig davon, wer sie verwaltet: mehrere Registrare, mehrere DNS-Anbieter, Multi-Cloud und mehrere Zertifizierungsstellen. Du kannst nicht schützen, was du nicht gefunden hast.
2. Baseline. Definiere, wie ein guter Zustand aussieht: die von dir zugelassenen Registrare und DNS-Anbieter, deine genehmigten Cloud-Bereiche und Zertifizierungsstellen, deine E-Mail-Authentifizierungslage und wo du mit DNSSEC signierst. Ohne Baseline sieht jede Änderung gleich aus, und nichts wirkt verdächtig.
3. Erkennen und Klassifizieren. Mache unerwartete Änderungen sichtbar und unterdrücke das erwartete Rauschen. Etwa 1 % der Namen ändern sich täglich, das entspricht rund 375 Ereignissen pro Tag. Erst die Klassifizierung macht das handhabbar.
4. Kontinuierlich bewerten. Prüfe den Bestand anhand der NIST SP 800-81r3-Themen: Schutz des DNS-Dienstes, Bedrohungen bei Zonentransfers, Zoneninhalt und -konsistenz, Minimierung von Informationslecks, Integrität externer Domains sowie DNSSEC-Signierung und -Validierung.
5. Priorisieren. Stufe den Bestand ab, damit das Modell tragfähig bleibt. Nicht alles benötigt die gleiche Aufmerksamkeit.

Tu das, und OWASPs Rat zur Inventarisierung sowie AWS' Rat "Entferne den Eintrag vor der Ressource" hören auf, bloße Wunschvorstellungen zu sein. Sie werden zu Schritten, die du messen und wiederholen kannst.

Die Phase, an der alle scheitern, ist die erste, denn du kannst nicht inventarisieren oder überwachen, was du nicht siehst, und weder die Anbieter noch die kostenlosen Tools geben dir einen vollständigen Überblick. Cloud-native Konfigurationsprüfungen sind nützlich, aber von Natur aus auf ein einzelnes Konto und eine einzelne Cloud beschränkt. Open-Source-Scanner decken mehr ab, laufen aber nur, wenn du daran denkst, sie zu starten. Die Einträge, die übernommen werden, sind selten die, an die du gerade denkst. Es sind die, die du vergessen hast, die du bei einer Übernahme geerbt hast, oder von denen du nie wusstest, dass sie existieren.

Red Sift ASM (Attack Surface Management) deckt genau die Lücken ab, die die Plattformen offenlassen. Es entdeckt Domains und Subdomains über deinen gesamten externen Bestand hinweg, prüft DNS-, Web- und Cloud-Konfigurationen und meldet Dangling-Einträge sowie beanspruchbare Ressourcen, sobald sie auftauchen – über jeden Registrar und jede Cloud hinweg, statt Konto für Konto. Im Grunde erhältst du damit die kontinuierliche Verifizierungsebene, die AWS nicht bietet, angewendet auf deinen gesamten Bestand.

Gute DNS-Hygiene, also den Eintrag vor der Ressource zu entfernen, ist die erste Verteidigungslinie, und sowohl OWASP als auch AWS liefern dir dafür ein solides Vorgehen. Kontinuierliche Entdeckung ist das, was die Einträge abfängt, die dennoch durchrutschen. Du musst nicht warten, bis ein Anbieter die Lücke schließt, um ihr einen Schritt voraus zu sein.

Finde mit Red Sift ASM heraus, worauf dein DNS zeigt, oder durchstöbere die vollständige Sammlung der Red Sift-Guides für mehr zum Umgang mit DNS- und Zertifikatsrisiken.