Cuando el DNS falla, un sitio web sano se vuelve inalcanzable. El servidor está en marcha, la aplicación está bien, pero el navegador del visitante no puede averiguar a dónde conectarse. El navegador informa de algo como «servidor no encontrado», y no dice nada más.

Esta guía te ayuda a descubrir qué tipo de fallo es y dónde ocurre. Para una explicación sencilla de los términos, consulta resolución DNS.

Lee primero el síntoma

Una respuesta DNS lleva un estado. Cuatro resultados cubren la mayoría de los casos.

Lo que ves Significado Causas habituales
NXDOMAIN El nombre no existe Un error tipográfico, un registro o una zona eliminados, una delegación que falta, un dominio vencido
Respuesta vacía, estado NOERROR El nombre existe, pero no tiene un registro del tipo que pediste No hay registro AAAA en un sitio que solo usa IPv4. Suele ser normal
SERVFAIL El servidor no pudo completar la consulta Los servidores de nombres de la zona no responden o responden mal, una delegación rota, una comprobación DNSSEC fallida
Tiempo de espera agotado, sin respuesta Nadie respondió a tiempo Una red bloqueada, un resolvedor sobrecargado o caído, un cortafuegos

La RFC 1035 define los códigos de «fallo del servidor» y «error de nombre» (el nombre no existe). La RFC 8499 explica los nombres habituales SERVFAIL y NXDOMAIN. A la respuesta vacía a veces se la llama NODATA. No es un estado propio, solo una respuesta correcta sin nada dentro.

Haz pruebas con dig

dig es la herramienta estándar en Linux y macOS. Muestra el estado en la línea de cabecera.

dig example.com A
dig example.com AAAA

Busca la línea status: en la salida. Para quedarte solo con las direcciones:

dig +short example.com A

Windows tiene nslookup:

nslookup example.com

Pregunta a otro resolvedor

De forma predeterminada preguntas al resolvedor que te dio tu red. Para preguntar a otro, nómbralo después de @:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Si tu resolvedor habitual falla y los demás responden, el problema es el resolvedor o el camino hasta él, no tu dominio. Si todos los resolvedores fallan, el problema está en tu zona o en tu delegación.

Pregunta a los servidores autoritativos

Averigua qué servidores son responsables del dominio y pregúntales directamente:

dig example.com NS +short
dig @ns1.your-dns-provider.example example.com A

Un servidor autoritativo conoce la zona a partir de sus propios datos. Si devuelve la dirección correcta mientras los resolvedores públicos no, es probable que la respuesta esté en caché en algún sitio, o que la delegación en el registrador apunte a otra parte. Si el servidor autoritativo no responde en absoluto, tu proveedor de DNS tiene un problema.

Recorre la cadena

dig +trace empieza en la raíz y sigue cada delegación:

dig +trace example.com

Muestra qué paso deja de responder. Un recorrido que termina con el registro sin dar servidores de nombres para tu dominio sugiere un problema de delegación, a menudo un registro que ha caducado.

Acótalo

Trabaja de fuera hacia dentro.

  1. ¿Lo ven otras redes? Prueba con un teléfono con datos móviles y con un resolvedor público. Si solo falla tu red, revisa los resolvedores locales, una VPN o un filtro.
  2. ¿Venció el dominio? Un registro vencido es una causa común de un NXDOMAIN repentino. Comprueba la fecha como se describe en Cómo comprobar cuándo vence un dominio.
  3. ¿Cambió la delegación? Si se cambiaron los servidores de nombres en el registrador, compara los registros NS del registro con los servidores donde vive realmente la zona.
  4. ¿Cambió algún registro? Un registro A, AAAA o CNAME eliminado o mal escrito da una respuesta vacía o incorrecta.
  5. ¿Falla la máquina local? Revisa el archivo hosts, vacía la caché local y prueba desde otro dispositivo.

Por qué una corrección no se ve en todas partes a la vez

Los resolvedores guardan las respuestas en caché. Las respuestas positivas se conservan durante el tiempo de vida (TTL) del registro. Las respuestas negativas también se guardan: la RFC 2308 describe el almacenamiento en caché de las respuestas «el nombre no existe» y «sin datos», usando el tiempo indicado por el registro SOA de la zona. Un resolvedor que oyó NXDOMAIN un momento antes de que crearas el registro puede seguir diciéndolo hasta que ese tiempo se agote.

Un SERVFAIL también puede guardarse en caché, aunque la RFC 2308 pide que ese almacenamiento no supere los cinco minutos.

Así que, después de una corrección, haz primero la prueba contra los servidores autoritativos. Ellos muestran la verdad. Los resolvedores públicos se ponen al día a medida que caducan sus cachés.

A y AAAA: una caída parcial que se esconde bien

Un registro A contiene una dirección IPv4 (RFC 1035). Un registro AAAA contiene una dirección IPv6 (RFC 3596). Un sitio puede tener ambos o solo A.

Que falte el registro AAAA es normal. Que sea incorrecto no lo es: un visitante cuya conexión prefiere IPv6 puede ser enviado a una dirección donde nadie responde, mientras que los visitantes con IPv4 ven un sitio que funciona. Si los avisos de «el sitio está caído» vienen solo de algunos usuarios, compara dig example.com A con dig example.com AAAA.

Qué comprueba UptimeWire

Una vez por hora, para cada sitio web, UptimeWire resuelve el nombre de host del sitio con el resolvedor estándar del sistema y examina la respuesta:

  • La comprobación se supera cuando el nombre se resuelve en al menos una dirección pública.
  • Falla cuando el dominio no existe (NXDOMAIN) o cuando el nombre se resuelve solo en direcciones privadas.
  • Muestra desconocido cuando el servidor de nombres no respondió. Un DNS inalcanzable no dice nada seguro sobre el dominio, así que no se envía ningún aviso.

Cuando la comprobación pasa de correcta a fallida, UptimeWire envía un único aviso por correo y por Telegram, con el motivo. Un aviso de DNS no es un incidente y no va a canales de webhook ni de chat.

La comprobación ordinaria del sitio web también falla cuando el nombre no puede resolverse, con el motivo «no se pudo resolver el nombre de dominio». Tras fallos repetidos, esa comprobación puede abrir un incidente.

UptimeWire no detecta cambios en los registros DNS, no sigue la propagación, no consulta otros tipos de registro como MX o TXT y no valida DNSSEC. Te dice que el nombre dejó de resolverse, no por qué.

Lista de comprobación

  • Anota el estado exacto: NXDOMAIN, respuesta vacía, SERVFAIL o tiempo de espera agotado.
  • Consulta dos resolvedores públicos y los servidores autoritativos.
  • Comprueba la fecha de registro y los servidores de nombres en el registrador.
  • Compara las respuestas A y AAAA.
  • Acuérdate de la caché antes de decidir que una corrección no funcionó.
  • Guarda un registro de qué cambió y cuándo.