Dienst gelöscht – DNS vergessen? So entstehen übernehmbare Subdomains
Ein alter CNAME zu einem gelöschten Cloud- oder SaaS-Dienst kann zur übernehmbaren Subdomain werden. So prüfen Sie DNS-Lebenszyklen, Verifizierung und Decommissioning.
Eine Kampagnenseite wird abgeschaltet. Das Helpcenter zieht um. Eine Preview-Umgebung wird gelöscht. Die Rechnung beim SaaS-Anbieter ist beendet – aber im DNS bleibt promo.example.de als CNAME auf den alten Dienst stehen.
Für Besucher sieht das zunächst nur wie eine kaputte Subdomain aus. Sicherheitstechnisch kann daraus mehr werden: Wenn der Zielname oder die zugehörige Ressource bei einem Drittanbieter erneut beansprucht werden kann, kann jemand anderes Inhalte unter Ihrer eigenen Subdomain ausliefern.
Microsoft und OWASP beschreiben dieses Muster als dangling DNS beziehungsweise Subdomain Takeover. Das Problem ist weniger ein exotischer DNS-Trick als ein Lebenszyklusfehler: Der DNS-Eintrag lebt länger als der Dienst, auf den er einmal gezeigt hat.
Der gefährliche Moment ist oft das Aufräumen
Beim Launch denken Teams an DNS. Beim Abschalten denken sie an Kosten. Das Ticket lautet dann: Cloud-App löschen, SaaS kündigen, Projekt archivieren. Der DNS-Eintrag wirkt wie ein Detail und bleibt zurück.
Genau deshalb sind alte Kampagnen, frühere Staging-Systeme, migrierte Helpcenter, temporäre Landingpages, Demo-Umgebungen und Proof-of-Concepts interessante Kandidaten.
Die bessere Decommissioning-Frage lautet nicht nur: „Ist der Dienst abgeschaltet?“ Sondern: „Welche Domain, Subdomain, Weiterleitung, OAuth-Konfiguration und externe Referenz zeigte auf diesen Dienst – und was passiert damit jetzt?“
Nicht jeder kaputte DNS-Eintrag ist automatisch übernehmbar
Ein wichtiger Punkt gegen Alarmismus: Ein CNAME, der ins Leere zeigt, ist nicht automatisch eine ausnutzbare Sicherheitslücke.
Für eine tatsächliche Übernahme müssen typischerweise zwei Bedingungen zusammenkommen:
- Ihr DNS verweist weiterhin auf eine Ressource oder einen Dienst, den Sie nicht mehr kontrollieren.
- Der jeweilige Provider erlaubt einem anderen Account, genau die relevante Ressource, Hostname-Bindung oder Domain-Zuordnung zu beanspruchen.
Provider unterscheiden sich. Manche reservieren Namen nach einer Löschung, andere verlangen zusätzliche Domain-Verifizierung oder haben spezielle Schutzmechanismen. GitHub Pages empfiehlt beispielsweise die Verifizierung benutzerdefinierter Domains, damit andere GitHub-Nutzer eine weiterhin konfigurierte Domain nicht einfach ihrer eigenen Pages-Site zuordnen können.
Ein Audit sollte daher niemals nur nach „DNS-Ziel antwortet nicht“ urteilen. Ein nicht erreichbares Ziel ist ein Signal für manuelle Prüfung – kein automatischer Exploit-Beweis.
Warum eine übernommene Subdomain mehr als ein hässlicher 404 ist
Eine fremd kontrollierte Seite unter support.example.de trägt weiterhin Ihren Domainnamen. Das verleiht ihr etwas, das eine zufällige Phishing-Domain nicht hat: bestehendes Vertrauen.
Mögliche Auswirkungen hängen von der restlichen Architektur ab:
- Phishing oder Fake-Login unter einer vertrauten Subdomain,
- alte Links und Bookmarks führen plötzlich zu fremden Inhalten,
- Wildcard-Regeln in CSP, CORS oder anderen Allowlisten vertrauen der Subdomain weiterhin,
- OAuth- oder SSO-Konfigurationen enthalten veraltete Redirect-URIs,
- zu breit auf die Parent-Domain gesetzte Cookies erhöhen das Risiko,
- Suchtreffer, PDFs, QR-Codes und externe Links schicken weiterhin Besucher dorthin.
Die relevante Frage lautet deshalb nicht nur, wer dort HTML ausliefern kann, sondern welche anderen Systeme diesem Hostnamen noch vertrauen.
Fünf Red Flags im Betrieb
1. Niemand kann jedem DNS-Eintrag einen Eigentümer zuordnen
Die Agentur verwaltet die Website, IT den Registrar und Marketing seine Landingpage-Plattform. Wenn niemand Zweck, Provider und Owner eines Records nennen kann, wird er schnell zum Dauerbewohner.
2. Der Dienst wird vor dem DNS gelöscht
OWASP empfiehlt für Decommissioning die sicherere Reihenfolge: DNS kontrolliert ändern oder entfernen, TTL und Propagation berücksichtigen und erst danach die externe Ressource endgültig aufgeben.
3. Wildcard-DNS wird aus Bequemlichkeit verwendet
Ein *.example.de kann legitim sein, vergrößert aber die Vertrauensfläche. GitHub warnt im Pages-Kontext ausdrücklich vor Wildcard-DNS. Wildcards sollten bewusst, eng und dokumentiert sein.
4. Temporäre Subdomains stehen in keinem Inventar
www und app kennt jeder. Vergessen werden eher beta, events, jobs, demo, docs-old oder eine Jahreskampagne. Gerade temporäre Systeme leben organisatorisch oft länger als technisch.
5. DNS und Dienst haben unterschiedliche Owner
Die Person, die Vercel, GitHub, Azure, Netlify, einen Helpdesk oder Shop löscht, hat möglicherweise keinen DNS-Zugriff. Dann braucht die Abschaltung einen expliziten Übergabeschritt.
Ein brauchbarer Audit beginnt mit einem DNS-Inventar
Für jede öffentlich erreichbare Domain und Subdomain sollten mindestens Record-Typ, Ziel, geschäftlicher Zweck, Owner, Provider, Existenz der Zielressource, Domain-Verifizierungsstatus, letztes Prüfdatum und Abschaltprozess dokumentiert sein.
Besonders relevant sind externe Ziele: Cloud-Hostnamen, SaaS-Subdomains, CDN-Endpunkte, Helpcenter, Shops, Website-Builder sowie frühere Agentur- und Kampagnenplattformen.
OWASP empfiehlt für technische Prüfungen Subdomain-Enumeration, Provider-Fingerprints und anschließend manuelle Validierung. Dieser letzte Schritt ist entscheidend: Scanner liefern Kandidaten; die tatsächliche Übernehmbarkeit hängt von der aktuellen Provider-Logik ab.
Decommissioning braucht eine Definition of Done
Für externe Webdienste sollte „abgeschaltet“ mehr bedeuten als „Rechnung beendet“:
- Abhängigkeiten erfassen: DNS, Links, Redirects, OAuth/SSO, CSP/CORS, E-Mail, Monitoring und Dokumentation.
- Ersatz oder Redirect planen, falls die URL weiter gebraucht wird.
- DNS ändern oder entfernen, solange die alte Ressource noch unter eigener Kontrolle ist.
- TTL und DNS-Propagation berücksichtigen.
- Externe Ressource oder Vertrag löschen.
- Hostnamen anschließend aus einem frischen Netzwerk oder Browser erneut prüfen.
- Veraltete Trust-Beziehungen wie OAuth-Redirects, Allowlisten und Webhooks entfernen.
- Inventar aktualisieren.
Das muss kein Enterprise-Prozess sein. Für kleine Teams reicht eine kurze, verpflichtende Decommissioning-Checkliste.
Domain-Verifizierung ist eine zweite Schutzschicht
Wo Provider Domain-Verifizierung anbieten, sollte sie aktiviert werden. GitHub dokumentiert sie für Pages ausdrücklich als Schutz gegen Übernahme-Szenarien. Microsoft beschreibt für Azure ebenfalls Schutzmechanismen rund um verifizierte Domains.
Aber: Verifizierung ersetzt keine DNS-Hygiene. Ein nicht mehr benötigter Record gehört entfernt. Provider-Schutz ist Defense in Depth, keine Erlaubnis, verwaiste Infrastruktur liegen zu lassen.
Was Website-Pflichtencheck prüfen würde
Ein DNS-Lifecycle- und Subdomain-Takeover-Check kann öffentlich sichtbare Subdomains und DNS-Ziele inventarisieren, Drittanbieter-Zuordnungen erkennen, nicht mehr existente Ziele markieren, Kandidaten manuell gegen das aktuelle Provider-Verhalten prüfen, Wildcard-Einträge bewerten und vorhandene Domain-Verifizierung kontrollieren.
Zusätzlich sollte geprüft werden, welche Vertrauensbeziehungen an alten Hostnamen hängen: Cookies, CSP, CORS, OAuth/SSO, Webhooks, E-Mails, QR-Codes, Dokumente und Monitoring.
Das Ziel ist nicht, jede kaputte Subdomain zum Notfall zu erklären. Es ist ein sauberer Lebenszyklus: Wenn eine Ressource verschwindet, muss auch die technische Vertrauensbeziehung zu dieser Ressource verschwinden.
Ein DNS-Eintrag ist winzig. Seine Lebensdauer kann trotzdem länger sein als die Erinnerung daran, warum er einmal angelegt wurde. Genau deshalb gehört DNS-Aufräumen in den normalen Website-Betrieb.