Subdomain-Finder: bekannte Subdomains einer Domain

Der Subdomain-Finder zeigt, welche Subdomains einer Domain öffentlich bekannt sind. Du gibst eine Domain ein, etwa beispiel.de, und erhältst eine alphabetische Liste wie shop.beispiel.de, mail.beispiel.de oder test.beispiel.de. Neben jedem Namen stehen zwei Links: einer öffnet die Subdomain im Browser, der andere prüft ihre Einträge im DNS-Check. Bei großen Domains mit vielen Zertifikaten dauert die Suche einige Sekunden.

Wie der Finder Subdomains findet

Die Liste stammt aus den Certificate-Transparency-Logs. Das sind öffentliche Verzeichnisse, in die Zertifizierungsstellen ihre TLS-Zertifikate eintragen. Einträge werden nur angehängt, nie gelöscht, und jeder kann sie lesen ^{[1, 2]}. Browser wie Chrome und Safari bestehen auf diesen Einträgen, deshalb steht praktisch jedes öffentlich vertrauenswürdige Zertifikat in mindestens einem Log ^[2].

In jedem Zertifikat stehen die Hostnamen, für die es gilt. Der Finder fragt beim Dienst crt.sh alle Zertifikate ab, deren Namen auf die eingegebene Domain enden, und sammelt daraus jeden Namen genau einmal. Wurde für dev.beispiel.de irgendwann ein Zertifikat ausgestellt, steht dev.beispiel.de in der Liste, auch wenn die Subdomain längst abgeschaltet ist. Was eine Subdomain technisch ist, erklärt Was ist eine Subdomain?

Was die Liste nicht zeigt

Die Liste ist kein vollständiges Verzeichnis. Subdomains, für die nie ein öffentliches Zertifikat ausgestellt wurde, fehlen. Das betrifft zum Beispiel Namen, die nur intern genutzt werden oder nur über unverschlüsseltes HTTP laufen.

Auch Wildcard-Zertifikate verbergen Namen. Ein Zertifikat für *.beispiel.de gilt für jede Subdomain auf genau einer Ebene, also für shop.beispiel.de und blog.beispiel.de ^[3]. In den Logs steht dann nur der Stern und kein einzelner Name. Der Finder blendet solche Sterneinträge aus, weil sie keine konkrete Subdomain nennen. Wie Wildcards im DNS arbeiten, steht im Ratgeber Wildcard-DNS: ein Eintrag für alle Subdomains.

Außerdem sagt die Liste nichts darüber, ob eine Subdomain heute noch existiert. Dafür ist der DNS-Link neben jedem Eintrag da: Er zeigt, ob der Name noch eine Adresse oder einen CNAME hat.

Vergessene Subdomains aufräumen

Für die eigene Domain ist der Finder eine schnelle Bestandsaufnahme. Oft tauchen alte Testsysteme, abgelöste Shops oder Namen für Dienste auf, die niemand mehr nutzt. Gefährlich wird das, wenn im DNS noch ein Eintrag auf einen Dienst zeigt, den es nicht mehr gibt. Microsoft nennt solche Einträge in der Azure-Dokumentation "dangling DNS". Besonders anfällig sind CNAME-Einträge, die auf eine gelöschte Cloud-Ressource verweisen. Legt ein Angreifer unter dem frei gewordenen Zielnamen eine eigene Ressource an, landet der Verkehr deiner Subdomain bei ihm ^[4].

Auf so einer übernommenen Subdomain kann der Angreifer eigene Inhalte zeigen, Phishing-Seiten betreiben und sogar ein gültiges Zertifikat beantragen. Weil viele Anwendungen ihre Cookies für alle Subdomains freigeben, kann er unter Umständen auch Sitzungscookies abgreifen ^[4]. Das Risiko betrifft auch E-Mail: Über verwaiste MX-Einträge könnten Angreifer Mails empfangen, die an eine echte Subdomain gerichtet sind ^[4]. Microsoft empfiehlt, beim Abschalten eines Dienstes den DNS-Eintrag als festen Arbeitsschritt zu löschen und die DNS-Zone regelmäßig auf Einträge ohne Ziel zu prüfen ^[4].

