Liens courts à domaine personnalisé : DNS, TLS et ce qui tourne à l'edge

Un lien court brandé est, à la base, deux pièces d'infrastructure boulonnées ensemble : un enregistrement DNS qui dit à internet que votre sous-domaine vit ici, et un certificat TLS qui prouve que la connexion HTTPS est légitime. Aucun des deux n'est compliqué en isolation. La question intéressante est ce qui tourne à l'edge après que la redirection se résout - comment une plateforme qui gère les domaines personnalisés de milliers de tenants émet des certs à la demande, évite les limites de taux de Let's Encrypt, reste sous un budget de latence p95 de 15 ms, et récupère gracieusement quand l'équipe DNS d'un client annihile son CNAME en pleine campagne.

C'est de cela que parle cet article.

TL;DR#

• La vérification DNS est un challenge CNAME ou TXT ; l'émission TLS se produit via ACME à la demande, déclenchée la première fois qu'un nouveau hostname reçoit une requête.
• Let's Encrypt plafonne à 50 certificats par domaine enregistré par semaine - ce qui signifie qu'il vous faut un domaine enregistré séparé par tenant à l'échelle, pas des sous-domaines d'un seul elido.me.
• Les certificats ECDSA P-256 sont matériellement plus rapides que RSA-2048 à la couche de handshake TLS ; Elido émet du P-256 pour chaque domaine personnalisé.
• Trois choses cassent régulièrement les configurations de domaine personnalisé en production : retard de propagation DNS, enregistrements CAA expirés, et clients supprimant leur propre CNAME. Chacune a un chemin de récupération concret.

Les deux parties d'un raccourcisseur à domaine personnalisé#

Les liens courts à domaine personnalisé exigent deux choses de vous, propriétaire du domaine, et deux choses de la plateforme.

