Configuración de dominio personalizado para apps web: DNS, SSL y corte

Qué cambia un dominio personalizado (y qué puede salir mal)

Un dominio personalizado es más que una URL más bonita. En el momento en que pasas de una dirección de plataforma (por ejemplo, una app que construiste en Koder.ai bajo un subdominio de la plataforma) a tu propio dominio, los navegadores y las redes lo tratan como un sitio distinto. Eso afecta el enrutamiento, la seguridad y cómo se comportan las sesiones de usuario.

Una vez que cambias a un dominio personalizado, algunas cosas cambian de inmediato:

• Enrutamiento DNS: los usuarios dejan de ir al hostname antiguo y empiezan a llegar al destino que apunte tu DNS.
• TLS/SSL: el certificado debe coincidir con el nuevo(s) hostname(s), y debe estar activo antes de que lleguen usuarios reales.
• Redirecciones: decides si los usuarios aterrizan en www o en el dominio raíz, y necesitas reglas consistentes de HTTP a HTTPS.
• Cookies y sesiones: las cookies están limitadas a un dominio. Una cookie de sesión para old-platform.example no funcionará automáticamente en app.yourdomain.com.
• Caché y propagación: los resolvers DNS y los navegadores cachean resultados, así que no todos cambian al mismo tiempo.

Las interrupciones cortas suelen venir por el tiempo. El DNS puede empezar a enviar tráfico al nuevo host antes de que el certificado SSL esté listo, lo que provoca advertencias del navegador. O al revés: el SSL está listo, pero muchos usuarios siguen golpeando el sitio antiguo porque su caché DNS no ha caducado.

Las redirecciones también pueden romper los inicios de sesión de forma sutil. Una redirección que cambia el hostname (de apex a www, o viceversa) puede hacer que se pierdan cookies si se configuraron para el otro host. Los proveedores de autenticación pueden fallar si su URL de callback sigue apuntando al dominio antiguo.

Un corte de bajo riesgo significa planear un solapamiento: mantener la URL antigua funcionando, poner el nuevo dominio en paralelo, cambiar el tráfico en un momento predecible y hacer que el rollback sea tan simple como cambiar el DNS de vuelta.

Decide tu dominio y hostnames antes de tocar DNS

Antes de cambiar nada, anota exactamente qué nombres quieres que los usuarios escriban y cuáles deberían redirigir silenciosamente. La mayoría de los problemas de “¿por qué funciona a medias?” vienen de equipos que nunca se pusieron de acuerdo en un único hostname verdadero.

Empieza con la gran decisión: apex (example.com) o www (www.example.com) como primario. Cualquiera puede funcionar, pero elige uno y trata al otro como una redirección. Esto importa después también para las cookies: las sesiones suelen ser más fáciles cuando la app vive en un host consistente.

Después, decide qué subdominios necesitas ahora y cuáles pueden esperar. Un patrón común es app.example.com para la app web y api.example.com para APIs, con admin.example.com o assets.example.com añadidos más tarde. Si estás configurando un dominio personalizado en una plataforma como Koder.ai, estas elecciones se mapean directamente a lo que validarás para SSL y a lo que apuntarás en DNS.

Conoce quién controla realmente el DNS

Mucha gente compra un dominio en un registrador, pero el DNS puede estar alojado en otro sitio. Confirma dónde se editan los registros hoy, quién tiene acceso y si alguna automatización gestiona cambios (TI de la empresa, una agencia o un proveedor de DNS gestionado). Si no puedes entrar y ver los registros actuales, detente y arregla eso primero.

También audita qué ya usa el dominio. El correo es la trampa clásica: puedes romper la entrega de emails borrando o sobrescribiendo registros.

Antes de seguir, captura estas decisiones por escrito:

