El dominio apunta parcialmente y algunos servicios todavía fallan

Si parte de tu dominio funciona pero otras cosas – la web, el correo o API – responden de forma errática, lo más probable es que haya rutas mixtas tras un cambio reciente: delegación incompleta en los servidores de nombres, registros faltantes o mal apuntados, o una CDN/proxy que está interponiéndose. No te alarmes: la diferencia clave es saber si el problema viene de la delegación (qué servidores son los responsables) o de los registros y la configuración dentro de esos servidores.

Qué observas y por qué ocurre

Cuando un dominio “apunta parcialmente” suele suceder que distintos resolvers (los servidores DNS que usan los usuarios) están recibiendo respuestas diferentes. Eso ocurre si algunos resolvers consultan servidores autoritativos antiguos y otros consultan los nuevos; también si faltan registros en el servidor autoritativo correcto, o si una capa intermedia (CDN, proxy o firewall) cambia la ruta. El resultado: algunos usuarios verán el sitio nuevo, otros seguirán en el anterior; el correo puede fallar porque los registros MX o TXT no están bien propagados, o el certificado TLS no coincide con el host que responde.

También puedes revisar esta lectura relacionada para contrastar el criterio antes de decidir La renovación cuesta mucho más que el primer periodo.

Mecanismo básico: delegación, registros y cachés

La delegación es la asignación en el registrador que dice “estos servidores de nombres son los responsables de mi dominio”. Si la delegación está incompleta o con errores, algunos resolvers todavía preguntarán a los servidores antiguos. Incluso con delegación correcta, cada servidor autoritativo debe contener los registros necesarios: A (IP), CNAME (alias), MX (correo), TXT (SPF/DKIM), etc. Además, los caches de Internet memorizan respuestas hasta que expira su TTL; eso explica por qué el comportamiento puede normalizarse de forma gradual.

Si el siguiente paso es atraer visitas, esta lectura te ayuda a conectar la decisión con una fuente de tráfico El tráfico crece pero todavía no satura la infraestructura.

Cómo comprobarlo desde ya

Las comprobaciones básicas te dicen si el origen del fallo es delegación, registros o la propia configuración del servicio. Hazlas en este orden práctico:

• Confirma quién gestiona el DNS: entra en el panel del registrador del dominio y mira los servidores de nombres (nameservers). Si no tienes acceso, pide a quien lo tenga que lo verifique.
• Comprueba la delegación pública: usa una herramienta de consultas DNS como dig o un comprobador en línea para ver los NS que devuelve la zona raíz. Por ejemplo, con dig: dig +ns midominio.com y dig +trace midominio.com; si los NS listados por la raíz no coinciden con los del registrador, la delegación está mal.
• Consulta los servidores autoritativos: con dig @ns1.proveedor midominio.com A (reemplaza ns1.proveedor por los nameservers que debería responder) y compara la respuesta con la que obtienes desde un resolver público (por ejemplo, dig @8.8.8.8 midominio.com A).
• Revisa registros críticos: dig MX para correo, dig TXT para SPF/DKIM, dig CNAME/A para web y APIs. Busca registros faltantes, que apunten a IPs antiguas o a hosts equivocados.
• Prueba los servicios directamente: para la web usa curl -I https://midominio.com para ver encabezados y códigos; para SMTP puedes usar telnet a puerto 25 al host MX para verificar conexión; si el HTTPS falla por certificado, una prueba con openssl s_client -connect midominio.com:443 mostrará el certificado presentado (esta última es más técnica).
• Verifica desde varios puntos: usa comprobadores públicos de DNS y desde redes móviles o diferentes proveedores para detectar si el problema es local o global.

Qué arreglar primero y por qué

La regla práctica es: primero la delegación, luego los registros, y por último la configuración del servicio. Motivos:

• Si la delegación es incorrecta, cualquier corrección dentro del servidor DNS “correcto” no será consultada por muchos resolvers.
• Si la delegación es correcta pero faltan registros o apuntan al lugar equivocado, corrige A/CNAME para la web y MX/TXT para el correo; esas correcciones suelen ser inmediatas en el autoritativo aunque tardan en llegar a caches.
• Si los registros son correctos pero la web o API responden mal, revisa la configuración del servidor de destino: virtual hosts (para que el host coincida con el dominio), certificados TLS (que cubran el dominio) y reglas del CDN/proxy (que pueden reescribir cabeceras o ocultar la IP real).

En la práctica, si no controlas el registrador debes pedir al titular que actualice la delegación. Si no controlas los registros dentro del proveedor de DNS, contacta con quien los administre y comparte las pruebas anteriores.

Un ejemplo concreto

Imagina que migraste tu sitio a un nuevo hosting y en el panel del host configuraste los registros A y CNAME, pero olvidaste cambiar los nameservers en el registrador. Algunos resolvers consultan aún los NS antiguos y muestran el sitio viejo; otros, tras pedir a los nuevos NS, muestran el sitio nuevo. Resultado: usuarios ven versiones diferentes y el correo puede ir al servidor antiguo porque los MX no están sincronizados. Solución en ese ejemplo: actualizar los nameservers en el registrador para delegar a la nueva DNS, esperar a que se propague y luego verificar que todos los registros necesarios estén presentes en ese proveedor DNS.

Si después de todas las comprobaciones la delegación, los registros y la configuración del servicio parecen correctos pero el problema persiste desde ciertas ubicaciones, decide si conviene esperar el tiempo de propagación (si acabas de cambiar) o escalar al soporte del registrador, del proveedor DNS o del CDN según quién controle el elemento que falla. Esa decisión – corregir tú la delegación, esperar a la propagación o pedir soporte – depende de a quién tengas acceso y del impacto en tu proyecto; elige la opción que permita volver a un estado conocido y reversible mientras reduces la pérdida de correos o visitantes.