Monitor DNS
El monitor DNS verifica que la resolución de nombres de un dominio devuelve las respuestas esperadas. Es esencial para detectar problemas de propagación, configuraciones incorrectas o cambios no autorizados en DNS antes de que afecten a tus servicios.
¿Cuándo usarlo?
- Detectar cambios de DNS no autorizados o accidentales en cualquier registro crítico.
- Verificar que los registros MX de tu dominio de correo son los correctos y no han sido modificados.
- Comprobar que un CNAME apunta al destino correcto después de una migración.
- Monitorear que un registro A o AAAA devuelve la IP esperada tras un cambio de proveedor o una reconfiguración.
- Confirmar que los registros TXT de SPF, DKIM o verificación de dominio siguen en su lugar.
- Supervisar la propagación de cambios de DNS y detectar inconsistencias entre regiones.
¿Qué comprueba?
En cada check el probe realiza una consulta DNS directa y valida el resultado:
- UP: la consulta resuelve correctamente y la respuesta coincide con los valores esperados.
- DOWN: la consulta falla, el dominio no existe (
NXDOMAIN), hay un error de servidor (SERVFAIL), o la respuesta no coincide con lo configurado.
Tipos de registro soportados
| Tipo | Uso típico |
|---|---|
A | Dirección IPv4 de un dominio (ejemplo.com → 93.184.216.34). |
AAAA | Dirección IPv6 de un dominio. |
CNAME | Alias de un dominio a otro nombre (www.ejemplo.com → ejemplo.com). |
MX | Servidores de correo del dominio. |
TXT | Registros de texto: SPF, DKIM, verificación de dominio, etc. |
NS | Servidores de nombres autoritativos del dominio. |
Validación del resultado
Puedes especificar el valor exacto que esperas en la respuesta:
- Con valor esperado: el check pasa si la respuesta incluye el valor configurado. Si el registro devuelve varios valores (por ejemplo, múltiples IPs en balanceo round-robin), basta con que uno coincida.
- Sin valor esperado: el check solo verifica que la consulta resuelve sin error — útil cuando solo quieres saber si el dominio existe y responde, sin importar el valor concreto.
Formato del valor esperado por tipo de registro
| Tipo | Ejemplo de valor esperado |
|---|---|
A | 93.184.216.34 |
AAAA | 2606:2800:220:1:248:1893:25c8:1946 |
CNAME | destino.cdn.com |
MX | mail.ejemplo.com |
TXT | v=spf1 include:_spf.google.com ~all |
NS | ns1.ejemplo.com |
Configuración
| Campo | Descripción |
|---|---|
| Dominio | El nombre de dominio a consultar (ej. ejemplo.com, correo.ejemplo.com). Sin http:// ni ruta. |
| Tipo de registro | El tipo de registro DNS a consultar: A, AAAA, CNAME, MX, TXT, NS. |
| Valor esperado | Valor que debe aparecer en la respuesta. Déjalo vacío para verificar solo que el dominio resuelve. |
| Intervalo | Frecuencia de comprobación. |
| Timeout | Tiempo máximo de espera antes de marcar el check como DOWN. |
Incidentes y alertas
El monitor DNS sigue el mismo motor que los demás monitores: los probes consultan verificaciones pendientes, ejecutan la consulta DNS de forma independiente y reportan el resultado al hub. El hub aplica el consenso multi-región antes de abrir un incidente — si un probe tiene un problema de resolución local pero los demás resuelven correctamente, no se genera un incidente falso.
Diferencia con un monitor HTTP
Un monitor HTTP también detectará indirectamente problemas de DNS — si el dominio no resuelve, el request HTTP fallará — pero el error será genérico: solo sabrás que el sitio no carga. El monitor DNS es específico: te indica exactamente qué registro falló, qué valor devolvió el servidor y cuál era el esperado.
| Monitor | Detecta fallo DNS | Indica qué registro falló |
|---|---|---|
| HTTP | Indirectamente (el sitio no carga) | No |
| DNS | Directamente | Sí |
Para servicios críticos, combina ambos: un monitor DNS detecta si la resolución es correcta; un monitor HTTP confirma que el servicio responde correctamente una vez resuelta la dirección.
Buenas prácticas
- Monitorea los registros más críticos con valor esperado explícito: el registro
Aprincipal, losMXde correo y losNSautoritativos. Así detectas cambios no autorizados, no solo fallos de resolución. - Para registros TXT como SPF o DKIM, configura el valor esperado como la cadena completa — un cambio parcial en SPF puede romper la entrega de correo sin que el dominio deje de resolver.
- Cuando hagas un cambio de DNS intencional, actualiza el valor esperado en el monitor antes o al mismo tiempo que el cambio. Así el monitor no genera falsos positivos durante la propagación.
- Usa el monitor DNS junto con un monitor HTTP para el mismo dominio: si el DNS cae pero el HTTP sigue UP (desde caché), el DNS te avisa primero; si el HTTP cae pero el DNS está UP, el problema es de aplicación.
Limitaciones actuales
| Limitación | Detalle |
|---|---|
| Estado DEGRADED | No soportado. El resultado es siempre UP o DOWN. |
| Servidor DNS personalizado | Los probes consultan usando su resolver regional. No es posible especificar un nameserver concreto (ej. el autoritativo del dominio). |
| Propagación y TTL | Justo después de un cambio de DNS, los probes pueden devolver valores distintos según su caché regional. Si el valor esperado no coincide con lo que devuelve el resolver de un probe, ese check reportará DOWN hasta que el TTL expire y el nuevo valor se propague. Esto es comportamiento normal durante una propagación. |