• Hostname primario (apex o www) y la dirección de redirección
• Subdominios requeridos ahora (app, api, admin) vs ideas para más tarde
• Dónde se aloja el DNS y quién puede publicar cambios
• Registros críticos existentes (MX, SPF, DKIM, DMARC, TXT de verificación)
• Expectativas de cookies y autenticación (host único vs compartido entre subdominios)

Si marketing ya gestiona correo en example.com, no toques los registros de mail mientras solo añades lo que necesita la app.

Registros DNS que usarás y por qué importan

Gran parte del riesgo en una mudanza de dominio personalizado no es la app en sí. Es un cambio DNS equivocado que envía tráfico al vacío, rompe el correo o hace fallar la validación SSL.

Los registros básicos (A, CNAME y afines)

Un registro A apunta un nombre a una dirección IP. En términos sencillos: “envía a la gente a este servidor”. Es común para el apex (example.com) cuando tu proveedor te da una IP fija.

Un registro CNAME apunta un nombre a otro nombre. En términos sencillos: “trata este nombre como un alias de ese hostname”. Es común para www.example.com apuntando a un hostname de la plataforma.

Muchos proveedores DNS también ofrecen ALIAS/ANAME en el apex. Se comporta como un CNAME pero funciona para example.com. Si tu proveedor lo soporta, puede ser más fácil de gestionar porque el objetivo puede moverse sin que tengas que tocar IPs.

Un modelo mental simple:

• A: name -> IP (directo)
• CNAME: name -> name (alias)
• TXT: name -> texto (pruebas y políticas)
• MX: name -> servidores de correo (no tocar salvo que lo necesites)

Registros TXT: verificación, SSL y seguridad de correo

A menudo añadirás TXT para comprobaciones de propiedad de dominio (verificación de plataforma) y para la validación de certificados SSL (algunas CA validan mediante un token TXT). TXT también se usa para políticas de correo como SPF. Borrar o reemplazar un SPF existente puede romper la entrega de mail.

TTL: tu perilla de “velocidad de cambio”

TTL controla cuánto tiempo otros sistemas cachean la respuesta DNS. Un día antes del corte, baja el TTL en los registros que planeas cambiar (comúnmente 300 a 600 segundos). Después de que todo esté estable, súbelo otra vez para reducir la carga de consultas.

Evita sobrescribir registros existentes y documenta el rollback

Antes de editar, exporta o haz una captura de pantalla de la zona actual. Anota cada registro que vas a cambiar, su valor antiguo, nuevo y TTL. Si algo falla, el rollback es restaurar los valores previos.

Esto es especialmente importante cuando tu dominio ya tiene MX, DKIM u otros TXT para correo.

Emisión de SSL: validación, tiempos y cobertura

SSL (el icono de candado) cifra el tráfico entre el navegador y tu app. Los navegadores modernos y muchas APIs esperan HTTPS por defecto. Sin él, puedes tener advertencias, peticiones bloqueadas y funciones como service workers, geolocalización o algunos flujos de pago pueden dejar de funcionar.

Para emitir un certificado, la autoridad certificadora debe verificar que controlas el dominio. Los métodos comunes de validación son validación HTTP y validación mediante TXT en DNS:

• Validación HTTP: coloca un archivo temporal o una respuesta en una URL específica de tu app.
• Validación DNS TXT: añade un registro TXT en tu zona DNS.

La validación DNS suele ser más sencilla cuando usas un CDN o cuando tu app aún no es accesible en el nuevo dominio.

Dónde se emite el certificado depende de tu arquitectura. Algunos equipos emiten certificados directamente en su stack de hosting, otros lo hacen en el CDN, y algunas plataformas que soportan dominios personalizados lo gestionan por ti (por ejemplo, Koder.ai puede gestionar el certificado durante la configuración del dominio). Lo importante es saber quién posee el ciclo de vida del certificado, incluidas las renovaciones.

Tiempos y reintentos

