Síntoma y contexto
Un dominio que "no apunta bien" puede significar varias cosas distintas y cada una lleva a un diagnóstico diferente. A veces el navegador muestra "no se puede acceder a este sitio" o un error DNS_PROBE_FINISHED_NXDOMAIN. Otras veces la página carga, pero es la del registrador, una web antigua en otro hosting o un certificado SSL que no coincide con el dominio. También está el caso en que la web funciona pero el correo deja de entrar o salir justo después de mover DNS o cambiar de proveedor.
Estos síntomas suelen aparecer al registrar un dominio nuevo, migrar de hosting, activar Cloudflare por primera vez, conectar un SaaS (Webflow, Shopify, Carrd) o recuperar un dominio que estuvo expirado. La confusión típica es editar registros A en el panel del registrador mientras los nameservers del dominio apuntan a otro sitio: los cambios no tienen efecto porque la autoridad DNS está en otro proveedor.
El tiempo también engaña. DNS no es instantáneo: cada registro tiene un TTL (tiempo de vida en caché) y los resolvers de tu ISP, tu router o tu sistema operativo pueden guardar respuestas antiguas durante minutos u horas. Antes de declarar el cambio como fallido, conviene contrastar qué responde un DNS público frente a tu resolución local.
Esta guía te ayuda a ordenar el problema: primero el síntoma visible, luego quién controla la zona DNS, después los registros concretos y por último si toca esperar propagación o corregir configuración. No hace falta ser administrador de sistemas; basta con saber qué pantalla mirar y qué capturar si necesitas ayuda remota.
Causas probables
Nameservers apuntando al panel equivocado
El dominio delega la autoridad DNS mediante registros NS. Si compraste el dominio en un registrador pero pusiste los nameservers de Cloudflare, los registros que edites en el registrador (apartado DNS básico) no se usan. Hay que editar la zona donde apuntan los NS. Lo mismo ocurre al revés: nameservers del hosting mientras sigues cambiando DNS solo en el registrador.
Registro A o CNAME incorrecto en apex o www
El apex (tudominio.com sin www) no puede usar CNAME clásico en todos los proveedores; a veces hace falta registro A a una IP, ALIAS/ANAME o CNAME flattening de Cloudflare. Si www apunta bien pero el apex no (o al contrario), los usuarios ven comportamientos distintos según cómo escriban la URL. Registros A obsoletos hacia la IP del hosting anterior mantienen vivo el sitio viejo para quien aún tiene caché o para quien resuelve por esa IP.
Propagación y TTL alto
Un TTL de 86400 segundos (24 horas) hace que muchos resolvers sigan sirviendo la IP antigua hasta que expire. Tras un cambio urgente, bajar TTL con antelación ayuda; si el cambio ya se hizo con TTL alto, solo queda esperar o limpiar caché local. No confundas "no ha propagado" con "registro mal puesto": si DNS públicos ya muestran el valor nuevo y tú ves el viejo, es caché local.
Dominio expirado o en estado de retención
Si el dominio no renovó a tiempo, puede dejar de resolver o mostrar página del registrador. Comprueba fecha de expiración y estado (active, redemption, clientHold). Un clientHold por verificación de datos o disputa bloquea resolución aunque los registros parezcan correctos en el panel.
Conflicto entre web y correo tras mover DNS
Al cambiar nameservers a un proveedor nuevo, hay que recrear MX, TXT (SPF, verificación), DKIM y a veces SRV. Olvidar los MX es la causa más común de "la web va pero el correo murió". También pasa al apuntar el apex a un hosting que no contempla correo en el mismo dominio.
Cloudflare u otro proxy mal configurado
El icono naranja (proxy activo) oculta la IP real y pasa el tráfico por la red del proveedor. Si el origen no acepta conexiones o el certificado de origen es inválido, aparecen errores 525 o 526. Modo "solo DNS" (gris) expone la IP y simplifica el diagnóstico. Reglas de página o redirects en Cloudflare pueden enviar el dominio a una URL inesperada.
Registros duplicados o wildcards
Dos registros A distintos para el mismo nombre, un wildcard (*) que captura subdominios no previstos o un CNAME en el apex junto con otros registros pueden producir respuestas impredecibles según el resolver. Limpia la zona y deja una sola cadena coherente hacia el destino actual.
Caché del navegador y HTTPS
Menos frecuente que DNS, pero un HSTS antiguo o redirecciones cacheadas pueden hacer creer que el dominio apunta mal cuando el fallo es solo en tu navegador. Prueba en ventana privada o otro dispositivo en datos móviles para descartarlo.
Checklist copiable
DOMINIO QUE NO RESUELVE - CHECKLIST □ Dominio exacto (con/sin www, subdominio si aplica) □ Síntoma: no carga / sitio viejo / parking / solo correo roto □ Registrador del dominio y fecha de expiración □ Nameservers actuales (captura del panel del registrador) □ ¿Dónde editas DNS hoy? (registrador / Cloudflare / hosting) □ Registro A o AAAA del apex → IP esperada □ Registro www → CNAME o A correcto □ Registros MX presentes si usas correo en ese dominio □ TXT SPF y DKIM sin borrar tras el último cambio □ TTL de los registros modificados □ Hora del último cambio DNS □ Prueba: dig / nslookup desde tu red □ Prueba: DNS público (1.1.1.1 o 8.8.8.8) ¿misma respuesta? □ ¿Cloudflare activo? Modo proxy naranja o gris □ Certificado SSL: ¿error de nombre o caducado? □ Cambio reciente de hosting, SaaS o proveedor de correo
Qué capturar
El diagnóstico remoto de DNS se acelera con capturas del panel y salidas de consultas, no con contraseñas del registrador.
Panel del registrador
Captura donde se ven los nameservers delegados y la fecha de expiración del dominio. Si el DNS vive en otro sitio, indícalo explícitamente: "los NS son ada.ns.cloudflare.com y bob.ns.cloudflare.com, edito en Cloudflare".
Zona DNS activa
Exporta la zona o captura la tabla de registros relevantes: A, AAAA, CNAME, MX, TXT críticos. Censura si aparece algún token de verificación largo si prefieres no exponerlo; con los tipos y nombres suele bastar para ver huecos (por ejemplo, sin MX).
Salida de consultas DNS
Desde terminal:
dig tudominio.com A +short dig www.tudominio.com CNAME +short dig tudominio.com MX +short dig tudominio.com NS +short
Sustituye tudominio.com por tu dominio real. Si no usas terminal, herramientas como Google Admin Toolbox Dig o dnschecker.org muestran la misma información. Anota si las respuestas difieren entre tu red y un DNS público.
Error del navegador
Texto literal o captura: NXDOMAIN, timeout, ERR_SSL_VERSION_OR_CIPHER_MISMATCH, nombre en certificado que no coincide. Eso separa problema DNS puro de problema en origen o SSL.
Contexto del cambio
Qué querías lograr (migrar web a X, activar correo en Google Workspace, conectar dominio a Shopify) y qué pasos diste. Si tocaste solo un registro, indica cuál era el valor anterior si lo recuerdas.
Correo si está afectado
Mensaje de rebote completo si el correo falla, proveedor de buzón (Google, Microsoft, Zoho) y si el fallo es entrante, saliente o ambos. Un rebote con "DNS Error" o "MX not found" confirma zona incompleta.
No envíes contraseñas del registrador ni claves privadas. El acceso al panel se acuerda por correo si hace falta, con alcance claro.
Cuándo escalar
Puedes resolver solo muchos casos sencillos: corregir un A hacia la IP nueva, crear el CNAME de www que indica tu hosting, bajar TTL para el próximo cambio o esperar unas horas si los DNS públicos ya muestran lo correcto y solo tu red está en caché. Flushear DNS local (reiniciar router, sudo systemd-resolve --flush-caches en Linux, ipconfig /flushdns en Windows) a veces basta cuando la configuración ya es buena.
Escala cuando:
- Tras 24-48 horas y TTL razonable, los DNS públicos siguen devolviendo valores incorrectos o mezclados.
- No identificas qué panel es autoritativo: registrador y hosting muestran zonas distintas y no sabes cuál manda.
- El dominio está en clientHold, redemption o pendiente de verificación y no sabes el trámite en el registrador.
- Necesitas correo y web en el mismo dominio con un SaaS que exige registros específicos (MX + SPF + DKIM) y la documentación no coincide con tu zona.
- Cloudflare devuelve errores SSL hacia el origen y no tienes acceso al servidor para instalar o renovar certificado.
- Varias personas en distintas redes ven sitios diferentes y sospechas split-horizon o registros duplicados que no localizas.
- El cambio es en producción con tráfico o correo crítico y no puedes permitirte prueba y error prolongada.
Al contactar, usa la categoría Dominio, DNS o correo del formulario. Adjunta la checklist, capturas de NS y registros, salidas de dig y el síntoma exacto. Con eso se puede proponer la secuencia correcta: delegar NS, recrear zona, apuntar apex, restaurar MX o ajustar proxy sin volver a romper el buzón.
DNS parece frágil porque muchos actores intervienen (registrador, CDN, hosting, correo), pero con un solo origen de verdad y registros mínimos necesarios el dominio se comporta de forma estable. Evita tener la misma zona editada en dos sitios y documenta cada cambio con hora y valor anterior: el futuro tú (o quien te ayude) lo agradecerá cuando algo vuelva a "no resolver" en mitad de una migración.