Un enlace corto de marca es, en esencia, dos piezas de infraestructura unidas: un registro DNS que le dice a internet que tu subdominio vive aquí, y un certificado TLS que prueba que la conexión HTTPS es legítima. Ninguna de esas es complicada en aislamiento. La pregunta interesante es qué se ejecuta en el edge después de que la redirección se resuelve - cómo una plataforma que maneja dominios personalizados de miles de tenants emite certificados bajo demanda, evita los límites de tasa de Let's Encrypt, se mantiene bajo un presupuesto de latencia p95 de 15ms y se recupera con gracia cuando el equipo de DNS de un cliente destruye su CNAME a mitad de campaña.
De eso trata este post.
TL;DR#
- La verificación DNS es un desafío CNAME o TXT; la emisión TLS sucede vía ACME bajo demanda, activada la primera vez que un nuevo hostname recibe una petición.
- Let's Encrypt limita a 50 certificados por dominio registrado por semana - lo que significa que necesitas un dominio registrado separado por tenant a escala, no subdominios de un solo
elido.me. - Los certificados ECDSA P-256 son materialmente más rápidos que RSA-2048 en la capa de handshake TLS; Elido emite P-256 para cada dominio personalizado.
- Tres cosas rompen rutinariamente las configuraciones de dominio personalizado en producción: retraso de propagación DNS, registros CAA expirados y clientes eliminando su propio CNAME. Cada uno tiene una ruta de recuperación concreta.
Las dos partes de un acortador con dominio personalizado#
Los enlaces cortos con dominio personalizado requieren dos cosas de ti, el propietario del dominio, y dos cosas de la plataforma.
De ti: un cambio DNS (un registro CNAME o ALIAS apuntando tu subdominio al edge de la plataforma) y una prueba de propiedad (generalmente un registro TXT DNS o un desafío CNAME que permite a la plataforma verificar que controlas el dominio antes de acceder a servirlo).
De la plataforma: una regla de enrutamiento que reconoce tu hostname y sabe desde qué workspace servir enlaces, y un certificado TLS emitido a tu hostname para que los navegadores vean un candado verde en lugar de una advertencia.
Elido maneja las segundas dos a través de un servicio de validación de dominios, que es responsable de la verificación DNS, la emisión de certificados y mantener la tabla de enrutamiento actualizada. Gestiona el TLS automático bajo demanda y resuelve el mapeo de workspace. Nuestro servicio de edge - el del presupuesto de latencia de menos de 10 ms en la región - no sabe nada sobre la emisión de certificados; todo eso sucede antes de la ruta de la petición.
El flujo de verificación es directo. Añades un CNAME desde tu subdominio a b.elido.me (nivel Business), luego añades un registro TXT como _elido-verify.acme.example.com = "ws_abc123" para probar que posees el dominio. El servicio de validación de dominios sondea el registro TXT, lo confirma, marca el dominio como verificado y lo registra para TLS. La primera petición HTTPS a acme.example.com activa la emisión TLS bajo demanda - más sobre eso en un momento.
DNS: CNAME vs ALIAS vs A#
El tipo de registro DNS que puedes usar depende de qué subdominio estás delegando.
CNAME funciona para cualquier subdominio no ápex. links.example.com CNAME b.elido.me. es la configuración canónica. RFC 1034 §3.6.2 prohíbe los registros CNAME en el ápex de zona (el example.com desnudo) porque entran en conflicto con los registros SOA y NS que deben existir ahí. Casi todos los registradores y proveedores DNS lo aplican.
Los registros ALIAS / ANAME son una extensión no estándar que varios proveedores DNS implementan (Route 53 ALIAS, CNAME flattening de Cloudflare, DNSimple ALIAS) para resolver exactamente el problema del ápex. Se comportan como CNAMEs sintácticamente pero resuelven a registros A/AAAA detrás de escena, por lo que los servidores de nombres del proveedor DNS aplanan la búsqueda antes de publicarla. Si necesitas absolutamente que example.com (no www.example.com) redirija, ALIAS es tu única opción compatible con la especificación DNS. Revisa la documentación de tu proveedor DNS - no son interoperables, y el nombre de la característica varía.
Un registro A apuntando directamente a una IP de Elido es un último recurso. Las IPs pueden cambiar cuando añadimos un POP o re-direccionamos un clúster del edge, y no consideramos las IPs del edge como una superficie de API estable. Si estás en un registro A hoy, muévete a un CNAME o ALIAS.
Una cosa más que los operadores pierden: las redirecciones del ápex a menudo chocan con DNS de email. MX, _dmarc, _domainkey y los registros TXT SPF todos viven en o bajo el ápex. Un ALIAS en el ápex no entra en conflicto con ellos - son tipos de registro diferentes - pero algunas implementaciones de ALIAS de proveedores DNS tienen restricciones no documentadas sobre la coexistencia de registros del ápex. Prueba esto antes de ponerlo delante de una campaña.
TLS: ACME, límites de tasa y el patrón de emisión bajo demanda#
Cada dominio personalizado obtiene su propio certificado. No usamos certificados comodín para dominios de tenant porque requieren un desafío DNS-01 según RFC 8555 §8.4, lo que significa que necesitaríamos controlar la zona DNS de cada dominio de tenant - y no la controlamos. Los desafíos HTTP-01 son más simples (solo requieren accesibilidad HTTP) y cubren certificados por hostname. Usamos HTTP-01 para cada dominio personalizado.
La autoridad de certificación es Let's Encrypt. Sus límites de tasa son la principal restricción operativa que necesitas entender: 50 certificados por dominio registrado por semana, donde "dominio registrado" es el eTLD+1 (la parte justo encima del sufijo público - example.com para links.example.com). Las renovaciones de certificados duplicados no cuentan hacia este límite, pero cada nuevo dominio sí.
Esto tiene una implicación importante para plataformas multi-tenant. Si dejas que todos tus usuarios creen dominios personalizados bajo *.yourbrand.com, tu presupuesto de 50 certificados por semana se comparte entre todos esos subdominios de yourbrand.com. A cualquier escala significativa alcanzas el límite. La arquitectura correcta - y la que usa Elido para sus propios subdominios de nivel - es que el dominio personalizado verificado de cada tenant sea un subdominio de su propio dominio registrado (links.example.com), por lo que el límite de tasa se aplica por tenant, no por plataforma.
La emisión TLS bajo demanda es cómo el edge maneja el volumen. En lugar de pre-emitir certificados para cada dominio verificado antes de que llegue cualquier tráfico, el certificado se emite en la primera petición a ese hostname. El TLS automático bajo demanda pregunta a un endpoint upstream (en nuestro caso, el servicio de validación de dominios) si el hostname está permitido antes de intentar la emisión. Si devuelve 200 (el dominio está verificado), el edge procede con el desafío HTTP-01 de ACME, obtiene el cert, lo cachea y sirve la petición. Si el hostname es desconocido, el edge devuelve una alerta TLS y la conexión falla antes de que se solicite un cert.
El flujo ACME según RFC 8555:
- El edge solicita una nueva orden al servidor ACME (Let's Encrypt).
- Let's Encrypt responde con un desafío HTTP-01: "coloca un token en
http://acme.example.com/.well-known/acme-challenge/<token>." - El edge coloca el token en su manejador HTTP en memoria y notifica a Let's Encrypt.
- Let's Encrypt obtiene el token sobre HTTP plano (puerto 80), lo valida y emite el certificado.
- El edge almacena el certificado en su capa de almacenamiento y sirve la petición HTTPS original.
Los pasos 1-5 añaden latencia a la primera petición desde un dominio recién verificado, típicamente 1-3 segundos. Cada petición posterior alcanza un certificado en caché sin sobrecarga observable.
Rendimiento: matemática del handshake TLS#
Una vez que el certificado se emite, el costo por petición es el handshake TLS más la lógica de redirección.
Un handshake TLS 1.3 completo es 1 RTT. Desde un cliente europeo a nuestro POP en la región de la UE, eso es aproximadamente 10-20ms dependiendo de la ciudad. La reanudación de sesión TLS 1.3 (tickets o IDs de sesión) lleva las conexiones posteriores a 0-RTT o 0.5-RTT para datos - el cliente puede enviar datos de aplicación en el primer flight. Para enlaces cortos, donde la petición HTTP es minúscula y la respuesta es un 302 con una cabecera Location, las sesiones reanudadas se sienten casi instantáneas desde la perspectiva del cliente.
El algoritmo del certificado importa. Los certificados ECDSA P-256 tienen una firma que es aproximadamente 70 bytes; los certificados RSA-2048 llevan aproximadamente 256 bytes de firma más una clave pública mucho más grande. En una conexión móvil lenta la diferencia en bytes es insignificante, pero el costo de CPU de la verificación de firma RSA no lo es: verificar una firma RSA-2048 toma aproximadamente 30-50× los ciclos de CPU de verificar una firma ECDSA P-256 a nivel de seguridad equivalente. Para un edge sirviendo miles de conexiones concurrentes, esa diferencia de CPU se acumula. Elido emite P-256 para todos los certificados de dominio personalizado. El análisis de Cloudflare de ECDSA vs RSA en producción llega a la misma conclusión y vale la pena leerlo si gestionas tu propia terminación TLS.
Después del handshake, la redirección en sí aterriza en la ruta caliente: búsqueda LRU en proceso (L1), cae a la caché en memoria (L2) si no se encuentra, cae al origen sobre gRPC como último recurso. En un hit de caché L1 - que representa la abrumadora mayoría del tráfico una vez que un enlace está caliente - la redirección se resuelve en menos de 10 ms en la región (p50), de extremo a extremo en el edge, excluyendo el handshake. El presupuesto de p95 de 15ms acomoda los hits L2 y la pequeña fracción de tráfico frío. Ver el análisis profundo de enlaces inteligentes para la arquitectura completa de caché y la mecánica de invalidación.
Qué se rompe en producción#
Las configuraciones de dominio personalizado fallan de maneras predecibles. Aquí están las tres que vemos más a menudo y qué hacer sobre cada una.
Retraso de propagación DNS. Añades el CNAME, verificas en el panel, y el enlace aún no resuelve para algunos usuarios. Los valores TTL de DNS para muchas zonas gestionadas por registradores predeterminan a 3600 segundos - una hora de potencial obsolescencia. El estado del dominio del panel refleja si el servicio de validación de dominios puede ver la respuesta DNS correcta desde la región de la UE. Si muestra "verificado" pero los usuarios en otros lugares aún obtienen el destino antiguo, están alcanzando un resolvedor que ha cacheado la respuesta anterior. No hay atajo; esperas a que el TTL se agote. La solución para la próxima vez es bajar el TTL a 300-600 segundos antes de hacer el cambio, luego restaurarlo después.
Registros CAA expirados o desemparejados. Los registros Certification Authority Authorization (CAA) le dicen a las CAs cuál está permitida para emitir certificados para un dominio. Si tu admin DNS previamente añadió example.com CAA 0 issue "digicert.com", Let's Encrypt se negará a emitir un certificado para links.example.com porque links.example.com hereda la política CAA del ápex. El error es urn:ietf:params:acme:error:caa en la respuesta ACME; la solución es añadir links.example.com CAA 0 issue "letsencrypt.org" (o eliminar la restricción CAA del ápex si eso es apropiado para tu política de seguridad). El endpoint de estado del servicio de validación de dominios devuelve errores CAA en su cuerpo de error para que puedas diagnosticar esto sin escarbar en los logs del edge.
El cliente elimina el CNAME a mitad de campaña. Este es el doloroso. Un admin DNS del lado del cliente elimina o cambia el CNAME - tal vez como parte de una migración de dominio, tal vez accidentalmente - y cada redirección desde ese dominio personalizado empieza a fallar porque el edge ya no puede servirlo, o peor, la renovación del cert TLS falla silenciosamente durante los próximos 60 días de ventana de renovación y el cert expira. El servicio de validación de dominios de Elido ejecuta una comprobación periódica de salud DNS en todos los dominios verificados y marca un dominio como degraded cuando el CNAME ya no resuelve al objetivo esperado. El propietario del workspace recibe una notificación; hay un período de gracia de 7 días antes de que el dominio sea movido a suspended. Durante el período de gracia, las peticiones continúan sirviéndose desde el último cert válido. La recuperación es: restaurar el CNAME, esperar la propagación, y el estado del dominio vuelve a activo automáticamente en el siguiente ciclo de comprobación de salud (se ejecuta cada 15 minutos).
Un breve recorrido#
Aquí está cómo se ve la configuración de extremo a extremo, comenzando desde una pizarra en blanco.
Paso 1: Añade los registros DNS. En el panel de control de tu proveedor DNS:
acme.example.com CNAME b.elido.me.
_elido-verify.acme.example.com TXT "ws_01HXK4..."
El valor ws_01HXK4... es tu token de verificación de workspace, mostrado en el panel bajo Settings → Custom Domains → Add Domain.
Paso 2: Registra el dominio con la API. También puedes hacer esto en el panel, pero si estás automatizando una configuración multi-tenant - digamos, una agencia incorporando un nuevo cliente - la API es más limpia:
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 respuesta incluye un verification_token y un status de pending_verification. Sondea GET /v1/workspaces/{id}/domains/{domain_id} o observa el panel hasta que status transicione a verified.
Paso 3: La primera petición emite el cert. Una vez verificado, cualquier petición HTTPS a acme.example.com activará TLS bajo demanda si el cert no está ya cacheado. Esa primera petición puede tardar 2-3 segundos mientras el intercambio ACME se completa. Cada petición posterior es sub-15ms en p95.
Paso 4: Crea enlaces bajo el dominio personalizado. Pasa domain_id al crear enlaces:
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"
}'
El enlace resuelve en https://acme.example.com/spring-launch inmediatamente. Si estás gestionando esta configuración como infraestructura como código, ver el post del provider de Terraform - elido_custom_domain es una fuente de datos que puedes encadenar a recursos elido_link.
Cuándo no usar un dominio personalizado#
No toda situación se beneficia de un dominio personalizado, y añadir uno tiene costo de configuración en ambos lados.
Herramientas internas y enlaces de staging. Si el enlace corto solo es clicado por personas dentro de tu empresa - documentos internos, punteros de entorno de staging, recursos compartidos en Slack - un dominio personalizado añade sobrecarga de gestión DNS por cero beneficio de marca. Usa un workspace en f.elido.me o s.elido.me y sigue adelante.
Enlaces de campaña desechables con vida útil de 48 horas. La ventana de propagación DNS por sí sola es potencialmente una hora. Si tu campaña se lanza mañana y aún no tienes el registro DNS en su lugar, un dominio personalizado es un pasivo. Usa un subdominio de la plataforma, saca la campaña y añade el dominio personalizado a la hoja de ruta para la próxima.
Compradores empresariales SSO que no han aprobado la delegación de subdominio. En empresas con posturas maduras de seguridad de TI, la delegación de subdominio a un SaaS de terceros requiere revisión de seguridad - a veces una evaluación formal de riesgo. La revisión puede tardar semanas. Si tu motion de compras ya está en una cola larga de aprobación, no bloquees el trato en la configuración de dominio personalizado. Comienza con el dominio de la plataforma; ofrece migrar a un dominio personalizado como parte de la incorporación post-venta. Elido soporta migración de dominio sin romper enlaces existentes, y la página de soluciones para agencias tiene más sobre la configuración de marca blanca que hace esta transición limpia.
Los dominios personalizados están disponibles en planes Business y Enterprise. Los niveles Free y Pro usan subdominios proporcionados por la plataforma. Si estás evaluando la característica, el panel te permite añadir un dominio verificado en Pro como ruta de prueba - revisa la comparación actual de planes en la página de precios para el límite exacto.
La guía completa de configuración, incluyendo recomendaciones de registros CAA, referencia de API para todos los endpoints de dominio, y el esquema de respuesta de comprobación de salud del dominio, está en /docs/guides/custom-domains. La página de la característica de dominios personalizados cubre la integración de Apple App Site Association y el flujo Universal Link / App Link para deep-linking móvil en un dominio personalizado.
Marius Voß es DevRel + edge infra en Elido. Posee los servicios de edge redirect y de validación de dominios.
Relacionados en el blog#
Prueba Elido
Pega una URL, obtén un enlace corto
Sin registro. El enlace vive 30 días. Crea una cuenta para conservarlo.
Gratis, sin registro · 2 por día