La emisión de certificados no siempre es instantánea. La propagación DNS, las comprobaciones de validación y los límites de tasa pueden retrasarla. Planifica reintentos y evita programar el corte para el último minuto.

Un plan práctico de tiempos:

• Baja el TTL de DNS un día antes para que los cambios se apliquen más rápido.
• Añade los registros de validación con antelación (TXT en DNS o token HTTP).
• Espera hasta que el certificado aparezca como emitido para todos los hostnames.
• Solo entonces apunta el tráfico al nuevo destino.

Cobertura: incluye los hostnames correctos

Un certificado debe cubrir todos los hostnames a los que los usuarios accederán. Revisa la lista SAN (Subject Alternative Names). Si tu app estará disponible en example.com y www.example.com, el certificado debe incluir ambos.

Los comodines (como *.example.com) ayudan para muchos subdominios, pero no cubren el dominio apex (example.com).

Ejemplo concreto: si solo emites un certificado para www.example.com, los usuarios que escriban example.com verán advertencias a menos que hagas una redirección en una capa que ya tenga un certificado válido para example.com.

Reglas de redirección: www, apex, HTTP a HTTPS y valores seguros

Las redirecciones parecen simples, pero aquí aparecen la mayoría de los problemas de dominio: bucles, contenido mixto y usuarios que pierden la sesión porque rebotaron entre hostnames.

Elige un host canónico y apégate a él: www.example.com o example.com (apex). El otro punto de entrada debe redirigir a tu host canónico para mantener consistencia en cookies, sesiones y señales SEO.

Valores seguros por defecto:

• Un host canónico, con una única redirección 301 desde el otro host
• Redirección 301 de http:// a https:// para cada petición
• Preservar la ruta completa y la query string durante redirecciones (los enlaces profundos deben seguir funcionando)
• Redirigir solo una vez (evita cadenas como http -> https -> www)

Para HTTP a HTTPS, evita reglas que hagan rebotar a los usuarios. La forma más fácil de prevenir bucles es basar la decisión en lo que la petición realmente fue. Si tu app está detrás de un proxy o CDN, configúralo para respetar los encabezados reenviados (por ejemplo, un header que diga que el esquema original fue HTTP). De lo contrario, tu app puede pensar que cada petición es HTTP y seguir redirigiendo para siempre.

Durante una mudanza, mantiene las rutas antiguas vivas. Si cambias rutas (por ejemplo /login a /sign-in), añade redirecciones explícitas para esas rutas. No confíes en una redirección general hacia la página principal; eso rompe marcadores y enlaces compartidos.

Evita activar HSTS al principio. Si lo activas demasiado pronto y después necesitas servir HTTP para validación o solución de problemas, los navegadores podrían negarse. Espera hasta que HTTPS esté estable y hayas confirmado la cobertura de subdominios.

Para probar redirecciones sin afectar a todos, usa un hostname de prueba temporal, prueba enlaces profundos reales (incluyendo páginas de autenticación) y ejecuta una petición por línea de comandos que muestre cada paso de redirección y el destino final.

Plan de corte paso a paso y de bajo riesgo (sin tiempo de inactividad)

Un corte seguro es mayormente cuestión de tiempos. Quieres que tu nuevo dominio esté listo y probado antes de que cualquier usuario real lo vea, y quieres que los cambios DNS se propaguen rápido para no quedarte esperando durante un incidente.

1) Preparar y probar antes de tocar el DNS de producción

Baja el TTL de DNS (de los registros que cambiarás) con suficiente antelación. Hazlo el día antes si puedes y espera la ventana del TTL antiguo para que las caches cojan el valor más bajo.

Luego, añade el dominio personalizado en tu hosting/proveedor y completa la verificación que pidan. Si usas una plataforma como Koder.ai, añade el dominio allí primero para que la plataforma confirme propiedad y prepare el enrutamiento.

Emite SSL con antelación. Los certificados pueden tardar minutos o más según la validación, y no quieres ese retraso durante el cambio.