De vous : un changement DNS (un enregistrement CNAME ou ALIAS pointant votre sous-domaine vers l'edge de la plateforme) et une preuve de propriété (généralement un enregistrement DNS TXT ou un challenge CNAME qui permet à la plateforme de vérifier que vous contrôlez le domaine avant qu'elle n'accepte de le servir).

De la plateforme : une règle de routage qui reconnaît votre hostname et sait depuis quel workspace servir les liens, et un certificat TLS émis pour votre hostname pour que les navigateurs voient un cadenas vert au lieu d'un avertissement.

Elido gère les deux secondes via un service de validation de domaine, qui est responsable de la vérification DNS, de l'émission de certificats et du maintien à jour de la table de routage. Il pilote le TLS automatique à la demande et résout le mapping de workspace. Le service edge - celui avec le budget de latence inférieur à 10 ms en région - ne sait rien de l'émission de certificats ; tout cela se produit avant le chemin de requête.

Le flux de vérification est simple. Vous ajoutez un CNAME de votre sous-domaine vers b.elido.me (palier Business), puis ajoutez un enregistrement TXT comme _elido-verify.acme.example.com = "ws_abc123" pour prouver que vous possédez le domaine. Le service de validation de domaine poll l'enregistrement TXT, le confirme, marque le domaine comme vérifié, et l'enregistre pour TLS. La première requête HTTPS vers acme.example.com déclenche l'émission TLS à la demande - plus à ce sujet dans un instant.

DNS : CNAME vs ALIAS vs A#

Le type d'enregistrement DNS que vous pouvez utiliser dépend du sous-domaine que vous déléguez.

CNAME fonctionne pour tout sous-domaine non-apex. links.example.com CNAME b.elido.me. est la configuration canonique. RFC 1034 §3.6.2 interdit les enregistrements CNAME à l'apex de zone (le example.com nu) parce qu'ils entrent en conflit avec les enregistrements SOA et NS qui doivent exister là. Presque chaque registrar et fournisseur DNS l'applique.

Les enregistrements ALIAS / ANAME sont une extension non standard que plusieurs fournisseurs DNS implémentent (Route 53 ALIAS, Cloudflare CNAME flattening, DNSimple ALIAS) pour résoudre exactement le problème de l'apex. Ils se comportent comme des CNAME syntaxiquement mais résolvent vers des enregistrements A/AAAA en coulisses, donc les nameservers du fournisseur DNS aplatissent la recherche avant publication. Si vous avez absolument besoin que example.com (pas www.example.com) redirige, ALIAS est votre seule option compatible avec la spec DNS. Vérifiez la documentation de votre fournisseur DNS - ils ne sont pas interopérables, et le nom de la fonctionnalité varie.

Un enregistrement A pointant directement vers une IP Elido est un dernier recours. Les IP peuvent changer quand nous ajoutons un POP ou ré-adressons un cluster edge, et nous ne considérons pas les IP edge comme une surface d'API stable. Si vous êtes sur un enregistrement A aujourd'hui, passez à un CNAME ou ALIAS.

Une chose de plus que les opérateurs ratent : les redirections d'apex entrent souvent en collision avec le DNS d'email. Les enregistrements MX, _dmarc, _domainkey et SPF TXT vivent tous à ou sous l'apex. Un ALIAS à l'apex n'entre pas en conflit avec eux - ce sont des types d'enregistrements différents - mais certaines implémentations ALIAS de fournisseurs DNS ont des restrictions non documentées sur la coexistence d'enregistrements à l'apex. Testez ceci avant de le mettre devant une campagne.

TLS : ACME, limites de taux et le pattern d'émission à la demande#

Chaque domaine personnalisé obtient son propre certificat. Nous n'utilisons pas de certificats wildcard pour les domaines de tenants parce qu'ils exigent un challenge DNS-01 selon RFC 8555 §8.4, ce qui signifie que nous devrions contrôler la zone DNS de chaque domaine de tenant - et nous ne le faisons pas. Les challenges HTTP-01 sont plus simples (ils n'exigent que l'accessibilité HTTP) et couvrent les certificats par hostname. Nous utilisons HTTP-01 pour chaque domaine personnalisé.

L'autorité de certification est Let's Encrypt. Leurs limites de taux sont la contrainte opérationnelle principale que vous devez comprendre : 50 certificats par domaine enregistré par semaine, où « domaine enregistré » est le eTLD+1 (la partie juste au-dessus du suffixe public - example.com pour links.example.com). Les renouvellements de certificat dupliqués ne comptent pas dans cette limite, mais chaque nouveau domaine compte.

Cela a une implication importante pour les plateformes multi-tenants. Si vous laissez tous vos utilisateurs créer des domaines personnalisés sous *.yourbrand.com, votre budget de 50 certs par semaine est partagé à travers tous ces sous-domaines de yourbrand.com. À toute échelle significative, vous atteignez le plafond. L'architecture correcte - et celle qu'Elido utilise pour ses propres sous-domaines de palier - est que le domaine personnalisé vérifié de chaque tenant soit un sous-domaine de leur propre domaine enregistré (links.example.com), pour que la limite de taux s'applique par tenant, pas par plateforme.

L'émission TLS à la demande est comment l'edge gère le volume. Plutôt que de pré-émettre des certificats pour chaque domaine vérifié avant qu'aucun trafic n'arrive, le certificat est émis à la première requête vers ce hostname. Le TLS automatique à la demande demande à un endpoint amont (dans notre cas, le service de validation de domaine) si le hostname est autorisé avant de tenter l'émission. S'il retourne 200 (le domaine est vérifié), l'edge procède avec le challenge ACME HTTP-01, obtient le certificat, le met en cache, et sert la requête. Si le hostname est inconnu, l'edge retourne une alerte TLS et la connexion échoue avant qu'aucun certificat ne soit jamais demandé.

Le flux ACME selon RFC 8555 :

1. L'edge demande une nouvelle commande au serveur ACME (Let's Encrypt).
2. Let's Encrypt répond avec un challenge HTTP-01 : « placez un token à http://acme.example.com/.well-known/acme-challenge/<token>. »
3. L'edge place le token dans son gestionnaire HTTP en mémoire et notifie Let's Encrypt.
4. Let's Encrypt récupère le token via HTTP en clair (port 80), le valide et émet le certificat.
5. L'edge stocke le certificat dans sa couche de stockage et sert la requête HTTPS originale.

Les étapes 1 à 5 ajoutent de la latence à la toute première requête d'un domaine nouvellement vérifié, typiquement 1 à 3 secondes. Chaque requête suivante touche un certificat en cache sans surcoût observable.

Performance : maths du handshake TLS#

Une fois le certificat émis, le coût par requête est le handshake TLS plus la logique de redirection.

Un handshake TLS 1.3 complet est 1 RTT. D'un client européen vers notre POP UE en région, c'est environ 10 à 20 ms selon la ville. La reprise de session TLS 1.3 (tickets ou identifiants de session) ramène les connexions suivantes à 0-RTT ou 0,5-RTT pour les données - le client peut envoyer des données applicatives dans le premier flight. Pour les liens courts, où la requête HTTP est minuscule et la réponse est une 302 avec un en-tête Location, les sessions reprises semblent quasi instantanées du point de vue du client.

