Warum eine eigene Domain erst dann geroutet wird, wenn du bewiesen hast, dass sie dir gehört
Subdomain-Takeover ist eine dieser Schwachstellenklassen, die obskur klingen, bis man sie einmal erlebt hat: Ein Team zeigt mit status.example.com auf einen Drittanbieter-Dienst, nutzt diesen Dienst nicht mehr, vergisst, den DNS-Eintrag zu entfernen, und Monate später beansprucht jemand anders denselben Dienst-Slot und kontrolliert jetzt, was status.example.com ausliefert – komplett mit gültigem Zertifikat, für jeden, der die Seite besucht. Es ist eine gut dokumentierte Bug-Klasse genau deshalb, weil der Fehlerzustand so leicht versehentlich entsteht und so leicht übersehen wird, bis er ausgenutzt wird.
Wo der Standardschutz eigentlich liegt
Jede App startet mit einer funktionierenden, zertifizierten URL, ohne dass etwas konfiguriert werden muss: https://<name>.<server-ip>.sslip.io – ein kostenloser DNS-Trick (sslip.io löst anhand der im Hostnamen selbst eingebetteten IP auf), der überhaupt keinen eigenen DNS-Eintrag braucht, sodass es am ersten Tag nichts falsch zu konfigurieren gibt.
Eine echte eigene Domain hinzuzufügen ist der Punkt, an dem das Takeover-Risiko normalerweise liegt, und genau da passiert der eigentliche Check: Zusammen mit dem DNS-Eintrag, den du hinzufügst (ein A-Eintrag auf die IP des Servers, oder CNAME für eine Subdomain), wird ein zweiter TXT-Eintrag angefordert – _railyard-verify.<domain> → railyard-verify=<token>. Automatisch alle 30 Sekunden geprüft, oder auf Abruf mit Check now. Zertifikat und Routing starten nicht, bevor dieser TXT-Eintrag tatsächlich gefunden wurde. Jemand, der eine Domain, die er nicht kontrolliert, auf eine App zeigt – genau die Mechanik hinter einem Takeover – kommt schlicht nie über „unverified“ hinaus, weil er kein Token vorzeigen kann, das er nie bekommen hat.
Die Zustände, die das nachvollziehbar machen, nicht nur erzwungen
Eine Domain zeigt einen von fünf Zuständen, und jeder beantwortet eine andere Frage ehrlich, statt alles in ein generisches „pending“ zu quetschen: unverified (der TXT-Eintrag wurde noch nicht gefunden), pending (Eigentum bestätigt, Zertifikat noch nicht ausgestellt), live (liefert tatsächlich Traffic aus), unrouted (verifiziert, aber die App wurde seit dem Hinzufügen nicht neu deployt – ein Redeploy ist es, der tatsächlich routet) oder misconfigured (Zertifikatsausstellung fehlgeschlagen, mit Check now, das zeigt, warum). Zu wissen, in welchem dieser Zustände sich eine Domain befindet, ist der Unterschied zwischen „ist wahrscheinlich okay“ und tatsächlich zu wissen, was noch zu tun ist.
Wildcards bekommen denselben Check, hochskaliert
*.example.com hinzuzufügen routet alle Subdomains auf einmal zur App, statt jede einzeln von Hand hinzuzufügen – wirklich nützlich für ein Multi-Tenant-Produkt, das jedem Kunden seine eigene Subdomain gibt. Die Eigentumsprüfung skaliert mit: Sie prüft railyard-check.example.com statt jeder möglichen Subdomain, sodass die Wildcard nicht beansprucht werden kann, ohne die eigentliche Zone zu kontrollieren. Standardmäßig bekommt jede Subdomain beim ersten Besuch ihr eigenes Zertifikat; das Hinzufügen eines DNS-Credentials ergibt stattdessen ein Zertifikat, das die gesamte Wildcard abdeckt – ein Trade-off zwischen Setup-Komplexität und Zertifikatsanzahl, den man bewusst wählen sollte, statt hineinzurutschen.
Das www/nackte-Domain-Paar, zusammen behandelt
Auch die www/nackte-Domain-Version hinzufügen ankreuzen, und beide werden zusammen hinzugefügt und verifiziert, mit Weiterleitung auf die, die du später als primär markierst – ein Detail, das wichtig ist, weil die Hälfte dieses Paars, die jemand vergisst, meist die ist, die am Ende unüberwacht bleibt und irgendwann das eigentliche Ziel eines Takeovers wird.
Vollständige Referenz: Domains und HTTPS.