Ein Branded Short Link besteht im Kern aus zwei Infrastruktur-Komponenten: einem DNS-Eintrag, der dem Internet mitteilt, dass Ihre Subdomain hier existiert, und einem TLS-Zertifikat, das die Rechtmäßigkeit der HTTPS-Verbindung bestätigt. Beides ist für sich genommen nicht kompliziert. Die interessante Frage ist, was am Edge passiert, nachdem der Redirect aufgelöst wurde - wie eine Plattform, die tausende Custom Domains von Mandanten verwaltet, Zertifikate bei Bedarf ausstellt, Let's Encrypt Rate-Limits vermeidet, ein p95 Latenzbudget von unter 15 ms einhält und sich gnadenvoll erholt, wenn das DNS-Team eines Kunden mitten in einer Kampagne den CNAME löscht.
Genau darum geht es in diesem Beitrag.
TL;DR#
- Die DNS-Verifizierung erfolgt über eine CNAME- oder TXT-Challenge; die TLS-Ausstellung geschieht via ACME On-Demand, getriggert beim ersten Aufruf eines neuen Hostnamens.
- Let's Encrypt erlaubt maximal 50 Zertifikate pro registrierter Domain pro Woche - das bedeutet, man benötigt bei entsprechender Skalierung eine separate registrierte Domain pro Mandant, statt Subdomains einer einzigen
elido.me. - ECDSA P-256 Zertifikate sind auf der TLS-Handshake-Ebene wesentlich schneller als RSA-2048; Elido stellt P-256 für jede Custom Domain aus.
- Drei Dinge führen im Live-Betrieb regelmäßig zu Problemen: DNS-Propagationsverzögerungen, abgelaufene CAA-Records und Kunden, die ihren eigenen CNAME löschen. Für jedes Szenario gibt es einen konkreten Wiederherstellungspfad.
Die zwei Komponenten eines Kurzlink-Dienstes mit eigener Domain#
Eigene Domains für Kurzlinks erfordern zwei Dinge von Ihnen als Domaininhaber und zwei Dinge von der Plattform.
Von Ihnen: Eine DNS-Änderung (ein CNAME- oder ALIAS-Record, der Ihre Subdomain auf den Edge der Plattform verweist) und einen Inhabernachweis (meist ein DNS-TXT-Record oder eine CNAME-Challenge, mit der die Plattform prüft, ob Sie die Domain kontrollieren, bevor sie diese bedient).
Von der Plattform: Eine Routing-Regel, die Ihren Hostnamen erkennt und weiß, aus welchem Workspace die Links serviert werden sollen, sowie ein für Ihren Hostnamen ausgestelltes TLS-Zertifikat, damit Browser ein grünes Schloss statt einer Warnung anzeigen.
Elido übernimmt die letzten beiden Punkte über einen Domain-Validierungsdienst. Dieser ist für die DNS-Verifizierung, die Zertifikatsausstellung und die Aktualisierung der Routing-Tabelle verantwortlich. Er steuert das automatische On-Demand-TLS und löst das Workspace-Mapping auf. Der Edge-Dienst - derjenige mit einem Sub-10-ms-In-Region-Latenzbudget - weiß nichts über die Zertifikatsausstellung; das passiert alles außerhalb des Request-Pfads.
Der Verifizierungs-Flow ist simpel. Sie fügen einen CNAME von Ihrer Subdomain auf b.elido.me (Business-Tier) hinzu und erstellen dann einen TXT-Record wie _elido-verify.acme.example.com = "ws_abc123", um den Besitz der Domain zu beweisen. Der Domain-Validierungsdienst pollt den TXT-Record, bestätigt ihn, markiert die Domain als verifiziert und registriert sie für TLS. Der erste HTTPS-Request an acme.example.com triggert die On-Demand-TLS-Ausstellung - dazu gleich mehr.
DNS: CNAME vs ALIAS vs A#
Welchen Typ von DNS-Eintrag Sie verwenden können, hängt davon ab, welche Subdomain Sie delegieren.
CNAME funktioniert für jede Subdomain, die nicht der Apex ist. links.example.com CNAME b.elido.me. ist das Standard-Setup. RFC 1034 §3.6.2 verbietet CNAME-Einträge am Zonen-Apex (der nackten Domain example.com), da sie mit SOA- und NS-Einträgen kollidieren würden, die dort existieren müssen. Fast jeder Registrar und DNS-Anbieter erzwingt dies.
ALIAS / ANAME Einträge sind eine nicht-standardisierte Erweiterung, die mehrere DNS-Anbieter implementieren (Route 53 ALIAS, Cloudflare CNAME flattening, DNSimple ALIAS), um genau das Apex-Problem zu lösen. Syntaktisch verhalten sie sich wie CNAMEs, werden aber im Hintergrund zu A/AAAA-Records aufgelöst. Der DNS-Provider flacht den Lookup also ab, bevor er ihn publiziert. Wenn Sie zwingend example.com (statt www.example.com) weiterleiten müssen, ist ALIAS Ihre einzige DNS-konforme Option. Prüfen Sie die Dokumentation Ihres DNS-Anbieters - diese Features sind nicht interoperabel und die Bezeichnungen variieren.
A record direkt auf eine Elido IP ist der letzte Ausweg. IPs können sich ändern, wenn wir einen neuen POP hinzufügen oder ein Edge-Cluster umadressieren; wir betrachten Edge-IPs nicht als stabile API-Oberfläche. Wenn Sie heute einen A-Record verwenden, wechseln Sie zu CNAME oder ALIAS.
Ein weiterer Punkt, den Administratoren oft übersehen: Apex-Redirects kollidieren häufig mit Email-DNS. MX, _dmarc, _domainkey und SPF-TXT-Records liegen alle am oder unter dem Apex. Ein ALIAS am Apex kollidiert nicht mit ihnen - es sind unterschiedliche Eintragstypen - aber einige ALIAS-Implementierungen von DNS-Providern haben undokumentierte Einschränkungen für die Koexistenz von Apex-Einträgen. Testen Sie dies, bevor Sie eine Kampagne starten.
TLS: ACME, Rate-Limits und das On-Demand-Muster#
Jede eigene Domain erhält ihr eigenes Zertifikat. Wir verwenden keine Wildcard-Zertifikate für Mandanten-Domains, da diese laut RFC 8555 §8.4 eine DNS-01 Challenge erfordern. Das würde bedeuten, dass wir die DNS-Zone jeder Domain unserer Kunden kontrollieren müssten - was wir nicht tun. HTTP-01 Challenges sind einfacher (sie erfordern nur HTTP-Erreichbarkeit) und decken Zertifikate pro Hostname ab. Wir nutzen HTTP-01 für jede Custom Domain.
Die Zertifizierungsstelle ist Let's Encrypt. Deren Rate-Limits sind die wichtigste operative Einschränkung: 50 Zertifikate pro registrierter Domain pro Woche. Dabei ist die „registrierte Domain“ die eTLD+1 (der Teil direkt über dem Public Suffix - also example.com für links.example.com). Erneuerungen identischer Zertifikate zählen nicht gegen dieses Limit, jede neue Domain hingegen schon.
Dies hat eine wichtige Auswirkung für Multi-Tenant-Plattformen. Wenn Sie all Ihren Nutzern erlauben, eigene Domains unter *.ihrebrand.de zu erstellen, wird Ihr Budget von 50 Zertifikaten pro Woche über alle diese Subdomains von ihrebrand.de geteilt. Bei nennenswerter Skalierung erreichen Sie das Limit. Die richtige Architektur - und diejenige, die Elido für seine eigenen Tier-Subdomains nutzt - sieht vor, dass die verifizierte Custom Domain jedes Mandanten eine Subdomain seiner eigenen registrierten Domain ist (links.kunde.de), sodass das Rate-Limit pro Mandant und nicht pro Plattform gilt.
On-Demand-TLS-Ausstellung ist die Art und Weise, wie der Edge dieses Volumen bewältigt. Anstatt Zertifikate für jede verifizierte Domain vorab auszustellen, bevor Traffic eintrifft, wird das Zertifikat beim ersten Request auf diesen Hostnamen ausgestellt. Das automatische On-Demand-TLS fragt einen Upstream-Endpunkt (in unserem Fall den Domain-Validierungsdienst), ob der Hostname zulässig ist, bevor die Ausstellung versucht wird. Wenn er 200 zurückgibt (Domain ist verifiziert), fährt der Edge mit der ACME HTTP-01 Challenge fort, erhält das Zertifikat, speichert es im Cache und bedient den Request. Ist der Hostname unbekannt, gibt der Edge einen TLS-Alert zurück und die Verbindung bricht ab, bevor überhaupt ein Zertifikat angefordert wurde.
Der ACME-Flow gemäß RFC 8555:
- Der Edge fordert eine neue Order vom ACME-Server (Let's Encrypt) an.
- Let's Encrypt antwortet mit einer HTTP-01 Challenge: „Platziere ein Token unter
http://acme.example.com/.well-known/acme-challenge/<token>.“ - Der Edge platziert das Token in seinem In-Memory-HTTP-Handler und benachrichtigt Let's Encrypt.
- Let's Encrypt ruft das Token über normales HTTP (Port 80) ab, validiert es und stellt das Zertifikat aus.
- Der Edge speichert das Zertifikat in seinem Storage-Layer und bedient den ursprünglichen HTTPS-Request.
Schritte 1–5 fügen dem allerersten Request einer neu verifizierten Domain eine Latenz hinzu, typischerweise 1–3 Sekunden. Jeder nachfolgende Request greift auf ein gecachtes Zertifikat zu, ohne merklichen Overhead.
Performance: Die Mathematik des TLS-Handshakes#
Sobald das Zertifikat ausgestellt ist, bestehen die Kosten pro Request aus dem TLS-Handshake plus der Redirect-Logik.
Ein voller TLS 1.3 Handshake entspricht 1 RTT. Von einem europäischen Client zu unserem In-Region-EU-POP sind das etwa 10–20 ms, je nach Stadt. TLS 1.3 Session Resumption (Tickets oder Session-IDs) reduziert nachfolgende Verbindungen auf 0-RTT oder 0.5-RTT für die Daten - der Client kann Anwendungsdaten bereits im ersten Paket senden. Bei Kurzlinks, wo der HTTP-Request winzig ist und die Antwort ein 302 mit einem Location-Header, fühlen sich wiederaufgenommene Sessions aus Client-Sicht fast unmittelbar an.
Der Zertifikats-Algorithmus spielt eine Rolle. ECDSA P-256 Zertifikate haben eine Signatur von etwa 70 Bytes; RSA-2048 Zertifikate tragen etwa 256 Bytes Signatur plus einen wesentlich größeren Public Key. Bei einer langsamen mobilen Verbindung ist der Unterschied in Bytes vernachlässigbar, aber die CPU-Kosten für die RSA-Signaturvalidierung sind es nicht: Das Verifizieren einer RSA-2048 Signatur verbraucht etwa das 30–50-fache an CPU-Zyklen im Vergleich zu einer ECDSA P-256 Signatur bei gleichem Sicherheitsniveau. Für einen Edge-Server, der tausende gleichzeitige Verbindungen bedient, summiert sich dieser CPU-Unterschied. Elido stellt P-256 für alle Custom Domain Zertifikate aus. Cloudflares Analyse zu ECDSA vs RSA im Live-Betrieb kommt zum gleichen Ergebnis und ist lesenswert, wenn Sie Ihre eigene TLS-Terminierung verwalten.
Nach dem Handshake landet der Redirect selbst im „Hot Path“: In-Process LRU-Lookup (L1), bei Miss Fallback auf den In-Memory-Cache (L2), und als letzter Ausweg das Origin via gRPC. Bei einem L1-Cache-Treffer - was den überwältigenden Teil des Traffics ausmacht, sobald ein Link „warm“ ist - wird der Redirect in unter 10 ms in der Region (p50) aufgelöst, end-to-end am Edge, exklusive Handshake. Das 15 ms p95 Budget berücksichtigt L2-Treffer und den kleinen Teil an „kaltem“ Traffic. Lesen Sie den Deep-Dive zu Smart Links für die vollständige Cache-Architektur und die Mechanismen zur Invalidierung.
Was im Live-Betrieb schiefgeht#
Setups mit eigenen Domains scheitern auf vorhersehbare Weise. Hier sind die drei häufigsten Fälle und was jeweils zu tun ist.
DNS-Propagationsverzögerung. Sie fügen den CNAME hinzu, verifizieren ihn im Dashboard, aber der Link funktioniert für einige Nutzer immer noch nicht. Die DNS-TTL-Werte vieler von Registraren verwalteter Zonen stehen standardmäßig auf 3600 Sekunden - eine Stunde potenzieller Veraltung. Der Domain-Status im Dashboard zeigt an, ob der Domain-Validierungsdienst die korrekte DNS-Antwort aus der EU-Region sehen kann. Wenn dort „verifiziert“ steht, aber Nutzer anderswo immer noch das alte Ziel erhalten, greifen sie auf einen Resolver zu, der die vorherige Antwort noch gecacht hat. Hier gibt es keine Abkürzung; Sie müssen warten, bis die TTL abgelaufen ist. Die Lösung für das nächste Mal: Senken Sie die TTL vor der Änderung auf 300–600 Sekunden und stellen Sie sie danach wieder zurück.
Abgelaufene oder inkompatible CAA-Records. Certification Authority Authorization (CAA) Einträge teilen CAs mit, welche Stelle Zertifikate für eine Domain ausstellen darf. Wenn Ihr DNS-Admin zuvor example.com CAA 0 issue "digicert.com" hinzugefügt hat, wird Let's Encrypt die Ausstellung für links.example.com verweigern, da links.example.com die CAA-Policy des Apex erbt. Der Fehler lautet urn:ietf:params:acme:error:caa in der ACME-Antwort. Die Lösung ist, links.example.com CAA 0 issue "letsencrypt.org" hinzuzufügen (oder die Apex-Beschränkung zu entfernen, falls dies mit Ihrer Sicherheitsrichtlinie vereinbar ist). Der Status-Endpunkt des Domain-Validierungsdienstes gibt CAA-Fehler im Error-Body zurück, sodass Sie dies diagnostizieren können, ohne Edge-Logs wälzen zu müssen.
Kunde löscht den CNAME mitten in der Kampagne. Das ist der schmerzhafte Fall. Ein DNS-Admin auf Kundenseite entfernt oder ändert den CNAME - vielleicht im Zuge einer Domain-Migration oder aus Versehen - und jeder Redirect dieser Domain schlägt fehl, weil der Edge ihn nicht mehr bedienen kann. Schlimmer noch: Die TLS-Erneuerung schlägt innerhalb des nächsten 60-Tage-Fensters lautlos fehl und das Zertifikat läuft ab. Elidos Domain-Validierungsdienst führt einen periodischen DNS-Healthcheck für alle verifizierten Domains durch und markiert eine Domain als degraded, wenn der CNAME nicht mehr auf das erwartete Ziel verweist. Der Workspace-Inhaber erhält eine Benachrichtigung; es gibt eine 7-tägige Kulanzzeit, bevor die Domain auf suspended gesetzt wird. Während dieser Zeit werden Anfragen weiterhin mit dem letzten gültigen Zertifikat bedient. Die Wiederherstellung: CNAME wiederherstellen, Propagation abwarten, und der Domain-Status kehrt beim nächsten Healthcheck-Zyklus (alle 15 Minuten) automatisch auf „aktiv“ zurück.
Ein kurzer Walkthrough#
So sieht das Setup end-to-end aus, beginnend bei Null.
Schritt 1: DNS-Einträge hinzufügen. In der Verwaltungsoberfläche Ihres DNS-Anbieters:
acme.example.com CNAME b.elido.me.
_elido-verify.acme.example.com TXT "ws_01HXK4..."
Den Wert ws_01HXK4... finden Sie in Ihrem Dashboard unter Settings → Custom Domains → Add Domain.
Schritt 2: Die Domain über die API registrieren. Sie können dies auch im Dashboard tun, aber wenn Sie ein Multi-Tenant-Setup automatisieren - etwa als Agentur, die einen neuen Kunden onbordet - ist die API sauberer:
curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/domains \
-H "Authorization: Bearer $ELIDO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"hostname": "acme.example.com",
"tier": "business"
}'
Die Antwort enthält ein verification_token und den Status pending_verification. Pollen Sie GET /v1/workspaces/{id}/domains/{domain_id} oder beobachten Sie das Dashboard, bis der status auf verified wechselt.
Schritt 3: Der erste Request stellt das Zertifikat aus. Sobald die Domain verifiziert ist, triggert jeder HTTPS-Request an acme.example.com das On-Demand-TLS, falls das Zertifikat noch nicht gecacht ist. Dieser erste Aufruf kann 2–3 Sekunden dauern, während der ACME-Austausch stattfindet. Jeder weitere Request liegt bei p95 unter 15 ms.
Schritt 4: Links unter der eigenen Domain erstellen. Übergeben Sie die domain_id beim Erstellen von Links:
curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/links \
-H "Authorization: Bearer $ELIDO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"domain_id": 17,
"slug": "spring-launch",
"destination_url": "https://example.com/landing/spring"
}'
Der Link ist sofort unter https://acme.example.com/spring-launch erreichbar. Wenn Sie dieses Setup als Infrastructure-as-Code verwalten, schauen Sie sich den Beitrag zum Terraform-Provider an - elido_custom_domain ist eine Datenquelle, die Sie in elido_link Ressourcen einbinden können.
Wann man auf eine eigene Domain verzichten sollte#
Nicht jede Situation profitiert von einer eigenen Domain, und das Hinzufügen verursacht Aufwand auf beiden Seiten.
Interne Tools und Staging-Links. Wenn der Kurzlink nur von Personen innerhalb Ihres Unternehmens geklickt wird - interne Dokumentation, Verweise auf Staging-Umgebungen, in Slack geteilte Ressourcen - erzeugt eine eigene Domain nur DNS-Verwaltungsaufwand ohne Marken-Nutzen. Nutzen Sie einen Workspace auf f.elido.me oder s.elido.me und fertig.
Wegwerf-Links für Kampagnen mit 48 Stunden Laufzeit. Allein das Zeitfenster für die DNS-Propagation beträgt potenziell eine Stunde. Wenn Ihre Kampagne morgen startet und Sie den DNS-Eintrag noch nicht gesetzt haben, ist eine eigene Domain ein Risiko. Nutzen Sie eine Plattform-Subdomain, bringen Sie die Kampagne raus und setzen Sie die eigene Domain auf die Roadmap für die nächste Aktion.
Enterprise-SSO-Kunden, die der Subdomain-Delegierung noch nicht zugestimmt haben. In Unternehmen mit reifen IT-Sicherheitsstrukturen erfordert die Delegation einer Subdomain an ein Drittanbieter-SaaS eine Sicherheitsüberprüfung - manchmal sogar eine formale Risikobewertung. Diese Prüfung kann Wochen dauern. Wenn Ihr Beschaffungsprozess bereits in einer langen Warteschlange steckt, blockieren Sie den Deal nicht durch das Setup einer eigenen Domain. Starten Sie mit der Plattform-Domain und bieten Sie die Migration auf eine eigene Domain als Teil des Onboardings nach dem Kauf an. Elido unterstützt die Domain-Migration, ohne bestehende Links zu beeinträchtigen; die Lösungsseite für Agenturen bietet weitere Details zur White-Label-Konfiguration, die diesen Übergang reibungslos macht.
Eigene Domains sind in den Business- und Enterprise-Plänen verfügbar. Die Free- und Pro-Tiers nutzen von der Plattform bereitgestellte Subdomains. Wenn Sie das Feature testen möchten, erlaubt das Dashboard das Hinzufügen einer verifizierten Domain im Pro-Tarif als Testpfad - prüfen Sie die aktuellen Limits auf der Preisseite.
Die vollständige Konfigurationsanleitung, einschließlich Empfehlungen für CAA-Records, der API-Referenz für alle Domain-Endpunkte und des Schemas für DNS-Healthcheck-Antworten, finden Sie unter /docs/guides/custom-domains. Die Feature-Seite für Custom Domains deckt zudem die Integration der Apple App Site Association sowie den Universal Link / App Link Flow für mobiles Deep-Linking auf einer eigenen Domain ab.
Marius Voß ist DevRel + edge infra bei Elido. Er verantwortet den Edge-Redirect- und den Domain-Validierungsdienst.
Passende Artikel im Blog#
Elido testen
URL einfügen, kurzer Link in Sekunden
Kein Konto nötig. Link bleibt 30 Tage aktiv. Konto erstellen, um ihn dauerhaft zu behalten.
Kostenlos, keine Anmeldung erforderlich · 2 pro Tag