L'algorithme de certificat compte. Les certificats ECDSA P-256 ont une signature d'environ 70 octets ; les certificats RSA-2048 portent environ 256 octets de signature plus une clé publique beaucoup plus grosse. Sur une connexion mobile lente, la différence en octets est négligeable, mais le coût CPU de la vérification de signature RSA ne l'est pas : vérifier une signature RSA-2048 prend environ 30 à 50× les cycles CPU de la vérification d'une signature ECDSA P-256 à niveau de sécurité équivalent. Pour un edge servant des milliers de connexions concurrentes, cette différence CPU s'accumule. Elido émet du P-256 pour tous les certificats de domaine personnalisé. L'analyse de Cloudflare sur ECDSA vs RSA en production atteint la même conclusion et vaut la lecture si vous gérez votre propre terminaison TLS.

Après le handshake, la redirection elle-même atterrit sur le chemin chaud : recherche LRU en process (L1), retombée vers le cache en mémoire (L2) si non trouvé, retombée vers l'origine sur gRPC en dernier recours. Sur un cache hit L1 - qui représente l'écrasante majorité du trafic une fois qu'un lien est chaud - la redirection se résout en moins de 10 ms en région (p50), de bout en bout à l'edge, excluant le handshake. Le budget p95 de 15 ms accommode les hits L2 et la petite fraction de trafic froid. Voir le deep-dive smart links pour l'architecture complète du cache et la mécanique d'invalidation.

Ce qui casse en production#

Les configurations de domaine personnalisé échouent de manières prévisibles. Voici les trois que nous voyons le plus souvent et quoi faire pour chacune.

Retard de propagation DNS. Vous ajoutez le CNAME, vérifiez dans le tableau de bord, et le lien ne se résout toujours pas pour certains utilisateurs. Les valeurs TTL DNS pour beaucoup de zones gérées par registrar par défaut à 3600 secondes - une heure de péremption potentielle. Le statut de domaine du tableau de bord reflète si le service de validation de domaine peut voir la bonne réponse DNS depuis la région UE. S'il affiche « verified » mais les utilisateurs ailleurs reçoivent toujours l'ancienne destination, ils tapent un resolver qui a mis en cache la réponse précédente. Il n'y a pas de raccourci ; vous attendez que le TTL se vide. Le remède pour la prochaine fois est d'abaisser le TTL à 300-600 secondes avant de faire le changement, puis de le restaurer ensuite.

Enregistrements CAA expirés ou non concordants. Les enregistrements Certification Authority Authorization (CAA) disent aux CA laquelle est autorisée à émettre des certificats pour un domaine. Si votre admin DNS a précédemment ajouté example.com CAA 0 issue "digicert.com", Let's Encrypt refusera d'émettre un certificat pour links.example.com parce que links.example.com hérite de la politique CAA de l'apex. L'erreur est urn:ietf:params:acme:error:caa dans la réponse ACME ; le remède est d'ajouter links.example.com CAA 0 issue "letsencrypt.org" (ou supprimer la restriction CAA de l'apex si c'est approprié pour votre politique de sécurité). L'endpoint de statut du service de validation de domaine retourne les erreurs CAA dans son corps d'erreur pour que vous puissiez diagnostiquer ceci sans fouiller dans les logs de l'edge.

Le client supprime le CNAME en pleine campagne. Celui-ci est le douloureux. Un admin DNS côté client supprime ou change le CNAME - peut-être dans le cadre d'une migration de domaine, peut-être par accident - et chaque redirection depuis ce domaine personnalisé commence à échouer parce que l'edge ne peut plus le servir, ou pire, le renouvellement de certificat TLS échoue silencieusement sur la fenêtre de renouvellement de 60 jours suivante et le certificat expire. Le service de validation de domaine d'Elido fait tourner un check de santé DNS périodique sur tous les domaines vérifiés et marque un domaine comme degraded quand le CNAME ne se résout plus vers la cible attendue. Le propriétaire du workspace reçoit une notification ; il y a un délai de grâce de 7 jours avant que le domaine ne soit déplacé vers suspended. Pendant le délai de grâce, les requêtes continuent à être servies depuis le dernier cert valide. La récupération est : restaurer le CNAME, attendre la propagation, et le statut du domaine retourne à actif automatiquement au cycle suivant du check de santé (toutes les 15 minutes).

Une courte démarche#

