So funktioniert’s
Viele Dienste werden per CNAME an eine Subdomain gehängt: shop.example.com zeigt auf example.myshopify.com, docs.example.com auf example.github.io, app.example.com auf eine Azure-Web-App. Wird der Dienst gekündigt oder gelöscht, bleibt der CNAME oft stehen und zeigt nun auf einen Namen, den beim Anbieter niemand mehr belegt (Dangling CNAME).
Kann jeder diesen Namen beim Anbieter neu anlegen, übernimmt er damit die Subdomain: Er eröffnet ein Konto, beansprucht den freien Namen oder die Custom Domain und liefert unter shop.example.com eigene Inhalte aus, oft samt gültigem Zertifikat, das der Dienst automatisch ausstellt.
Dasselbe Muster gibt es bei NS-Delegationen auf DNS-Zonen, die beim Anbieter gelöscht wurden, und bei A-Records auf Cloud-Adressen, die freigegeben und inzwischen einem anderen Kunden zugeteilt wurden.
Warum gefährlich
Eine übernommene Subdomain ist für Besucher, Browser und Spamfilter echt: Phishing-Seiten unter login.example.com wirken glaubwürdig, Cookies, die für die ganze Domain gesetzt sind, gehen an den Angreifer, und Regeln, die jeder Subdomain vertrauen (CORS, CSP, OAuth-Weiterleitungen), arbeiten für ihn.
Den Schaden trägt der Ruf des Kunden: Suchmaschinen indexieren Spam unter seiner Domain, und Google kann die Subdomain auf seine Warnliste setzen, was Besucher zusätzlich verunsichert.
So vermeidest du es
- Beim Abschalten eines Dienstes zuerst den DNS-Eintrag löschen und erst danach Konto, App oder Bucket beim Anbieter.
- CNAME-, NS- und A-Records regelmäßig mit der Liste der aktiven Dienste abgleichen; Zonen-Backups oder Exporte beim DNS-Anbieter helfen dabei.
- Wo der Anbieter es kann, die Domain per TXT-Record verifizieren (etwa verifizierte Domains bei GitHub Pages oder asuid-Einträge bei Azure), damit nur dein Konto sie beanspruchen kann.
- Keine Wildcard-CNAMEs auf externe Dienste setzen und Testumgebungen wie staging oder dev nach Projektende samt DNS-Eintrag entfernen.
- Beim Offboarding eines Kunden oder Dienstleisters eine Checkliste für die DNS-Einträge abarbeiten.
So erkennt DomainWarn es
Der Check „Subdomain-Takeover“ prüft täglich bis zu 60 Hostnamen: die Domain, die Hosts der Website-Monitore, die Hostnamen aus den CT-Logs und typische Präfixe wie www, staging, dev, shop oder api. Er verfolgt jede CNAME-Kette autoritativ. Zeigt sie auf einen Namen, den es nicht mehr gibt (von einem zweiten öffentlichen Resolver bestätigt), oder meldet ein bekannter Dienst wie GitHub Pages, Heroku, Amazon S3, Shopify, Netlify oder Vercel, dass der Name dort frei ist, ist das kritisch und eröffnet den Incident „Subdomain übernehmbar (verwaister DNS-Eintrag)“. Dasselbe gilt für eine Subdomain, die an Nameserver delegiert ist, die die Zone nicht mehr kennen.
Ein verwaister CNAME, den niemand beanspruchen kann (etwa mit Ziel unter der eigenen Domain), ist eine Warnung, ebenso ein Hostname aus den CT-Logs, dessen Adresse bei einem Cloud-Anbieter liegt und weder auf Port 80 noch auf 443 antwortet. DomainWarn erkennt nur: Es legt nirgends ein Konto an und beansprucht keinen Namen.
DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.