Antes de hacer público el dominio, haz una prueba privada: accede al nuevo endpoint de una forma que no dependa del DNS público (por ejemplo, usando una entrada temporal en el host de tu máquina) y confirma que el sitio carga por HTTPS con el certificado correcto.

2) Cortar en pasos pequeños y reversibles

Usa un enfoque por etapas para poder parar rápido si algo falla:

• Reduce TTL con antelación y espera a que el periodo del TTL anterior haya pasado.
• Completa la verificación de dominio en tu host y confirma que el dominio apunta internamente a la app correcta.
• Confirma que SSL está activo para cada hostname que vayas a servir (apex y/o www) antes de cambiar usuarios.
• Cambia DNS de forma controlada: empieza con un subdominio, una región pequeña o una ruta de audiencia limitada si puedes.
• Mantén el dominio antiguo en línea y redirigiendo mientras observas tráfico y tasas de error estabilizarse.

Si no puedes hacer un canario real a nivel DNS, aún puedes escalonar cambiando solo un hostname primero (por ejemplo www) y dejando el apex intacto hasta tener confianza.

3) Planea el rollback mientras aún estás tranquilo

Anota exactamente qué revertirás (qué registros, qué valores) y quién lo hará. El rollback suele ser volver a poner el DNS como estaba.

Asegúrate de que la configuración antigua siga siendo válida (incluido SSL en el dominio antiguo) para que los usuarios puedan volver sin problemas mientras arreglas la nueva ruta.

Evitar cookies rotas, sesiones y problemas de auth después del cambio

Un cambio de dominio no es solo un cambio DNS. Para muchas apps, “estar logueado” depende de cookies que los navegadores atan a un hostname específico. Si cambias de hostname, el navegador puede dejar de enviar las cookies antiguas y tu app parecerá que ha cerrado sesión a todos.

Los ajustes de cookie suelen ser la razón:

• Domain decide qué hostnames pueden recibir la cookie. Una cookie puesta para app.old.com no se enviará a app.new.com. Una cookie puesta para .example.com puede funcionar entre app.example.com y www.example.com.
• Path limita dónde se envía la cookie. Si es demasiado estrecho (como /api), la interfaz web puede no verla.
• Secure significa que la cookie solo se envía por HTTPS. Tras moverte a HTTPS-only, cualquier petición HTTP no la incluirá.
• SameSite afecta redirecciones cross-site y flujos embebidos. Lax suele estar bien, pero algunos SSO o redirecciones de pago pueden necesitar None más Secure.

Para reducir riesgos, planifica una transición corta donde ambos dominios funcionen. Mantén el hostname antiguo respondiendo y redirigiendo con cuidado, pero permite que las sesiones se refresquen en el nuevo dominio. Si puedes, usa un almacén de sesiones compartido para que un usuario que llegue a cualquiera de los hostnames pueda ser reconocido.

Si usas SSO u OAuth, actualiza las configuraciones antes del corte: URLs de callback, orígenes permitidos y cualquier allowlist de redirect URI. Si no lo haces, los inicios de sesión pueden tener éxito en el proveedor de identidad pero fallar al regresar a tu app.

Prueba primero los flujos que suelen romperse: registro (y verificación por email), inicio de sesión/cierre, restablecimiento de contraseña, checkout o retorno de pago, y sesiones con varias pestañas.

Ejemplo: si rediriges www.example.com a example.com, asegúrate de que las cookies se configuren para .example.com (o usa consistentemente un único hostname). Si no, los usuarios rebotan entre hostnames y pierden sesión.

Errores comunes que causan interrupciones o comportamientos extraños

La mayoría de los problemas de dominio no son “misteriosas fallas de internet”. Son pequeñas descoordinaciones entre DNS, certificados y reglas de redirección que solo aparecen cuando usuarios reales llegan al sitio.