Voici à quoi ressemble la configuration de bout en bout, en partant d'une page blanche.

Étape 1 : ajouter les enregistrements DNS. Dans le panneau de contrôle de votre fournisseur DNS :

acme.example.com   CNAME   b.elido.me.
_elido-verify.acme.example.com   TXT   "ws_01HXK4..."

La valeur ws_01HXK4... est votre token de vérification de workspace, affiché dans le tableau de bord sous Settings → Custom Domains → Add Domain.

Étape 2 : enregistrer le domaine via l'API. Vous pouvez aussi faire ceci dans le tableau de bord, mais si vous automatisez une configuration multi-tenants - disons, une agence onboardant un nouveau client - l'API est plus propre :

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"
  }'

La réponse inclut un verification_token et un status de pending_verification. Poll GET /v1/workspaces/{id}/domains/{domain_id} ou regardez le tableau de bord jusqu'à ce que status passe à verified.

Étape 3 : la première requête émet le cert. Une fois vérifié, toute requête HTTPS vers acme.example.com déclenchera le TLS à la demande si le cert n'est pas déjà en cache. Cette première requête peut prendre 2-3 secondes pendant que l'échange ACME se complète. Chaque requête suivante est sub-15ms à p95.

Étape 4 : créer des liens sous le domaine personnalisé. Passez domain_id lors de la création de liens :

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"
  }'

Le lien se résout à https://acme.example.com/spring-launch immédiatement. Si vous gérez cette configuration comme infrastructure-as-code, voir l'article sur le provider Terraform - elido_custom_domain est une source de données que vous pouvez chaîner dans des ressources elido_link.

Quand ne pas utiliser un domaine personnalisé#

Toutes les situations ne bénéficient pas d'un domaine personnalisé, et en ajouter un a un coût de configuration des deux côtés.

Outillage interne et liens de staging. Si le lien court n'est jamais cliqué que par des gens à l'intérieur de votre entreprise - docs internes, pointeurs d'environnement staging, ressources partagées via Slack - un domaine personnalisé ajoute du surcoût de gestion DNS pour zéro bénéfice de marque. Utilisez un workspace sur f.elido.me ou s.elido.me et passez à autre chose.

Liens de campagne jetables avec une durée de vie de 48 heures. La fenêtre de propagation DNS à elle seule est potentiellement d'une heure. Si votre campagne se lance demain et que vous n'avez pas encore l'enregistrement DNS en place, un domaine personnalisé est une responsabilité. Utilisez un sous-domaine de plateforme, sortez la campagne, et ajoutez le domaine personnalisé à la roadmap pour la suivante.

Acheteurs enterprise SSO qui n'ont pas approuvé la délégation de sous-domaine. Dans les entreprises avec des postures de sécurité IT matures, la délégation de sous-domaine à un SaaS tiers exige une revue de sécurité - parfois une évaluation formelle de risque. La revue peut prendre des semaines. Si votre motion d'achat est déjà dans une longue file d'approbation, ne bloquez pas la transaction sur la configuration de domaine personnalisé. Commencez avec le domaine de plateforme ; offrez de migrer vers un domaine personnalisé dans le cadre de l'onboarding post-vente. Elido supporte la migration de domaine sans casser les liens existants, et la page solutions pour agences a plus sur la configuration white-label qui rend cette transition propre.

Les domaines personnalisés sont disponibles sur les forfaits Business et Enterprise. Les paliers Free et Pro utilisent des sous-domaines fournis par la plateforme. Si vous évaluez la fonctionnalité, le tableau de bord vous laisse ajouter un domaine vérifié sur Pro comme chemin d'essai - vérifiez la comparaison de forfait actuelle sur la page de tarification pour la limite exacte.

Le guide complet de configuration, y compris les recommandations d'enregistrement CAA, la référence API pour tous les endpoints de domaine, et le schéma de réponse du check de santé de domaine, est à /docs/guides/custom-domains. La page de fonctionnalité custom domains couvre l'intégration Apple App Site Association et le flux Universal Link / App Link pour le deep-linking mobile sur un domaine personnalisé.

Marius Voß est DevRel + edge infra chez Elido. Il possède les services de redirection edge et de validation de domaine.

En lien sur le blog#

• Atteindre p95 < 15ms pour les redirections depuis FRA, ASH et SGP
• Configurer des liens courts brandés : choisir un domaine, livrer en un après-midi
• Deep links pour applications mobiles sans SDK
• Résidence des données UE pour les outils marketing : ce que votre DPO demande vraiment