Por qué un dominio personalizado no empieza a enrutar hasta que demuestras que es tuyo
El secuestro de subdominio es una de esas clases de vulnerabilidad que suena rebuscada hasta que la has visto pasar una vez: un equipo apunta status.example.com a un servicio de terceros, deja de usar ese servicio, se olvida de quitar el registro DNS, y meses después alguien más reclama ese mismo espacio de servicio y ahora controla lo que sirve status.example.com —con certificado válido incluido, para quien lo visite. Es una clase de bug bien documentada precisamente porque el modo de falla es tan fácil de crear por accidente y tan fácil de pasar por alto hasta que se explota.
Dónde está realmente la protección por defecto
Cada app arranca con una URL funcional y con certificado, sin nada que configurar: https://<name>.<server-ip>.sslip.io —un truco de DNS gratuito (sslip.io resuelve según la IP incrustada en el propio hostname) que no necesita ningún registro DNS propio, así que no hay nada que configurar mal el primer día.
Agregar un dominio personalizado real es donde suele vivir el riesgo de secuestro, y es donde ocurre la comprobación real: junto al registro DNS que agregas (un registro A a la IP del servidor, o CNAME para un subdominio), se solicita un segundo registro TXT —_railyard-verify.<domain> → railyard-verify=<token>. Se revisa automáticamente cada 30 segundos, o a demanda con Check now. El certificado y el enrutamiento no arrancan hasta que ese registro TXT se encuentra de verdad. Alguien que apunta un dominio que no controla a una app —la mecánica exacta detrás de un secuestro— simplemente nunca pasa de “no verificado”, porque no puede producir un token que nunca le dieron.
Los estados que hacen esto legible, no solo exigido
Un dominio muestra uno de cinco estados, y cada uno responde honestamente una pregunta distinta en vez de meter todo en un “pendiente” genérico: no verificado (el registro TXT todavía no se encontró), pendiente (propiedad confirmada, certificado aún no emitido), en línea (sirviendo tráfico de verdad), sin enrutar (verificado, pero la app no se ha redesplegado desde que se agregó —un redespliegue es lo que realmente lo enruta), o mal configurado (la emisión del certificado falló, y Check now muestra por qué). Saber en cuál de estos está un dominio es la diferencia entre “probablemente está bien” y saber realmente qué queda por hacer.
Los wildcards reciben la misma comprobación, a mayor escala
Agregar *.example.com enruta todos los subdominios a la app de una sola vez en vez de agregarlos uno por uno a mano —genuinamente útil para un producto multi-tenant que le da a cada cliente su propio subdominio. La comprobación de propiedad escala con él: sondea railyard-check.example.com en vez de cada subdominio posible, así que el wildcard no se puede reclamar sin controlar la zona real. Por defecto, cada subdominio recibe su propio certificado la primera vez que se visita; agregar una credencial DNS consigue en cambio un solo certificado que cubre todo el wildcard, una contrapartida entre complejidad de configuración y cantidad de certificados que vale la pena elegir a propósito y no por defecto.
El par www/dominio desnudo, manejado juntos
Marca Also add the www/bare-domain version y ambos se agregan y verifican juntos, redirigiendo hacia el que más tarde marques como principal —un detalle que importa porque la mitad de este par que alguien olvida suele ser justo la que termina sin monitorear y, con el tiempo, la que de verdad termina siendo blanco de un secuestro.
Referencia completa: Dominios y HTTPS.