Una trampa fácil es el dominio apex (example.com). Muchos proveedores DNS no permiten un CNAME verdadero en el apex. Si intentas forzar un CNAME en el apex puede fallar silenciosamente, resolverse de forma inconsistente o romperse solo en algunas redes. Usa lo que tu host DNS soporte (a menudo un registro A/AAAA, o un registro ALIAS/ANAME).

Otra causa frecuente de tiempo de inactividad es cambiar el DNS antes de que SSL esté listo en el nuevo endpoint. Los usuarios llegan, la app carga y luego el navegador lo bloquea porque falta el certificado o solo cubre parte de tus hostnames. En la práctica, normalmente quieres que el certificado cubra tanto example.com como www.example.com, incluso si planeas redirigir uno al otro.

Errores comunes que crean interrupciones o comportamiento extraño:

• Cambiar DNS sin bajar TTL con antelación y luego esperar horas a que expiren las respuestas antiguas
• Mantener reglas de redirección que crean bucles (www al apex, luego apex de vuelta a www), o forzar HTTP en un lado y HTTPS en otro
• Enviar contenido mixto por hardcodear recursos con http://, lo que provoca advertencias y funciones rotas
• Olvidar registros DNS no web, especialmente MX y TXT, que pueden romper correo y verificaciones de dominio
• Probar solo en un navegador y no ver cachés HSTS o peculiaridades de cookies que otros usuarios padecerán

Una comprobación rápida: abre ambos hostnames (www y apex) por HTTPS, inicia sesión, refresca y confirma que la barra de direcciones nunca vuelve a HTTP.

Si haces esto en una plataforma como Koder.ai, confirma que los dominios personalizados están conectados y que SSL se emitió antes de tocar el DNS de producción, y mantén una opción de rollback para que una mala redirección o un cambio de registro no persista.

Lista de verificación rápida antes, durante y después del corte

Un corte calmado es casi todo trabajo de preparación. El objetivo es simple: los usuarios deben seguir iniciando sesión, las cookies deben seguir funcionando y debes poder revertir rápido si algo va mal.

Antes del corte

Haz esto mientras el tráfico sigue yendo al dominio antiguo. Date un día si puedes, para que los cambios DNS tengan tiempo de asentarse.

• Baja el TTL de DNS (de los registros que cambiarás) y anota los valores actuales para poder restaurarlos rápido.
• Documenta cada hostname que vas a servir (apex, www, api, etc.) y elige tu método de validación SSL (DNS o HTTP).
• Prepara reglas de redirección y pruébalas en staging: HTTP a HTTPS, www al apex (o viceversa) y un host canónico.
• Actualiza ajustes de autenticación que dependen de URLs exactas: callbacks OAuth, orígenes permitidos, configuraciones de cookie y SSO.
• Decide quién vigila qué durante el corte (logs, checks de disponibilidad, bandeja de soporte) y fija una ventana corta de cambio.

Durante y después del corte

Cuando cambies el DNS, trata la primera hora como un ejercicio de incidente. Observa los flujos reales de usuarios, no solo los paneles de estado.

• Durante: monitoriza picos de 4xx/5xx, bucles de redirección y fallos de inicio de sesión (especialmente “invalid redirect URI” o caídas de sesión repentinas).
• Después: confirma la cadena de certificados en varios navegadores y que las páginas importantes cargan en HTTPS sin contenido mixto.
• Después: verifica el comportamiento del host canónico (solo un host en la barra de direcciones) y que las cookies críticas se establecen y se envían.
• Después: mantén la redirección del dominio antiguo por un tiempo. Muchos usuarios volverán por marcadores antiguos, emails o enlaces en caché.

Aunque Koder.ai (u otra plataforma) gestione dominios personalizados y SSL por ti, esta lista sigue siendo importante. La mayoría de los problemas vienen de DNS y redirecciones, no del código de la app.

Ejemplo: pasar de una URL de plataforma a un dominio personalizado