So gehst du mit der Liste vor:

1. Für jede Subdomain klären, wofür sie gedacht war und wer sie betreut.
2. Mit dem DNS-Link prüfen, ob noch ein A-, AAAA- oder CNAME-Eintrag besteht.
3. Zeigt ein CNAME auf einen Dienst, den du nicht mehr nutzt, den Eintrag beim DNS-Anbieter löschen.
4. Subdomains, die bleiben sollen, mit einem aktuellen Zertifikat versorgen und im SSL-Check kontrollieren.

Eine feste Gelegenheit für diese Prüfung ist das Ende eines Projekts, etwa wenn eine Kampagnenseite ausläuft oder ein Shop umzieht. Wer viele Subdomains hat, führt am besten eine Liste mit Name, Zweck, Ziel im DNS und Ansprechpartner. Microsoft rät zu einem solchen Verzeichnis der eigenen Endpunkte mit den zuständigen Personen ^[4].

Weitere Schutzmaßnahmen für Domain und DNS stehen im Ratgeber Domain-Hijacking verhindern. Wie Betrüger mit echt wirkenden Adressen arbeiten, beschreibt betrug.domain-root.de unter Phishing-Mails erkennen.

Subdomains sind öffentlich

Wer für eine Subdomain ein öffentliches Zertifikat beantragt, macht ihren Namen damit bekannt. RFC 9162 weist ausdrücklich darauf hin, dass sich über die Logs Domainnamen herausfinden lassen, die sonst schwer zu entdecken wären. Manche Namen verraten zudem, welche Dienste oder Programme ein Betreiber nutzt, und erleichtern so gezielte Angriffe ^[1].

Ein unauffälliger Name schützt ein Testsystem also nicht. Sichere es mit einem Passwort oder einer Sperre auf bestimmte IP-Adressen. Soll der Name gar nicht in den Logs stehen, kommt ein Wildcard-Zertifikat in Frage, weil es nur *.beispiel.de enthält. Vor- und Nachteile vergleicht SSL für Subdomains: Wildcard oder einzelne Zertifikate.

Nutzung und Datenschutz

Nutze den Finder für deine eigenen Domains oder für Domains, die du betreust, etwa als Administrator oder Agentur. Die Daten sind zwar öffentlich, doch nur bei eigenen Domains kannst du aus dem Ergebnis auch etwas verbessern.

Die Abfrage läuft direkt aus deinem Browser zu crt.sh, nicht über unseren Server. crt.sh erfährt dabei den Namen, den du prüfst, und deine IP-Adresse. Der Dienst gehört zu den Websites von Sectigo, verantwortlich ist laut Datenschutzerklärung die Sectigo Limited mit Sitz im Vereinigten Königreich ^[5]. Ist crt.sh überlastet, meldet der Finder einen Fehler, dann hilft ein zweiter Versuch nach kurzer Zeit. Nach dem Aufruf steht die Domain mit "?d=" in der Adresse dieser Seite, damit du das Ergebnis als Link weitergeben kannst. Was unsere Statistik und die Werbung dabei erfassen, steht in der Datenschutzerklärung.

1. Gesetz RFC 9162: Certificate Transparency Version 2.0, Abschnitte 1, 4 und 11.5. IETF. Stand Dezember 2021. abgerufen am 29.10.2026
2. Organisation How CT works. Certificate Transparency (Google). Stand 2026. abgerufen am 29.10.2026
3. Gesetz RFC 9525: Service Identity in TLS, Abschnitt 6.3. IETF. Stand November 2023. abgerufen am 29.10.2026
4. Organisation Prevent dangling DNS entries and avoid subdomain takeover. Microsoft. Stand 20.07.2026. abgerufen am 29.10.2026
5. Organisation Privacy Policy. Sectigo Limited. Stand 2026. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.