Configurar un dominio personalizado con HTTPS requiere dos registros DNS y unos tres minutos de espera por la propagación. El resto del tiempo se gasta normalmente entendiendo qué significan los registros, por qué se necesitan ambos y qué sucede después de añadirlos. Este post es la versión práctica: cinco pasos concretos, la llamada de API exacta y una explicación de la maquinaria de certificados para que sepas qué hacer cuando algo va mal.
Por qué TLS importa específicamente para enlaces cortos#
Un enlace corto sin HTTPS es un pasivo de maneras que una URL regular sin HTTPS no lo es.
La respuesta de redirección - un 301 o 302 con una cabecera Location - es el payload completo. Si la petición HTTP inicial viaja sobre HTTP plano, cualquiera en la ruta de red puede leer la URL de destino antes de que el cliente la siga. Eso significa que tu destino de campaña, tu URL de afiliado o tu enlace de herramienta interna es visible para cualquier observador de red en el primer salto. Los navegadores modernos han comenzado a mostrar advertencias de seguridad en enlaces cortos HTTP precisamente por este patrón de exposición.
Los códigos QR agravan el problema. Una persona que escanea un código en un espacio físico no tiene relación previa con la URL - el código es la señal de confianza completa. Una advertencia del navegador en la primera carga es el peor punto de fricción posible: ya has pagado la tirada de impresión, la colocación del evento o el medio OOH, y una advertencia de seguridad en el escaneo es la cosa más probable que aleje a una persona curiosa. Un certificado TLS válido bajo tu propio dominio es la señal de confianza más barata que puedes comprar para una campaña basada en QR.
En s.elido.me o b.elido.me, el certificado TLS pertenece a Elido. El candado es real, pero el dominio no es tuyo, lo que significa que la confianza de marca se acumula a la plataforma, no a ti. Un dominio personalizado bajo go.acme.com pone tu nombre en el certificado.
Más sobre los fundamentos de DNS y TLS en el post cornerstone: Enlaces cortos de dominio personalizado: DNS, TLS y qué se ejecuta en el edge.
Paso 1: Elige el hostname#
La elección más común es un subdominio corto de tu dominio principal: go.example.com, links.example.com o s.example.com. Corto es mejor - el prefijo del subdominio aparece en cada enlace que envías.
Dos restricciones que conocer antes de decidir:
Solo subdominio, a menos que tu proveedor DNS soporte registros ALIAS. RFC 1034 §3.6.2 prohíbe registros CNAME en el ápex de zona (example.com). Si quieres que el ápex desnudo redirija, tu proveedor DNS debe soportar registros ALIAS o ANAME (Route 53 ALIAS, CNAME flattening de Cloudflare, DNSimple ALIAS). Estas son extensiones no estándar que aplanan la búsqueda antes de publicarla. Revisa la documentación de tu proveedor; el nombre de la característica varía y no todos los proveedores la ofrecen.
Elige un subdominio que no uses para nada más. links.example.com redirigiendo a través de Elido no debe tener también un registro A apuntando a tu servidor web o un CNAME existente. Los registros DNS para el mismo nombre deben ser consistentes.
Para la mayoría de los equipos: go.example.com o links.example.com está bien. Elígelo, anótalo y pasa al paso 2.
Paso 2: Registra el dominio en Elido#
Abre Settings → Custom Domains → Add Domain en el panel, ingresa tu hostname y haz clic en Add. La respuesta son dos valores de registro DNS: un token de verificación y el objetivo CNAME. Usarás ambos en el paso 3.
Si estás programando esto - incorporando un nuevo workspace de cliente, ejecutándolo como parte de un pipeline de despliegue o gestionándolo con el provider de Terraform - la llamada de API es:
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": "go.example.com",
"is_wildcard": false
}'
El cuerpo de la respuesta incluye un verification_token (una cadena hex aleatoria) e instructions conteniendo los valores exactos del registro DNS:
{
"domain": {
"id": 42,
"hostname": "go.example.com",
"status": "pending_verification"
},
"instructions": {
"txt_record": "_elido-verify.go.example.com TXT \"verify=<token>\"",
"cname_record": "go.example.com CNAME edge.elido.me"
}
}
Los dominios personalizados están disponibles en planes pagos. El plan Business es el punto de entrada para dominios personalizados; las agencias que gestionan múltiples dominios de cliente bajo una organización deberían mirar el modelo de workspace en la página de soluciones para agencias.
Paso 3: Añade los dos registros DNS#
Ve al panel de control de tu proveedor DNS y añade ambos registros desde el objeto instructions. Necesitas ambos - el CNAME enruta el tráfico al edge de Elido; el registro TXT prueba que posees el dominio antes de que Elido acceda a servirlo.
Para un subdominio regular:
go.example.com CNAME edge.elido.me.
_elido-verify.go.example.com TXT "verify=<your-token>"
Para un dominio comodín (plan Business, cubre *.go.example.com):
*.go.example.com CNAME edge.elido.me.
_elido-verify.go.example.com TXT "verify=<your-token>"
El prefijo _elido-verify es una convención estándar de desafío DNS - pone la prueba de propiedad en un subdominio del hostname siendo verificado, así que el registro TXT no puede colisionar con el CNAME.
Algunas notas específicas del proveedor:
- Cloudflare: Añade ambos registros. Deja el interruptor de proxy CNAME en off (nube gris, solo DNS). El proxy HTTP de Cloudflare elimina el hostname original antes de que llegue al edge de Elido, lo que rompe la comprobación de autorización
CaddyAsk. El modo solo DNS pasa la petición sin modificar. - AWS Route 53: Usa un registro ALIAS si necesitas el ápex; para subdominios un CNAME plano es correcto. Route 53 no soporta CNAME en el ápex de zona pero sí soporta ALIAS a objetivos externos.
- GoDaddy / Namecheap / la mayoría de DNS de registrador: CNAME y TXT estándar - sin configuración especial.
Establece el TTL de ambos registros a 300 segundos (5 minutos) si tu proveedor lo permite. El TTL por defecto para muchas zonas gestionadas es 3600 segundos; un TTL más corto significa confirmación de propagación más rápida y recuperación más rápida si necesitas cambiar los registros más tarde.
Paso 4: Espera la verificación#
Una vez que los registros estén en su lugar, domain-manager los sondea automáticamente usando el resolvedor público de Google (8.8.8.8) en un intervalo corto. No necesitas hacer clic en "Verificar ahora".
El servicio comprueba dos condiciones antes de marcar el dominio como activo:
_elido-verify.go.example.comdevuelve un registro TXT cuyo valor esverify=<token>- esto confirma que controlas la zona DNS.go.example.comresuelve vía CNAME aedge.elido.me- esto confirma que el tráfico llegará al edge de Elido.
Cuando ambas comprobaciones pasan, status se mueve de pending_verification a verified. Puedes sondear esto tú mismo:
curl https://api.elido.app/v1/workspaces/{workspace_id}/domains/42 \
-H "Authorization: Bearer $ELIDO_API_TOKEN"
Observa el campo status. El tiempo de propagación típico para registros establecidos con un TTL de 300s es bajo 5 minutos. Los registros con el TTL por defecto de 3600s pueden tardar hasta una hora si estás en una parte del mundo donde los resolvedores son agresivos sobre el caché.
Si la verificación se estanca, comprueba que tus registros se publican correctamente:
dig TXT _elido-verify.go.example.com +short
dig CNAME go.example.com +short
La búsqueda TXT debería devolver "verify=<your-token>". La búsqueda CNAME debería devolver edge.elido.me. (el punto al final es normal).
Paso 5: La primera petición emite el certificado automáticamente#
Una vez que domain-manager marca el dominio como verificado y lo registra con Caddy, has terminado por tu parte. TLS sucede sin ninguna acción adicional.
El mecanismo es el TLS bajo demanda de Caddy (ADR-0012): en lugar de pre-emitir certificados para cada dominio verificado, Caddy emite el certificado en el primer handshake TLS para un nuevo hostname. Antes de intentar la emisión ACME, Caddy llama al endpoint CaddyAsk de domain-manager - un GET ?domain=go.example.com HTTP plano. Si domain-manager devuelve 200 (el dominio está en estado verificado o activo), Caddy procede. Si devuelve 404, el handshake TLS falla y nunca se solicita un certificado. Esta puerta es la última línea de defensa contra la emisión incorrecta de certificados para hostnames no reconocidos.
Cuando Caddy procede, el flujo ACME (RFC 8555) ejecuta un desafío HTTP-01:
- Caddy solicita una nueva orden a Let's Encrypt.
- Let's Encrypt responde con un token de desafío: colócalo en
http://go.example.com/.well-known/acme-challenge/<token>. - Caddy coloca el token en su manejador HTTP en memoria.
- Let's Encrypt obtiene el token sobre HTTP plano y lo valida.
- El certificado es emitido, almacenado en la caché de certificados de Caddy, y la petición HTTPS original es servida.
Los pasos 1-5 añaden aproximadamente 2-3 segundos de latencia a la primera petición a un dominio recién verificado. Cada petición posterior usa el certificado en caché sin sobrecarga. Caddy maneja la renovación automáticamente antes de la expiración.
Elido emite certificados ECDSA P-256 para todos los dominios personalizados. Las firmas P-256 son más pequeñas y rápidas de verificar que RSA-2048, lo que importa en el edge donde los handshakes TLS están en la ruta caliente.
Obstáculos comunes#
Registros CAA bloqueando Let's Encrypt. Los registros Certification Authority Authorization (CAA) especifican qué autoridades de certificación están permitidas para emitir certificados para un dominio. Si tu zona DNS tiene example.com CAA 0 issue "digicert.com", Let's Encrypt se negará a emitir un certificado para go.example.com porque hereda la política CAA del ápex. La solución: añade go.example.com CAA 0 issue "letsencrypt.org", o elimina la restricción del ápex si tu política de seguridad lo permite. El endpoint de estado de domain-manager devuelve errores CAA en su cuerpo de error.
Proxy de Cloudflare habilitado. Ver paso 3 - el CNAME debe ser solo DNS (nube gris). El modo proxy (nube naranja) reescribe el hostname en la petición, lo que causa que la autorización CaddyAsk falle.
CNAME flattening en el ápex. El CNAME flattening de Cloudflare funciona para la mayoría de los casos de uso pero tiene un efecto sutil: la respuesta DNS de los servidores de nombres de Cloudflare es un registro A (la IP resuelta), no un CNAME. La comprobación de verificación de Elido usa LookupCNAME, que tiene éxito cuando los servidores de nombres del proveedor sirven una respuesta CNAME sintetizada. Si el flattening de tu proveedor DNS sirve solo el registro A final y no CNAME, la comprobación CNAME no pasará. En la práctica, el flattening de Cloudflare incluye el CNAME en la cadena de respuesta para registros no ápex; en el ápex depende de la implementación del proveedor. Prueba con dig CNAME go.example.com desde un resolvedor estándar antes de concluir que hay un bug.
TLS comodín es HTTP-01, no DNS-01. Elido no emite certificados comodín (*.go.example.com) vía el flujo automatizado estándar - según RFC 8555 §8.4, los certificados comodín requieren un desafío DNS-01, que requiere acceso de escritura a la zona DNS. Elido no controla tu zona DNS. La función de dominio comodín en el plan Business significa que un CNAME cubre el enrutamiento para todos los subdominios, pero cada hostname (client1.go.example.com, client2.go.example.com) obtiene su propio certificado emitido vía HTTP-01 en la primera petición - no un certificado comodín único. El resultado operativo es el mismo: los subdominios funcionan automáticamente. El almacén de certificados crece proporcionalmente.
Eliminar el CNAME después de la verificación. Si tu equipo de DNS elimina el CNAME durante una migración o limpieza, la comprobación periódica de salud de domain-manager detectará el registro faltante y moverá el dominio a estado degraded. Recibes una notificación; hay un período de gracia antes de que el dominio sea suspendido. Restaura el CNAME y la comprobación de salud moverá el dominio de vuelta a activo automáticamente.
Cómo difiere esto de Bitly y Rebrandly#
La configuración de dominio personalizado de Bitly requiere que subas un certificado TLS o uses su flujo de cert gestionado, que implica un paso manual de solicitud de certificado en niveles de plan más antiguos. El nivel de automatización depende de tu plan de Bitly; las cuentas empresariales obtienen una ruta más gestionada.
El proceso de configuración de Rebrandly es pulido - su asistente de onboarding proporciona instrucciones CNAME específicas del proveedor y valida la propagación en el navegador. El mecanismo TLS subyacente está respaldado por CloudFront: Rebrandly usa la función de dominio personalizado de AWS CloudFront, lo que significa que la autoridad de certificación y el ciclo de vida del certificado son gestionados por ACM de Amazon. Eso funciona bien, pero significa que el tráfico de tu dominio personalizado se enruta a través de la infraestructura US-East de AWS por defecto, lo que es relevante si estás evaluando la residencia de datos de la UE (ver Elido vs Rebrandly para la comparación completa de residencia).
El enfoque de Elido - TLS bajo demanda de Caddy con una puerta de autorización domain-manager - mantiene el ciclo de vida completo del certificado internamente, funciona idénticamente para despliegues autoalojados, y no crea una dependencia de ningún CDN de terceros para la gestión de certificados. El costo de latencia de la primera petición (2-3s para el desafío ACME) es la compensación; las peticiones posteriores no llevan sobrecarga.
Una vez que la verificación se completa, crea un enlace bajo tu dominio personalizado pasando domain_id en la llamada de creación de enlace - o selecciónalo desde el selector de dominio en el panel o la app móvil. El enlace está inmediatamente en vivo en https://go.example.com/<slug> con un certificado válido.
Lectura adicional: Enlaces cortos de dominio personalizado: DNS, TLS y qué se ejecuta en el edge cubre la arquitectura completa incluyendo la mecánica de caché del edge, límites de tasa y modos de fallo de producción. La guía completa de configuración de dominio incluyendo recomendaciones CAA y la referencia de API está en /docs/guides/custom-domains.
Marius Voß es DevRel + edge infra en Elido. Posee los servicios edge-redirect y domain-manager.
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