Tu app corre en una dirección temporal de plataforma como myapp.koder.ai. Funciona, pero quieres que los clientes usen example.com, con www.example.com redirigiendo al apex, y todo forzado a HTTPS.

Un plan DNS simple mantiene el riesgo bajo. Antes de cambiar nada, anota el estado actual que funciona (haz una captura si tu plataforma lo permite, como Koder.ai) y reduce el TTL a algo corto con 24 horas de antelación.

Añade los nuevos registros dejando la URL de la plataforma intacta:

• example.com: registro A/ALIAS apuntando al objetivo de hosting que te proporcione la plataforma
• www.example.com: CNAME apuntando a example.com (o al objetivo de la plataforma, según el proveedor)
• Mantén myapp.koder.ai tal cual para tener siempre un fallback conocido y funcional

Una vez el DNS esté en su sitio, solicita SSL para ambos hostnames (example.com y www.example.com). No cambies el tráfico hasta que el certificado esté emitido y activo, de lo contrario los usuarios verán advertencias del navegador.

Cronograma de corte con puntos de control claros:

• T-24h: baja TTL, confirma que puedes revertir rápido
• T-0: habilita el dominio en el host de la app, verifica que SSL está listo
• T+15m: prueba example.com en una ventana de incógnito (página principal, assets estáticos, llamadas a la API)
• T+30m: habilita redirecciones (HTTP a HTTPS, y www al apex)
• Momento de rollback: si fallan logins o llamadas API, revierte el DNS al destino previo y mantén la URL de la plataforma viva

Después del cambio, valida el comportamiento de cookies. Inicia sesión, refresca y comprueba que sigues logueado en www y en el apex. Si las sesiones se rompen, suele deberse a configuración de dominio de cookie o SameSite que aún asume el host antiguo.

Siguientes pasos: monitoriza, documenta y haz futuros cambios más seguros

Después de que el corte funcione, el trabajo no termina. La mayoría de las mudanzas de dominio fallan más tarde porque nadie detecta un deterioro lento: un certificado cerca de expirar, un cambio DNS apresurado o una modificación de redirección que rompe un flujo de login.

Establece una pequeña rutina de monitorización que realmente mantendrás. No necesitas una herramienta empresarial para empezar, pero sí algunas señales fiables: checks de disponibilidad para páginas clave (inicio, login y una página autenticada), alertas de expiración de certificado (por ejemplo, a 30 días y de nuevo a 7 días), seguimiento de tasas de error (vigila picos de 4xx/5xx, no solo uptime) y validación ocasional de redirecciones (HTTP va a HTTPS y el hostname preferido gana).

Mantén una ventana corta de rollback, incluso si todo parece bien. Durante 24 a 72 horas, deja la configuración anterior lista (targets DNS antiguos, configuración de hosting antigua, ajustes TLS antiguos) para que puedas revertir rápido si aparece un problema oculto, como un callback de pago o un proveedor OAuth que aún apunta al dominio antiguo.

Cuando tengas confianza, sube de nuevo los valores TTL. Un TTL bajo es útil durante cambios, pero añade carga a los resolvers y aumenta el impacto de pequeños errores. Elige un TTL normal que coincida con la frecuencia esperada de cambios (muchos equipos eligen 1 a 4 horas).

Finalmente, documenta el estado final mientras aún está fresco: qué registros existen (tipo, nombre, valor, TTL), qué hostnames se soportan y las reglas exactas de redirección. Incluye dónde se emiten los certificados, qué cubren (apex, www, subdominios) y quién posee las renovaciones.

Si construyes y despliegas en una plataforma, ayuda que los dominios sean una función de primera clase y que el rollback sea sencillo. En Koder.ai, los dominios personalizados están junto a snapshots y rollback, lo que puede facilitar futuros cambios de dominio y redirección cuando haya que deshacer algo rápidamente.